CISC 471 Compiler Design / 672 Compiler Construction
Syllabus
Course Overview
Course Learning Objectives
This course examines the fundamental theory and practice of
implementing
today's programming languages.
Students should emerge with a good appreciation for the implementation
issues and strategies behind making programs in high level programming
languages work correctly
and efficiently on a target machine.
A major part of the course is
the practical experience of implementing various phases of a compiler for
a small object-oriented programming language.
Students learn translation
methodology that is useful in many other situations in addition to compilation, including
command interpreters, report-generating systems, programmable applications,
configuration file handling, preprocessors, debuggers, static program analysis tools, testing tools,
virtual machines, integrated development environments, and many other software engineering
tools.
You should consider taking CISC 471 / 672 if you are curious about:
- the inner workings of a basic compiler
- the implementation of object-oriented programming language features
- building a large software system starting with a base library of useful
utilities
- the answers to many of your questions about how programming languages
work
- the issues in gaining good performance from a high level language program
on a particular target architecture
AND you have the proper prerequisites. Note: There is no assumption of previous
coursework in compilers.
Prerequisite: CISC 320: Algorithms and Advanced Programming or permission of instructor.
Course Requirements
-
Keith Cooper and Linda Torczon, Engineering a Compiler, Second Edition
Morgan Kaufmann, 2011
Suggested References:
- John Levine, lex & yacc, O'Reilly and Associates, Inc., 1992.
- David Grune, Henri E. Bal, Ceriel J. H. Jacobs, Koen G. Langendoen,
Modern Compiler Design, John Wiley and Sons, 2000, ISBN: 0471976970.
- Any MIPS or SPARC Reference.
Distinction between CISC471 and CISC672
The lectures for CISC471 and CISC672 will be the same. The projects and
exams will be more challenging for CISC672 students versus the projects and
exams done by CISC471 students.
Project Materials:
The course web site has links to all needed project
handouts (gmake, flex, bison, spim, ...).
The project files will be made available through an SVN repository available on
the EECIS machines as the course progresses. More here soon.
Programming Environment and Computer Usage:
The project will be written in Java.
The project is typically done in teams of 3 (unless otherwise noted), but you
are welcome to tackle it individually if desired.
If you are not yet verse in this language, it is suggested that you
read through an appropriate Java book and
familiarize yourself with the language by writing some small programs.
The last project will involve learning some of the MIPS assembly language.
The testing of the last phase must be done on the SPIM simulator.
You will use
JLex and
CUP.
Your grade will be based on your performance in the various activities in
the course. Some of the activities will be done in groups, and some will
be done individually. There will be two in-class examinations. The midterm
will concentrate on the first half of the course, while the final concentrates
on the second half of the course. The relative weights of the components of
the grade will be approximately:
- (4%) Class participation and in-class activities, or (approved) department speaker seminars. All of these efforts count toward the class participation grade.
- (4%) Cool Test Program(s) (Individual)
- (5%) Scanner (individual)
- (8%) Parser
- (14%) Semantic Analyzer
- (15%) Code Generator
- (20%) Midterm - first half of course
- (30%) Final Examination - second half of course
- Read the textbook. At least read
the chapter as each new topic is covered in class. Use the textbook as
a reference during projects and for vocabulary and filling in the
details of concepts covered in class and projects.
The readings in this course are critical to your active participation in
class meetings. Part of your grade is based on class participation.
Besides, you should not expect to gain all understanding of the concepts from
passively listening in the class periods alone.
- Speak up in class.
This course is not meant to be a passive learning course,
as it has been shown that
the best learning occurs when the learner is an active participant,
not a passive listener.
Besides, classes are much more enjoyable when the audience actively
participates!
- Take an active role in your group projects. Ask your group members
to explain concepts you do not clearly understand, and share ideas among
the group members.
Meet regularly with your group.
- Form an informal study group outside of class.
Compare your notes from class, work together on group projects, and discuss
concepts you find unclear.
- Seek help if you start to feel lost, ASAP. Take advantage
of instructor and TA office hours. Ask questions via email.
The due dates are to be taken seriously and you should not expect
them to be extended. The pace of work is implicit in the due
dates and necessary if you expect to finish by the end of the semester.
Homeworks to be graded should be turned in at the start of class on the specified due date.
Programming assignments should be dated before 11:59 PM on the due date.
NO late programs or homeworks will be accepted FOR FULL CREDIT without
discussion with me prior to the due date. If you can not reach me, leave
a message on my voicemail. All other assignments not delivered
by the due date are considered late.
My philosophy on late assignments is:
(1) Everyone should try their best to complete all assignments by the
specified due date. (2) People who work conscientiously to make the deadlines should
be rewarded for their promptness and sacrifice of sleep. Thus, allowing others to hand
in late assignments without some penalty is not fair to these people. However, there
are various circumstances that may prevent you from completing an assignment by
the due date. Allowing no late assignments would not give you much incentive to
continue to work on the assignment, which is a major source of learning in this course.
Thus, I believe late assignments are better than no assignment.
Late assignments will be penalized 5% off the total possible points if
turned in within the first 24-hour period after the specified due date and
time, and 5% per 24-hour period (or fraction of a day) (including weekends)
after that time, up to a week after the due date.
Late assignments will be accepted with penalty up to one week after
the due date. Assignments submitted at any later time without
an approved excuse will not be accepted.
It is up to you to determine the version of your assignment
to be graded. You must weigh the
late penalty against the completeness of your assignment.
Regrading Policy:
If you are dissatisfied with a grade on a homework, programming assignment,
or exam,
you should consult the instructor directly within a week of the day the
graded assignment was returned to you. No regrade requests will be considered
after this week period.
Posting Grades:
With your permission, grades will be posted electronically via a link
on the course web site. You will need to give me a secret code name for
this posting in order to keep your grade posting
anonymous. If no name is given, I will assume you do not want your
grades to appear.
Questions about accuracy of recorded grades should be
addressed to me.
You will be told specifically which assignments are to be done collaboratively
in groups, and which ones should be done individually without collaboration.
For individual assignments, you should be directing your questions to
the instructor, not to other students, unless the question is a clarification
question.
Any evidence of collaboration other than this kind
will be handled as stated in the Official Student Handbook of the University of Delaware.
You should not be using or examining any program code used for projects for
this course in any prior instantiations of this course.
If you are in doubt regarding the requirements,
please consult with me before you complete any requirement of this course.
Collaboration Policy:
General philosophy
This course requires a significant amount of programming. You are allowed to
choose a programming partner for some or all of the programming assignments.
This document should make it very clear what is and what isn't considered acceptable
collaboration, so there is no ambiguity.
The general premise of this policy is that your submissions must be your own
independent and original work. You should not give or receive any aid which
makes the assigned tasks significantly easier. Discussion and
help is allowed among students, but it is expected that
you document any significant help that you
receive. On my part, I will treat you with trust and will protect the honorable
student's interests by investigating and prosecuting dishonorable behavior.
Collaboration on coding projects
"Your code is like your boyfriend or girlfriend. It's okay to
talk about it on an abstract, high level. But you don't want to go into the
specific details, and you certainly don't want to share."
- Pascal Van Hentenryck, Professor of CS, Brown University, 1997
For the purposes of the collaboration policy, students
choosing to work with a partner are effectively considered as one entity, and
are freely allowed to exchange, help, design, and code with one other, but the
guidelines below apply outside the partnership (neither of you should be
debugging, sharing code, etc. with other people or teams). There are also some
specific rules that apply within the partnership.
Things that are always allowed
These things are encouraged and allowed
at all times for all students.
- Discussing material covered in lecture or handouts.
- Discussing the requirements of an assignment.
- Discussing features of any programming language (including the one for
which we are writing a compiler).
- Discussing how to use the tools or development environments.
- Discussing general techniques of coding or debugging.
- Any discussion between the student and a TA, or me. You are welcome to
discuss any and all ideas, design, code, debugging, and details with the
course staff (TA and instructor). They are the best folks
to talk to because they are
knowledgeable about all the material and know how to help you without giving
away the farm. They also have the authority to give you definitive answers to
your questions.
Collaboration that is allowed if documented
Two students engaging in a more detailed discussion of the project specifics
can cross into the area of collaboration that is acceptable only if documented.
I require that you include the name of those whom you received specific
assistance from and properly credit their contribution, as you would cite a
reference in a research paper. Some examples:
- Discussing the design of the project. Design is a crucial part of the
programming process, and discussion can be valuable, but you should take care
to document any design input you got from others.
- Getting help from another student in order to debug your code. You
should credit their assistance.
- Sharing advice about testing. For example, if the team next to you tells
you about some lesson learned ("our program didn't handle the case where the
input file didn't end with a newline") that you then use to improve your
program's robustness, you should credit them for providing you with that
insight.
Collaboration that is NOT allowed
Basically, the rule is that you should
be handing in code which represents your original, independent work. It should
not be based on, influenced by, or copied from anyone else's.
- Copying code. This is the most blatant violation. You should not be
copying anyone else's work. You should also not allow anyone else to copy
yours. You should keep your work secure (restrict access on the filesystem,
don't leave printouts lying around, etc.)
- Using work from past semesters. Using someone's work or solutions
from a previous semester is an obvious violation.
- Looking for this project on the Internet and copying the code.
- Studying someone else's code. You should not be reading anyone
else's code whether it is on the screen or written out by hand.
- Debugging someone else's code. Debugging along with someone makes
it too easy to look over their code and allow (sometimes unintended)
code-copying. Describing to someone a problem and asking for advice on how to
track it down is okay, but you should do the actual debugging yourself.
You can freely exchange ideas and assistance
within the partnership, but outside it, the same rules apply (your or your
partner should not be sharing code with others, etc.). A few special rules
regarding partnerships:
There will be some written homework
assignments. The expectations about academic integrity are similar for
these assignments to those for the programming assignments, but there are
some differences in the ground rules:
Above all you should use your common sense. If you suspect
that what you are about to do is a violation, play it safe and ask a staff
member first rather than take risks with your academic career.
Cheating is taken very seriously in this course.
Please do your part in maintaining a community where academic work is
done with a high standard of integrity!
Some parts of this document are based on a similar
collaboration policy for CS courses at Brown, Drexel, and Stanford.