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

[Warner Losh]

On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>     > 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:
>
>   https://gunkies.org/wiki/KD11-D_CPU
>
> 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:
>
>   https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console
>
> which added another quad card). The first -11 CPU i) on a single card and
> ii) with memory management was the FDF11-A:
>
>   https://gunkies.org/wiki/KDF11-A_CPU
>
> 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:
>
>   https://gunkies.org/wiki/KD11-Z_CPU
>
> 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.
>
>   https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition
>   https://gunkies.org/wiki/UNIX_V6_memory_layout
>
> The code in m45.s to handle split I+D in the kernel:
>
>   https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s
>
> 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).
>

V7 had a number of patches for MENLO_LINKER or MENLO_OVERLAY that Berkeley
integrated into the tree, but I'm not sure they wrote it. Their hacks were
usually UCB_something...

Warner

    > 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:
>
>   https://gunkies.org/wiki/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.
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230803/cea52cf3/attachment-0001.htm>