Re: Object Oriented Compiler Construction

>|> It occurs to me that inheritance should be especially useful in the
>|> construction of a parse tree. ...


Sure, no question. But is this an interesting problem?


>|> A better way to do this, it seems to me, is to define an abstract class
>|> for parse tree nodes, and then subclass specific node types from the
>|> abstract base class. I envision member functions like SanityCheck(),
>|> Optimize(), and GenerateCode() which take very different (though
>|> conceptually identical) actions for each node subclass.


litsios@iis.ee.ethz.ch (James Litsios) writes:
>I have a feeling this only works well for simple compilers. On my current
>project I am writing a compiler that does so many transformation of the
>original parse tree that the idea of storing each different type of node
>in a different class (the work is in C++) is simply not practical.
>Instead I use the OO properties of C++ to manipulate generic LISP like
>data structures


I agree, generally. Parse trees just aren't a great representation for
optimization (an exception might be if you have to perform
source-to-source transformations). If you want to do optimization, I
believe it's better to transform the parse tree into a flexible and
efficient internal form (perhaps like Litsios' data structures).


Consider an optimization like moving loop-invariant code outside a loop.
Using a parse tree, loops can have many explicit representations and
perhaps a few hidden ones (especially if your source language allows gotos
or recursion). It seems easier to translate all these parse tree forms to
a low-level form (something like assembly, with only unconditional jumps
and conditional branches for control flow) and use a single version of the
optimization to handle all kinds of loops.


Preston Briggs
--

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