On Thu, Jun 18, 2026 at 9:19 PM Van Snyder via cctalk <[email protected]> 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/regression-compile/asm6809.lis (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/regression-compile-imptoc/asm6809.c 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/regression-compile-tmp/asm6809.c (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/regression-compile-tmp/asm6809.recoded.lis 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/code-listings/ ) So I do believe there is still a place for language translation of this sort. Graham
