Math Co-procs

[John Temples]

In article <1486 at inews.intel.com> dlau at mipos2.UUCP (Dan Lau) writes:
>The SysV math library code actually checks at run-time whether a 287 or
>387 is available, and it will use the 387 instructions only if a 387 is
>installed (or the 387 emulator is being used).  That was the way the code
>looked when Intel gave it back to AT&T, I don't know if the current
>versions are still the same.

I extracted sin.o from /lib/libm.a, disassembled it, and sure enough,
there was an fsin instruction in there.  (Unfortunately, "dis" barfed
on it -- it doesn't seem to understand the 387-only instructions.)
I checked this on ESIX-D, Microport 2.2, and ISC 2.0.2 -- they all
had it.

>The standard pcc in SysV does not generate
>in-line math operations, so there is no question of compatibility there.
>Almost all third party 386 compilers will generate the 387 instructions
>directly for some of the math functions (like sin/cos, sqrt, etc.).  The
>compilers are supposed to "assume" only a 287

I remember running the "savage" benchmark (transcendental-intensive)
on a 387-equipped machine, compiling with both cc and Green Hills
gcc a couple years ago.  The gcc-compiled binary (with -f387x) was so
much faster than the cc binary that I assumed libm.a was 287-only.
It's surprising that using inline instructions would be so much
faster than calling a procedure using the same instructions.

>Speaking of the emulator, I know AT&T used to (still do?) ship two versions
>of the 387 emulator with SysV3.2+, do other vendors do it too?

ESIX has both emulators.  The release notes say that the default
emulator doesn't do the 387-only instructions, but runs much faster.
But code with 387-only instructions will get a floating point
exception with the default emulator.
-- 
John W. Temples -- john at jwt.UUCP (uunet!jwt!john)