[Info-vax] VAX VMS going forward

[John Reagan]

On Monday, July 27, 2020 at 5:55:52 PM UTC-4, Stephen Hoffman wrote:
> On 2020-07-27 13:20:28 +0000, John Reagan said:
> 
> > On Monday, July 27, 2020 at 8:47:36 AM UTC-4, Simon Clubley wrote:
> >> On 2020-07-24, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> >>> 
> >>> 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.
> >> 
> >> 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.
> > 
> > As I said, it is a flat 64-bit address space. There is no "mode".  We 
> > just decide to load the stack, the static data, and code into addresses 
> > that can fit in 32-bits because of the history of descriptors and 
> > itemlists with 32-bit pointers in them.  It is part of the "recompile 
> > and go" we promised back on the VAX days.  We require that anybody 
> > wanting to use memory that needs a 64-bit pointer to modify their 
> > compile command or source files. However, you can't move the stack or 
> > static data.  You just get to heap allocate or mapsection into those 
> > memory ranges.  And as I mentioned, for x86, we move your code there to 
> > leave more 32-bit room for stack and 32-bit addressable heap.
> 
> I'm happy to be corrected here, but AFAIK there are no 64-bit apps on 
> OpenVMS. None. There are 32-bit (~30-bit) apps with 64-bit (50-bit?) 
> extended, or segmented, or, sure, maybe flat, addressing available. But 
> there are no 64-bit apps.
> 

All code on Alpha, Itanium, and x86 will execute properly in any address
location from any compiler by default.  [Itanium C++ is the exception as it
has an incorrect assumption that the size of the PC is the same size as the
C++/POINTER_SIZE qualiflier.]

Our move of code from P0 to P2 on x86 is most of a symbolic change than a
solving a problem.  On Alpha/Itanium, P0 is (code, heap, static data).
When an program runs out of P0 heap, the choices are to start using P2
heap or move something else out of P0.  Ironically, the Itanium C++ compiler
itself often runs out of P0 space.  The actual code in the compiler is probably 50MB give or take so it isn't much.


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

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