CSE 401: Assignment 3, Due Friday 4/20/01

CSE Home

About Us

Search

Contact Info

Individual homework

Project

As usual, turn in only one solution per group.

Design and implement the necessary extensions to the PL/0 parser and AST class hierarchy to parse and represent the extended PL/0 language. Use the project description and extended BNF description (available after assignment #2 is submitted) as the language definition.

Thinking carefully about the AST extensions will pay off. One particular pitfall to avoid: an array of arrays is not a 2-D array; PL/0 only has 1-D arrays (whose elements can be of any type, including array).

Turn in:

• your files and test cases electronically, and
• print outs of your changed implementation, with your changes clearly highlighted with highlighter pen.

Optional, Extra Credit, Project Extension

It's spring, life's a breeze, you've got tons of time on your hands before graduation, and compilers are groovey, baby. So, if you'd like to dig into it more, a modest number of extra credit points and a significant number of techno-karma points are to be had by implementing a substantive addition to PL/0: add records (structs) to the language (a tiny step towards PL/OO). You/your group get to design the syntax and semantics, and carry through the implementation from scanner through code generation. Ideally, you will turn in various benchmark pieces of this in parallel with the regular assignments, e.g. parsing now, type-checking next time, etc., but we can be a little flexible about the schedule.

1. What to do: start by designing your extensions. Give us written descriptions of the syntax and semantics that you intend to implement, at least at a level of detail comparable to the project description. Where possible, try to think ahead to the types of processing that will be required in later phases, such as the sorts of legality checks that you'll need, issues of scopes of names, parameter passing, storage allocation, etc. Document them briefly. Obviously, I don't expect you to be experts on all those things (until June 7th), but the point is that there are actually a fair number of choices to be made, and some of them will make your life much easier in the later phases, so it pays to try to anticipate the key issues.
2. What not to do: (a) Don't be overly ambitious about what you decide to implement. E.g., records with overloaded polymorphic multiple inheritance, while tempting, is perhaps best left to students a schools on the semester system. (b) Do NOT let work on the extensions interfere with finishing the basic course requirements on time. I'd suggest you not even think about the extensions until you've turned in a clean, debugged version of the basic code, with test cases.
3. What to turn in: For this first turnin, give us documentation for your planned extensions (see 2), together with code and test cases for scanning, AST, and parsing. Next time, you give us your type-checking code, and test cases, etc. Also, if you later decide to change any of your initial design specs, tell us that, and sketch why ("We now realized that doing X will be way easier than Y because it nicely fits in with Z" or whatever).