Welcome to ECE 468 Course Project

last update:


Step 0 : Submission test and group selection Due on Mon, Aug 27

Step 1 : Scanner Due on Wed, Sept 5

Step 2 : Parser Due on Fri, Sept 14

Step 3 : Symbol Tables Due on Tue, Oct 2

Step 4 : Expressions Due on Fri, Oct 12

Step 5 : Control Structures Due on Fri, Oct 26

Step 6 : Functions Due on Fri, Nov 16

Step 7 : Register Allocation Due on Fri, Dec 7

Step 8 : Final Submission Due on Wed, Dec 12


You may NOT have any folders or files that start with “test” or “grade”. These will be deleted by our grading script and you may not get feed back or your code may not run.

If you are using ANTLR with java, you may assume that we will export the path for the antlr-4.7-complete.jar as the CLASSPATH variable. So you will compile with something such as:

> java -cp ${CLASSPATH} org.antlr.v4.Tool -o outputfolder Micro.g4
>javac -cp ${CLASSPATH} ...

UPDATE: Reference implementation web portal

We have developed a reference implementation for the compiler project. For the convenience of testing the expected output of the compiler project under different inputs, we have provided here a web portal to our reference implementation.


40% of your course grade in this class comes from your course project: you will be building an end-to-end compiler that takes programs written in a simple language, translates them to assembly code that can run on a simulator, and performs some basic optimizations.

Unlike in a lot of your previous classes, every assignment in this course builds on previous assignments. When you’re done, you will have written a single program with thousands of lines of code. To make it easier to manage such a large project (and to keep you from waiting until the last week of class to try and write an entire compiler), we have broken up the project into a series of distinct steps, each of which will explore one aspect of what a compiler does.

You can (and are encouraged to) work on the project for this class with a partner. If you choose to work with a partner, you must let us know by Friday, August 24th. If you are working with a partner this will be your partner for the rest of the semester. We will not let you change partners. You and your partner will get the same grade on the project, even if one partner does more work than the other.

Because each step will depend on previous steps, you will essentially be writing a single program over the course of the semester. To facilitate this type of development strategy (which isn’t all that different than what you’ll encounter in the real world), we will be using version control to manage your source code. We will also use it to handle submissions.

We will be using Github Classroom, which we have setup for the instructors to have ownership of the repositories you will create in Step 0, and you will have administrative rights to the repository. At the end of the course, the repositories will be archived and you will lose access to them. We keep all previous years submissions to have a plagiarism script test against all previous submissions. Cheating is not tolerated!

Short ‘git’ Tutorial

Version control helps you to roll back changes, helps with backups if your computer crashes, and is an indication you probably did not plagiarize. ‘git’ is different than ‘Github’, though you will be using both for this class. Github will be your remote server to push too, which you setup in Step 0. Here are a few basic concepts (Look at Step 0 for creating your repository):

  • Clone the repository to develop your assignment

Cloning a repository creates a local copy. Change your directory to whichever directory you want to create your local copy in, and type:

> git clone [your repository URL] project

This will create a subdirectory called project, where you will work on your code.

  • As you develop your code, you can commit a local version of your changes (just to make sure that you can back up if you break something) by typing:

  > git add <file name that you want to commit>
  > git commit -m "<describe your changes>"

git add <filename> tells git to “stage” a file for committing. Staging files is useful if you want to make changes to several files at once and treat them as one logical change to your code. You need to call git add every time you want to commit a file that you have changed.

git commit tells git to commit a new version of your code including all the changes you staged with git add. Note that until you execute git commit, none of your changes will have a version associated with them. You can commit the changes many times. It is a good habit committing often. It is very reasonable if you commit every ten minutes (or more often).

Do not type git add * because you will likely add unnecessary files to the repository. When your repository has many unnecessary files, committing becomes slower. During submission only relevant code will be submitted, otherwise you may lose points. You may wish to google .gitignore and create one for your repository.

  • To copy your changes back to Github (to make sure they are saved if your computer crashes, or if you want to continue developing your code from another machine), type

> git push

If you do not push, the teaching staff cannot see your solutions.

  • You will use git’s “tagging” functionality to submit assignments. Rather than using any submission system, you will use git to tag which version of the code you want to grade. To tag the latest version of the code, type:

> git tag -a <tagname> -m "<describe the tag>"

This will attach a tag with name to your latest commit. To then submit the tag, you will type:

> git push --tags

  • To resubmit, or re-tag a submission, you will need to add the -f flag as shown when tagging:

> git tag -a -f <tagname> -m "<describe the tag>"
> git push -f --tags

Please be careful about the following rules:

  • For each assignment, we will grade only the last commit tagged for each step. It is your responsibility to tag the correct one.

  • After tagging a version “submission”, any modifications you make to your program will not be graded (unless you update the tag, as described).

  • The grading program starts retrieving soon after the submission deadline of each assignment. If your repository has no version tagged submission, it is considered that you are late.

  • The time of submission is the time when you push the code to the repository, not the time when the grading program retrieves your code. If you push the code after the deadline, we will consider it late.

  • You are encouraged to tag partially working programs for submission early. This can give you an opportunity to get partial credit (although there is no partial credit available for step 0) Please remember to tag improved version as you make progress.