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.
> First, I figured out where the problem is coming from:
>
> r4k_switch.S is included for all processors but the r3000 and r3912.
> Is that really correct? Then, it references FPU_SAVE_DOUBLE, which
> includes:
Yes. Originally written for the R4000 the Dr. Franksteins at MIPS in the
meantime also have taken r4k-style fpus and put them into 32-bit processors,
> 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.
> Something is fishy here. Anyone know what? I have a suspicion that we
> need to change the way we invoke binutils. Making -mmad imply -m4650
> just seems lame, since -m4650 also implies -msingle-float, and I don't
> think that's right for the r8000.
R8000 is serious fp, indeed.
> 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.
Ralf
