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: Wednesday, January 31, 2007 10:49 PM
> 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
> >> On Jan 29, 2007, at 4:00 AM, Zhu Ebony-r57400 wrote:
> >>
> >>> Hi Kumar,
> >>>
> >>> I think enabling SPEFSCR[FINXE] or SPEFSCR[FRMC]=3D0b10/0b11
> >> to enable
> >>> FP round interrupt will cause the exception occurring very often,=20
> >>> which will dramatically decrease the performance of SPE
> >> instructions.
> >>> Do you think putting an option in menuconfig to let user choose=20
> >>> whether to enable FP round simulation is a reasonable idea?
> >>
> >> I don't see any issue with it, but I have to believe if=20
> you want full=20
> >> IEEE results, you want full IEEE results for everything.
> >>
> >> - k
> >>
> >
> > Agreed, we need to fully comply with IEEE754. So let's talk=20
> something=20
> > about the handler.
> >
> > The round exceptions can be put into 2 categories:
> >
> > 1. SPEFSCR[FRMC] =3D 0b10 or 0b11 (rounding toward +Inf and -Inf) We =

> > need to handle this exception to comply with IEEE
> >
> > 2. SPEFSCR[FINXE] =3D 1
> > If we enable this, round exception will occurs when=20
> inaccurate results=20
> > are generated. However, I think we don't need to do so.=20
> With FINXE=3D0,=20
> > if SPE data exception occurs, we can handle the exception=20
> by existing=20
> > handler, which is fully IEEE complied, including rounding.=20
> If no data=20
> > exception occurs, HW can implement "round to nearest" and "round=20
> > toward zero" with IEEE complied, and "round toward=20
> +Inf/-Inf" can be=20
> > handled by the handler of point 1.
> > So all
> > the situations are covered, we do have to enable FINXE.
> >
> > Could you make some comments on this? Thanks!
>=20
> While I agree with most of what you're saying there is one=20
> issue.  If the user want's an exception reported on inexact=20
> results when the =20
> rounding mode is set to "round to nearest" or "round towards zero".  =20
> Of course we know when the user requests this and can=20
> enable/disable this exception at that point if we want to.
>=20
> On a side node, wondering if you've come across this test suite:
> http://www.jhauser.us/arithmetic/TestFloat.html
>=20
> - k

Thank  you for your comments and useful link. It seems quite good for
testing the handler.

B.R.
Ebony






>=20