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