Post by Ronald C.F. AntonySo if Linux automatically uses a math processor, if present, unless
told to do so otherwise, then why on the one hand does the arch/
i386/Makefile specify in the standard kernel the -msoft-float
compiler flag, and why do we bother removing it for the xbox if the
standard kernel decides it's important to have that option?
I mean, either the kernel does the right thing, even with this
option, and uses the coprocessor if present, or it doesn't.
Somehow, this seems somewhat contradictory to me.
http://uwsg.iu.edu/hypermail/linux/kernel/0409.1/2266.html
Why this kernel is always compiled with the FP emulation for x86?
CFLAGS += -pipe -msoft-float
And it's hardcoded, it does not depend on CONFIG_MATH_EMULATION. So,
is this just a typo or not?
It catches bogus attempts to use floating point in the kernel by
making them error at link-time.
So does this mean the kernel is not supposed to use floating point
at all, and the -msoft-float forces the compiled to create
references to libraries, which then aren't linked and hence cause a
link error to catch this problem?
If so, shouldn't we stop patching this, and leave the -msoft-float
compiler flag where it is and reduce the size of the xbox-linux
kernel patch a bit?
To answer my own question:
a) the kernel isn't supposed to use floating point calculations
=> http://uwsg.iu.edu/hypermail/linux/kernel/0409.1/2534.html
Post by Ronald C.F. AntonyThe problem is that the kernel can't use the FPU. I think this is
because its context is not saved on context switch (userland ->
kernel), so we'd end up messing up the FPU state, and userland
applications would get silly results for calculations with context
switches in between.
Thus we force gcc to use the library functions for floating point
arith, and since we don't link against gcc's lib, FPU users get a
fancy linker error.
If you want to use floating point arith inside the kernel, you're
probably wrong wanting it. If you really need it, you can
a) emulate it using fixed-point math on unsigned long or
b) manually save the FPU state, load your operations into it, operate,
get the results and restore the FPU state.
I have yet to see someone who really needs to do floating point maths
inside the kernel.
b) we DO use floating point in drivers/video/xbox/conexant.c
Now if all the other screen drivers can figure out the parameters w/o
floating point calcuations, why does the XBOX chip need such tricks?
First, all screen dimensions are integer in the first place. Second,
even things like clock rates, etc. can be made integer by getting the
proper unit e.g. 0.3 seconds are 300ms.
If the code were a bit more readable/documented, then I'd take it
upon myself to convert that into integer math, but given the
potential to fry screens and graphic chips with the wrong data in the
registers, that's not something I want to debug without having a
clear understanding of what is supposed to be going on. :)
The amount and kind of math done in floating point seems trivial, but
it's not clear to me what precision is required and what some of
these parameters mean, because fields in some structs are not
documented, etc.
Any takers for either explaining me the details or converting this to
integer math? It seems odd that for one such module we run afoul of
the rules.
Ronald