Home Original page

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

Richard Sandiford rdsandiford@googlemail.com
Wed May 26 21:24:00 GMT 2010 
"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Wed, 26 May 2010, Richard Sandiford wrote:
>> >  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
>
>  Correct.  What value does it have in this case?  Can you think of a 
> single case where a user would get a build error because of one of these 
> mnemonics and then realised they need to rewrite the piece of code 
> differently because their CPU predates architectural definitions of these 
> aliases?  I find it highly unlikely these days.  And Linux kernel hackers 
> that fiddle with old SGI or DEC gear tend to be smart enough not to need 
> such aids. ;)
>
>> 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.
>
>  SSNOP is for superscalar processors rather than SMP (you may have had 
> SYNC in mind).

No, my bad.  I meant superscalar, but had been thinking about an
SMP problem just before ;-)

> Introduced with the R8000 BTW (which we don't support 
> anyway) for things like the usual CP0 hazard avoidance.  I'd expect any 
> pre-MIPS32/MIPS64 ISA superscalar hardware either to implement it as 
> expected (like the MIPS R8000 or the NEC VR5500) or not to need it at all 
> (like the MIPS R10000 and friends that interlock instead).

I don't recall it being a superscalar nop on the VR4131 (which didn't
have interlocks for all hazards) but perhaps I'm wrong.

>> If it is, then why only bump EHB down to MIPS32?  Why not bump it down
>> all the way to MIPS I?
>
>  That would be my preference as well.  I missed this somehow from the 
> original patch, but I don't think it makes any sense to limit EHB like 
> this.  The original choice comes from MIPS UK, but unfortunately I can't 
> recall why this was done like this, perhaps just because MTI did not 
> actively care about legacy MIPS ISAs.  I don't think I was involved with 
> the decision.  And the two changes were probably made separately, hence 
> the inconsisteny.

Well, OK, I'm not entirely convinced, but the weight of opinion
is obviously the other way.  Patch is OK with EHB changed to I1.

Richard
More information about the Binutils mailing list