<div dir="ltr"><div dir="ltr">On Sat, Jul 13, 2024 at 4:00 PM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is conflating two different things over the life of the MACRO-32<br>
language.  It certainly started out as a macro assembler, but with the<br>
introduction of the Alpha, DEC turned it into a true compiler (where<br>
the source language happens to be VAX assembly language) that<br>
generated native code for whatever machine it was compiled for: VAX or<br>
Alpha; using the GEM backends.<br>
<br></blockquote><div>The confusion arises because the name VAX MACRO was used for two completely independent and very different software tools.</div><div><br></div><div>The first VAX MACRO was the conventional assembler for VAX/VMS, developed in the mid-1970s.  It had conventional macroinstruction capabilities, hence the name.</div><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When Compaq started the port to Itanium, they employed the same<br>
technique; this was maintained by HP.<br>
<br></blockquote><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
VSI has shifted to using LLVM as their compiler backend for the x86_64<br>
port, with ELF as the executable file format (and presumably for<br>
object files as well).  As I understand the current state of affairs,<br>
there is a GEM to LLVM layer that interfaces between the still-GEM<br>
output of compiler frontends and the LLVM backend, that performs<br>
native code generation.  Macro, in particular, bypasses most of the<br>
LLVM optimization layer.<br>
<br></blockquote><div>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.<br></div><div> </div><div>-Paul W.<br></div></div></div>