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

[Stephen Hoffman]

On 2014-02-04 01:58:57 +0000, David Froble said:

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

The major choices are to rework the parsers on the existing compilers 
that already target x86-64, graft the existing front-end parser onto a 
new back-end, or rework the GEM back-end to add support for x86-64 and 
whatever other extensions might be deemed appropriate.  (For instance, 
I'd probably just expect to have all of the current-generation 
capabilities available within the current or near-term x86-64 server 
processors, and wouldn't try to provide subset support for older 
processors.)

Source-to-source translation would probably break cross-architecture 
source code compatibility if the changes required were significant, 
though having some sort of a source code scanner would be handy for 
folks porting code.

The other big part of the work involved is an overhauled or wholly new 
linker, the debugger, ANALYZE /IMAGE, ANALYZE /OBJECT, process dump 
support, the image activator, the SET IMAGE command, the librarian, and 
a few other hunks that know about objects and images.

Any applications that directly generate executable code will be effected, too.

Probably also the tools to emulate or to translate at least some of the 
existing binaries.

This is all after the calling standard and the rest of the 
architecture-specific implementation are worked out.   Like Itanium, 
anything using VAX floating point would be slow.

> I have no idea of just what such would entail.

It's probably a fairly large chunk of work for a small group of folks, 
as a complete guestimate.

> If it would not raise your blood pressure too much, is there any chance 
> that you could present some general ideas about feasibility, effort, 
> and such?

VMS chose to use existing GEM support of Itanium for most of the 
existing compilers, and migrated to the Intel C++ compiler.

Whether GEM was modified for Poulson, I don't know.  AFAIK, there 
haven't been any new compilers released.

I'd investigate use of LLVM here, as an alternative to maintaining the 
compiler chain.  That'll hit the debugger and a whole host of other 
hunks, though.

<http://www.hp.com/products1/evolution/alpha_retaintrust/download/openvms-i64-porting-whitepaper.pdf> 




-- 
Pure Personal Opinion | HoffmanLabs LLC