General remarks

Deadlines

The assignments should be turned in no later than 08:59 on the dates listed below:

Assignment	Date
1	November 13 $^\textrm{\small th}$, 2006
2	January 8 $^\textrm{\small th}$, 2007

For every day that you hand in your assignment late we will subtract 1 point.

Documentation

The assignments should be accompanied by separate documentation, preferably in PDF format. The documentation should reflect on how you handled the assignment; report on your approach and link it to the general theory of compiler construction as provided by the book and lectures. For instance, for assignment 1 you could indicate where you applied left factoring to make the original Asterix grammar LL(1) and provide an example grammar rule. It is important that you are explicit about the particular problems that you encountered; you must clearly describe them, your solution, used algorithms, and so on. Nevertheless, the documentation must be to the point and concise, so limit your writing to around 4 pages. The documentation will also be graded.

Instructors

At the beginning of this practical course, you will receive mail that will give you information about who will be your instructor. He will grade your solutions and provide feedback.

Person	Email address	Room
Gertjan Halkes	G.P.Halkes@ewi.tudelft.nl	HB 09.080
Bas Breijer	S.D.Breijer@student.tudelft.nl
Peterpaul Klein Haneveld	P.T.Kleinhaneveld@ewi.tudelft.nl
Leon Planken	L.R.Planken@student.tudelft.nl

Two instructors will be present at the labs at Drebbelweg to answer questions and assist with practical problems (e.g., debugging code). Take advantage of this service!

Day (Sep 20 - Dec 21)	Time	Rooms
Wednesday	8:45 - 12:45	DW_1-010, DW_1-170
Thursday	8:45 - 12:45	DW_1-010, DW_1-170

For questions about assignment 2 (object-oriented Asterix) you can also request the on-line assistance of Panoramix. This Java applet takes an Asterix program and returns example C-code (cb.h & cb.c) produced by an extended version of the reference compiler. Thus, Panoramix will provide you with a flavor of the target code that your compiler could generate. In addition, you can consult Panoramix to resolve language semantics (``what should dynamic binding do in this test case?''). Enjoy.

Grading

Grading is done per assignment. According to the following table, points can be obtained for test results, documentation, and source code. The total amounts to a 70 points maximum; 30 points are reserved for the final written exam¹.

Assignment	Test results	Documentation	Source code
1	16	7	7
2	26	7	7

How to submit your work

• In your own source directory, type

  make submit

  which will pack the complete compiler into a file named submit.tgz. Warning: if you not only modified files, but also added new ones, be sure to add them at the appropriate place in the Makefile. Note: you may not modify the cbc script, because our grading tools depend on your compiler behaving ``nicely''.

• Test if you can unpack and compile your compiler with

  tar xfz submit.tgz

  make

  (Go to some temporary directory before unpacking the compiler.)

• Upload the submit.tgz file and your documentation (PDF file) to the CPM system:

  -

  login to CPM (http://cpm.ewi.tudelft.nl/) using your NetID and password from Blackboard.

  -

  select the 'compiler construction' course.

  -

  click on the `right' entry in the overview table, which will pop-up a browse menu for sumbitting a deliverable; you need to do this twice (sources + documentation).

  -

  click on the 'notification' button if you want to receive an e-mail once your assignment is graded.

  Do not submit unless you managed to unpack and compile your own sources.

It is useless to turn in your solution far in advance of a deadline; your compiler will be tested and examined (shortly) after the deadline.

Important announcements

Frequently check the blackboard (in4020); announcements and updates to this course will be posted there.

Useful hints

• Carefully read the specifications of the language (extensions) and make sure you understand every sentence.
• Stick to the original programming style. Write cleanly, since your code will be thoroughly examined.
• Before turning in your compiler, test it carefully, both with correct and incorrect programs. Generate correct output for correct input, and give clear errors for incorrect input. Make sure your program does not dump core, even on incorrect input (although the use of assert() is encouraged).
• Both the compiler and the generated code are ANSI-C. This implies in particular that:
  • you should not generate zero-sized structs;
  • you should not generate zero-sized arrays, or arrays of variable size (use malloc() instead);
  • a block may not end with a label (e.g.: write default:;} instead of default:});
  • void * is not compatible with a function pointer; cast to the appropriate type;
  • the last field of an enum may not be followed by a comma;
  • you should only use standard library functions that are described by the ANSI-C reference manual;
  • you should not rely on the evaluation order of actual arguments.
  To test whether the code is ANSI-C conformant, use gcc -ansi -pedantic.