[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-24 12:38:04 +0000, Simon Clubley said:

> On 2020-07-23, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2020-07-23 17:38:33 +0000, Simon Clubley said:
>>> P1 space would also be right in the way of a flat 64-bit addressing 
>>> mode so all the code which uses P1 space would have to be rewritten to 
>>> support flat 64-bit addresses because P1 space would have to be moved 
>>> well out of the way.
>> 
>> P0 and P1 space and S0 and S1 space are for VAX compatibility within 
>> apps and app source code.
> 
> P1 space is a little more than that. :-)

I disagree.

> It's where DCL and the associated data structures live.

Yes. Which is a design holdover from VAX virtual memory addressing, and 
the longstanding OpenVMS fondness for using user-mode rundown as a 
cleanup mechanism.

If flat 64-bit addressing were designed to "park" DCL and control 
structures at some designated offset circa 2^63-1 for instance, off we 
go. That's approximately the VAX design, address-extended. Or park a 
64-bit (~P2) pointer in the 64-bit system space ~S2 PCB or PHB for that 
matter, and use that to find the formerly-P1 DCL data.

> How much work would be involved in moving what is currently in P1 space 
> to somewhere up the 64-bit memory map to just below where the kernel is 
> mapped ?

That's little different than what would necessarily happen with P0, S0, 
and S1 space contents, to move to flat addressing.

> For one example, how much of the P1 code and data structures are still 
> 32-bit only ?

DCL is comparatively less concerning than all the 32-bit apps that are 
dependencies, as DCL can be fixed.

> That would mean as well that you would have P1 data cells with 
> different locations on the system depending on whether you are running 
> in 32-bit or 64-bit mode.

That's at the core of having processes with 32-/64-bit hybrid running 
alongside processes using flat 64-bit, for the duration of the 
transition.

The system-space address windows lurking in P1 space would need to be 
addressed, too.

> There's also the question of whether flat 64-bit addresses are a 
> process level attribute or an image level attribute. Think about what 
> that means for P1 space as well as for mixing 32-bit and 64-bit 
> applications in the same process space.

It's necessarily both process space and executable code supporting 
64-bit while running 64-bit process space.

Also the compilers, and the libraries, and the linker, and third-party 
apps. Etc.

There's a reason the 32-/64-bit design was chosen.

Superseding the V7.0 32-/64-bit hybrid design would be no small effort. 
And I don't foresee work toward flat 64-bit addressing happening at VSI 
any time soon, either.


-- 
Pure Personal Opinion | HoffmanLabs LLC