[U-Boot] Discussion topics / issues

[Albert ARIBAUD]

Hi Jeroen,

On Fri, 10 Oct 2014 22:40:48 +0200, Jeroen Hofstee
<dasuboot at myspectrum.nl> wrote:

> Hello Albert,
> 
> On 10-10-14 21:51, Albert ARIBAUD wrote:
> > Hi Jeroen,
> >
> > On Fri, 10 Oct 2014 18:09:19 +0200, Jeroen Hofstee
> > <jeroen at myspectrum.nl> wrote:
> >
> >> Hello Marek,
> >>
> >> On 10-10-14 16:26, Marek Vasut wrote:
> >>> On Friday, October 10, 2014 at 04:04:40 PM, Jeroen Hofstee wrote:
> >>>> Hello Wolfgang,
> >>>>
> >>>> On 10-10-14 14:22, Wolfgang Denk wrote:
> >>>>>> It does not mention puts() vs. printf(), if it is indeed meant to be
> >>>>>> u-boot policy.
> >>>>> This is not just U-Boot philosophy, but something that I would
> >>>>> consider a matter of course when writing code - using the appropriate
> >>>>> tools for the task at hand.  If all you want to do is sendout a
> >>>>> constant string to the utput device, there is no need to invoke a
> >>>>> function that provides fancy formatting options.
> >>>>>
> >>>>> Don't we always try to use the smallest, most efficient tool that is
> >>>>> suited for a task?
> >>>> calling printf("%s\n", "string") gets translated into puts by the
> >>>> compiler. There should be no difference in the binary
> >>> Is this LLVM specific or does GCC do that too ? This is interesting information.
> >> I was talking about gcc, it has been doing such since ages ago
> >> (unless you purposely disable it). clang does it as well.
> > That's a good thing, but generally speaking, I think that just because
> > the compiler is being clever doesn't mean we are allowed to rely on
> > that, because if we do take a habit of relying on the compiler being
> > clever, two things will happen:
> 
> Why can't this be relied on, I gave up digging if this is a gcc 3 or 2
> feature. It is old at least, museum stuff if it is not supported.

It's a general habit I have of never assuming anything is forever.

> > 1) we will keep thinking the compiler is being clever even when for
> > some reason it will stop being clever -- for instance, because someone
> > decided to disable the clever feature;
> 
> If you ask to disable it, it is good if it does so, don't see a problem
> with that. Anyway, it is not an u-boot issue, anything below -O2 is not
> supported anyway.

There is no problem if the person disabling the feature is also the one
doing assumptions on the feature state. Problems arise when these are
two different persons, because the one relying on the feature might not
know or notice that the other one disabled it.

> > 2) we will begin thinking the compiler is clever in situations where it
> > never has and never will.
> 
> I would almost take this as an insult, I hope u-boot folks know or at
> least check before they assume a compiler does XYZ. And yes
> compilers will replace simple printf call with their simpler equivalent
> and has been doing so for quite a while (and that is an understatement).

I certainly did not intend this as an insult. But no, if I personally
had encountered a printf("%s\n", s) in the course of some development, I
would not have gone and looked whether the compiler might turn it into a
puts(s). I'd have assumed it does not, because assuming so was the
fastest and safest approach.

Don't misunderstand me: I'm quite pleased that gcc and LLVM do that.
And I'm also quite convinced that it's a good thing -- actually, I did
start by saying so. The problem I see is not specifically with the
printf()/puts() case, it is with the *general* assumption that a
compiler is clever -- and again, I did start my opinion with
"generally speaking".

The problem I see is that a developer will not necessarily go and test
every single thing that the compiler *might* be clever enough to do
(or dump enough not to); a developer will assume some of it, and
whenever he assumes, he should assume a dumb compiler.

> > IMO, a quick cost/benefit comparison of choosing between manually
> > turning printf() into puts whenever doable vs letting the compiler do
> > the changes automatically, the manual option wins -- it's bit like
> > Pascal's Wager: you don't lose much but you can only win.
> 
> No it is the other way around; why on earth do you want demand
> patch submitters to make changes which result in the exactly same
> binary; you waste time of reviewers / patch submitter and it doesn't
> serve a goal.
> 
> So to turn it around: just use printf: "you don't lose much but you
> can only win."

In the specific case of printf()/puts(), a wager is meaningless since
the compiler capability is already known. Therefore, there is no reason
to "wager on 'just us[ing] printf'"; there is reason to "just use
printf because it is known to turn into puts() if possible".

But please remember that I considered the wager *only* in a *general*
case where a developer could replace some code with some other, more
efficient code, and does *not* know whether the compiler could be clever
enough to do the replacement by itself. The developer /might/ check the
compiler... or he might not check, and instead, wager on the compiler
being clever or dumb; and in this *general* case, he should wager on a
dumb compiler.

Of course, if the case is specific and known to him, i.e. he already
knows whether the compiler will be clever or dumb in that specific case,
then there is *no* wager to be done; the developer should just act on
his knowledge (and check it again from time to time, but that's somewhat
beside the point).

> Regards,
> Jeroen

Amicalement,
-- 
Albert.