Project 4: Synthesis: translation

Due 11:59pm Wednesday November 14th

Useful Links


Description

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.

Resources

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.

Getting Started

Source code to get started with is available via svn on any of the lab machines using the command:
  svn co file:///homes/cs352/svn/p4
or remotely using the command:
  svn co svn+ssh://sslab01.cs.purdue.edu/homes/cs352/svn/p4
You will now have a working copy of the project files in the directory p4. The p4 directory contains src and lib subdirectories. The src subdirectory contains source files for this project. The lib subdirectory contains any precompiled class files you will need to compile this project. (The files are actually configured as an Eclipse project, so you can also import the p4 directory as a new project in Eclipse at your convenience.)

As in previous projects, you must run the setup script to configure your environment.

All commands below will assume that you have first set your current directory to the p4/src subdirectory using the command:

  cd p4/src
to enter the src subdirectory.

All changes for this project will be done to the translation file mojo/Translate.java in the p4/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 the previous project, but I have provided you my implementation of that project as a binary class file.

You can compile the project using the commands:

  javac */*.java
in the p4/src subdirectory.

You can run the translation with the command:

  java mojo.Translate file.mj
where file.mj is a mojo source code file. This will print out the intermediate code tree for the input program.

Hints

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.


Turnin

You should turn in whatever files you have changed so we can compile and run your solution. This will certainly include mojo/Translate.java. Please also provide a README describing all the features of the language that you have implemented. (e.g., have you implemented VAR and READONLY parameters?).

For example:

	cd p4/src
	turnin -ccs352 README mojo/Translate.java

Grading

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 type checker.

There will be a reconciliation period after initial grading when you will be able to compare outputs of your parser 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.