On Wed, Mar 14, 2001 at 07:59:19PM +0100, Ralf Baechle wrote:
> On Wed, Mar 14, 2001 at 08:46:33AM -0500, Daniel Jacobowitz wrote:
>
> > I've been trying for a couple of days now to build a MIPS kernel with
> > CONFIG_CPU_NEVADA, and I can't get it to work. r4k_switch.S produces a
> > pile of "opcode not supported by processor" errors.
>
> Known and unsolved problem.
> > cfc1 tmp, fcr31; \
> > sdc1 $f0, (THREAD_FPU + 0x000)(thread); \
> > sdc1 $f2, (THREAD_FPU + 0x010)(thread); \
> >
> >
> > The sdc1 instruction in binutils is flagged like this:
> > if (mips_cpu == CPU_R4650)
> > {
> > as_bad (_("opcode not supported on this processor"));
> > return;
> > }
> >
> > And the IVR sets CONFIG_CPU_NEVADA, which produces
> > ifdef CONFIG_CPU_NEVADA
> > GCCFLAGS += -mcpu=r8000 -mips2 -Wa,--trap -mmad
> > endif
> >
> > and -mmad becomes -m4650 to the assembler.
>
> Which is pretty much bs because mmad may have been introduced with the
> R4640 / R4650 but isn't only available on this processor. From an ISA
> view it's a processor specific extension and as such it should be
> controlled by a separate option. Gcc has -mmad which is fine but passing
> it on to as as -m4650 is borken.
OK, so that needs to change. That's pretty easy to do, at least in our
local toolchains.
> > I worked back in time in gcc, binutils, and kernel sources and I
> > couldn't figure out what's changed - I'm sure this worked at some
> > point.
>
> You'll have to go back far in time. I introduced the use of -mmad for
> Nevada-class CPUs in late summor '97.
>
> As a second bug which makes this one even more annoying something like
>
> .set mips3
> sdc1 $f2, (a0)
> .set mips0
>
> also doesn't work - the assembler will still throw an "opcode not supported
> on this processor" message. After all MIPS III means double precission fp.
> And passing additional assembler options with -Wa,foo doesn't help either
> in this case so without the necessary gcc / assembler changes this
> optimization is lost for now.
Does -mmad make a sufficient difference on these processors to bother
fixing it?
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.
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
"I am croutons!"
