|Source to Source Compiler? Christoph.Niedermeier@zfe.siemens.de (1996-05-10)|
|Re: Source to Source Compiler? email@example.com (Derek M Jones) (1996-05-13)|
|Re: Source to Source Compiler? firstname.lastname@example.org (1996-05-13)|
|Re: Source to Source Compiler? email@example.com (1996-05-14)|
|Re: Source to Source Compiler? firstname.lastname@example.org (Dr. Karl Prott) (1996-05-14)|
|Re: Source to Source Compiler? email@example.com (Norman Culver) (1996-05-19)|
|Re: Source to Source Compiler? firstname.lastname@example.org (1996-05-19)|
|From:||email@example.com (Alex Colvin)|
|Date:||13 May 1996 14:30:33 -0400|
|Organization:||Dartmouth College, Hanover, NH, USA|
Christoph.Niedermeier@zfe.siemens.de (Christoph Niedermeier) writes:
>We are intending to build a frontend compiler which translates ANSI C
>plus our own extensions to pure ANSI C. Our idea is to use the sources
>of the GNU C-Compiler and modify them such that C code is produced
>instead of assembler code.
I'm doing this for a C* to C translator. I agree that taking a real
compiler is probably not the way to go. C makes a lousy machine
language to emit, and too much useful information is lost.
What I do is turn the C source into a parse tree, then do tree
transforms on it. This is hard or easy depending on the nature of the
transforms. I annotate tree nodes with various information - the
declaration node for each variable reference, the type for
expressions, as well as bits for const, lvalue, etc.
One useful attribute is a bit marking subtrees that contain
nonstandard features. Anything not so marked is left alone. Types
keep their C structure, so generating a declaration for a temporary is
Since this is essentially a C parse tree, the back end is just a table
of formats for printing.
My work started with the UNH C* to C compiler. You can probably also
have my work-in-progress, in C++.
Return to the
Search the comp.compilers archives again.