due: Monday, October 26
As discussed in class, it is difficult to translate from high level source directly into assembly code. A solution to this problem is to complete simpler translations through intermediate representations. Often, compilers make use of multiple IRs, but your compiler should only use one. In this assignment, you will build an IR generator for Iota9 source. The output for this phase of the project will be canonical IR that closely resembles machine code.
We expect you to use the tree-based IR presented in class and in chapter 7 of Appel. You may add nodes to this IR or adjust the meaning or syntax of current nodes, but if you choose to do so, you should carefully describe and justify your changes. Note that we will be able to support you best if you use the IR presented in class.
You are required to output canonical (or lowered) IR. This means:
For this assignment, you are required to implement constant folding at the IR level. This optimization will improve the performance of your generated code by eagerly computing the values of static expressions whose values can be computed at compile time.
Your new functionality must be invokable through your driver. Your driver must behave as specified by the following command line interface:
java -jar YOUR_JAR [-O] [--dump_ast | --dump_ir] SOURCE_FILE
-O | Disable optimizations |
--dump_ast | Outputs a dump of the typed source AST (your output from PA3) |
--dump_ir | Outputs a dump of the canonical IR for each function or procedure in the source. |
As in PA2 and PA3, your driver should accept the file name of an Iota9 source file. If the file is invalid Iota (syntactic or semantic), you should report a helpful error message including the position of the invalid code and a description of the problem. If the program is valid, then the program should behave according to the flags passed in.
For example, java -jar acm22_ahj5_mo85.jar --dump_ir hello.i9
should output the optimized, canonical IR tree representing the program
hello.i9
.
You may add additional flags and options as long as you support these requirements.
Although your compiler will not be able to generate runnable code until after the next assignment, you will need to begin ensuring that your code will be compliant with the Iota9 application binary interface (ABI) for runtime support. You will need this runtime support for program bootstrapping, memory management and for I/O.
To help you with this, we are providing you with an ABI overview for your reference.
You should complete your implementation as you see fit, but we offer the following suggestions.
Before you start coding, you should specify the interfaces for your IR nodes. Incrementally define the translations you will apply to your source nodes to produce the IR nodes. As you write these translations, you should test them out using simple expressions. We encourage you to include these translations in your documentation.
It is important that your development and testing is incremental. A test for
the correctness of a translation e
need not (and should not) test for the
correctness of the translations of subexpressions of e
.
As before, you are building upon your work from PA3. The protocol is the same as in prior assignments: you are required to devise and incorporate tests that expose any issues with your implementation, then fix these issues.
As in previous assignments, please ensure that all your Java code lives in a package containing the NetId of at least one of your group members. Your code should compile without errors or warnings. Your code should not contain any superfluous print or debug statements.
Submit the following:
*.class
).Main-Class
to be your driver. This
will enable us to run your JAR file directly. See Sun's tutorial for
help with this.*.java
, *.flex
, *.cup
, etc.). Do not forget to
include your source. Failure to do so will result in a 0 for this
assignment..jar
, .zip
, or .tar.gz
) containing your testing code
and test cases.