avr-gcc-list
[Top][All Lists]
Advanced

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

AW: [avr-gcc-list] Program Memory


From: Stumpf Michael
Subject: AW: [avr-gcc-list] Program Memory
Date: Fri, 12 Apr 2002 08:39:11 +0200

Hi,

here it shows up where AVR-gcc origins from, namely a compiler for larger machines
where ram is cheap and everything resides in ram.

But - when compiling the small example given
my AVR-gcc just gives the desired code.
Doing that by command line here's my call

avr-gcc.exe %1 -mcall-prologues -v -S -fverbose-asm -fsigned-char -save-temps -O3 -IE:\compiler\AVRgcc\avr\include

/* prologue: frame size=0 */
        ldi r28,lo8(__stack - 0)
        ldi r29,hi8(__stack - 0)
        out __SP_H__,r29
        out __SP_L__,r28
/* prologue end (size=4) */
        ldi r24,lo8(18)        
        rcall foobar
/* epilogue: frame size=0 */
__stop_progIi__:
        rjmp __stop_progIi__
/* epilogue end (size=1) */


Another hint - if you just want named constants why not use enumerations:

 enum { foo = 0x12; }

regards
Michael


> -----Ursprüngliche Nachricht-----
> Von: Nils Kristian Strom [mailto:address@hidden]
> Gesendet: Mittwoch, 10. April 2002 13:34
> An: AVR-GCC List
> Betreff: [avr-gcc-list] Program Memory
>
>
> 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
>


reply via email to

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