Overview
|
In the course of the semester, we will implement a compiler for a
subset of C called C--.
The project will consist
of a series of programming assignments, each of which depends on
all of the previous assignments. For this reason, it is
crucial that you write your code in a way that makes it easy to debug and
extend.
I will attempt to provide, to the best of my ability, a precise specification for
each programming assignment. Programs are expected to meet
these specifications exactly. Questions and clarifications
should be settled beforehand. Programs that do not meet the stated
specifications will be penalized heavily.
|
Time Allocation
|
Each programming assignment will involve a time cycle of approximately
three weeks: roughly two weeks will be given to complete the programming
and turn in the code, and another 5-7 days (partly spanning the grading time)
will be available for correcting any bugs before the next assignment is
given out. Individual assignments may depart from this somewhat, depending
on their level of difficulty.
|
Grading Policy
|
Assignments are due at the time stated in the assignment handout.
Late submissions are permitted, but will be assessed a late penalty
of 10 points per day.
You may turn in multiple submissions for the same assignment: they will be
graded separately, and you will be awarded the maximum of their scores
(after adjusting for late penalties where appropriate). However,
note that I will generally check the turned in assignments once a day,
so a submission that comes soon after a previous one may overwrite
the previous one. In this case, it will be possible to grade only the
later submission.
In general, an assignment will be graded by comparing its output
against the "expected output" on a number of different test inputs
using the diff utility: if your output differs from the expected
output, it will be considered to have failed that test (it is for this
reason that strict adherence to the specification is important).
Correctness is always more important than efficiency.
|
Grading Procedure
|
The size of the programs involved in the project makes it impractical
to manually examine your source code to determine its correctness. Instead,
we will use the following procedure:
-
You will develop and test your code using your own test cases.
It is permissible for students to share test cases.
I strongly recommend giving very careful thought to your test
cases. In my experience it is very useful to have (1) a large number
of small test cases, each of which tests one or a few language
features; and (2) a shell script driver that runs your program on
all your test cases and checks whether you got the output you
expected.
-
I will make my test cases public after the submission deadline.
-
Your code will be grader on my test cases using a grading script.
You will be awarded a preliminary score based on the
number of test cases failed. This preliminary score will be
sent to you by email.
-
If you were penalized more
than once for the same problem, you will have the option of
bringing this to my attention over the two weeks following
notofication of your preliminary score. Specifically, you
will need to provide me with:
- a list of the specific problems in your code; and
- for each problem, the test cases that failed as a result.
-
Based on this, I may adjust your preliminary score where
appropriate, based on my assessment of the seriousness of
the problems. However, any such adjustment will always
be positive, i.e., you will not be penalized—but may be
rewarded—for explaining the problems in your code.
Different assignments will be given different weights, based on their
relative difficulty, and the weighted scores will be used to determine
the final grade.
|
Style
|
Some suggestions on programming style
|
Testing
|
Hints on Testing and test case generation
|