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

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


Nicolas Boulay wrote:
> > - 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 !
i do not agree with "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.
that's one perspective.

> > (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).
> I prefer (2), for the moment.
> >>> We should look more closely to the (3), too.

from another point of view, the LSU+fetcher+TLB block works a bit with (3)
unless i really have understood nothing at all.

After having read some documents yesterday about VM, i'm thinking about
how to enhance the current version. I think that we'll have something
better in a few weeks. Some ideas are floating around my head, i just
have to catch them (at last)...

> nicO
>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/