On Fri, 9 Feb 2001, Kevin D. Kissell wrote: > It's not so much that I doubt the feasibility, I just wonder > if there's any point to adding the complexity. As noted > above, if you're going to support FP-full binaries, you > have to support the processor model of FPU. The user > will be manipulating what he sees as FP registers, and > all of the state, signal, and context management logic > associated with them has to be there regardless of whether > they exist in the CPU or in the kernel. It's true that there are > a few paths through the code, the ones that actually load > and store the FP registers, that are distinct. Those could > certainly be suppressed at compile time if you wanted a > kernel that would never allow a real FPU to be used, > but the memory savings would be smaller than you seem > to think. It's not "HAS_FPU" versus "EMULATOR", > it's "SUPPORTS_FP" and "HAS_FPU". 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. 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. > 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. 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. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
