Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!decvax!ima!johnl
From: johnl@ima.UUCP
Newsgroups: mod.compilers
Subject: Re: Translating high-level languages into each other
Message-ID: <543@ima.UUCP>
Date: Wed, 15-Apr-87 21:15:34 EST
Article-I.D.: ima.543
Posted: Wed Apr 15 21:15:34 1987
Date-Received: Sun, 19-Apr-87 06:24:22 EST
Sender: johnl@ima.UUCP
Organization: Wang Institute
Lines: 62
Approved: compilers@ima.UUCP
Posted-Date: Wed, 15 Apr 87 21:15:34 est

In-Reply-To: <541@ima.UUCP>


>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]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request