linux-mips
[Top] [All Lists]

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

To: Dominic Sweetman <dom@algor.co.uk>
Subject: Re: R5000 support (specifically two-way set-associative cache...)
From: Jun Sun <jsun@mvista.com>
Date: Tue, 20 Jun 2000 11:41:10 -0700
Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com, nigel@algor.co.uk
References: <394EA5A0.B882F66A@mvista.com> <200006200947.KAA08574@mudchute.algor.co.uk>
Sender: owner-linux-mips@oss.sgi.com
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

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