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

[John Reagan]

On Tuesday, February 4, 2014 1:28:35 PM UTC-5, JF Mezei wrote:

> 
> Since there are already compilers for x86-64, wouldn't it be simpler to
> just adapt an existing one to support VMS ? Or does the need for Bliss
> and Macro-32 require a x86-64 version of GEM, and once you have that,
> you might as well use the existing compilers that run on VMS ?
> 
I did mention that another approach would be write some GEM-to-(gcc/LLVM/open64) converter and use that.  The "problem" is that those code generators probably just support the base AMD64 ABI, ELF and DWARF.  Any additional OpenVMS support needed would then have to be added.  For example, we had to adapt the Intel backed used in the C++ Itanium compiler to match the OpenVMS requirements.  Not sure which would be more work without a study.

Again, Macro-32 is unique in that it interfaces into GEM at a lower level, but since the other backends have things like "_asm" support, I would expect that something could be hacked together.
> 
> 
> In the case of a C compiler available for both Windows and Linux on x86,
> are the object files that are outputted identical and the linker is the
> one that makes the OS specific executables, or would the object files be
> fo different format ?

Windows and Linux have different calling standards, different object file formats, and different executable formats.  Even for x86-64, Windows picked a different calling standard than the AMD64 ABI.  All the other X86-64 OSs that I know about used the AMD64 ABI.