Re: [avr-gcc-list] Avr-gcc versions comparison.

[Bruce D. Lightner]

Joerg Wunsch wrote:

"Bruce D. Lightner" <address@hidden> wrote:

  

While you are "testing", have you checked the code quality for the
I/O "bit test" logic in avr-gcc v4.1.2?
    

Dmitry has taken responsibility for the math library code in avr-libc.
I don't think he'll be able to tell you much about GCC's code
generation...
  

My mistake.  I thought that I had remembered that Dmitry worked on the AVR-specific code generator logic, but maybe that was long, long ago.  So, who's the "expert" now?

I suspect that the degenerate behavior with "return 0" is related to some "generic" GCC "subroutine return" optimization, and the "trick" will be to get GCC to stop "optimizing" this *just* for "avr-gcc".  The "wonderful" optimization is likely destroying the information that allows the AVR-specific code generation logic to use the I/O bit test instructions.

The bad news is that I have found that this kind of code construct (i.e., test an I/O bit and then return "0" or "false") is quite common in embedded AVR code.

Regarding your bit test pessimizations, it might be worth opening a
GCC bug report, but still, it would need some GCC developer to track
that down, and eventually fix it...  For the time being, I've seen
better results by turning bit tests into inline functions (return type
"bool").
  

It tested just that, and it made no difference in my previously mentioned "regression tests".  But, I'm not surprised.  I suspect that "bool" true/false is the same as 0/1, once we get to the level of machine code.

Why did you think that "bool" would make a difference?  You want to "inline" the function, but that is just removing the "return 0" in exchange for using extra program space.  A fine idea in theory, but in a resource-constrained embedded application, not usually an option!

Which is why this degenerate behavior (not seen with "avr-gcc 2.9.5") is so irritating.  The AVR instruction set gives us the tools to create very compact, fast machine code, but "avr-gcc" just seems to keep getting worse at using the basic "tools"! :-)

Best regards,

Bruce

-- 
 Bruce D. Lightner
 Lightner Engineering
 La Jolla, California
 Voice: +1-858-551-4011
 FAX: +1-858-551-0777
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/