d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fb017b828d
freebsd-dev/lib/libc/i386/_fpmath.h

55 lines
1.9 KiB
C
Raw Normal View History

Implement fpclassify(): o Add a MD header private to libc called _fpmath.h; this header contains bitfield layouts of MD floating-point types. o Add a MI header private to libc called fpmath.h; this header contains bitfield layouts of MI floating-point types. o Add private libc variables to lib/libc/$arch/gen/infinity.c for storing NaN values. o Add __double_t and __float_t to <machine/_types.h>, and provide double_t and float_t typedefs in <math.h>. o Add some C99 manifest constants (FP_ILOGB0, FP_ILOGBNAN, HUGE_VALF, HUGE_VALL, INFINITY, NAN, and return values for fpclassify()) to <math.h> and others (FLT_EVAL_METHOD, DECIMAL_DIG) to <float.h> via <machine/float.h>. o Add C99 macro fpclassify() which calls __fpclassify{d,f,l}() based on the size of its argument. __fpclassifyl() is never called on alpha because (sizeof(long double) == sizeof(double)), which is good since __fpclassifyl() can't deal with such a small `long double'. This was developed by David Schultz and myself with input from bde and fenner. PR: 23103 Submitted by: David Schultz <dschultz@uclink.Berkeley.EDU> (significant portions) Reviewed by: bde, fenner (earlier versions)
2003-02-08 20:37:55 +00:00
/*-
Update my email address.
2005-02-06 03:23:31 +00:00
* Copyright (c) 2002, 2003 David Schultz <das@FreeBSD.ORG>
Implement fpclassify(): o Add a MD header private to libc called _fpmath.h; this header contains bitfield layouts of MD floating-point types. o Add a MI header private to libc called fpmath.h; this header contains bitfield layouts of MI floating-point types. o Add private libc variables to lib/libc/$arch/gen/infinity.c for storing NaN values. o Add __double_t and __float_t to <machine/_types.h>, and provide double_t and float_t typedefs in <math.h>. o Add some C99 manifest constants (FP_ILOGB0, FP_ILOGBNAN, HUGE_VALF, HUGE_VALL, INFINITY, NAN, and return values for fpclassify()) to <math.h> and others (FLT_EVAL_METHOD, DECIMAL_DIG) to <float.h> via <machine/float.h>. o Add C99 macro fpclassify() which calls __fpclassify{d,f,l}() based on the size of its argument. __fpclassifyl() is never called on alpha because (sizeof(long double) == sizeof(double)), which is good since __fpclassifyl() can't deal with such a small `long double'. This was developed by David Schultz and myself with input from bde and fenner. PR: 23103 Submitted by: David Schultz <dschultz@uclink.Berkeley.EDU> (significant portions) Reviewed by: bde, fenner (earlier versions)
2003-02-08 20:37:55 +00:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
union IEEEl2bits {
long double e;
struct {
unsigned int manl :32;
unsigned int manh :32;
unsigned int exp :15;
unsigned int sign :1;
unsigned int junk :16;
} bits;
Add an alternative view of the bits in an 80-bit long double (64+16 instead of 32+32+15+1) on all arches that have such long doubles (amd64, ia64 and i386). Large objects should be be accessed in large units, and the 32+32+15+1[+padding] decomposition asks for almost the opposite of that, sometimes resulting in very slow accesses depending on how well the compiler ignores what we ask for and converts to the best units for the given machine. E.g., on Athlons, there is a 10-20 cycle penalty for accessing the middle 32-bit word immediately after an 80-bit store. Whether actually using the alternative view is better is very machine- dependent. A 32+32+16 view is probably best with old 32-bit systems and gcc through 4.2.1. The compiler should mostly avoid the view and generate best accesses, but gcc-4.2.1 is far from doing that. I think 64+16 is best for now. Similarly for doubles -- they should be using 64+0 especially on 64-bit machines, but fdlibm uses 32+32 extensively for them. Fortunately, in 64-bit mode for doubles, gcc already ignores the 32+32-bit view and generates best accesses in many cases.
2008-01-17 16:39:07 +00:00
struct {
unsigned long long man :64;
unsigned int expsign :16;
unsigned int junk :16;
} xbits;
Implement fpclassify(): o Add a MD header private to libc called _fpmath.h; this header contains bitfield layouts of MD floating-point types. o Add a MI header private to libc called fpmath.h; this header contains bitfield layouts of MI floating-point types. o Add private libc variables to lib/libc/$arch/gen/infinity.c for storing NaN values. o Add __double_t and __float_t to <machine/_types.h>, and provide double_t and float_t typedefs in <math.h>. o Add some C99 manifest constants (FP_ILOGB0, FP_ILOGBNAN, HUGE_VALF, HUGE_VALL, INFINITY, NAN, and return values for fpclassify()) to <math.h> and others (FLT_EVAL_METHOD, DECIMAL_DIG) to <float.h> via <machine/float.h>. o Add C99 macro fpclassify() which calls __fpclassify{d,f,l}() based on the size of its argument. __fpclassifyl() is never called on alpha because (sizeof(long double) == sizeof(double)), which is good since __fpclassifyl() can't deal with such a small `long double'. This was developed by David Schultz and myself with input from bde and fenner. PR: 23103 Submitted by: David Schultz <dschultz@uclink.Berkeley.EDU> (significant portions) Reviewed by: bde, fenner (earlier versions)
2003-02-08 20:37:55 +00:00
};
Define LDBL_NBIT to be a mask indicating the position of the integer bit in a long double. For architectures that don't have such a bit, LDBL_NBIT is 0. This makes it possible to say `mantissa & ~LDBL_NBIT' in places that previously used an #ifdef to select the right expression. The optimizer should dispense with the extra arithmetic when LDBL_NBIT is 0.
2005-03-07 04:55:22 +00:00
#define LDBL_NBIT 0x80000000
#define mask_nbit_l(u) ((u).bits.manh &= ~LDBL_NBIT)
Add __ldtoa(), a wrapper around gdtoa() to make it look like dtoa(). In support of this, add some MD macros to assist in converting long doubles to the format expected by gdtoa(). Reviewed by: silence on standards@
2003-04-05 22:10:13 +00:00
Define LDBL_MANH_SIZE and LDBL_MANL_SIZE to be the sizes of the high and low words of the mantissa in bits, respectively.
2004-01-18 07:57:02 +00:00
#define LDBL_MANH_SIZE 32
#define LDBL_MANL_SIZE 32
Add __ldtoa(), a wrapper around gdtoa() to make it look like dtoa(). In support of this, add some MD macros to assist in converting long doubles to the format expected by gdtoa(). Reviewed by: silence on standards@
2003-04-05 22:10:13 +00:00
#define LDBL_TO_ARRAY32(u, a) do { \
(a)[0] = (uint32_t)(u).bits.manl; \
(a)[1] = (uint32_t)(u).bits.manh; \
Add an alternative view of the bits in an 80-bit long double (64+16 instead of 32+32+15+1) on all arches that have such long doubles (amd64, ia64 and i386). Large objects should be be accessed in large units, and the 32+32+15+1[+padding] decomposition asks for almost the opposite of that, sometimes resulting in very slow accesses depending on how well the compiler ignores what we ask for and converts to the best units for the given machine. E.g., on Athlons, there is a 10-20 cycle penalty for accessing the middle 32-bit word immediately after an 80-bit store. Whether actually using the alternative view is better is very machine- dependent. A 32+32+16 view is probably best with old 32-bit systems and gcc through 4.2.1. The compiler should mostly avoid the view and generate best accesses, but gcc-4.2.1 is far from doing that. I think 64+16 is best for now. Similarly for doubles -- they should be using 64+0 especially on 64-bit machines, but fdlibm uses 32+32 extensively for them. Fortunately, in 64-bit mode for doubles, gcc already ignores the 32+32-bit view and generates best accesses in many cases.
2008-01-17 16:39:07 +00:00
} while (0)
Reference in New Issue Copy Permalink