[Info-vax] OpenVMS.Org quick pool

[John E. Malmberg]

On 8/17/2012 10:31 AM, Keith Parris wrote:
>
> I'm not privy to any plans, but thinking in terms of what's technically
> possible: Consider what you would have it you took the Ski Itanium CPU
> emulator (which lacks emulation of any platform hardware) and added
> enough code from HP VM to provide a platform environment which looks
> just like HP VM to the VMS instance inside (with the HP VM code adjusted
> for endian-ness, and to run on Linux instead of HP-UX). No changes would
> be required in OpenVMS I64 code for it to run inside such an environment.

The Ski emulator would only be needed if the HP VM was not running on 
Itanium.  And the HP VM would not still not provide what was needed. 
The SKI emulator would have to be further enhanced.  Based on the 
description on the project page, the SKI emulator appears to be only 
emulating the user mode instructions, not the stuff needed for the VMS 
kernel to run.  That would be way too much work.

There is a simpler (relatively) way:

The first step for this hack would be to get the SKI Emulator running on 
Alpha/VMS so that you could have it load up and run an IA64 VMS ELF 
image, and configure it to call VMS/ALPHA library routines and system 
services instead of trying to make Linux routine calls as it does now 
according to the documentation.

Once you got that working, you could then hack the VMS image activator 
to launch that emulator when you tried to run that type of an image 
instead of running your own launcher.

While at this point, you might think it was a waste of time to do this 
because you end up with something slower than the original, read on.

After all, what is available for VMS on Itanium that is not also 
available for VMS on Alpha?

You then either do what is needed to stabilize an open source Alpha 
Emulator like the ES40 so that it can run VMS reliably if that is needed 
for it, or partner with one or more of the commercial Alpha emulators, 
because you need a way to break out of emulation and call native code.

There you make the change so that the an emulated Alpha program can call 
routines compiled in the native x86-64 instruction set.  This is 
something like a CMX86 trap.  The emulator would then run the user-mode 
code as native.  You would need to have a way for the x86-64 code to 
call VMS/Alpha library routines and system services, just like above.

But now you have binaries running at the native x86-64 speed except when 
making library calls.

Now the literature for some of the advanced emulators are caching some 
translated Alpha/VAX code with native code to get the speed up, so 
commonly used sections of VMS would be effectively running in x86 mode.

Now if you still need Itanium compatibility, you compile the previously 
ported SKI emulator to be native x86.  Now you have a x86 VMS emulator 
that can run Alpha, IA64, and native X86-64 all at the same time.

It is possible that the emulator vendors could each come up with their 
own method of running user built x86-64 code, but that would require 
software vendors that wanted that speed boost to compile on all the 
different emulator platforms.  From the ISV point of view, it would be 
better if someone worked out a common interface and building 
instructions for this.

If you do not need to support Itanium/VMS binaries, then you can skip 
that part and still have Alpha/VMS + x86-64/VMS binaries running on the 
same hardware.

And HP could use this to gradually supply parts of Alpha/VMS that also 
came with precompiled x86-64 binaries.

This gives you both backward binary compatibility and the ability to 
take advantage of newer x86-64 processors.

Another component that is needed for the emulators is paravirtualized 
drivers.  These would be custom device drivers that would use that 
"CMX86" trap to turn the actual I/O processing to the emulator host 
instead of having to have the emulator spend cycles emulating the actual 
I/O hardware.

Regards,
-John
wb8tyw at qsl.network
Personal Opinion Only