Subject: Re: FPU Emulator
To: Ken Nakata <>
From: Chris G. Demetriou <>
List: macbsd-development
Date: 08/31/1994 16:05:57
> But the second reason is somewhat less serious than the first because
> there already is Motorola's FPSP which provides most of higher level
> functions.  The instructions I have to implement are only the ones
> supported by 68040 in hardware-level.  So, the emulator will do the
> followings:
> 	1) F-line trap handler catches the trap.
> 	2) If the op-code or operand data type is *not* supported
> 	   by 68040, the emulator calls FPSP and have it do the job.
> 	3) If the op-code and operand data type is supported by
> 	   68040, the emulator does the job itself.
> Any comments are greatly appreciated.

"you asked for it..."  8-)

This method has one _significant_ drawback.  Looking in some of the fpsp
sources (i picked, because it has the most interesting
name... 8-), you'll find things like:

        FMOVE.X         FP0,FP1
        FMUL.X          FP1,FP1
        FMOVE.D         ATANA3,FP2
        FADD.X          FP1,FP2         ...A3+V
        FMUL.X          FP1,FP2         ...V*(A3+V)
        FMUL.X          FP0,FP1         ...U*V
        FADD.D          ATANA2,FP2      ...A2+V*(A3+V)
        FMUL.D          ATANA1,FP1      ...A1*U*V
        FMUL.X          FP2,FP1         ...A1*U*V*(A2+V*(A3+V))


so, when running the FPSP emulation code for a given instruction that
isn't implemented on the '040, you may end up taking numerous traps
while processing one single trap, which means that:
	(1) your emulator must be re-entrant
	(2) your emulator will be slow as snot (rather than just
		'slow', as would be expected... 8-) for instructions
		which aren't implemnted in the '040.

I think this is a reasonable "first step" implementation, but the
necessary reentrancy might make it more difficult.  'future work'
after you've done that much, however, would be to write versions of
the remaining routines, so that they didn't use FP at all.
(obviously, you wouldn't want, or even be able to, replace the
FP-using routines, for '040s.)

Another suggestion is that you look at /sys/arch/sparc/fpu.  It's
not a complete emulator, but it's close.  also, it uses macros
extensively, and documents the bit bashing necessary for IEEE
compliance, so it might provide you with some code that you can use,
or at least some hints as to what you need to do.  (Thanks to Theo de
Raadt, the guy who manages the NetBSD/sparc port, for most of the
info about the sparc FPU emulation code.)