barmar@think.com (Barry Margolin) (02/09/90)
O boy! In case we weren't having enough fun NeXT-bashing, now it's time to bash poor, defenseless Multics.... I've directed followups to comp.misc, because this isn't really about architecture. In article <1990Feb7.221800.804@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2093@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >> The only reason Multics is not where UNIX is today is that it was >>developed by one company which didn't know how to sell computers and >>then rights went to another... >I can think of several other reasons, actually, starting with Multics >being much larger, being much fussier about memory management and >such, and performing very poorly by comparison. Unix did not suddenly >spring into its position of prominence when hardware reached current >levels -- it steadily grew into it through ability to run well on small >machines (most Unix machines were small until very recently) and ability >to port to almost anything. Multics had no hope of ever copying that. Everything you say about Multics is true. It was heavily dependent on the architecture of the Honeywell (formerly GE) mainframes. For most of its lifetime about the only other machines with the necessary features were the IBM 370 and its followons and Burroughs systems. The first microprocessor that could reasonably support a Multics-like OS was the 80386 (a friend of mine claims to have implemented a small Multics clone for the 386). But I don't think this was the reason why Multics didn't sell well. For most of the 70's, the points you make were not very important considerations in the mainframe computer marketplace. GCOS wasn't portable, and ran on almost the same processors as Multics, yet Honeywell was able to sell orders of magnitude more GCOS systems than Multics systems. I've heard of cases where a Honeywell customer wanted to buy a Multics system and the salesman tried to talk him into GCOS! Your points would explain why Multics didn't sell well into the small business market, but no one ever claimed that was Multics's target market. Multics was designed to be a computer utility, taking advantage of economies of scale (is symmetrical multiprocessing one of those things we don't really need?). Compare it to other utilities, such as phone systems: there are different considerations when designing a PBX than a central office switch. 5ESS wouldn't be expected to be portable to the hardware for an office PBX. The question isn't why PDP-11 Unix sold better than Multics, but why VM/CMS did. Regarding whether Multics's feature are "needed", over the years I've been amazed at the number of requests for facilities I've seen in the Unix newsgroups where Multics has had that feature for fifteen years. Things like prioritized printing and batch queues, better process priority control, useful library routines (e.g. for wildcard matching), decent backup facilities, interprocess communication, and user-mode device drivers. One might argue that the hardware-supported security mechanisms aren't really required, but the hardware support is precisely what is needed to protect against viruses efficiently (see comp.virus for discussions about hardware support to limit the capabilities of programs to modify other programs); the originial Multics implementation did most of it in software, and there were known security holes that were closed when hardware rings were implemented. And Multics's performance problems weren't directly related to its features. The Honeywell processors on which Multics ran lagged behind the industry in performance. This may have been partly because the additional features Multics required had to be grafted on after the processor was designed for GCOS. Around the time Multics was cancelled they finally designed a processor for GCOS on which Multics could have run directly (actually, it had a minor problem with null pointers -- it would fault upon loading (not indirecting through) them), but Multics was never ported to it. 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. The dynamic linker could be reimplemented without the special hardware support that the Honeywell processors provided. And hardware segmentation isn't really necessary; a flat address space can be treated as segmented merely by calling the high-order N address bits the segment number, and using software to manipulate all the pages of a software segment as a unit; hardware segmentation is mostly a way to implement larger address spaces with smaller MMU tables, since many of the attributes of a page are common to all the pages in a segment (such as access modes and location on disk). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/10/90)
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