Why Linux Kernel must be built without FP instructions?

Karimo · 05-20-2013, 03:51 PM

Hi everybody,
as /usr/src/linux/arch/x86/Makefile says:

Code:

# prevent gcc from generating any FP code by mistake
KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
KBUILD_CFLAGS += $(call cc-option,-mno-avx,)

I'm wondering the exact reason for that... maybe the context change mechanisms should not rely on such a variery of full fledged registers? Just saying...
There is no way for the kernel internals to take advantage of hardware's FP advanced instructions?

Thanks in advance for any contribution on the topic!

Best Regards,

Karimo

salasi · 05-21-2013, 05:12 AM

I can only theorise at this point, but possibilities that come to mind are:

There is nothing for which the kernel legitimately needs floating point: At least, there is nothing that I can think of that it does, but that is probably more a reflection of my (very, very) limited knowledge of this area than anything else
if FP was used (on, eg, x86), there would be the distinct possibility of different bugs existing for that arch and other architectures where fp was not present and this would be unnecessarily messy to debug
FP is slow: variably slow, depending upon arch, and in some cases (eg, AMD's core approach, where FP units are shared, and therefore there may be a queue for the use of the FP) variably variable depending on when exactly the FP routine was called and what else was going on at the time
Slow is not just the obvious 'lack of speed' problem, but it might create race problems
FP is not infinitely (infinitesimally inaccurate, actually) accurate; if you like finding out that you have 1.9999999997 ethernet adaptors connected, but only 1.00000000 wireless one, this may only be of amusement to you, but it isn't an advantage (and, ok, you could round it afterwards, but what kind of progamming is that? See the last point!)
Linus: I can somehow imagine Linus having a quite attention grabbing rant (justifiably) about bugs slipping in, in using fp calculation when integer was intended, and this being the outcome of that rant. Not saying it actually happened, but it is easy to imagine it happening. Maybe, the possibility of it happening was enough...

sundialsvcs · 05-21-2013, 07:55 AM

One major reason is much more mundane ... if you don't use the floating-point chip, you don't have to save-and-restore the floating point processor state unless you actually switch tasks, which many kernel-entry/exit events do not do.

nobrowser · 06-30-2013, 11:29 AM

That is all true, but those instruction sets don't just do floating
point calculations - they can be used for vector operations like memcopy
and byteswap regardless of the interpretation of the bits being moved.
And they're faster than other ways of doing it. At least that is my
understanding. So by avoiding them the kernel misses a major potential
optimization on the x86 platform.

jpollard · 07-01-2013, 10:07 AM

There isn't that many places where it would be useful, and where it is, I think they save the floating point registers used (it would be in the assembly code rather than C code).