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 +
