Math Coprocessors

[Doug Gwyn]

In article <1990Nov12.032526.17125 at mccc.uucp> pjh at mccc.uucp (Pete Holsberg) writes:
>The question came up recently as to whether or not a math coprocessor
>would be a useful addition to a UNIX computer system.  One of us said
>that it would not unless the programs that were being run used floating
>point and/or extended integer arithmetic.  The other said that one will
>find relatively few programs which do not do at least SOME floating
>point or extended integer math, even if it is not explicitly present in
>the program it may be present in a library routine.

If the math coprocessor runs asynchronously, the kernel may require some
subtle hackery to properly context switch.  I ran into this when adapting
Sixth Edition UNIX for use on a PDP-11/34 with FPU.  (Fortunately, for
the most part I was able to borrow the FPU support code from the PDP-11/45
version.)  Even with math coprocessor hardware, you still need for the
compilers to generate floating-point instructions.  Most often they will
simply generate calls to run-time library arithmetic support routines,
which are implemented using the basic integer instruction set.  Then, you
need to be aware that any code that uses FP instructions and is copied to
a system that does not have the FP hardware is going to generate
exceptions; whether or not the kernel attempts to emulate the FP
operations or simple posts a SIGFPE to the process, the results will be
rather miserable.

As to how much FP hardware will help a typical application, the answer is
that it of course depends on the application.  Most "system" software
will be essentially unaffected by the availability of FP hardware.  A few
engineering-style, and some graphics, applications can speed up noticably
using FP hardware.  I would say that unless you have identified a
particular bottleneck application that heavily uses floating point,
you'd be wasting your money to buy an FPP.