Re: Making Lemonade (Floating-point format changes)

Lawrence D'Oliveiro wrote:

On Mon, 13 May 2024 21:16:48 +0000, MitchAlsup1 wrote:
 

Emulation is slow when trap overhead is large and not-slow when trap
overhead is small.

 I think it was a particular version of the old Mac OS, from around 1990 or
so, that implemented a really amazing hack. Some 32-bit machines had
hardware floating-point, others didn’t. So developers of numerics-
intensive apps had to build two versions of their code, one with the
floating-point instructions, the other with calls to Apple’s SANE library.
 The hack involved running code built to use hardware floating-point
instructions, on hardware that didn’t have them. The instructions were of
course trapped and emulated. But more than that, the system would patch
the instruction that caused the trap, turning it into a direct call into
the emulation routine. So after the first execution, each such instruction
would run much faster. Until the code got unloaded from RAM and the patch
was lost, of course.

This only works when each FP instruction is at least as long as a function call. This particular approach was standard on PCs more or less from the very beginning (i.e. 1981++):
You could build applicatons with direct 8087 instructions, with pure sw emulation via CALL FDIV_emulation etc, or in a mode where each emitted hw fp instruction was followed by enough NOPs to make the total length at least 5 bytes: This way the missing HW trap handler could patch them into CALLs (possibly followed by one or more NOPS if the HW opcode was very long) instead.
Since all those 8087 instructions were _very_ slow (30-300 clock cycles?), executiong an extra NOP or two made no discernible difference.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"