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??