From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] ARM missing __udivdi3 in lib_arm or fix 64bit division in nand_util.c?
Date: Wed, 01 Aug 2007 19:55:52 +0200 [thread overview]
Message-ID: <46B0C928.3020001@googlemail.com> (raw)
In-Reply-To: <20070731202728.9B288352659@atlas.denx.de>
Wolfgang Denk wrote:
> In message <46AF8CF0.7090600@googlemail.com> you wrote:
>
>>Something like in attachment?
>
> Probably not.
Thanks for commenting!
>>+/* The unnecessary pointer compare is there
>>+ * to check for type safety (n must be 64bit)
>>+ */
>>+# define do_div(n,base) ({ \
>>+ uint32_t __base = (base); \
>>+ uint32_t __rem; \
>>+ (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>>+ if (((n) >> 32) == 0) { \
>>+ __rem = (uint32_t)(n) % __base; \
>>+ (n) = (uint32_t)(n) / __base; \
>>+ } else \
>>+ __rem = __div64_32(&(n), __base); \
>>+ __rem; \
>>+ })
>
>
> CodingStyle: Generally, inline functions are preferable to macros
> resembling functions.
I know that this is no excuse for bad coding style, but please note
that this stuff is already part of U-Boot, see lib_avr32/div64.c and
include/asm-avr32/div64.h. My patch only moves the *unmodfied* files
to lib_generic for general use, as proposed by H?vard. Same as U-Boot
NG did ;)
>>Index: uboot/lib_generic/Makefile
>>===================================================================
>>--- uboot.orig/lib_generic/Makefile
>>+++ uboot/lib_generic/Makefile
>>@@ -27,7 +27,7 @@ LIB = $(obj)libgeneric.a
>>
>> COBJS = bzlib.o bzlib_crctable.o bzlib_decompress.o \
>> bzlib_randtable.o bzlib_huffman.o \
>>- crc32.o ctype.o display_options.o ldiv.o sha1.o \
>>+ crc32.o ctype.o display_options.o div64.o ldiv.o sha1.o \
>> string.o vsprintf.o zlib.o
>
>
> Why should I link this code and increase the memory footprint for all
> boards, when 99% of them don't need this?
Sorry if I misunderstood anything here. But with putting
do_div/__div64_32 to a *library* boards use it only if they need it?
Here, if they explicitly use do_div()? If they don't use do_div(), the
memory footprint isn't increased because it simply isn't used?
Please find below some tests with omap5912osk_config which doesn't use
do_div/__div64_32. The first numbers are with clean recent git, the
second with my patch with div64 stuff moved to lib_generic. As
expected, library size increases but image size stays the same.
Anything wrong with this?
> Rejected.
What's your proposal then with the 64bit division issue in nand_util.c?
Best regards
Dirk
==> Clean recent git:
> make omap5912osk_config
> make
> ll u-boot.bin
... 100016 ... u-boot.bin
> ll lib_generic/libgeneric.a
... 102740 ... lib_generic/libgeneric.a
> arm-elf-ar -t lib_generic/libgeneric.a
bzlib.o
bzlib_crctable.o
bzlib_decompress.o
bzlib_randtable.o
bzlib_huffman.o
crc32.o
ctype.o
display_options.o
ldiv.o
sha1.o
string.o
vsprintf.o
zlib.o
>
==> Clean recent git + div64_generic_patch.txt:
> make omap5912osk_config
> make
> ll u-boot.bin
... 100016 ... u-boot.bin
> ll lib_generic/libgeneric.a
... 106208 ... lib_generic/libgeneric.a
> arm-elf-ar -t lib_generic/libgeneric.a
bzlib.o
bzlib_crctable.o
bzlib_decompress.o
bzlib_randtable.o
bzlib_huffman.o
crc32.o
ctype.o
display_options.o
div64.o
ldiv.o
sha1.o
string.o
vsprintf.o
zlib.o
>
next prev parent reply other threads:[~2007-08-01 17:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 5:38 [U-Boot-Users] ARM missing __udivdi3 in lib_arm or fix 64bit division in nand_util.c? Dirk Behme
2007-07-31 8:17 ` Håvard Skinnemoen
2007-07-31 19:26 ` Dirk Behme
2007-07-31 20:27 ` Wolfgang Denk
2007-08-01 17:55 ` Dirk Behme [this message]
2007-08-01 20:14 ` Wolfgang Denk
2007-08-01 20:15 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B0C928.3020001@googlemail.com \
--to=dirk.behme@googlemail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.