[PATCH] invalid instructions in kernel mode

Fillod Stephane stephane.fillod at thomson.net
Tue Apr 5 22:24:39 EST 2005


Dan Malek wrote:
>> What I don't understand, is how the FP load/store operations
>> in misc.S can "work" on a system with no FPU and *no* math-emu?
>
>What should happen is to follow the example used by 8xx for
>many years.  As I said, when math emulation is disabled, there is
>still code that will emulate the load/store FP instructions.  These
>instructions are used in may places even if user applications
>are compiled without any FP usage.

Ok.

>> Many years? Allow me to doubt it's really used :).
>
>I wrote it in 1998 for the 8xx.  I thought 4xx and e500 used the
>same model.  If they don't, they should.

Let's get it fixed.

>> Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
>> for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.
>
>Well, then that should get fixed.

What's the right way to fix it?

>> So here is another patch,
[..]
>The only patch I'm interested in is making the 4xx and e500 follow the
>same path as 8xx.  All of the non-FP cores should work the same way.

Speaking for myself, I don't plan on using the SPE FPU of the e500, but
would like to see the MATH_EMULATION=n fixed. So how should we fix it?

It seems you didn't like my last patch which lets make enter the
math-emu
subdirectory only to compile the load/store (8xx could do that too).
Would you prefer a fix along the line of Soft_emulate_8xx() ?
Then should we make it a Soft_emulate_85xx and Soft_emulate_4xx or can
we attempt to fuse them altogether and rename(+make it generic)
Soft_emulate_8xx as Soft_emulate_classic?

>The e500 is a special case because it doesn't have a classic FPU but
>rather can utilize the SPE for floating point.  Put some thought into 
>that.

I don't know what Kumar and his team have in mind for the e500, whether
they will use SPE FPU for the classic load/store "emulation". Kumar,
can you please enlighten us on this topic?


Thanks,
-- 
Stephane




More information about the Linuxppc-dev mailing list