I have just noticed that Excel is changing the floating
point round off handling in the math coprocessor for my
C++ and Fortran DLL. Has anyone run into this ? I am
getting ready to try venturing into _Control87 calls
when my DLL is called from Excel.

I have verified this problem in both Excel 2003 and 2010.

Thanks,
Lynn

Lynn McGuire was thinking very hard :
I have just noticed that Excel is changing the floating
point round off handling in the math coprocessor for my
C++ and Fortran DLL. Has anyone run into this ? I am
getting ready to try venturing into _Control87 calls
when my DLL is called from Excel.

I have verified this problem in both Excel 2003 and 2010.

Thanks,
Lynn

Excel has its own method of handling floating point rounding and so
expect it to be different compared to another methodology.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

On 15/03/2012 16:16, Lynn McGuire wrote:
I have just noticed that Excel is changing the floating
point round off handling in the math coprocessor for my
C++ and Fortran DLL. Has anyone run into this ? I am

A long time ago and not specifically with Excel. It isn't safe to assume
inside a DLL that you will be handed the FPU in the state that your
compiler expects to find it. If your computation is sensitive to
rounding then you can get systematic errors introduced.

This sort of thing usually stems from rounding values for display. I
suspect Excel is setting the coprocessor to the state it requires and
that setting is not what Fortran and C++ compilers expect.

getting ready to try venturing into _Control87 calls
when my DLL is called from Excel.

I have verified this problem in both Excel 2003 and 2010.

Thanks,
Lynn

--
Regards,
Martin Brown

"Lynn McGuire" wrote:
I have just noticed that Excel is changing the floating
point round off handling in the math coprocessor for my
C++ and Fortran DLL. Has anyone run into this ?

I do not use C++ or Fortran, but what you describe does not surprise me,
speaking as a computer and software architect.

The floating-point unit is a global resource. I would not expect any
application to save and restore the FPU's previous state before making
application-specific changes.

Instead, I would expect each application to set the FPU state as it requires
before using it.

So the fault is not Excel's.

Instead, I would expect C++ and Fortran to configure the FPU as each
language requires it, especially the floating-point rounding option.

Alternatively, perhaps your application should configure the FPU as you
require it.

On 3/15/2012 11:34 AM, joeu2004 wrote:
"Lynn McGuire" wrote:
I have just noticed that Excel is changing the floating
point round off handling in the math coprocessor for my
C++ and Fortran DLL. Has anyone run into this ?

I do not use C++ or Fortran, but what you describe does not surprise me, speaking as a computer and software architect.

The floating-point unit is a global resource. I would not expect any application to save and restore the FPU's previous state before
making application-specific changes.

Instead, I would expect each application to set the FPU state as it requires before using it.

So the fault is not Excel's.

Instead, I would expect C++ and Fortran to configure the FPU as each language requires it, especially the floating-point rounding
option.

Alternatively, perhaps your application should configure the FPU as you require it.

It looks like that I need to save the current state
of the FPU, reconfigure the FPU and set the FPU back
to the saved state at each entry point in my DLL.

Lynn

"Lynn McGuire" wrote:
It looks like that I need to save the current state
of the FPU, reconfigure the FPU and set the FPU back
to the saved state at each entry point in my DLL.

I would think you only need to configure the FPU the way that you require
it, not save and restore the previous state.

As I said, I would expect each application to set up the FPU as it requires.
It really cannot assume that the FPU is in some "default" state, AFAIK.

(However, it is true that the FPU is in some well-known state at power-on.)

In any case, I would think you only need to program this once, then call the
procedure from each entry point -- at worst.

Alternatively, perhaps you can put the code into a single procedure that is
called when the DLL is loaded. I am not familiar with Windows DLLs. But it
is common practice in other architectures.

On 3/15/2012 7:23 PM, joeu2004 wrote:
"Lynn McGuire" wrote:
It looks like that I need to save the current state
of the FPU, reconfigure the FPU and set the FPU back
to the saved state at each entry point in my DLL.

I would think you only need to configure the FPU the way that you require it, not save and restore the previous state.

As I said, I would expect each application to set up the FPU as it requires. It really cannot assume that the FPU is in some
"default" state, AFAIK.

(However, it is true that the FPU is in some well-known state at power-on.)

In any case, I would think you only need to program this once, then call the procedure from each entry point -- at worst.

Alternatively, perhaps you can put the code into a single procedure that is called when the DLL is loaded. I am not familiar with
Windows DLLs. But it is common practice in other architectures.

The FPU is is the state 0x4000 every time my DLL
is called from Excel. I believe that 0x4000
means round up on the SSE2.

I am using the following code to reset the FPU in
my DLL:

unsigned checkMathCoprocessorStatus ()
{
unsigned old87Status = 0;
unsigned new87ControlWord = 0;
unsigned new87ControlMask = 0;
unsigned new87result = 0;

old87Status = _status87 ();
if (old87Status != 0)
{
char msg [4096];
sprintf (msg, "\nThe Math Coprocessor status is 0x%x, resetting to zero\n\n", old87Status);
writeLineToScreen (msg);
new87result = _control87 (new87ControlWord, new87ControlMask);
}

return old87Status;
}

Lynn