Re: Compiler Libraries and/or built-in routines

larry@tsd.arlut.utexas.edu (Larry Maturo) writes:
>I probably have a 6 or 8 compiler books and none of them address the
>issues of libraries to any great degree...
>... Is there a particular reference book compiler writers
>use for this? Are there any standards?


Apart from some books about how to build good floating-point math
functions, there's precious little. Plauger's book ("The Standard C
Library", I think the title is -- my copy's not handy) is quite new, very
good, and pretty much alone in the field.


>When I call the Sin routine in one compiler how close will the answer be
>to that of calling the Sin routine with the same argument in another
>compiler.


This depends a whole lot on how careful the implementors have been. Good
math routines are not that easy to do.


>How does one fake floating point when the target processor has
>no floating point unit? ...


Well, the compiler side of it is pretty straightforward:


1. You can generate the FP instructions anyway and set up a trap handler
to interpret them, which works well if your processor cooperates and the
traps are efficient. 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... :-)
Unfortunately, traps are often pretty costly, and sometimes aren't
available at all.


2. You can generate subroutine calls and then link with a suitable
library. There could be more than one library if some degree of hardware
support is sometimes available. You can even have a hardware-FP version
of the library, although performance won't be as good as generating the
real instructions, due to subroutine overhead and lost optimizations.


3. You can generate code (possibly via subroutine calls) that figures out
at runtime whether FP hardware is present, and copes accordingly. This at
least shares with #1 the advantage of working on all versions of the
hardware, although it too is kinda slow.


It might be instructive to note that Sun used a complex mixed stragegy
involving #2 and #3 on their 68k machines, and when they had a chance to
do a clean-slate implementation on the SPARC, they unhesitatingly decided
to require that the operating system fake it.


If you're wondering how to implement the floating-point ops in software,
that can be quite a chore if you're trying to do an accurate imitation of
well-designed FP hardware. I don't know of good references offhand.


>... Is faking it a black art
>that's not widely known or is it difficult to allow for both software and
>hardware floating point at the same time?


Yes. :-) Life is much simpler if you can assume a uniform interface, i.e.
it always looks like hardware is present. And efficient software FP is a
lot of work and rather arcane.


I rather suspect that one reason for limited publication on the subject is
that cheap hardware FP is becoming increasingly universal.
--
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu utzoo!henry
[A fairly common approach on micros is to generate subroutine calls, and
if FP hardware is present for the library to patch FP instructions on top
of the call each time one of the emulation routines is called. The HP1000
could do that at link time. -John]




--

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