[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] Program Memory
From: |
Nils Kristian Strom |
Subject: |
[avr-gcc-list] Program Memory |
Date: |
10 Apr 2002 13:34:11 +0200 |
Hi!
I have a feeling that avr-gcc dislikes program memory. I have tried
different approaches to make avr-gcc know that a variable is const, so
that it can save RAM.
I have searched for information about this topic, and my conclusion is
that gcc ALWAYS puts everything in SRAM. Unless, of course, the
attribute progmem directive is used. In this case, avr-gcc puts the
contents in Flash, and one MUST use the various progmem.h macros to
access the variable contents.
Please, tell me that this is not the case ;-(
The more recent AVR devices have a lpm instruction that is almost as
flexible as ld. Is there work going on to try to make the compiler more
elegant with regards to the different memories - at least for the newer
devices ?
As an example
const unsigned char foo = 0x12;
void foobar( unsigned char ch ){ asm( "nop" ); }
int main( void ) {
foobar( foo );
}
gives the following assembly output: (avr-objdump -S)
void foobar( unsigned char ch ){ asm( "nop" ); }
96: cf 93 push r28
-- snip --
foobar( foo );
c8: 80 91 60 00 lds r24, 0x0060
cc: 0e 94 4b 00 call 0x96
The optimal assembly would clearly be
ldi r24, 0x12
call 0x96
Changing the declaration to
const unsigned char __attribute__ ((progmem)) foo = 0x12;
puts foo in program memory, but the main() assembly output is
foobar( foo );
ca: 80 91 54 00 lds r24, 0x0054
ce: 0e 94 4c 00 call 0x98
0x0054 is foo's address in program memory.
Regards
Nils
avr-gcc-list at http://avr1.org
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [avr-gcc-list] Program Memory,
Nils Kristian Strom <=