Re: Coding a translator between languages with high abstraction levels

Hans-Peter Diettrich <DrDiettrich1@aol.com>
8 Nov 2006 13:55:33 -0500

          From comp.compilers

Related articles
Coding a translator between languages with high abstraction levels alfonso.acosta@gmail.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 p_ludemann@yahoo.com (Peter Ludemann) (2006-11-10)
Re: Coding a translator between languages with high abstraction levels cdiggins@gmail.com (Christopher Diggins) (2006-11-10)
| List of all articles for this month |
From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: 8 Nov 2006 13:55:33 -0500
Organization: Compilers Central
References: 06-11-029
Keywords: translator
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
further analysis.


> [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
skills ;-)


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?


DoDi


Post a followup to this message

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