summaryrefslogtreecommitdiff
path: root/arch/powerpc/math-emu
AgeCommit message (Collapse)AuthorFilesLines
2014-04-07powerpc: Correct emulated mtfsf instructionStephen Chivers1-35/+23
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-01-08powerpc: fix e500 SPE float SIGFPE generationJoseph Myers1-0/+20
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-08powerpc: fix e500 SPE float to integer and fixed-point conversionsJoseph Myers1-75/+188
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 afc0a07d4a283599ac3a6a31d7454e9baaeccca0. 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-08powerpc: fix e500 SPE float rounding inexactness detectionJoseph Myers1-7/+16
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-08powerpc: fix exception clearing in e500 SPE float emulationJoseph Myers1-1/+19
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>
2013-08-14powerpc/math-emu: Fix load/store indexed emulationJames Yang1-10/+5
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-14powerpc: Make flush_fp_to_thread() nop when CONFIG_PPC_FPU is disabledKevin Hao1-2/+1
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-14powerpc: split She math emulation into two partsKevin Hao2-18/+26
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-14powerpc/math-emu: Move the flush FPU state function into do_mathemuKevin Hao1-0/+9
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-14powerpc/math-emu: Remove the unneeded check for CONFIG_MATH_EMULATION in math.cKevin Hao1-4/+0
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-14powerpc/math-emu: Remove the dead code in math.cKevin Hao1-42/+0
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-06-20powerpc/math-emu: Fix decoding of some instructionsBenjamin Herrenschmidt4-5/+34
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>
2011-10-07powerpc/math_emu/efp: Look for errata handler when type mismatchesLiu Yu1-5/+1
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-07powerpc/math_emu/efp: No need to round if the result is exactLiu Yu1-1/+10
Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-10-07powerpc/math_emu/efp: Use pr_debug instead of printkLiu Yu1-46/+37
Signed-off-by: Liu Yu <yu.liu@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2011-03-15powerpc/85xx: Fix SPE float to integer conversion failureShan Hai1-4/+8
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-15powerpc/85xx: Workaroudn e500 CPU erratum A005Liu Yu1-1/+52
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>
2010-10-13powerpc/Makefiles: Change to new flag variablesmatt mooney1-1/+1
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>
2009-03-11powerpc/math-emu: Fix efp dependenceLiu Yu1-3/+2
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>
2008-12-03powerpc: Add SPE/EFP math emulation for E500v1/v2 processors.Liu Yu2-0/+722
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-03powerpc/math-emu: Remove redundant 'ret'Liu Yu18-52/+34
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-10-01powerpc/math-emu: Use kernel generic math-emu codeKumar Gala45-2574/+278
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-07-01powerpc: Add macros to access floating point registers in thread_struct.Michael Neuling1-28/+28
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-04-01[POWERPC] Replace remaining __FUNCTION__ occurrencesHarvey Harrison41-46/+46
__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-01-24[POWERPC] Fix carry bug in 128-bit unsigned integer addingLiu Yu1-10/+30
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>
2007-12-14[POWERPC] Fix rounding bug in emulation for double float operatingLiu Yu1-1/+2
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-10-16[POWERPC] Fix handling of stfiwx math emulationKumar Gala1-4/+9
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>
2006-09-26[POWERPC] ppc math-emu needs -fno-builtin-fabs for math.c and fabs.cAl Viro1-0/+3
... 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-06-30Remove obsolete #include <linux/config.h>Jörn Engel1-1/+0
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-28powerpc: move math-emu over to arch/powerpcKumar Gala53-0/+4506
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>