Re: Teaching compilers backwards?

Albert Hofkamp <>
8 Oct 2003 22:24:17 -0400

          From comp.compilers

Related articles
Teaching compilers backwards? (Andy Gill) (2003-09-23)
Re: Teaching compilers backwards? (2003-09-27)
Re: Teaching compilers backwards? (Rodney M. Bates) (2003-10-04)
Re: Teaching compilers backwards? (Albert Hofkamp) (2003-10-08)
Re: Teaching compilers backwards? (2003-10-08)
Re: Teaching compilers backwards? (Joachim Durchholz) (2003-10-12)
Re: Teaching compilers backwards? (Peter Flass) (2003-10-13)
Re: Teaching compilers backwards? (Brian Inglis) (2003-10-13)
Re: Teaching compilers backwards? (Michael Ross) (2004-03-11)
Re: Teaching compilers backwards? (Randy Crawford) (2004-03-15)
[11 later articles]
| List of all articles for this month |

From: Albert Hofkamp <>
Newsgroups: comp.compilers
Date: 8 Oct 2003 22:24:17 -0400
Organization: Eindhoven University of Technology, The Netherlands
References: 03-09-073 03-10-014
Keywords: courses
Posted-Date: 08 Oct 2003 22:24:16 EDT

On 4 Oct 2003 14:47:19 -0400, Rodney M. Bates <> wrote:
> 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?
>> Traditionally, a compiler class starts with lexing, and flows downstream
>> towards register allocation and assembly language generation.
>> I am considering starting a compiler class with assembly language exercises,
>> and having the students build a small compiler from the back, forward.

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(?))

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.


Post a followup to this message

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