Date: Tue, 13 Feb 1996 14:05:32 +0100 From: W.Oelen@PTT-Telecom.NL (Wilco Oelen) To: questions@FreeBSD.org Subject: precision of 'long doubles' Message-ID: <199602131305.OAA08555@hdxx05.unix.telecom.ptt.nl>
next in thread | raw e-mail | index | archive | help
Hello,
I'm using FreeBSD 2.1 for a while now and I'm using it with great pleasure.
It looks very stable and robust. However I have one question about using
floating point arithmatic under FreeBSD.
The Intel processors (80486/Pentium) support the so called extended
precision (or temporary double) format. This is an 80-bit format which
allows floating point operations with 64-bit mantissa and 16 bit exponent.
The gcc-compiler and also the gnu-assembler (as) supports this format. But
if I use this format under FreeBSD then only 53-bit mantissas are used (as
for standard doubles).
I used the following program to test the long double format:
main()
{
long double aa, bb;
double b;
aa = 1.0;
bb = 1.0/0x100000; /* divide by 2^20 */
bb /= 0x100000; /* idem */
bb /= 0x100000; /* idem */
bb = bb + 1.0; /* bb <-- 1 + 2^(-60). For a standard double the term */
/* 2^(-60) disappears due to roundoff. For a long */
/* double this term still is maintained. */
bb = bb -aa; /* bb <-- (1 + 2^(-60)) - 1. This equals zero for */
/* standard doubles, 2^(-60) for long doubles. */
b = bb; /* Convert to double in order to use printf with %le. */
/* 2^(-60) can be converted from long double to */
/* double. */
printf("sizeof double: %d\n", sizeof(double));
printf("sizeof long double: %d\n", sizeof(long double));
printf("b equals %le\n", b);
}
The result of this program is the following output:
sizeof double: 8
sizeof long double: 12
b equals 0.0e0
This program should give a non-zero result for b (2^(-60)) but it gives
zero. It uses 53-bit precision only and hence the value 2^(-60) disappears
due to roundoff when adding 1.0 and then subtracting 1.0 again. I also used
the same program under Linux 1.2.13 and there it gives the correct non-zero
result.
As a final test I compiled the program as follows under Linux:
gcc -S ldouble.c
gcc -c ldouble.s
This yields a module ldouble.o and I copied this to the FreeBSD system where
I linked it in order to obtain an executable binary:
gcc -o ldouble ldouble.o
So the object code has been generated by the Linux system (which supports
the long double correctly) and the binary has been made under FreeBSD 2.1.
But even with the above trick it does not work at full precision under FreeBSD.
I'm wondering why the code does not work under FreeBSD with full precision.
Even at the assembler and object level I do the same as under Linux but
still I do not succeed in obtaining the full extended precision.
I use a FreeBSD 2.1 kernel with math emulation switched off and npx0
enabled. This kernel is running on a Pentium 100 MHz with PCI bus. I did the
same tests (with the same results) on a 66 MHz Intel 80486DX2 with a PCI bus
as well.
The Linux system (where the long double precision _does_ work) contains an
AMD 80486DX2 running at 80 MHz with a VESA local bus. The Linux kernel has
math emulation switched off as well.
The FreeBSD kernel reports that npx0 is used, using the INT 16 interface.
Under Linux a similar message appears (FPU reports errors using interrupt 16).
I think that the hardware and kernel configurations are OK, so I think I do
something wrong with the software. If you can help me with this problem I
would be very pleased. Please let me hear if you know any solution to this
problem.
Thanks in advance,
Wilco Oelen
---------------------------------------------------------------------------
Wilco Oelen | Telephone: +31 50 855038
PTT Telecom BV | Telefax : +31 50 855310
I&AT | E-mail : W.Oelen@ptt-telecom.nl
P.O. Box 188 | DISCLAIMER: This statement is not an official
NL-9700 AD Groningen | statement from, nor does it represent an
The Netherlands | official position of, PTT Telecom B.V.
---------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602131305.OAA08555>