[Top] [All Lists]

Re: R5000 support (specifically two-way set-associative cache...)

To: Dominic Sweetman <>,,,
Subject: Re: R5000 support (specifically two-way set-associative cache...)
From: Jun Sun <>
Date: Tue, 20 Jun 2000 12:01:37 -0700
References: <> <> <>
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 Sun wrote:
> Dominic Sweetman wrote:
> >
> > Jun Sun ( 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

<Prev in Thread] Current Thread [Next in Thread>