[TUHS] history of virtual address space

[Paul Winalski via TUHS]

On Tue, Jan 20, 2026 at 1:24 PM John R Levine <johnl at taugh.com> wrote:

> > On Mon, Jan 19, 2026 at 9:22 PM John Levine via TUHS <tuhs at tuhs.org>
> wrote:
> >
> >>
> >>> Later we got the "kernel is high virtual with bit 31 set" -- when did
> that
> >>> first happen?
> >>
> >> That's how VAX addressing worked.  User programs were in the low half
> >> of the address space, the kernel in the high half.
> >>
> >
> > It has nothing to do with how the VAX implements virtual addressing per
> > se.  ...
>
> The 1981 VAX Architecture Handbook that I have in my hand disagrees with
> you.  The Memory Management chapter says that the top half of the address
> space is the System (S) while the bottom half is Process.  Process is
> further divided into P0 which grows up from 0 and P1 which grows down from
> the middle.  There is one S page table which is in real memory.  The P0
> and P1 page tables are in S address space, giving the effect of two-level
> page tables.  Each page table is logically contiguous, with a base and
> length register for each.
>
> The a.out program layout is the only one that makes sense on a Vax, code
> starts at zero, stack grows down from 2GB.
>
> I am very familiar with the 1981 VAX Architecture Handbook.  It is a
somewhat misleading document in that it is describing both how the VAX
hardware works (this is what I would call the "VAX Architecture") but also
the Application Binary Interface (ABI) of the VAX/VMS operating system.
Remember that at the time DEC was adopting a "one architecture, one
operating system" approach on VAX.  They were trying to intimately link VAX
(the hardware architecture) and VMS (the operating system) in the minds of
both DEC's own engineers and their customers.

The Memory Management chapter is describing the memory layout of a VAX/VMS
process.  If you look at the hardware architecture side of things, you will
see that there is absolutely no requirement or constraint at the hardware
level to have all of the virtual addresses with the high bit on be reserved
to the OS and those with the high bit off to user space.  Each page table
entry has its own protection bits that describe the read and write
permissions for each execution mode (user/supervisor/executive/kernel).

Bottom line is, back in the early days of VAX, when DEC referred to "VAX
Architecture" they meant both the hardware architecture of VAX and the OS
architecture of VMS.  Contrast this with "PDP-11 Architecture", which meant
only the hardware design, not the veritable zoo of operating systems that
ran on the PDP-11, each of which had its own peculiarities regarding memory
addressing.

One could have, if one wanted, done the opposite and put user address space
in the address range with the high bit on and the kernel address space in
the low part of the address space.  It would be fully conformant with the
VAX page table layout and supported by all then-extant (11/780/750/730) and
future VAXen.  Unix chose to follow the VMS design (as documented in the
VAX Architecture Manual) pretty much because there was no reason not to.

-Paul W.