[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Generating code using sbis, sbic

From: David Brown
Subject: Re: [avr-gcc-list] Generating code using sbis, sbic
Date: Fri, 19 Aug 2005 10:15:37 +0200

I'm far from convinced that integer promotion on an 8-bit AVR is an overall
win (except, perhaps, in terms of the time and effort it would take to
change the compiler to avoid it!).  I can see that if one function calls a
"char" function, and uses the result as an integer, then this saves the
callee doing the promotion.  But how often does that occur in real programs?
Carefully written AVR code makes heavy use of "unsigned char" (or the
programmer's favourite typedef'ed equivilent) precisely because it is the
fastest and most compact way to store a small number.  About the only
regularly occurances I can think of when a function would call a "char"
function and have to use the result as an integer is when it is used for an
if() or a switch().  Code such as "if(test1()) ..." ignores the high byte
anyway, while code such as "switch (test1())..." clears the high byte
explicitly, despite ignoring it in the generated code.

Perhaps I'm being overly fussy, or perhaps there is code usages that I
haven't thought of where integer promotion is a good idea, or perhaps
changing things would be too much work due to either standards requirements,
or fitting in with the rest of gcc (on targets which can work directly with
"ints", then integer promotion is probably a clear win), but I think this
should be classified as a "missed optomisation opportunity".  (In general,
avr-gcc produces excellent code, for which I am very grateful - I just enjoy
nit-picking :-)

Regarding the "return 0" issue, I guess that's something to look into, since
it must occur regularly.  In the meantime, using

    #define zero ({ unsigned char z; asm(" ldi %0, %1" : "=r" (z) : "M"
(0) ); z ; })

and replacing "return 0" with "return zero" gives good code in the function,
although it messes up the inlined version somewhat.

Best regards,


----- Original Message -----
From: "Joerg Wunsch" <address@hidden>
To: <address@hidden>
Sent: Thursday, August 18, 2005 11:28 PM
Subject: Re: [avr-gcc-list] Generating code using sbis, sbic

"David Brown" <address@hidden> wrote:

> Hardly optimal (does the result really have to be promoted to an
> integer?), but not bad.

That integer promotion is a feature, I remember an explanation from
Marek (long ago).  It has been added so the caller could more easily
use word operations when needed, as he can rely on the callee to
16-bit expand the result.  For that reason, it's much more efficient
to declare a function returning an 8-bit value as `unsigned char'
instead of `char' (which is signed by default in AVR-GCC), as
otherwise the 16-bit promotion would even include a sign extension,
instead of just zeroing r25.

>  The generated code for test1 is extraordinary:

This has recently been discussed and analyzed, I don't remember
exactly where, perhaps it wasn't here but on avrfreaks.net.  Someone
could track it down to a point where any literal 0 returned by a
function triggers this poor optimization behaviour.  This seems to be
the case in your situation as well.  Likewise, if you inline the
function, this disappears immediately, as no real function return
value is needed but instead the compiler can perform the actual
operation that was intented by your function return value immediately

It would be interesting (Björn?) whether GCC 4.x compiled better code
for this.

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

AVR-GCC-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]