There are various types of x87 emulators.
Back in the early days, there was a standard for this, used by various compilers. They would pre-pend x87 instructions with a software interrupt. The TSR would be installed in that interrupt, and emulate the instruction directly after the interrupt when no x87 was installed, or just return and let a real x87 handle it.
In some cases, these emulators were compiled directly into the binary (as you can see with Turbo Pascal/Turbo C++ code for example), so no TSR was required.

Obviously this requires that the application is compiled with support for the x87 emulator.
On newer CPUs it became possible to virtualize instructions directly, so a different type of x87 emulator became possible, and no specific code was required in the application.

So yes, x87 emulators are a thing, and they definitely do work (they do not go for tables and approximations however, they are specifically designed to emulate the x87 as closely as possible. Tables and approximations are better coded directly into the application).

I doubt they would work with a game like Quake though, since it uses a DOS extender, and basically completely takes over the machine and creates its own virtualized environment. The x87 emulator would likely no longer function.

I second that, Scali explained that very well IMHO.

This perhaps is slightly off-topic, but on Windows 2.x and 3.x, there's also a runtime named WIN87EM which both virtualizes and
emulates a simple x87 math coprocessor. Even if a real x87 is installed, virtualization might be necessary in order to allow multiple
Windows programs to access the math coprocessor at the same time. That runtime also saves and restores the state of the real FPU
from time-to-time, to make sure the different programs don't get into each others way.

Jo22 wrote:

This perhaps is slightly off-topic, but on Windows 2.x and 3.x, there's also a runtime named WIN87EM which both virtualizes and […]
Show full quote

This perhaps is slightly off-topic, but on Windows 2.x and 3.x, there's also a runtime named WIN87EM which both virtualizes and
emulates a simple x87 math coprocessor. Even if a real x87 is installed, virtualization might be necessary in order to allow multiple
Windows programs to access the math coprocessor at the same time. That runtime also saves and restores the state of the real FPU
from time-to-time, to make sure the different programs don't get into each others way.

Yes, the FPU has its own registers. The state of the registers are known as the 'context'. And in multitasking/multithreading, switching from one task to the next is known as a context switch.
So indeed, a multitasking environment needs to also switch the FPU context if you want to share the FPU between tasks.
For this exact reason, Intel decided to implement the MMX extension by re-using the FPU context instead of adding new registers. The advantage is that any multitasking environment with support for x87 would automatically work with MMX without any changes.
AMD's 3DNow! again was an extension of MMX, re-using the same registers, for the same reason.

When Intel later introduced SSE, they did add new registers, but now you needed an OS update in order to make use of SSE (or well, in practice you could run one SSE task, because its state would not get corrupted by any other tasks, but as soon as you'd run a second SSE task, the results would be undefined).

Thanks for the explanation, Scali! 😀
I remember some of this, but did forget the details and technical terms. 😅

They usually work with apps. Like Autocad,... MIght even work with Falcon 3.0. Don't remember anymore.

Try Q387:
https://www.pcorner.com/list/UTILITY/Q387_32B.ZIP/INFO/

Thank you guys for the answers!

I'll definitiely try those through second time. This time i'll try to get my hands on falcon 3.0 and maybe some autocad software to check it out.

Any other suggestions to try out to see the performance of emulated 387?

Hm. Some benchmark programs display x87 performance graphically as a bar (CheckIt!, NSSI etc).
Also visually interesting are fractal programs (Mandelbrot), though they also use integer math sometimes.

And some old CAM/CAM programs (I've recorded some clips of AutoSketch) or old PCB layout software (eagle, etc.).
Autodesk 3D Studio (DOS) also was popular. If memory serves, it supported some extensions of the ITT or Cyrix 387 FPUs.

In QuickBasic, there's the torus.bas sample program which is said to make use of x87 if available (if run via QB IDE).
As part of the Weitek diskette, there's a little beach ball like benchmark - one for Weitek and one for 387.

In Windows 3.1, the MOD4WIN player can use x87 for the IDO filter. Though I don't know if this increases performance or audio fidelity.
Speaking of Windows, I don't know if DOS TSRs for x87 emulation still work. If so, GDI itself may also benefit from x87 if available.

Hm. Maybe in Real-Mde of Win 2.x or 3.0 they still do..
If you want to give it a try, you can try this Mandelbrot program for Win 2.0+