Please be sure to use the exact email address specified above. For example,
mail sent to firstname.lastname@example.org will
be read, but mail sent to
|Times and Locations|
Monday/Wednesday/Friday, 1:30 p.m. - 2:50 p.m. in 4615A Wean Hall
There are none officially scheduled, but from time to time we may have one.
Your participation in the course will involve the following forms of activity: attending and participating in lectures and recitations, reading any assigned texts, doing the homework assignments, and project, and taking the exam. You should also periodically read the course bulletin board.
A major focus of this course is the project. We prefer that you work in groups of two on the project, although groups of up to three may be permitted depending on the scale of project (ask the instructor for permission before forming a group of three). The project is intended to be a scaled-down version of a real research project. The project must involve an experimental component–i.e. it is not simply a paper and pencil exercise. We encourage you to come up with your own topic for your project, although we will be posting suggested projects to the class web page at a future date. You will have six weeks to work on the project. You will present your findings in a written report (the collected reports may be published as a technical report at the end of the semester), and also during a poster session during the last day of class. Start thinking about potential project ideas soon!
There will be one exam covering the first half of the course material. The exam will be closed book, closed notes.
In general, we would like everyone to do their part to make this an enjoyable interactive experience (one-way communication is no fun). Students are also required to give a 20-30 minute talk on a research paper (See Course Schedule).
TextbookThere is no required textbook for the course. Instead we have put several books on reserve in the library:
Compilers: Principles, Techniques, and Tools (2nd Edition) by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman
This is an update to the classic "dragon" book. It's definitely a book worth having on your reference shelf.
Optimizing Compilers for Modern Architectures: A Dependence-based Approach by Randy Allen and Ken Kennedy
Advanced Compiler Design and Implementation by Steven Muchnick
Engineering a Compiler by Keith Cooper and Linda Torczon
To pass this course, you are expected to demonstrate competence in the major topics covered in the course. Your overall grade is determined as follows:
Although your grade does not depend directly on attendance, you will be responsible for the material covered both in the main lecture and in any recitations.
Grades for the course will be determined by a curve. First, we will compute a weighted total of each student's scores on assignments and exams. These will be plotted as a histogram, and then approximate cutoff points for the different letter grades will be determined. Individual cases, especially those near the cutoff points may then be adjusted upward or downward based on factors such as extra credit and participation in class discussions. Very roughly, we expect to give about 25-30% A's, 35-45% B's, 20-25% C's, and about 5% ``other.'' This is not a requirement; we could give all A's if performance warrants it.
This course is not intended to be your first compilers course; it is geared toward students who have already had such a course as undergraduates. For example, we expect that people are already at least somewhat familiar with basic blocks, control flow graphs, dominators, liveness analysis, and activation frames. Furthermore, some familiarity with the features of modern processor architectures. For example, the memory hierarchy, pipelining, branch prediction, and instruction issue mechanisms. If you have not had such a course already, then it is still possible to take this course provided that you are willing to spend some additional time catching up on your own. If you feel uncertain about whether you have adequate preparation, please discuss this with the instructor. If you are not a graduate student in the Computer Science PhD program, you need permission to take this class. If you have not already done so, send a message to the instructor stating your status, why you want to take the class, and if you want to take the class for credit or as an auditor.
Certain forms of collaboration are beneficial for helping all involved better understand the material and overcome small stumbling blocks. Blatant copying of homework is not. In this course, discussing the assignments to better understand them, helping each other locate bugs, and so forth are acceptable, but what you hand in should be your own work. On each problem and program that you hand-in, you must include the names of the people with whom you have had discussion concerning your solution. Indicate whether you gave help, received help, or worked something out together. If you are unsure whether an action you are contemplating would be considered cheating, then contact a member of the course staff first. The following are what we consider clear examples of cheating:
As a general rule, If you do not understand what you are handing in, you are probably cheating. Examples of collaboration:
To be fair to all students we must enforce a strict policy with respect to cheating. Programs that are identical or exhibit suspicious similarities will be automatically flagged, and students will be asked to explain how such similarities came about and how their programs work. The penalty for cheating will depend on the severity of the offense and the student's past record in this regard. In general, the student will be given a -100% for the assignment. Multiple or severe infractions will result in failure and a letter to the dean of student affairs. Historically, most students caught cheating during a one of our courses have ended up failing the course.
Our reaction to your cheating will also vary according to the way you handle the situation.
If you seek us out and admit that you have cheated, we will be lenient.
If we come to you and ask if you have cheated and you freely admit it, we will take that into consideration.
If you do not admit that you have cheated, we will provide our evidence that you have done so. We will at the very least fail you in the class; furthermore, we will take our evidence to the dean and seek more substantial penalties.
To help prevent cheating, you must read-protect the directory in which you develop your assignments (if you work on an Andrew machine). To protect a directory named, for example, 745hw, you would type the command
fs sa 745hw username all -clear
where username is your Andrew userID. Read-protect any directories in which you develop code for 15-745.
Collaboration not only helps you get the job done, it teaches you how to explain your (inchoate) ideas to others. This is why we permit discussion of the problems between students. Be careful not to let other people do all the work. If you misuse the opportunity for collaboration in this manner, you will fail the exams and do poorly in the course. Many of the course materials will be the same as in previous years. This is not because we are lazy. It takes years to develop good problems. The only reason to change them is to make cheating more difficult. It is far better for you to work on the most excellent problems that we could find in my life so far. We appeal to your sense of honor because this is what is optimal from a pedagogical point of view.
There is no need to cheat in this course. If you feel tempted to cheat for any reason (e.g., you are falling behind or feel that the material is too difficult), please reconsider and seek the advise of the instructor or one of the teaching assistants. You will find us to be open, understanding, flexible, and discreet in discussing your situation with you. Cheating is, both in the short and long term, the most difficult way out of a jam in this course.
|Top||General Info||Schedule||Projects||Assignments||Papers||Useful Info|