CS712/CS812
Project Phase 3
Spring 2004
Due Sunday March 28


In this phase you will implement and test the semantic analysis phase of your compiler.

The semantic analysis phase includes:

The symbol table mechanisms do not to be efficient. You may simply use linked lists and linear lookup.

When processing declarations, be sure to detect errors, such as duplicate declarations.

One goal of processing statements and expressions is to fully describe the semantics. Do not leave semantic discovery to the code generation phase. This means, for example, modifying the AST generated by the parser to label the types of operations, inserting dereference and conversion operators, etc. However, you may defer determining the machine dependent details of the field reference operator (the offset of the field in the object) and the method call operator (the offset of the method in the virtual method table) until the code generation phase. You may also leave the control-flow statements as they are, and translate to branches and labels in the code generation phase.

A second goal of processing statements and expressions is to detect errors. All semantic errors should be detected during semantic analysis. Do not leave any error detection for the code generation phase. All error messages should include the line number of (roughly) where the error occurred. Avoid cascades of error messages by marking subtrees containing errors with an error Type (or flag). When analyzing a node, do not generate an error for the node if one of its subtrees has been marked as containing an error.

Print the AST to display the results of semantic analysis. You may need to upgrade your print routines to allow semantic information (such as Type) to be displayed.

Develop a set of tests to thoroughly test your semantic analysis phase. Be sure your tests "cover" the whole language. Also include tests that "cover" all possible error cases.

Continue to update your language specification as needed. Remember you will need to re-submit your document later in the semester.

Develop a Makefile for building and testing your compiler (scanner, parser and semantic analysis) called "Makefile". The default Make target (topmost in the Makefile) should build your compiler. You should have a Make target for running all your compiler tests as one long string of tests, called "test". (You might want to develop scripts for running these strings of tests and then invoke the scripts from the Makefile.) Finally, have a Make target for cleaning up ALL files generated by any of the other Make targets, called "clean".

You can develop your compiler on any system that you have access to, but for grading purposes I will execute it on turing.unh.edu, so be sure to test in that environment.

The deliverables for this phase include the source code for your compiler, all the test programs that you developed, the Makefile, and any other support files needed to build and test your compiler. Also include a README file with your submission that describes the purpose of each file submitted.

If your files are organized in subdirectories, then tar or zip up your files and submit the tar or zip file. In this case include a note in your README file to explain how I should process the tar/zip file.

You should submit your files from turing.unh.edu using my "submit" script. To turn in this assignment, type:
~cs712/bin/submit phase3 list of filenames

Submissions can be checked by typing (also on turing.unh.edu):
~cs712/bin/scheck phase3

To receive full credit for the assignment, you must turn in your files prior to 8am on Monday March 29. Late submissions will be accepted at a penalty of 2 points for one day late, 5 points for two days late, 10 points for three days late, 20 points for four days late, and 40 points for five days late. No program may be turned in more than 5 days late.

Remember: you (with possibly an approved partner) are expected to do your own work on this assignment!


Last modified on March 4, 2004.

Comments and questions should be directed to hatcher@unh.edu