[TUHS] Split addressing (I/D) space (inspired by the death of the python... thread)

Noel Chiappa jnc at mercury.lcs.mit.edu
Fri Aug 4 09:10:44 AEST 2023

    > From: Clem Cole

    > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill
    > Strecker that he could implement an 11 on a single"hex high" CPU board
    > if he got rid of the lights and switches. He ran out of room to
    > implement seperate I/D, so it became an 11/40 class [and it has an
    > 8008-1 that runs the front panel].

I don't know about the Strecker story, but the first PDP-11 CPU on a single
card (a hex card) was the KD11-D:


of the -11/04. It didn't have _any_ memory management, though (or a front
panel; to get that, you had to use the KY"11-LB:


which added another quad card). The first -11 CPU i) on a single card and
ii) with memory management was the FDF11-A:


The first -11 CPU i) on a single card and ii) with split I+D memory
management was the KDJ11-A.

    > It was not until 11/44 that DEC was able to make a hex height
    > implementation of the 11 that managed to cram a full 11/70 into that
    > system.

I'm not sure what your point is here? The KD11-Z CPU of the -11/44:


was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex
cards). Floating point was an extra card; CIS was 2 more. 

    > if you look at the link line of sys/run the 45 does not have -i

Split I+D for the kernel was not supported by the linker in V6; a combination
of 'sysfix' (a special post-processor, which took as input a relocatable
linked image) and code in m45.s was needed.


The code in m45.s to handle split I+D in the kernel:


starts at 'start:' and is adequately commented to tell you what it's doing
when it plays around with kernel memory.

    > From: Will Senn

    > with I/D, you can use 64k for I and 64k for D. Was that it, or were
    > there other tricks to get even more allocated

I have this vague memory that someone (Berkeley, I think?) added support for
automatic code overlays in user processes. The programmer had to decide which
modules went in which overlays, but after that it was all automagic. There
was a 4xx code allocated to them.

I think the support for that (in e.g. the linker) was somehow involved with
the use of overlays in the kernel, but I don't know the details (nothing
after V6 is at all interesting to me).

    > didn't the 11 max out at 256k)?

You need to distinguish between i) the amount of memory the machine could
handle, and ii) the amount of memory that running code could 'see' at any
instant. The latter was always either 64KB, or 64KB+64KB (with split I+D
turned on, on CPUs which supported it).

The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB.
(Although there was the Able ENABLE:


which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70,
as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44
had an Extended UNIBUS, and could also handle up to 4MB (but only after the
MS11-P became available; there were only 4 main memory slots in the
backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the
KB11-A (Revision A), which only suppported 256 KB, all later revisions and
CPUs could also handle up to 4MB.


More information about the TUHS mailing list