Board index » delphi » Floating Point Exceptions caught by Delphi

Floating Point Exceptions caught by Delphi

I have written a DLL using WATCOM C. This DLL often does floating
point operations which result in overflows. The code in the DLL is
designed to deal with these overflows (eg. 1e307 * 1e307 -> infinity).
When I link the DLL with an example program also written in WATCOM C,
it works fine. However, when I call the DLL from a Delphi program,
Delphi's exception handling mechanism catches the exception, resulting
in control being yanked away from my DLL, and thus the computation
does not finish.

Anyone know how to get around this?

I've tried doing a signal(SIGFPE,SIG_IGN) at the beginning of each
entry point to the DLL, but it doesn't have any effect.

I'm at my wits end about this.

Stefan

 

Re:Floating Point Exceptions caught by Delphi


Quote
Stefan Vorkoetter <smvorkoet...@maplesoft.on.ca> wrote:
>I have written a DLL using WATCOM C. This DLL often does floating
>point operations which result in overflows. The code in the DLL is
>designed to deal with these overflows (eg. 1e307 * 1e307 -> infinity).
>When I link the DLL with an example program also written in WATCOM C,
>it works fine. However, when I call the DLL from a Delphi program,
>Delphi's exception handling mechanism catches the exception, resulting
>in control being yanked away from my DLL, and thus the computation
>does not finish.
>Anyone know how to get around this?

Have you tried to modify your DLL code to use exceptions (SEH) also?
That way your DLL would catch the exceptions first, and would not
leave them to the Delphi app.

Of course, this requires some modifications to your code, but it
should work after that.

Regards,

Jani J?rvinen
a.k.a SilverStream Software
Helsinki Finland

Tools, information, tips, reviews & bug lists
for professional Delphi, Win32 and WinHelp developers.

mailto:ja...@dystopia.fi
http://www.dystopia.fi/~janij/

Re:Floating Point Exceptions caught by Delphi


On Sat, 22 Mar 1997 01:02:58 GMT, Stefan Vorkoetter

Quote
<smvorkoet...@maplesoft.on.ca> wrote:
>I have written a DLL using WATCOM C. This DLL often does floating
>point operations which result in overflows. The code in the DLL is
>designed to deal with these overflows (eg. 1e307 * 1e307 -> infinity).
>When I link the DLL with an example program also written in WATCOM C,
>it works fine. However, when I call the DLL from a Delphi program,
>Delphi's exception handling mechanism catches the exception, resulting
>in control being yanked away from my DLL, and thus the computation
>does not finish.

Delphi sets the floating point control word to signaling. You need to
dip into assembly language to set it back to nonsignaling. Take a look
at the FltMath unit at http://www.tempest-sw.com/freeware/ for some
information on how to do that.
--
Ray Lischner             (send email to "lisch" at tempest-sw.com)
Author of Secrets of Delphi 2 (http://www.tempest-sw.com/secrets/)

Re:Floating Point Exceptions caught by Delphi


Quote
Stefan Vorkoetter wrote:

> I have written a DLL using WATCOM C. This DLL often does floating
> point operations which result in overflows. The code in the DLL is
> designed to deal with these overflows (eg. 1e307 * 1e307 -> infinity).
> When I link the DLL with an example program also written in WATCOM C,
> it works fine. However, when I call the DLL from a Delphi program,
> Delphi's exception handling mechanism catches the exception, resulting
> in control being yanked away from my DLL, and thus the computation
> does not finish.

How are you "dealing with these overflows" in your DLL? If you don't
want any floating-point exceptions, maybe you could turn them off
at source by reprogramming the FPU's Control Word. (Don't worry;
this is local to the application :-) ).

The relevant ASM instructions are
FLDCW [memory] (load memory-word into FPU's control word)
FSTCW [memory] (store control-word into memory)

Bit 3 is the overflow bit. I don't recall whether you would need
to set or clear it in order to turn overflows off, but then again,
there are only two possibilities. SO:

procedure NoFPUOverflows; assembler; (* Delphi 2 *)
const
  fpuOverflowBit = 3;
asm
  PUSH EAX  (* Create a temporary stack-variable *)
  FSTCW WORD PTR [ESP]
{
  Do we set Bit3 ...?

Quote
}

  BTS WORD PTR [ESP], fpuOverflowBit
{
  ... or do we clear it ...? Comment one of these lines out...
Quote
}

  BTR WORD PTR [ESP], fpuOverflowBit

  FLDCW WORD PTR [ESP]
  POP EAX  (* Destroy temporary variable *)
end;

Try calling this procedure when your application first loads.

Quote
> I've tried doing a signal(SIGFPE,SIG_IGN) at the beginning of each
> entry point to the DLL, but it doesn't have any effect.

I can't explain this point: I have no idea how this line of C
translates into assembler.

Chris.

Other Threads