cur022@zodiac.ukc.ac.uk (Bob Eager) (09/11/90)
In article <26665@bellcore.bellcore.com>, martin@cellar.uucp (Martin Harriss (ACP)) writes: >>segments, use page directories - you get 1MB 'segments' (in MULTICS terms) > > Actually you only get *1024* segments (not 1Mb.) I'm not sure that that would > be enough for a 'real' system. Sorry, what I intended here was that the 'segments' you get are 1MB in size; I realise you only get 1024 of them. I believe that is enough in most cases, since the limitation is per VM and not system wide. > 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? > Don't know about MULTICS, but EMAS did...that's the system I worked on. I'm amazed to hear someone has heard of it! EMAS used a separate linkage area which had to be relocated at load time; it wasn't very large, so the time penalty wasn't too bad. It meant that shared code didn't have to appear in the same place in every VM using it. >>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. Agreed. I was only saying that the actual words used can be confusing. > on a personal note: > Hi, Bob. Still at UKC? I guess some things never change! > Wait and see... > Martin Harriss > martin@cellar.bae.bellcore.com Now I know why he's heard of EMAS! ---------------------+----------------------------------------------------- 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 *************** ---------------------------------------------------------------------------
fetter@cos.com (Bob Fetter) (09/13/90)
In article <20911.26eca5fd@zodiac.ukc.ac.uk> cur022@zodiac.ukc.ac.uk (Bob Eager) writes: >In article <26665@bellcore.bellcore.com>, martin@cellar.uucp (Martin Harriss (ACP)) writes: >>>segments, use page directories - you get 1MB 'segments' (in MULTICS terms) >> >> Actually you only get *1024* segments (not 1Mb.) I'm not sure that that would >> be enough for a 'real' system. > >Sorry, what I intended here was that the 'segments' you get are 1MB in size; >I realise you only get 1024 of them. I believe that is enough in most cases, >since the limitation is per VM and not system wide. If I remember correctly, the *hardware* that Multics runs on has only 64 actual segments which it can access ( this number may be off, but it's a small number none-the-less -- much less than the 386/486 provides). The system uses an indirection from the user's set of "known segments" (each user has their own KnownSegmentTable (KST) with SegmentIDs assigned) to a system-wide SystemSegmentTable (SST). The SST is managed by the memory management kernel software, it mapping the SST entries to the currently-bound hardware segments. If there is a mis-match, one of the hardware segments is "made unknown", and is replaced with the requested reference. This way, the system multiplexed the limited set of hardware segments, providing each user with a virtual view of 1024 segments each (supporting many 10s of users). While this is a bottleneck, the net effect (including, of course, the use of LRU and related techniques for paging) is not all that bad. >> 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? > >Don't know about MULTICS, but EMAS did...that's the system I worked on. I'm >amazed to hear someone has heard of it! EMAS used a separate linkage area >which had to be relocated at load time; it wasn't very large, so the time >penalty wasn't too bad. It meant that shared code didn't have to appear in the >same place in every VM using it. Multics didn't do "relocation" per-se, in that all memory references as generated by the compilers are based on the current code segment and/or the relevent data segment. This, along with any unresolved-at-compile-time references (akin to the ld -A (?) option currently existing in Unix) being built as indirections through a symbol table section of the executable, allowed for pretty clean handling. It didn't take all that time, similar to what I can see EMAS did (the technique appears to be the same here). >>>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. > >Agreed. I was only saying that the actual words used can be confusing. Agreed, too. With the **286 on down, what I expected, given the wording, was not what was provided. . . . >> Martin Harriss >> martin@cellar.bae.bellcore.com > >Now I know why he's heard of EMAS! >---------------------+----------------------------------------------------- >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 *************** >--------------------------------------------------------------------------- As a general note -- I have re-read a few of my earlier postings regarding questions about Multics and am very disappointed with myself regarding the tone and "zealotry" I see myself as having presented. For this breach of Netiquette, I apologize. It doesn't do anybody any good to read the rantings of someone who didn't think before speaking, and it sure doesn't present any information in a form that folks will either read completely through or bother to read at all. If I slip from this, please don't hesitate to let me know and kick me back into a more reasonable place. (I really ought not read news and reply late at night anymore) -Bob-