All of lore.kernel.org
 help / color / mirror / Atom feed
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
 >

  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.