Commit Graph

30 Commits

Author SHA1 Message Date
Stephen Chivers
c59c015b6a powerpc: Correct emulated mtfsf instruction
The emulated (CONFIG_MATH_EMULATION_FULL)
PowerPC Floating Point instruction mtfsf
does not correctly copy bits from its source
register to the Floating Point Status and Register (FPSCR).

The error is in the preparation of the mask used to
select the bits to be copied from the source to the FPSCR.

Execution of the mtfsf instruction does not produce the same
results on a MPC8548 platform (emulated floating point)
as on MPC7410 or 440EP platforms (hardware floating point).

This error has been detected using a Freescale MPC8548
based platform and the patch below tested using that platform.

The patch is based on the patch(es) provided by
Gabriel Paubert and analysis by Gabriel, James Yang and David Laight.

Signed-off-by: Stephen Chivers <schivers@csc.com>
Signed-off-by: Gabriel Paubert <paubert@iram.es>
Tested-by: Stephen Chivers <schivers@csc.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-04-07 10:33:11 +10:00
Joseph Myers
01c9ccee3c powerpc: fix e500 SPE float SIGFPE generation
The e500 SPE floating-point emulation code is called from
SPEFloatingPointException and SPEFloatingPointRoundException in
arch/powerpc/kernel/traps.c.  Those functions have support for
generating SIGFPE, but do_spe_mathemu and speround_handler don't
generate a return value to indicate that this should be done.  Such a
return value should depend on whether an exception is raised that has
been set via prctl to generate SIGFPE.  This patch adds the relevant
logic in these functions so that SIGFPE is generated as expected by
the glibc testsuite.

Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
2014-01-07 18:43:42 -06:00
Joseph Myers
28fbf1d540 powerpc: fix e500 SPE float to integer and fixed-point conversions
The e500 SPE floating-point emulation code has several problems in how
it handles conversions to integer and fixed-point fractional types.

There are the following 20 relevant instructions.  These can convert
to signed or unsigned 32-bit integers, either rounding towards zero
(as correct for C casts from floating-point to integer) or according
to the current rounding mode, or to signed or unsigned 32-bit
fixed-point values (values in the range [-1, 1) or [0, 1)).  For
conversion from double precision there are also instructions to
convert to 64-bit integers, rounding towards zero, although as far as
I know those instructions are completely theoretical (they are only
defined for implementations that support both SPE and classic 64-bit,
and I'm not aware of any such hardware even though the architecture
definition permits that combination).

#define EFSCTUI		0x2d4
#define EFSCTSI		0x2d5
#define EFSCTUF		0x2d6
#define EFSCTSF		0x2d7
#define EFSCTUIZ	0x2d8
#define EFSCTSIZ	0x2da

#define EVFSCTUI	0x294
#define EVFSCTSI	0x295
#define EVFSCTUF	0x296
#define EVFSCTSF	0x297
#define EVFSCTUIZ	0x298
#define EVFSCTSIZ	0x29a

#define EFDCTUIDZ	0x2ea
#define EFDCTSIDZ	0x2eb

#define EFDCTUI		0x2f4
#define EFDCTSI		0x2f5
#define EFDCTUF		0x2f6
#define EFDCTSF		0x2f7
#define EFDCTUIZ	0x2f8
#define EFDCTSIZ	0x2fa

The emulation code, for the instructions that come in variants
rounding either towards zero or according to the current rounding
direction, uses "if (func & 0x4)" as a condition for using _FP_ROUND
(otherwise _FP_ROUND_ZERO is used).  The condition is correct, but the
code it controls isn't.  Whether _FP_ROUND or _FP_ROUND_ZERO is used
makes no difference, as the effect of those soft-fp macros is to round
an intermediate floating-point result using the low three bits (the
last one sticky) of the working format.  As these operations are
dealing with a freshly unpacked floating-point input, those low bits
are zero and no rounding occurs.  The emulation code then uses the
FP_TO_INT_* macros for the actual integer conversion, with the effect
of always rounding towards zero; for rounding according to the current
rounding direction, it should be using FP_TO_INT_ROUND_*.

The instructions in question have semantics defined (in the Power ISA
documents) for out-of-range values and NaNs: out-of-range values
saturate and NaNs are converted to zero.  The emulation does nothing
to follow those semantics for NaNs (the soft-fp handling is to treat
them as infinities), and messes up the saturation semantics.  For
single-precision conversion to integers, (((func & 0x3) != 0) || SB_s)
is the condition used for doing a signed conversion.  The first part
is correct, but the second isn't: negative numbers should result in
saturation to 0 when converted to unsigned.  Double-precision
conversion to 64-bit integers correctly uses ((func & 0x1) == 0).
Double-precision conversion to 32-bit integers uses (((func & 0x3) !=
0) || DB_s), with correct first part and incorrect second part.  And
vector float conversion to integers uses (((func & 0x3) != 0) ||
SB0_s) (and similar for the other vector element), where the sign bit
check is again wrong.

The incorrect handling of negative numbers converted to unsigned was
introduced in commit afc0a07d4a.  The
rationale given there was a C testcase with cast from float to
unsigned int.  Conversion of out-of-range floating-point numbers to
integer types in C is undefined behavior in the base standard, defined
in Annex F to produce an unspecified value.  That is, the C testcase
used to justify that patch is incorrect - there is no ISO C
requirement for a particular value resulting from this conversion -
and in any case, the correct semantics for such emulation are the
semantics for the instruction (unsigned saturation, which is what it
does in hardware when the emulation is disabled).

The conversion to fixed-point values has its own problems.  That code
doesn't try to do a full emulation; it relies on the trap handler only
being called for arguments that are infinities, NaNs, subnormal or out
of range.  That's fine, but the logic ((vb.wp[1] >> 23) == 0xff &&
((vb.wp[1] & 0x7fffff) > 0)) for NaN detection won't detect negative
NaNs as being NaNs (the same applies for the double-precision case),
and subnormals are mapped to 0 rather than respecting the rounding
mode; the code should also explicitly raise the "invalid" exception.
The code for vectors works by executing the scalar float instruction
with the trapping disabled, meaning at least subnormals won't be
handled correctly.

As well as all those problems in the main emulation code, the rounding
handler - used to emulate rounding upward and downward when not
supported in hardware and when no higher priority exception occurred -
has its own problems.

* It gets called in some cases even for the instructions rounding to
  zero, and then acts according to the current rounding mode when it
  should just leave alone the truncated result provided by hardware.

* It presumes that the result is a single-precision, double-precision
  or single-precision vector as appropriate for the instruction type,
  determines the sign of the result accordingly, and then adjusts the
  result based on that sign and the rounding mode.

  - In the single-precision cases at least the sign determination for
    an integer result is the same as for a floating-point result; in
    the double-precision case, converted to 32-bit integer or fixed
    point, the sign of a double-precision value is in the high part of
    the register but it's the low part of the register that has the
    result of the conversion.

  - If the result is unsigned fixed-point, its sign may be wrongly
    determined as negative (does not actually cause problems, because
    inexact unsigned fixed-point results with the high bit set can
    only appear when converting from double, in which case the sign
    determination is instead wrongly using the high part of the
    register).

  - If the sign of the result is correctly determined as negative, any
    adjustment required to change the truncated result to one correct
    for the rounding mode should be in the opposite direction for
    two's-complement integers as for sign-magnitude floating-point
    values.

  - And if the integer result is zero, the correct sign can only be
    determined by examining the original operand, and not at all (as
    far as I can tell) if the operand and result are the same
    register.

This patch fixes all these problems (as far as possible, given the
inability to determine the correct sign in the rounding handler when
the truncated result is 0, the conversion is to a signed type and the
truncated result has overwritten the original operand).  Conversion to
fixed-point now uses full emulation, and does not use "asm" in the
vector case; the semantics are exactly those of converting to integer
according to the current rounding direction, once the exponent has
been adjusted, so the code makes such an adjustment then uses the
FP_TO_INT_ROUND macros.

The testcase I used for verifying that the instructions (other than
the theoretical conversions to 64-bit integers) produce the correct
results is at <http://lkml.org/lkml/2013/10/8/708>.

Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
2014-01-07 18:38:59 -06:00
Joseph Myers
28414a6def powerpc: fix e500 SPE float rounding inexactness detection
The e500 SPE floating-point emulation code for the rounding modes
rounding to positive or negative infinity (which may not be
implemented in hardware) tries to avoid emulating rounding if the
result was inexact.  However, it tests inexactness using the sticky
bit with the cumulative result of previous operations, rather than
with the non-sticky bits relating to the operation that generated the
interrupt.  Furthermore, when a vector operation generates the
interrupt, it's possible that only one of the low and high parts is
inexact, and so only that part should have rounding emulated.  This
results in incorrect rounding of exact results in these modes when the
sticky bit is set from a previous operation.

(I'm not sure why the rounding interrupts are generated at all when
the result is exact, but empirically the hardware does generate them.)

This patch checks for inexactness using the correct bits of SPEFSCR,
and ensures that rounding only occurs when the relevant part of the
result was actually inexact.

Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
2014-01-07 18:33:48 -06:00
Joseph Myers
640e922501 powerpc: fix exception clearing in e500 SPE float emulation
The e500 SPE floating-point emulation code clears existing exceptions
(__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
emulated operation.  However, these exception bits are the "sticky",
cumulative exception bits, and should only be cleared by the user
program setting SPEFSCR, not implicitly by any floating-point
instruction (whether executed purely by the hardware or emulated).
The spurious clearing of these bits shows up as missing exceptions in
glibc testing.

Fixing this, however, is not as simple as just not clearing the bits,
because while the bits may be from previous floating-point operations
(in which case they should not be cleared), the processor can also set
the sticky bits itself before the interrupt for an exception occurs,
and this can happen in cases when IEEE 754 semantics are that the
sticky bit should not be set.  Specifically, the "invalid" sticky bit
is set in various cases with non-finite operands, where IEEE 754
semantics do not involve raising such an exception, and the
"underflow" sticky bit is set in cases of exact underflow, whereas
IEEE 754 semantics are that this flag is set only for inexact
underflow.  Thus, for correct emulation the kernel needs to know the
setting of these two sticky bits before the instruction being
emulated.

When a floating-point operation raises an exception, the kernel can
note the state of the sticky bits immediately afterwards.  Some
<fenv.h> functions that affect the state of these bits, such as
fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
PR_SET_FPEXC anyway, and so it is natural to record the state of those
bits during that call into the kernel and so avoid any need for a
separate call into the kernel to inform it of a change to those bits.
Thus, the interface I chose to use (in this patch and the glibc port)
is that one of those prctl calls must be made after any userspace
change to those sticky bits, other than through a floating-point
operation that traps into the kernel anyway.  feclearexcept and
fesetexceptflag duly make those calls, which would not be required
were it not for this issue.

The previous EGLIBC port, and the uClibc code copied from it, is
fundamentally broken as regards any use of prctl for floating-point
exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its
prctl calls (and did various worse things, such as passing a pointer
when prctl expected an integer).  If you avoid anything where prctl is
used, the clearing of sticky bits still means it will never give
anything approximating correct exception semantics with existing
kernels.  I don't believe the patch makes things any worse for
existing code that doesn't try to inform the kernel of changes to
sticky bits - such code may get incorrect exceptions in some cases,
but it would have done so anyway in other cases.

Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
2014-01-07 18:32:21 -06:00
James Yang
cc7059b5ea powerpc/math-emu: Fix load/store indexed emulation
Load/store indexed instructions where the index register RA=R0, such
as "lfdx f1,0,r3", are not illegal.

Load/store indexed with update instructions where the index register
RA=R0, such as "lfdux f1,0,r3", are invalid, and, to be consistent
with existing math-emu behavior for other invalid instruction forms,
will signal as illegal.

Signed-off-by: James Yang <James.Yang@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:59:57 +10:00
Kevin Hao
037f0eed57 powerpc: Make flush_fp_to_thread() nop when CONFIG_PPC_FPU is disabled
In the current kernel, the function flush_fp_to_thread() is not
dependent on CONFIG_PPC_FPU. So most invocations of this function
is not wrapped by CONFIG_PPC_FPU. Even through we don't really
save the FPRs to the thread struct if CONFIG_PPC_FPU is not enabled,
but there does have some runtime overhead such as the check for
tsk->thread.regs and preempt disable and enable. It really make
no sense to do that. So make it a nop when CONFIG_PPC_FPU is
disabled. Also remove the wrapped #ifdef CONFIG_PPC_FPU
when invoking this function.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:59:44 +10:00
Kevin Hao
e05c0e81b0 powerpc: split She math emulation into two parts
For some SoC (such as the FSL BookE) even though there does have
a hardware FPU, but not all floating point instructions are
implemented. Unfortunately some versions of gcc do use these
unimplemented instructions. Then we have to enable the math emulation
to workaround this issue. It seems a little redundant to have the
support to emulate all the floating point instructions in this case.
So split the math emulation into two parts. One is for the SoC which
doesn't have FPU at all and the other for the SoC which does have the
hardware FPU and only need some special floating point instructions to
be emulated.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:59:19 +10:00
Kevin Hao
6761ee3d7e powerpc/math-emu: Move the flush FPU state function into do_mathemu
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:59:06 +10:00
Kevin Hao
f0870c5530 powerpc/math-emu: Remove the unneeded check for CONFIG_MATH_EMULATION in math.c
The math.c is only built when CONFIG_MATH_EMULATION is enabled.
So the #ifdef check for CONFIG_MATH_EMULATION in it seems redundant.
Drop all of them.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:58:46 +10:00
Kevin Hao
cf5c2e543c powerpc/math-emu: Remove the dead code in math.c
The math.c is only built when CONFIG_MATH_EMULATION is enabled.
So we would never get into the case that CONFIG_MATH_EMULATION
is not defined in this file.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-08-14 14:58:40 +10:00
Benjamin Herrenschmidt
04ae900171 powerpc/math-emu: Fix decoding of some instructions
The decoding of some instructions such as fsqrt{s} was incorrect,
using the wrong registers, and thus could not work.

This fixes it and also adds a couple of place holders for missing
instructions.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-20 17:05:05 +10:00
Liu Yu
09af52f78e powerpc/math_emu/efp: Look for errata handler when type mismatches
We already have cpu a005 errata handler when instruction cannot be
recognized.  Before we lookup the inst, there's type checking, and we also
need to handle it in errata handler when the type checking failed.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-10-06 23:36:47 -05:00
Liu Yu
d5755e6f3a powerpc/math_emu/efp: No need to round if the result is exact
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-10-06 23:36:44 -05:00
Liu Yu
b430abc4d1 powerpc/math_emu/efp: Use pr_debug instead of printk
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-10-06 23:36:37 -05:00
Shan Hai
afc0a07d4a powerpc/85xx: Fix SPE float to integer conversion failure
Conversion from float to integer should based on both the instruction
encoding and the sign of the operand.

A simple testcase to show the issue:

static float fm;
static signed int si_min = (-2147483647 - 1);
static unsigned int ui;
int main()
{
       fm = (float) si_min; ;
       ui = (unsigned int)fm;
       printf("ui=%d, should be %d\n", ui, si_min);

       return 0;
}
Result: ui=-1, should be -2147483648

Signed-off-by: Shan Hai <shan.hai@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-03-15 13:48:15 -05:00
Liu Yu
ac6f120369 powerpc/85xx: Workaroudn e500 CPU erratum A005
This erratum can occur if a single-precision floating-point,
double-precision floating-point or vector floating-point instruction on a
mispredicted branch path signals one of the floating-point data interrupts
which are enabled by the SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits).  This
interrupt must be recorded in a one-cycle window when the misprediction is
resolved.  If this extremely rare event should occur, the result could be:

The SPE Data Exception from the mispredicted path may be reported
erroneously if a single-precision floating-point, double-precision
floating-point or vector floating-point instruction is the second
instruction on the correct branch path.

According to errata description, some efp instructions which are not
supposed to trigger SPE exceptions can trigger the exceptions in this case.
However, as we haven't emulated these instructions here, a signal will
send to userspace, and userspace application would exit.

This patch re-issue the efp instruction that we haven't emulated,
so that hardware can properly execute it again if this case happen.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-03-15 10:05:06 -05:00
matt mooney
4108d9ba90 powerpc/Makefiles: Change to new flag variables
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.

Signed-off-by: matt mooney <mfm@muteddisk.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-10-13 16:19:22 +11:00
Liu Yu
1a3d1fc227 powerpc/math-emu: Fix efp dependence
There is no dependece between efp and math-emu.  But when disable math-emu
the efp code cannot be built.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-03-11 06:00:08 -05:00
Liu Yu
6a800f36ac powerpc: Add SPE/EFP math emulation for E500v1/v2 processors.
This patch add the handlers of SPE/EFP exceptions.
The code is used to emulate float point arithmetic,
when MSR(SPE) is enabled and receive EFP data interrupt or EFP round interrupt.

This patch has no conflict with or dependence on FP math-emu.

The code has been tested by TestFloat.

Now the code doesn't support SPE/EFP instructions emulation
(it won't be called when receive program interrupt),
but it could be easily added.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-12-03 08:19:16 -06:00
Liu Yu
033b8a333c powerpc/math-emu: Remove redundant 'ret'
FP_DECL_EX is already used, so ret is redundant.
And FP_SET_EXCEPTION will add status into return value.

Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-12-03 08:19:15 -06:00
Kumar Gala
d2b194ed82 powerpc/math-emu: Use kernel generic math-emu code
The math emulation code is centered around a set of generic macros that
provide the core of the emulation that are shared by the various
architectures and other projects (like glibc).  Each arch implements its
own sfp-machine.h to specific various arch specific details.

For historic reasons that are now lost the powerpc math-emu code had
its own version of the common headers.  This moves us to using the
kernel generic version and thus getting fixes when those are updated.

Also cleaned up exception/error reporting from the FP emulation functions.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-10-01 08:40:07 -05:00
Michael Neuling
9c75a31c35 powerpc: Add macros to access floating point registers in thread_struct.
We are going to change where the floating point registers are stored
in the thread_struct, so in preparation add some macros to access the
floating point registers.  Update all code to use these new macros.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-01 11:28:43 +10:00
Harvey Harrison
e48b1b452f [POWERPC] Replace remaining __FUNCTION__ occurrences
__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-01 20:43:09 +11:00
Liu Yu
e3bc3a09bd [POWERPC] Fix carry bug in 128-bit unsigned integer adding
Synchronize it to the definition in include/math-emu/op-4.h for short term.

Signed-off-by: Liu Yu <Yu.Liu@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2008-01-23 19:34:21 -06:00
Liu Yu
c896862105 [POWERPC] Fix rounding bug in emulation for double float operating
This patch fixes rounding bug in emulation for double float operating on PowerPC platform.

When pack double float operand, it need to truncate the tail due to the limited precision.
If the truncated part is not zero, the last bit of work bit (totally 3 bits) need to '|' 1.

This patch is completed in _FP_FRAC_SRS_2(X,N,sz) (arch/powerpc/math-emu/op-2.h).
Originally the code leftwards rotates the operand to just keep the truncated part,
then check whether it is zero. However, the number it rotates is not correct when
N is not smaller than _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the improper case.

This patch fixes this issue.

Signed-off-by: Liu Yu <b13201@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-12-13 22:59:00 -06:00
Kumar Gala
ba02946a90 [POWERPC] Fix handling of stfiwx math emulation
Its legal for the stfiwx instruction to have RA = 0 as part of its
effective address calculation.  This is illegal for all other XE
form instructions.

Add code to compute the proper effective address for stfiwx if
RA = 0 rather than treating it as illegal.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-10-16 09:05:24 -05:00
Al Viro
054e51a44b [POWERPC] ppc math-emu needs -fno-builtin-fabs for math.c and fabs.c
... since they deal with internal function with that name.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-26 15:24:35 +10:00
Jörn Engel
6ab3d5624e Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-30 19:25:36 +02:00
Kumar Gala
5cd272085b powerpc: move math-emu over to arch/powerpc
Towards the goal of having arch/powerpc not build anything over in arch/ppc
move math-emu over.  Also, killed some references to arch/ppc/ in the
arch/powerpc Makefile which should belong in drivers/ when the particular
sub-arch's move over to arch/powerpc.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2006-03-27 23:43:27 -06:00