linux-mips
[Top] [All Lists]

Re: MIPS32 patches breaking DecStation

To: "Ralf Baechle" <ralf@oss.sgi.com>, "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Subject: Re: MIPS32 patches breaking DecStation
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Tue, 9 Jan 2001 20:30:05 +0100
Cc: <linux-mips@oss.sgi.com>
References: <20010109095438.A10683@paradigm.rfc822.org> <XFMail.010109181100.Harald.Koerfgen@home.ivm.de> <20010109162835.B4232@bacchus.dhis.org>
Sender: owner-linux-mips@oss.sgi.com
> > 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.


<Prev in Thread] Current Thread [Next in Thread>