* floating points in kernel space @ 2011-01-04 12:43 mohit verma 2011-01-04 14:31 ` Victor Rodriguez 2011-01-04 15:44 ` Dave Hylands 0 siblings, 2 replies; 8+ messages in thread From: mohit verma @ 2011-01-04 12:43 UTC (permalink / raw) To: kernelnewbies hi all, i read somewhere that there is no floating point arithmatic supported in the kernel space . is it true?? but the floating point registers and even floating point arithmatic units are all handled by the.........( kernel i think). thanks in advance for help........... -- ........................ *MOHIT VERMA* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/069a6cc2/attachment.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 12:43 floating points in kernel space mohit verma @ 2011-01-04 14:31 ` Victor Rodriguez 2011-01-04 15:44 ` Dave Hylands 1 sibling, 0 replies; 8+ messages in thread From: Victor Rodriguez @ 2011-01-04 14:31 UTC (permalink / raw) To: kernelnewbies On Tue, Jan 4, 2011 at 6:43 AM, mohit verma <mohit89mlnc@gmail.com> wrote: > hi all, > i read somewhere that there is no floating point arithmatic supported in the > kernel space . is it true?? > but the floating point registers and even floating point arithmatic units > are all handled by the.........( kernel i think). > > > thanks in advance for help........... > HI it is true , the floating point is not supported on printk , AFAIK the only way to handle is to send it like HEX values and then some other application like perl or python transform it to floating point Hope it helps Regards Victor Rodriguez > -- > ........................ > MOHIT VERMA > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 12:43 floating points in kernel space mohit verma 2011-01-04 14:31 ` Victor Rodriguez @ 2011-01-04 15:44 ` Dave Hylands 2011-01-04 16:57 ` Mulyadi Santosa 1 sibling, 1 reply; 8+ messages in thread From: Dave Hylands @ 2011-01-04 15:44 UTC (permalink / raw) To: kernelnewbies Hi Mohit, On Tue, Jan 4, 2011 at 4:43 AM, mohit verma <mohit89mlnc@gmail.com> wrote: > hi all, > i read somewhere that there is no floating point arithmatic supported in the > kernel space . is it true?? > but the floating point registers and even floating point arithmatic units > are all handled by the.........( kernel i think). That is correct. In some architectures, attempts to use floating point from the kernel will work. I've seen some x86 code that uses it. However, with ARM for example, there is no float support in the kernel, and some ARM architectures have no floating point support in the hardware either. For ARM, there is a kernel implemented emulation of the floating point instructions, but these can only be called from user space. There are also some ARM software floating point libraries (aka soft-fp) which can be used from user space (which are much more efficient than using the kernel emulation library) The kernel also doesn't support 64-bit division using the C divide statement, unless you happen to be running on a 64-bit architecture. There are some helper functions to achieve 64-bit division (see div64.h). Dave Hylands ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 15:44 ` Dave Hylands @ 2011-01-04 16:57 ` Mulyadi Santosa 2011-01-04 22:19 ` julie Sullivan 0 siblings, 1 reply; 8+ messages in thread From: Mulyadi Santosa @ 2011-01-04 16:57 UTC (permalink / raw) To: kernelnewbies Hi.. On Tue, Jan 4, 2011 at 22:44, Dave Hylands <dhylands@gmail.com> wrote: > That is correct. In some architectures, attempts to use floating point > from the kernel will work. I've seen some x86 code that uses it. AFAIK, once x86 didn't supported due to floating point related registers are not correctly (or even doing?) saved and restored during context switching. So maybe it is fixed now... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 16:57 ` Mulyadi Santosa @ 2011-01-04 22:19 ` julie Sullivan 2011-01-04 22:32 ` Greg Freemyer 0 siblings, 1 reply; 8+ messages in thread From: julie Sullivan @ 2011-01-04 22:19 UTC (permalink / raw) To: kernelnewbies > > On Tue, Jan 4, 2011 at 22:44, Dave Hylands <dhylands@gmail.com> wrote: > > That is correct. In some architectures, attempts to use floating point > > from the kernel will work. I've seen some x86 code that uses it. > > > AFAIK, once x86 didn't supported due to floating point related > registers are not correctly (or even doing?) saved and restored during > context switching. So maybe it is fixed now... > > -- > I've often wondered about this oft-cited kernel behaviour too, in my naivety. I understand that this must be on a per-arch basis, but does this mean that the kernel doesn't police FP access at _all_ (perhaps this is what Mohit means too)? Does code like X for example have to access it directly, or does it just use the GPU? What about other user-space code - does it have a separate library and do its own security? Video drivers? Sorry if these are basic questions, I grepped for float in the kernel but as-yet the associated code looks really arcane to me - if anyone could answer any of these questions generally (if that's possible) that would be very helpful with visualizing the mechanism. Maybe I'm looking in the wrong place. When I started looking at the kernel I imagined this small, neat, concise piece of highly efficient code so I wasn't surprised there was no float (don't laugh - how one learns :-/ ) ... I suppose any float per-arch 'hacks' (to get a larger word size) would not be worth the overhead of the mode switch and extra code? Thanks Julie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/bb73a59d/attachment-0001.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 22:19 ` julie Sullivan @ 2011-01-04 22:32 ` Greg Freemyer 2011-01-04 23:26 ` julie Sullivan 0 siblings, 1 reply; 8+ messages in thread From: Greg Freemyer @ 2011-01-04 22:32 UTC (permalink / raw) To: kernelnewbies On Tue, Jan 4, 2011 at 5:19 PM, julie Sullivan <kernelmail.jms@gmail.com> wrote: > >> >> On Tue, Jan 4, 2011 at 22:44, Dave Hylands <dhylands@gmail.com> wrote: >> > That is correct. In some architectures, attempts to use floating point >> > from the kernel will work. I've seen some x86 code that uses it. >> >> >> AFAIK, once x86 didn't supported due to floating point related >> registers are not correctly (or even doing?) saved and restored during >> context switching. So maybe it is fixed now... >> >> -- > > I've often wondered about this oft-cited kernel behaviour too, in my > naivety.? I understand > that this must be on a per-arch basis, but does this mean that the kernel > doesn't police FP > access at _all_ (perhaps this is what Mohit means too)? Does code like X for > example have to access it directly, or does it just use the GPU? What about > other user-space code - does it > have a separate library and do its own security? Video drivers? > Sorry if these are basic questions, I grepped for float in the kernel but > as-yet the associated > code looks really arcane to me - if anyone could answer any of these > questions generally > (if that's possible) that would be very helpful with visualizing the > mechanism. > Maybe I'm looking in the wrong place. > > When I started looking at the kernel I imagined this small, neat, concise > piece of highly > efficient code so I wasn't surprised there was no float (don't laugh - how > one learns :-/ ) ... > I suppose any float per-arch 'hacks' (to get a larger word size) would not > be worth > the overhead of the mode switch and extra code? > > Thanks > Julie Julie, I think the issue is the kernel is extremely concerned with the efficiency of the syscall path. Very legitimately some benchmarks just measure that one path to see how many thousands of syscalls per second can be made. To accelerate that path as much as possible, the linux kenel chooses not to incur the overhead of preserving the FP registers on every syscall. So kernel code that uses FP must first ensure any registers it uses are preserved. I don't recall ever writing any FP kernel code, so I don't know what facilities are available to do that. Greg ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 22:32 ` Greg Freemyer @ 2011-01-04 23:26 ` julie Sullivan 2011-01-21 14:38 ` lei yang 0 siblings, 1 reply; 8+ messages in thread From: julie Sullivan @ 2011-01-04 23:26 UTC (permalink / raw) To: kernelnewbies > I think the issue is the kernel is extremely concerned with the > efficiency of the syscall path. > > Very legitimately some benchmarks just measure that one path to see > how many thousands of syscalls per second can be made. > > To accelerate that path as much as possible, the linux kenel chooses > not to incur the overhead of preserving the FP registers on every > syscall. > > So kernel code that uses FP must first ensure any registers it uses > are preserved. I don't recall ever writing any FP kernel code, so I > don't know what facilities are available to do that. > > Greg > Greg I had a vague idea about overhead being incurred due to the mode switch, but your clear explanation makes it a lot easier to understand _where_ this happens. It's very helpful, thank you for your response. Julie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/ff816de8/attachment.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* floating points in kernel space 2011-01-04 23:26 ` julie Sullivan @ 2011-01-21 14:38 ` lei yang 0 siblings, 0 replies; 8+ messages in thread From: lei yang @ 2011-01-21 14:38 UTC (permalink / raw) To: kernelnewbies How can I know arm kernel has suppored hardware float point? is there a kernel config to be enabled for this supporting? Lei On Wed, Jan 5, 2011 at 7:26 AM, julie Sullivan <kernelmail.jms@gmail.com> wrote: > >> I think the issue is the kernel is extremely concerned with the >> efficiency of the syscall path. >> >> Very legitimately some benchmarks just measure that one path to see >> how many thousands of syscalls per second can be made. >> >> To accelerate that path as much as possible, the linux kenel chooses >> not to incur the overhead of preserving the FP registers on every >> syscall. >> >> So kernel code that uses FP must first ensure any registers it uses >> are preserved. ?I don't recall ever writing any FP kernel code, so I >> don't know what facilities are available to do that. >> >> Greg > > Greg > > I had a vague idea about overhead being incurred due to the mode switch, but > your clear explanation makes it a lot easier to understand _where_ this > happens. > It's very helpful, thank you for your response. > > Julie > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-21 14:38 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-04 12:43 floating points in kernel space mohit verma 2011-01-04 14:31 ` Victor Rodriguez 2011-01-04 15:44 ` Dave Hylands 2011-01-04 16:57 ` Mulyadi Santosa 2011-01-04 22:19 ` julie Sullivan 2011-01-04 22:32 ` Greg Freemyer 2011-01-04 23:26 ` julie Sullivan 2011-01-21 14:38 ` lei yang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.