On Wed, 7 Feb 2001, Kevin D. Kissell wrote:
> Moving forward, MIPS CPUs will have a specific FPU-present bit
> in one of the CP0 Config registers, as specified by MIPS32/MIPS64.
Thanks for pointing this out -- this might prove useful. Though the old
IDT detection method is not any more complicated and it's universal. It
should work for MIPS32/MIPS64 anyway, right?
> As other people have observed, having the FPU emulator in
> the kernel is necessary for full IEEE math even if one *has*
> an FPU. When I bolted the Algorithmics emulator into the 2.2
> kernel at MIPS, I made it optional so that people could regress
> to Ralf's old not-fully-compliant mini-emulator if they were really
> desperate for memory and didn't need full IEEE. Maybe I
> should have just nuked it and made the full emulator mandatory.
How much of the emulator is really required for every system? Can we
assume R[23]010 functionality if there is FP hw present?
> As far as the library-versus-kernel-emulation debate is
> concerned, yes, user-level emulation will always be faster.
Why would be faster? You need to handle SIGFPE, which needs a
user->kernel->user transition anyway. I think a kernel emulation might be
marginally faster as we may skip signal interface handling (and such
details like an integer overflow/division by zero) and handle exceptions
directly.
> However, you end up with a rather unpleasant configration
> management problem - every application and library
> distributed needs to be built both with and without FP.
Nope -- you just require an emulator in glibc (or whatever libc you
decide to use). No need to change application software -- FP opcodes will
just trap into libc.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|