From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>,
"Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Cc: <linux-mips@oss.sgi.com>
Subject: Re: MIPS32 patches breaking DecStation
Date: Tue, 9 Jan 2001 20:30:05 +0100 [thread overview]
Message-ID: <019901c07a72$94d19f00$0deca8c0@Ulysses> (raw)
In-Reply-To: 20010109162835.B4232@bacchus.dhis.org
> > Same here on my /260 (R4400SC V4.0). Neither inserting four "sll
$0,$0,1" nor
> > four "nop" seem to work. The branch, on the other hand, does.
Then it's apparently more than just a garden-variety CP0 hazard.
> Note the ssnops only make sense on superscalar CPUs, so not on the R4000.
My point is that an SSNOP should cause a 1 cycle stall on *any* MIPS
implementation to date, superscalar or not. It's not documented that
way for the R10000, but if I recall correctly, it works there too. If one
wants to standardize on a single mechanism, that's the one to use.
That's all I'm saying.
> Also note that the branch is equivalent to three nops. One for the
> branch instruction itself, the two more for instructions in the pipeline
> that get killed. On the R4600 / R500 where the hazard is only a single
> instruction the branch is equivalent to only a single nop. So while
> unobvious the branch is a rather neat idea.
Yes, it's cute, but it relies on accidents of implementation to work,
and could easily fail on other CPUs otherwise compatible with
the R4000. In principle, such a branch might incur no delay at
all on an advanced 64-bit processor. By all means, use it for
the specific cases of the CPUs on which it is known to work,
but it should not be used in "default" MIPS CP0 handlers.
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralf Baechle <ralf@oss.sgi.com>,
Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Cc: linux-mips@oss.sgi.com
Subject: Re: MIPS32 patches breaking DecStation
Date: Tue, 9 Jan 2001 20:30:05 +0100 [thread overview]
Message-ID: <019901c07a72$94d19f00$0deca8c0@Ulysses> (raw)
Message-ID: <20010109193005.Z23QL4ZgP7c2rXb1yV0zREpNBa8C-LWWZB9xObxzpFk@z> (raw)
In-Reply-To: 20010109162835.B4232@bacchus.dhis.org
> > Same here on my /260 (R4400SC V4.0). Neither inserting four "sll
$0,$0,1" nor
> > four "nop" seem to work. The branch, on the other hand, does.
Then it's apparently more than just a garden-variety CP0 hazard.
> Note the ssnops only make sense on superscalar CPUs, so not on the R4000.
My point is that an SSNOP should cause a 1 cycle stall on *any* MIPS
implementation to date, superscalar or not. It's not documented that
way for the R10000, but if I recall correctly, it works there too. If one
wants to standardize on a single mechanism, that's the one to use.
That's all I'm saying.
> Also note that the branch is equivalent to three nops. One for the
> branch instruction itself, the two more for instructions in the pipeline
> that get killed. On the R4600 / R500 where the hazard is only a single
> instruction the branch is equivalent to only a single nop. So while
> unobvious the branch is a rather neat idea.
Yes, it's cute, but it relies on accidents of implementation to work,
and could easily fail on other CPUs otherwise compatible with
the R4000. In principle, such a branch might incur no delay at
all on an advanced 64-bit processor. By all means, use it for
the specific cases of the CPUs on which it is known to work,
but it should not be used in "default" MIPS CP0 handlers.
Regards,
Kevin K.
next prev parent reply other threads:[~2001-01-09 19:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-08 23:41 MIPS32 patches breaking DecStation Florian Lohoff
2001-01-08 23:41 ` Florian Lohoff
2001-01-09 0:34 ` Kevin D. Kissell
2001-01-09 0:34 ` Kevin D. Kissell
2001-01-09 8:54 ` Florian Lohoff
2001-01-09 17:11 ` Harald Koerfgen
2001-01-09 18:28 ` Ralf Baechle
2001-01-09 19:30 ` Kevin D. Kissell [this message]
2001-01-09 19:30 ` Kevin D. Kissell
2001-01-09 19:54 ` Ralf Baechle
2001-01-09 19:54 ` Ralf Baechle
2001-01-09 20:33 ` Kevin D. Kissell
2001-01-09 20:33 ` Kevin D. Kissell
2001-01-09 15:09 ` Ralf Baechle
2001-01-09 15:09 ` Ralf Baechle
2001-01-09 15:50 ` Kevin D. Kissell
2001-01-09 15:50 ` Kevin D. Kissell
2001-01-09 16:43 ` Harald Koerfgen
2001-01-09 17:01 ` Ralf Baechle
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='019901c07a72$94d19f00$0deca8c0@Ulysses' \
--to=kevink@mips.com \
--cc=Harald.Koerfgen@home.ivm.de \
--cc=linux-mips@oss.sgi.com \
--cc=ralf@oss.sgi.com \
/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