From: Jun Sun <jsun@mvista.com>
To: Dominic Sweetman <dom@algor.co.uk>
Cc: 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 11:41:10 -0700 [thread overview]
Message-ID: <394FBAC6.3D29C4A7@mvista.com> (raw)
In-Reply-To: 200006200947.KAA08574@mudchute.algor.co.uk
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 18:43 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 [this message]
2000-06-20 19:01 ` Jun Sun
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=394FBAC6.3D29C4A7@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