Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!gamma!pyuxp!pyuxe!pyuxf!asg From: asg@pyuxf.UUCP (alan geller) Newsgroups: comp.arch Subject: Re: Is the Intel memory model safe from NO-ONE ?!? Summary: What's the gain of segments? Keywords: 386 intel memory protection management model segmented Message-ID: <314@pyuxf.UUCP> Date: 11 May 88 15:45:10 GMT References: <1806@obiwan.mips.COM> <2904@omepd> <353@cf-cm.UUCP> Organization: Bell Communications Research Lines: 64 Posted: Wed May 11 11:45:10 1988 In article <353@cf-cm.UUCP>, mch@computing-maths.cardiff.ac.uk (Major Kano) writes: > ... > The 32-bit within-segment addresses are what > people have been waiting for for ages. I would question the fact that > only 16 bit selectors are avaliable, but I defy anyone to come up, in the > near or intermediate future, with an Intel-style memory model that is > better than Intel's, without opening up a whole can of voracious > memory-eating killer-worms at the descriptor table level. If you don't > know what I mean by that, pretend for a moment, that YOU were the > person who had to come up with the byte/page granularity > kludge in order to make 4GB segments fit in a DT entry. > ... > I find the segmented architecture is a natural way of protecting programs > and data, and although we often hear negative remarks, no-one seems to be able > to give any coherent justification of such remarks. In particular. no-one has > EVER in my experience directly compared segmenting to straight linear/paging > without TOTALLY ignoring the advantages of segmenting, ie., ease of doing > relocatable code, logical program design (code, data/heap stack separation), > inter-task separation (LDT's) and a few other related features. I don't get it -- what is the advantage of the segmented architecture over the memory mapping model provided by, say, Motorola's PMMU (68851?)? - Why is relocatable code easier with a segmented architecture? I presume you refer to the ability to reset the base of the code and data segments, so that in principle every procedure could think that it starts at (virtual) 0. Of course, this means reloading these segment pointers on every procedure call/return, plus having to use long pointers (64 bits!! including the extra segment register) to access some other procedure's local data. While it is true that this could be simulated on the PMMU, it would be such a kludge as to bring any system to a halt. On the other hand, it's not going to do great things for your performance on the 386, either. - The aforementioned PMMU allows you to separate the data and code address spaces. This does still allow the possibility of stack and heap contention (in a 4 GB arena), but does separate the code from the data, so that code 0 and data 0 are separate. It is also possible, with the 68020 and the PMMU, to still force a code or data access for any given data reference, as one can do with segment prefixes on the 386. - The PMMU supports multiple translation tables. There are special copprocessor instructions that support saving and restoring the mapping state, and the translation cache supports multiple processes. What does the 386 have extra? - What related features? You mean, like the ability to have variable page sizes? You mean, like the ability to provide the result of a logical-to-physical translation to the CPU? You mean, like the ability to see if an address is mapped (probe)? Sure, the 386 model works, but I fail to see how it adds any new power over and above the Motorola PMMU (or the venerable VAX memory model, which is similar). It certainly adds complexity (data segment? extra segment? and what about these new segments? what do they all mean???). Alan Geller Bellcore ...!{rutgers,princeton}!bellcore!pyuxp!pyuxf!asg I'm not responsible for what I said, so how can my employers be??