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

[Kumar Gala]

On Jan 25, 2007, at 2:53 AM, Zhu Ebony-r57400 wrote:

>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> Sent: 2007年1月25日 16:29
>> 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 25, 2007, at 2:25 AM, Zhu Ebony-r57400 wrote:
>>
>>>
>>>> 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.
>>>
>>> Hi Kumar,
>>>
>>> I have some new thoughts about rounding handler.
>>> Suppose we set SPEFSCR[FRMC]=0b10 (rounding towards +Inf)
>> and a normal
>>> "efsmul" may generate rounding interrupt. At this time,
>> according to
>>> manual, unrounded (truncated) result is placed in the
>> target register.
>>> Please note the target register contains a hexadecimal
>> representation
>>> of a floating point number. Since it represents a floating point
>>> number exactly so we can not round it anymore.
>>
>> I don't follow what you mean by not being able to round it anymore.
>
> I try to make myself clear:
>> From my understanding, rounding is from a floating point number to  
>> another
> which can be represented by IEEE-754 complied hexadecimal, but not
> from a hexadecimal to another. For example:
>
> Assume the result we got from efsmul is 3.29305125103e-44
> It will be stored in target register as 0x00000017. However,  
> 0x00000017
> Represents 3.2229864679470793e-44 accurately. Can we round   
> 3.2229864679470793e-44?
> I'm afraid not. I mean, we must round the result before it being  
> stored in
> target register as hexadecimal, not after.

I still don't follow what you are getting at.  The HW stores the non- 
rounded result.  You seem to imply there is some format change or  
something that is going on between the computed result and what's  
stored in the register.  If the result is such that it doesn't need  
rounding than you don't round (I forget if you can an exception or  
not if G|X are not set).

>>> Maybe we still need to emulate the whole "efsmul" instruction by
>>> software.
>>
>> You can't always do that.  Think about the following instruction:
>>
>> 	efsmul	r3, r3, r3
>>
>> You'll have lost the original value of r3 when the exception occurs.
>
> If this operation causes FP data interrupt, just let data interrupt  
> handler to
> do the simulation. I think there's no chance that we get data and  
> round interrupts
> simultaneously.

Agreed, and I think FP data will take precedence, however the example  
I use can still cause a round exception and no data exception given  
the right input values.

- k