18 Jun
2026
18 Jun
'26
11:30 a.m.
On Jun 18, 2026, at 2:10 PM, Bill Gunshannon via
cctalk <cctalk(a)classiccmp.org> wrote:
On 6/18/2026 1:13 PM, Van Snyder via cctalk 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.
paul
On Thu, 2026-06-18 at 15:38 +0800, Tom Hunter via
cctalk wrote:
Interesting. I did Autocoder but never thought of it as assembler.
Programming the 1401 in assembler was when you took the output from
an Autocder deck and hand optimized it to a single card. :-)
As for translating from one language to another, that was pretty much
standard practice for a long time. GNAT Ada produced C. P2C converted
Pascal to C. F2C the same for Fortran. Early precursors of GNU COBOL
did the same. Assembler knowledge is not necessarily needed to write
a compiler if you have another language to function as the intermediate
stage of the compiler. You missed the point. The compiler backend is
emitting assembly code,
so
you better have a very good understanding of the underlying hardware
and
the assembly language for the machine to successfully write a
compiler
backend for the architecture in question.
The IBM 1401 COBOL compiler wrote
assembler (Autocoder) on a tape. Then
you had to mount the Autocoder assembler tape and assemble it. And it
included the input COBOL code as Autocoder comments.