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 +
|