Related articles |
---|
Translating Algol to C or Cobol deh0654@sjfc.UUCP (1989-05-16) |
Re: Translating Algol to C or Cobol kgg@lfcs.ed.ac.uk (1989-06-15) |
Re: Translating Algol to C or Cobol juliar@hpcll17.HP.COM (1989-06-06) |
Newsgroups: | comp.compilers |
Summary: | |
Expires: | |
References: | <3893@ima.ima.isc.com> <539@sjfc.UUCP> |
From: | kgg@lfcs.ed.ac.uk (Kees Goossens) |
Organization: | Laboratory for the Foundations of Computer Science, Edinburgh U |
Keywords: | ALGOL, C, translation |
In article <539@sjfc.UUCP> deh0654@sjfc.UUCP (Dennis E. Hamilton) writes:
>In article <3893@ima.ima.isc.com> Gordon Jenkins <gordon@pyr.gatech.edu> writes:
>>I'm looking for any information available on sources for tools to
>>aid in the conversion of ALGOL sources to C (or heaven forbid, COBOL).
>
>As the moderator commented, this would be quite a challenge.
I worked on project which translated a large subset of Algol68 to C.
The subset excluded most of the transput (IO), a more limited module
system than the original system (RS Algol68) has and some small restrictions
(eg selecting a field from an array of structures resulting in array:
[10] STRUCT INT first, REAL second END : array;
[] INT another array = first OF array;
... # Note no ^ space! a nice feature... # )
It worked. And the generated C ran as fast as the original Algol68.
The code produces was truly horrendous.
> ... Unfortunately, the nesting of procedures in ALGOL
>is a very real requirement, as is the passing of closures as parameters
We had to pass environments around ourselves to get around this. Even so,
the resultant code was runnable (rather than walkable :-).
>In no case would I expect a translation of ALGOL to COBOL to be
>intelligible to a human programmer, and the odds are that C translations
>would not be maintainable by human beings either.
> ... ALGOL translations should be at least as hairy,
>though for different reasons.
We generated unique variables names (for the module system to work)
of the form ABCDEF_orginalname to retain some of the original program.
The main problem was that we generated immense amounts of temporary
variables and brackets, mainly because it was not always possible to
tell whether something is going to evaluated more than once.
>-- Dennis E. Hamilton {uucp: ... !rochester!cci632!sjfc!deh0654}
Kees Goossens Keep in Touch with the Dutch:
LFCS, Dept. of Computer Science JANET: kgg@lfcs.ed.ac.uk
University of Edinburgh UUCP: ..!mcvax!ukc!lfcs!kgg
Edinburgh EH9 3JZ, UK. ARPA: kgg%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.