14 Jul
2024
14 Jul
'24
10:16 p.m.
On Sat, Jul 13, 2024 at 4:00 PM Dan Cross <crossd(a)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.