[COFF] machine code translation, as mental architecture models

[Paul Winalski]

On Sat, Jul 13, 2024 at 4:00 PM Dan Cross <crossd at gmail.com> wrote:

>
> This is conflating two different things over the life of the MACRO-32
> language.  It certainly started out as a macro assembler, but with the
> introduction of the Alpha, DEC turned it into a true compiler (where
> the source language happens to be VAX assembly language) that
> generated native code for whatever machine it was compiled for: VAX or
> Alpha; using the GEM backends.
>
> The confusion arises because the name VAX MACRO was used for two
completely independent and very different software tools.

The first VAX MACRO was the conventional assembler for VAX/VMS, developed
in the mid-1970s.  It had conventional macroinstruction capabilities, hence
the name.

An inconveniently large amount of the VAX/VMS operating system code was
written in VAX assembly language.  Dave Cutler didn't believe in using
higher level languages for system code, and he despised BLISS (DEC's
standard HLL language for software product development) in particular.  To
migrate VMS to Alpha it was decided that the quickest and least error-prone
path was to write a compiler front end that takes VAX MACRO syntax and
generates expanded intermediate language (EIL) for the GEM compiler back
end.  GEM then generates the Alpha code and writes it into an object file.
This work was done circa 1990.  The name "VAX MACRO" was used for this
compiler as well as for the previous assembler.


> When Compaq started the port to Itanium, they employed the same
> technique; this was maintained by HP.
>
> No further work needed to be done in the VAX MACRO compiler front end to
support Itanium.  All that needed to be done was to add Itanium code
generation capability to the GEM back end.  After that all GEM-based
compilers acquired Itanium code generation capability.  That is the big
advantage of having a common back end for all compilers.  Over its lifetime
GEM could generate object files for the MIPS, Alpha, and IA-32 machine
architectures and for the VMS, Ultrix, OSF-1, and Windows operating
systems.

VSI has shifted to using LLVM as their compiler backend for the x86_64
> port, with ELF as the executable file format (and presumably for
> object files as well).  As I understand the current state of affairs,
> there is a GEM to LLVM layer that interfaces between the still-GEM
> output of compiler frontends and the LLVM backend, that performs
> native code generation.  Macro, in particular, bypasses most of the
> LLVM optimization layer.
>
> VAX MACRO also bypassed most of GEM's optimization layer as well.  And
yes, most (if not all) of the legacy OpenVMS compilers use a GEM-to-LLVM IL
translator.  VSI has more than enough on their plate without taking on a
wholesale rewrite of the IL generators in the compiler front ends.

-Paul W.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240714/0f39fa4f/attachment-0001.htm>