On 02/04/2012 19:44, joeu2004 wrote:
PS.... I wrote:
"Martin Brown" wrote:
And her compiler returns bare metal X87 status words
0x127F works
But on subsequent calls the FPRESET state 0x137F prevails
since that is what C has forced it to!

That is an interesting theory. You might be correct.

I can't quite prove it. The DLL is too large and confusing and I cannot
locate the actual test example inside it. It isn't quite consistent
since on checking the FPRESET state should be 0x037F according to the
datasheet so something has tweaked infinity handling elsewhere.

I need a version stripped to the absolute minimum bare bones and
preferably as an MSC project DLL to trace into the executable code and
or with an assembler listing of the generated code.

I can't figure out the differences between TESTDLL1.DLL and TESTDLL.DLL
the VBA only seems to reference the first, but both are locked when XL
is running the test.

I assumed that _control87 returns the abstract values for
_PC_64, _RC_NEAR et al documented in
http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx.

I also read (misread?) that webpage to say that _control87
and _controlfp used the same parameters and returned the
same results.

And I believe my interpretation (no misreading) is reinforced by this
example in that webpage:

_control87( _EM_INVALID, _MCW_EM );
// DENORMAL is unmasked by this call
_controlfp( _EM_INVALID, _MCW_EM );
// DENORMAL exception mask remains unchanged

Note that the documented value for _EM_INVALID, 0x10, is not consistent
with the position of that bit in the FPU control word, namely 0x01.

I suspect that this is down to a difference between the implementation
on the Watcom C compiler and in the MS Visual Studio. Same symbolic
names are being used but with very different constant values!

--
Regards,
Martin Brown