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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.