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

["Zhu Ebony-r57400" <ebony.zhu@freescale.com>]

=20

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: 2007=C4=EA1=D4=C213=C8=D5 02:36
> To: Zhu Ebony-r57400
> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
> Subject: Re: [patch][0/5] powerpc: Add support to fully=20
> comply with IEEE-754 standard
>=20
>=20
> On Jan 12, 2007, at 2:09 AM, Zhu Ebony-r57400 wrote:
>=20
> >  Hi Kumar,
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: 2007=C4=EA1=D4=C212=C8=D5 14:42
> >> To: Zhu Ebony-r57400
> >> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
> >> Subject: Re: [patch][0/5] powerpc: Add support to fully=20
> comply with=20
> >> 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=20
> >>> 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=20
> the fixup=20
> >> handling [you break math-emu]
> >
> > I don't think I break the math-emu. I think the codes I=20
> added have no=20
> > impact to the existing math-emu.
>=20
> This snippet of code breaks it from math-emu/sfp-machine.h
>=20
> >> +#ifdef CONFIG_SPE
> >> +#define __FPU_FPSCR	(current->thread.spefscr)
> >> +#else
> >>  #define __FPU_FPSCR	(current->thread.fpscr.val)
> >> +#endif
>=20
> By doing this if I want 'classic FP' emulation as well as the=20
> IEEE fixup my fpscr for classic emu will not be updated properly.

Logically, user can choose "SPE Support" and "Math emulation" at the=20
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.


>=20
> >
> >> * 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 =20
> > copyright information
> > of the orig authors. I think the math-emu code comes from=20
> glibc. In =20
> > the
> > sigfpe_handler.c, I gave credit to the orig author.
>=20
> I think a comment is sufficient stating this is take from the math-=20
> emu code.
>=20
> >> * Why isn't there any handling of SPEFloatingPointRound exceptions?
> >
> > I think the SPEFloatingPointRound exception is not necessary to =20
> > handle if we
> > handle floating point exception this way.
>=20
> I dont believe this, you'll have to explain if this is really true.  =20
> But, I'm almost sure that if the RND mode is set to +/-inf and we do =20
> an operation that is within the normal bounds that should round we =20
> will NOT get one of the other exceptions.
>=20
> - k
>=20
>=20

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?

Thanks.

Ebony