Xref: utzoo comp.unix.i386:3584 comp.windows.x:19888 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!srcsip!jhereg!uci!clay From: clay@uci.mn.org (Clayton Haapala) Newsgroups: comp.unix.i386,comp.windows.x Subject: Re: Why do you need a 387 to run X11R3? Keywords: slowness, 80387 Message-ID: <1990Mar14.152821.14202@uci.mn.org> Date: 14 Mar 90 15:28:21 GMT References: <9868@batcomputer.tn.cornell.edu> <20203@nuchat.UUCP> <4.523N2ggpc2@ficc.uu.net> <20301@nuchat.UUCP> Organization: Unified Communications, Inc. Lines: 27 In article <20301@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >Dynamic linking is about the only good solution, but you still have >to allow the heavy FP users to compile for specific hardware to >avoid the two jumps per FLOP overhead. There was a scheme proposed >in which illegal instructions were compiled into the program and >replaced at run time with the "right" intruction by the kernel. Don't >know if that ever went out with a commercial system. I think XENIX uses a variation of that scheme -- an initial fault on the first time an FP instruction is attempted, then the kernel "hot patches" the binary with a transfer to the right emulation code. Next time through there is no fault, just a call. Has to be faster than a complete context switch with a fault, I would think. I heard this rumor when I was working with XENIX 3 for 286 boxes. I know from empirical evidence that XENIX FPP emulation beats the pants off of SysV 386 emulation. Say, anybody try the IIT 3C87? It's a clone of the Intel 80387, supposed to run 25-30% faster. They also have a 287 replacement. I'm thinking of buying one in a couple of weeks unless I hear terrible things about its performance under XENIX/UNIX. -- Clayton Haapala ...!bungia!uci!clay (clay@uci.uci.com) Unified Communications Inc. "Every morning I get in the Queue. 3001 Metro Drive - Suite 500 'n get on the Bus that takes me to you." Bloomington, MN 55425 -- the Who