Re: [mips patch rfa] Add MIPS32 Release 2 support.

[Richard Sandiford <rsandifo at redhat dot com>]

cgd@broadcom.com writes:
> At 07 Jan 2003 19:46:17 +0000, Richard Sandiford wrote:
> > I agree that __mips isn't good for 32r2-aware code because it
> > isn't descriptive enough.  That's why setting __mips to 32
> > makes sense IMO.  Any existing mips32 code that checks __mips
> > should work OK for mips32r2 as well.
> 
> So, then my mind goes to ask, why should any existing code that checks
> _MIPS_ISA be different than code that checks __mips, for MIPS32
> vs. MIPS32R2.
> 
> At least naively, I'd expect that if __mips had the same value for
> MIPS32 and MIPS32R2, _MIPS_ISA would as well...

On the one hand, yes, and I guess that goes back to the idea of
having a separate revision macro.  On the other hand, _MIPS_ISA
has been set up as an enum while __mips has always been the
numerical ISA level.  Adding a new _MIPS_ISA value doesn't
seem as bad as inventing a magic number for __mips.

> From a programmer POV, mips32r2 is a superset of mips32...  but then
> mips32 was similarly a superset of mips2.  8-)

Right.  But looking at the terminology, "mips2" and "mips32"
are obviously different numerical ISA levels.  "mips32r2"
and "mips32" both look to me like different versions of
the same numerical ISA level.

I don't think all __mips==32 targets have to have exactly the
same ISA: they just need to be a superset of the original.
Just like __mips==4 when compiling code for the vr5400 ISA.

Having separate ISA level & revision macros (or relying on
_MIPS_ISA if you prefer that) gives users just as much
information as __mips=33 and seems to be more consistent
with the naming convention.

Richard