EAF@.Prime.COM (09/06/90)
The micro which most closly approaches the Multics model is the INTEL 960XA which was used in the BiiN architecture. Unfortunately the 386 and 486 do not feature a page table for every segment, even though they do have rings of protection. Further if I understand correctly, they do not have protection at the segment level but rather at the page level. These facts would make the "simulation" of multics difficult.
cur022@zodiac.ukc.ac.uk (Bob Eager) (09/07/90)
In article <72900004@.Prime.COM>, EAF@.Prime.COM writes: > Unfortunately the 386 and 486 do not feature a page table for every > segment, even though they do have rings of protection. Further if I understand > correctly, they do not have protection at the segment level but rather > at the page level. These facts would make the "simulation" of multics > difficult. I worked on a MULTICS-style OS for some years, and idly looked at the 386 architecture to see if it could be done on there. I think the thing to do is to ignore the 386 segments - just map a couple of 4GB ones on to the whole VM (one for code, one for data). For the MULTICS segments, use page directories - you get 1MB 'segments' (in MULTICS terms) then. The use of the term 'segment' for the Intel 8088-style contruct (albeit bigger on the 386) tends to push one's thinking in the wrong direction... ---------------------+----------------------------------------------------- Bob Eager | University of Kent at Canterbury rde@ukc.ac.uk | +44 227 764000 ext 7589 ---------------------+----------------------------------------------------- *** NB *** Do NOT use the return path in the article header *************** ---------------------------------------------------------------------------
martin@cellar.uucp (Martin Harriss (ACP)) (09/11/90)
In article <20907.26e6edac@zodiac.ukc.ac.uk> cur022@zodiac.ukc.ac.uk (Bob Eager) writes: >In article <72900004@.Prime.COM>, EAF@.Prime.COM writes: >> Unfortunately the 386 and 486 do not feature a page table for every >> segment, even though they do have rings of protection. Further if I understand >> correctly, they do not have protection at the segment level but rather >> at the page level. These facts would make the "simulation" of multics >> difficult. Actually, the 386 architechture has protection at both the segment and the page level. However, the page level protection is less comprehensive than the segment level protection (which I guess is actuallaly what you'd want for multics.) >I worked on a MULTICS-style OS for some years, and idly looked at the 386 >architecture to see if it could be done on there. > >I think the thing to do is to ignore the 386 segments - just map a couple >of 4GB ones on to the whole VM (one for code, one for data). For the MULTICS >segments, use page directories - you get 1MB 'segments' (in MULTICS terms) >then. Actually you only get *1024* segments (not 1Mb.) I'm not sure that that would be enough for a 'real' system. It also implies that you do relocation whenever you load an executable segment. Not neccessarily a bad thing, but it does take time... Did Multics do this? what about EMAS? >The use of the term 'segment' for the Intel 8088-style contruct (albeit bigger >on the 386) tends to push one's thinking in the wrong direction... Actually, I think that the segmentation model, as implemented on the 386 (as opposed to the 8086/66) is very powerful. It would, however, be considerably more useful if there were high level language support for full 48 bit pointers. You would then be able to write code which would (dynamically) load in any segment. You would also be able to access any external segment (again, dynamically) by using the appropriate long pointer. Has anybody hacked the GNU 386 compiler to do long pointers? >Bob Eager | University of Kent at Canterbury on a personal note: Hi, Bob. Still at UKC? I guess some things never change! Martin Harriss martin@cellar.bae.bellcore.com