> Let me remind the actual problem the discussion started from was whether
> we want to hardcode FP hw presence based on a CPU identification or to
> check for it explicitly. I hope we agree the latter is saner.
Absolutely.
> But the code that needs to know whether there is a real FPU present is
> indeed minimal (as it should be) thus the gain from removing the detection
> altogether in favour to a config option is at least questionable if not
> insane.
Well, I might not have put it that strongly, but I quite agree.
> > My own recommendation would be to either have
> > full FP support for binaries or none at all. If someone
> > really wants to put the FPU-specific assembler
> > routines under a different conditional, that's cool, but
> > the configuration options should be such that the
> > (c) cannot be generated by the config scripts.
>
> I think I may research what the gain from leaving parts of the FPU
> emulator apart would be for systems that have FP hw.
Surprisingly little. Basically, you could remove emulation
for moves, loads, and stores. Any instruction that actually
computes a value can potentially turn out to be unimplemented,
depending on the inputs. If you *knew* you had an FPU, you
could also make the emulation fractionallly more efficient by
having it operate directly on the FP registers. When the current
kernels emulate an instruction that failed on a HW FPU,
they copy the HW FPU state into the software FPU
registers, invoke the emulator, and when the emulation
has completed, restore the HW FPU state. It made for
a clean interface to do things that way, and my
judgement was that the operation was too infrequent
to justify complicating things further.
> It's not a priority
> task for me at the moment -- the current configuration works and having
> unused code in a running kernel is ugly but non-fatal.
"If it ain't broke..."
Kevin K.
