🚀 go-pugleaf

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