386s and implied OS support

[Piercarlo Grandi]

In article <3806 at geaclib.UUCP> daveb at geaclib.UUCP (David Collier-Brown) writes:
    
    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.

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 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.  

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 at nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg at cs.aber.ac.uk