On 04/04/2012 09:29, joeu2004 wrote:
"Martin Brown" wrote:
On 03/04/2012 01:33, joeu2004 wrote:
There is a difference(!) when calling InitTestDLL from
XL2003 VBA v. XL2010 VBA. And I misinterpreted the results
from XL2003 VBA.
[....]
This is also the behaviour in XL2007 so it looks like
XL2010 is the point where MS went back to using full
64 bit mantissas (80 bit reals).

I don't believe so.

Normally, XL2003 VBA does compute using _PC_64, just as XL2007 and
XL2010 VBA do.

However, I did not uncover a defect in XL2003 VBA that is reproducible
nearly 100% of the time.

Inexplicably, after we import a module into XL2003 VBA (SP3), the FPU
control word is set to _PC_53. And apparently it remains in that state
until we change it by calling _controlfp ourselves.

That does not happen in XL2007 and XL2010.

That is odd though. For me here on XL2007 it does.

I am using XL2007 SP3 here and I see exactly consistent behaviour with
control word set to _PC_53 on entry just like with XL2003. It gets the
"right" answer the first time through but fails on subsequent goes when
the control word has been reset to _PC_64. I think by his application.

One way to tell would be to set _PC_24 and see if you get handed back
the FPU in that parlous state the second time around.

I say "nearly 100% of the time" because I believe there were a couple
times out of 20 or 30 when that did not happen; that is, when the
precision mode continued to be _PC_64.

Be that as it may, that has nothing to do with Lynn's problems.

You seem to be doing a great job of disassembling his DLL and ferreting
out the root cause.

So I will leave you to it.

I am curious now as to what is actually going on.

The alleged "fault" should have no bearing on the DLLs computational
accuracy since _PC_64 maintains additional guard digits beyond what
normal _PC_53 REAL*8 computations can manage. The final results may
differ slightly but a 64 bit mantissa should give better results!

--
Regards,
Martin Brown