Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!dgis!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.arch
Subject: Re: How does compiled code use the floating point unit?
Message-ID: <306@bms-at.UUCP>
Date: Tue, 9-Dec-86 21:40:25 EST
Article-I.D.: bms-at.306
Posted: Tue Dec  9 21:40:25 1986
Date-Received: Wed, 10-Dec-86 10:55:31 EST
References: <394@houxs.UUCP>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 22
Summary: A combination method

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

> 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.  At this point either:

> 4)  Code generation emits code which always causes transfer to the
> OS, e.g. by illegal opcodes or TRAP instructions.  The OS then

With the *86/*87 chips, there is a very elegant solution combining
3 & 4.  Both emulation and real code are easily defined to be
identical except by a constant difference in the first byte.
Then the OS can select for the presence or absence of the chip at
program load time by using a relocation table to modify the initial
instruction bytes if the *87 is absent.  This way you get optimal
emulator performance and optimal hardware performance.
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>