[Top][All Lists]

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

Re: [avr-chat] Missed Optimisation ?

From: Michael Hennebry
Subject: Re: [avr-chat] Missed Optimisation ?
Date: Fri, 4 Mar 2011 10:22:31 -0600 (CST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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."

reply via email to

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