3167 and 387

[Ted Powell]

In article <3036 at amelia.nas.nasa.gov> izen at amelia.nas.nasa.gov (Steven H. Izen) writes:
>I have a Compaq Deskpro 386/20 which has both a 3167 and a 387 in it.  In order
>to take advantage of the Weitek 3167 I have been using MicroWays's c and 
>Fortran compilers.  However, the 1167 (used for the 3167) math libraries 
>supplied by both ISC and MicroWay are incomplete.  In particular drand48 does
>not appear in either version of libm1167.a.
>
>	As a result, I have been looking for a way to use a subroutine which
>uses the 387 for its floating point calculations while the calling routine uses
>the 3167.  If I naively link two such subroutines together, I get a floating
>point exception at run time.

While talking to MicroWay yesterday, I asked them about this, and got
a call back this morning. They don't know of any customer who has
successfully used both co-processors from within the same program.
Although they concede that it may be theoretically possible, their
opinion (which I take to be an informed one :-) ) is that it would be
extremely messy, hence no support for this.

The first two files on the GNU compiler (tar) tape are:
    gnu-compiler-beta-tape/4.3BSD-tahoe.README
    gnu-compiler-beta-tape/4.3BSD-tahoe.tar.Z
This is all stuff from Berkeley which is AT&T-free.
The latter file contains:
    4.3BSD-tahoe/lib/libc/gen/random.c
which may or may not contain drand48. If you don't have convenient
access to the Tahoe code (via this GNU tape or otherwise), send me
netmail and I'll check it out. (I got the above info from a printed
listing.)

If you want to get really bizarre (and circumstances are such that the
overhead would not be prohibitive), you could probably have two
processes communicating through pipes or shared memory, with one process
using the 3167, and the other (which incorporates code you don't have
the source for) using the 387.
-- 
ted at eslvcr.wimsey.bc.ca   ...!ubc-cs!van-bc!eslvcr!ted    (Ted Powell)