[Info-vax] VAX VMS going forward

[Arne Vajhøj]

On 7/28/2020 11:42 AM, John Reagan wrote:
> On Monday, July 27, 2020 at 5:55:52 PM UTC-4, Stephen Hoffman wrote:
>> Getting a flat address space and getting rid of the mumble() and
>> mumble64() and 64-bit objects is no small development project, and
>> that's past the remediations for the forever-32-bit-app dependencies
>> that lurk.
> 
> The address space is flat.  The CPU ensures that.  There are no segment
> registers on Alpha, Itanium, and x86 (in its 64-bit hardware mode).
> 
> It is the APIs that drag you down.  Descriptors and itemlists for the most
> part.  RMS data structures have some limits as well.
> 
> And it really all goes back to the Macro-32 code with a PUSHL or PUSHAB.
> They are 32-bit operations.   And while you might think you can slip in
> a 64-bit SP value, you hit the wall the moment you see code that attempts
> to build a descriptor with a PUSHAB -4(FP) PUSHAB n(SP).

I guess there are 3 ways to go from 32 to 64 bit:

1) Let the CPU have a 32 and 64 bit mode and have 32 and 64 bit
    programs co-exist.

2) Only 64 bit mode and change all API's to use 64 bit
    addresses/pointers.

3) Only 64 bit mode and keep existing API's with 32 bit
    "compressed" addresses/pointers and add new API's with 64 bit
    addresses/pointers.

AMD chose to support 32 and 64 bit mode, so Windows,
Linux etc. use #1 on x86-64.

DEC chose not to support VAX ISA on Alpha, so #1 was not
an option.

That left #2 and #3.

DEC picked #3. It is rather unique, but given the business
situation back in the early 1990's then it probably made sense.

But the result is not pretty.

Arne