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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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).  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).

> 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.

 I appreciate your concerns BTW.  Questioning changes makes it easier to 
find any possible flaws in understanding.

  Maciej