Re: Teaching compilers backwards?

Peter Fröhlich <phf@cs.ucr.edu> writes:


> On Monday, Mar 15, 2004, at 06:37 US/Pacific, Johnathan wrote:
>
> > I'm at the stage where I'm doing compiler construction and I agree.
> > Compiler courses are very unsatisfactory because we don't write real
> > compilers or really learn anything. By the time the exam is "last
> > week," everything is pretty much forgotten. The course runs way too
> > fast and everything is vague and abstract. If we're lucky we'll do a
> > stupid YARPNC (Yet Another Reverse Polish Notation Calculator).
>
> I have been teaching one of those "dreaded" (if I read the other
> comments in this thread right) single quarter courses three times now,
> one time in a 6 week summer session. Students write a compiler from
> scratch and target an actual "machine" not just another source
> language like C.


I have similar experience (my undergraduate compiers course used to be
combined with computer architecure over a semester, but will be a
quarter-course from this autumn).


> In my mind, the key to make this work is to focus on *simple* language
> concepts. For example, students in my course do *not* implement
> procedures. [...]
>
> The programming assignments are structured into scanner, parser,
> symbol table, abstract syntax tree, interpreter, and finally code
> generator. Until this quarter I used a simple stack machine of my own
> design, but I asked people to volunteer for MIPS, and some did. Next
> quarter it's going to be MIPS only. The goal is not to generate "good"
> code at all, all they need to do is "simulate" a stack machine on the
> MIPS. Optionally they can do more, and one of the "excited" students
> actually wrote a graph-coloring register allocator this quarter.


In my course, the students also write lexers and parsers (using
generators) and generate "real" code (a very small MIPS subset). What
makes it possible is that the language is simple (it does, however,
have procedures) and because a register allocator is provided. The
students typically generate realistic, though unoptimized, code. I
believe it is important that the students get a feel for how code
generated by "real" compilers look, as it helps them understand what
consequences different programming styles (e.g., using global
variables versus function parameters) have on efficiency.


> > I have issues with the textbooks too. They are boring and extremely
> > hard to decipher.
>
> I agree. The only text I ever *really* liked is Wirth's and that's out
> of print. Sad but true. The Cooper/Torzcon text is decent, but it
> doesn't match my course very well. So I keep using my old slides, and
> that seems to work decently. I recommend Cooper or Appel as
> "background reading" for interested students though.


I have written my own book/notes, but I fear that these too seem
boring and hard to decipher by the students. Some of this is hard to
avoid: The techniques used in lexer and parser generators do make
rather dry material, and it takes a while before you get an intuition
for it.


> I guess all I wanted to say is that things *can* work out in a single
> quarter, but that there's always room for improvement. :-)


I agree. Any material will feel cramped in a quarter, but it is
doable if you avoid getting bogged down in details. For example, I
use simple algorithms instead of the optimal/optimized ones used in
real compilers (but do say that this is the case).


One reason the course including project in the course can be done in a
quarter is that the students already know Standard ML, so I can use
this as an implementation language, which makes it a lot less tedious
to write and debug the compiler (compared to, say, C).


Torben

Return to the comp.compilers page.
Search the comp.compilers archives again.