> > > 1. Config option approach :
> > >
> > > In the kernel config menu, one picks one or more CPUs. One also
specifies
> > > whether the CPU(s) have a FPU.
> > >
> > > All FPU related code in kernel is configured in or out based on the
CONFIG
> > > setting.
> >
> > As has been noted in other messages in this exchange, whether one
> > has an FPU or not isn't really the determining factor in including FP
> > support code in the kernel. The bulk of it is the emulator, and the
> > emulator needs to be there if you want to execute binaries built
> > to include MIPS FP instructions, whether in full emulation or using
> > the FPU (for the denormal cases, etc.).
> >
> That needs a little more explanation.
>
> . When I say "All FPU related code", I really meant FPU code which is not
a
> part of FPU emaulator. One example is the code in exit_thread()
> (arch/mips/process.c) as brough up by flo. I believe there are also such
code
> in ptrace.c.
Understood. My point is that that code can be lumped with
the emulator as the set of support needed to run FPU-full
binaries. Even with an emulator, one needs to manage
and communicate FP state. The only difference is that
the "floating point registers" are in the thread structure,
not in the CPU.
> . Regarding whether we should have FPU emulator, I think it should be a
> separate CONFIG option. It is orthorgal to HAS_FPU option.
>
> In other words, we will have four combinations:
>
> a) HAS_FPU & FPU_EMULATION - which is necessary when FPU is not a full
> implementation.
>
> b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
> application
>
> c) HAS_FPU & !FPU_EMULATION - when FPU is a full implementaion (or use
the
> old incomplete emaulation?)
We're talking about MIPS/Linux here. To the best of my knowledge
there are *no* "full" implementations of IEEE floating point on
a MIPS CPU. The number of unimplemented cases varies
somewhat from design to design, but I know of no MIPS CPU
where it is a null set.
> d) !HAS_FPU & !FPU_EMULATION - it mandates non-fpu-ful userland (which to
me
> is perfectly fine)
>
> I start to feel a little "shaky" here as I have not written any FPU code.
> Will such a classification make life easier or worse? Is there any
> feasibility issue here?
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".
But my main objection to treating the two options as
orthogonal is that your (c) case above will simply
create kernels that are guaranteed fail for some
cases of IEEE math. It's just not good engineering
to give people a 25% chance of building a kernel
that seems to be just fine, at first...
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.
Regards,
Kevin K.
