29 Jan
2021
29 Jan
'21
11:52 p.m.
At Mon, 17 Aug 2020 17:52:08 -0700, Rob Gingell <gingell(a)computer.org> 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 <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>