3

I'm interested in retrocomputing and emulation of old computers and have a question about the 80287:

Using a modern FPU the FNSAVE instruction writes 94 bytes of data when the CPU executes 16-bit code and 108 bytes of data when the CPU executes 32-bit code. The FSTENV instruction behaves similar (14 or 28 bytes depending on the code type).

However the 80287 FPU which has been designed for the 16-bit 80286 CPU can also be used together with the 32-bit 80386 CPU.

How would FNSAVE and FSTENV behave when called from 32-bit code with paging enabled with the 386/287 combination?

The 80287 manual explicitly mentions the 80386 but it only describes the 94 byte data format. However another manual states that it is the 80386 and not the 80387 which is responsible for saving the 108 bytes instead of 94 bytes.

And what is the reason that Linux allegedly crashed when using the 80287?

Is the 94 byte format related to the Linux problem?

Thanks

Martin Rosenau
  • 17,897
  • 3
  • 19
  • 38
  • 1
    The Intel287xl manual shows two figures of the two 28-byte forms used by the 386 in 32-bit mode: When the 287xl is used with a 386 in 32-bit mode, the 28-byte form is used. The manual also states that the 80C287 behaves exactly like the 287xl. The 80287 without the "C" is not hardware compatible to the 80C287 - so it is still not clear if the 80287 (without the "C") uses the 28-byte form. – Martin Rosenau Apr 23 '19 at 19:53

1 Answers1

2

However the 80287 FPU which has been designed for the 16-bit 80286 CPU can also be used together with the 32-bit 80386 CPU.

How would FNSAVE and FSTENV behave when called from 32-bit code with paging enabled with the 386/287 combination?

Exactly as with 16 bit code, as the 287 does not kw anything about 32 or more bit modes nor addressing at all. While the 8087 was a co-processor executing the instruction stream in parallel to the 8086, the 287 and later have been turned into I/O devices handled over a series of I/O ports (see here for details)

This is especially relevant as transfer of data uses a special to type DMA protocol using dedicated handshake lines (BUSY/PEREQ/Addressing) for communication.

The 80287 manual explicitly mentions the 80386 but it only describes the 94 byte data format.

As that's what the 287 delivers until BUSY is revoked. The 287 does not know which host CPU it's working for. It's a complete external FPU, attached via I/O ports, much like back in the days of it's grand-grand-grand-father the AM9511. So it will always deliver 94 bytes, no matter what addressing or memory management state the 80386 is in.

However another manual states that it is the 80386 and not the 80387 which is responsible for saving the 108 bytes instead of 94 bytes.

Mind to add the manual you're referring to?

Hans Franke
  • 71
  • 5
  • 1
    According to the preliminary 80387 data sheet that was attached to the [80386 Programmers Reference](https://ia601404.us.archive.org/23/items/bitsavers_intel80386ammersReferenceManual1987_14896856/231917-001_80387_Programmers_Reference_Manual_1987.pdf), the four registers which are responsible for the different size (14 vs. 28 bytes) are not located in the 80387 but in the 80386 (for example on page 2-7). And therefore the 80386 (and not the 80387) is writing these values to memory. I would have expected that the 80386 receives 94 bytes from the 80287 and writes 108 bytes to memory. – Martin Rosenau Feb 12 '23 at 20:49
  • 1
    On the other hand, I wonder what FSETPM/FRSTPM did? – Yuhong Bao Feb 13 '23 at 02:36
  • @YuhongBao The x87 FPU needs to know whether it is operating in Real Mode or Protected Mode because the floating-point environment accessed by the F(N)SAVE, FRSTOR, FLDENV and F(N)STENV instructions has different formats in Real Mode and Protected Mode. It also alters the exception handling depending on the mode. On an 80386 `fnsetpm` is a NOP since the processor automagically tells the FPU if it is in protected mode or not. Wouldn't surprise me that an 80287 on an 80386 in protected mode actually wrote just 94 bytes – Michael Petch Feb 13 '23 at 02:57
  • I think the aim for an 80287 on an 80386 was for compatibility with 80286 software and OSes. So the idea of protected mode on a 386 with an 80287 was compatibility with 16-bit protected mode, not 32-bit protected mode. I may be wrong. – Michael Petch Feb 13 '23 at 03:40
  • The original reason was I believe that the 80387 was not going to be available in time. – Yuhong Bao Feb 13 '23 at 06:40