Xref: utzoo comp.unix.i386:3473 comp.windows.x:19652
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!texsun!texbell!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.i386,comp.windows.x
Subject: Re: Why do you need a 387 to run X11R3?
Keywords: slowness, 80387
Message-ID: <20301@nuchat.UUCP>
Date: 12 Mar 90 02:50:22 GMT
References: <9868@batcomputer.tn.cornell.edu> <20203@nuchat.UUCP> <4.523N2ggpc2@ficc.uu.net>
Reply-To: steve@nuchat.UUCP (Steve Nuchia)
Organization: Houston Public Access
Lines: 46

In article <4.523N2ggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <20203@nuchat.UUCP> I wrote:
>> When I cut my teeth, unix systems without FP hardware did the
>> emulation thing in library routines that were 10 to maybe

note that I specifically mean user-mode routines, no trapping
allowed.  Of course there are dozens of variations, no need
to enumerate them.

>I'm moderately sure that Version 7 UNIX on the PDP-11 trapped an illegal
>instruction and emulated it, just like the 80386 UNIXes do. It might be that

Not having immediate access to a V7 system I can't argue, but I
think that the mechanism is quite old.  I know that the V7 compiler
I used generated library calls rather than FP instructions, and
I know most of the low-priced sysIII boxes from the early eighties
did the same.  Come to think of it though, I'm not sure how many
of them even had FPA options available.  The v7 compiler had the
option of generating FP instuctions, but I can't remember another
system off the top of my head, other than Sun, that uses that scheme.

It is an unpleasant trade off to have to make -- either you make FP
slower than it has to be (386 case, and other "transparent" schemes)
or you complicate the users' lives with N different versions of the
library and of each executable (Sun case).  Sun tried to choose the
third alternative by specing a single, always-present FP device for
the sun4 line, but less than a year after the sun4 shipped there
was a (slightly) different FPA option requiring different compile
options.  Sigh.

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.

Personally I think the choice of doing FP emulation in the kernel
was regretable, especially given the price-sensitivity common
to most 386 users and the astounding price of 387 chips.  But
I can understand why they went that way, with the huge push
for binary compatiblity that is going on.

-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
"You have no scars on your face, and you cannot handle pressure." - Billy Joel