Syllabus and general information for MCS-388: Compiler Design (Spring 2003)
Overview
MCS-388 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, and optimization, including suppression of
partial redundancies.
Office hours
I will be available in my office (OHS 303) 10:30-11:20 Mondays,
Wednesdays, Thursdays, and Fridays, as well as by
appointment. Or try your luck: just stop by and see whether my door
is open.
You may send me electronic mail at max@gustavus.edu or call me at
extension 7466. I'll try to put any updates to my office
hours on my web page, so check
there if in doubt.
World Wide Web
All course materials will be available through my World Wide Web page.
The URL for this course is http://www.gustavus.edu/~max/courses/S2003/MCS-388/.
After this syllabus I will give hardcopy handouts only to those
students who want them.
Prerequisites
MCS-388 draws heavily on MCS-265, MCS-287, and MCS-284. Some notions from MCS-375
and MCS-236 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 languages,
so if you would rather use another language, that's
fine too, you'll just have a little less of a support network.
I'll gladly accept labs written in any programming language:
C++, Scheme, Python, ML, Ada, you name it.
Text and readings
Our primary text will be the "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://java.sun.com/docs/books/tutorial/,
and copies of a couple Java books in
the MCS Lab monitors' room, any of which you are welcome to use as
a supplement.)
Labs
Some days, shown in the syllabus, we will meet in the OHS 326 computer
lab rather than in the usual classroom. Each lab has two to five lab
days set aside for us to work together, but will also require you to
spend additional time out of class.
Attendance is mandatory for all lab sessions, unless you have already
turned in your lab report. I will excuse up to two absences per
student, for any reason. Use yours wisely. If you exceed this
allowance, I may reduce your course grade by one letter grade.
Honor
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
dishonorable.
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
action.
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.
Late assignments
All lab assignments are due at the beginning of class on
the day indicated. Late lab 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 or solutions are distributed.
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 see the separate homework
policy, linked to the web version of this syllabus.
Grade changes
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.
Grading
I will provide you with a 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. The homeworks
will contribute 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.
You are responsible for all course material, whether or not you are
present when it was covered or distributed.
Please see the separate homework
policy, linked to the web version of this syllabus.
Style guidelines
All assignments should be readily readable, and should
not presuppose that I already know what you are trying to say. Use
full English sentences where appropriate (namely almost everywhere)
and clear diagrams, programs, etc. 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.
Accessibility
Please contact me immediately if you have a learning or physical
disability requiring accommodation.
Syllabus
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
syllabi.
| Date | Reading | Topic | Due
|
|---|
| 2/10 | 1.0-2.2 | Introduction, syntax definition |
|
| 2/12 | 2.3-2.4 | Syntax-directed translation |
|
| 2/13 | 2.5-2.6 | Your first compiler |
|
| 2/14 | | No class: campus conversation |
|
|
| 2/17 | | Lab 1: A First Compiler |
|
| 2/19 | 3.0-3.1, 3.3, 3.5 | Lexical analysis | HW 1
|
| 2/20 | | Lexical-analyzer generators |
|
| 2/21 | 4.0-4.2 | Context-free grammars |
|
|
| 2/24 | | Lab 1 (continued) |
|
| 2/26 | | No class: trip to Federated Insurance |
|
| 2/27 | 4.3 | Writing a grammar | HW 1, draft 2
|
| 2/28 | 4.4-p.188 | Top-down parsing | Lab 1
|
|
| 3/3 | 4.4 | More on predictive parsing |
|
| 3/5 | 4.5, 4.7-p.220 | Bottom-up parsing | HW 2
|
| 3/6 | | Lab 2: Adding Variables |
|
| 3/7 | 4.7-p.230 | SLR parser generation |
|
|
| 3/10 | 4.7-p.240 | Canonical LR and LALR parser generation |
|
| 3/12 | 4.8-p.251, 4.9 | Using ambiguous grammars; parser generators | HW 3
|
| 3/13 | | Lab 2 (continued) |
|
| 3/14 | 5.0-5.3 | Syntax-directed definitions | HW 2, draft 2
|
|
| 3/17 | | Abstract Syntax Trees (Lab 3 preview) |
|
| 3/19 | | Lab 3: Generating Better Code from ASTs | Lab 2
|
| 3/20 | 8.0-8.1 | Intermediate code | HW 3, draft 2
|
| 3/21 | | Lab 3 (continued) |
|
|
| 3/24 | | Lab 3 (continued) |
|
| 3/26 | | Lab 3 (continued) |
|
| 3/27 | 8.2-8.3, p.481 | Declarations and simple assignments |
|
| 3/28 | 8.3 | Array access; type conversions |
|
|
| 4/7 | 8.4 | Control flow |
|
| 4/9 | 7.0-7.2 | Run-time environments |
|
| 4/10 | 7.3 | Storage-allocation strategies |
|
| 4/11 | | Lab 4: Control Flow and Scoping | Lab 3
|
|
| 4/14 | | Modern run-time environment issues |
|
| 4/16 | 9.0-9.3 | Code generation | HW 4
|
| 4/17 | | Lab 4 (continued) |
|
|
| 4/23 | 9.4 | Basic blocks and flow graphs | Lab 4
|
| 4/24 | | Lab 5: Procedures |
|
| 4/25 | 10.0-10.2 | Optimization |
|
|
| 4/28 | 10.4 | Loops in flow graphs |
|
| 4/30 | | Lab 5 (continued; Mayday: 12:10-12:40) |
|
| 5/1 | 10.5 | Data-flow analysis |
|
| 5/2 | 10.6 | Iterative data-flow analysis | HW 5
|
|
| 5/5 | | Lab 5 (continued) |
|
| 5/7 | | Liveness analysis |
|
| 5/8 | | Lab 5 (continued) |
|
| 5/9 | notes | Interference graphs |
|
|
| 5/12 | | Lab 5 (continued) | HW 5, draft 2
|
| 5/14 | | Lab 5 (continued) |
|
| 5/15 | | Lab 6: Wildcard Lab | Lab 5
|
| 5/16 | | More on register allocation |
|
|
| 5/19 | | Lab 6 (continued) | HW 6
|
| 5/21 | | Synthesis; evaluation | Lab 6
|
Course web site: http://www.gac.edu/~max/courses/S2003/MCS-388/
Instructor: Max Hailperin <max@gac.edu>