• Re: base registers, ancient OS history, ARM is sort of channeling the I

    From John Levine@21:1/5 to All on Sun Jun 30 17:09:02 2024
    According to Stephen Fuld <[email protected]d>:
    They would have fared better by assigning a base register (or two,
    one for data and one for code) invisible from problem state
    and handled by the OS.

    Precisely! This is what the, roughly contemporary, Univac 1108 did. It >worked will for several decades. ...

    So did the PDP-6 (one base register) and the original KA10 (two).
    Later PDP-10s added paging, I expect so that they could run Tenex
    which was way cooler than TOPS-10.

    Yes. John Levine said they thought that changing the, user visible,
    base registers would be doable :-(

    That's certainly the impression I got from reading the 1964
    Architecture article. The addressing design had two competing
    criteria: they needed to be able to address megabytes of RAM in large
    models, and the addresses in instructions had to be compact so code
    would fit on small models with 8K or 16K. So they provided 24 bit
    linear addresses, but all instructions used base registers with a 12
    bit offset. They say:

    [Committing to base registers everywhere] implies that all programs
    are location-independent, except for constants used to load the base
    registers. Thus, all programs can easily be relocated. This commitment
    also implies that the programming support effectively and efficiently
    handles the mechanics of base-register use. ...

    It's not clear whether they meant relocated when initially loaded, which
    worked fine, or relocated later, which did not.

    The invisible base registers may require an extra adder in the CPU when >computing addresses, but this is much less overhead than paging
    requires.

    It worked fine on the PDP-6 built out of transistors in 1963.

    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Levine on Mon Jul 1 05:35:54 2024
    On Sun, 30 Jun 2024 17:09:02 -0000 (UTC), John Levine wrote:

    Later PDP-10s added paging, I expect so that they could run Tenex ...

    The paging hardware was originally developed by BBN, as was TENEX.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Mon Jul 1 21:01:55 2024
    According to Lawrence D'Oliveiro <[email protected]d>:
    On Sun, 30 Jun 2024 17:09:02 -0000 (UTC), John Levine wrote:

    Later PDP-10s added paging, I expect so that they could run Tenex ...

    The paging hardware was originally developed by BBN, as was TENEX.

    I took a look at some of the PDP-10 stuff at bitsavers, and my copy
    of the DEC computer engineering book.

    The KA-10 pager that BBN built for Tenex was quite complicated, with
    hardware indirect page pointers, but only allowed the KA's usual 256K
    of physical memory..

    The pager for the KI-10 was considerably simpler but handled larger
    physical memory up to 4M words, They added a kludge so the monitor
    could execute intructions in user context to get at memory above 256K. Wikipedia says DEC later bought the rights to Tenex and adapted it
    to the KI's simpler pager.

    Someone from BBN came to DEC to work on the KL which had a more
    complex pager so the KL could run TOPS-20 which was Tenex with extra
    stuff like expanded memory addressing.

    So there is a line through the software from Tenex to TOPS-20 but it
    looks like the paging hardware was redone each time.

    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)