Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!pyrnj!mirror!ima!johnl From: johnl@ima.UUCP (John R. Levine) Newsgroups: comp.arch Subject: Re: How does compiled code use the floating point unit? Message-ID: <285@ima.UUCP> Date: Tue, 9-Dec-86 12:12:57 EST Article-I.D.: ima.285 Posted: Tue Dec 9 12:12:57 1986 Date-Received: Wed, 10-Dec-86 04:13:17 EST References: <394@houxs.UUCP> Reply-To: johnl@ima.UUCP (John R. Levine) Organization: Javelin Software Corporation Lines: 51 Summary: All sorts of ways. In article <394@houxs.UUCP> daw@houxs.UUCP (D.WOLVERTON) writes: >In some systems, the hardware floating point (fp) unit is _optional_. > ... >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. This is the most common in PC languages I've seen. >2) Like (1), but the test for fp unit is made before the function >call. The code is larger, but in the case where the fp unit is >present it is faster because not function call was performed. Never seen it. PC compilers usually are more concerned with small code size than fast execution. >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. ... This is what the PDP-11 versions of Unix always did. Originally, the FP emulator was linked into all of the executables which caught their own illegal instruction faults and then did the emulation. More recent versions have moved the FP emulation into the OS so that you can just emit code that assumes that the floating point is present. Unfortunately, this trick does not work on PCs and other 8088 machines because if you have no 8087, your floating point instructions go into outer space and hang or return random results. One clever trick used in the PC/IX version of Unix is this: Every floating point instruction has to be preceded by a one-byte "wait" instruction to make sure that the FP unit has finished the preceding instruction. It also turns out that the first byte of all FP instructions is DC, DD, or DE hex. When the assembler emits an FP instruction, rather than emitting a wait instruction, it emits the first byte of an INT instruction which causes a software trap. The trap number is determined by the next byte in the instruction stream, which is the DC, DD, or DE. When the OS gets such an interrupt, it checks to see if the system has an 8087. If so, it patches the INT instruction to a WAIT and returns to it, so that the hardware executes the instruction. Otherwise it emulates the operation and returns. This means that there is a trap for each instruction the first time it is encountered in the program, but if there is an 8087, the program runs at full speed after that. The 80286 and its successors make this hack unnecessary, since they have a bit you can set to force traps on execution of unimplemented instructions. -- John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.EDU The opinions expressed herein are solely those of a 12-year-old hacker who has broken into my account and not those of any person or organization.