[patch][0/5] powerpc: Add support to fully comply with IEEE-754 standard

[Kumar Gala]

On Jan 15, 2007, at 12:37 AM, Zhu Ebony-r57400 wrote:

>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> Sent: 2007年1月13日 02:36
>> To: Zhu Ebony-r57400
>> Cc: paulus at samba.org; linuxppc-dev at ozlabs.org
>> Subject: Re: [patch][0/5] powerpc: Add support to fully
>> comply with IEEE-754 standard
>>
>>
>> On Jan 12, 2007, at 2:09 AM, Zhu Ebony-r57400 wrote:
>>
>>>  Hi Kumar,
>>>
>>>> -----Original Message-----
>>>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>>>> Sent: 2007年1月12日 14:42
>>>> To: Zhu Ebony-r57400
>>>> Cc: paulus at samba.org; linuxppc-dev at ozlabs.org
>>>> Subject: Re: [patch][0/5] powerpc: Add support to fully
>> comply with
>>>> IEEE-754 standard
>>>>
>>>>
>>>> On Jan 11, 2007, at 11:19 PM, Zhu Ebony-r57400 wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> This series of patch add support to fully comply with IEEE-754
>>>>> standard for E500/E500v2 core when hardware floating point
>>>> compiling
>>>>> is used.
>>>>>
>>>>> Ebony
>>>>
>>>> Here are some general comments:
>>>> * We should be able to support math-emu (as it stands) and
>> the fixup
>>>> handling [you break math-emu]
>>>
>>> I don't think I break the math-emu. I think the codes I
>> added have no
>>> impact to the existing math-emu.
>>
>> This snippet of code breaks it from math-emu/sfp-machine.h
>>
>>>> +#ifdef CONFIG_SPE
>>>> +#define __FPU_FPSCR	(current->thread.spefscr)
>>>> +#else
>>>>  #define __FPU_FPSCR	(current->thread.fpscr.val)
>>>> +#endif
>>
>> By doing this if I want 'classic FP' emulation as well as the
>> IEEE fixup my fpscr for classic emu will not be updated properly.
>
> Logically, user can choose "SPE Support" and "Math emulation" at the
> same time on menuconfig. But from my understanding, it is not  
> necessary
> to select math-emu on a SPE available system, since SPE can do math  
> operation.

This is not true.  If I want to run a "classic" PPC binary with FP I  
need "Math emulation" and if I want to run an SPE one I enable "SPE  
Support".  I could want to run both of these types of binaries on the  
same system at the same time.

>>>> * Copyrights / header comments should give credit to the orig
>>>> math- emu code
>>> I'd like to do this, but in most handler codes, I can't find
>>> copyright information
>>> of the orig authors. I think the math-emu code comes from
>> glibc. In
>>> the
>>> sigfpe_handler.c, I gave credit to the orig author.
>>
>> I think a comment is sufficient stating this is take from the math-
>> emu code.
>>
>>>> * Why isn't there any handling of SPEFloatingPointRound exceptions?
>>>
>>> I think the SPEFloatingPointRound exception is not necessary to
>>> handle if we
>>> handle floating point exception this way.
>>
>> I dont believe this, you'll have to explain if this is really true.
>> But, I'm almost sure that if the RND mode is set to +/-inf and we do
>> an operation that is within the normal bounds that should round we
>> will NOT get one of the other exceptions.
>>
>> - k
>>
>>
>
> I looked into the manual again, and found what you are saying is  
> correct. The reason
> for developing IEEE-754 fixup came from customer's complain, which  
> is about denormalized
> computation can't generate the correct result as the same as on  
> x86. So what I was
> concentrating on is floating-point data interrupt. The truth is, FP  
> round interrupt may
> be taken on some circumstance that FP data interrupt doesn't take  
> place.
>
> As you said, if RND mode is set to +/- inf, FP round interrupt will  
> generate if we
> do an operation within the normal bounds. Do you think we use the  
> same way to
> handle FP round interrupt as FP data interrupt is reasonable? How  
> would you suggest?

No, I think the round handler should try to do the rounding by hand.   
Since you have the non rounded information provided by HW, its much  
simpler to just do the rounding step.

- k

>
> Thanks.
>
> Ebony
>
>
>
>