[Info-vax] VAX VMS going forward
John Reagan
xyzzy1959 at gmail.com
Fri Jul 24 14:51:20 EDT 2020
On Friday, July 24, 2020 at 1:54:39 PM UTC-4, Simon Clubley wrote:
> On 2020-07-24, johnwa... at yahoo.co.uk <johnwa... at yahoo.co.uk> wrote:
> > On Friday, 24 July 2020 13:38:08 UTC+1, Simon Clubley wrote:
> >> On 2020-07-23, Stephen Hoffman <seao... 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.
I've been trying to follow this whole conversation but I might have missed something.
I don't get this whole hybrid thing. VMS has a 64-bit flat virtual address layout.
It is just that only parts of it can be accessed with a 32-bit pointer. The rest requires a
64-bit pointer. Due to things like descriptors and itemlists which have a builtin assumption
about only holding 32-bit pointers, we go out of our way to make sure that anything that you
can take the address of resides in 32-bit space. On Alpha, Itanium very little S2 is used and no P2
without explicit code or linker qualifiers to do so. x86 will get code in P2 (and trampolines in 32-bit
space so you can still take their address).
Could DCL be moved? Well, anything could be moved with enough effort. As you very well know,
the Macro-32 code has to types and the sizes of data is not just a 'typedef' but essentially encoded
in every instruction. Want to promote a WORD field to a LONGWORD field, find and change EVERY
instruction that touches it. Same for LONGWORD to QUADWORD but that is even more interesting
with extensive use of condition codes.
And the stack in 32-bit space (since you might want to take the address of a stack variable to shove
in a descriptor or itemlist) can't easily be moved to 64-bit space.
As you pointed out, "pointers" in C provide an abstraction. Macro-32, descriptors, and itemlists do not.
Here's an image layout as displayed by DELTA on a running program on my VBox. You can see images
with sections in P0 (static data, trampolines, etc) and a section above 00000000.80000000 that have
code.
Image Name Base End Symbol-Vector Flags
DCL 00000000.7ADBA000 00000000.7AEBA51F S
DLOPEN2 00000000.00002000 00000000.0000402F M
00000000.80000000 00000000.80008000 M
DECC$SHR 00000000.00006000 00000000.00041DBF 00000000.0002C000
00000000.80088000 00000000.8056C000
DPML$SHR 00000000.00042000 00000000.0006A2EF 00000000.00062000 S
00000000.8058E000 00000000.8064A000 S
CMA$TIS_SHR 00000000.0006C000 00000000.000793AF 00000000.00078000 S
00000000.80650000 00000000.8065C000 S
LIBRTL 00000000.0007E000 00000000.000ABF0F 00000000.000A8000 S
00000000.80690000 00000000.8085E000 S
LIBOTS 00000000.0007A000 00000000.0007D50F 00000000.0007C000 S
00000000.80660000 00000000.80672000 S
FFFFFFFF.FFFFFFFF FFFFFFFF.FFFFFFFF FFFFFFFF.85E00000
FFFFFFFF.FFFFFFFF FFFFFFFF.FFFFFFFF FFFFFFFF.85E0CA00
DELTA 00000000.000AC000 00000000.000BA12F 00000000.000BA000
00000000.80874000 00000000.808F2000
P.S. I'm posting this via the new Google Groups site. Still has some rough edges.
More information about the Info-vax
mailing list