and I suspect, 68LC040 and 68040V machines. Method used:
1. do NOT use the frames effective address at all
2. do NOT use the frames next instruction address, but
3. restore the "this instruction" pc into the pc field of the frame at the
beginning of the emulation, if we got a frame format 4.
TODO:
A. find the bug in the usage of the frame EA, and revert to using it.
B. find the bug in the usage of the frames next instruction address, and
consider whether it's worthwhile to use it.
C. make the emulation complete.... FEXP FETOM1, and the trigonometric functions
are missing.
I've fixed most (not all) m68k FPE bugs that give bogus
calculation results, esp. fsqrt instruction. Also, the internal FP
representation has been reduced from 115-bit mantissa to 67-bit
mantissa which reduced the required mantissa operation roughly by one
fourth. I've done an extensive (though not exhaustive - it's
impossible!) test on the internal routines by feeding them randomly
generated FP numbers, and found that the new code is more precise than
MC68040 FPU (it seems to have a rounding bug).
[ Only change was to keep fpu_calcea.c's name instead of renaming to
fpu_ea.c in Ken's patch. --akb ]
<kenn@remus.rutgers.edu>. This emulator does not yet emulate
the following functions:
FSINH, FETOXM1, FTANH, FATAN, FASIN, FATANH, FSIN, FTAN,
FETOX, FTWOTOX, FTENTOX, FCOSH, FACOS, FCOS, FSINCOS
It is sufficient, however, to allow programs like df, w, and newfs,
to run to completion with correct results.
Portions of this code were based on the sparc fpe and on initial
work by gwr.
is