Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@oss.sgi.com
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
Date: Thu, 11 Jul 2002 19:27:17 +0400	[thread overview]
Message-ID: <3D2DA3D5.66664759@niisi.msk.ru> (raw)
In-Reply-To: Pine.GSO.3.96.1020711152156.7876E-100000@delta.ds2.pg.gda.pl

> >
> > There're two possible optimization:
> > 1. (Requires only the instruction that swaps caches must run uncached)
> >       CPU may skip implementation of double check of cache hit on loads.
> >       Scenario: mtc0 with cache swapping with ensuring next instructions are
> > in cache
> >       (pipelining here!); swap occurs; must check again the instructions are
> > in
> >       the cache because the same cacheline in the data cache may have valid
> > bit set
> >       and CPU will get data instead of code.
> 
>  I can't really see a problem here for proper implementations.  The CPU
> may have fetched a few instructions beyond the mtc0 doing a cache swap.

Load from memory into I-cache, setting the valid bit.

> It's OK since we didn't modify the code.  As long as the swap doesn't
> complete, the CPU is using the real I-cache.  Once it's completed, it uses
> the D-cache.  Since the new cache is used in the normal mode of operation,
> now tag matches and line replacements occur here as if it was the real
> I-cache.  No need to do any extra checks at any stage.

Have to check the cacheline at given address again. D-cache may have the
valid bit set for the cacheline at the same address. Address means
location in a cache, not memory. Check at address requires one extra
tick as opposed to checking the bit.

Please, note that CPU isn't a monolitic program, but rather a set of
functional blocks, so "proper implementation" may require additional
signals on wires and delays.

> 
>  It's possible they broke something, simply.

My guess they implemented No. 1. more or less.

Anybody from IDT here with strong willing to broke NDA ? :-)

Regards,
Gleb.

  reply	other threads:[~2002-07-11 15:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-10 14:16 mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96 Jon Burgess
2002-07-11  0:15 ` Ralf Baechle
2002-07-11  8:48   ` Gleb O. Raiko
2002-07-11  9:18     ` Carsten Langgaard
2002-07-11 10:06       ` Gleb O. Raiko
2002-07-11 10:15         ` Carsten Langgaard
2002-07-11 10:36           ` Gleb O. Raiko
2002-07-11 10:46             ` Carsten Langgaard
2002-07-11 11:12         ` Ralf Baechle
2002-07-11 17:01           ` Maciej W. Rozycki
2002-07-11 23:02             ` Dominic Sweetman
2002-07-12  0:24               ` Ralf Baechle
2002-07-12 10:37               ` Gleb O. Raiko
2002-07-12 18:40               ` Maciej W. Rozycki
2002-07-11 11:23         ` Maciej W. Rozycki
2002-07-11 13:11           ` Gleb O. Raiko
2002-07-11 13:41             ` Maciej W. Rozycki
2002-07-11 15:27               ` Gleb O. Raiko [this message]
2002-07-11 15:59                 ` Maciej W. Rozycki
2002-07-12 10:26                   ` Gleb O. Raiko
2002-07-12 19:02                     ` Maciej W. Rozycki
2002-07-15  9:16                       ` Gleb O. Raiko
2002-07-16  9:00                         ` Maciej W. Rozycki
2002-07-16 10:20                           ` Gleb O. Raiko
2002-07-16 10:36                             ` Maciej W. Rozycki
2002-07-11  7:34 ` Carsten Langgaard
  -- strict thread matches above, loose matches on Subject: below --
2002-07-11  9:49 Jon Burgess
2002-07-11 12:13 ` Ralf Baechle
2002-07-12  9:18 ` Carsten Langgaard
2002-07-11 12:11 Jon Burgess
2002-07-11 16:53 ` Jun Sun
2002-07-11 16:33 Jon Burgess
2002-07-12  9:08 Sedjai, Mohamed
2002-07-12  9:08 ` Sedjai, Mohamed
2002-07-12  9:26 ` Geert Uytterhoeven
2002-07-12  9:40 ` Carsten Langgaard
2002-07-12 15:24 Jon Burgess
2002-07-15  9:42 Jon Burgess
2002-07-22  8:18 Sedjai, Mohamed
2002-07-22  8:18 ` Sedjai, Mohamed

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=3D2DA3D5.66664759@niisi.msk.ru \
    --to=raiko@niisi.msk.ru \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /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