Re: [avr-chat] Missed Optimisation ?

[Michael Hennebry]

On Fri, 4 Mar 2011, Pertti Kellomäki wrote:

> On Fri, Mar 4, 2011 at 12:05 AM, Michael Hennebry
> <address@hidden> wrote:
> > avr-gcc isn't obligated to produce code for anything that is not an AVR.
>
> Herein lies the rub.
>
> If you think of avr-gcc primarily as a tool that maps C programs to
> the specific chips manufactured by Atmel, then the compiler indeed has
> complete freedom to do whatever it wants as long as the external
> behavior of the chip (i.e. the physical pins) is in accordance with
> the source program.

I had.

> On the other hand, if you think of avr-gcc primarily as a C compiler
> which just happens to target the AVR architecture, then it needs to
> stick to the C standard even in cases where it would not be necessary
> for the Atmel chips. I would be surprised if there were no soft core
> implementations of the AVR architecture on FPGA, so a non-Atmel AVR is
> not such a far fetched idea.

I'd forgotten about them.
They've been mentioned on AVR-Freaks.
On further consideration, my logic applies even in this case.
If the compiler can allocate an ordinary variable there,
it even applies to external memory.
Compiler-allocated variables make no sense in an IO space.

> There are also shades of gray in between the two views of avr-gcc. As
> noted, the behavior wrt. sbi probably violates the ANSI standard, yet
> nobody gets upset because of the convenience value offered.

The replacement sequence I mentioned is exactly equivalent
unless one is using an "AVR" device that exports the I bit in SREG.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."