Re: Making Lemonade (Floating-point format changes)

On 2024-06-10 9:07, Terje Mathisen wrote:

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++):

I believe that the same approach (trap and patch) was used in the HP 2100 computers that I used in the early 1980's, which were designed in the 1960's. I don't think any NOPs were needed to match instruction lengths for these machines.
You can also do it the other way around: always compile a function call, but on a machine that has an FPU use a dummy emulation library that back-patches the call to become an FPU instruction, so that each emulation function is called at most once.
To be honest, I'm not sure which way around the HP 2100 used.