All of lore.kernel.org
 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 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.