[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-29 06:03:00 +0000, John Dallman said:

> Nowadays, 4GB is far too restrictive, so confining ourselves to P0 
> would be impractical...
> 
> Can anyone point me to documentation about how malloc32 and malloc64 
> relate to P0, P1 and P2?

Not what's really necessary, IMNSHO. Not in any one spot. Closest is 
the Guide to 64-bit Addressing manual, and the OpenVMS Programming 
Concepts manual.

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.

The OpenVMS system and product APIs are a mix of 32-bit, 64-bit, and 
either-bit interfaces.

Above ignores that existing OpenVMS virtual addresses are limited to 50 
bits significant. Looking ahead, x86-64 is either 48- or 54-bit 
virtual, addressing depending on whether the particular x86-64 
processor and operating system supports four-level or five-level page 
tables. VSI hasn't indicated which they're supporting.


-- 
Pure Personal Opinion | HoffmanLabs LLC