> On Jun 18, 2026, at 2:10 PM, Bill Gunshannon via cctalk
> <[email protected]> wrote:
>
>
>
> On 6/18/2026 1:13 PM, Van Snyder via cctalk wrote:
>> On Thu, 2026-06-18 at 15:38 +0800, Tom Hunter via cctalk wrote:
>>> 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.
>
> 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.
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
