Re: ssnop for mips

["Kevin D. Kissell" <kevink at mips dot com>]

> > Ssnop is documented as ``breaks superscalar dispatch''.  See also the
> > comments in IRIX <sys/asm.h> which I can't paste here for (C) reasons.
>
> As noted, i forgot some words there.  specifically, "on the rm7k"
> though there may well be certain other processors on which it doesn't
> force single-issue as well.

Bummer.  They should have known better.  I'm quite surprised.

> (looks like on some of the IDT parts you can still co-issue FP
> instructions.)

That's unfortunate, but probably not too dangerous.  The
main reason to want to assure single-issue is when one
is navigating CP0 hazards, and FP instructions are
generally not an issue (pun not intended).

> > > Personally, I don't think it should be enabled if not MIPS32/MIPS64:
> > >
> > > * the behaviour may not be what's expected, and
> >
> > All CPUs that don't implement ssnop's special semantics will decode it
as
> > sll $zero, $zero, 1 which is obviously harmless.
>
> Right, but looked at the other way, it's not.
>
> you see ssnop in the assembly code, and you think "ahh, one per
> cycle."
>
> but in fact that's not the case for a bunch of parts.

Historically, SSNOP was invented for the old R8000 BiCMOS
monster, which was the first superscalar MIPS CPU.  The R10K
preserved the convention, as I believe does the R54xx (though
I also believed it true of the RM7000), but until the MIPS32 and
MIPS64 specs were published, that's all it was, a convention.
It was not part of the MIPS-I/II/III/IV ISA compliance tests.

But while it may be true that SSNOP is not guaranteed to force
single issue across all MIPS implementations, it is still the best
known method of forcing single issue, and should be used in
preference to a simple "nop" for negotiating pipeline hazards,
even on pre-MIPS32 CPU's, in my opinion.  If the RM7000
needs more SSNOPS than it should because it can issue
them two at a time, that's philosophically indistinguishable
from it respecting SSNOP, but having longer pipeline hazards.

            Regards,

            Kevin K.