Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.arch
Subject: Re: How does compiled code use the floating point unit?
Message-ID: <3749@utcsri.UUCP>
Date: Mon, 8-Dec-86 14:21:09 EST
Article-I.D.: utcsri.3749
Posted: Mon Dec  8 14:21:09 1986
Date-Received: Wed, 10-Dec-86 05:10:31 EST
References: <394@houxs.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 51
Summary: 

In article <394@houxs.UUCP> daw@houxs.UUCP (D.WOLVERTON) writes:
>In some systems, the hardware floating point (fp) unit is _optional_.
>The Itty Bitty Machines (IBM) PC is a good example.  From the
>point of view of a compiler writer, how does one deal with
>that uncertainty?

As a compiler writer, you should provide an option to directly use the
fp unit. Run-time subroutines will be used otherwise.
If you are writing distribution software, which must run whether an fp
unit exists or not, and which uses the fpu if it does exist, then
you have this problem.

>
>I know of, or can imagine, several flavors of code generation
>in the face of this situation:
>
>1)  Code generation emits calls to a floating point library.  
>This library checks for the presence of fp hardware, and uses 
>the fp hardware it is is present, otherwise it emulates the operation.
>
>2)  Like (1), but the test for fp unit is made before the function
>call.
>
>3)  Code generation pretends that the fp unit will always be present,
>so it emits code which uses the fp unit directly into the instruction
>stream.  If a fp unit is not present, the hardware arranges for a trap
>to occur which transfers control to the OS [ and the fp op is emulated..]

>4)  Code generation emits code which always causes transfer to the
>OS, e.g. by illegal opcodes or TRAP instructions.  The OS then
>proceeds like (3a) or (3b) above except that the fp unit may be used 
>if present.

5) The program contains a jump table to fp routines. At program start-up,
the presence or absence of the fp unit is determined, and the jump table
is modified to point either to routines which use the fp hardware, or to
routines which do the work in software. The generated code then makes calls
indirectly via this jump table. So no testing is done at run-time once
the table is set up.

Even better, but a a little weirder: The code directly calls routines which
use the fp hardware. If there is no fp unit, the start-up code puts a jump
instruction at the start of each routine, which jumps to the equivalent
subroutine. This makes the code a little faster when an fp is present. When
it isn't, the extra jump won't matter much anyway.


-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...