Path: utzoo!dciem!nrcaer!xios!greg From: greg@xios.XIOS.UUCP (Greg Franks) Newsgroups: comp.arch Subject: Re: Is the Intel memory model safe from NO-ONE ?!? Message-ID: <524@xios.XIOS.UUCP> Date: 17 May 88 17:34:21 GMT Article-I.D.: xios.524 Posted: Tue May 17 13:34:21 1988 References: <1806@obiwan.mips.COM> <2904@omepd> <353@cf-cm.UUCP> <3384@drivax.UUCP> Reply-To: greg@sdn.UUCP (Greg Franks) Organization: XIOS Systems Corporation, Ottawa, Ontario, Canada Lines: 68 In article <3384@drivax.UUCP> alexande@drivax.UUCP (Mark Alexander) writes: >Maybe I'm slow, but I can't see how segmentation makes these things >much easier, compared with a typical non-segmented paging system. We >did a port of FlexOS to both the 386 and the NEC V60, and the V60 was >actually easier to deal with precisely because we didn't have to muck >with all that segment stuff. And on the V60 it was very easy to >achieve all these Nice Things you mentioned, like code/data >separation, relocatability, inter-task protection, etc. > >Hoping someone can explain this to me in a followup article. >-- >Mark Alexander (UUCP: amdahl!drivax!alexande) >"Bob-ism: the Faith that changes to meet YOUR needs." --Bob (as heard on PHC) Well, I hope this helps. First, the Intel way of doing segmenting is totally brain damaged. I am sure that you will hear few arguments in this group to the contrary. The biggest win when segmenting is implemented properly, is that it allows you to put individual items into separate segments and then use the hardware protection mechanisms to catch illegal references. Bounds checking can be done in parallel to program execution because explicit 'check' instructions need not be included in the program. Ideally, one would have an unlimited supply of segment registers so that every `object' in a program could be isolated from one and another. Trampling over data is worse than trampling over code, simply because you will more likely get the *wrong* answer instead of *no* answer. Of course, some dated-but-popular languages ignore things like checking bounds on arrays, so they merrily allow one to trample all over data with errant pointers and indicies. In fact, I think that C makes array bounds checking almost impossible due to the uncontrolled manner in which pointers can be used (Is that the fire alarm I hear ringing?) However, please don't quote me on that thought because I am *not* a compiler designer. The *BIG BOTCH* in the Intel 80*86 scheme of things is the position of the protection and table descriptor bits. They occupy the low three bits of the segment register. So address 0x00010000 in a flat address space is represented as 0x00080000. Consequently one gets all sorts of convoluted 'memory models' and performace hits to perform: real_address = (virt_address & 0x1fff0000) << 3 + virt_address & 0x0000ffff Had Intel put these bits at the high end of the address register, the 80286 could have a *flat* address space, albeit _only_ (:-)) 29 bits wide. Personally, I find it interesting that each entry in the descriptor tables is 8 bytes long ( 1 << 3 == 8 ). The machine could also stand quite a few more segment registers, and a more convenient way of loading them. Oh well, too late now.... Segmenting can be faked on a paging system by putting each object in its own set of pages in memory. For example, each UNIX process has two segments, text and data. An 80286 would probably run version 6 quite nicely! :-). See Structured Computer Organization by Andy Tanenbaum for more info. Personally, I suspect that segmenting (done right) may catch on again as object oriented languages like C++ and (gasp) Ada catch on. Good day eh! -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, utzoo!dciem!nrcaer!xios!greg Ottawa, Ontario, Canada, K1Z 8R8. (613) 725-5411. "Those who stand in the middle of the road get hit by trucks coming from both directions." Evelyn C. Leeper.