Xref: utzoo comp.unix.microport:3059 comp.unix.questions:12537 comp.unix.wizards:15300 Path: utzoo!yunexus!geac!geaclib!daveb From: daveb@geaclib.UUCP (David Collier-Brown) Newsgroups: comp.unix.microport,comp.unix.questions,comp.unix.wizards Subject: 386s and implied OS support Message-ID: <3806@geaclib.UUCP> Date: 30 Mar 89 03:01:54 GMT Article-I.D.: geaclib.3806 References: <18250@gatech.edu> Organization: GEAC Computers, Toronto, CANADA Lines: 38 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