11

The 8087 and 287 FPUs were designed before the IEEE 754 standard was released. Because of this, they contain some instructions which are not compliant with it. When the 387 was released in 1987, it addressed these problems by adding some new instructions (notably, FPREM1) and also by changing a lot of rules and quirks about rounding, infinities and denormal numbers (the main differences are listed in the 80387 Programmer's Reference Manual, Appendix C and D).

While some 387 programs may lose precision by being run on a 287, and some may even miss some important overflow/underflow/denormal exceptions, a 387 program is guaranteed to not work correctly if it tries a new instruction like FSIN or FUCOM.

Since the 387 was released 2 years after the 386, the first 386 systems were built with a 287 socket. Is it possible for such a system to emulate the new 387 instructions (without swapping the 287 with a 287XL)? By that, I mean to trap only the 387 opcodes, not every FPU opcode (which is trivial by setting CR0.EM).

Current x86 CPUs seem to trap invalid FPU opcodes (in the D8DF range). However, the 80386 CPU has no idea which FPU opcodes are valid and which aren't, because the FPU is external.

18
  • 2
    @ecm Wouldn't that create a performance penalty almost as bad as software emulation? The point is to utilize the 287 at its best, otherwise software emulation would be a much better and more robust solution, as it would create a true 387 environment.
    – DarkAtom
    May 31 at 22:08
  • 3
    So to begin. what does a 287 generally do when it encounters an unknown opcode? I skimmed the 287 manual and didn't see this addressed. If it doesn't trap in some fashion, then it seems that this effort is dead in the water. Jun 1 at 5:02
  • 1
    @ecm In Protected Mode, those context switches can be pretty expensive. In a standard DOS environment you're probably right and it shouldn't be that big of a problem.
    – DarkAtom
    Jun 1 at 10:24
  • 1
    @NateEldredge I see...I was hoping someone here would know more about this matter, because I also didn't find anything in the manual. I guess ecm's idea is probably the best, if there is no way to trap unknown x87 opcodes.
    – DarkAtom
    Jun 1 at 10:35
  • 2
    Update: It seems that the CPU might actually know about invalid FPU opcodes. In this article about 80386 errata, it is mentioned that one of the bugs for the A1 stepping is: "Bad Floating-Point Instructions: The execution of certain undefined floating-point instructions causes the 80386 to hang rather than reporting an invalid instruction fault.". I guess this means that the 80386 is supposed to be able detect undefined x87 opcodes.
    – DarkAtom
    Jun 5 at 8:18

0

You must log in to answer this question.

Browse other questions tagged .