From: Jun Sun <jsun@mvista.com>
To: Dominic Sweetman <dom@algor.co.uk>,
linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com,
nigel@algor.co.uk
Subject: Re: R5000 support (specifically two-way set-associative cache...)
Date: Tue, 20 Jun 2000 12:01:37 -0700 [thread overview]
Message-ID: <394FBF91.76AE6FD0@mvista.com> (raw)
In-Reply-To: 394FBAC6.3D29C4A7@mvista.com
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
next prev parent reply other threads:[~2000-06-20 19:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-19 22:58 R5000 support (specifically two-way set-associative cache...) Jun Sun
2000-06-20 1:51 ` Ralf Baechle
2000-06-20 8:44 ` Geert Uytterhoeven
2000-06-20 9:47 ` Dominic Sweetman
2000-06-20 10:02 ` Geert Uytterhoeven
2000-06-20 18:41 ` Jun Sun
2000-06-20 19:01 ` Jun Sun [this message]
2000-06-20 20:59 ` Dominic Sweetman
2000-07-01 1:22 ` Jun Sun
-- strict thread matches above, loose matches on Subject: below --
2000-07-01 6:46 Kevin D. Kissell
2000-07-01 6:46 ` Kevin D. Kissell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=394FBF91.76AE6FD0@mvista.com \
--to=jsun@mvista.com \
--cc=dom@algor.co.uk \
--cc=linux-mips@fnet.fr \
--cc=linux@cthulhu.engr.sgi.com \
--cc=nigel@algor.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox