Re: Translating high-level languages into each other

William McKeeman <decvax!wanginst!mckeeman>
Wed, 15 Apr 87 21:15:34 est

          From comp.compilers

Related articles
Re: Translating high-level languages into each other decvax!wanginst!mckeeman (William McKeeman) (1987-04-15)
| List of all articles for this month |

Date: Wed, 15 Apr 87 21:15:34 est
From: William McKeeman <decvax!wanginst!mckeeman>
Posted-Date: Wed, 15 Apr 87 21:15:34 est
In-Reply-To: <541@ima.UUCP>
Organization: Wang Institute

>I guess I don't think there is a lot of difference between a translator and
>any other kind of compiler....

There is a long and honorable history of source-to-source translators. In
the old days they were called SIFT programs. I forget why. The bottom line
is that it is easy to do the easy stuff and impossible to do the hard stuff.
If you push, you end up translating a reasonable program in the source
language into a mess in the target language. Even if it works you don't want
it. An example of pushing:

Fortran: DIM X(20,30)
X(1,2) = 7

C: double x[20*30];
x[(1-1)*20+(2-1)] = 7;

It is sometimes less ugly if you are taking a simple language into a more
powerful one since you can pick a subset of the target language which is
close to the source language. It is also not too bad if you are willing to
use obvious (but wrong) equivalents. For example, translate to

C: double x[21][31];
x[1,2] = 7;

above and then hand-repair any faults this introduces because of the
difference in array layouts and Fortran single subscript "cheating".

For similar languages (say C and Pascal), the easy part can usually be done
by building the parse tree for the source program, transforming it into the
parse tree for the target program, and then printing the leaves on a
left-to-right sweep.

It is also sometimes useful to first simplify the source language before
attempting to translate. The original IBM PL/1 level F compiler beat all the
complex constructs into simple constructs before starting compilation. The
same trick helps in source-to-source.

For example:
C before: y = ++x;
C after: x = x+1; y = x;
Pascal after: x := x+1; y := x;

There is a school of thought that says using SIFT tools is harmful -- It is
better to take the opportunity to seriously re-engineer and rewrite old code.
Management can often be sold on a rewrite if the alternative is tool
building. It is a cost/benefit decision, where effort involved and the
quality of the product have to be taken into account.

/s/ Bill
W. M. McKeeman mckeeman@WangInst
Wang Institute decvax!wanginst!mckeeman
Tyngsboro MA 01879
[Oh yeah, SIFT, the SHARE Internal Fortran Translator, translated one dialect
of IBM Fortran to another. And almost 20 years ago I tried a Fortran->PL/I
converter from IBM and, true to form, it produced the most astoundingly awful
PL/I program, due mostly to subtle differences in the way that Fortran and
PL/I output formatting, which look almost the same, are defined. -John]

Post a followup to this message

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