daveb@geaclib.UUCP (David Collier-Brown) (03/30/89)
From article <18250@gatech.edu>, by ken@gatech.edu (Ken Seefried iii): > I thought about that, but it is my understanding (which surely could > be wrong) that multics is based on dynamicly allocated, variable size > segments of potentially large size. Certainly, the 80286 doesn't fit > this criteria with its fixed size, 64K segments. Also, doesn't > Multics use more than 4 rings of protection? [...] > The 80386 *IS*, however, Multics-on-a-chip... > > ...ken seefried iii > ken@gatech.edu Well, its a "superset of Unix on a chip", but it falls a bit short of a good target machine for Multics. One of the big wins with Mutlicks was the integration of the file system managment with the active segment managment, which allows one to fold about three very large special cases into one (possibly overcomplex) function. This implies: a "known segment" table of large and variable size a large number of segments (ie, not four) a simple mapping from segments to pages (to cut down redundant descriptor information) This is, in my humble opinion, HARD on a 386. Not impossible, but not a shoe-in by any means. To paraphrase Henry, they shold have spent more time building implementation capabilities into the hardware, instead of building policy in... --dave (its easier to put multics on something like the GE machine with 1 accumulator and four address registers [intel segments!] than on a 386) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
pcg@aber-cs.UUCP (Piercarlo Grandi) (04/01/89)
In article <3806@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: From article <18250@gatech.edu>, by ken@gatech.edu (Ken Seefried iii): > I thought about that, but it is my understanding (which surely could > be wrong) that multics is based on dynamicly allocated, variable size > segments of potentially large size. Certainly, the 80286 doesn't fit > this criteria with its fixed size, 64K segments. The multics segments were 2^18 words, i.e. 1meg; to build lareger files one could have multisegment files. This would not be difficult with engineer with 64k segments. I know of another operating system, supporrting segments sizes from 64k to 256k, that did the same, without problems. Also, in most cases 64k is a sufficient size for mapping a file; 95% of files on a tipical Unix machine are < 64k, and the rest can be accessed with a windowing, multisegment scheme. Also, both 286 and 386 have varying size segments, that can grow either upwards or downwards. Only the 8088/8086 has fixed size segments. >Also, doesn't > Multics use more than 4 rings of protection? The Multics hardware has 8 rings, but I am hard pressed to think of any case where more than 4 would have been really needed. This is a non-issue, I reckon. > The 80386 *IS*, however, Multics-on-a-chip... > > ...ken seefried iii > ken@gatech.edu Well, its a "superset of Unix on a chip", but it falls a bit short of a good target machine for Multics. Even the 286 is a sufficiently large subset of a Multics machine, byt the way. One of the big wins with Mutlicks was the integration of the file system managment with the active segment managment, which allows one to fold about three very large special cases into one (possibly overcomplex) function. This implies: ^^^^^^^^^^^ No, actually a memory mapping operating system, that has no files but only persistent (or not) memory segments can be vastly smaller and simpler than one based on files, and also quite a bit faster (if properly implemented). There is no good reason I believe to have traditional file management on a machine that can support persistent segments. a "known segment" table of large and variable size a large number of segments (ie, not four) a simple mapping from segments to pages (to cut down redundant descriptor information) This is, in my humble opinion, HARD on a 386. Not impossible, but not a shoe-in by any means. I beg to differ, this is remarkably as easy on a 386 as on a Multrics machine. The 386 can support a VERY large number of segments, not four; the four you mention are merely the current segments, that can be changed without problems. Also, on a 386 I would use the paging mechanism, not the segmentation one (small model, 32 bit addresses, not large model 48 bit ones) for implementing segments, defining as segment the group of pages that can be mapped by a page table (four megs of addressabiloity). LAST NOTE: the 286 (and 386) large model is segmented and has the bizarre features it has (ring number in the middle of the address instead at the high end, four current segment registers, etc....) because the 286 was designed as a Pascal machine, not a C machine. While C almost mandates a flat address space and the ability to do pointer arithmetic easily, both are irrelevant to Pascal, whose memory model indeed is a 3+1 model. e.g. in Pascal pointers can only be created by new, and deleted by dispose, and there can be no pointers to static or auto data, or procedures, etc... If you think of it, the 286 (and 386) large model architectures fit the bill for a Pascal based Multics like system perfectly. The 386 now has the pageing mode, that does provide the flat, pointer arithmetic favoring, addressing that C likes. Indeed Unixes on the 386 do run with segmentation virtually ignored, in the small model, and use the paging mechanism almost exclusively. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk