Re: standard intermediate representation for C/C++ ?

In article 92-05-095, Stephen J Bevan <bevan@computer-science.manchester.ac.uk> writes:
> dalamb@qucis.queensu.ca (David Lamb) writes:
> [Would something like DIANA be useful for C or C++?]
>
> I think the problem may be that many people don't see the point of making
> a compiler generate this special AST if all they are going to do is then
> generate code.


ASTs are resource hogs, particularly of memory, and in the early 80s most
machines simply couldnt handle a DIANA-based compiler. Plus DIANA was
specified using an object-oriented language (IDL), which had to be mapped
into a non-object-oriented language language like C or ADA. A lot was lost
along the way, including readibility and performance.


My experience suggests that each tool in a programming environment will
have a particular set of requirements for the AST, including the compiler.
The skill is designing an AST that can satisfy them all, without allowing
the AST design to grow like topsy. To achieve this you need a good core
design coupled with extensibility.


> However, IMHO this ignores some of the good uses that a standard AST can
> be put to. Some examples, that spring to mind are :-
>
> + pretty printers.
> Tools like indent for C are hopless as they consistently fail on
> source that doesn't match its limited input format.


The relationship between the abstract syntax and concrete syntax is an
area that most AST specifications do not address. DIANA didn't, it only had
the notion of an "lx_comments" attribute on each node, with no definition
of how a comment was mapped to a node. Typically a given AST supports only
a canonical concrete representation, with the original lexical whitespace
removed. I used to believe that this was acceptable, but experience has
persuaded me that an AST needs to preserve all the original input and be
able to regenerate it exactly. This does not preclude a pretty-printer, of
course.


> + code analysers
> e.g. somebody has written a program that trawls over the standard AST
> produced by the SRC Modula III compiler and finds which procedures
> are never called.


For the record, the SRC Modula-3 compiler does not make available a public
AST interface. The program in question is based on another compiler
front-end, which does have a public AST interface, and is derived from the
now defunct Olivetti implementation of Modula-3. The AST specification was
strongly influenced by the DIANA work. However, it is directly specified
in a language with object types (Modula-3 itself), in which the compiler
and associated tools are also written. The end result is reasonably
efficient in both space and time, but still more resource hungry than some
people would find acceptable. You can find more about it in:


  "An Extensible Programming Environment for Modula-3", Mick Jordan,
    Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development
    Environments, Software Engineering Notes, 15, 6, Dec 1990.


A copy of the system can be had from gatekeeper.dec.com from the file
/pub/DEC/Modula-3/release/m3tk-2.06.tar.Z. You will need the standard SRC
Modula-3 distribution installed before you can build it.


Mick Jordan


--

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