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 2517 invoked from network); 3 Aug 2023 21:10:23 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 21:10:23 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 27A204164D; Fri, 4 Aug 2023 07:10:19 +1000 (AEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by minnie.tuhs.org (Postfix) with ESMTPS id 2C6124111F for ; Fri, 4 Aug 2023 07:10:16 +1000 (AEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5C088320098A; Thu, 3 Aug 2023 17:10:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 03 Aug 2023 17:10:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ronnatalie.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691097014; x=1691183414; bh=bIy1sNw64YQmRxoznGQRzXRO2UD455u1FJ5 Ca15vKeE=; b=sqA1DD+Vgnz1c/zneR1KAqRPZVImRVk1iBtC0DmcFvdkHq13gjC Whw+bNmnKyJGCogRm1IbScLlUAZ3Uo2og4QRUk5PRrdRQaaMtDPd68lC+GjwvDtK fTXivR5zPzz6TNZgkPwD72PsXytsE2a74KnHWd96RSGD72QSWOAV+MWPY0P6m+z8 rsHqdBcYM1xu735wkLi7GMRwg5I2YqqCozPMQ6pkVd7m5HsRk8QT6F+4oLURUJdw NX6DX4pYqa4Cby82cDedKn+caQJyMxOcLsMTzd08BEXZ8QlgbOGnhd3CMLcvik1p 3pZXkTsrBRddOylBcIxDcMozIBiOXkaCydA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1691097014; x=1691183414; bh=b Iy1sNw64YQmRxoznGQRzXRO2UD455u1FJ5Ca15vKeE=; b=dDGwECnlrtZ18eabj ANiqjDnOssrOcEAt//2JKnxLhQ4jYF5tIAKFog5DH0m6n2mThnWzv5yv/FWEQt6u fQhk+cdmRaRPUhsy3wZo2bfhKpfz7HQCfDdzNErvXBS55g/AUZLHxwNbE5askhN9 ei3z9xyfdpNbADeLglf2C8SBdE+L+qIntglbyQilDfjqy2uF+D/puAtkKCpeL3R0 raX4Wd20NKt3Q3S86JgatVCe3t88bJfeHSjOWi/XTM8qRtAHwc/QFO6+87RTWAxt J8wF1rfr2Mzm1ki3eVzULkDuN04ggVOd1WKWuQ4gS0V2QpY2t0bmnXQ0tWOY4oc8 Etygw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkedvgdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufevfffkjghfrhgfgggtsegrtderredtreejnecuhfhrohhmpedftfho nhgrlhguucfprghtrghlihgvfdcuoehrohhnsehrohhnnhgrthgrlhhivgdrtghomheqne cuggftrfgrthhtvghrnhepudekhfffieeikefghefhfeejfefhleduvddtffevleelkeeg leegtedvgfdtfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprhhonhesrhhonhhnrghtrghlihgvrdgtohhm X-ME-Proxy: Feedback-ID: iaba146ad:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 3 Aug 2023 17:10:14 -0400 (EDT) From: "Ronald Natalie" To: "Kenneth Goodwin" , "Will Senn" Date: Thu, 03 Aug 2023 21:10:14 +0000 Message-Id: In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> User-Agent: eM_Client/9.2.1841.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBEFD1EDB2-ED6E-41A0-8AF2-821573B4288B" Message-ID-Hash: CAHAP3OYZNQZ7TI2ENFQEGB5IR6RQE5X X-Message-ID-Hash: CAHAP3OYZNQZ7TI2ENFQEGB5IR6RQE5X X-MailFrom: ron@ronnatalie.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 Reply-To: Ronald Natalie 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: --------=_MBEFD1EDB2-ED6E-41A0-8AF2-821573B4288B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that=20 it did have split I/D. V6 supported split I/D for user mode programs.=20 The kernel originally wasn=E2=80=99t split I/D. Version 7, if I=E2=80= =99m recalling=20 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=20 of the python... thread) >At the risk of exposing my ignorance and thus being events long long=20 >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=20 >assembler and loader always built the binary object file as the three=20 >sections - instructions, data and bss spaces so loading an object file=20 >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=20 >give you a machine type to switch off of. > >With something like that you could determine memory availability hard=20 >limits on the DATA/bss side if you needed to. > >But that was also easily determined by a allocation failure in=20 >malloc/sbrk with an out of memory error. > >If you really needed to know availability, you could have a start up=20 >subroutine that would loop trying to malloc ever decreasing memory=20 >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=20 >into two pieces. One running in kernel mode and one running in=20 >supervisor mode in order to double the amount of available instruction=20 >and data spaces for the operating system. I recall playing around with=20 >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=20 >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? >> --------=_MBEFD1EDB2-ED6E-41A0-8AF2-821573B4288B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div>Having cut my UNIX teeth on the JHU 11/45, I can tell you very much tha= t it did have split I/D. =C2=A0 =C2=A0V6 supported split I/D for user mode= programs. =C2=A0 The kernel originally wasn=E2=80=99t split I/D. =C2=A0 Ver= sion 7, if I=E2=80=99m recalling properly, did run the kernel split I/D on= the 45 and 70.

=0A

=0A

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

=0A
=0A
A= t 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=C2=A0

1.=C2=A0 I don't think t= he 11/45 had split I & d.
But I could be wrong.<= /div>
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 b= inary object file as the three sections - instructions,=C2=A0 data and bss= spaces so loading an object file could be done on any platform.
Programmers generally did not worry about the underlying hardwa= re=C2=A0

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

With something like that you could determine memory availability hard l= imits on the DATA/bss side if you needed to.

<= /div>
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,=C2= =A0 you could have a start up subroutine that would loop trying to malloc e= ver decreasing memory sizes until success and until out of available memory = error.
Then release it all back via free(). Or mana= ge it internally.

As I = recall however vaguely,=C2=A0 there was an attempt to split the kernel int= o two pieces. One running in kernel mode and one running in supervisor mode = in order to double the amount of available=C2=A0 instruction and data spac= es for the operating system. I recall playing around with what was there tr= ying to get it to work right.
I was trying to suppor= t over 200 users on a pdp 11/70 at the time running a massive insurance dat= abase 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
=0Aconfiguration or is= it convention and programmer's responsibility to
=0Aknow and manage w= hat's actually available?
=0A
=0AWill
=0A
=0AOn 8/3/23= 12:00, Rich Salz wrote:
=0A> What, we all need something to kick no= w that we've beaten sendmail?=C2=A0
=0A> How about something unix, = ideally a decade old?
=0A
=0A
=0A
=
=0A --------=_MBEFD1EDB2-ED6E-41A0-8AF2-821573B4288B--