Re: Teaching compilers backwards?

I've long maintained that teaching compiler construction in a one semester
course is doomed to fail. The kids simply can't learn fast enough. IMHO, the
best way to teach compiler construction is to require a machine organization
and architecture course, and an assembly language programming course as
prerequisites. Then have compiler construction split across two semesters or
3 quarters, depending on your school. And instead of having the kids write
their own from scratch, something they'll probably never do in their
industrial careers, have them pick up something like gcc, study it, and
modify it. Retarget it to a new machine. Add syntax. Go through and
understand how it does error recovery, and try to improve on it. Yes, you
can teach them to use flex and bison along the way, but this approach will
be closer to real life, and over a year's time, working in teams, they'll
learn enough about compilation to actually be useful. Just my opinion...
Mike


"Albert Hofkamp" <hat@se-126.se.wtb.tue.nl> wrote in message
> > Well, it seems like one obvious problem with this is that each
> > phase uses as input, the output of the previous phase. And what
> > that output is, both its format/syntax, and its deeper semantics, are
> > things a compiler course student won't already know. And explaining
> > that will considerably overlap just studying the previous phase.
> >
> > Andy Gill wrote:
> >> Has anyone ever taught compilers backwards? How did it work out? ...
>
> I don't have any experience teaching compiler construction, but an
> alternative approach could be top-down, ie start with a simple
> search/replace problem, then increase the gap. As the gap becomes
> bigger, the need for a structured approach to the translation becomes
> apparent. What at least would become clear is that 'translating code'
> is not only 'real' compilers, translation happens in many forms.
>
> For example (in an assembly-like language):
>
> - have variables with a name (search/replace name to address-value)
> - have loop statements (you need local labels to jump to)
> - have expressions (a tree structure is needed(?))
> etc
>
> This can be seen as working backwards because you keep the target
> language constant, but the problems (like above) are not really
> related (as in the second problem can be solved by re-using the
> solution to the first problem) at first sight.

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