Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!sdcsvax!darrell From: bobp@vsedev.vse.com (Bob Pearson) Newsgroups: mod.os Subject: Re: Who needs files? Message-ID: <2892@sdcsvax.UCSD.EDU> Date: Sun, 22-Mar-87 14:30:33 EST Article-I.D.: sdcsvax.2892 Posted: Sun Mar 22 14:30:33 1987 Date-Received: Tue, 24-Mar-87 01:38:36 EST Sender: darrell@sdcsvax.UCSD.EDU Organization: Society For The Prevention Of Cruelty To Dinosaurs Lines: 238 Approved: mod-os@sdcsvax.uucp Please excuse the length of the following and the inclusion of ravings of biblical proportions. Also, please excuse me if some of my opinions are not new as I did not have access to "news" when Multics was cancelled and I am new to the net. If I've broken any net etiquette, let me apologize in advance. My comments refer to the HIS (Honeywell Information Systems) Series 60 Level 68 and HIS Series 6000 6180 processors and not the HIS Series 600 645/647 (was General Electric) processors that were discussed in "The Multics System: An Examination of Its Structure" by Elliott Organick (MIT Press 1972). Please reference "The Multics Virtual Memory" (H.I.S. June 1972, AG95 Rev. 0). This is a historical paper on the Multics virtual memory implementation and also describes how rings are implemented in hardware (they were not in the Multics implementation on the HIS 645/647 describe by Organick). As an interesting footnote, Honeywell estimated that the software simulation of rings on the HIS 645/647 took between 10 to 20 percent of total chargeable time, with a hardware implementation of rings it became negligible. yerazuws@lll-crg.ARPA (Crah) writes: >> Multics used the idea of "no such thing as 'files' from the very >> start. Everything was in virtual memory (36-bit addresses, too) >> >> Look where it got them. :-( to which darrell@sdcsvax.UCSD.EDU (Darrell Long) responds: > Actually, the hardware limitations are probably what did Multics in. If a > Multics-like machine was designed today, instead of in 1966, it would probably > be a much better performer. Things like a maximum segment size of 256K (18-bit > segments, 2^18 # of segments), a single 36-bit accumulator, very limited > memory capacity, etc. meant that performance was very limited. And > implementing the MMU (with associative look-up cache), caches, etc. with > ancient technology was very expensive. FLAME (RAVE) ON... I do not agree. The problem with Multics was that is was way ahead of its time and the fact that Honeywell did not know how to market it. The hardware was quite sound given the desire that secondary storage be directly processor addressable. There is a real cost (read high overhead) associated with this capability that has to be weighed against the power it gives you [be very careful here, raving of unimaginable magnitude follows], the best program- ming environment in the world. Compared with IBM's TSO or VM/CMS , DEC's VAX/VMS or TOPS-20 operating systems, or UNIX [your favorite incarnation here] (now you opened a hornet's nest) there is no comparison. It is a crime that so much great work must be lost and the wheel be reinvented again and again. Please do not rave at me with "if Multics was so good, then why wasn't it successful?". I attributed this to the fact that Honeywell didn't know how to market it and never realized what they had. It didn't help that IBM released the IBM 360/67 (CP 67) computer (to compete in the timesharing arena) priced to earn a minuscule 0.009% (read PERCENT) profit. BIG BLUE didn't want to lose any more customers (see DATAMATION, May 1 1986, "Multics Users Face Their Maker" by John W. Verity, pages 103-112). I ascribe the success of UNIX to the fact that it is "portable" across many different architectures (no small feat). Multics needs very specific hardware support to run. Multics was done right (if albeit painfully) and didn't take many easy way outs [design compromises (read kludges)]. It was an extremely elegant design. Maybe its goals were lofty but I for one believe in shooting for the stars. FLAME (RAVE) OFF... > There was no such thing as a "file" in Multics. Everything was a segment, > mappable into virtual memory via a system call. Incorrect. While a process can directly invoke a supervisory routine to make a segment known to a process, the normal method was via a hardware fault (trap). The process of making a segment (procedure or data) known takes a rather lengthly discussion to describe all of the mechanics involved (omitted here). It is not done by a "system call" but a hardware trap. Basically, a reference to a segment (by symbolic name) that does not have a valid segment number assigned [(i.e.) its ITS (Indirect To Segment) word "snapped" in the process combined linkage segment for this ring], would not point to a valid SDW (Segment Descriptor Word) and this would cause a Segment Missing Fault that traps to a specific supervisor module [the SCM (Segment Control Module)] that is mapped into every process address space and has a fixed segment number in the address space. This module is responsible to search the supervisor's database of known and active segments to see if the segment is known by any other process (and hence the supervisor), if it is not, it invokes Directory Control Module procedures to locate the desired segment's directory entry with its location in secondary storage (and access rights, page map, and other file attributes) and brings it into main memory. The final byproduct of all of this is that a SDW is constructed in the descriptor segment, the process access rights are set and the segment descriptor word is made to point to word zero of the page table for this segment and the ITS word is set with k# (an offset to the SDW in the descriptor segment for this process). Now the faulting process can continue executing with a valid k# (the segment is now known). The actually process is unfortunately even more complicated. This process is part of dynamic linking. The address (k#) of the target segment is *NOT* known at reference time. > However, traditional "file" > operations were also allowed. A segment was 18 bits, and there were 2^18 > possible segments (thus the "36 bit addresses", which is as misleading as > saying that an 80286 has "32 bit addresses"). Segments were paged, and there > was a segment table and a paging table keeping track of all this > segmentname-segment# info and virtual-address/real-address mapping. Also, conventional I/O was possible via DIMs (Device Interface Modules), that is another topic definitely. Multics also supported nonpaged segments also, but this is not the issue. > An interesting thing was that all memory was also accessible as a file -- that > is, since a segment can be either interpreted as being a file or as being > memory... there was a "process directory", which contained all these segments, > with randomly-generated filenames (Multics has a tree-structured file/segment > system, which is where Unix got its concept from). Another Multics oddity was > dynamic binding. This may have also had some negative impact on performance, > and really should be considered to be a different topic altogether from having > memory and files as being identical. I am not certain that it is a different topic altogether. Dynamic linking is the single biggest win, in my opinion, with the Multics system. It is indeed built on top of the segmented/paged virtual memory but is part of the justif- ication for all this addressing complexity (as well as the true sharing of pure procedures and read only data). It allows the running of incomplete programs and a debugging environment par excellence. In a traditional system, a link editor resolves all external references to construct a core image using either via real memory addresses, relative to relocation registers or via paged virtual addresses. This is fixed at compile and/or link time. In Multics, global symbol table information is included in an executable module and intra-segment references are resolved on the fly. A change in a procedure involves only a recompilation of the segment in which it is found. VMS or SVR3 shared libraries are not needed as all pure procedure (procedures that do not modify themselves) are shareable. All users reference the same main memory resident pages. As an added bonus, a user can replace a version of a procedure that is part of large subsystem (program) with his own copy by modifying search rules used to find missing segments (before they are made known or *AFTER*), and not have to recompile and link a new "image". I could test this version without my new procedure affecting any other users who are running this subsystem. How's that for flexibility? In Multics, if a segment is pure, its pages are either in main memory or in secondary storage. No special mechanism needs to be invoke, it is the normal operating environment. The combination of a segmented/paged addressing scheme with dynamic linking leads to a very good simulation of an idealized infinite memory. There is a performance penalty associated with this added capability that I for one, think is well worth it. Another unique feature of the Multics system is that changes in access to a segment are immediately enforced. Once a process has access to a segment and the access rights are changed, future references to the segment cause protection violations. What other system does this? > The processor itself (Level-68) was pretty weird. It has a single 36-bit > accumulator, 16 18-bit index registers, 16 32-bit in-segment addressing > registers, and a whole lot of other similarly brain-dead stuff that I can't > remember (it's been 4 years since I last looked at the architecture manual). > All instructions used 18-bit addresses -- that is, the first 18 bits have the > instruction and addressing mode, the second 18 bits is an address (it has 36 > bit words). So most addressing was indexed off one of those 32-bit segment > registers, which is quite a bottleneck if you're wanting to access more > segments than the available # of segment registers. But standard languages > just used a few segments -- a heap, a static variables area, and the stack > segment. The PL/1 compiler was huge, and did some of the funkiest optimization > that I ever saw... necessary, since there was a LOT of operating system, > almost all of it written in PL/1, and you're trying to get decent performance > out of some of the most... bizarre... hardware in existence. > Despite the fastest I/O processors I've ever seen, a triple-processor > Level-68 Multics system could only handle about 100 users before becoming > sluggish. Which is really great for a $5,000,000 system :-). A network of > three Pyramid 98x machines do that, for under a million... it is probably that > fact, rather than anything inherent about treating files as memory, which > accounts for the big flop. An 80386 has most of the architectural features of > Multics, much improved (such as 32 bit addresses, 2^32 # of segments), and > probably would make a much better basis for implementing such an architecture, > than the kluged '60s-era GE hardware (originally intended for GECOS) that > Honeywell cobbled together. I doubt that anybody will ever do it, though, with > Unix around, and Honeywell more interested in bringing GCOS up to bronze-age > standards (bringing it up to modern standards would be nigh impossible...). The restriction of 256K byte segments can be handle via multisegment files and few procedures (ala structured programming) need to be greater that 256K bytes, though data files do. This is not to say that the Level 68 was ideal and could not be much improved but all the great work was done is now dust in the wind (I hope not!!). I believe it is impossible to fairly evaluate Multics hardware by looking at its features and/or capabilities in isolation. Rather, one must look at them as providing a foundation for the support of a truly unique operating system/ developing environment. Multics gave us, rings (domains of execution), dynamic linking, a hierarchical file system that was extremely reliable, control sharing of programs/data via discretionary ACLs (Access Control Lists) and nondiscretionary AIM (Access Isolation Mechanism), demand paging (no thrashing here), unparalleled security, device independent I/O, the concept of files as an extension of memory, IPCs, replaceable execution environments (that a USER could code), a realtime pre- emptive operating system that was highly interactive, the ability to do backups automatically on ACTIVE FILE SYSTEMS, the ability to install changes to the OS without taking the system down, etc, etc... MORE RAVING... One is incredulous that with these features, so far ahead of all its competition of the day (vintage IBM VM/CMS, the TSO of MVS, TOPS-10, TWENEX, VMS, et al), were not enough to save this very elegant operating system. But alas, the Dollar wielded its mighty sword and slayed this sleeping giant. We all know that this is the most important criteria on judging an operating system. If it doesn't make money, it must be a loser. Since Multics could not make it in the real world, it couldn't have been that great of a system. I for one, think Honeywell and the industry in general, didn't know a great thing when they saw it. When I talk to CS students who take OS courses, some say they studied Multics in class and their general impression is that it is a dinosaur, that the operating systems of today are much more advance and elegant. I wonder... I am truly HBD (Honeywell Brain-Damaged), Bob Pearson And now for the BIGGEST RAVE OF ALL TIME... DEFINITION OF UNIX (eunuchs)... Multics without the balls... The opinions expressed here and not the opinions of my employer or of any sane, rational sentient being. btw... I actually like UNIX a lot. ============================================================================= -- -- UUCP: ..!seismo!vsedev!bobp (Bob Pearson) ..!verdix!vrdxhq!vsedev!bobp INET: vsedev.VSE.COM!bobp@seismo.CSS.GOV