Now this is getting intresting.. Its good to read that a bunch of hardware coders and
compiler writers dont even care about precision ;-) But thats a different story..
Seeking the internet for a Faulty P4 I did indeed ran into story's from back in 1995,
this P4 is from around 1998 so I expect it to have a bug anyway because it one from
a lowcost Compaq mainstream where the Sticker "Intel INside" is bigger then the
machine ittself..
Looking at the GCC compiler optimalizations I added the -march=pentium4 together
with the -O2 this indeed does help a bit but not yet fully to cover the DBL_MIN value
of (DBL_MIN 2.2250738585072014e-308) which is bothering me..
So this is what i did on the command line, a max and a min.. The only difference
where it clashes is the -308...not the max..
Code: Select all
>
(mul 2e308 2)
inf
> (mul 2e+308 2)
inf
> (div 2e+308 2)
inf
> (div 2e308 2)
inf
> (div 2e-308 2)
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009A.
Im seeking deeper...
PS: After a small C program compiled with GCC laso that clashed.. So its now time
to digg into this gcc port..
PPS: And why is there a difference of 6 all the time between the result and the
original??
Code: Select all
> (div (mul 4195835e128 3145727e128 ) 3145727e128 )
4.195835e+134
= 4195835e128 equal to 4.195835e+134 ? 6 zero's more ? Is this a rounding error?
> (div (mul 4195835e134 3145727e134 ) 3145727e134 )
4.195835e+140
..
> (div (mul 4195835e140 3145727e140) 3145727e140 )
4.195835e+146
> (div (mul 4195835e146 3145727e146) 3145727e146 )
4.195835e+152
> (div (mul 4195835e152 3145727e152) 3145727e152 )
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 0098.
PPPS: I did some tests for the FDIV P4 Bug but thats not My P4.. So lets assume
Compaq did sell a working "Intel Inside" for a second...