Due 11:59pm Thursday Nov 5
You will implement translation to Intermediate Code Trees, as described in Chapter 7, by traversing the Abstract Syntax Tree (AST) generated by the parser, and translating into intermediate code trees.
Before starting this project, familiarize yourself with Chapter 6 and 7 of the textbook. In addition to the lectures, this will give you a solid foundation for starting your translator.
Source code is available in a tarball in the /homes/cs352 directory, which can be copied into your working directory and expanded by doing the following:
cp /homes/cs352/Fall15/project4.tar.gz ./ tar -xvf
If you wish to integrate the project into an Eclipse project, follow the directions on this blogpost to create an Eclipse project using the included Makefile.
All changes for this project will be done to the translation file mojo/Translate.java in the project4/src subdirectory. Note that the class mojo.Translate extends class mojo.Semant from your previous project, and itself makes use of methods from that class. You can see the source code for those methods in mojo.Semant from your previous project, but we have provided you the canonical implementation of that class as a binary class file.
To make the project, type "make" as per usual. To run your project, go into the bin directory and type:
./p4.sh file.mjwhere file.mj is a Mojo source code file. This will print out the IR tree that you have synthesized.
A litany of tests have been included in the p4tests directory in the base directory of the project. Run these on your translator to check for correct functionality. Each test is a Mojo file. Note that your output need not be identical to the output shown in the included PDF, as long as it represents the correct translation of the AST that comes from the code in each test.
In this project, you will be traversing the AST as in the previous project and converting it into intermediate code trees.
For each procedure we create a Translate.Frame object to represent the activation record for the procedure. Local variables in each procedure are represented as temporaries (Translate.Temp). Two methods are used to reserve space as needed for both local variables and formal parameters in each method: Translate.Frame.allocFormal and Translate.Frame.allocLocal. Both of these methods return a Translate.Frame.Access object that can be used to generate code to access the corresponding variable. We maintain a map from variables to their corresponding Translate.Frame.Access object. In the intermediate code a temporary is similar to a register on an actual processor.
The intermediate code tree (Translate.Tree) comprises objects of two main types: Translate.Tree.Exp and Translate.Tree.Stm. However, these classes are abstract so the objects in the trees will be instances of concrete subclasses of these types.
For each method in each class we create a Translate.Frame and a method body (a tree rooted at a Translate.Tree.Stm). The Translate.Frame and the body together form a fragment of code (in this case a Translate.Frag.Proc). Each Translate.Frag.Proc is added to the linked list called frags.
You should turn in your src/mojo/Translate.java file, using the turnin command available on CS Unix machines. To turn in your project, make sure that you are in the directory that contains your Translate.java file (src/mojo). Then type the following:
turnin -c cs352 -p project4 Translate.java
To verify your turned-in work, do:
turnin -c cs352 -p project4 -v
We will create a set of test cases, and then compare the output of your solution to our reference implementation. Grading test cases are intended to test separable functionality of your translation. Towards the end of the project period, we may release the results of our own tests to demonstrate what the translator should produce.
There will be a reconciliation period after initial grading when you will be able to compare outputs of your translator with those of the reference implementation, and you may then offer simple fixes for the TAs to apply to your implementation to improve your grade. These fixes will be accepted only at the discretion of the TAs and the instructor. We will judge what "simple" means!
The reconciliation period is only intended for you to be able to fix simple problems that you may have mistakenly overlooked. Thus, you must make sure to test your implementation thoroughly.