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 2697 invoked from network); 3 Aug 2023 21:16:48 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 21:16:48 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C42EA41670; Fri, 4 Aug 2023 07:16:43 +1000 (AEST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by minnie.tuhs.org (Postfix) with ESMTPS id 0CCB14166D for ; Fri, 4 Aug 2023 07:16:39 +1000 (AEST) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-4f4b2bc1565so2494318e87.2 for ; Thu, 03 Aug 2023 14:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691097397; x=1691702197; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bm5N6xOghjYZES9f6e3tZyNRJdNdeHIpdeNpC22/cPc=; b=2CVqG5YyrrEeAVCbLo/8pmupdRLzk3R/fu73+PxKHliDxu+KSYyDn6HA/HBJSnFvMI DQTefngHy5brsWdigBLj2HEEmcQ4AbZjhITZJQJyulpIYU9eryO1S4gKc+oO7Q00kx/P uAu8aiOs9uJeDzolI+TbMnZS2rYUE/UlNsmxKeLA64EzpelyAS8htahSfPIp3C9iP0W6 fEzuXKPv81vLnVSPBaa3ZW5RVUQH6+SNHNk/bnIk8p0I8WiaLK8qgqJOAYZvERhhz/Rf uJ9wiKQbhYJcoeNs4dtdJ76MJKU4n9rJuAUUp5HC8ENCjxSlq6zGR8TLDWiEwnTbmJYv SRmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691097397; x=1691702197; 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=Bm5N6xOghjYZES9f6e3tZyNRJdNdeHIpdeNpC22/cPc=; b=TrpK7AbPjQVCTKR/t6mFXvn68zwNE2Ns9pNRWrk3LzR4Ej8vVPAk7ujrN+6T2MvPBF IpwCmlHTB7L0GFdAKby5o8liRJVwWc6vq6HbUGAw01EAyv0L8dUPD2da45N4hOuZSdle X/PDIXrpnlaH29oV8xoxGjJXcD89NVDnyt5R/sD9tk/xATD3eA9zTY30BRmXOMsvlspF EBG3fAfbxTA3ADSZRvp3CJHp8bRVehh8WknKc++TweP5mDBUoSSyU7OMUHNuGz7bf2sK PUj8xfufGyUsNvigoN4PsLozYqRWNeQyWw/m59RERAxxF3QRESeLGHwd1v8TX/TVgkK6 w5oA== X-Gm-Message-State: ABy/qLaAis6OyYiZ9wq5/Gt8n1DnLo4nl69n8TM1XvqfcVVtdtv3VM+L O2y0tgnPr18mdoRDXM2wLxENQ5aInzhpkhucCSDRZyzF/JyEMrsLrRU= X-Google-Smtp-Source: APBJJlFxkY3Nk1MV9t68GyZ0jR49xIz7RI7jLYYeRziikVbqzwkyzYBpSR4xB2lts0OgnbnY4nolMGxX0FUyGIICwAs= X-Received: by 2002:ac2:5a1c:0:b0:4fd:c399:eb25 with SMTP id q28-20020ac25a1c000000b004fdc399eb25mr8374232lfn.50.1691097396845; Thu, 03 Aug 2023 14:16:36 -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: Warner Losh Date: Thu, 3 Aug 2023 15:16:25 -0600 Message-ID: To: Ronald Natalie Content-Type: multipart/alternative; boundary="0000000000009ec13506020b4b91" Message-ID-Hash: WV6T65D6W7A4K2ZB7SR4SKW4DP442FCN X-Message-ID-Hash: WV6T65D6W7A4K2ZB7SR4SKW4DP442FCN 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: --0000000000009ec13506020b4b91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2BSD also did split I&D in the kernel (as well as run TCP in supervisor mode to get another I/D space). A lot of the overlays was done in the linker, but it wasn't completely automated. I had to tweak the overlay tables a little as I did the 2.11pl0 work since the early stuff wasn't exactly careful about distributing the hacks to the makefile to make it happen... Warner On Thu, Aug 3, 2023 at 3:10=E2=80=AFPM Ronald Natalie = wrote: > Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that > it did have split I/D. V6 supported split I/D for user mode programs. > The kernel originally wasn=E2=80=99t split I/D. Version 7, if I=E2=80= =99m recalling > properly, did run the kernel split I/D on the 45 and 70. > > > > ------ Original Message ------ > From "Kenneth Goodwin" > To "Will Senn" > Cc "The Eunuchs Hysterical Society" > Date 8/3/23, 5:05:31 PM > Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of > the python... thread) > > At the risk of exposing my ignorance and thus being events long long ago > in history.... > And my mind now old and feeble... > > =F0=9F=98=86 =F0=9F=A4=A3 > > 1. I don't think the 11/45 had split I & d. > But I could be wrong. > That did not appear until the 11/70 > And was in the later generation 11/44 several years later. > > 2. The kernel determined it by MMU type and managed it solely. The > assembler and loader always built the binary object file as the three > sections - instructions, data and bss spaces so loading an object file > could be done on any platform. > Programmers generally did not worry about the underlying hardware > > 3. I don't recall if a systype style system call was available in v7 to > give you a machine type to switch off of. > > With something like that you could determine memory availability hard > limits on the DATA/bss side if you needed to. > > But that was also easily determined by a allocation failure in malloc/sbr= k > with an out of memory error. > > If you really needed to know availability, you could have a start up > subroutine that would loop trying to malloc ever decreasing memory sizes > until success and until out of available memory error. > Then release it all back via free(). Or manage it internally. > > As I recall however vaguely, there was an attempt to split the kernel > into two pieces. One running in kernel mode and one running in supervisor > mode in order to double the amount of available instruction and data > spaces for the operating system. I recall playing around with what was > there trying to get it to work right. > I was trying to support over 200 users on a pdp 11/70 at the time running > a massive insurance database system. > > On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: > >> Does unix (v7) know about the PDP-11 45's split I/D space through >> configuration or is it convention and programmer's responsibility to >> know and manage what's actually available? >> >> Will >> >> On 8/3/23 12:00, Rich Salz wrote: >> > What, we all need something to kick now that we've beaten sendmail? >> > How about something unix, ideally a decade old? >> >> --0000000000009ec13506020b4b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2BSD also did split I&D in the kernel (as well as run = TCP in supervisor mode to get another I/D space). A lot of the overlays was= done in the linker, but it wasn't completely automated.
I had to t= weak the overlay tables a little as I did the 2.11pl0 work since the early = stuff wasn't exactly careful about distributing the hacks to the makefi= le to make it happen...

Warner

On Thu, Aug 3,= 2023 at 3:10=E2=80=AFPM Ronald Natalie <ron@ronnatalie.com> wrote:
H= aving cut my UNIX teeth on the JHU 11/45, I can tell you very much that it = did have split I/D. =C2=A0 =C2=A0V6 supported split I/D for user mode progr= ams. =C2=A0 The kernel originally wasn=E2=80=99t split I/D. =C2=A0 Version = 7, if I=E2=80=99m recalling properly, did run the kernel split I/D on the 4= 5 and 70.



------ Original Message ------
From "Kenneth Goodwin" <kennethgoodwin56@gmail.com>
To "Will Senn" <will.senn@gmail.com>
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/3/23, 5:05:31 PM
Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death= of the python... thread)

At the risk of exposing my ignorance and thus being event= s long long ago in history....
And my mind now old and fee= ble...

=F0=9F=98=86 =F0= =9F=A4=A3=C2=A0

1.=C2=A0 I= don't think the 11/45 had split I & d.
But = I could be wrong.
That did not appear until the 11/7= 0
And was in the later generation 11/44 several year= s later.

2. The kernel d= etermined it by MMU type and managed it solely. The assembler and loader al= ways built the binary object file as the three sections - instructions,=C2= =A0 data and bss spaces so loading an object file could be done on any plat= form.
Programmers generally did not worry about the = underlying hardware=C2=A0

3. I don't recall if a systype style system call was available in v7 = to give you a machine type to switch off of.

With something like that you could determine memory av= ailability hard limits on the DATA/bss side if you needed to.

But that was also easily determined b= y a allocation failure in malloc/sbrk with an out of memory error.

If you really needed to know ava= ilability,=C2=A0 you could have a start up subroutine that would loop tryin= g to malloc ever decreasing memory sizes until success and until out of ava= ilable memory error.
Then release it all back via fr= ee(). Or manage it internally.

As I recall however vaguely,=C2=A0 there was an attempt to split the= kernel into two pieces. One running in kernel mode and one running in supe= rvisor mode in order to double the amount of available=C2=A0 instruction an= d data spaces for the operating system. I recall playing around with what w= as there trying to get it to work right.
I was tryin= g to support over 200 users on a pdp 11/70 at the time running a massive in= surance database system.

On Thu, Aug 3, 2023, 4:35 PM Will Senn = <will.senn@gmail.com> wrote:
Does unix (v7) know about the PDP-11 45's split= I/D space through
configuration or is it convention and programmer's responsibility to know and manage what's actually available?

Will

On 8/3/23 12:00, Rich Salz wrote:
> What, we all need something to kick now that we've beaten sendmail= ?=C2=A0
> How about something unix, ideally a decade old?

--0000000000009ec13506020b4b91--