Switch FPU emulator trap to BREAK instruction

Switch FPU emulator trap to BREAK instruction

[Muthu Kumaran]

I am using 2.6.18 linux version on MIPS32 core. One of the application
is using intensive floating point operations. This hardware doesn't
have FPU and also the application is not compiled for software
floating point support.
Hence, it is using the floating point emulation.

While running that application, On a timer interrupt there is a normal
integer div instruction which gives wrong result in the HI register.

However, when I applied the following patch, this problem disappeared.

http://kerneltrap.org/mailarchive/git-commits-head/2008/10/30/3873324

When I looked into the patch, handling of invalid instruction
exception is moved from trap to break.
There is no other behavioural change in this patch. I really don't
understand the need for this patch, May I ask someone to explain the
background information behind this patch? Is this for any known issue?

Thanks.
I am new to both Linux and also MIPS core.

-- 
http://testbed.aws.cit.ie/panneer

Re: Switch FPU emulator trap to BREAK instruction

[David Daney]

Muthu Kumaran wrote:
> I am using 2.6.18 linux version on MIPS32 core. One of the application
> is using intensive floating point operations. This hardware doesn't
> have FPU and also the application is not compiled for software
> floating point support.
> Hence, it is using the floating point emulation.
> 
> While running that application, On a timer interrupt there is a normal
> integer div instruction which gives wrong result in the HI register.
> 
> However, when I applied the following patch, this problem disappeared.
> 
> http://kerneltrap.org/mailarchive/git-commits-head/2008/10/30/3873324
> 
> When I looked into the patch, handling of invalid instruction
> exception is moved from trap to break.

Incorrect analysis.  It was changed from an Adress Error (ADE) exception 
to a BREAK.


> There is no other behavioural change in this patch. I really don't
> understand the need for this patch, May I ask someone to explain the
> background information behind this patch? Is this for any known issue?
> 

The change log states the reason.  FPU emulator delay slot emulation was 
failing on some systems.


David Daney

Re: Switch FPU emulator trap to BREAK instruction

[Muthu Kumaran]

On 5 February 2010 17:36, David Daney <ddaney@caviumnetworks.com> wrote:
> Muthu Kumaran wrote:
>>
>> I am using 2.6.18 linux version on MIPS32 core. One of the application
>> is using intensive floating point operations. This hardware doesn't
>> have FPU and also the application is not compiled for software
>> floating point support.
>> Hence, it is using the floating point emulation.
>>
>> While running that application, On a timer interrupt there is a normal
>> integer div instruction which gives wrong result in the HI register.
>>
>> However, when I applied the following patch, this problem disappeared.
>>
>> http://kerneltrap.org/mailarchive/git-commits-head/2008/10/30/3873324
>>
>> When I looked into the patch, handling of invalid instruction
>> exception is moved from trap to break.
>
> Incorrect analysis.  It was changed from an Adress Error (ADE) exception to
> a BREAK.
>
I am sorry, I interpreted from the heading.  The following being
inserted to emulate the delay slot.
#define AdELOAD 0x8c000001	/* lw $0,1($0) */

>
>> There is no other behavioural change in this patch. I really don't
>> understand the need for this patch, May I ask someone to explain the
>> background information behind this patch? Is this for any known issue?
>>
>
> The change log states the reason.  FPU emulator delay slot emulation was
> failing on some systems.
>
Thanks.
In the morning, Ralf had pointed me "This is required only for the
Cavium cnMIPS core; for all other cores
this is just a more elegant implementation."

I think, I put the question in wrong sentence. I intended to ask
whether this fix impact MIPS32 core.
Ralf also pointed me that this fix has nothing to do with the div
error that I am seeing. If I dont have this patch, when I run
intensive floating point operating, I am getting wrong result in HI
register for a div operation.