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

[Michael Riepe <michael@stud.uni-hannover.de>]

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.

> (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).

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

> + 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.

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