In Connection with the Exam

How strong a requirement is it that no lines in our programs should be longer than 79 characters?

When we evaluate your project, we primarily look at your code on our screens, and it's not a problem if lines are somewhat longer. However, people use different font sizes and wrap-around lines are a pain, so try to avoid extremely long line. Occasional long lines is not a problem in this context. Another issue is the oral examination. Due to the rapid succession of students, we have to use a simple and fast format for discussing your code. I normally prepare transparencies for this. If your lines are no longer than 79 characters, then you are guaranteed that the code you see during the exam has the same layout you're used to. If you have long lines, they will wrap around. If nearly every line does this, it's really hard to read, and you may get confused or be too slow at explaining what you see on the slide. When I prepare the code questions, and I observe this, I may try to improve on it by fixing some of the wrap-around lines. This will improve readability, but will of course imply that what you see on the slide is not your own layout. If you completely ignore the requirement and have all long lines, I may decide that there's no reasonable fix, and you may be presented with something like this: ManyReallyLongLines.c.

How do you ensure that the code you put on the projector is written by the student you are examinating?

Obviously, I can't. This is one reason why all group members are responsible for all code, independent of who has written it. You must know the code written by fellow group members as well as your own.

Is it OK to talk about stuff that we didn't have time to do?

It's OK to go beyond what you did. If you got halfway through something, but ended up not finishing because of problems and time issues, it might be interesting to sketch your concrete problems and how they can be solved. Even if you just considered a certain topic carefully, but didn't manage to implement it, you could discuss some of the issues. It's important to notice, however, that you do not get any credit for just telling us about parts of the curriculum from the compiler course. For example, explaining the general algorithm for register allocation through liveness computation, graph building, and graph coloring is not a new contribution. Instead, you should explain in context of your compiler what the additional issues are when you want to realize the algorithm known from the course. Thus, you could discuss questions such as the following: Which registers can be used as colors? What would you do with registers that are special to some instructions? What parts of your code would you analyze? How would you identify those parts? Should one use a special strategy when generating temporaries in order to get the best possible result? Etc.