From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Mon, 8 Sep 2008 13:27:05 +0200
Subject: [U-Boot] CFG_64BIT_xxx and friends
In-Reply-To: <20080908130046.63a779ba@hskinnemo-gx745.norway.atmel.com>
References: <200809041609.26474.matthias.fuchs@esd-electronics.com>
	<200809080943.45406.sr@denx.de>
	<20080908130046.63a779ba@hskinnemo-gx745.norway.atmel.com>
Message-ID: <200809081327.06175.matthias.fuchs@esd-electronics.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Here is the U-Boot size for the PLU405 board (405EP-based) with
and without

#define CFG_64BIT_VSPRINTF
#define CFG_64BIT_STRTOUL
.

without:
# ppc_4xx-size u-boot
   text    data     bss     dec     hex filename
 289568   17532  301312  608412   9489c u-boot

with 64bit format handling:
# ppc_4xx-size u-boot
   text    data     bss     dec     hex filename
 291368   17532  301312  610212   94fa4 u-boot

So the difference is 1800 bytes on this architecture.

Matthias

On Monday 08 September 2008 13:00, Haavard Skinnemoen wrote:
> Stefan Roese <sr@denx.de> wrote:
> > > Seriously: How much of code size are we talking about? And activating
> > > / deactivation the feature is  not  so  trivial  as  it  affects  the
> > > printf() format specifiers we have to use.  
> > 
> > I'm with Wolfgang here and think it would be best to unconditionally support 
> > the 64bit printf format too.
> 
> Would be nice to see some numbers first though. I suspect there won't
> be much difference, but it could be the printf() implementation does
> something stupid, and it's much easier to tell when the config symbol
> is still in place.
> 
> Haavard
> 
>