From owner-freebsd-questions Tue Feb 13 05:16:16 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA10599 for questions-outgoing; Tue, 13 Feb 1996 05:16:16 -0800 (PST) Received: from mx.kpn.com (mx.kpn.com [192.87.176.36]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA10592 for ; Tue, 13 Feb 1996 05:16:12 -0800 (PST) Received: (from uucp@localhost) by mx.kpn.com (8.6.10/8.6.10) with UUCP id OAA13191 for questions@FreeBSD.org; Tue, 13 Feb 1996 14:10:20 +0100 Received: (from smap@localhost) by hdxx05.unix.telecom.ptt.nl (8.6.10/8.6.10) id OAA08555 for ; Tue, 13 Feb 1996 14:05:32 +0100 Date: Tue, 13 Feb 1996 14:05:32 +0100 Message-Id: <199602131305.OAA08555@hdxx05.unix.telecom.ptt.nl> Received: from unknown(145.7.179.102) by hdxx05.unix.telecom.ptt.nl via smap (V1.3) id sma008535; Tue Feb 13 14:05:07 1996 X-Sender: oelen001@mailgate.telecom.ptt.nl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: questions@FreeBSD.org From: W.Oelen@PTT-Telecom.NL (Wilco Oelen) Subject: precision of 'long doubles' X-Mailer: Sender: owner-questions@FreeBSD.org Precedence: bulk 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. ---------------------------------------------------------------------------