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 2319 invoked from network); 3 Aug 2023 21:05:54 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 21:05:54 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id BED2941640; Fri, 4 Aug 2023 07:05:50 +1000 (AEST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by minnie.tuhs.org (Postfix) with ESMTPS id 248834163D for ; Fri, 4 Aug 2023 07:05:45 +1000 (AEST) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-31757edd9edso1151676f8f.2 for ; Thu, 03 Aug 2023 14:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691096743; x=1691701543; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A4fv6CyqS+BVIgR20PYBAM6ESwAlKXIR7pIJdfocAOI=; b=XS+s+I9YdVcgSadwnWlRk2x3NiL5RB0f9grLyP+XraWXYbR80lcToi7RbOzg289uxO 76ni3kmEJQndOg5wrnh1Ol5tudE3McG8Hix0Wmja/LqVpFA6siv5S5Nfi8k5Arres/wo pEaVm7qdxZ7IA49d0lSiNBzY3Rir0hZPv7KDYdHYiioIyOHr3mPHE2DelSIDggMrErhH 6SHtI35m81socykcpCqZJ+v+OnOv7y4lj6JLGgyZ9/WGDvGXII3LnS1nC8I3C9IBlsGg 8SjV/CZJelo6NNB7IGAPyGXxkKRjgXjWT53DQiwr14QutbjEDvyUV+ahXx94xPYFEXkz DvBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691096743; x=1691701543; 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=A4fv6CyqS+BVIgR20PYBAM6ESwAlKXIR7pIJdfocAOI=; b=DKWEtE50HliA9+LAuG0MpqyKEPt4j8R510Y+fy+iNM0Ue3osCe4a5/3JcoHgUQTWaQ O07K9E6Bhq3JXUTiSaPfizpe5Z/is1frv6mp5VYsOJdS5IZaN/XmJmz9N9RIMaX/5gaT iAFCsf3RN1nlDmtO+EFmAmy0hHEisGiamitb8mJmuHzN89lH3kGAe8dRV3l/KY9yilEZ a1kHCTHMXlyKKVxKdqgKdCTQIvVQUMqK+gI/HYAXsk7LK0VP30F6VKzd3fvpv3jENY1J wwhMtKLY5ekVJo30YVRXiitZoPY5LjKXbmPe1JnMtJJq3n5viFHpKNlrgtqUi92V34el p7Sg== X-Gm-Message-State: ABy/qLYkyvwSSyKhJqa3UW5dq/1VFbCBh6E2a9eu2ErigopSy7LQWCNs cDj3z+CP9RWq3cKxwVICUGco+3YKFWCinG1EOdlanXT+ X-Google-Smtp-Source: APBJJlE1CgZpMVw/mmqqMdXFQSpzW8BaeikK8qiQn23786dbb2ouMA8DSk3C7aY+kYG4oLlZta9PqWltzSQ2vJevN3s= X-Received: by 2002:a5d:53ca:0:b0:317:18a8:5fa1 with SMTP id a10-20020a5d53ca000000b0031718a85fa1mr8319709wrw.69.1691096743064; Thu, 03 Aug 2023 14:05:43 -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 17:05:31 -0400 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="000000000000a6b82c06020b246d" Message-ID-Hash: FR6A3XQGLN2AMULDCULJY4JAOY2WULTH X-Message-ID-Hash: FR6A3XQGLN2AMULDCULJY4JAOY2WULTH 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: --000000000000a6b82c06020b246d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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/sbrk 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? > > --000000000000a6b82c06020b246d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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?

--000000000000a6b82c06020b246d--