[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-28 17:19:53 +0000, Arne Vajhj said:

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

In the OpenVMS hybrid segmented addressing—OpenVMS hybrid addressing, 
not Alpha addressing—the addresses are truncated and are sign-extended.

OpenVMS itself was 32-bit sign extended prior to V7.0, and then opened 
up some app access to 64-bit addressing with V7.0.

As for your list:

4) Allow 32-bit apps to run in parallel and in separate processes, with 
developer and 64-bit API work toward 64-bit apps pending retirement of 
the 32-bit APIs and apps, and allowing a transition to 64-bit apps to 
happen over a decade or more, and which makes this 64-bit app 
transition more incremental and thus somewhat less disruptive.

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

This isn't about the processor architecture, this is about the 
operating system and developer abstractions for the architecture.

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

This is muddled.  I'm here discussing OpenVMS prior to V7.0, and 
OpenVMS V7.0 and later. Not Alpha addressing. Tru64 Unix went with a 
flat 64-bit address space, too. Much cleaner, for those that have 
worked on Tru64 Unix, too. Alpha has always been able to provide that 
addressing, too.

BTW. Intel tried that old-instruction-set stuff with Itanium.  That was 
slow and limited, and the issues with that were _very_ popular with the 
press at the time. I have stories, there.  But I digress.

Again, this isn't about instruction sets. Or the processor 
architecture. This is about programming on OpenVMS. Go try writing a 
64-bit app on OpenVMS, without having it be a 32-bit app with 64-bit 
data. You won't be able to.

The mess here isn't with the processor architecture—not that x86-64 
isn't a mess, and not that Itanium isn't epically weird—it's about the 
OpenVMS software APIs and software abstractions, and particularly those 
with OpenVMS V7.0 and later.

It's about the necessity to use and to consider software segmented 
addressing; of needing to be aware of P0, P1, and P2 space when 
developing, as the OpenVMS APIs and tools have differing expectations 
and limits here. Of segmenting.

The OpenVMS V7.0 design works great for existing apps.  Spectacularly 
clever, even.  That same design constrains app overhauls and new app 
work from fully adopting 64-bit, and the design makes source code 
development and APIs that much more complex.

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

Compatibility has its costs. OpenVMS 64-bit addressing support is an example.




-- 
Pure Personal Opinion | HoffmanLabs LLC