Pentium problems reported on net
David Hough
sun!Eng!David.Hough
Mon Nov 7 15:48:33 PST 1994
Starting from a posting in comp.arch.arithmetic, Alex Liu tracked down the
original in comp.sys.intel, and extracted the following short test program
which fails on our local Pentium system running Solaris, and passes on our
local 486 system running Solaris; "long double" means Intel extended here:
/*
Expected output:
t0 = 8.24633702441000000000e+11 :4026BFFFFFB829000000
t1 = 1.00000000000000000000e+00 :3FFF8000000000000000
t2 = 1.21265962940866695676e-12 :3FD7AAAAAAEA8638FB73
t3 = 1.00000000000000000000e+00 :3FFF8000000000000000
On the Pentium, one gets instead:
t0 = 8.24633702441000000000e+11 :4026BFFFFFB829000000
t1 = 1.00000000000000000000e+00 :3FFF8000000000000000
t2 = 1.21265962489115780402e-12 :3FD7AAAAAADFDB8E4CCB
t3 = 9.99999996274709701592e-01 :3FFEFFFFFFF000000001
*/
#include <stdio.h>
#include <stdlib.h>
static long double
foo(void) {
return 824633702441.0L;
}
void
Dump(unsigned char *p) {
int i;
for (i = 10 - 1; i != -1; i--)
printf("%2.2X", (unsigned int)(*(p+i)));
printf("\n");
}
void
main(void) {
long double t0, t1, t2, t3;
t0 = foo();
t1 = 1.0L;
t2 = t1 / t0;
t3 = t2 * t0;
printf("t0 = %30.20Le :",t0); Dump((unsigned char*)&t0);
printf("t1 = %30.20Le :",t1); Dump((unsigned char*)&t1);
printf("t2 = %30.20Le :",t2); Dump((unsigned char*)&t2);
printf("t3 = %30.20Le :",t3); Dump((unsigned char*)&t3);
exit(0);
}
Some of the earlier net postings:
Article: 21673 of comp.sys.intel
From: Terje.Mathisenahda.hydro.com (Terje Mathisen)
Newsgroups: comp.sys.intel
Subject: Glaring FDIV bug in Pentium!
Date: 3 Nov 1994 09:02:09 GMT
After my post yesterday about how Intel improved the precision of
trancendental functions on the Pentium, I got an interesting email from
Alex Wolfe, who works for EETimes.
It seems someone reported on Compuserve that the Windows calculator gave
wrong results when used on a Pentium machine, but correct on a 486!
I wrote a tiny test program, p87.pas, in Borland Pascal, using Extended real
precision (80 bit) for all fp operations to verify this.
It looks to me like the Pentium, both the 60 and the 90MHz models, only
carry fp divisions to single precision.
The tested expression is (1/824633702441)*824633702441:
Pentium (60 & 90)
8.24633702441000E+0011 = 4026BFFFFFB829000000 824633702441
1.00000000000000E+0000 = 3FFF8000000000000000 1
1.21265962489116E-0012 = 3FD7AAAAAADFDB8E4CCB 1/824...
9.99999996274710E-0001 = 3FFEFFFFFFF000000001 (1/824..)*824...
486DX
8.24633702441000E+0011 = 4026BFFFFFB829000000
1.00000000000000E+0000 = 3FFF8000000000000000
1.21265962940867E-0012 = 3FD7AAAAAAEA8638FB73
1.00000000000000E+0000 = 3FFF8000000000000000
Since the program is so tiny, I'll include it here (source and exe), so you
can verify if/that the bug exists in all your Pentium PCs.
I've reported these results directly to Intel and Compaq as well.
-Terje Mathisen (include std disclaimer) <Terje.Mathisenahda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Article: 9383 of comp.sys.intel
From: akaananke.s.bawue.de (Andreas Kaiser)
Newsgroups: comp.sys.intel
Subject: Re: Glaring FDIV bug in Pentium!
Date: Fri, 04 Nov 94 20:05:44 GMT
jenkinsjaoils.ozy.dec.com writes in article <39dcgc$7u9anntpd.lkg.dec.com>:
> Sureley this must be a difference between the 486 and 586, i.e.
> different FPDIV instructions what I mean this is intentional
> and not a blunder ??
Usually, the division is correct (what did you expect?). Just a few
operands are divided wrong. My results (P90) with ~25.000.000.000
random arguments (within 1..2^46), with even results divided by two
until odd, to assure unique mantissa patterns (the binary exponent
doesn't care, of course).
3221224323
12884897291
206158356633
824633702441
1443107810341
6597069619549
9895574626641
13194134824767
13194134826115
13194134827143
13194134827457
13194138356107
13194139238995
26388269649885
26388269650425
26388269651561
26388276711601
26388276712811
52776539295213
52776539301125
52776539301653
52776539307823
52776553426399
Gruss, Andreas
--------------------
-- Andreas Kaiser -- internet: akaananke.s.bawue.de
-------------------- fidonet: 2:246/8506.9
Article: 598 of comp.arch.arithmetic
From: dikacwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.arch.arithmetic,comp.sys.intel
Subject: Re: FDIV bug in Pentium chips!
Date: 6 Nov 94 02:01:42 GMT
In article <39g3f9$890avkhdsu01.hda.hydro.com> Terje.Mathisenahda.hydro.com (Terje Mathisen) writes:
> This is just a pointer to a discussion started a few days ago over in
> comp.sys.intel, re a problem with floating point divisions on Pentium
> cpus.
This is a follow-up from comp.arch, cross-posted to comp.arch.arithmetic
and comp.sys.intel with comp.arch left out from the follow-up newsgroups
(to make everything a bit more difficult ;-)). For the readers of c.a.a it
includes part of another message from c.s.i.
>
> Followups should probably be directed to c.s.i to avoid cluttering the
> news-groups.
I included c.a.a as it has relevance for that newsgroup.
>
> It seems FDIV is only carried out to about 29 bits of resolution in the
> mantissa, which is OK for single precision, but totally absurd for a chip
> that claims IEEE extended real (80-bit, 64 in mantissa) conformance.
>
The post by Andreas Kaiser seems to imply that is not really true; here
follows the relevant part:
In article <783979544snxaananke.s.bawue.de> akaananke.s.bawue.de (Andreas Kaiser) writes:
> Usually, the division is correct (what did you expect?). Just a few
> operands are divided wrong. My results (P90) with ~25.000.000.000
> random arguments (within 1..2^46), with even results divided by two
> until odd, to assure unique mantissa patterns (the binary exponent
> doesn't care, of course).
Followed by a list of 23 numbers for which the division goes wrong.
I have rearranged the list, giving the normalized mantissa in binary
(and indeed, exponent appears to be irrelevant):
1000111111111111111000110101111000010101000100 = 9895574626641
1010011111111111111101101101011000010010100000 = 1443107810341
1011111111111111111110111000001000110111101101 = 52776539295213
1011111111111111111110111000001001100100000000 = 206158356633
1011111111111111111110111000001001110011111100 = 13194134824767
1011111111111111111110111000001001111110111010 = 26388269649885
1011111111111111111110111000001010001111110010 = 26388269650425
1011111111111111111110111000001010010100000101 = 52776539301125
1011111111111111111110111000001010011100010101 = 52776539301653
1011111111111111111110111000001010110011010010 = 26388269651561
1011111111111111111110111000001011000000000000 = 12884897291
1011111111111111111110111000001011001000001100 = 13194134826115
1011111111111111111110111000001011111100101111 = 52776539307823
1011111111111111111110111000001100001000011100 = 13194134827143
1011111111111111111110111000001100011100000100 = 13194134827457
1011111111111111111111101110000010000101100010 = 26388276711601
1011111111111111111111101110000010011000101100 = 13194138356107
1011111111111111111111101110000010101011010110 = 26388276712811
1011111111111111111111101110000010110111011111 = 52776553426399
1011111111111111111111111011100000100101001100 = 13194139238995
1011111111111111111111111011100000101001000000 = 824633702441
1011111111111111111111111011100000101011101000 = 6597069619549
Except for the first two there is a common definite pattern:
a leading 10, followed by a bunch of 1's, followed by 0111000001.
If the random numbers are random enough this seems to be
significant. I would like to see verification of the first
two numbers listed (perhaps a transcription error or some-such?).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dikacwi.nl
More information about the Numeric-interest
mailing list