[Info-vax] VAX VMS going forward

[John Dallman]

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