This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ssnop for mips
cgd@sibyte.com (Chris G. Demetriou) writes:
> for some value of 'needed'. it may have some absolutely different
> 'no-op' meaning on non-MIPS32/MIPS64 processors.
>
> if i recall correctly, that instruction doesn't inhibit multi-issue.
i edited a couple of words out accidentally.
"on the RM7000." From the looks of it, it has two pipes both of which
can handle "sll $0, $0, 1" at the same time.
so, to reiterate: 'ssnop' (sll $0, $0, 1) does not (as far as I know)
generally inhibit multi-issue, and, specifically (as far as I can
tell) does not inhibit it on the rm7000.
The behavior, and that name, are unique to MIPS32 and MIPS64 (and
chips which implement that specific instruction), but definitely _do
not_ go back to MIPS I or even MIPS IV AFAIK.
It makes no more sense to include it in MIPS I - MIPS IV (and possibly
V -- i dunno) than it does to include, oh, pref or something in MIPS
I.
I also said:
> * if you need to use it, you can quite easily do:
>
> .set push
> .set mips32
> ... whatever ...
> ssnop
> ... whatever ...
> .set pop
That covers the assembly case.
The disassembly case is obvious: if you want to dissassemble MIPS32 /
MIPS64 instructions in a binary that's not marked MIPS32 or MIPS64,
then you should do so with a -m flag or similar.
you don't disassemble random non-conflicting instructions for MIPS I,
just because they're non-conflicting, eh?
cgd