"Lynn McGuire" wrote:
That particular test is for detection of the Pentium
FPU FDIV bug:
http://en.wikipedia.org/wiki/Pentium_FDIV_bug

Yes, I remember that defect quite well. That bug appeared and was fixed
long ago (c. 1993 according to the wiki article). No modern Intel x32 or
x64 processor has that defect.


"Lynn McGuire" wrote:
If that test does not round to exactly zero then the
FPU is having problems.

I don't see that test or that statement in the wiki article. I suspect you
are relying on information you found by following one of the many links on
that webpage.

If you can point me to it, I'd appreciate it.

In any case, I am quite sure that it is referring to 80-bit FPU operations,
not rounding to 64-bit.

And as I demonstrated with the VBA procedure "testit2", the 80-bit FPU
operations do indeed result in exactly zero.

Note that the wiki article does clearly state that 4195835 / 3145727 should
result in 1.333820449136241002, and the FPU bug results in
1.333739068902037589 (forgive any typos).

First, I hasten to point out that that is beyond the formatting limits of
VBA, which will only format the first 15 significant digits.

But VBA arithmetic does indeed result in 1.33382044913624, essentially the
same as the corrected FPU result and not at all like the result due to the
FPU bug.

So the difference you see has nothing to do with the FPU bug. (But perhaps
you did not intend to imply otherwise.)

Actually, the exact 64-bit representation is
1.33382044913624,109305771980871213600039482116699 21875.

Note the difference in the 4 digits following the first 15: 1093 v. 1002.

That reinforces my assertion that any expectations of zero for the complete
test is based on the 80-bit FPU arithemetic, not as it is represented in
64-bit storage.

Moreover, I can tell you that 1.333820449136241002 is only an approximation.
An exact conversion of any binary fractional part will end in 5, as
demonstrated by the exact conversion of the 64-bit representation above.


"Lynn McGuire" wrote:
I am beginning to think that you are correct about
the rounding mode.

For my edification, please articulate what you "beginning to think" I am
correct about. I have made a number of assertions.

I hope the point you have come to understand is: the difference between the
DLL called from C++ and the DLL called from VBA is not related to the FPU
rounding mode; instead, it is probably related to 80-bit operands v. a mix
of 80-bit and 64-bit operands.

Certainly the rounding to 64-bit causes the difference. But I do not
believe that any change in FPU rounding mode would make a difference.

However, I can only speculate. I could be wrong. So I will be very
interested in your results after applying Martin's corrections.