Talk:Compilers

These are just the textual comments from the feedback forms. The numeric scores, e.g. for whether I was audible from the back, are too boring to be worth preserving.

Comments from 2013

Lectures

• Very good course and lecturer, did feel the notes lacked a lot of detail, though.
• The lectures were interesting and really useful.
• The course was great and Spivey is an excellent lecturer. I wish his notes were more thorough and the provided texts are useful for general reading although not terribly helpful for the specific problems (often implementing certain discussed problems in OCaml).
• More thorough notes would be useful.
• The practicals were essential to the understanding of the course. Was doubtful as to how much I'd enjoy the course but was very pleasantly surprised.

Practicals

• Clearly prepared for Linux, it didn't cater well for those like me who had very little experience with Linux. I passed hours trying to make the practicals compatible with Windows, to no avail. I ended up by installing a Linux virtual machine on my own machine as suggested by our tutor, which worked very well. Having never used a virtual machine before, I hesitated to use it since I believed it would be a big hassle to set up. Therefore for future years it might be useful to indicate that this is the best way to go for Windows users and that it's very easy to set up.
• The final practical's static link following exercise was a little too challenging in my opinion. Many students struggled a lot and resorted to hacking or seeking excessive help. More, simpler questions would perhaps have been more helpful. (That said, it very much reinforced the concept of static links in those of us who succeeded so I suppose I'm torn on the issue!)
• The practicals were difficult but invaluable in understanding the material.
• Essential to the understanding of the course!

Comments from 2012

Lectures

Was there anything you particularly liked about the material you learned on this option?

• This course also teaches a lot about language constructs that I never considered until I came to compile them, and why certain things aren't part of languages.
• I really enjoyed learning about stack frames. The explanation on how Object Oriented languages can be implemented was really useful. Coupled with the fact that I was attempting to write my own language in Haskell in a rather odd way for a different reason alongside the course, I found the whole course really fascinating. Sometimes I saw that what I had implemented coincided with the real world, and other times it did not. In particular, I wanted to deny address arithmetic so that it would be easy to determine when two operations would interfere. That was possible while the memory allocated remained static, but as soon as it could only be determined at run time, I ended up having to simulate address arithmetic anyway.
• Explored the topic of compilers pretty comprehensively and quite accessibly, considering the short amount of time available. Also, Spivey's a fun and not boring lecturer, and it's pretty obvious he likes compilers. I missed only one of these lectures this term, and I'm sorry I did. Also, the standalone OOP compiler lecture was good.
• Good pacing. Great that examples were given for both RISC and pseudo-x86 of various things throughout.

Was there anything you particulary disliked about the material you learned on this option?

• There were a few areas that I would really have loved clarification for. For example, I don't think the reasons for the dynamic link and the return address were explained enough, and LR1 parsing felt rushed.
• Not sure I liked the whole passing the Static Link as an argument on the stack thing, just to support nested procedures. It complicates the compiler (adding +1 to CALLW everywhere, that damn code from lab4 for walking up the stack frames.. ugh), and I reckon we could've gotten away with just passing the necessary args from outer procedures to the inner ones on the stack directly (in anything other than extreme cases). Then again, I guess it is the only thing that makes lab4 hard, and we should learn to deal with some arbitrary complexity. The register-based machine code at the end appeared a little suddenly. Not that that's a particularly heinous crime, but I'm pretty sure on the last problem sheet I wrote all my `stw' instructions the wrong way round... Also, 8(bp) means (value of bp + 8), right? (note: these are all minor things)

Were there any topics that were not included in this option that you would like to have seen covered?

• Things like polymorphic types, and lazy evaluation perhaps would have been more interesting than low level code optimisation.
• I know there's no time left in labs, but actually implementing/modifying the peephole optimizer would've been pretty cool. Maybe briefly describe some calling conventions on desktop operating systems? (e.g. how sometimes caller and sometimes callee must clean up dependent on convention, what GCC does on lin, how mips&x64 like to use registers, more vs. x86 win, how it's all an unholy mess. on second thoughts, maybe this is a terrible idea.)

Are there any other comments you would like to make about this topic in particular or the Undergrad/MSc course in general?

• Dr Spivey is one of the best, if not the best lecturer I have had in a year and a half of CS. Compilers strikes me as something that could have been painful and confusing, yet the lectures were straightforward and interesting, making this my favourite course of the year so far.
• Some of the Keiko specification on Mike's website seems out of date or inaccurate occasionally.
• Mike spivey is the best lecturer I've had for this or last year. I hope that I can have him for at least one of my Lecturers next year.
• While OCaml doesn't produce the worst error messages in the world when processing incorrect code, it's not really helpful, either. I think there's some tool that's a prettifier for OCaml code that comes with the standard OCaml dist, that produces much more helpful errors when using bad syntax and so forth. Might wanna namedrop it in lectures/labs. (Or switch to F#. (I kid, I kid.))

Practicals

Were the arrangements of the sessions (the number of sessions, the signing up method, the schedule) clear?

• One of the two sessions for this lab was arranged at the same time as a core 2nd year course. This meant that there were 3 people in one lab session and closer to 20 in the other - hardly seemed fair on the lone demonstrator, or on the 20 people who needed to be signed off in a single session.
• The times were changed and I didn't realise this at one point for some reason. I think that is really my own fault...
• One of the practical sessions (the wednesday one) was arranged for during the wednesday concurrency lecture, which was compulsory for all second years. as a result, everyone had to go to the friday session (~22, 23 people), and literally 2 people went to the wednesday ones.

Was the signing off of your practicals prompt?

• Not enough demonstrators.
• (As prompt as could be, considering the previously mentioned issue with the uneven group sizes.)

What was the most interesting aspect of the practical?

• Learning about how all the different parts of our compiler communicate.
• Really enjoyed the material.

What, if anything, do you think should be changed?

• 4 sessions for 4 lab tasks is a bit tight - lab 1 is framed as optional but the demonstrator correctly advised that it would be a very good idea to do it. Had the 4th session not been pushed back a week, completing the 4th lab would have been a rushed and stressful affair.
• The first part, which is supposed to be to learn ML, doesn't really teach enough of it. A longer part introducing ML and another session or two would have made the remainder much easier.

Comments from 2011

Lectures

Was there anything you particularly liked about the material you learned on this option?

• Dr Spivey's functional code
  reads like
  a pearly haiku.
• Very useful (and still accessible) to someone without a particularly strong programming background like myself.

Was there anything you particulary disliked about the material you learned on this option?

• The Keiko virtual machine is not documented, or at least the documentation I could find on it (the one-page summary at the end of the lab manual) was not nearly sufficient. How are we supposed to write assembly for an undocumented machine?!
• The course focused too much on low-level details such as optimizations and code generation.

Were there any topics that were not included in this option that you would like to have seen covered?

• The course did not cover more advanced high-level features such as object-oriented languages.

Are there any other comments you would like to make about this topic in particular or the Undergrad/MSc course in general?

• Really well structured course; very informative.
• The lecturer was in a few cases rude to the audience; fine when he knows the people, but in some cases more restraint could have been shown; the purpose of a lecture is to inform, not to attempt to entertain.

Practicals

What was the most interesting aspect of the practical?

• Fitted perfectly with the taught part of the course, more so than any other practical course I've ever taken (in this or previous degrees); in no way felt tacked on, and was extremely useful in understanding the taught material.

What, if anything, do you think should be changed?

• In the lab manual number the chapters starting at 0. This would make the chapter numbers line up with the lab numbers.
• The practicals had a very "do x, then do y, then vaguely do something like z" feel to them. At first, I really didn't understand what I was doing at all, and even as I started to change things, it took many weeks to have any kind of handle on what was happening. Also: the provided files' function names and comments were kind of iffy; I didn't (and still don't!) really understand what many of them were doing.
• The last excercise was not explained well, and was confusing.
• In the description of the course it was stated that there would be an introduction to the language OCaml. The lab1 was supposed to be such, but it was helpless in terms of learning to use the language (the materials did not teach how to solve the exercise).
• In my opinion, using OCaml was much more a problem than a useful tool during the whole course. I spent much longer dealing with syntax and debugging issues than with the underlying concepts themselves. Also, starting from the whole code and only modifying it does not really give a complete overview of the structure of the compiler, and makes it more difficult to understand than if it were built part by part by the student.

Classes

• The classes for this course were fantastic. They complemented the course well, made me think about various relevant issues, and really helped me develop my understanding. The class tutor was also excellent.
• The problem sheets went up very late, leaving little time to complete them
• Really good. For two of the four classes, the exercise sheet was published 2 days or 1 day before the deadline. This means that the class was virtually wasted, as there was no practical time to complete the proposed work (keep in mind that many courses had overlapping deadlines).
• Also, many of the exercises were quite open and too long. This meant that the exercise sheets did not provide the students a good measure of how well they were doing in the course.