Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!primerd!tiger1!efeustel From: efeustel@prime.com (Ed Feustel) Newsgroups: comp.arch Subject: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: Date: 22 Mar 91 14:06:06 GMT References: <1991Mar21.164242.886@sj.nec.com> Lines: 63 Nntp-Posting-Host: tiger1 As a vendor of segmented architectures, Prime has both an understanding of and appreciation for the benefits and drawbacks of segments. Given a segment whose size can range from 1 - 4GB and given enough of them on a per process basis, one can construct a very good(efficient, secure, etc.) operating system. The major difficulty with a segmented architecture in today's marketplace arises from the use of the language C and C's notion of a pointer as the total address. On a segmented architecture of the Multics variety, any address consists of a compound (and probably .) where S is the segment number, N is an offset in bytes (words), and P is protection information which might include the process number. C assumes that pointers are linear and monotonically increasing. So for C, I must add offsets to take me from one segment to another. Other languages do not have such a limited notion of what an address is and can deal with the fact that an address is a structure rather than an elementary object. If you are saddled with small segments with N < 2**18 or so, you will soon come to hate segments because you have to continually map C addresses onto multiple segments in order to support the linear model. With N ~ 2**32 this is much less of a problem since the need for individual objects of this size is much reduced. One still has a problem with S < 4096 if one adopts the notion of one "object" per segment. This is true even if the address space has a range of unique segment numbers for each process as well as a range of segment numbers which are global. If S>256K, this problem is much reduced. Even with Intel's scheme, the problem is not severe if the granualarity of objects is large enough. Note the size of Intel's address space is 2**13 * 2**32 shared bytes for all processes + n * 2**13 * 2**32 bytes, where n is the number of processes. This logical address space is mapped to the currently implemented 2*32 paged address space which is mapped to a maximum of 16 M.b. to 64 M.B. by the physical architecture of your P.C. Assuming that protection, sharing, and process address spaces are structured on the basis of segments, each of which has its own independent page table (which allows the segment/object to expand and contract independent of all other objects), highly reliable and efficient operating systems can be constructed which have the property that page table overhead is minimized. It should be noted that Intel has chosen to implement page table per process rather than page table per segment on the 386/486. They did do "the right thing" on the 960XA used by BiiN and the military. By using the same page table for every process, sharing of the operating system, code of shared libraries, etc. is enabled. Another difficulty often cited is the requirement of loading segment registers and the cost of doing this. This is an artifact of Intel's 386/486 architecture/implementation which was designed when Silicon area was at a premium. An intelligent implementation in which attention is given to the use of segments need not require such a high penalty for changing segments (as IBM and HP can attest). This is obviously a trade off between registers used for pointing and tlbs which contain the segment information. Thus the intelligent designer should try to discern why the feature is desired, what it costs, and whether its use can be exploited pervasively before disgarding it based on experience with "an existing implementation". Of course I speak for myself and not for Prime when I advocate a re-examination of the benefits of segments. Ed Feustel Prime Computer