[Info-vax] VAX VMS going forward

[John Reagan]

On Wednesday, July 29, 2020 at 4:15:01 PM UTC-4, John Dallman wrote:
> In article <rfs4pg$mgo$1 at dont-email.me>, seaohveh at hoffmanlabs.invalid
> (Stephen Hoffman) wrote:
> 
> > OpenVMS app code lives in P0 30-bit space, and stack and data lives 
> > in P1 30-bit space, and app data can live in P0, or in P1, or in P2 
> > 62-bit user space.
> > 
> > P0 and P1 space are directly hauled over from OpenVMS VAX. Together 
> > P0 and P1 comprise the lower half of 32-bit space.
> > 
> > P2 space arrived with OpenVMS Alpha V7.0. P2 is the lower half of 
> > 64-bit space, less P0 and P1 space.
> > 
> > Basically, 30-bit apps with 62-bit data are feasible. An app built 
> > without regard to P0 and P1 really isn't. And an app necessarily 
> > with more than 30 bits of executable code is... interesting.
> 
> Can one build a program where pointers to data are /always/ 64-bit? Since
> I'd be porting code that is expecting uniform memory addressing, rather
> than dealing with different realms of data, that would make life much
> simpler.
> 
> However, that gives me the problem that I can only call functions that
> take 64-bit pointers. Is the standard C library all set up for that? How
> about the threading functions? Those categories are all I need. 
> 
> John

The linker simply won't put static data in a memory region that needs a 64-bit pointer to access it.  Of course, you are welcome to create-and-map-section-64 into 64-bit space and access it as you see fit. 

Since the calling conventions have 64-bit wide slots, almost all routines simply trust that the address in those incoming as valid.  Since the hardware all requires 64-bit addresses anyway, you normally don't see chopping of extra bits.  There are some C options to "clean" such incoming arguments if you want to make them conform exactly to the code.

BLISS-32 is an exception.  It will only grab the bottom 32-bits of the argument slot and sign-extend it before using it.  That's normal BLISS-32 behavior for any other location and arguments aren't really special in that way.

The CRTL Reference Manual does list a few routines that have 32-bit address assumptions baked into them (routines that take an address and write the result to where that address points).  There are only a few.  Most work just fine with all addresses.