Re: Compiler Libraries and/or built-in routines (Henry Spencer)
Fri, 9 Oct 1992 17:08:40 GMT

          From comp.compilers

Related articles
Re: Compiler Libraries and/or built-in routines (1992-10-06)
Re: Compiler Libraries and/or built-in routines (1992-10-07)
Re: Compiler Libraries and/or built-in routines (1992-10-07)
Re: Compiler Libraries and/or built-in routines (1992-10-09)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Henry Spencer)
Organization: U of Toronto Zoology
Date: Fri, 9 Oct 1992 17:08:40 GMT
Keywords: library
References: 92-10-022 92-10-033

I wrote:
>1. You can generate the FP instructions anyway and set up a trap handler
>to interpret them... Actually, the *right* way to handle the issue is for
>the operating system to do this for you, so it *always* looks to you like
>the hardware does FP, except that sometimes it's kinda slow... :-)

Credit where credit is due dept...

To the best of my knowledge, the first person to think of this approach
was Mike Tilson at HCR (now SCO Canada). The original pdp11 Unix method
was to compile the trap handler into each program. This was clumsy and
meant having two different flavors of binary. Mike worked out some simple
modifications to the trap handler that permitted stuffing it into the
kernel instead.

(Note, I'm not claiming Mike thought of the general concept of emulating
unimplemented instructions. That's been around for a long time, and of
course that was what the original trap handler did. The specific issue at
hand is providing floating-point emulation as a system service, available
to all programs without special preparation.)

Worked pretty well, too. Actually, programs *could* tell whether they
were getting real FP or the emulator, even without running timings, but
that was simply because the emulator didn't try all that hard to match the
hardware exactly. Cleanly-written programs that didn't care about the
last decimal place just ran, either way. When we finally got hardware FP
on our 11, not a single thing in the system software needed changing.

(A surprising number of *user* programs broke... but when we investigated,
it always turned out that they were broken already. Notably, the emulator
didn't trap division by zero, and the hardware did...)
Henry Spencer @ U of Toronto Zoology, utzoo!henry

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.