Re: PART 3. Why it seems difficult to make an OOO VAX competitive (really long)
- From: "Peter \"Firefly\" Lund" <firefly@xxxxxxx>
- Date: Tue, 9 Aug 2005 14:41:04 +0200
On Tue, 9 Aug 2005, Nick Maclaren wrote:
That's an implementation misdesign. There is no reason that they should be any slower than page-based virtual memory.
Segments on the IA-32 may not behave the way you expect. The base gets added to the logical address (formed by a displacement or an immediate or a register or ...) which in turn gets you the virtual address. Only then (or rather, in parallel with the cache lookup) are the TLBs consulted.
The TLBs would have to know which segment register was used with the logical address -- or rather which selector (the contents of the segment register) -- was used to form the virtual address. Actually, that's not quite true, either. It depends on the base/limit fields of the segment descriptor, which gets loaded from either the local or the global descriptor table, depending on a bit in the selector.
And it is perfectly possible, valid, and normal to use several segment registers and selectors to access the same virtual address.
To sum up: I don't see how the TLBs should be designed to handle the base/limit stuff.
(Limit checking could presumable happen in parallel with the cache access -- I don't see why it should add extra cycles. Nor why it should involve the TLBs ;) .)
-Peter .
- References:
- Re: Code density and performance?
- From: Eric P.
- Re: PART 3. Why it seems difficult to make an OOO VAX competitive (really long)
- From: Nick Maclaren
- Re: Code density and performance?
- Prev by Date: Re: PART 3. Why it seems difficult to make an OOO VAX competitive (really long)
- Next by Date: Re: Code density and performance?
- Previous by thread: Re: PART 3. Why it seems difficult to make an OOO VAX competitive (really long)
- Next by thread: Re: PART 3. Why it seems difficult to make an OOO VAX competitive (really long)
- Index(es):
Relevant Pages
|