Re: Object Oriented Approach to Compiler design and Implementation.

    naveens@noida.hclt.com wrote:
> In recent months,I had some time to see the implementation of some
> compilers of C,Fortran. Understanding the implemenations was
> difficult,simply because there were too many globals modified in
> different parts of codes.Such a problem seemed more acute in
> complicated language like Fortran-90.Also,it seemed that
> implementations were procedural(From maintainablity point of view
> object oriented implementations would look more promising.Plus other
> benefits of object oriented paradigm)


    Instead of viewing compiler implementation as a monolithic piece of
software that translates a given language like C++ or Fortran 90
(does anyone still use Fortran 90), it is better to view a compiler
as an infrastructure. A compiler infrastructure can be built from
objects that support:


    -- memory allocation (assuming we are not using Java)
    -- abstract syntax tree generation
    -- constant pools
    -- string pools
    -- Parsers (which generate a common abstract syntax trees type)
    -- symbol table (and perhaps type table, for languages
          like C, C++ and VHDL)
    -- flow graph creation
    -- extended basic block (EBB) creation
    -- local common subexpression elimination on EBBs
    -- static single assignment optimization
    -- register allocation
    -- code generation


    Ideally these objects could be pulled apart and replaced with new
objects. This makes the compiler easier to modify for new
applications and targets and greatly reduces development time.


    I don't think that such an object oriented compiler would
necessarily be much easier to understand that an well written
monolithic compiler. Compiler infrastructures like this always remind
me of Sauron's ring in the Lord of the Rings. Sauron can use it
because he created it for his use. In everyone else's hands the ring
does little good and potentially much harm to the user.


    An object oriented infrastructure does not change the fact that
compilers are large complex pieces of software. There is a huge
learning curve in understanding someone else's infrastructure.


    Finally, while a well engineered compiler created out of objects
will be easier to maintain and be more reliable, I have seen horrors
in C++ that simply are not possible in C. For example, complex and
convoluted constructor chains in deeply nested objects that took me
hours to understand and unravel. So the fact that a compiler is
implemented in C++ is no guarantee that it is any better than a
compiler implemented in C. In fact, it may be much worse.


    There are some object oriented compiler infrastructures out there
that are targeted at compiler front ends and middles (e.g., AST
transformation). For example, the SUIF infrastructure from Stanford.


    Compilers are expensive to create, so most people who write them do
not put them in the public domain. Certainly the GNU C++ compiler is
not a model of object oriented clarity. I believe that the HP C++
compiler uses the C++ front end which was written at Taligent. This
is probably very object oriented code. Most of the Fortran, C and
VHDL compilers I've seen have been implemented in C. But again, this
does not mean that their design and implementation is necessarily
worse that a C++ compiler.


    Ian Kaplan
    abuse@bearcave.com (a valid, but anti-spammer address)

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