[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-28 15:42:44 +0000, John Reagan said:

> On Monday, July 27, 2020 at 5:55:52 PM UTC-4, Stephen Hoffman wrote:
> 
>> The 32-bit API limits and the 32-bit compiler limits are among the 
>> impediment on the path to 64-bit apps.  Linker work or linker testing, 
>> as that's involved with building 64-bit apps.
> 
> There aren't really that many compiler limits.  The one that keeps 
> coming up is the size of the largest single variable (size_t).  Given 
> VMS continues to keep the stack in P1 (which is shared with DCL, RMS 
> buffers, and the like), the size of any single variable is less than 
> 1GB.  Until something changes there, there is no real benefit in the 
> compiler trying to subtract 16GB from the stack pointer to allocate a 
> large local variable.  It will never work.

_malloc64, _strdup64, etc, all 32-bit limited?

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

The CPU is certainly capable of this, yes. I've never stated that the 
Alpha and Itanium processors were not 64-bit. They are.

But until we've expunged all discussions of P0, P1, and P2, OpenVMS has 
segmented addressing.

> It is the APIs that drag you down.  Descriptors and itemlists for the 
> most part.  RMS data structures have some limits as well.

Twas seemingly the expectation that existing app dependencies won't be 
updated, and the double-edged sword that is compatibility, but that's 
probably just splitting, um, heritage.

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

One of various examples.

The 32-bit hole goes much deeper, as you well know.

And as I've been grumbling.

I'm not looking for a 64-bit version of Macro32. I doubt anybody is.

And as an aside, it'd be interesting to learn how much new Macro32 code 
is around, and how much of that is more than just glue code. And what 
can be done to remove the need for glue, whether API changes, or 
platform-native assembler, or C asm() calls or built-ins, or other 
changes.

Watching a vendor focus on making their platform easier to develop for 
has been an interesting experience, too. Without intending to cast 
aspersions toward any of the excellent folks involved, it's been a 
while since simplifications and enhancements for developers were a 
central focus for OpenVMS. Hopefully VSI gets the cycles for some of 
that, in the post-port future.

And no, please, no Balmer moments here, thank you. 
https://www.youtube.com/watch?v=SaVTHG-Ev4k



-- 
Pure Personal Opinion | HoffmanLabs LLC