[Info-vax] VAX VMS going forward

[Arne Vajhøj]

On 7/27/2020 8:47 AM, Simon Clubley wrote:
> On 2020-07-24, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2020-07-24 18:51:20 +0000, John Reagan said:
>>> I've been trying to follow this whole conversation but I might have
>>> missed something.
>>>
>>> I don't get this whole hybrid thing.  VMS has a 64-bit flat virtual
>>> address layout.
>>>
>>> It is just that only parts of it can be accessed with a 32-bit pointer.
>>>   The rest requires a 64-bit pointer.  Due to things like descriptors
>>> and itemlists which have a builtin assumption about only holding 32-bit
>>> pointers, we go out of our way to make sure that anything that you can
>>> take the address of resides in 32-bit space.   On Alpha, Itanium very
>>> little S2 is used and no P2 without explicit code or linker qualifiers
>>> to do so.  x86 will get code in P2 (and trampolines in 32-bit space so
>>> you can still take their address).
>>
>> Tried building a 64-bit app without having to contend with 32-bit
>> giblets including the 32-bit APIs, the 64-bit APIs, and the either-bit
>> APIs, and the switch qualifiers to get everything to 64-bit, and the
>> stuff that isn't yet 64-bit?
> 
> John, this is why the current setup is not a flat 64-bit implementation
> but is a hybrid of 32-bit and 64-bit modes.

It is not a 32 mode and a 64 bit mode.

The CPU always use 64 bit addresses.

A program is not running in any mode.

It is API's that can use either 64 bit addresses or 32 bit "compressed"
addresses (by only passing the lower part and assuming high bits
are all 0).

In many ways that is way harder to fix than 32 and 64 bit mode.

> The current 64-bit memory model on VMS reminds me somewhat of the old
> segmented memory models that used to exist under MS-DOS before the flat
> 32-bit address space came into use on the x86.

Not close.

That was a CPU feature/problem.

This is an API feature/problem.

Arne