[Info-vax] VAX Macro to C conversion

[John Reagan]

On Monday, July 8, 2019 at 11:12:43 PM UTC-4, Dave Froble wrote:
> On 7/8/2019 8:58 PM, Simon Clubley wrote:
> > On 2019-07-08, Michael Moroney <> wrote:
> >> seasoned_geek <> writes:
> >>
> >>> On Monday, June 24, 2019 at 7:39:07 AM UTC-5, Simon Clubley wrote:
> >>>>
> >>>> How much work would be involved in a rewrite of the shadowing code in C ?
> >>>>
> >>
> >>> Careful there. You are forgetting the C compiler is roughly 2 decades behind in
> >>> standards and capabilities.
> >>
> >> Out-of-date C compilers would be the least of the problems with such a
> >> rewrite.
> >
> > Yes, but if you were implementing something like this from scratch
> > these days, you would use C instead of Macro-32 simply because of
> > all the major advantages C brings you, even with an old compiler.
> >
> > And before all you Macro-32 lovers jump on me for that comment, :-)
> > remember that times change and for good reason.
> >
> > I understand why huge amounts of VMS were written in Macro-32 back
> > in the 1970s and why it was probably the correct choice for that era.
> >
> > It doesn't mean it's the right choice however if you were to do VMS
> > from scratch in the 21st century, or even if you were to do any new
> > significant additions to the existing VMS codebase.
> >
> > Simon.
> >
> 
> Macro-32 is an assembler on the VAX.  On Alpha, itanic, and x86 is is a 
> compiled language, and not anything you'd want to use on the non-VAX 
> systems.  Just ask John.  It exists strictly for existing code.
> 

I wouldn't say that.  The generated code from AMACRO and IMACRO is pretty reasonable.  You don't get things like "inlining", "loop unrolling", and other higher level optimizations, but the actual code for each VAX instruction is pretty good.  Currently for x86, I'd say I'm mostly pleased with the generated code but we have some ideas to improve it a little more before the 9.2 release.

[On Alpha/Itanium, we interface into GEM *BEFORE* the peephole optimizer.  On x86/LLVM, the assembler interface is after any scheduling and there is no equivalent peephole optimizer to help remove things like "jumps to jumps" so we'll have to do that ourselves.]