izen@amelia.nas.nasa.gov (Steven H. Izen) (08/30/89)
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.
Does anyone have any ideas?
I expect that this will also be a problem if I attempt to link any 3167
application to the Xlib routines provided by ISC, but I haven't tried that one
yet. (Any ISC techies out there--Do you think it would be possible to obtain a
version of Xlib compiled to use the 3167?)
Thanx in advance.
Steve Izen
--
Steve Izen: {sun,decvax,uunet}!cwjcc!skybridge!izen386!steve
or steve%izen386.uucp@skybridge.scl.cwru.edu
or izen@cwru.cwru.eduted@eslvcr.UUCP (Ted Powell) (09/01/89)
In article <3036@amelia.nas.nasa.gov> izen@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@eslvcr.wimsey.bc.ca ...!ubc-cs!van-bc!eslvcr!ted (Ted Powell)