DEBUG and the 8087 FPU

[Chuck(G)]

No--I don't believe that the 8087 makes use of the mechanism. What I remember from the 80287 was that the memory access scheme used by the 8086 wasn't suitable for the protected-mode 80286 (think about the segmented memory model). The 80287 datasheet also says this:

I/O ports 00F8H to OOFFH are reserved for the 80286/80287 interface. To guarantee correct operation of the 80287, programs must not perform any I/O operations to these ports.

The way I understand it, the 80286/80386 does all of the fetching and storing, rather than having the 80287 handle the bus (as it does with the 8087); data is passed via I/O and the 287 keeps track of the number of bytes transferred.

 

[george]

It was obvious that all communication with the 80287 / 80387 went through these I/O ports. But the protocol was never public. I was trying to built an ISA card back then to plug the cheaper and more available 80287 into 386 machines via the ISA bus or via the 387DX PGA socket (the 387SX socket was mechanically not very convenient) and back then I was highly interested in this obscured information. Still it is a mystery...

 

[Chuck(G)]

Well, the 80387 data sheet has quite a bit on the interface (section 4) that the 80287 data sheet doesn't. Perhaps that's a starting point.

 

[george]

Well, the 80387 data sheet has quite a bit on the interface (section 4) that the 80287 data sheet doesn't. Perhaps that's a starting point.

The starting point is no longer important due to obvious reasons.
By the way 80287 and above don't need WAIT instruction synchronization like 8087 does.

 

[Chuck(G)]

The starting point is no longer important due to obvious reasons.
By the way 80287 and above don't need WAIT instruction synchronization like 8087 does.

I'm probably very dense this morning, but for what obvious reason is the starting point no longer important? If you want to know the content of what's happening with the protocol, grab a system and a logic analyzer and look. It's not really important, as you can't do anything about the conversation from a programming standpoint. That is, you can do the port I/O to 0Fx, but you can't control the status lines that are part of the protocol. If you're out to design your own NPX, I suspect that may be important.

The business about the 80287+ WAIT is called out in the datasheet, but the 80286/80287 programmer's guide does call out some ordering issues where an exception thrown can potentially foul recovery up.

 

[Trixter]

The starting point is no longer important due to obvious reasons.
By the way 80287 and above don't need WAIT instruction synchronization like 8087 does.

It sure looks like that's still necessary, unless I'm misunderstanding you: "In all cases, a WAIT or ESC instruction should be inserted after any 80287 store to memory (except FSTSW and FSTCW) or load from memory (except FLDENV or FRSTOR) before the 80286 reads or changes the value."

 

[Chuck(G)]

That's exactly what the programmer's reference says--and even furnishes examples where this might go wrong.

 

[george]

That's exactly what the programmer's reference says--and even furnishes examples where this might go wrong.

The obvious reason is that the problem is over 30 yrs old (me too) so it is no longer of practical use ). I am still curious but I am now not going to reverse the stupid vintage secrets of Intel . Anyway several alternative coprocessor vendors obviously had done this back in time.

Here is what one manual says literally about the WAIT instruction:

The dedicated signals provide
instruction synchronization, and eliminate the need of
using the Am386DXlDXL CPU WAIT op-code (9Bh) for
387DX math coprocessor instruction synchronization
(the WAIT op-code was required when 8086 or 8088
was used with the 8087 coprocessor).

 

[Chuck(G)]

I think Jim's quoting from the Intel programmer's manual verbatim. (It's on bitsavers). What book are you citing?

 

[Trixter]

He's quoting the 80386 datasheet. I was quoting the 80287 datasheet. While both are Intel, the 80287 datasheet is what one should refer to when examining the 80287 coprocessor.

 

[george]

He's quoting the 80386 datasheet. I was quoting the 80287 datasheet. While both are Intel, the 80287 datasheet is what one should refer to when examining the 80287 coprocessor.

80287 & 80387 share the same signals and method of access so WAIT should not be needed with both.

 

[Chuck(G)]

The issue is overlapped NPX and CPU instruction ordering without the WAIT. When an exception is thrown, if the ordering isn't correct or the WAIT instruction isn't used, the wrong location of the instruction is returned. There are practical ramifications.

Again, this is cited in the programmer's manual.

 

[george]

The issue is overlapped NPX and CPU instruction ordering without the WAIT. When an exception is thrown, if the ordering isn't correct or the WAIT instruction isn't used, the wrong location of the instruction is returned. There are practical ramifications.

Again, this is cited in the programmer's manual.

Which exception exactly? If you were right then an exception would point to the WAIT instruction and still not to the faulty instruction.

This is an exact quote of Intel's manual which differs a bit from the AMD manual I quoted before.

In 8086/8087 systems, WAIT instructions may
be required to achieve synchronization of both commands
and operands. In 80286/80287 and
i386/i387 processor systems, WAIT instructions are
required only for operand synchronization; namely,
after NPX stores to memory (except FSTSW and
FSTCW) or loads from memory. Used this way,
WAIT ensures that the value has already been written
or read by the NPX before the CPU reads or
changes the value.

 

[Chuck(G)]

PDF Page 122 et seq. "Concurrent Processing"

 

[george]

PDF Page 122 et seq. "Concurrent Processing"

OK, you meant numeric exception. This is absolutely not the case with the problem with data inconsistency described in this thread. The almost identical exceptions occur in 8087. On the same page you are referring to there is a paragraph dedicated to the ЕМUL387. The similar emulators were advertised by Intel for 87 & 287. Have you ever seen some of these software/libraries or whatever modules they were?

 

[Chuck(G)]

I've seen the ones for 8087; even wrote one myself back in the day (Jim knows about that).

 

[george]

I've seen the ones for 8087; even wrote one myself back in the day (Jim knows about that).

I meant the original Intel complete and accurate npu emulators. Are they available nowadays from public sources?

 

[Chuck(G)]

You mean the old ISIS/iRMX Intel support library; E8087.LIB etc.? I'm sure someone must have held onto a copy, but I wouldn't know who has one now.

 

[george]

You mean the old ISIS/iRMX Intel support library; E8087.LIB etc.? I'm sure someone must have held onto a copy, but I wouldn't know who has one now.

I only read short notes about these in Intel datasheets therefore I am not sure what type of files are they or which packages they may be included in. For example here is what the manual you provided link to (The 387 Programmers Reference Manual) says:

An emulator package (EMUL387) that runs on 80386 systems is available from Intel. This
emulation package operates in both real and protected mode as well as in virtual 8086 mode,
providing a complete functional equivalent for the 80387 emulated in software.

The EMUL387 software emulator for 80386 systems is available from Intel as a separate
program product.

 

[Chuck(G)]

The E8087 package was available on floppy disk; I don't know how the 387 package was distributed.