lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (10/12/90)
In article <15007@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >I believe that DEC has already announced that it is deep into a >project to port VMS to the MIPS machines. The whole idea of porting an OS was new in the mid-70's: most of us hadn't even considered it, until the first Unix port took place. Unix was suitable, not because its developers had allowed for that - they hadn't - but because it was well done, and mostly not in assembler. But Multics (written in PL/I) was well done, and so was MCP (written in Burroughs Extended Algol). Why Unix? Perhaps the biggest (non-political) point was that Unix didn't expect much from the underlying machine. The PDP-11 didn't have much to give! When the VAX design was started, there were people at DEC who wanted to build some flavor of capability/domain machine. It would have been exciting: it would have been risky. The design group finally settled for something that they knew they could make work. It's really quite ironic that their design is now used as an example of complexity. An important consequence is that VMS doesn't expect much from a VAX. And that's why the Mach group at CMU can plan to build a VMS "server" to run on the Mach pure kernel, just as their Unix server does. I think there's a moral here somewhere. -- Don D.C.Lindsay
pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/15/90)
On 12 Oct 90 00:56:20 GMT, lindsay@gandalf.cs.cmu.edu (Donald Lindsay) said: lindsay> The whole idea of porting an OS was new in the mid-70's: most of us lindsay> hadn't even considered it, until the first Unix port took place. Only because nbody knew about the MUSS thingie in the UK. OS-6 was also designed to be portable, but after Unix. MUSS antedates Unix by a lot, and was designed not just to be portable, but to support a heterogenous loosely coupled multiprocessor. References: Ibbett&Morris, "The MU5 computer System", MacMillan; Morris, Theaker, Capon, Frank, etc... "The MUSS operating system" etc..., SP&E, Aug. 1979. lindsay> Unix was suitable, not because its developers had allowed for lindsay> that - they hadn't - but because it was well done, and mostly lindsay> not in assembler. But Multics (written in PL/I) was well done, lindsay> and so was MCP (written in Burroughs Extended Algol). Why lindsay> Unix? 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 :-). lindsay> Perhaps the biggest (non-political) point was that Unix didn't lindsay> expect much from the underlying machine. The PDP-11 didn't lindsay> have much to give! And here we also have the biggest problem: current Unix implementations still mostly assume that common lowest denominator (vide Minix, Xinu). 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. It's difficult to be sure, but if we were to run Multics and SVR4/4.3BSD both on a GE 645 or both on a 486 or both on a MIPS, I think that Multics performance would be better. Not to speak of MUSS, that I saw running on a 68010 years ago, with performance well above that of 4.1BSD, of course. Incidentally, I think a lot of the sophistication in hw architectures is there only because of the pride and whim of the hw designer -- the 80286 has a very sophisticated architecture, where it must not be compatible with the 8086, but I cannot see it having it for anything resembling reasons of market demand. Ditto for many other similar cases, e.g. the MV/8000 rings, the Pr1me I32 mode, etc... "The soul of a new machine" I think is quite revealing on this (the 'no mode bit' struggle!). lindsay> I think there's a moral here somewhere. One of my morals is that hw designers have been *architecturally* far more advanced than OS designers, and this because of UNIX. I am sure that UNIX has evelevated the *median* level of OS use (by replacing loads of AOSes and RSXs out there), but certainly has set back the clock -- current generations of CS students assume that UNIX is all that there is to OS design, and this is a catastrophe, because it is about twenty years behind the state of the art. The beauty of UNIX lies in that its designers have made a particularly efficient compromise between what it should do and the limited resources offered by the hardware. In other words by a very good price/performance ratio at the low performance end of the spectrum. -- 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
tom@stl.stc.co.uk (Tom Thomson) (10/16/90)
In article <10734@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >The whole idea of porting an OS was new in the mid-70's: most of us Not really new. Lots of people had thought about it as part of thinking about introducing a new machine. ICL had not only thought about it, but done it before the mid 70s: old operating systems from the 1900 series were on 2903 (24 bit mainframe os ported to 32 bit mini with 2 instruction streams, null slots after branches, main store requests 3 slots before main store access...) and in the early 70s in Edinburgh my team ran VME/K (2900 mainframe os) and the 5J and Multimac OSs{from S4} in prototype form on 2903 too. The S4 and 1900 OSs were run on 2900 mainframes from mid 70s onwards (and accounted in the early days for far more of the company's revenue than the OSs designed for 2900 mainframes). So porting OSs was sufficiently old hat to be hard commercial business by the mid 70s, not a new idea. Tom[tom%uk03.icl.icl.gold-400.gb@ukc.ac.uk/tom@nw.stl.stc.co.uk/tom@prg.ox.ac.uk
firth@sei.cmu.edu (Robert Firth) (10/18/90)
In article <10734@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >The whole idea of porting an OS was new in the mid-70's To add more to Tom's refutation of this: Strachey's group at Oxford were looking at portable operating systems in the late '60s. They published a lot of papers and monographs on their work between 1968 and about 1972, including the complete source of an OS ('OSpub') written in BCPL and running on their Modular-1 machine. Meanwhile, at the Other Place, Martin Richards and his students were following the path that led to Tripos in (I believe) 1975. So a better chronology is: the idea of porting an OS was new in the mid 60s; by 1970 several different groups had realised that the real issue was not porting an existing OS but designing an OS to be portable; by the mid 70s such OS were a reality.
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (10/19/90)
In article <PCG.90Oct14182345@odin.cs.aber.ac.uk> 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
peter@ficc.ferranti.com (Peter da Silva) (10/19/90)
In article <9110@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: > So a better chronology is: the idea of porting an OS was new in the > mid 60s; by 1970 several different groups had realised that the > real issue was not porting an existing OS but designing an OS to > be portable; by the mid 70s such OS were a reality. By the *early* '70s. UNIX first popped up in '72 or thereabouts. (And my own experience with Tripos, as its incarnation in the Commodore Amiga, is less than thrilling...) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/19/90)
In article <10801@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: | 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. I am amazed that someone hasn't done this. There is enough software for Multics to provide a rich operating environment, and if you could run it on a box which is no more costly than a small unix system there would be a mass market for it, as well. With the proven security you would have a lock on part of the military small system market. The nice thing is that for developers, educators, and just wierd people who have home unix systems, for the price of a disk drive you could have a Multics disk to use or play with. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
henry@zoo.toronto.edu (Henry Spencer) (10/19/90)
In article <9110@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >>The whole idea of porting an OS was new in the mid-70's > >To add more to Tom's refutation of this... Actually, I think a more accurate version of the original statement would be that the idea of porting an OS and getting something useful out of the effort was novel. :-) Several groups had looked at it for systems that were widely (although not always accurately) classed as toys. Unix gave the idea credibility with a real-world system. >... by 1970 several different groups had realised that the >real issue was not porting an existing OS but designing an OS to >be portable... If so this would be a bit ironic, given that Unix was not particularly designed for portability. (It shows in various ways.) -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
pcg@aber-cs.UUCP (Piercarlo Grandi) (10/21/90)
In article <10801@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: In article <PCG.90Oct14182345@odin.cs.aber.ac.uk> 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
axaris@acsu.buffalo.edu (vassilios e axaris) (10/22/90)
In article <2059@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > ************* vis (very interesting stuff) deleted ****************** > >... . What about some research in minimalistic OS >support architectural features? Or does the RISC concept stop at the ALU? >-- Here at SUNY Buffalo such topics are covered (to my surprise at first) in a course on comp. architecture by a professor who's regarded as an authority in microprogrammable (completely horizontal microcode) systems. His name is available upon request. His system, built from discrete SSI logic, occupying a roomful, is still running without a hitch since early 70's! Part of the course was topics as such. To name a few: large multiported register files which support the concept of task and process workspaces, memory management of paged systems supporting a large number of pages (1Meg :-)) using the LRU algorithm implemented in hardware (was a great project to say the least!) task management hardware which supported multitasking at the microprogram level, and provided security at the same level. Undoubtedly complex systems but offering a high level of functionality, for time-sharing as well as real time systems. Needless to say that he was against the RISC philosophy for the simple reason, that all these complex functions could not be supported efficiently due to the approach's simplicity. Anyone care to start a discussion on these topics? :-) Vassilios E. Axaris Dept. of Electrical and Computer Engineering, SUNY at Buffalo.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/23/90)
On 19 Oct 90 15:59:17 GMT, henry@zoo.toronto.edu (Henry Spencer) said: henry> Actually, I think a more accurate version of the original statement would henry> be that the idea of porting an OS and getting something useful out of the henry> effort was novel. :-) Several groups had looked at it for systems that henry> were widely (although not always accurately) classed as toys. Unix gave henry> the idea credibility with a real-world system. I will never tire to repeat that the counterexample is neatly described in the August 1979 issue of SoftPract&Exp and in "The MU5 Computer System" by Ibbett & Morris, MacMillan. Read, read these and weep, thinking of what we would have now instead of SVR4/4.xBSD if we had started from MUSS and not from Unix V7 (a neat system for PDP-11s). Yet in a sense the greatest culprits are the authors of MUSS, who did not have appreciation of the politics of research, and of what it means to offer your system for free to any University who cares to ask. -- 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
tosh-km@aiai.ed.ac.uk (ichi Maeda) (10/25/90)
In article <10801@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >In article <PCG.90Oct14182345@odin.cs.aber.ac.uk> 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 The essential hardware support for Multics is _segmentation_ rather than rings. Segmentation is important both for dynamic linking and resource sharing with the single level store. -- Ken-ichi -------------------------------------------------------------------- Ken-ichi Maeda, AI Applications Institute, University of Edinburgh, 80 South Bridge, Edinburgh EH1 1HN, United Kingdom. -------------------------------------------------------------------- JANET: Maeda@uk.ac.edinburgh ARPA: Maeda%uk.ac.ed@nsfnet-relay.ac.uk BITNET: Maeda%uk.ac.ed@ukacrl.bitnet UUCP: ...mcvax!ukc!ed.ac.uk!Maeda --------------------------------------------------------------------
rteasdal@polyslo.CalPoly.EDU (Falconer) (10/30/90)
In article <41894@eerie.acsu.Buffalo.EDU> axaris@acsu.buffalo.edu (vassilios e axaris) writes: >>-- >Here at SUNY Buffalo such topics are covered (to my surprise at first) >in a course on comp. architecture by a professor who's regarded as an authority >in microprogrammable (completely horizontal microcode) systems. {deleted} >Needless to say that he was against the RISC philosophy for >the simple reason, that all these complex functions could not be supported >efficiently due to the approach's simplicity. >Anyone care to start a discussion on these topics? :-) "Implement a hereditary mechanism capable of supporting the evolution of sentient life while using only four nucleotide bases? Stuff and nonsense!" snorted the eminent Dr. Curmudgeon. :-) -- |||||| Russ Teasdale -- rteasdal@polyslo.CalPoly.EDU -- (Falconer) ||||||| ------------------------------------------------------------------------------- "Gentlemen, if we do not succeed, then we run the risk of failure." - D. Quayle
jesup@cbmvax.commodore.com (Randell Jesup) (11/09/90)
In article <MCI6GLD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >(And my own experience with Tripos, as its incarnation in the Commodore > Amiga, is less than thrilling...) We're trying our best to hide it's origins... ;-) Actually, some of the ideas in it are quite useful (processes for handlers/filesystems, and a few other things), though there were more than a few glaring holes and basic design flaws (it showed it's academic heritage, I'm afraid). It's biggest non-implementation flaws involved basic resource locking issues, and some important missing primitives. Implementation problems included a poor compiler, funny environment, lack of understanding of the multitasking Exec kernal and it's messaging system, and important functions available only from BCPL, not from anywhere else. 2.0 is much improved, expanded, and fixes or fills in most of the flaws (particularily in the original implementation), and it's in C now instead of BCPL, which eases maintenance. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
Bruce.Hoult@bbs.actrix.gen.nz (11/21/90)
In article <272cdde6.7069@petunia.CalPoly.EDU> rteasdal@polyslo.CalPoly.EDU (Falconer) writes: > In article <41894@eerie.acsu.Buffalo.EDU> axaris@acsu.buffalo.edu (vassilios e axaris) writes: > > >Needless to say that he was against the RISC philosophy for > >the simple reason, that all these complex functions could not be supported > >efficiently due to the approach's simplicity. > >Anyone care to start a discussion on these topics? :-) > > "Implement a hereditary mechanism capable of supporting the > evolution of sentient life while using only four nucleotide bases? > Stuff and nonsense!" snorted the eminent Dr. Curmudgeon. :-) Since when is DNA-based life the most efficient possible way to do it? It works, but that's about all you can say about it.
barmar@think.com (Barry Margolin) (11/22/90)
In article <1990Nov21.042907.20211@actrix.co.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: >In article <272cdde6.7069@petunia.CalPoly.EDU> rteasdal@polyslo.CalPoly.EDU (Falconer) writes: >> "Implement a hereditary mechanism capable of supporting the >> evolution of sentient life while using only four nucleotide bases? >> Stuff and nonsense!" snorted the eminent Dr. Curmudgeon. :-) >Since when is DNA-based life the most efficient possible way to do it? It >works, but that's about all you can say about it. Also, if the above quote is intended to suggest that nucleotide bases are analogous to instructions, I think it's a poor metaphor. Nucleotide bases are probably more like digits; in this case, most computers are more "reduced" than genes, because they use only two digits while genes use four. The "opcodes" in DNA use three bases, so they're effectively 12 bits long, which is more than the opcode size of most older microprocessors (e.g. 8080). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
shirriff@sprite.berkeley.edu (Ken Shirriff) (11/22/90)
In article <1990Nov21.185727.22338@Think.COM> barmar@think.com (Barry Margolin) writes: > Nucleotide bases are probably more like digits; in this case, most computers > are more "reduced" than genes, because they use only two digits while genes > use four. The "opcodes" in DNA use three bases, so they're effectively 12 > bits long, which is more than the opcode size of most older microprocessors. DNA triples (opcodes) are equivalent to 6 bits (2 bits per base pair), not 12. By your reasoning, the 8080 has 8 binary digits with 2 values each, making it a 16 bit processor :-) Ken Shirriff shirriff@sprite.Berkeley.EDU "Let no one enter who does not know geometry."