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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32013 invoked from network); 29 Jan 2021 23:53:33 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 29 Jan 2021 23:53:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5B4769C87C; Sat, 30 Jan 2021 09:53:27 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 81CD69C772; Sat, 30 Jan 2021 09:52:51 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 921AC9C772; Sat, 30 Jan 2021 09:52:48 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id D12C89C6CF for ; Sat, 30 Jan 2021 09:52:45 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)d207-6-82-137.bchsia.telus.net[207.6.82.137] port=51996) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (5005 bytes) (sender: ) (ident using UNIX) id for ; Fri, 29 Jan 2021 18:52:45 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)xentastic.local[10.0.1.140] port=64955) by more.local([10.0.1.129] port=25) via TCP with esmtp (4499 bytes) (sender: ) id for ; Fri, 29 Jan 2021 15:52:44 -0800 (PST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Fri, 29 Jan 2021 15:52:44 -0800 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Fri_Jan_29_15:52:26_2021-1 Content-Type: text/plain; charset=US-ASCII At Mon, 17 Aug 2020 17:52:08 -0700, Rob Gingell wrote: Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler > > mmap() is descended from TENEX's PMAP, which is a simplified > descendant of the file/process memory integration provided by > Multics. (Other antecedents I leave to more informed genealogists than > I.) Indeed. I see mmap() as just a poor-man's version of Multics segments, and with it being bolted on after the fact, and without integrated language and compiler support, that makes it far less useful. > Multics was most definitely not portable due to its unique hardware > constraints (Intel's 432 being an exception). Well the basic design of Multics would/does fit reasonably well onto the iAPX-386 / IA-32 architecture, though a lone x86 CPU would have been a bit more limited in some capabilities than the Multics hardware was. I think that if more than just OS/2 had made good use of all of the segmentation features of iAPX-386 then possibly CPU designers (including beyond Intel) would have had some incentive to continue to improve it and make it more efficient and effective and indeed to carry it on in full-fledged manner to the x86-64 architecture as well. I think the failure of the iAPX-432 to meet performance expectations, especially with silicon limitations of the day (along with the i960MX never really getting full public exposure), put OS people in general off the idea of building anything better than Unix, which of course only needs a single flat address space and thus ran just fine on the much better performing silicon already available at the same time. I personally also think another problem that limited the porting and evolution of Multics, and the creation of new systems using much more of its design (and thus which favoured the growth of Unix in many ways) was that a lot of commercial OS people were put off by the idea of going with an object oriented model all the way from the languages on top and down through the OS and into the hardware. Too many users were (are) still running applications written in FORTRAN and Cobol and similar, and these were already implemented to use more direct read/write I/O models for data access that Unix supports well. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Fri_Jan_29_15:52:26_2021-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCYBSfvQAKCRBie18UwlnH hfoKAJsH5XDOXgGeahIIU2LBv6n51+sHwACgmTK35vGjDgsYHOFAmwK8I7v4DU0= =Vcjk -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Jan_29_15:52:26_2021-1--