It will only work if the code is designed to work with an emulator installed into some standardized ints.
What a compiler for 8086/8088 does for x87 code is this:
1. Emit the proper int NN call for a certain range of FPU instructions.
2. Emit the actual x87 opcode.
The emulator can either be compiled into the binary itself, and install itself at program startup, based on the detection of an FPU, or it can be pre-loaded as a TSR.
The emulator installs handlers for the ints, and these will do one of the following:
- If there is a physical FPU, the int NN call is overwritten with nops, then the handler returns, and the instruction will be executed by the FPU. Since the int is nopped out, the emulator routine will not be called again for that instruction the next time.
- If there is no physical FPU, the emulator interprets the instruction following the int NN call, and after execution, it will return to the next instruction after the FPU instruction that was just interpreted.
On a 286 and higher, the int calls are not required, because the CPU will generate an interrupt by itself when an FPU instruction is encountered without a physical FPU present.
That's why you can emulate an FPU for all software on 286+, but only for specially compiled software on 8086/8088.
Try disassembling some Turbo Pascal code with FPU operations for example, you'll see the distinct pattern of CD NN prefixes (note that Turbo Debugger is actually aware of the emulation, and it does not show these int instructions as separate instructions in the disassembly).
I test it with AMD 287 demo software
http://cd.textfiles.com/pcmedic/util...are/amd287.zip in PCem emulator (machine type: XT). It works.
That is not a good test.
OpenWatcom-generated files do not hang on PCem either with the fwait-problem, but they do on real hardware.
Compilers are horribly inaccurate when it comes to early PCs.