[Info-vax] VAX VMS going forward

[Arne Vajhøj]

On 7/28/2020 1:19 PM, Arne Vajhøj wrote:
> 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.

And to quote myself from last time this was discussed:

#I was not there, so I can't say why.
#
#My guesses would be that the reasons include:
#* big changes in libraries required
#* big changes in compilers reqyured
#* problems in Macro-32 applications where MOVL could be data or a pointer
#* problems with VEST (if it is difficult to distinguish between
#  data and pointer in Macro-32 then it is even worse in binary
#  translation)
#* memory usage - early Alphas came with just 128/256/512 MB of RAM so
#  memory could be tight and changing pointers from 32 to 64 bit can
#  increase memory usage significant for some applications

Arne