[Info-vax] Reimplementing VMS, was: Re: HP adds OpenVMS Mature Product Support beyond the end of Standard Support

[John Reagan]

On Wednesday, February 5, 2014 9:22:45 AM UTC-5, Stephen Hoffman wrote:

> 
> Probably a minimal need to hack this, as there's already an x86-64 
> assembler via llvm: <http://llvm.org/docs/CommandGuide/llvm-as.html>.  
> Somebody would end up writing or porting a front end for Macro32, 
> obviously.  This if getting GEM to work isn't the chosen approach.
> 
That isn't an X86-64 assembler.  That is a LLVM intermediate language assembler.  It lets a compiler developer write prototype IR without having to have a full frontend in place.  GEM has the same thing called OPAL.  The GEM dumpers will even format their output as OPAL so you can then work from that without having to keep modifying/rebuiding a frontend.

The issue with Macro-32 (or any assembler that wants to use the IR of a backend) is the cross-jumping from routine to routine (enter via one .ENTRY and leave via another routine's RET or RET'ing from a JSB routine).  Such concepts usually aren't representable at the high-level.  That is why Macro-32 interfaces into GEM at a much lower level (and has to tons of work itself that other frontends don't have to).  Plus creating efficient emulation of VAX condition codes would be tough for GEM (or any backend).


> 
> > Extensions and restrictions, necessary to support object file and image 
> > file features that are specific to the OpenVMS operating system, will 
> > be published in a future release.
> 
> I don't recall if these extensions were ever generally published.
> 

Yes.  It is all in the Calling Standard Manual.  There is even an appendix listing the differences between the OpenVMS Calling Standard & ABI vs the Intel Itanium Runtime Conventions and ABI.  We added things like R25 as arginfo (count and translated flags) and new relocations into the ABI.