* about 64-bits division in kernel
@ 2011-05-20 3:34 loody
2011-05-20 4:15 ` Dave Hylands
0 siblings, 1 reply; 6+ messages in thread
From: loody @ 2011-05-20 3:34 UTC (permalink / raw)
To: kernelnewbies
hi all:
My platform is 32-bits cpu and I need following calculation in my driver.
#define longdiv(sr1, sr2, div) (unsigned long )((((unsigned long
long)(sr1) << 32) ^ (sr2)) / (div))
my question are:
1. why "__udivdi3" has any relationship with above calculation?
2. I know the above calculation is implemented in clibc, but why
kernel still implement itself?
why kernel try to make another wheel instead of including what
clib provided ?
--
Regards,
^ permalink raw reply [flat|nested] 6+ messages in thread* about 64-bits division in kernel 2011-05-20 3:34 about 64-bits division in kernel loody @ 2011-05-20 4:15 ` Dave Hylands 2011-05-20 5:51 ` loody 0 siblings, 1 reply; 6+ messages in thread From: Dave Hylands @ 2011-05-20 4:15 UTC (permalink / raw) To: kernelnewbies Hi lody, On Thu, May 19, 2011 at 8:34 PM, loody <miloody@gmail.com> wrote: > hi all: > My platform is 32-bits cpu and I need following calculation in my driver. > #define longdiv(sr1, sr2, div) ? ? ?(unsigned long )((((unsigned long > long)(sr1) << 32) ^ (sr2)) / (div)) > > my question are: > 1. why "__udivdi3" has any relationship with above calculation? Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit division is not supported in all kernels. > 2. I know the above calculation is implemented in clibc, but why > kernel still implement itself? > ? ? why kernel try to make another wheel instead of including what > clib provided ? The kernel doesn't use anything from the C runtime library at all. 64-bit division and floating point are 2 things not supported in the kernel, although they do happen to word on some platforms, they aren't portable operations. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* about 64-bits division in kernel 2011-05-20 4:15 ` Dave Hylands @ 2011-05-20 5:51 ` loody 2011-05-20 6:47 ` Dave Hylands 0 siblings, 1 reply; 6+ messages in thread From: loody @ 2011-05-20 5:51 UTC (permalink / raw) To: kernelnewbies hi Dave: Thanks for your kind reply. 2011/5/20 Dave Hylands <dhylands@gmail.com>: > Hi lody, > > On Thu, May 19, 2011 at 8:34 PM, loody <miloody@gmail.com> wrote: >> hi all: >> My platform is 32-bits cpu and I need following calculation in my driver. >> #define longdiv(sr1, sr2, div) ? ? ?(unsigned long )((((unsigned long >> long)(sr1) << 32) ^ (sr2)) / (div)) >> >> my question are: >> 1. why "__udivdi3" has any relationship with above calculation? > > Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit > division is not supported in all kernels. why the name "__udivdi3" has relation to 64-bits arighmetic? Why linker ask for "__udivdi3", it seems there is a common sense for linker that when doing 64-bits calculation it will try to find "__udivdi3", am i right? > >> 2. I know the above calculation is implemented in clibc, but why >> kernel still implement itself? >> ? ? why kernel try to make another wheel instead of including what >> clib provided ? > > The kernel doesn't use anything from the C runtime ?library at all. > > 64-bit division and floating point are 2 things not supported in the > kernel, although they do happen to word on some platforms, they aren't > portable operations. > the 64-bit division seem supported in gcc toolchain, and gcc will take care the platform issue when we cross-compile the gcc, right? It should be safe to static link the 64bits division in gcc. -- Regards, ^ permalink raw reply [flat|nested] 6+ messages in thread
* about 64-bits division in kernel 2011-05-20 5:51 ` loody @ 2011-05-20 6:47 ` Dave Hylands 2011-05-21 6:57 ` loody 0 siblings, 1 reply; 6+ messages in thread From: Dave Hylands @ 2011-05-20 6:47 UTC (permalink / raw) To: kernelnewbies Hi loody, On Thu, May 19, 2011 at 10:51 PM, loody <miloody@gmail.com> wrote: > hi Dave: > Thanks for your kind reply. > 2011/5/20 Dave Hylands <dhylands@gmail.com>: >> Hi lody, >> >> On Thu, May 19, 2011 at 8:34 PM, loody <miloody@gmail.com> wrote: >>> hi all: >>> My platform is 32-bits cpu and I need following calculation in my driver. >>> #define longdiv(sr1, sr2, div) ? ? ?(unsigned long )((((unsigned long >>> long)(sr1) << 32) ^ (sr2)) / (div)) >>> >>> my question are: >>> 1. why "__udivdi3" has any relationship with above calculation? >> >> Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit >> division is not supported in all kernels. > > why the name "__udivdi3" has relation to 64-bits arighmetic? > Why linker ask for "__udivdi3", it seems there is a common sense for > linker that when doing 64-bits calculation it will try to find > "__udivdi3", am i right? Well, since the CPU doesn't directly have support for 64-bit division, the compiler uses helper functions. The helper function __udivdi3 is the one for the particular operation you're providing. The functions in question are part of a library called libgcc and this library is not linked into the kernel. >>> 2. I know the above calculation is implemented in clibc, but why >>> kernel still implement itself? >>> ? ? why kernel try to make another wheel instead of including what >>> clib provided ? >> >> The kernel doesn't use anything from the C runtime ?library at all. >> >> 64-bit division and floating point are 2 things not supported in the >> kernel, although they do happen to word on some platforms, they aren't >> portable operations. >> > the 64-bit division seem supported in gcc toolchain, and gcc will take > care the platform issue when we cross-compile the gcc, right? > It should be safe to static link the 64bits division in gcc. You need to use the do_div macro available in linux/div64.h to perform 64-bit division in the kernel. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* about 64-bits division in kernel 2011-05-20 6:47 ` Dave Hylands @ 2011-05-21 6:57 ` loody 2011-05-21 7:22 ` Dave Hylands 0 siblings, 1 reply; 6+ messages in thread From: loody @ 2011-05-21 6:57 UTC (permalink / raw) To: kernelnewbies hi dave: 2011/5/20 Dave Hylands <dhylands@gmail.com>: > Hi loody, > > On Thu, May 19, 2011 at 10:51 PM, loody <miloody@gmail.com> wrote: >> hi Dave: >> Thanks for your kind reply. >> 2011/5/20 Dave Hylands <dhylands@gmail.com>: >>> Hi lody, >>> >>> On Thu, May 19, 2011 at 8:34 PM, loody <miloody@gmail.com> wrote: >>>> hi all: >>>> My platform is 32-bits cpu and I need following calculation in my driver. >>>> #define longdiv(sr1, sr2, div) ? ? ?(unsigned long )((((unsigned long >>>> long)(sr1) << 32) ^ (sr2)) / (div)) >>>> >>>> my question are: >>>> 1. why "__udivdi3" has any relationship with above calculation? >>> >>> Because you're doing 64 bit arithmetic (unsigned long long) and 64 bit >>> division is not supported in all kernels. >> >> why the name "__udivdi3" has relation to 64-bits arighmetic? >> Why linker ask for "__udivdi3", it seems there is a common sense for >> linker that when doing 64-bits calculation it will try to find >> "__udivdi3", am i right? > > Well, since the CPU doesn't directly have support for 64-bit division, > the compiler uses helper functions. The helper function __udivdi3 is > the one for the particular operation you're providing. > > The functions in question are part of a library called libgcc and this > library is not linked into the kernel. > >>>> 2. I know the above calculation is implemented in clibc, but why >>>> kernel still implement itself? >>>> ? ? why kernel try to make another wheel instead of including what >>>> clib provided ? >>> >>> The kernel doesn't use anything from the C runtime ?library at all. >>> >>> 64-bit division and floating point are 2 things not supported in the >>> kernel, although they do happen to word on some platforms, they aren't >>> portable operations. >>> >> the 64-bit division seem supported in gcc toolchain, and gcc will take >> care the platform issue when we cross-compile the gcc, right? >> It should be safe to static link the 64bits division in gcc. > > You need to use the do_div macro available in linux/div64.h to perform > 64-bit division in the kernel. I found div64.h is located at includ/asm-generic/div64.h instead of include/linux/ BTW, I still cannot figure out why kernel doesn't adopt the gcc's solution. libgcc.a will be compiled by different platform, arm, mips, etc. And that should be safe for kernel to adopt it. -- Thanks a lot, miloody ^ permalink raw reply [flat|nested] 6+ messages in thread
* about 64-bits division in kernel 2011-05-21 6:57 ` loody @ 2011-05-21 7:22 ` Dave Hylands 0 siblings, 0 replies; 6+ messages in thread From: Dave Hylands @ 2011-05-21 7:22 UTC (permalink / raw) To: kernelnewbies Hi miloody, ...snip... > I found div64.h is located at includ/asm-generic/div64.h instead of > include/linux/ > BTW, I still cannot figure out why kernel doesn't adopt the gcc's solution. > libgcc.a will be compiled by different platform, arm, mips, etc. > And that should be safe for kernel to adopt it. I believe that the gcc approach is only safe from user-space, and may cause traps from within kernel space. >From the reading I've done, gcc expects a certain environment, and the kernel provides a different environment. I believe that the primary reason has to do with the fact that libgcc also provides floating point support, which doesn't work in the kernel, so they don't allow any of libgcc to be used. I believe that there are people working on getting support for the integer stuff, but I'm not sure what the status of this is. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-21 7:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-20 3:34 about 64-bits division in kernel loody 2011-05-20 4:15 ` Dave Hylands 2011-05-20 5:51 ` loody 2011-05-20 6:47 ` Dave Hylands 2011-05-21 6:57 ` loody 2011-05-21 7:22 ` Dave Hylands
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.