www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/05/25/04:41:32

Date: Tue, 25 May 1999 11:10:12 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Eric Rudd <rudd AT cyberoptics DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: More x87 weirdness
In-Reply-To: <3749CB1A.9A12D076@cyberoptics.com>
Message-ID: <Pine.SUN.3.91.990525110951.24405X-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 24 May 1999, Eric Rudd wrote:

> 1. While shelled out to DOS from Win95 v950B on a 266-MHz P II, I
> found that the SIGFPE messages generally stopped within 400 ticks or
> so, frequently within 100 ticks.

What do you mean by ``shelled out to DOS''?  I ran the test program in
a windowed DOS box and never saw SIGFPEs stop.  FWIW, my Windows
version is 4.00.950-r7.

> 2. On my home computer, which is a completely Windows-free 200-MHz
> Pentium MMX, typically the program would run for a couple of
> thousand ticks before the SIGFPE messages would stop.

That is also my observation on DOS.  Sometimes I can make it happen
earlier by pressing Ctrl-C continuously for several seconds, but
sometimes Ctrl-C doesn't help (or maybe I lose patience ;-).

> Since there is a much greater interrupt latency under Windows,
> perhaps something funny is happening when a tick occurs during an
> interrupt, and there is some pending floating-point exception.

That was my general impression, too.  It seems to be confirmed by the
fact that adding _clear87() to each signal handler makes the problem
go away.  However, none of my x87 references says anything about what
happens if an exception strikes in the middle of an FP operation and
whether this can get the FPU into some funny state.  Perhaps this is
something specific to Pentium and later CPUs (my references all stop
at i486, and I don't have access to such a machine to test).

Interestingly, if I call _status87() or examine the control word with
_control87() when SIGFPEs stop, I see the same bits as in the normal
case.  So whatever happens to magically mask the FP exceptions doesn't
even show in status and control words!  I'm at a loss what hidden
features could cause such a strange situation.

This all lets me wonder whether we should add a call to _clear87()
into the signal-handling machinery in dpmiexcp.c.  It's probably not a
good idea for SIGFPEs, as the application's handler might want to look
at the FPU status.  But what about other exceptions?  Will it do
something bad to clear the FPU in case of, say, SIGINT?  If Ctrl-C was
pressed in the middle of some FP calculation, could _clear87() do any
harm?

Anyway, thanks for looking at this.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019