|Source to Source compilation - targeting C? email@example.com (Mark Txx) (2009-12-28)|
|Re: Source to Source compilation - targeting C? firstname.lastname@example.org (Ira Baxter) (2009-12-30)|
|Re: Source to Source compilation - targeting C? email@example.com (BGB / cr88192) (2009-12-30)|
|Re: Source to Source compilation - targeting C? Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2009-12-31)|
|From:||"Ira Baxter" <firstname.lastname@example.org>|
|Date:||Wed, 30 Dec 2009 09:53:17 -0600|
|Posted-Date:||30 Dec 2009 12:28:31 EST|
"Mark Txx" <email@example.com> wrote in message
> Anyone have suggestions for a way to take a fairly simple "custom"
> high level language (syntax and semantics) to target C as the output?
> (doesn't have to be readable C)
> By this I mean an existing backend that outputs C already exists for
> the "tool". The "tool" must be relatively easy to use assuming
> knowledge of BNF, grammars etc but not much in the way of code
> generation knowledge.
> Does the ROSE compiler framework do this?
The ROSE compiler framework is relatively good at transforming C and
C++ into revised C and C++, and perhaps Fortran into revised Fortran.
This "limitation" occurs because it ROSE uses preexisting parsers (the
EDG front end for C and C++ and something else for FORTRAN) and
doesn't have a general mechanism for defining DSLs, as I understand
The DMS Software Reengineering Toolkit is designed to be a source-to-source
transformation system for arbitrary langauges. It has means for
defining your own arbitray syntax, automating the construction for parsers
for such, and applying transformations that map fragments of your syntax
into fragments of syntax of other langauges. DMS can be obtained
with robust C front ends, so defining transformations that your DSL
into C fragments is generally straightforward.
I don't know if DMS will satisfy your "relatively easy to use" criteria.
If nothing else, the C parser that DMS uses is pretty complex
because C itself is complicated and messy.
In actual practice, langauge translations can be pretty complex; after
all, you are trying to bridge a non-trivial semantic gap if your DSL
is interesting. (If you aren't bridging a deep semantic gap, what's
the point of the DSL?) This means you in general you need all the
machinery of complex translation engines (symbol table construction,
AST walking, control and data flow analysis, optimizing transforms,
etc.) and and understanding of how all of that is put together with a
particular infrastructure. Learning the particular infrastructure
takes some time. The point is that you can learn and use such
infrastructure in far less time (weeks to months) than it will take
you to build the pieces (years, IMHO) you need if you want to do
something really interesting. DMS has been in constant engineering
for 15 years, and Rose I think for about 10.
DMS does provide a well-documented infrastructure with all of this (it
is a commercial product and we try to meet commercial expectations).
Rose does have online documentation and of what I can see it seems
fairly reasonable. YMMV.
Ira Baxter, CTO
Return to the
Search the comp.compilers archives again.