The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread)
Date: Thu,  3 Aug 2023 19:10:44 -0400 (EDT)	[thread overview]
Message-ID: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> (raw)

    > 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).

    > 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

             reply	other threads:[~2023-08-03 23:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 23:10 Noel Chiappa [this message]
2023-08-03 23:42 ` Warner Losh
  -- strict thread matches above, loose matches on Subject: below --
2023-08-04 21:40 Noel Chiappa
2023-08-03 23:14 Steve Simon
2023-08-03 21:48 Noel Chiappa
2023-07-30 23:59 [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman Erik E. Fair
2023-08-01 10:58 ` Erik E. Fair
2023-08-02  0:37   ` Dave Horsfall
2023-08-02 14:52     ` Ron Natalie
2023-08-02 21:14       ` Grant Taylor via TUHS
2023-08-02 22:20         ` segaloco via TUHS
2023-08-02 23:49           ` Rich Salz
2023-08-03  0:51             ` [TUHS] Re: python Larry McVoy
2023-08-03  2:07               ` Clem Cole
2023-08-03 16:57                 ` [TUHS] Re: [TULSA] " Phil Budne
2023-08-03 17:00                   ` Rich Salz
2023-08-03 20:35                     ` [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Will Senn
2023-08-03 21:05                       ` [TUHS] " Kenneth Goodwin
2023-08-03 21:10                         ` Ronald Natalie
2023-08-03 21:16                           ` Warner Losh
2023-08-03 21:24                             ` Ronald Natalie
2023-08-03 22:34                           ` Kenneth Goodwin
2023-08-03 21:05                       ` Ronald Natalie
2023-08-03 21:44                       ` Clem Cole
2023-08-03 22:08                         ` Will Senn
2023-08-03 22:54                           ` Clem Cole
2023-08-03 23:08                             ` Dave Horsfall
2023-08-03 23:15                             ` Clem Cole
2023-08-04  0:38                             ` John Cowan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230803231044.2B4AB18C080@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).