Re: [patch] change to MIPS 4650 instruction support

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Fri, Mar 16, 2001 at 12:42:01PM -0800, Chris G. Demetriou wrote:
> dmj+@andrew.cmu.edu (Daniel Jacobowitz) writes:
> > The 4650 support in binutils changed after 2.8.1 - it now both adds the
> > new instructions (mad, madu, mul) and imposes restrictions on the
> > available instructions (double floating point).  Up till now, GCC has
> > translated -mmad on its command line into -m4650 in binutils, but that
> > doesn't work any more.
> > 
> > This is my proposed solution - I add a separate flag, implied by
> > -m4650, to control the new instructions.
> >
> > Comments?  The patch is actually against 2.10.91.0.2 rather than HEAD,
> > but I can provide it for the head if wanted.
> 
> I'm wondering what your end goal is with this change.  I.e., is it to
> support a different CPU which doesn't have those restrictions, is it
> to support compilation of code that works both with the 4650 and less
> limited CPUs in the same object file, etc...

The goal of this change is mostly to support the Nevada line - the
Linux kernel makefiles traditionally pretend that they are r8000's,
because that's the closest match to their scheduling that GCC has
available, and add -mmad to gcc to enable these extra instructions. 
That used to work (with gcc converting -mmad to -m4650), but doesn't
any more.

> I'm not convinced it's a particularly good change to make as
> submitted.  (I say this as the last person to touch the
> OPCODE_IS_MEMBER crud... 8-)
> 
> Really, in the long run, I think OPCODE_IS_MEMBER should take one,
> maybe two masks:
> 
> 	(1) ISA
> 	(2) set of CPU-related extensions to enable
> 
> (plus the 'gp32' flag if that's _really_ necessary...)  adding random
> flags isn't the way to go, and adding essentially a cpu-specific flag
> to mips_set_options is definitely not.

I agree completely... I just didn't want to touch all that code right
away.  Both ISA and CPU are currently tested with equality in a bunch
of places, so changing them to masks is not trivial.

> If you're trying to support a new CPU type, it seems obvious how to do
> that without rewriting a bunch of code.

I was going to do it that way, but Ralf Baechle suggested otherwise:
    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.

> Note also that the rest of the stuff in mips_set_options can be used
> as described above, i.e. they're changeable state.  Even if this patch
> was otherwise OK (and I don't particularly like it, but i'm not in a
> position to reject it 8-), then mad4650 should be .set'able.

I could certainly do that.  I could even do something cleaner overall,
if anyone expresses a preference for how it should be done.

I envision the CPU argument setting defaults for a collection of
extension flags for all sorts of groups of instructions (like single
float, double float, mad, etc.) as well as a scheduling or otherwise
quirky policy, and then allowing the instruction flags to be
overridden.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team
                         "I am croutons!"