[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月15日 22:37
> 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 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.
> 
So how about defining a separate macro for spefscr?

 #define  __FPU_SPEFSCR	(current->thread.spefscr) 


> >>>> * 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.
> 

OK, I will study it.

Thanks,
Ebony