On Thu, Jun 18, 2026 at 9:19 PM Van Snyder via cctalk <cctalk(a)classiccmp.org>
wrote:
True, but that
approach has significant drawbacks and from where I
sit it appears more like a technique that was used for a while as a
shortcut to implementing a language. All the examples you gave are
now obsolete, at least in the GCC system, replaced by full front ends
that tie into the code generation machinery. A reason why this
matters is debug info; having C debug info for your Fortran program,
let alone COBOL or Pascal, is painful. Another reason is semantic
mismatches. C doesn't like nested function definitions (though GCC
sort of allows them as an extension) while other languages (Algol for
sure, and Pascal also I think) consider them perfectly good things to
do.
I'm currently working, off and on, on exactly this. I'm translating the
Imp language (which is a very Algol60-like derivative of Atlas Autocode,
which itself was a rival response to the '58 proposal that became Algol 60)
to C. Yes, I am limited to gcc due to the nested procedures, but I'm doing
it because I think gcc has a better chance of some longevity than a native
bootstrapped Imp port. (which we currently have to x86 architecture as well
as this translation project.) Imp had extensive runtime diagnostics and
post mortem facilities as well as symbolic debugging on some platforms, and
the linux/gcc environment has allowed me to reproduce many of them.
Extensive use of #line allows most of the diagnostics to appear to be in
the source language and the mapping to C is close enough that debugging
with gdb is not an issue.
I'm actually working on two translators - one is high-level and attempts to
generate C code that looks and feels more or less like native C; the other
is lower level and translates from the intermediate code generated by one
of the last native Imp compilers into C that is not meant to be seen by the
programmer - it's just another step in the translation.
To give you a comparison, here's an imp program that assembles 6809 code:
https://gtoal.com/history.dcs.ed.ac.uk/archive/languages/imp77-tmp/gtoal/re…
(that's the compiler's listing file, I could point you at the
.imp source instead but unfortunately my stupid web server causes it to
download so you can't trivially view it in a browser)
Here's the high-level generated C. This was created by writing a new
parser and compiler from scratch:
https://gtoal.com/history.dcs.ed.ac.uk/archive/languages/imp77-tmp/gtoal/re…
Here's the more low-level generated C (which for now is a more
accurate translation):
https://gtoal.com/history.dcs.ed.ac.uk/archive/languages/imp77-tmp/gtoal/re…
(You can see the differences in style at places like line 429 where an
if/then/else statement is broken down into gotos in the low-level
translation)
The low-level translation is more or less a direct transliteration of the
assembly code that the original imp77 front end (now translated into C)
generated:
https://gtoal.com/history.dcs.ed.ac.uk/archive/languages/imp77-tmp/gtoal/re…
The GCC route lets me target multiple architectures (eg code comparison at
https://gtoal.com/history.dcs.ed.ac.uk/archive/languages/imp77-tmp/gtoal/co…
)
So I do believe there is still a place for language translation of this
sort.
Graham