Re: Object-oriented compiler construction: ideas?

Oliver Plohmann wrote: (Well, just for the record, I think I recognize my
own post, unless Oliver is sharing my most intimate thoughts...)


: You can even take this idea further by having a NonTerminal root
: class, a Statement class derived from NonTerminal, an IfStatement
: class derived from Statement, etc...


: You can then have semantical analysis and code generation methods
: defined as virtual (deferred) in the intermediate classes, and
: redefined in the leafs.


> A surprising (tiny) benefit of this organization is that people's bug
> reports often identify exactly which piece of the compiler is broken.
> Bug reports are usually "when I write this IF statement it doesn't work".
> It's rare to have someone say, "I think code generation of conditional
> branches is broken". The value of this benefit increases as the
> experience of the bug fixer decreases.


Another benefit of this approach is what we referred to as the
"compiler support feature". The basic idea is very simple: the programmer
can define his (or her) own classes replacing virtually any of the existing
classes of the compiler, so that one can change its behaviour by redefining
one or more methods.


This approach is quite interesting in the sense that it allows for
different versions of the compiler without actually altering the original
source code. New versions of the compiler can be produced without invalidating
the other versions.


Creators are objects responsible for the creation of the various objects
of the compiler (quite similar to the Factory pattern). One can define his
(or her) own creator so that a derived IfStatement can be used instead
of the original IfStatement. Originally, the creators mechanism was restricted
to non terminals; but it has been extended to other objects of the compiler
(lexical analyzer, symbol table, etc...) as well.


One might think that this is only a techie's feature, and, when originally
thinking about it, I thought it would be limited in scope. In practice, it
happened to be extremely useful. Among other interesting achievements,
we have a SQL aware compiler, where SQL statements can be mixed freely
with common YAFL statements and where SQL expressions can be mixed with
common YAFL expressions. We also have a compiler-compiler compiler, where
some classes are marked as non-terminal classes, with a grammar rule. This
compiler compiler avoids most of the impendance mismatch between YACC
and the host language (C).


> The SRC Modula-3 compiler does not include an optimizer. If it did,
> I expect other weaknesses in the design would be exposed. I don't think
> it would be difficult to implement high-level optimizations using
> methods for the needed predicates and transformations. Low-level
> stuff like instruction scheduling doesn't fit as well. But, by the
> time you get to that stuff, the AST is largely irrelavent.


Regarding the intrinsic limitation in terms of optimization one can
apply to a compiler that generates C code, we did implement quite a
few optimizations using this scheme, with reasonable success.


Subtrees pattern matching can be performed in an almost generic way
(having methods in intermediate classes; redefined in leaf classes).
We also included quite a lot of work in detecting when the garbage
collector was actually needed, so each nonterminal maintains some
information indicating whether it does allocate memory or not. Here
again, this feature is provided quite deep in the inheritance tree,
redefined in an whole bunch of derived classes.


Cheers...


Darius


--

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