Date: Sun, 15 Nov 1998 13:33:28 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Nate Eldredge <nate AT cartsys DOT com>
cc: djgpp AT delorie DOT com, Cesar Scarpini Rabak <csrabak AT ipt DOT br>
Subject: Re: DJGPP tools and utilities SIGFPE'ng after Floating Exception
In-Reply-To: <364CE415.DB9AAFD0@cartsys.com>
Message-ID: <Pine.SUN.3.91.981115133308.1381j-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com


On Fri, 13 Nov 1998, Nate Eldredge wrote:

> Now, it seems to me I've asked this before, but I've forgotten the
> answer.  Why don't we reset the FPU at startup, shutdown, or in the
> default SIGFPR handler?

I don't remember any discussion, but my memory leaves a lot to be
desired ;-).

Anyway, this is not as simple as it might sound.  For starters,
there's no ``default SIGFPE handler''; SIGFPE is by default handled by
the same function as other signals are.  Of course, it could be
modified to reset and clear the FPU if SIGFPE strikes.

More importantly, even if this does the trick, a non-DJGPP program
that leaves the FPU in a mess, or a DJGPP program that installs a
custom SIGFPE handler and doesn't clear it, will still be a problem.

As to the startup code, I'd guess the exception happens inside the
code which tries to detect whether an FPU is available.  If that's
true, I'm not sure what will _clear87 and _fpreset do if called before
an FPU is detected.

In sum, this calls for some non-trivial effort to get right.
Volunteers are welcome, as usual...