linux/arch/sparc/include/asm/sfp-machine.h

9 lines
200 B
C
Raw Normal View History

sparc: join the remaining header files With this commit all sparc64 header files are moved to asm-sparc. The remaining files (71 files) were too different to be trivially merged so divide them up in a _32.h and a _64.h file which are both included from the file with no bit size. The following script were used: cd include FILES=`wc -l asm-sparc64/*h | grep -v '^ 1' | cut -b 20-` for FILE in ${FILES}; do echo $FILE: BASE=`echo $FILE | cut -d '.' -f 1` FN32=${BASE}_32.h FN64=${BASE}_64.h GUARD=___ASM_SPARC_`echo $BASE | tr '-' '_' | tr [:lower:] [:upper:]`_H git mv asm-sparc/$FILE asm-sparc/$FN32 git mv asm-sparc64/$FILE asm-sparc/$FN64 echo git mv done printf "#ifndef %s\n" $GUARD > asm-sparc/$FILE printf "#define %s\n" $GUARD >> asm-sparc/$FILE printf "#if defined(__sparc__) && defined(__arch64__)\n" >> asm-sparc/$FILE printf "#include <asm-sparc/%s>\n" $FN64 >> asm-sparc/$FILE printf "#else\n" >> asm-sparc/$FILE printf "#include <asm-sparc/%s>\n" $FN32 >> asm-sparc/$FILE printf "#endif\n" >> asm-sparc/$FILE printf "#endif\n" >> asm-sparc/$FILE git add asm-sparc/$FILE echo new file done printf "#include <asm-sparc/%s>\n" $FILE > asm-sparc64/$FILE git add asm-sparc64/$FILE echo sparc64 file done done The guard contains three '_' to avoid conflict with existing guards. In additing the two Kbuild files are emptied to avoid breaking headers_* targets. We will reintroduce the exported header files when the necessary kbuild changes are merged. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-07-18 06:55:51 +02:00
#ifndef ___ASM_SPARC_SFP_MACHINE_H
#define ___ASM_SPARC_SFP_MACHINE_H
#if defined(__sparc__) && defined(__arch64__)
#include <asm/sfp-machine_64.h>
[MATH-EMU]: Fix underflow exception reporting. The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-17 07:59:49 +02:00
#else
#include <asm/sfp-machine_32.h>
[MATH-EMU]: Fix underflow exception reporting. The underflow exception cases were wrong. This is one weird area of ieee1754 handling in that the underflow behavior changes based upon whether underflow is enabled in the trap enable mask of the FPU control register. As a specific case the Sparc V9 manual gives us the following description: -------------------- If UFM = 0: Underflow occurs if a nonzero result is tiny and a loss of accuracy occurs. Tininess may be detected before or after rounding. Loss of accuracy may be either a denormalization loss or an inexact result. If UFM = 1: Underflow occurs if a nonzero result is tiny. Tininess may be detected before or after rounding. -------------------- What this amounts to in the packing case is if we go subnormal, we set underflow if any of the following are true: 1) rounding sets inexact 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too 3) underflow is set in FPU control register trap-enable mask The initially discovered example was "DBL_MIN / 16.0" which incorrectly generated an underflow. It should not, unless underflow is set in the trap-enable mask of the FPU csr. Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. However, if underflow is set in the trap enable mask, only underflow should be set and reported as a trap. That is handled properly by the prioritization logic in arch/sparc{,64}/math-emu/math.c:record_exception(). Based upon a report and test case from Jakub Jelinek. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-17 07:59:49 +02:00
#endif
#endif