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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5606 invoked from network); 3 Aug 2023 22:34:49 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 22:34:49 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 1AE03416D5; Fri, 4 Aug 2023 08:34:44 +1000 (AEST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by minnie.tuhs.org (Postfix) with ESMTPS id 8E6E2416D4 for ; Fri, 4 Aug 2023 08:34:36 +1000 (AEST) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-317716a4622so1306378f8f.1 for ; Thu, 03 Aug 2023 15:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691102075; x=1691706875; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wKkga2HGt5LKGlFT3T9RRxUk9NTo3aPJfbxRB/SP71w=; b=cEkXNhDJ8kJP7m8N0BWkjmPoooQOcakT+LnkVxDunJwtdU4qIAI3WuFXi+VtdqUONC DibxqHdZtY6rjOejJLTJ0XTg6mca3lOdLvXVBKKAfHzDBaLZDSh6sSQqf19ei0AMD7Dr 3U80JvEc8SpgpdR+b9kfE0EktXlXwhwY0SlC2PSQACPHQbNJ+8OIm8ik8zlMCqT6AwRI tCEv/jc2hbwJF/5y5MWvhGE41cvtbjtnkfvjwybXR0fZvl3KrOUnfQVJKw182n0QVUhw aYAulq0qsel1STEyCC0A725jr1uRe2BQ38ZlugK+7g//riXcPT/SiNFTcmHI3AUsP0p5 bNFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691102075; x=1691706875; 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=wKkga2HGt5LKGlFT3T9RRxUk9NTo3aPJfbxRB/SP71w=; b=fia2EhfHJD1fUqewcmuFTFYdTXR5JShLqScQdwpzP5LeIhHgdeu8d16T3N+1g5+Mov ygLgVPAQxFPhGOBU0M8F5n2d07tHqOE3GbJATYzc/usHue6BEKfKp/trVFrv93U90JvI eLJxBd57UpYYms7Tn4EwDwG2foAcCpxM6t+XElnjdtPl7UW4yj2cyZsnsvi79HNiXRjw nuS7DSgyhSgtJ0E6ZPYdT0y0jtkAgRW523pc8V4jwLAbIR6wQVTE78J7pQUK29Vdcqp8 Z8J5aYj0NtFSuBozL2gcc/NUZlVwAaEXSsm0ozSjwZUEWPTSELaO1QaUEMdhhewgXHL8 pL7g== X-Gm-Message-State: ABy/qLbD5d3fTHREieTk/0TzDfZfcr4G46WnHT3l9i3scz8IIs9iXXja s2vegHQJHVouNHaHZuZnSn/kL2VSrIwWqcRHdsM= X-Google-Smtp-Source: APBJJlGSdAoVPZ9F88V52MUrjdnVNhsIder43pftgdFR1T5dB7woJIcGMeX3oK99N1FbjnU01FXygbqJJWBzujmrBgk= X-Received: by 2002:a5d:6ac2:0:b0:317:6a7c:6e07 with SMTP id u2-20020a5d6ac2000000b003176a7c6e07mr7498726wrw.32.1691102074588; Thu, 03 Aug 2023 15:34:34 -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: Kenneth Goodwin Date: Thu, 3 Aug 2023 18:34:23 -0400 Message-ID: To: Ronald Natalie Content-Type: multipart/alternative; boundary="0000000000006f5bb106020c62b1" Message-ID-Hash: EZ4FSBCZMM7P7DBTPNV4YQS3KU2TRND3 X-Message-ID-Hash: EZ4FSBCZMM7P7DBTPNV4YQS3KU2TRND3 X-MailFrom: kennethgoodwin56@gmail.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: --0000000000006f5bb106020c62b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having worked on the v6 kernel on the 11/70 it was split on that version on that hardware. On Thu, Aug 3, 2023, 5:10 PM 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? >> >> --0000000000006f5bb106020c62b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having worked on the v6 kernel on the=C2=A0
11/70 it was split on that version on that hardware.

On Thu, Aug 3= , 2023, 5:10 PM Ronald Natalie <ro= n@ronnatalie.com> wrote:
Having cut my UNIX teeth on t= he 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 programs. =C2=A0 The kernel orig= inally 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 45 and 70.



------ Original Message ------
From "Kenneth Goodwin" <kennethgoodwin56@gmail.co= m>
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 spa= ce 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?

--0000000000006f5bb106020c62b1--