15-411: Compiler Design

Table of Contents
  1. Labs & Assignments
    1. Lab Schedule
    2. Collaboration and Academic Integrity
    3. Due Dates
    4. Subversion
    5. Submission
    6. Grading
  2. Lab Machines
    1. Quick Start Login
    2. Getting Help
    3. Frequently Asked Questions
    4. Technical Specifications

Labs & Assignments

The labs are the heart of this course and count for 70% of your grade. Much of what you learn in this course will be through completing these labs. Labs can be done individually or in pairs. You must choose a partner by the due date of the tests for the first lab. If you have difficulty finding a partner, or if problems in your working relationship arise during the semester, please get in touch with the instructor as soon as possible.

The second component of your work consists of written assignments, accounting for 30% of your grade. Written assignments must be done individually. University standards for academic integrity will be applied rigorously (see the policy details below).

Lab Schedule

The Lab and Assignment Schedule is tentative!
Points Lab Due (at 11:59pm)
Lab 1    100 Register Allocation Tests Tue 09/07
Compiler Tue 09/14
Lab 2 100 Loops & Conditionals Tests Tue 09/21
Compiler Tue 09/28
Lab 3 100 Functions Tests Tue 10/05
Compiler Tue 10/12
Lab 4 100 Structs & Arrays Tests Thu 10/21
Compiler Thu 10/28
Lab 5 100 Memory Safety & Basic Optimizations Tests Tue 11/04
I Memory Safety Part and Compiler Tue 11/09
II Basic Optimizations Part Compiler Tue 11/16
Lab 6 200 Optimization
or Garbage Collection
or Virtual Machine
Compiler Tue 11/30
Term paper Tue 12/07
Points Assignment Due (in lecture)
Asst 1    60 Instruction Selection & Register Allocation LaTeX Tue 09/07
Asst 2 60 Parsing LaTeX Thu 09/23
Asst 3 60 Function Calls & SSA LaTeX Tue 10/05
Asst 4 60 Optimizations LaTeX Tue 10/19
Asst 5 60 Tuples and More Optimizations LaTeX Tue 11/02

Collaboration and Academic Integrity

The university policies and procedures on academic integrity will be applied rigorously.

All labs in this course must be done either by a single student or by a pair of students, at your discretion. The work must be your own and your partner's. Do not copy any parts of the lab from anyone. Do not look at other students' code. Do not make parts of your code available to anyone besides your partner, and make sure noone else can read your files.

General libraries, such as the SML Basis Library, the SML/NJ Library, or other publicly available libraries may be used in your code. This also includes the code supplied with the textbook. Please clearly identify if you used library code, credit its source, and summarize any changes you may have made to the library. Portions of other students' compilers, from this or previous semesters, are explicitly prohibited. If in doubt, please contact the instructor.

All assignments in this course are single-student assignments. The work must be all your own. Do not copy any parts of any of the assignments from anyone. Do not look at other students' papers. Do not make any parts of your assignments available to anyone, and make sure noone can read your files.

We will be using the Moss system to detect software plagiarism.

It is not considered cheating to clarify vague points in the labs, assignments, or textbook, or to give help or receive help in using the computer systems, compilers, debuggers, profilers, or other facilities.

Due Dates

All handins of labs are electronic via the Autolab system. All lab assignments are due at 11:59pm on the specified due date. These deadlines are firm and no extensions will be granted for lab due dates.

All handins of written assignments are on paper at the beginning of lecture (1:30pm) on the due date. Up to two assignments may be handed in late, any time before next lecture. The exception is Thanksgiving break, where you have to make separate arrangements for a late handin.

You may not submit a lab late. You will receive no credit for late labs.

Exceptions to the policies above will be granted only in exceptional circumstances and must be discussed with and approved by the course instructor in advance.


We are using a subversion repository administered by the course staff for distribution and autograding purposes.

Suppose your group name is USERID. To check out a working copy of the svn module for your group, do

svn checkout https://cvs.concert.cs.cmu.edu/15411-f10/USERID
Your userid would be USERID and your password should have been mailed to you.

This will create a directory USERID/ with a subdirectory for each lab. For the very first lab, there is also some starter code in USERID/lab1/compiler which you may edit freely or replace entirely.

When you are ready to hand in your code (and you may hand in as often as you like), make sure you have committed the most recent version to the repository with svn commit.

Then go to the Autolab server, select the lab you would like to hand in and select option

S5b - Autograde your code in svn repository
Depending on whether you are handing in test cases or a compiler, the autograder for Lab 1 will do either
svn checkout https://cvs.concert.cs.cmu.edu/15411-f10/USERID/lab1/tests
svn checkout https://cvs.concert.cs.cmu.edu/15411-f10/USERID/lab1/compiler
and then run the driver to autograde your code. For each lab, the autograder will look for the two handin directories tests and compiler.

You are encouraged to use the svn repository to manage your development, but you are not required to do so as long as you hand in your code as specified above.


We always count your latest submission, both for grading purposes and for the purpose of determining whether you have submitted in time. You should avoid the scenario where you make final clean-up edits close to the submission deadline without subsequently compiling and re-testing your code. You might end up with no credit if you accidentally fail to close a comment or miss a parenthesis!

Some labs may permit unofficial submissions in order to test your code with the Autolab grader. Unofficial submissions will not be graded. Please make sure to hand in at least one official submission, however, otherwise you will receive no credit. If you want to run an unofficial testrun on a fish machine without grading it, just call

driver.pl -f testfiles

On autolab, be sure to select

S6 - View your handin history and scores
to see the official autolab output and instructor evaluations of your submissions.


Grading criteria are stated separately with each lab. Some of each score will be determined by the Autolab grading script. In addition, the teaching assistants will read your code and award additional points based on code quality.

The most important criterion is always correctness. Buggy code is useless, and is likely to get a low score. A secondary criterion is the selection of appropriate algorithms and data structures for your implementation. Finally, it is important that your code be readable and well-organized. This includes proper use of the module system and clear comments.

Grading for written assignments is based on the correctness of the answer and the presentation of your reasoning. Strive for clarity and conciseness, but show how you arrived at the answer. Stating an answer without explanation does not count as an answer. If you cannot solve a problem, explaining your approach and why you failed is encouraged. Such answers will be given partial credit.

Grades are based primarily on the total score for the class out of 1000 points. This includes 700 points for lab and 300 points for assignments. There are no predetermined cut-offs. Instead, the teaching staff will decide on grade boundaries at the end of the year. We will use intangibles, such as participation in class for those close to grade boundaries.

Lab Machines

Intel engineers traditionally use the names of North American rivers as internal names for their processor projects. So it seems fitting that we, as denizens of the Intel cluster, name the machines after freshwater fish of North America.
flounder.ics.cs.cmu.edu      grouper.ics.cs.cmu.edu      kingfish.ics.cs.cmu.edu
mackerel.ics.cs.cmu.edu marlin.ics.cs.cmu.edu pompano.ics.cs.cmu.edu
sailfish.ics.cs.cmu.edu seabass.ics.cs.cmu.edu seatrout.ics.cs.cmu.edu
swordfish.ics.cs.cmu.edu tarpon.ics.cs.cmu.edu tuna.ics.cs.cmu.edu

Quick Start Login

Suppose your user name is bovik. Login to an Andrew Linux or Unix machine and go to your Andrew home directory. Then run the following
/afs/cs.cmu.edu/user/aplatzer/course/15411-f10/bin/checkin   # first time only
ssh -x -l bovik@ANDREW.CMU.EDU tuna.ics.cs.cmu.edu
then type your Andrew password to the prompt. The uppercase 'ANDREW.CMU.EDU' is significant! The string "-l" is dash el, not dash one. Your top level Andrew home directory needs to be at least world listable: "system:anyuser l".

Getting Help

Information about the CS computing environment can be obtained from the SCS Help Desk. If you are having trouble logging in, please send mail to the instructor or TAs.

Frequently Asked Questions

How do I get an account?
Accounts will be created for you automatically.
What do I need to do before logging in for the very first time?
From your Andrew home directory on an Andrew Unix machine (e.g., linux.andrew.cmu.edu or unix.andrew.cmu.edu), run the following one-time checkin script:
Your top level Andrew home directory needs to be at least world listable: "system:anyuser l".
What does the checkin script do?
The checkin script activates your account so that you can login to the fish machines using your Andrew password. It creates a hidden directory called ~/.15411 with login credentials for the fish machines. If you don't have one already, it also creates a protected directory ~/411hw where you can safely do your assignments without other students being able to see them. You only need to run the checkin script once, before your very first login to the fish machines. However, you can safely run the checkin script as often as you like.
How do I login to one of these machines once I have run the checkin script?
If your Andrew login is bovik and you want to login to the fish machine called tuna.ics.cs.cmu.edu, then type the following while logged in to an Andrew Unix machine:
ssh -x -l bovik@ANDREW.CMU.EDU  tuna.ics.cs.cmu.edu
[type your Andrew password to the prompt]
Note: The uppercase 'ANDREW.CMU.EDU' is significant.
Note: "-l" is "dash el".
Note: The "-x" option disables X11 forwarding, which interacts poorly with the new 64-bit FC3 boxes. It's not always necessary, but we suggest using it just to be sure.
I did everything you said but I still can't login. Now what?
Here are the most common reasons students can't login:
  • You're not logging in from an Andrew Linux or Unix machine.
    FIX: ssh to linux.andrew and login from there.
  • You're logging in as user or bovik@andrew.cmu.edu instead of bovik@ANDREW.CMU.EDU
    FIX: Run ssh using "-l bovik@ANDREW.CMU.EDU"
  • You forgot to type -l ("dash el") before your user name on the ssh command line.
    FIX: Run ssh using "-l bovik@ANDREW.CMU.EDU"
  • Your Andrew ~ (home) or ~/.15411 directories are not accessible.
    FIX: Make them accessible:
    fs sa -dir ~ -acl system:anyuser l
    fs sa -dir ~/.15411 -acl system:anyuser rl
  • You've somehow deleted the .login and .klogin files in your ~/.15411 directory.
    FIX: Rerun the checkin script.
  • You've changed your Andrew password after you ran the checkin script.
    FIX: Logout from the Andrew machine, log back in, and try again.
  • If you still can't login, please send mail to your instructor or TAs.

Technical Specifications

Each node on the cluster runs a 64-bit version of Fedora Core 3 (Linux kernel 2.6.16) and consists of the following hardware: