🚀 go-pugleaf

bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:

>The following short program compiled with MS-FORTRAN 5.0 with 
>coprocessor crashes OS2 Ver. 2 on my machine:

[division by zero example deleted]

I think you have encountered a problem described in the PC-Clone
UNIX Hardware Buyer's Guide (see news.groups for it).

Here's the relevant part:

Archive-name: pc-unix/hardware
Last-update: Wed Aug 12 13:15:22 1992
Version: 6.0

[...]

Finally, beware the infamous FP exception bug!  Some motherboards fail to
handle floating point exceptions correctly; instead of generating a SIGFPE they
lock up. The following fragment of C code will reproduce the problem:

	double d;

	d = 0.0;
	d = 1.0 / d;	/* floating divide by zero should yield SIGFPE */

John R. Levine <johnl@iecc.cambridge.ma.us> explains: "The difficulty stems
from the fact that there are two ways to handle floating exceptions on a 486,
the right way and the PC way.  What the 486 wants to do is to generate an
interupt 16 when there is a floating point error, all entirely internal to the
CPU.  This has been the native way to handle floating point interrupts since
the 286/287.  The 286/287 and 386/387 each have a dedicated ERROR pin that the
FPU uses to tell the CPU that it's time for an error interrupt.

Unfortunately, the 8086/8087 handled interrupts differently.  The error pin on
the 8087 was wired to the 8259A interrupt controller, the same interrupt
controller that handled keyboard, disk, clock, etc.  interrupts.  The PC/AT
enshrined IRQ 13 as the one for floating interrupts.  (The details of this are
a little hazy to me, since the XT didn't have IRQ 13 tied to an 8259A, so the
AT must have at least changed the interrupt number.)  PC designs have generally
wired the 287 or 387 ERROR pin to the 8259A, not to the ERROR pin on the CPU,
or at best had some poorly documented way to switch between the two interrupt
methods.
 
In the interest of backward compatibility, the 486 has a mode bit that says not
to handle FP exceptions automatically, but rather to freeze the FPU and send a
signal on the FERR pin, which is usually tied to an 8259A which then feeds the
interrupt back as IRQ 13.  There is some extra complication involved here
because the FPU has to stay frozen until the interrupt is accepted so the CPU
can go back and look at the FPU's state.  Early 386/25 chips had a bug that
would sometimes freeze up on a floating point interrupt and you had to get a
kludge socket with a PAL that fixed the timing glitch that provoked the bug.

So as likely as not, the motherboard hardware that runs FERR out and back isn't
working correctly.  It's not surprising, few DOS users take floating point
seriously enough to notice whether the interrupts are working right."

When you specify a system, make clear to your vendor that the motherboard must
handle float exceptions properly.  Test your motherboard's handling of
divide-by-zero; if it doesn't work, press your vendor to replace it *and
send me email*!  Only by publishing a list of boards known bad can we
protect ourselves and pressure vendors to fix this problem.

[...]
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.