Re: Source to Source Compiler?

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.


>Is there anyone who has done such a job and can give advice? Maybe
>there is even some modified gcc frontend or other software serving
>this purpose ?


As part of the Philips TriMedia ISO C compiler, I developed a tool
called 'sst' (for source-to-source translator, btw, the name was
penned by Andrew Huang of CMU, who also did some of the original work
on it.)


Anyway, the idea was to build a multi-file or program level Abstract
Syntax Tree / call graph representation and then do interprocedural
analysis and inlining/cloning type optimizations on it.


Currently, it performs profile and heuristic based inlining at call
sites or by recognition of 'inline' on a multi source file
(irrespective of function position) basis. So its a little superior
to most inliners in that its more selective and tunable about when and
where to make an inlining decision. I added a language extension to
the compiler supporting block-statements in expressions (ala gcc) to
simplify the actual instantiation.


Interprocedural alias information was to have been passed through to
the compiler by adding pragma's denoting the alias sets for parameters
and globals. Complexities of path specific alias information were not
considered. This feature was never implemented. I believe that this
capability would enable better global optimization and code scheduling
decisions to be made.


Other features that I thought could be added to this type of tool
would be:


A multi-file lint capability.


Interprocedural copy propagation (maybe).


Dynamic bounds and pointer checking code, sort of
source level purify(tm) capability.


I remember that avoiding parse-time rewrites of the AST (as is done in
all other C compilers I'm aware of) allowed emitting C source code
that was very much like the original user's source (though pretty
printed). It would have been simple to support passing comments
through the translator, but I had no real need for this capability.
Actually, since each node in the AST form referenced its original
source line and column, it would have been possible to reconstruct the
original user's formatting style. In any case, since sst necessarily
runs post preprocessor there were few requests for this type of
feature.


Execution speed was comparable to preprocessor overhead, the downside
being that all files needed to be compiled at once, also name pasting
of statics could end up in confusing debug information.


Structurally its pretty elegant, it shares the same front-end as the
compiler proper. The idea was to avoid an overly complex monolithic
compiler by breaking out program level optimizations in a multi-file
preprocessing stage. The downside is that this analysis is source
language, rather than compiler intermediate representation or object
code specific.


Still, I believe it would provide an interesting platform for various
types of optimization and program analysis research. Partly since the
AST form is very close to the original source code.


Both sst and the C compiler proper were developed under contract to
Philips TriMedia, as part of that contractual agreement I retain full
rights to these tools. These tools are also fully validated by both
Plum-Hall and Perennial validation suites.


I would be willing to make sst available for research purposes under
NDA and a small licensing fee. I'd require fairly strict assurances
since I am actively marketing the technology.


Of course if anyone just wants to go over some the problems in this
kind of effort, feel free to mail me.
--

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