[Info-vax] VAX VMS going forward

[John Reagan]

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

> 
> > Every time I've tried creating a 64-bit app, I get a sad and revert to 
> > 32-bit with hunks of data up in P2 and/or S2.  At one point?haven't 
> > verified this limit lately?code wasn't permitted in some of the 
> > segments.
> >
> 
> I hope you are not having to copy the same data between P2 and P0 to use it.
> 

Can't speak directly for Steve, but copying back into 32-bit addressable
memory ranges exists at various places in the system.