[TUHS] history of virtual address space

[Paul Winalski via TUHS]

On Tue, Jan 20, 2026 at 10:45 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

>
> It has nothing to do with how the VAX implements virtual addressing per
> se.  It's more to do with the way that the various a.out formats for
> program images (OMAGIC, NMAGIC, ZMAGIC) all assume that program addressing
> starts at 0.  It offers the greatest convenience and flexibility if the
> parts of kernel address space that must be mapped into user process address
> space are at the high end of the address space, well out of the way of user
> code and data.
>
> I found and downloaded a copy of the 1981 VAX Architecture Handbook and it
turns out I was wrong about this.  The page table design for VAX defines
three ranges of virtual addresses:

System (S): bit 31 of virtual address on
Program 0 (P0):  bits 31 and 30 of virtual address off
Program 1 (P1):  bit 31 of virtual address off, bit 30 on

Each page table has a pair of hardware registers defining the base and
length of the page table (SBR/SLR, P0BR/P0LR, P1BR, P1LR).  The SBR address
is a physical address.  The P0BR and P1BR addresses are virtual addresses
in system (bit 31 on) space.

This design facilitates a virtual address layout where there is a single
system address range occupying high virtual memory and per-process P0 and
P1 regions.  P1 is intended to implement a stack that grows downwards from
virtual address 0x7fffffff.  P0 is intended to implement code and heap
space growing upwards from 0x00000000.  VAX/VMS set the protection on the
first page of memory to allow neither read nor write access to any of the
four protection modes, so that any attempt to use small integers in the
range 0-511 (decimal) caused a seg fault.  This caught countless
programming errors.

So the virtual address layout of early Unix on the VAX was indeed dictated
by the page table mechanism of the VAX hardware.  Thanks to John Levine for
correcting me on this.

-Paul W.