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

[John Reagan]

On Monday, February 3, 2014 8:58:57 PM UTC-5, David Froble wrote:

> 
> As you have possibly been 
> very involved in the VMS compilers, Macro-32 and Pascal I'm pretty sure, 
> and possibly others,

Possibly yes.

 
> 
> I'm figuring the front ends of the compilers would need little to no 
> change, since we're not talking about changing the languages.  It's the 
> back end, GEM, that would have to take whatever the front ends produced 
> and produce something that would run on x86.
> 

To recap more (I think I've said as much over the past few years):

The frontends didn't need many changes from Alpha to Itanium as they pretty much figured it out from VAX to Alpha.  Some frontends, like Pascal, have common sources for all three architectures (VAX, Alpha, Itanium).  Others like BASIC, C and COBOL have VAX vs Alpha/Itanium.  Fortran has several due to the F77/F90 transition along the way. 

As mentioned, GEM did have a x86-32 bit target that didn't support the complete intermediate language.  You'd have to finish all of that work, teach it about 64-bit registers & instructions, make it generate ELF/DWARF, don't forget cross-compilers, taking some existing Calling Standard and extending it to handle OpenVMS conventions (the AMD64 ABI would be a good start but needs more), etc.

Or you could write some GEM IL converter for another code generator, but most of the other ones available (gcc, LLVM, open64) might need work as well for some of the language extensions.

And not just compilers, other compiler toolchain tools (linker, librarian).  The Alpha to Itanium was hard on the linker/librarian with the change of object and image formats to ELF.  A port to another ELF platform would potentially be easier.

Then consider all the work in the OS that is target sensitive.  SWIS, exception handling, all the LIB$ calling standard routines, debuggers, etc.

And I won't get started again on Macro-32 register conventions and how to make that all work as-is and support all those register linkages between Macro-32, BLISS, and C.  The register mapping that was strange enough Itanium seems simple to what you might need for x86-64.

oh, and you want binary translation too?

The compilers aren't the "key" component.  Everything is the "key" component.