Step 8

last update:

This step does not introduce any new requirements to your project. We will simply be testing your project on all test cases published so far that do not have syntax/type errors (or any other errors), as well as some hidden test cases.

You should use this opportunity to write additional test cases for your compiler to ensure that it is robust and can handle a wide variety of situations (e.g., functions with many arguments; functions with many local variables; mutually recursive functions; function calls that have complex expressions as arguments, including functions that have other functions as arguments).

Testing your Tiny code

You can test your Tiny code by running it on our updated Tiny simulator that limits you to four registers. This simulator can be built by running:

> g++ -o tiny4 tiny4regs.cpp

You can then run a program with tiny commands using:

> ./tiny4 <code file>

What you need to do

Submit your final version of the compiler. This version does not add any new requirements.

Handling errors

All the inputs we will give you in this step will be valid programs. We will also ensure that all expressions are type safe: a given expression will operate on either INTs or FLOATs, but not a mix, and all assignment statements will assign INT results to variables that are declared as INTs (and respectively for FLOATs).

Sample inputs and outputs

Notice we do not give you the reference or output for this step.


There are no late submissions for this project. Because the project is due finals week, there is a hard cuttoff.

Extra credit

For full credit on this assignment, your generated code merely needs to work properly. However, we will also evaluate how fast your Tiny code runs (the “Total Cycles” reported by the Tiny simulator).

The groups whose generated Tiny code runs fastest (averaging across all the inputs) will receive bonus points for this step: 15% for the fastest code, 10% for second, and 5% for third.

What you need to submit

  • All of the necessary code for your compiler that you wrote yourself. You do not need to include the ANTLR jar files if you are using ANTLR.

  • A Makefile with the following targets:

    1. compiler: this target will build your compiler
    2. clean: this target will remove any intermediate files that were created to build the compiler
    3. team: this target will print the same team information that you printed in step 0.
  • A shell script (this must be written in bash, which is located at /bin/bash on the ecegrid machines) called runme that runs your compiler. This script should take in two arguments: first, the input file to the compiler and second, the filename where you want to put the compiler’s output. You can assume that we will have run make compiler before running this script.

While you may create as many other directories as you would like to organize your code or any intermediate products of the compilation process, both your Makefile and your runme script should be in the root directory of your repository.

Do not submit any binaries. Your git repo should only contain source files; no products of compilation or test cases. If you have a folder named test in your repo, it will be deleted as part of running our test script (though the deletion won’t get pushed) – make sure no code necessary for building/running your compiler is in such a directory.

You should tag your step 8 submission as step8-submission