Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg From: pcg@aber-cs.UUCP (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Porting OSes Summary: Indeed KeyKOS for 68000, Multics for 386. Keywords: KeyKOS Multics 68000 386 Message-ID: <2059@aber-cs.UUCP> Date: 21 Oct 90 13:29:48 GMT Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal) Lines: 87 In article <10801@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: 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. Yes, yes, it was my slip. I got mixed up with the port of KeyKOS to the 68k, not of Multics. >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. To me it seems that SVR4 and 4.3BSD have all the same missions and ambitions as Multics, and Multics could support much greater loads on much slower hardware than SVR4 and 4.3BSD can now; just look at the different sizes of the wired down kernel code, where Multics is significantly smaller, or at the working sets of similarly powerful sw under both architectures. Raw impressions, but I reckon fairly indicative. On the other hand you might observe that the 'computer utility' dream is dead -- but that was a dream after all. Multics in practice was about timesharing and sw development and databases etc... The areas of functionality of SVR4/4.3BSD and Multics are almost the same. It may be argued that Multics is a streamlined, minimalist, efficient, lean and mean successor to and redesign of SVR4/4.3BSD. Unfortunately for this argument it predates them by 25 years. 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. That's KeyKOS for one (see above the 68k confusion). But however successful sw capability architectures may have been technically, they have been a dead flop as to popularity. The nearer you are to MSDOS the better as to that. :-(. Just consider a 'success' story near (your) home: Accent can be characterized as a sw capability system. It was a technical success and a popularity flop. Now Mach, which is what one can put of Accent under UNIX, i.e. technically a backwards step, is getting popular (even if it is ten years old technology), because nobody knows it is a sw capability system that really has nothing to do with UNIX (which is technically a backwards step from Multics, a twenty five years old technology), not even by now a passing resemblance (under the hood, that is). Maybe Accent died because it was written in Pascal and was not ported to many things as it was a commercial product tied to a struggling small company (and a large hapless British one :->). Or maybe because it was outside the "mainstream". As to sw capability systems, my current research, often hinted at on these columns, is about a sw capability system for non shared memory heterogenous multiprocessors, where all capabilities are capabilities to continuations (read "protected procedures"). This is reminiscent of the PDP-1 (that far back!). The most recent unorthodox, little known developments in the sw capability field that I know of are Elmwood and Psyche from Rochester, in which I have found many good old ideas (much the same I have been working on, but with interesting twists...) nicely executed in some original way (...as their target is a NUMA shared memory homogenous parallel machine). There are many many other more orthodox research sw capability systems, but I still regard the commercially developed KeyKOS as the best example. Finally: what about building-block support for OS architectures? Instead of providing sophisticated support for particular OS styles, hardware designers should provide simple architectural features that can be used in sw for building more sophisticated OS support technology. For example, the i386 is CISC also in its model of OS services to support. The problem I see is that many compiler-wise RISC machines are too simplified in their OS support technology, or too complicated. After all benchmarks sell machines, and benchamrks are about raw speed, not OS usefulness... (vide the catastrophic problems with the existing SPARC implementations and their MMUs). What about some research in minimalistic OS support architectural features? Or does the RISC concept stop at the ALU? -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk