Re: base and bounds, Why I've Dropped In

On 6/15/2025 10:15 AM, John Levine wrote:

According to Thomas Koenig  <tkoenig@netcologne.de>:

The problem of the /360 was that they put their base registers in
user space.  The other machines made it invisible from user space
and added its contents to every memory access.  This does not take
up opcode space and allows swapping in and out of the whole process,
which was a much better solution for the early 1960s. (Actually, I
believe the UNIVAC had two, one for program and one for data).

 The PDP-6, which was designed around the same time as the 360, had
base and bounds relocation registers which indeed allowed swapping.
The follow-on KA10 had two, the low half of the address space for
private data and the high half for shared code. Later PDP-10s all had
paging.
 Base and bounds is OK, but I gather that the PDP-6 and KA10 spent
a lot of time shuffling memory to consolidate free space.  An
underappreciated advantage of paging is that you don't have to do
that, since one page frame is as good as another.

Yes, that is true.  While I don't like "tying" the inherently "program oriented" concepts of r/w/e, sharing permissions, etc. to the inherently "system" oriented concept of storage management, if you had to choose one, paging is clearly the best answer.
An interesting question is whether it is worthwhile to do both.  I gather the Mill is supposed to do that, and Unisys implemented paging transparently "under" its base and bound permission system.  It frees up the system to optimize page size for just memory management, but it seems to incur a penalty of requiring two "lookups", one for the permissions, the other to get the physical address.  But that idea certainly hasn't caught on.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)