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

[Richard Sandiford <rdsandiford at googlemail dot com>]

"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