Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.misc
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <2112@crdos1.crd.ge.COM>
Date: 9 Feb 90 18:15:00 GMT
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <33823@news.Think.COM>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 17

In article <33823@news.Think.COM> barmar@think.com (Barry Margolin) writes:

| Actually, the hardest thing about porting Multics to an entirely different
| architecture would have been fixing all the "fixed bin (17)" and "fixed bin
| (35)" declarations in nearly every single PL/I source file.  Demand-paged
| virtual memory is about all it really requires from the hardware, and no
| one would think of doing a serious timesharing system without this these
| days.  

  I suspect that you could get around the first problem, but I think you
miss the importance of the rings of privilege in the CPU. When I first
saw the 386 spec I thought of Multics. I believe that a lot of the
performance comes from having this in hardware, and that four instead of
eight rings could be used because they are done in pairs now.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me