Re: Is C++ really used ?

Daniel J. Salomon (salomon@silver.cs.umanitoba.ca) wrote:
  > There were two significant shortcomings in the OOP design of our compiler:


Shankar Unni <shankar@chromatic.com> wrote
> And therein lies the crux of the discussion. Daniel is talking about
> an O-O design of a compiler, while the others are talking about
> implementing a compiler in C++. Needless to say, the discussion is at
> cross-purposes.
>
> Certainly using C++ as a more advanced C, with better encapsulation
> and type checking, is a great idea. I'm all for it, and in fact, have
> seen several compilers do this. No argument there.
>
> It's an altogether different thing to design a compiler in an object
> oriented fashion from the ground up.
>
> Daniel pointed out the two critical points at which the
> straightforward O-O paradigm breaks down: transforming ascii text into
> a parse tree, and transforming the tree back into optimized machine
> code.
>
> I think the key is that we must recognize that there are three
> "processes" involved here, conceptually. The first process parses the
> source code and produces a tree of objects.




You can easily produce an object-oriented parse tree out of BNF-like syntax
by considering three kinds of productions:
- aggregate productions
A ::= B C D
    which can be translated into
class A has three attributes : B C & D
- list productions
A ::= {B C}
    where B is the repeting element and C is an optional separator
    which can be translated into
class A is a list of Bs
- choice productions
A ::= B | C | D
    which can be translated into
B derives from A
C derives from A
D derives form A
Writing a grammar with these sole kinds of productions allows you to
produce a parse tree without writing a single line of code (provided you
have the right tools...)


> Once the tree is created, the second "process" performs the entire
> frontend semantic analysis, and even generation of a first level of
> intermediate code, and can be designed in an object-oriented fashion
> ("analyze yourself"; "allocate storage for yourself"; "generate
> intermediate code for yourself"). You'd need the odd standalone global
> objects to manage storage allocation, etc., but overall, the whole
> thing can be pretty clean from an O-O point of view.
>


Semantic is also easily implemented given that every class corresponding
to a production has a validity method
Code generation is also possible using a design pattern such as the Visitor
pattern
This allows you to reuse your parse tree for other purposes (beautifiers,
doc
generators, etc...)


> Once we descend into the third "process" (optimization and code
> generation), it's another ballgame once again. Most optimization
> algorithms used today are not readily amenable to an object-oriented
> implementation.
>


Many of the optimization algorithms can gain from being implemented in
an object-oriented way. For example, solving data-flow equations can
be made generic by using a design pattern such as the Strategy pattern.


> However, an object-oriented implementation is not necessary in order
> to achieve a modular optimizer design (where passes are
> interchangeable and intermixable) - SUIF is a good example of such a
> design, as are several commercial optimizers.


However, object-oriented techniques such as dynamic binding can
advantageously
replace 'switch' statements and make your compiler run faster...
--

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