[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rep:Re: [f-cpu] virtually or physically-addressed cache ?



-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 01/03/02
Objet: Re: [f-cpu] virtually or physically-addressed cache ?

On Thu, Feb 28, 2002 at 03:09:23PM +0100, Christophe wrote:
> Virtual or physical addressing ?
> -------------------------------------------
> (1) virtually-addressed caches (virtual tags)
> 
> + do address translation only on a cache miss
> + faster for hits because no address translation
> - cache flushing on a context switch (example : local data segments
will get
> an erronous hit for virtual addresses already cached after changing
virtual
> address space, if no cache flushing).
> - synonym problem (several different virtual addresses cannot span the
same
> physical addresses without being dupplicated in cache).

Abgelehnt. This one causes severe problems.

>>> Not really, it causes waste space, only !

> (2) physically-addressed caches (physical tags)
> 
> - do virtual-to-physical address translation on every access

Not necessarily. The TLB lookup can be started as soon as loadaddr (or
one of its variants) is called, and doesn't have to be repeated in all
cases (e.g. with a postincremented pointer, you'll perform a range check
first and only do a full lookup if the range check fails).

>>> Consider that the LSU is a kind of virtually addressed caches.

> - increase in hit time because must translate the virtual address
before
> access the cache

See above - the LSU may cache the results of the TLB lookup.

>>>See above, too ;p

> + no cache flushing on a context switch
> + no synonym problem (several different virtual addresses can span the
same
> physical addresses : a much better hit ratio between processes)

Looks fine.

> (3) virtually-addressed caches (physical tags)
> 
> + address translation in parallel with cache access
> + same fast hit time as a virtual cache : increase in hit time can be
> avoided because address translation is done in parallel with the cache
> access
> - restrict cache size so that cache index bits shall be in the page
offset
> (page offset bits are the same for virtual & physical addresses)
> - compare the physical tag from the cache to the physical address
(page
> frame #) from the TLB
> - If the cache is too small, only can increase cache size, but still
use
> page offset bits for the index, by increasing associativity

This may become *very* hairy with variable page size. We'd have to use
the minimum page size (1K? 4K?) on order to keep it simple. That's only
10...12 index bits (and probably 128-way or more).

> + no cache flushing on a context switch
> + no synonym problem (several different virtual addresses can span the
same
> physical addresses : a much better hit ratio between processes)
> 
> Conclusion - which one is better ?

I prefer (2), for the moment.

>>> We should look more closely to the (3), too.
nicO

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/