[Info-vax] VAX VMS going forward

[johnwallace4 at yahoo.co.uk]

On Friday, 24 July 2020 13:38:08 UTC+1, Simon Clubley  wrote:
> 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. :-)
> 
> It's where DCL and the associated data structures live.
> 
> 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 ?
> 
> For one example, how much of the P1 code and data structures are still
> 32-bit only ?
> 
> 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.
> 
> 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.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I wonder if any other software has ever had to cope with the 
migration from 32bit-pointer to 64-bit pointer, and whether any parallels 
and learnings might be findable or even relevant.

Meanwhile, have a look at this:
http://www2.phys.canterbury.ac.nz/dept/docs/manuals/unix/DEC_5.0a_Docs/HTML/ARH9VBTE/PNTRPPXX.HTM

Without giving too much away, it describes how a 64bit-pointer UNIX 
managed (sort of) to support 32bit-pointer source and applications.

Obviously UNIX isn't VMS.