Floating-point in kernel space
zombyfork at gmail.com
Fri Mar 9 18:44:50 UTC 2007
On 3/9/07, Oliver Fromme <olli at lurza.secnetix.de> wrote:
> Maslan <maslanbsd at gmail.com> wrote:
> > I think i've seen somewhere but i don't remember that floating point
> > arithmetic is not allowed in kernel space, if that's right, can anyone
> > please tell why ???
> Because the overhead of swapping the contents of the FPU
> registers on every context switch within the kernel.
> So far there has been no compelling reason for having FP
> support in kernel code that would justify to pay that
> > and why not not emulate the floating point in kernel space ???
> First, FPU emulation is rather slow, and second, someone
> would have to write the code. In the past, the FreeBSD
> kernel had two FPU emulation libraries (for emulation
> of FPU instructions in userland). One was BSD-licensed,
> but incomplete and not 100% compatible, and the second
> was GPL, so it couldn't be enabled by default. As far as
> I know, both of them were removed because hardware without
> an FPU was considered obsolete, and nobody was willing to
> improve and maintain the code.
> Let me ask you, why would you want to have floating point
> support in the kernel? Most of such typical uses can
> easily be replaced by simple fixed-point arithmetic with
> integer instructions. There are several examples of such
> code, e.g. in ALTQ, DUMMYNET and in the NTP support code.
> Best regards
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
> chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
> "I have stopped reading Stephen King novels.
> Now I just read C code instead."
> -- Richard A. O'Keefe
It would be helpful to know why you need this support as well. For many
projects that I've done, the kernel code is used for transferring the
"binary" data from the computer system (hardware or kernel) to a userland
daemon that would do the FP processing (which is likely significantly time
consuming) and then this daemon would provide a listening socket that other
software could use to retrieve said data.
I would imagine that if you are needing FP processing in the kernel, then
you'll be doing a serious amount of work and may not want to be hogging up a
lot of kernel time doing it. However, there are Real-Time applications for
such an implementation. Perhaps posting about the problem would be more
More information about the freebsd-hackers