Syllabus and general information for MC97: Compiler Design (Spring 1997)
MC97 attempts to draw together the theory and practice of compiler
construction. Much of the material will have a strong theoretical
foundation. However, with the exception of the last couple topics
(due to time constraints), this material will serve as the basis for
compiler-writing projects. Topics include lexical and syntactic
analysis, naive code generation, data-flow analysis, register
allocation and assignment, suppression of partial redundancies, and
I will be available in my office (OHS 303) on Mondays from 1:30 to
2:20, on Tuesdays and Thursdays from 10:30 to 11:20, on Wednesdays
from 9:00 to 9:50, and by appointment. You may send me electronic mail at
email@example.com or call me at extension
7466. I'll try to put any temporary updates to my office hours on my
web page and any long-term updates on my
on-line schedule, so check
there if in doubt.
World Wide Web
All course handouts will be available through my World Wide Web page,
and some supplementary materials such as code to use as a starting
point in assignments may be available there as well. The URL for this
course is http://www.gac.edu/~max/courses/S97/MC97/.
MC97 draws heavily on MC55, MC87, and MC48. Some notions from MC57
and MC36 also crop up. You're expected to be able to program. Since
the compiler-building tools and pre-existing code modules I supply
will be centered around the Java programming language, the path of
least resistance will probably be to learn that language as we go if
you don't already know it. On the other hand, there are comparable
compiler-building tools centered around other langauges (including in
particular C/C++), so if you would rather use another language, that's
fine too, you'll just have a little less of a support network. In
fact, I'll glady accept labs written in any programming language:
Scheme, ML, Ada, you name it.
Text and readings
Our primary text will be the ``red dragon book,'' i.e.,
Compilers: Principles Techniques and Tools by Alfred
V. Aho, Ravi Sethi, and Jeffrey D. Ullman, Addison Wesley, 1986. We
will also use some additional material: documentation, some of which
will be on-line or in the lab area and some of which I'll hand out,
and supplementary readings, which I will hand out. (There's also an
on-line Java Tutorial at http://www.javasoft.com/books/Series/Tutorial/,
and copies of Arnold and Gosling's The Java Programming
Language book and Cornell and Horstmann's Core Java book in
the MCS Lab monitors' room, any of which you are welcome to use as
Students are encouraged to discuss the course, including issues raised
by the assignments. However, the solutions to assignments
should be individual original work unless otherwise specified. If an
assignment makes you realize you don't understand the material, ask a
fellow student a question designed to improve your understanding,
not one designed to get the assignment done. To do otherwise is to
cheat yourself out of understanding, as well as to be intolerably
Any substantive contribution to your solution by another person or
taken from a publication should be properly acknowledged in writing.
Failure to do so is plagiarism and will necessitate disciplinary
The same standards regarding plagiarism apply to team projects as to
the work of individuals, except that the author is now the entire team
rather than an individual. Anything taken from a source outside the
team should be be properly cited.
One additional issue that arises from the team authorship of
project reports is that all team members must stand behind all reports
bearing their names. All team members have quality assurance
responsibility for the entire project. If there is irreconcilable
disagreement within the team it is necessary to indicate as much in
the reports; this can be in the form of a ``minority opinion'' or
``dissenting opinion'' section where appropriate.
All homework and lab assignments are due at the beginning of class on
the day indicated. Late assignments will be penalized by one ``grade
notch'' (such as A to A- or A- to B+) for each weekday late or fraction
thereof. However, no late assignments will be accepted after graded
assignments are handed back.
If you are too sick to complete an assignment on time, you
will not be penalized. Simply write ``late due to illness'' at the
top of the assignment, sign your name and hand it in. Other circumstances
will be evaluated on a case-by-case basis.
Please point out any arithmetic or clerical error I make in grading,
and I will gladly fix it. You may also request reconsideration if I
have been especially unjust.
I will provide you with a letter grade on each homework assignment and
lab assignment, in addition to the mid-term and final grades, so that
you may keep track of your performance. As a guideline, the homeworks
will contribute approximately half of your final grade, with the labs
contributing the other half. However, I reserve the right to
subjectively adjust your final grade. Please see me if you have any
question how you stand. Class participation is not graded; however,
it allows you to find and repair the gaps in your understanding before
doing the assignments, and thus can dramatically improve your grade.
All homework and lab reports should be readily readable, and should
not presuppose that I already know what you are trying to say. In
Programs should be easily read as well. Some points to remember are
Use full English sentences where appropriate (namely almost
everywhere, including in mathematical proofs or derivations).
Word-process or type your homework if you can. In any case, make sure
it is legible.
Use diagrams, tables, programs, and calculations as supporting
components of English writing, not in isolation. Remember that your
goal is to communicate clearly, and that the appearance of these
technical items plays a role in this communication process.
Be sure your assignments are always stapled together and that your
name is always on them.
Begin each program file with a comment block explaining the purpose of
the program and identifying the author and date.
In general, each procedure should be preceded by a brief comment
specifying what the procedure does (not how it does it).
This may include assumptions it makes about its inputs and guarantees
it makes about its results. Occasionally the name of the procedure
and of its arguments will adequately substitute for this. Classes may
need to be similarly commented with information about purpose and
Use comments within procedures sparingly, making sure that they
explain the code rather than echoing it. Comments should explain why
the procedure does what it does, or why it works, or what a low-level
operation means in higher-level terms.
You may use any computer facilities you want. However, my
expectation is that the SGI workstations and Linux PCs in OHS 326 and
OHS 329 will be the normal choice. The assignments will presume you
have access to a number of software tools that are already installed
on the MCS SGIs and Linux PCs. We'll be using the MIPS processor that
the SGIs are based on as the target processor for your compliers.
However, normally you'll be using a MIPS simulation program called
SPIM rather than the real MIPS processor, and SPIM is available on the
PCs and in fact on the NeXTs as well. (On the SGIs and PCs, the
graphical user interface version of SPIM is called xspim while on the
NeXTs it is NeXTspim.)
Please contact me immediately if you have special physical
circumstances, e.g. impaired vision, which may affect the
accessibility of any course components. I will do my best to
facilitate necessary arrangements or resources.
In the reading column, section 0 means the material at the beginning
of a chapter before the first section.
When a reading is indicated as going to a particular page number, it
means up to the heading on that page. The same section number on the
next class day then indicates to finish the section.
This is my best guess as to the rate at which we will cover material.
However, don't be shocked if I have to pass out one or more revised
|2/10||1.0-2.2||Introduction, MIPS ISA, syntax definition||
|2/14||2.5-2.6||Your first compiler||
|2/17||3.0-3.1, 3.3, 3.5||Lexical analysis||HW 1
|2/24||4.3||Writing a grammar||Lab 1
|3/3||4.4||More on predictive parsing||HW 2
|3/5||4.5, 4.7-p.220||Bottom-up parsing||
|3/7||4.7-p.230||SLR parser generation||
|3/10||4.7-p.240||Canonical LR and LALR parser generation||Lab 2
|3/12||4.8-p.251, 4.9||Using ambiguous grammars; parser generators||
|3/17||5.4-5.6||L-attributed definitions; bottom-up attribute evaluation||HW 3
|3/21||8.2-8.3, p.481||Declarations and simple assignments (10:30-11:05)||
|3/24||8.3||Array access; type conversions||
|3/27||(no class, just a due date)||Lab 3
|4/14||Modern run-time environment issues||
|4/18||9.4||Basic blocks and flow graphs||
|4/23||10.4||Loops in flow graphs||
|4/28||Liveness analysis||HW 4
|5/2||More on register allocation||
|5/5||Yet more on register allocation||
|5/7||10.6||Iterative data-flow analysis||Lab 5
|5/9||More data-flow analysis||HW 5
|5/12||notes||Suppression of partial redundancy||
|5/14||10.11||Data-flow analysis frameworks||
|5/16||notes||Instruction scheduling||HW 6
|5/19||More on instruction scheduling||
|5/21||Synthesis; evaluation||Lab 6
Course web site: http://www.gac.edu/~max/courses/S97/MC97/
Instructor: Max Hailperin <firstname.lastname@example.org>