386s and implied OS support

[David Collier-Brown]

>From article <18250 at gatech.edu>, by ken at 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 at 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