Oops! My bad!
I meant to talk about Vr5000 but I was looking at the Vr5432 manual!
So here is the clarification :
1. both CPUs have two-way set-associative caches
2. Vr5432 uses vAddr:0 to select the way
3. I am not 100% sure about Vr5000. I think it actually uses vAddr:4,
the MSB of cache line size. If this is true, the
reducing-line-size-by-half trick would work for Vr5000.
Sorry for the confusion.
Jun
Jun Sun wrote:
>
> Dominic Sweetman wrote:
> >
> > Jun Sun (jsun@mvista.com) writes:
> >
> > > 2. Specifically, NEC Vr5000 has two-way set-associative cache. I
> > > browsed through the cache code, and got concerned that I don't see any
> > > code that seems to take care of that. Do I miss something?
> >
> > The two-way cache on the R5000 (and its R4600 parent) is implemented
> > so that the cache operations used during running don't have to know
> > about the cache organisation. Even initialisation of an R5000 cache
> > can be done by a piece of code which has no reference to two-wayness
> > and just works over R4x00/R5000 CPUs.
> >
> > So this is not *necessarily* a problem.
> >
>
> I am not sure here.
>
> Vr5000 uses vAddr:0 (bit 0) to select the way in a set. I just cannot
> imagine how you can invalidate both ways without referring to some
> vAddrs that end with 1.
>
> I understand some CPUs (perhaps R4600 is so?) uses the most-significant
> bit within the cache line to select the way. In that case, one can just
> treat the line size as half as what the actual line size is, and the
> cache can be treated as if they are directed mapped. But I believe this
> can not be the case with Vr5000.
>
> Can someone familiar with R4600 tell us more about how R4600 cache is
> setup to hide two-wayness? Thanks.
>
> Jun
|