From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 08 Jul 2009 16:29:18 -0500 Subject: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants In-Reply-To: <20090708212401.67CD2832E416@gemini.denx.de> References: <1246873688-25113-1-git-send-email-sr@denx.de> <20090706111759.47700832E416@gemini.denx.de> <200907061739.33498.sr@denx.de> <20090708200123.BBAB3832E416@gemini.denx.de> <4A550B66.1090506@freescale.com> <20090708212401.67CD2832E416@gemini.denx.de> Message-ID: <4A550FAE.30500@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: > Dear Scott Wood, > > In message <4A550B66.1090506@freescale.com> you wrote: >> Note that the overhead of 64-bit printf (assuming the 64-bit >> divide/remainder functions in libgcc aren't pulled in for anything else) >> is 2524 bytes on powerpc (using GCC 4.3.2). That's less than NFS, >> which gets turned on by default (as was brought up recently). :-) > > But compare the functionality... I use 64-bit prints from time to time. I've never used NFS in u-boot. More relevantly, it's obvious if NFS is missing -- it says "Unknown command". It's not always obvious whether (or why) the printf output you're looking at has been corrupted by an incomplete implementation. >> What if we were to invert the option (CONFIG_SYS_NO_64BIT_VSPRINTF) so >> that it would only be disabled on boards at the intersection of tight >> space constraints and a board maintainer who's pretty sure this board >> doesn't need it? There could also be some warning from printf() if %ll >> is used when not supported, and/or it could still check for %ll and pop >> a long long from the varargs but discard the high half. > > And by default we would add CONFIG_SYS_NO_64BIT_VSPRINTF to all board > config files? No, that's the point -- it would require the board maintainer to explicitly say "this board doesn't need this". By default we would provide a correct printf. -Scott