[Info-vax] VAX VMS going forward

[Simon Clubley]

On 2020-07-24, johnwallace4 at yahoo.co.uk <johnwallace4 at yahoo.co.uk> wrote:
> 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.
>> 
>
> 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.
>

Yes, Unix has indeed been through this and because of the Unix design
(and the choice of C as the lowest-level supported language instead of
assembly language) it was far less painful than implementing a flat
64-bit address space in VMS (to go alongside the current 32-bit/64-bit
addressing hybrid that VMS has) would be.

> 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.
>

Yes, these are all standard issues (although storing pointers in ints
is something that hasn't been done in the Unix world for a generation
and even then you had support in the C language to avoid this).

That actually highlights one of the many issues in moving to a flat
64-bit mode in VMS when compared to Unix and why it is far easier to
move C code from 32-bit to 64-bit mode than it is to do the same with
Macro-32.

Consider the following line of C code in some data structure somewhere:

	unsigned char *ptr;

In C, the size of the pointer is an implementation detail that you
don't have to worry about in your C code. You don't care if it's
4 bytes (for 32-bit mode) or 8 bytes (for 64-bit mode) and you
don't care about the underlying ABI that makes these decisions
for you because it simply doesn't matter to your code.

Similar comments apply to other parts of C and calling functions (for example).

Now compare that to what the code in Macro-32 would look like.

This kind of stuff is abstracted away for you in C and (mostly)
in the Unix APIs in a way that simply isn't possible in Macro-32.

> Obviously UNIX isn't VMS.

No it isn't. And one other difference is that every program run
in a Unix environment gets it's own private process which is then
terminated when the program exits. It doesn't really matter if
the program is running in 32-bit mode or 64-bit mode as far as
the shell is concerned.

However, in VMS, DCL shares the same process as the programs
it runs and P1 space is currently right in the middle of where
the flat 64-bit address space would be for user programs.

So, how do you handle running both flat 32-bit programs and
flat 64-bit programs within the same process space as DCL ?

Do you declare that you are only running either flat 32-bit or
flat 64-bit programs exclusively when you login or is the
flat 32-bit or flat 64-bit image type exclusively some kind of
an image attribute and you can run both during the same DCL session ?

In that case, how do you keep P1 space at its current location
for flat 32-bit applications but then move it out of the way when
you want to run a flat 64-bit application ?

These are the types of issues you don't have to deal with in Unix
because of the Unix design.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.