@@ -840,6 +840,8 @@ load_up_spe:orisr5,r5,MSR_SPE@hmtmsrr5/*enableuseofSPEnow*/isync+lir5,(SPEFSCR_FINVE|SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE)+mtsprSPRN_SPEFSCR,r5/**ForSMP,wedon't do lazy SPE switching because it just gets too*horrendouslycomplex,especiallywhenataskswitchesfromoneCPU
@@ -166,7 +166,9 @@ #define __FP_PACK_RAW_2(fs, val, X) \#include<linux/kernel.h>#include<linux/sched.h>+#ifndef __FPU_FPSCR#define __FPU_FPSCR (current->thread.fpscr.val)+#endif/* We only actually write to the destination register*ifexceptionssignalled(ifany)willnottrap.
Take a look at the path I put up that reworks the error handling from
do_mathemu() we need to be doing something similar (in parsing
spefscr/fpexc_mode to setup code properly)
- _exception(SIGFPE, regs, code, regs->nip);
- return;
+ if (err == -EFAULT) {
+ /* got an error reading the instruction */
+ _exception(SIGSEGV, regs, SEGV_ACCERR, regs->nip);
+ } else if (err == -EINVAL) {
+ /* didn't recognize the instruction */
+ printk(KERN_ERR "unrecognized spe instruction "
+ "in %s at %lx\n", current->comm, regs->nip);
We should probably just SIGSEGV in this case since will never make
forward progress once we hit this case.
@@ -166,7 +166,9 @@ #define __FP_PACK_RAW_2(fs, val, X) \#include<linux/kernel.h>#include<linux/sched.h>+#ifndef __FPU_FPSCR#define __FPU_FPSCR (current->thread.fpscr.val)+#endif/* We only actually write to the destination register*ifexceptionssignalled(ifany)willnottrap.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Thursday, February 08, 2007 3:33 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support=20
for Embedded Floating-Point instructions
=20
=20
On Feb 7, 2007, at 9:55 PM, ebony.zhu@freescale.com wrote:
=20
quoted
Add the general support for Embedded Floating-Point instructions to=20
fully comply with IEEE-754.
Signed-off-by:Ebony Zhu [off-list ref]
---
arch/powerpc/kernel/head_fsl_booke.S | 4
arch/powerpc/kernel/traps.c | 57 +++++
arch/powerpc/math-emu/Makefile | 25 ++
arch/powerpc/math-emu/sfp-machine.h | 2
arch/powerpc/math-emu/spe.h | 1
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/sigfpe_handler.c | 361 +++++++++++++++++++++++
+++++++++++
7 files changed, 442 insertions(+), 9 deletions(-)
=20
I thought we were going to have some general Kconfig option=20
to enable all this? EMDEDDED_FP_IEEE or something like that
So that users have chance to enable/disable fully IEEE compliance?
Segher
had mentioned this, and it sounds reasonable.=20
=20
Take a look at the path I put up that reworks the error=20
handling from =20
do_mathemu() we need to be doing something similar (in parsing =20
spefscr/fpexc_mode to setup code properly)
It's new in trap.c? I'll look into it.
=20
quoted
- _exception(SIGFPE, regs, code, regs->nip);
- return;
+ if (err =3D=3D -EFAULT) {
+ /* got an error reading the instruction */
+ _exception(SIGSEGV, regs, SEGV_ACCERR, regs->nip);
+ } else if (err =3D=3D -EINVAL) {
+ /* didn't recognize the instruction */
+ printk(KERN_ERR "unrecognized spe instruction "
+ "in %s at %lx\n", current->comm, regs->nip);
=20
We should probably just SIGSEGV in this case since will never make =20
forward progress once we hit this case.
Won't it hit the case that the instruction is not an spe instruction?
types.o udivmodti4.o
=20
This isn't right, we don't want to always build these files.
=20
fabs.o/fneg.o should be built in the case
that CONFIG_MATH_EMULATION or CONFIG_SPE or both are
enabled. Because I reused fabs.c and fneg.c to implement instruction
efdabs and
efdneg. Therefore, these two files should be build once we have chance
to build the files in directory math-emu. Types.c and udivmodti4.c
contain the function
that both math emulation instructions and spe instructions may call, so
they always need
to be built.
B.R
Ebony
From: Kumar Gala <hidden> Date: 2007-02-08 17:32:19
On Feb 8, 2007, at 3:06 AM, Zhu Ebony-r57400 wrote:
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, February 08, 2007 3:33 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support
for Embedded Floating-Point instructions
On Feb 7, 2007, at 9:55 PM, ebony.zhu@freescale.com wrote:
quoted
Add the general support for Embedded Floating-Point instructions to
fully comply with IEEE-754.
Signed-off-by:Ebony Zhu [off-list ref]
---
arch/powerpc/kernel/head_fsl_booke.S | 4
arch/powerpc/kernel/traps.c | 57 +++++
arch/powerpc/math-emu/Makefile | 25 ++
arch/powerpc/math-emu/sfp-machine.h | 2
arch/powerpc/math-emu/spe.h | 1
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/sigfpe_handler.c | 361 +++++++++++++++++++++++
+++++++++++
7 files changed, 442 insertions(+), 9 deletions(-)
I thought we were going to have some general Kconfig option
to enable all this? EMDEDDED_FP_IEEE or something like that
So that users have chance to enable/disable fully IEEE compliance?
Segher
had mentioned this, and it sounds reasonable.
Its alot of code to bring in if you don't care about IEEE compliance.
Take a look at the path I put up that reworks the error
handling from
do_mathemu() we need to be doing something similar (in parsing
spefscr/fpexc_mode to setup code properly)
It's new in trap.c? I'll look into it.
Pretty recent commit, in Paul's tree, not yet in linus's.
(or look at my last pull request email to paul)
quoted
quoted
- _exception(SIGFPE, regs, code, regs->nip);
- return;
+ if (err == -EFAULT) {
+ /* got an error reading the instruction */
+ _exception(SIGSEGV, regs, SEGV_ACCERR, regs->nip);
+ } else if (err == -EINVAL) {
+ /* didn't recognize the instruction */
+ printk(KERN_ERR "unrecognized spe instruction "
+ "in %s at %lx\n", current->comm, regs->nip);
We should probably just SIGSEGV in this case since will never make
forward progress once we hit this case.
Won't it hit the case that the instruction is not an spe instruction?
No, since we will not get this exception on something that's not an
SPE instruction.
types.o udivmodti4.o
This isn't right, we don't want to always build these files.
fabs.o/fneg.o should be built in the case
that CONFIG_MATH_EMULATION or CONFIG_SPE or both are
enabled. Because I reused fabs.c and fneg.c to implement instruction
efdabs and
efdneg. Therefore, these two files should be build once we have chance
to build the files in directory math-emu. Types.c and udivmodti4.c
contain the function
that both math emulation instructions and spe instructions may
call, so
they always need
to be built.
Right, but doesn't the new rule say to always build, regardless if
CONFIG_MATH_EMULATION or CONFIG_SPE are set?
Why not just duplicate fabs.o fneg.o ... in both lists. I don't
think that will cause any harm.
- k
We should do this via INIT_THREAD, is there a reason that=20
you want to=20
quoted
quoted
set these always?
I just thought it's the first time that an SPE instruction is=20
encountered, so I enable the exceptions here.
=20
Lets do this via INIT_THREAD instead, its cleaner. (just=20
remember to add the proper ifdef protection for SPE_IEEE
Talking about INIT_THREAD, I'm wondering where is the best place to
enble the exceptions? Please advice!
And also, I will put all of your other suggestions into next patches.
Thank you!
B.R.
Ebony
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, February 09, 2007 1:29 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support=20
for Embedded Floating-Point instructions
=20
=20
On Feb 8, 2007, at 11:15 PM, Zhu Ebony-r57400 wrote:
=20
We should do this via INIT_THREAD, is there a reason that
you want to
quoted
quoted
set these always?
I just thought it's the first time that an SPE instruction is=20
encountered, so I enable the exceptions here.
Lets do this via INIT_THREAD instead, its cleaner. (just=20
remember to=20
quoted
quoted
add the proper ifdef protection for SPE_IEEE
Talking about INIT_THREAD, I'm wondering where is the best place to=20
enble the exceptions? Please advice!
=20
What's the issue with enabling via INIT_THREAD? am I missing=20
something?
Do you mean that add=20
".spefscr =3D SPEFSCR_FINV| SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE"
In the defination of INIT_THREAD?
I think it should work.
From: Kumar Gala <hidden> Date: 2007-02-09 06:04:28
On Feb 8, 2007, at 11:48 PM, Zhu Ebony-r57400 wrote:
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, February 09, 2007 1:29 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support
for Embedded Floating-Point instructions
On Feb 8, 2007, at 11:15 PM, Zhu Ebony-r57400 wrote:
quoted
quoted
quoted
quoted
quoted
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/
quoted
quoted
quoted
quoted
quoted
kernel/head_fsl_booke.S index 66877bd..0d05db0 100644
We should do this via INIT_THREAD, is there a reason that
you want to
quoted
quoted
set these always?
I just thought it's the first time that an SPE instruction is
encountered, so I enable the exceptions here.
Lets do this via INIT_THREAD instead, its cleaner. (just
remember to
quoted
quoted
add the proper ifdef protection for SPE_IEEE
Talking about INIT_THREAD, I'm wondering where is the best place to
enble the exceptions? Please advice!
What's the issue with enabling via INIT_THREAD? am I missing
something?
Do you mean that add
".spefscr = SPEFSCR_FINV| SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE"
In the defination of INIT_THREAD?
You may want to have something like #define SPE_EXCEPTION_ENABLE
(SPEFSCR_FINV| SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE)
Yep, with the proper #ifdef CONFIG_ protection.
- k
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Friday, February 09, 2007 2:04 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support=20
for Embedded Floating-Point instructions
=20
=20
On Feb 8, 2007, at 11:48 PM, Zhu Ebony-r57400 wrote:
=20
quoted
quoted
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Friday, February 09, 2007 1:29 PM
To: Zhu Ebony-r57400
Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support for=20
Embedded Floating-Point instructions
On Feb 8, 2007, at 11:15 PM, Zhu Ebony-r57400 wrote:
quoted
quoted
quoted
quoted
quoted
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/
quoted
quoted
quoted
quoted
quoted
kernel/head_fsl_booke.S index 66877bd..0d05db0 100644
load_up_spe:
oris r5,r5,MSR_SPE@h
mtmsr r5 /* enable use
of SPE now */
quoted
quoted
quoted
quoted
quoted
isync
+ li r5,(SPEFSCR_FINVE | SPEFSCR_FDBZE |
SPEFSCR_FUNFE |
quoted
quoted
quoted
quoted
quoted
SPEFSCR_FOVFE)
+ mtspr SPRN_SPEFSCR,r5
We should do this via INIT_THREAD, is there a reason that
you want to
quoted
quoted
set these always?
I just thought it's the first time that an SPE instruction is=20
encountered, so I enable the exceptions here.
Lets do this via INIT_THREAD instead, its cleaner. (just
remember to
quoted
quoted
add the proper ifdef protection for SPE_IEEE
Talking about INIT_THREAD, I'm wondering where is the=20
best place to=20
quoted
quoted
quoted
enble the exceptions? Please advice!
What's the issue with enabling via INIT_THREAD? am I missing=20
something?
Do you mean that add
".spefscr =3D SPEFSCR_FINV| =
SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE"
quoted
In the defination of INIT_THREAD?
=20
You may want to have something like #define=20
SPE_EXCEPTION_ENABLE (SPEFSCR_FINV|=20
SPEFSCR_FDBZE|SPEFSCR_FUNFE|SPEFSCR_FOVFE)
=20
Yep, with the proper #ifdef CONFIG_ protection.
I thought we were going to have some general Kconfig option
to enable all this? EMDEDDED_FP_IEEE or something like that
So that users have chance to enable/disable fully IEEE compliance?
Segher
had mentioned this, and it sounds reasonable.
Its alot of code to bring in if you don't care about IEEE compliance.
Yes certainly, and that's important for embedded applications.
My point however is that this should be selectable *per process*
at runtime. Compare to the AltiVec situation (where processes
can select (non-)IEEE behaviour by themselves); most tasks do
*not* want IEEE behaviour as it is just too expensive (and not
necessary for many applications).
Segher
I'm sorry, but is sysdev/ really fitting place for this file?
Shouldn't it be under kernel/ or math-emu/ instead?
quoted
quoted
Also, the name doesn't look fittingto me, since we're not
handling
*SIGFPE* here (which is for userland), we're handling SPE
exceptions.
quoted
arch/powerpc/math-emu/spe/<whatever>.c seems like a good
place?
Yeah, certainly more like it. :-)
quoted
Segher
Agreed, this shouldn't have been in sysdev, didn't notice that :)
We should probably rename this as well, since its not just handling
the sigfpe part, but the actual fixup/emulation.
- k
-----Original Message-----
From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
Sent: Friday, February 09, 2007 10:40 PM
To: Kumar Gala
Cc: paulus@samba.org; Zhu Ebony-r57400; linuxppc-dev@ozlabs.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support=20
for Embedded Floating-Point instructions
=20
quoted
quoted
quoted
I thought we were going to have some general Kconfig option to=20
enable all this? EMDEDDED_FP_IEEE or something like that
So that users have chance to enable/disable fully IEEE compliance?
Segher
had mentioned this, and it sounds reasonable.
Its alot of code to bring in if you don't care about IEEE=20
compliance.
=20
Yes certainly, and that's important for embedded applications.
=20
My point however is that this should be selectable *per=20
process* at runtime. Compare to the AltiVec situation (where=20
processes can select (non-)IEEE behaviour by themselves);=20
most tasks do
*not* want IEEE behaviour as it is just too expensive (and=20
not necessary for many applications).
=20
=20
Segher
Sorry for the delaying response since I just came back from vacation.
Agreed with you that the IEEE handler is expensive for processes. Do
you
think adding a switch to the Kconfig option is not enough? I'm
wondering how
to make it selectable *per process* at runtime.
Ebony
-----Original Message-----
From: linuxppc-dev-bounces+ebony.zhu=3Dfreescale.com@ozlabs.org=20
[mailto:linuxppc-dev-bounces+ebony.zhu=3Dfreescale.com@ozlabs.or
g] On Behalf Of Kumar Gala
Sent: Friday, February 23, 2007 2:23 AM
To: Sergei Shtylyov
Cc: linuxppc-dev@ozlabs.org; paulus@samba.org
Subject: Re: [patch][5/5] powerpc V2: Add the general support=20
for EmbeddedFloating-Point instructions
=20
=20
On Feb 22, 2007, at 10:56 AM, Sergei Shtylyov wrote:
=20
I'm sorry, but is sysdev/ really fitting place for this file?
Shouldn't it be under kernel/ or math-emu/ instead?
quoted
quoted
Also, the name doesn't look fittingto me, since we're not=20
handling
*SIGFPE* here (which is for userland), we're handling SPE=20
exceptions.
quoted
arch/powerpc/math-emu/spe/<whatever>.c seems like a good place?
Yeah, certainly more like it. :-)
quoted
Segher
=20
Agreed, this shouldn't have been in sysdev, didn't notice that :)
=20
We should probably rename this as well, since its not just=20
handling the sigfpe part, but the actual fixup/emulation.
=20
- k
Hi All,
Base on your suggestion, how about move sigfpe_handler.c to
arch/powerpc/math-emu/spe/spe_handler.c? Or do you have any other
suggestions on file name?
B.R.
Ebony