[patch][5/5] powerpc V2: Add the general support for Embedded Floating-Point instructions
Kumar Gala
galak at kernel.crashing.org
Fri Feb 9 04:31:25 EST 2007
On Feb 8, 2007, at 3:06 AM, Zhu Ebony-r57400 wrote:
>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> Sent: Thursday, February 08, 2007 3:33 PM
>> To: Zhu Ebony-r57400
>> Cc: paulus at samba.org; linuxppc-dev at 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 at freescale.com wrote:
>>
>>> Add the general support for Embedded Floating-Point instructions to
>>> fully comply with IEEE-754.
>>>
>>> Signed-off-by:Ebony Zhu <ebony.zhu at freescale.com>
>>> ---
>>> 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.
>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/
>>> kernel/head_fsl_booke.S
>>> index 66877bd..0d05db0 100644
>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>> @@ -705,7 +705,7 @@ #else
>>> #endif /* CONFIG_SPE */
>>>
>>> /* SPE Floating Point Round */
>>> - EXCEPTION(0x2050, SPEFloatingPointRound, unknown_exception,
>>> EXC_XFER_EE)
>>> + EXCEPTION(0x2050, SPEFloatingPointRound,
>>> SPEFloatingPointException_Round, EXC_XFER_EE)
>>>
>>> /* Performance Monitor */
>>> EXCEPTION(0x2060, PerformanceMonitor,
>>> performance_monitor_exception, EXC_XFER_STD)
>>> @@ -840,6 +840,8 @@ load_up_spe:
>>> oris r5,r5,MSR_SPE at h
>>> mtmsr r5 /* enable use of SPE now */
>>> isync
>>> + li r5,(SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE |
>>> SPEFSCR_FOVFE)
>>> + mtspr SPRN_SPEFSCR,r5
>>
>> We should do this via INIT_THREAD, is there a reason that you
>> want to
>> 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
add the proper ifdef protection for SPE_IEEE
>>> /*
>>> * For SMP, we don't do lazy SPE switching because it just gets too
>>> * horrendously complex, especially when a task switches
>> from one CPU
>>> diff --git a/arch/powerpc/kernel/traps.c
>> b/arch/powerpc/kernel/traps.c
>>> index 6915b91..30ab0f7 100644
>>> --- a/arch/powerpc/kernel/traps.c
>>> +++ b/arch/powerpc/kernel/traps.c
>>> @@ -986,9 +986,16 @@ #endif /* CONFIG_FSL_BOOKE */
>>> #ifdef CONFIG_SPE
>>> void SPEFloatingPointException(struct pt_regs *regs)
>>> {
>>> + extern int spedata_handler(struct pt_regs *regs);
>>> unsigned long spefscr;
>>> int fpexc_mode;
>>> int code = 0;
>>> + int err;
>>> +
>>> + preempt_disable();
>>> + if (regs->msr & MSR_SPE)
>>> + giveup_spe(current);
>>> + preempt_enable();
>>
>> use flush_spe_to_thread(current);
>
> OK. It works, and I'll change it.
>
>>
>>>
>>> spefscr = current->thread.spefscr;
>>> fpexc_mode = current->thread.fpexc_mode;
>>> @@ -1013,9 +1020,55 @@ void SPEFloatingPointException(struct pt
>>> code = FPE_FLTRES;
>>>
>>> current->thread.spefscr = spefscr;
>>> + err = spedata_handler(regs);
>>> + if (err == 0) {
>>> + regs->nip += 4; /* skip emulated instruction */
>>> + emulate_single_step(regs);
>>> + return;
>>> + }
>>
>> 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)
>>> - _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.
>>> diff --git a/arch/powerpc/math-emu/Makefile
>> b/arch/powerpc/math-emu/
>>> Makefile
>>> index 29bc912..2da11ba 100644
>>> --- a/arch/powerpc/math-emu/Makefile
>>> +++ b/arch/powerpc/math-emu/Makefile
>>> @@ -1,16 +1,29 @@
>>>
>>> -obj-y := math.o fmr.o lfd.o stfd.o
>>> -
>>> -obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o
>> fadds.o fcmpo.o
>>> fcmpu.o \
>>> +obj-y := fabs.o fneg.o
>> 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
More information about the Linuxppc-dev
mailing list