From: | Edward Feustel <efeustel@hughes.net> |
Newsgroups: | comp.compilers,comp.arch |
Followup-To: | comp.arch |
Date: | Tue, 09 Dec 2008 08:07:45 -0500 |
Organization: | Compilers Central |
References: | 08-12-025 08-12-039 08-12-042 08-12-049 |
Keywords: | architecture, history |
Posted-Date: | 10 Dec 2008 16:50:54 EST |
X-DF-Seen-By: | ms |
On Mon, 08 Dec 2008 04:05:07 -0700, Glen Herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
>George Neuner wrote:
>(snip)
>
>> The problem wasn't segmentation per se, but using segmentation as the
>> _only_ isolation mechanism ... and the segment limits were too small.
>> Using segments+paging in 32-bit mode on the 386 and 486 was fun. The
>> Pentium and follow-ons reduced the descriptor cache to just 2 entries
>> and made general switching of segments painful.
>
>I have heard rumors about a descriptor cache but I never found
>anything about one in any intel documentation. (I did look.)
>
>Are there processors that will check if the selector is the same
>as the current selector won't reload the descriptor? I don't
>even remember seeing that, but it wouldn't seem hard.
>
>Otherwise, even a small descriptor cache could speed up code
>using multiple segments by a large factor.
>
>-- glen
>[I never saw an x86 with any sort of performance boost for segments, not
>even noticing that you were reloading the same selector. -John]
And a segment cache did speed up the Prime computers and the Multics
system. Unfortunately Intel decided to deprecate segments so that
switching segments on the X86 series is excruciatingly slow compared
to what it could be. Then because of their size, no one wanted to use
them.
I don't know for certain if the Intel 960XA had a segment cache, but I
believe it did.
Regards,
Ed Feustel
Return to the
comp.compilers page.
Search the
comp.compilers archives again.