From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7781 invoked from network); 3 Aug 2023 23:42:36 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 23:42:36 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7EB3B41679; Fri, 4 Aug 2023 09:42:31 +1000 (AEST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by minnie.tuhs.org (Postfix) with ESMTPS id A3D8741651 for ; Fri, 4 Aug 2023 09:42:22 +1000 (AEST) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-522462d8416so1860893a12.1 for ; Thu, 03 Aug 2023 16:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691106141; x=1691710941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zSqbFcw1+U5Ks+G3r+q61SWrB2lZE5wET3ERRgeZbmY=; b=tHyVQ8Vqc01llZZ+rk7aejrYEf8vQqXoEm4fs7RtcW4u/eVQvD8+ZzSRa1OqaBWawh Gs4WFWnZ1NtKSdtd272eoP0hqgmjZY58AkiboH98weE3UOtKKIfhB5FaQvNloJlwRAmU Jax/TpAC70sGzsgDpLzR7om1BAytx8CiULZO4Bmxe6kS6KnlXkXKD7ad8nkAtixQDebP CQ5oBAMM2cyj/HHhIq2zKJ++VhEmyk4NNB6sBA5H4mVmVUIQiH0ID+dyyQVTvbRke0Gj lWLGhdO/rjfwKapVO3jbtYqaSh9wHn2oMCAd6ZXPA7SK0ErjDR2QVc2DITNcYmEK4Ams Zc1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691106141; x=1691710941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zSqbFcw1+U5Ks+G3r+q61SWrB2lZE5wET3ERRgeZbmY=; b=gDV+CnCyI1ovxvxIvIIeRW7I4zqPZlGBGdPNqgHhsSI3MkYwv7wScV2h5IrTuJYw6G PQePmbqZ6iB05vV9WUnWV1Ck6My96hIiubfZtaGQ5lyMrziGverSvGllOJZgWGTSslYT MTQVCsWjMm+sE8REdkm/J92FYawbdCX1dXlCUR8hM9yL8cbUCxfP0OZl98z5cWuVIvNz zyLL4Axss6quDjT+KM6N7YLtOUPTKm5FUc3zvN0N8NuKIvn9kjF3MBgwB7/ncxdzPg1m a+TjcRIhzaB55SXzSPGrbjJHfzXeieVFcn1zjFbQd3ac8NyHxvTGAbQ9/LK4d3LEVreH k/Tg== X-Gm-Message-State: AOJu0Yxx/zOcdozJfnELjiHQFfb2RcAxDACYOn/S7112VqcG8FQT7aAr r2lPgh6+2TZoSuVlWXLQ3OTspfKHcmrIFkz4DhL43arrjZj+qK0k X-Google-Smtp-Source: AGHT+IGiM3hvFxazxlf+xjg/AWkiOjW76OBfreUD1u4EuUzmSPsfpbswFe7Uc2HlSuQPjPGtle1MnZKOp90tJ9D8LB8= X-Received: by 2002:a05:6402:282:b0:522:5591:d748 with SMTP id l2-20020a056402028200b005225591d748mr194314edv.15.1691106140717; Thu, 03 Aug 2023 16:42:20 -0700 (PDT) MIME-Version: 1.0 References: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> In-Reply-To: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> From: Warner Losh Date: Thu, 3 Aug 2023 17:42:09 -0600 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="000000000000cb94d706020d5465" Message-ID-Hash: FFBHWK56L2J5KKA2BTZAUT4UAT4HSK3V X-Message-ID-Hash: FFBHWK56L2J5KKA2BTZAUT4UAT4HSK3V X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000cb94d706020d5465 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa 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 > --000000000000cb94d706020d5465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:<= br>
=C2=A0 =C2=A0 > From: Clem Cole<= br>
=C2=A0 =C2=A0 > A new hire in 1976, Jeff Mitchell supposedly had a bet w= ith Bill
=C2=A0 =C2=A0 > Strecker that he could implement an 11 on a single"= hex high" CPU board
=C2=A0 =C2=A0 > if he got rid of the lights and switches. He ran out of = room to
=C2=A0 =C2=A0 > implement seperate I/D, so it became an 11/40 class [and= it has an
=C2=A0 =C2=A0 > 8008-1 that runs the front panel].

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

=C2=A0 https://gunkies.org/wiki/KD11-D_CPU

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

=C2=A0 https://gunkies.org/wiki/KY= 11-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:

=C2=A0 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.


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

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

=C2=A0 https://gunkies.org/wiki/KD11-Z_CPU

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


=C2=A0 =C2=A0 > 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 combinati= on
of 'sysfix' (a special post-processor, which took as input a reloca= table
linked image) and code in m45.s was needed.

=C2=A0 https://gunkies.org/wiki/Upgr= ading_UNIX_Sixth_Edition
=C2=A0 https://gunkies.org/wiki/UNIX_V6_mem= ory_layout

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

=C2=A0 https://minni= e.tuhs.org/cgi-bin/utree.pl?file=3DV6/usr/sys/conf/m45.s

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



=C2=A0 =C2=A0 > From: Will Senn

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

I have this vague memory that someone (Berkeley, I think?) added support fo= r
automatic code overlays in user processes. The programmer had to decide whi= ch
modules went in which overlays, but after that it was all automagic. There<= br> 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 (nothin= g
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
=C2=A0 =C2=A0 > 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 2= 56KB.
(Although there was the Able ENABLE:

=C2=A0 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<= br> CPUs could also handle up to 4MB.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel
--000000000000cb94d706020d5465--