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_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6965 invoked from network); 3 Aug 2023 23:16:04 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 23:16:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 417C141753; Fri, 4 Aug 2023 09:16:01 +1000 (AEST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by minnie.tuhs.org (Postfix) with ESMTPS id 95D1441752 for ; Fri, 4 Aug 2023 09:15:53 +1000 (AEST) Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-447d04c6d58so396702137.0 for ; Thu, 03 Aug 2023 16:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1691104552; x=1691709352; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QFDQrvPI83zDA3Za2UaG53TF6+iFVQetIBl+vw+Wtw0=; b=DYV7QpTFJobd3VbVfr/n/V1p16xfuiVZ+GSpxAgLS7b4DB0BijYYIVTlXZ5ej9qShp qyCnlvM14vAOQLZlfNDW2xmVVel7aVFE+TCtBor/HpvUs0ZZ5RNjj8aCJJtLTe+ptR9K 06qmibq9NN+GJqiQd3YLB6TtxUevQBdip8oCY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691104552; x=1691709352; 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=QFDQrvPI83zDA3Za2UaG53TF6+iFVQetIBl+vw+Wtw0=; b=OrtUgOJQzWFfi4uVrbF2/rll1LHaVUdKH/gScKbp0J7D5P5xIiCzV++Pvt9szD3TFo KOZ8b4z5K7BneDMDBvEK4c9WgsuUY7g5eKDVknYR4diBnrNY3M60slttp09h70Z6d+gi Ivgi4aQ3a/lIMHHfiaUDF5jRanuuQ9a/fR+NtGtsxsQF/aIIBmKDEU2DInGOj+sHpzHV qQqQHKoXAnI7p0lMPjORVwH1fgi48mMDAXhV8n2ME9dAg0nW90XltzGmuBbA2fvSZuKc 6t4YMBRkd1cnN8444B+kZixv13ERojy79xxcfwvpAAKrCONMcrhbPWH/CTj7KiyOR3T+ pXtQ== X-Gm-Message-State: AOJu0YwryaSQZJnHgfAWjAi0frkXHvlfYhpCXlx5Z6jYL3hzmk8nCsYZ PGzjujB4N45NCqJOv3v6BEA6Kh0EaGqPl3MMg9jDHA== X-Google-Smtp-Source: AGHT+IGIS9r/VdIECTct7uRrj/oQzUTksIuH0VHKXzqu24hxuCn8VFuis5dzlTeY+y79MpYMBEHYS3/A7w/GRjTB6w4= X-Received: by 2002:a67:f886:0:b0:447:919b:ad93 with SMTP id h6-20020a67f886000000b00447919bad93mr52554vso.10.1691104552310; Thu, 03 Aug 2023 16:15:52 -0700 (PDT) MIME-Version: 1.0 References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> In-Reply-To: From: Clem Cole Date: Thu, 3 Aug 2023 19:15:16 -0400 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="0000000000001e735606020cf687" Message-ID-Hash: 3RASV5P4UGI3JEU377CMDJK2KICKHW6G X-Message-ID-Hash: 3RASV5P4UGI3JEU377CMDJK2KICKHW6G X-MailFrom: clemc@ccc.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: tuhs@tuhs.org 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: --0000000000001e735606020cf687 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I probably should add one more thing... RT11 and RSX, and in particular the DEC FTN compiler, supported thunks and overlays - i.e. larger-sized programs before UNIX did. IIRC, they needed them because by then the FTN subsystem needed overlays to run itself. So .. assuming my memory is correct, this was the reason why Fred rewrote the V7 code, and DEC pushed it out as part of the v7m release. Ken's original overlay support code was not sufficient for the DEC language tools. I don't remember if Ultrix-11 or v7m for that matter, ultimately got the FTN compiler. That said, Paul W might remember as he did the linker work for Ultrix moving the VMS linker to Ultrix to support the 'Technical Languages Group' (TLG ). Utrix-32 certainly did get FTN I think a couple of other of the RSX and RSTS languages, but my memory of Fred's work was to support overlays in V7 so it could support it. This was all during the Unix wars inside of DEC. Fred was part of the 'Telephone Industries Group' (TIG) in MRK. =E1=90=A7 On Thu, Aug 3, 2023 at 6:54=E2=80=AFPM Clem Cole wrote: > > =E1=90=A7 > below... [and I meant to answer the second =C2=BD of your question before= ] > > On Thu, Aug 3, 2023 at 6:09=E2=80=AFPM Will Senn wr= ote: > >> Clem, >> >> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D, >> you can use 64k for I and 64k for D. >> > Exactly but ... more in a minute. > > > > >> Was that it, or were there other tricks to get even more allocated >> (didn't the 11 max out at 256k)? >> > Different issues... the MMU on the 40 class and the 45/55 allows 256K [18 > bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers > had 18 bits of address and RH70 controllers could support 22 bits of > extended addresses - see the processor and peripheral handbooks for detai= ls > [or I can explain offline]. > > What the PDP-11 books calls 'pages' are 64-byte segments. So the MMU is > set up to allow the processor to address 64K or 64KI/64KD at the time, > depending on if you have the I/D hardware, and the MMU is set up as to > which 'pages' are being addressed. > > But you could overlay things ... [0405 files] with 'thunks'. > > So to allow a process (or the kernel) to have more than 64K, overlays can > be loaded into memory and since the total physical space memory space is > either 18 or 22 bits, if the kernel supports overlays - processes could g= et > bigger [which is part of your first question]. > V7 was when 0405 [text only] overlays were added. With DEC's release of > v7m - Fred Cantor rewrote the overlay code and they became more general > [and that would go into 2.9BSD]. > > So the programmer needs to decide what you wanted to put into what > overlay. For processes, the kernel can swap out segments and replace th= em > as needed. The key is that link needs to generate near/far style calls > and it can be a PITA. If you want to access a routine that is not > currently mapped into memory, the 'thunk' needs to ask the OS to switch i= t. > Great thought of what was going to be stored where. > > > > >> >> The kernel could be compiled either with, or without separate I/D. The >> only reason not to is if you didn't have more then 64k or were there oth= er >> reasons? >> > Well by V6, UNIX needed at least 64K of physical memory and it was really > slow with anything less than 256K. For the kernel, using I/D allowed th= e > kernel to grow more easily. By the time of trying to cram networking int= o > it, running on anything less than an 11/44 was pretty hard. > > That said, Able made an alternate MMU called the ENABLE that allow 4M of > memory on a Unibus system. It worked at a cache/bus repeater. So you se= t > the internal MMU to point to it and then use its MMU. Very cool and a > soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in > Teklabs with the first Enable board. > > For whatever its worth, even with 4M the kernel had started to become a > problem for V7 on an 11/70. Data buffers eat a lot of memory. > >> >> So, besides the kernel what apps tended to be split? If I remember >> correctly, vi was one, pascal another? >> > Anything that started to get big ;-) > > Ppeople ran out of data space and text space from 64K fairly fast. With > the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away= . > Rob has an excellent paper -> "cat -v considered harmful" BSD UNIX, an= d > the Vaxen greatly fueled that. Adding features and thinking less about > what functionality was really needed started to get lost [so now we have > Gnu - but I digress]. Werner and the BSD 2.9 folks are to be commended f= or > what they did with so few resources. They moved things back from the Va= x > by using the overlays, but if you were to have any semblance of > performance, you need the overlays to stay resident so you need that full > 4M of memory. > > As for this specific question first two subsystems for the 11 that ran ou= t > of text space were indeed vi and Pascal subsystems (Joy having had his ha= nd > in both, BTW). But they were hardly the only ones once the genie was out > of the bottle. Data space quickly became the real issue. People really > wanted larger heaps in particular. In fact, by the 1990s, I knew of few > programs that run out of 32-bit worth of text space, but many that > started to run out of 32-bits of data space -> hence Alpha. But BTW: > DEC took a performance hit originally, and there was a huge discussion at > the time if 64-bits was really needed. > =E1=90=A7 > --0000000000001e735606020cf687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I probably=C2=A0should add one more thing...=C2=A0 RT11= and RSX, and in particular the DEC FTN compiler, supported thunks and over= lays - i.e. larger-sized programs before UNIX did.=C2=A0 IIRC, they needed = them because by then the FTN subsystem needed overlays to run itself.=C2=A0= So .. assuming my memory is correct, this was the reason=C2=A0why Fred rewr= ote the V7 code, and DEC pushed it out as part of the v7m release.=C2=A0 Ke= n's original=C2=A0overlay support code was not sufficient for the DEC l= anguage tools.=C2=A0

I don't remember if Ultrix-= 11 or v7m for that matter, ultimately got the FTN compiler.=C2=A0 That said= , Paul W might remember as he did the linker=C2=A0work for Ultrix moving th= e VMS linker to Ultrix to support the 'Technical Languages Group' (= TLG ).=C2=A0 Utrix-32 certainly did get=C2=A0FTN I think a=C2=A0couple of o= ther of the RSX and RSTS languages, but my memory of Fred's work was to= support overlays in V7 so it could support it.=C2=A0 This was all during t= he Unix wars inside of DEC.=C2=A0 Fred was part of the 'Telephone Indus= tries=C2=A0Group' (TIG) in MRK.
3D""=E1=90=A7
On Thu, A= ug 3, 2023 at 6:54=E2=80=AFPM Clem Cole <clemc@ccc.com> wrote:

3D""= =E1=90=A7
below... [and I mean= t to answer the second =C2=BD of your question before]

On Thu, Aug 3,= 2023 at 6:09=E2=80=AFPM Will Senn <will.senn@gmail.com> wrote:
=20 =20 =20
Clem,

Oh, so... Without I/D, you're stuck with 64k max per process, wit= h I/D, you can use 64k for I and 64k for D.
Exactly=C2=A0but ... more in a minute.=


=C2=A0
Was that it, or were there other tricks to get even more allocated (didn't the 11 max out at 256k)?
Different issues... the MMU on the 40 class and the 45/55 allows 256K = [18 bits], the MMU for the 70 class is 4M [22 bits],=C2=A0Unibus= I/O controllers had 18 bits of address and RH70 controllers could <= font color=3D"#0000ff">support 22 bits of extended addresses - see the proc= essor and peripheral=C2=A0handbooks for details [or I can explain offline].=

What the PDP-11 books calls = 'pages' are 64-byte segments.=C2=A0 So the MMU is set up to allow t= he processor to address 64K or 64KI/64KD at the time, depending on if you= =C2=A0have the=C2=A0I/D hardware, and the MMU is set up as to which 'pa= ges' are being addressed.

But you could overlay things ... [040= 5 files] with 'thunks'.

=
So to allow a process (or the kerne= l) to have more than 64K, overlays can be loaded into memory and since the = total physical space memory space is either 18 or 22 bits, if the kernel su= pports overlays=C2=A0- processes could get bigger [which is part of your fi= rst question].=C2=A0
V7 was when 040= 5 [text only] overlays were added.=C2=A0 =C2=A0With DEC's release of v7= m - Fred Cantor rewrote the overlay code and they became more general [and = that would go into 2.9BSD].

So the programmer needs to decide what= you wanted to put into what overlay.=C2=A0 =C2=A0For processes, the kernel= can swap out segments and replace them as needed.=C2=A0 =C2=A0The key is t= hat link needs to generate near/far style calls and it can be a PITA.=C2=A0= If you want to access a routine that is not currently mapped into memory, = the 'thunk' needs to ask the OS to switch it. Great thought of what= was going to be stored where.
=C2=A0

= =C2=A0

The kernel could be compiled either with, or without separate I/D. The only reason not to is if you didn't have more then 64k or wer= e there other reasons?
Well by V6, UNIX needed at least 64K of physical memory and it= was really slow with anything less than 256K.=C2=A0 =C2=A0For the kernel, = using I/D allowed the kernel to grow more easily.=C2=A0 By the time of tryi= ng to cram networking into it, running on anything less than an 11/44 was p= retty hard.

That said, Able made an alternate MMU called t= he ENABLE that allow 4M of memory on a Unibus system.=C2=A0 It worked at a = cache/bus repeater.=C2=A0 So you set the internal MMU to point to it and th= en use its MMU.=C2=A0 =C2=A0Very cool and a soft spot for me.=C2=A0<= span style=3D"color:rgb(0,0,255)">I ran an 11/60 [which is 40 class] with 2= M of memory in Teklabs with the first Enable board.

For whatever=C2=A0its worth, even with 4M the kernel had started to= become a problem for V7 on an 11/70.=C2=A0 Data buffers eat a lot of memor= y.

So, besides the kernel what apps tended to be split? If I remember correctly, vi was one, pascal another?
<= font color=3D"#0000ff">Anything that started to get big ;-)=C2= =A0

Ppeople ran out of data space and text space from 64K f= airly fast.=C2=A0 =C2=A0With the 32-bit Vax, the UNIX Small is Beautiful th= inking started to fall away.=C2=A0 =C2=A0Rob has an excellent paper -> &= quot;cat -v considered harmful"=C2=A0 =C2=A0BSD UNIX, and the Vaxen gr= eatly fueled that.=C2=A0 =C2=A0Adding features and thinking less about what= functionality was really needed started to get lost [so now we have Gnu - = but I digress].=C2=A0 Werner and the BSD 2.9 folks are to be commended for = what they did with so few resources.=C2=A0 =C2=A0They moved things back fro= m the Vax by using the overlays, but if you were to have any semblance of p= erformance, you need the overlays to stay resident so you need that full 4M= of memory.

=
As for this=C2=A0specific que= stion first two subsystems for the 11 that ran out of text space were indee= d vi and Pascal subsystems (Joy having had his hand in both, BTW).=C2=A0 Bu= t they were hardly the only ones once the genie was out of the bottle.=C2= =A0 =C2=A0Data space quickly became the real issue.=C2=A0 = People really wanted larger heaps in particular.=C2=A0=C2=A0<= span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,255)">= =C2=A0In fact, by the 1990s, I knew of few programs that run out of 32-bit = worth of text space, but=C2=A0many tha= t=C2=A0started=C2=A0to=C2=A0run out of 32-bits of dat= a space -> hence Alpha.=C2=A0 =C2=A0But BTW:=C2=A0 DEC took a perfor= mance hit originally, and there was a huge discussion at the time if 64-bit= s was really needed.=C2=A0 =C2=A0
3D""==E1=90=A7
--0000000000001e735606020cf687--