|Coding a translator between languages with high abstraction levels email@example.com (Alfonso Acosta) (2006-11-08)|
|Re: Coding a translator between languages with high abstraction levels DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-08)|
|Re: Coding a translator between languages with high abstraction levels firstname.lastname@example.org (Peter Ludemann) (2006-11-10)|
|Re: Coding a translator between languages with high abstraction levels email@example.com (Christopher Diggins) (2006-11-10)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||8 Nov 2006 13:55:33 -0500|
|Posted-Date:||08 Nov 2006 13:55:32 EST|
Alfonso Acosta wrote:
> I'm a computer science engineering student, writing his masters thesis
> about a VHDL translator for ForSyDe
> (http://www.imit.kth.se/info/FOFU/ForSyDe/ , a Hardware Description
> Language embedded in Haskell, http://www.haskell.org/ ).
> Can anyone recommend any books/articles which cover translation
> between high level languages? Pointing to an open source project with
> similar characteristics would also be helpful.
I've nothing ready for study, but in my last decompiler project I came
accross almost the same problem/task. My decompiler accepts several
input sources, through frontends, including HLL, and creates CFGs for
> [In my experience, code generation for high level translators isn't
> very different from generating assembler. Constructs that seem the
> same always turn out to be just different enough that you have to do
> grotty detailed stuff to get the semantics right. -John]
That's my impression as well. I've been working on the low (procedural)
level for now, with a set of common HL control flow structures,
including e.g. loops, switches and SEH. For now these structures are
created from source code only, with the intended extension of
structuring LL (even binary) code as well, in an intermediate analysis step.
Most of these structures have attributes, describing the subtle
differences between languages. Every HLL back end can translate certain
more or less immediately compatible forms of the structures, based on
fixed patterns. Unhandled structures should be broken down into lower
level structures, possibly by using methods in the front end module,
that produced the intermediate representation and knows about the
implementation details of the source language.
Finally the back end can analyse the resulting control structures again,
and transform them into constructs of the target language. But all that
transformation stuff is theory for now, stopped at the point of the
selection of an appropriate list/tree manipulation language. I think
that I should leave this part to other people, with more appropriate
As soon as various models for objects or lifetime management (GC...)
come into play, the sets of compatible languages can become very small.
Did you consider the formal description of algorithms as kind of very
high abstraction level languages/code?
Return to the
Search the comp.compilers archives again.