This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] change to MIPS 4650 instruction support
- To: "Chris G. Demetriou" <cgd at sibyte dot com>
- Subject: Re: [patch] change to MIPS 4650 instruction support
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Fri, 16 Mar 2001 15:53:54 -0500
- Cc: binutils at sources dot redhat dot com
- References: <20010316084713.A1228@nevyn.them.org> <mailpost.984750568.13437@postal.sibyte.com> <yov53dcdsaxy.fsf@highland.sibyte.com>
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!"