Our div64.h macro is quite broken, and causes printk to not be able to do
a long long format.
Is there a 'fast' generic C algorithm we can replace it with, instead of
mucking with ASM?
--
Troy Benjegerdes | master of mispeeling | 'da hozer' | hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Our div64.h macro is quite broken, and causes printk to not be able to do
a long long format.
Is there a 'fast' generic C algorithm we can replace it with, instead of
mucking with ASM?
Usually you can copy the asm version from the gcc sources (libgcc).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2002-01-26 22:30:49
On Sat, 26 Jan 2002, Troy Benjegerdes wrote:
Our div64.h macro is quite broken, and causes printk to not be able to do
a long long format.
Is there a 'fast' generic C algorithm we can replace it with, instead of
mucking with ASM?
If depends on what you want from do_div. If you guarantee that in
do_div(n,base) base will be constant it's fairly easy (provided GCC does
proper constant propagation). I also have the expanded code for 10
explicitly somewhere in prepboot, I just wrote it for fun for my own
printb(==printk for bootloader). I also wrote a generic 64 by 32 divide
for the x86 ROM BIOS emulator (stupid looping, slow but ok for this, I
short-circuit it for 32/32 divides which are the most common).
On a somewhat relared topic, there is also an inverse estimator to use
mulhwu somewhere in the time code (mulhwu_scale_factor IIRC what I
wrote:-)), but it's deliberately compact and slow.
Which flavour would you prefer ? (The one in do_div is only for 64 bit
targets, someone clearly goofed on that one).
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Troy> Our div64.h macro is quite broken, and causes printk to not be able to do
Troy> a long long format.
Troy> Is there a 'fast' generic C algorithm we can replace it with, instead of
Troy> mucking with ASM?
Hmm, I sent a patchlet to lkml with Subject: [PATCH] 64-bit divide tweaks.
Doesn't it work for you ?
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/