Re: Can't build a CONFIG_CPU_NEVADA kernel

["Kevin D. Kissell" <kevink@mips.com>]

> > If it does, I can probably whip up a -mmad patch to binutils to allow
> > those opcodes - or I could introduce -mnevada, or whatever the
> > appropriate term would be, to mean "r8000 with the mad* extensions". 
> > In fact, that would probably be easiest, and sounds like the most
> > correct.
> 
> Don't think of the r8000; the kernel only uses the -mcpu=r8000 option
> because the Nevada CPUs have _somewhat_ similar scheduling properties
> to the R8000.  This of it as an independant ISA expension which can
> be used with an arbitrary MIPS processor - even a R3000 processor.

In the interests of historical accuracy and general pedantry,
let me point out that -mcpu=r8000 is in effect a rather klugy
way of saying "-mips4" to compilers that predate official
MIPS IV ISA support.  The R8000 was the first MIPS IV
CPU, followed by the R10000 and the R5000.  The "Nevada"
processors added three implementation specific instructions
to the MIPS IV ISA: MAD, MADU, and MUL (targeted multiply).
"Correct" usage would be to enable those three instructions
with a "-mcpu=nevada", or better still, "-mcpu=r5200" (for 
consistency), and to enable the rest of the MIPS IV ISA 
with "-mips4" instead of the archaic r8000 hack.

Note, furthermore, that -mmad needs to be handled with care: 
Prior to MIPS standardizing the instruction as part of 
MIPS32, there were four or five subtly (or not so subltly) 
different definitions of integer multiply-accumulate for MIPS.  
Most use the same opcode, but even those can differ in side 
effects (is the rd field interpreted, etc.). A R4650 madd operation
will probably behave equivalently on a Nevada CPU, 
but certainly not on a Vr41xx part, for example.

            Regards,

            Kevin K.