Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!sdcsvax!darrell From: darrell@sdcsvax.UCSD.EDU (Darrell Long) Newsgroups: mod.os Subject: Re: Who needs files? Message-ID: <2875@sdcsvax.UCSD.EDU> Date: Tue, 17-Mar-87 03:51:25 EST Article-I.D.: sdcsvax.2875 Posted: Tue Mar 17 03:51:25 1987 Date-Received: Sat, 21-Mar-87 10:30:28 EST Lines: 71 Approved: mod-os@sdcsvax.uucp yerazuws@lll-crg.ARPA (Crah): > 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. :-( 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. I currently attend a university that has an old Multics unit hanging around, the University of Southwestern Louisiana (although USL-Multics is being replaced by an IBM 3090 -- ick). For those of you who've never seen a Multics system and how it does its "all files are segments and are mappable into the address space" trick, a quick description follows: There was no such thing as a "file" in Multics. Everything was a segment, mappable into virtual memory via a system call. 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. 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. 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 similiarly 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...). -- Darrell Long Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp Operating Systems submissions to: mod-os@sdcsvax.uucp