public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
Date: Wed, 08 Jul 2009 16:29:18 -0500	[thread overview]
Message-ID: <4A550FAE.30500@freescale.com> (raw)
In-Reply-To: <20090708212401.67CD2832E416@gemini.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

  reply	other threads:[~2009-07-08 21:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-06  9:48 [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants Stefan Roese
2009-07-06 11:17 ` Wolfgang Denk
2009-07-06 15:39   ` Stefan Roese
2009-07-08 20:01     ` Wolfgang Denk
2009-07-08 21:11       ` Scott Wood
2009-07-08 21:24         ` Wolfgang Denk
2009-07-08 21:29           ` Scott Wood [this message]
2009-07-08 21:57             ` Wolfgang Denk
2009-07-08 22:27               ` Scott Wood
2009-07-09  4:57                 ` Stefan Roese
2009-07-09  7:41                 ` Wolfgang Denk
2009-07-08 22:18         ` Jerry Van Baren
2009-07-08 22:27           ` Scott Wood
2009-07-09  5:00           ` Stefan Roese
2009-07-09 12:24             ` Jerry Van Baren
2009-07-09 12:48               ` Stefan Roese
2009-07-09 13:02                 ` Jerry Van Baren
2009-07-09  4:54       ` Stefan Roese
2009-07-17 18:44         ` 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=4A550FAE.30500@freescale.com \
    --to=scottwood@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox