Re: Compiler Libraries and/or built-in routines

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, henry@zoo.toronto.edu utzoo!henry
--

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