=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

quoted

 Hi Kumar,

quoted

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

quoted

quoted

IEEE-754 standard


On Jan 11, 2007, at 11:19 PM, Zhu Ebony-r57400 wrote:

quoted

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

quoted

is used.

Ebony

Here are some general comments:
* We should be able to support math-emu (as it stands) and=20

the fixup=20

quoted

quoted

handling [you break math-emu]

I don't think I break the math-emu. I think the codes I=20

added have no=20

quoted

impact to the existing math-emu.

=20
This snippet of code breaks it from math-emu/sfp-machine.h
=20

quoted

quoted

+#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

quoted

quoted

* 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

quoted

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

quoted

quoted

* 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