Date: Tue, 25 May 1999 09:26:11 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: More x87 weirdness
To: djgpp-workers AT delorie DOT com
Message-id: <374AB303.4980D9C8@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.05 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990525110951 DOT 24405X-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> 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.

From the Windows desktop, I double click on "MS-DOS Prompt".  That loads a
copy of the DOS shell, no?

> 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.

This reminds me of a very elusive bug that I found several years ago in a
Turbo C program.  The symptom was that the coprocessor stack gradually
filled up with extra numbers during the course of the computations,
eventually becoming full and causing the program to abort.  I was almost
convinced that I had found a hardware bug, since the instruction stream
had nothing in it with unbalanced coprocessor stack pushes and pops.

The problem turned out to be caused by improper exception handling by the
Turbo C runtime library.  When a denormal was encountered, the compiler
did not mask the denormal exception, but the exception handler simply
returned to the next instruction without doing anything.  This turns out
to be subtly different than masking the exception.  Careful reading of the
Intel coprocessor manual showed that when an unmasked exception is
encountered, the instruction is aborted at that point.  Since the
instruction in question was FCOMP, which was supposed to pop the stack
after the comparison, the stack pop didn't happen, and there was an extra
number left on the stack.  Since denormals occurred only occasionally in
the course of the computations, this resulted in the program running for
hundreds of iterations before the coprocessor stack finally filled up.

The fact that the program also had this problem when running with a Cyrix
coprocessor was instrumental in diagnosing the problem.

> 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).

The latest manuals are available online from Intel:

   http://developer.intel.com/design/PentiumIII/manuals/

-Eric Rudd
rudd AT cyberoptics DOT com