No, read the comment and think about it some more.
"fmov $f31, $f0\n\t"
"cvttq/svm $f31, $f31\n\t"
"cmpteq $f31, $f31, $f0\n\t"
"addt $f31, $f31, $f31\n\t"
"stt $f0, %0"
In the broken case, we'll enter entIF with pc==cvttq. Add 8 gives
addt, subtract 4 gives cmpteq, which gives $f0 = 2.0.
In the working case, we'll enter entIF with pc==cmpteq. Add 8 gives
stt, subtract 4 gives addt, which is engineered to be a noop.
> Further, if fp emulation isn't compiled in, we'll have kernel mode
> instruction fault. A quick fix appears to be
Hmm. If fp emulation isn't compiled in, we shouldn't bother
testing this, I think. Means you can't debug fp emulation via
modules on Multia, but I'm pretty sure I don't care.
I suppose the other alternative to get the testing code out of
the normal entIF is to create a custom entIF that is installed
only during opDEC testing. Seems too much work...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/