In this phase you will implement and test the semantic analysis phase of your T compiler. However, you are not responsible for handling arrays or method overloading in this phase. Arrays and method overloading will be handled (both semantic analysis and code generation) in Phase 5.
The semantic analysis phase includes:
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 operators, etc. However, you may defer determining the machine dependent details of the field reference operator (the byte offset of the field in the object) and the method call operator (the byte 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 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 (minus arrays and method overloading). Also include tests that "cover" all possible error cases.
If you detect a weakness in the T language specification, please notify me so that we can discuss it in class (or via e-mail) to resolve the problem.
Develop a Makefile for building and testing your T compiler (scanner, parser and semantic analysis) called "Makefile". The Makefile should include a target called "tc", which builds and names the compiler "tc". (As in Phase 2 the compiler should simply read from stdin.) 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.
Archive all your files in a tar file called "phase3.tar".
You should submit your tar file from turing.unh.edu using my "submit"
script.
To turn in this assignment, type:
~cs712/bin/submit phase3 phase3.tar
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 27. 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 are expected to do your own work on this assignment!
Comments and questions should be directed to hatcher@unh.edu