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

[Zhu Ebony-r57400]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org] 
> Sent: 2007年1月25日 23:11
> 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: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).

I'm now confused on this point. If I get round interrupt and the target
register is 0x00000017, what the round result should be for 0x00000017?
What is it if round to zero? If round to nearest? If round to +Inf? If round to -Inf?
>From the only info that 0x00000017 is a non-rounded result, we still don't know
how to round it. 0x00000017 is an inexact value itself.

Actually, in existing code of math-emu, rounding takes place when packing the bits
back into native fp result.

> >>> 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.
OK, and I think I need to do some more tests to prove this.


Thanks for your feedback!

B.R.
Ebony