Linux MIPS Architecture development
 help / color / mirror / Atom feed
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

  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