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

[Stephen Hoffman]

On 2014-02-04 19:22:01 +0000, John Reagan said:

> 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.

Without a study, and without some more general project-level guidance 
toward the longer-term goals of the effort — llvm is quite modular, and 
that can be exceedingly useful for tools and integration that just 
isn't available on OpenVMS right now.  gcc is now progressing down a 
similar and more modular path, too.  Why project-level guidance?  If 
you're looking to get stuff out the door that's stable and works and 
preferably quickly, then tweaking the existing stuff can be, well, 
expedient.  Longer term, moving toward the llvm modular architecture 
might be preferable.  The ability to continuously compile in an editor 
— what Xcode is doing with llvm — is quite useful, and it's the sort of 
thing that is just not as effective with GEM and its static compiler 
diagnostic file approach.

That's the fun thing about an OS.  There are always trade-offs in any 
approach, and there's always far more stuff to work on that somebody 
_really_ needs than there's available staff.  Like any large software 
project, an OS development effort will usually expand to occupy all 
available staff, and to consume all available budget.

> 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.

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.

>> 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.

As mentioned, OpenVMS used ELF and DWARF, with a few extensions that 
provided support for capabilities that existing OpenVMS applications 
expected.

This <http://h71000.www7.hp.com/doc/82final/6673/6673pro_003.html> stuff:

> The object file format conforms to the 64-bit version of the executable 
> and linkable format (ELF), as described in the System V Application 
> Binary Interface draft of 24 April 2001. This document, published by 
> Caldera, is available on their web site at:
> http://www.caldera.com/developers/gabi
> The object file format also conforms to the I64 specific extensions 
> described in the Intel® Itanium® Processor-specific Application Binary 
> Interface (ABI), May 2001 edition (document number 245270-003). 
> 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.

As with Itanium before it, this entirely hypothetical port to x86-64 
will probably need some similar ABI-level tweaks.

FWIW and IIRC, HP had indicated that there were plans to port more 
compilers over to a different (non-GEM) compiler back-end back during 
the initial availability of OpenVMS on Itanium, though those compiler 
migrations obviously didn't happen.

-- 
Pure Personal Opinion | HoffmanLabs LLC