🚀 go-pugleaf

Dick Dunn writes:
>It might be obscure, but that's not a convincing argument.  How extensive
>are the test suites for the 387? <<enter tired-aphorism mode>>  Testing can
>only reveal the presence of bugs, not their absence.  <<exit tedium>>
>
>A better measure of the problem is what it takes to avoid triggering it.
>What's the cost in software to dodge the problem?  Actually, the 486 is
>early enough in its lifetime that hopefully the bug can be banished by
>replacing chips instead of hacking around it.

Hacking around it isn't an option, since the 486 is intended to be used
to run all those billions of bytes of 386/387 software.  The bugs wouldn't
be hard to work around if changing the compiler was an option, but it
isn't.

There are two separate problems:

1. If the FTAN or FSINCOS instructions are executed, in particular rounding
modes, and the result causes a carry out from the mantissa (which occurs if
the result is an integer power of two), AND another FP instruction occurs
within a certain number of clock cycles, AND that instruction is one of a
certain group, then the floating-point stack gets corrupted.

2. If an unmasked FP exception occurs, and then a WAIT or FWAIT instruction
is encountered that is followed by one of a certain group of instructions,
then the error is not properly handled.

The first problem will obviously never occur if the FTAN and FSINCOS
instructions are used, and even if they are, the data patterns that
are required are statistically unlikely -- though of course, it would be
easy to contrive a program that would generate the error repeatedly.

The second problem apparently isn't an issue for most DOS applications,
because they don't unmask FP exceptions.  I don't know if Unix apps do.

Michael Slater, Microprocessor Report    mslater@cup.portal.com
415/494-2677   fax: 415/494-3718
550 California Ave., Suite 320, Palo Alto, CA 94306