[Patch] [MIPS] Change opcode membership for the ssnop and ehb instructions

Richard Sandiford rdsandiford@googlemail.com
Wed May 26 19:59:00 GMT 2010

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Sun, 23 May 2010, Richard Sandiford wrote:
>> > This patch changes the opcode membership for the ssnop instruction to 
>> > I1 from I32 | N55.  It also changes the opcode membership of the ehb 
>> > instruction to I32 from I33.  For those ASE's which don't support ehb 
>> > and/or ssnop, the instruction executes as a nop.  This change make the 
>> > disassembly read more cleanly.  Does this look okay to install?
>> I'm not convinced this is a good idea.  Do we really want:
>> 	.set mips32
>>         ehb
>> to be acceptable?
>  Well, EHB is an assembly idiom for "SLL $0, $0, 3" and likewise SSNOP for 
> "SLL $0, $0, 1".  Both instructions were chosen deliberately to execute 
> correctly back to the MIPS I ISA.

Right, I get that, but...

> I see no harm with assembling them and, 
> more importantly, they are much more readable in `objdump' or GDB where 
> you don't have the luxury of a per-instruction ISA annotation.
>  With an example hazard-clearing sequence like this:
>  ssnop; ssnop; ehb
> (EHB executes as SSNOP on pre-MIPS-r2 processors) I see no gain with 
> interspersing this code with .set directives (or even wrapping it all).
>  What's the cause of your concern?

...it was simply that these directives currently carry certain architectural
guarantees in cases where they're accepted.  After the patch, we'd silently
allow SSNOP for some processors that are used in SMP environments without
the SSNOP acting any differently from a normal nop.  I thought it was at
least worth asking the question whether this was a good idea.

If it is, then why only bump EHB down to MIPS32?  Why not bump it down
all the way to MIPS I?


More information about the Binutils mailing list