Path: utzoo!utgpu!watserv1!watmath!att!att!dptg!ulysses!andante!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay) Newsgroups: comp.arch Subject: Re: Porting OSes Message-ID: <10801@pt.cs.cmu.edu> Date: 18 Oct 90 20:02:44 GMT References: <4462@trantor.harris-atd.com> <107038@convex.convex.com> <15007@hydra.gatech.EDU> <10734@pt.cs.cmu.edu> Organization: Carnegie-Mellon University, CS/RI Lines: 31 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Somebody has said on these screens that a Multics port was considered or >done, to some kind of 68K machine, and it would/did cost a few man >years, that is peanuts :-). Since the somebody hasn't spoken up, I will point out that it was the 286/386, not the 68K. The difference is that the Intel hardware supports call gates and hence is the only recent hardware that could give Multics its protection rings. >We are still getting a PDP-11 related programming model on architectures >designed to support Multicses. Recent Unixes are starting now to have >some of what was introduced in Multics and MUSS *twenty* years ago. And >I am quite sure that Multics twenty years ago was far more efficient >that is SVR4/4.3BSD now. This claim of efficiency seems doubtful, since the two had different missions and ambitions. There are things to regret (e.g. security): but they are outside the purview of comp.arch. Multics needed hardware support for rings. The ring idea was long ago replaced by capabilities - a concept that relates well to the recent interest in objects. Some capability/object machines have been built, and even sold. (Does anyone know how to characterize the Biin machine?) HOWEVER, I have seen a number of success stories where capabilities were supported entirely in software. It would be interesting to discuss efficency, and portable OSes, in this more modern context. -- Don D.C.Lindsay