UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/arch/mips/math-emu/dp_simple.c

50 lines
1.3 KiB
C
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
/* IEEE754 floating point arithmetic
* double precision: common utilities
*/
/*
* MIPS floating point support
* Copyright (C) 1994-2000 Algorithmics Ltd.
*
* This program is free software; you can distribute it and/or modify it
* under the terms of the GNU General Public License (Version 2) as
* published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
MIPS: math-emu: Cleanup coding style. o Only define variables in the outermost block o One empty line at most o Format comments as per CodingStyle o Update FSF address in licensing term comment o Spell FPU and MIPS in all capitals. o Remove ####-type of lines in comments. o Try to make things a bit most consistent between sp_*.c / dp_*.c files. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-04-26 07:49:14 +08:00
* 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
*/
#include "ieee754dp.h"
MIPS: math-emu: Get rid of typedefs. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-04-16 07:31:11 +08:00
union ieee754dp ieee754dp_neg(union ieee754dp x)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
{
MIPS: math-emu: Make ABS.fmt and NEG.fmt arithmetic again The ABS.fmt and NEG.fmt instructions have been specified as arithmetic in the MIPS architecture, which in particular implies handling NaN data in the usual way with qNaN bit patterns propagated unchanged and sNaN bit patterns signalling the usual IEEE 754 Invalid Operation exception and quieted by default. A series of changes applied over time to our implementation: c5033d78 [MIPS] ieee754[sd]p_neg workaround cea2be44 MIPS: Fix abs.[sd] and neg.[sd] emulation for NaN operands has led to the current situation where the sign bit is updated according to the operation requested even for NaN inputs. This is according to these commits a workaround so that broken binaries produced by GCC disregarding the properties of these instructions have a chance to work. For sNaN inputs this remains within IEEE Std 754 as the standard leaves the choice of output qNaN bit patterns produced under the default Invalid Operation exception handling for individual sNaN input bit patterns to implementer's discretion, even though it still recommends as much NaN input information to be preserved in NaN outputs. For qNaN inputs however it violates the standard as it requires a qNaN input bit patterns to propagate unchanged to output. This is also unlike real MIPS FPU hardware behaves where sNaN and/or qNaN processing has been fully implemented with no Unimplemented Operation exception signalled. Such hardware propagates any input qNaN bit pattern unchanged. It also quiets any input sNaN bit pattern in an implementer-specific manner, for example the MIPS 74Kf processor returns the default qNaN pattern with the sign bit always clear and the Broadcom SB-1 and BMIPS5000 processors propagate the input sNaN bit pattern with the sign bit unchanged and the quiet bit first cleared in the trailing significand field and then the next lower bit set if clearing the quiet bit left the field with no other bit set. Especially the latter observation indicates the limited usefulness of the workaround as it will cover many hardware configurations, but not all of them, only making it harder to discover such broken binaries that need to be recompiled with GCC told to avoid the use of ABS.fmt and NEG.fmt instructions where non-arithmetic semantics is required by the algorithm used. Revert the damage done by the series of changes then, and take the opportunity to simplify implementation by calling `ieee754dp_sub' and `ieee754dp_add' as required and also the rounding mode set towards -Inf temporarily so that the sign of 0 is correctly handled. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9710/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-04-04 06:27:43 +08:00
unsigned int oldrm;
union ieee754dp y;
oldrm = ieee754_csr.rm;
ieee754_csr.rm = FPU_CSR_RD;
y = ieee754dp_sub(ieee754dp_zero(0), x);
ieee754_csr.rm = oldrm;
return y;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
}
MIPS: math-emu: Get rid of typedefs. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-04-16 07:31:11 +08:00
union ieee754dp ieee754dp_abs(union ieee754dp x)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
{
MIPS: math-emu: Make ABS.fmt and NEG.fmt arithmetic again The ABS.fmt and NEG.fmt instructions have been specified as arithmetic in the MIPS architecture, which in particular implies handling NaN data in the usual way with qNaN bit patterns propagated unchanged and sNaN bit patterns signalling the usual IEEE 754 Invalid Operation exception and quieted by default. A series of changes applied over time to our implementation: c5033d78 [MIPS] ieee754[sd]p_neg workaround cea2be44 MIPS: Fix abs.[sd] and neg.[sd] emulation for NaN operands has led to the current situation where the sign bit is updated according to the operation requested even for NaN inputs. This is according to these commits a workaround so that broken binaries produced by GCC disregarding the properties of these instructions have a chance to work. For sNaN inputs this remains within IEEE Std 754 as the standard leaves the choice of output qNaN bit patterns produced under the default Invalid Operation exception handling for individual sNaN input bit patterns to implementer's discretion, even though it still recommends as much NaN input information to be preserved in NaN outputs. For qNaN inputs however it violates the standard as it requires a qNaN input bit patterns to propagate unchanged to output. This is also unlike real MIPS FPU hardware behaves where sNaN and/or qNaN processing has been fully implemented with no Unimplemented Operation exception signalled. Such hardware propagates any input qNaN bit pattern unchanged. It also quiets any input sNaN bit pattern in an implementer-specific manner, for example the MIPS 74Kf processor returns the default qNaN pattern with the sign bit always clear and the Broadcom SB-1 and BMIPS5000 processors propagate the input sNaN bit pattern with the sign bit unchanged and the quiet bit first cleared in the trailing significand field and then the next lower bit set if clearing the quiet bit left the field with no other bit set. Especially the latter observation indicates the limited usefulness of the workaround as it will cover many hardware configurations, but not all of them, only making it harder to discover such broken binaries that need to be recompiled with GCC told to avoid the use of ABS.fmt and NEG.fmt instructions where non-arithmetic semantics is required by the algorithm used. Revert the damage done by the series of changes then, and take the opportunity to simplify implementation by calling `ieee754dp_sub' and `ieee754dp_add' as required and also the rounding mode set towards -Inf temporarily so that the sign of 0 is correctly handled. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9710/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-04-04 06:27:43 +08:00
unsigned int oldrm;
union ieee754dp y;
oldrm = ieee754_csr.rm;
ieee754_csr.rm = FPU_CSR_RD;
if (DPSIGN(x))
y = ieee754dp_sub(ieee754dp_zero(0), x);
else
y = ieee754dp_add(ieee754dp_zero(0), x);
ieee754_csr.rm = oldrm;
return y;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
}