This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]