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

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

Re: [avr-gcc-list] Use of variables and programming in avr-gcc


From: J Wunsch
Subject: Re: [avr-gcc-list] Use of variables and programming in avr-gcc
Date: Thu, 1 Mar 2001 15:24:54 +0100 (MET)

address@hidden (Robert Rozman) wrote:

> - do recomendations from mentioned application note apply also for
> avr-gcc ? if not, what should be done differently ?

I just noticed this application note, but will take some time to read
it more thoroughly.  Basically, the coding rules should be the same
regardless of the compiler used, although it might be that gcc uses
different registers internally for some things.

> - what declaration keywords are really implemented and what is their
> effect (const, register, volatile, ...) and how exactly to use them ?

`const' is implemented, but in C, it's merely a hint to the compiler
to warn the user when attempts are made (and detected by the compiler)
to write to that variable.  In any case, an (initialized) variable is
created for it, which is basically a waste of space.  Thus, it's
common practice to use a #define for actually defining a constant
value.  (Things are different in C++, where `const' really declares a
constant that doesn't allocate space in the data segment.)

`register' is implemented but should be avoided.  The compiler often
knows much better which variables should be kept in registers.

`volatile' is implemented and is very much required in a
microcontroller environment.  It is used to prevent the compiler from
optimizing access to some variable.  You need this if your variable
can be modified outside the compiler's code flow view, like in an
interrupt routine.

> - is it better to keep SRAM variables in structures - as APP note
> recomends) or not ?

Well, the simplest way to find out is to use their example code, and
try it. :)  I did so, and compiled the C file into assembler source
with `avr-gcc -O3 -S foo.c'.  Here's the result:

main:
/* prologue: frame size=0 */
        ldi r28,lo8(0x25f - 0)
        ldi r29,hi8(0x25f - 0)
        out __SP_L__,r28
        out __SP_H__,r29
/* prologue end (size=4) */
        ldi r30,lo8(global)
        ldi r31,hi8(global)
        ld r24,Z
        subi r24,lo8(-(1))
        st Z,r24
        lds r24,min
        subi r24,lo8(-(1))
        sts min,r24
/* epilogue: frame size=0 */
__stop_progIi__:
        rjmp __stop_progIi__

If you compare this with the generated code in the application note,
you'll see that gcc generates code not identical but very similar.  In
particular, structure elements are accessed through the Z register as
well, while regular variables are accessed through LDS/STS.  (Note
that gcc optimized the entire conditionalizing away, since the
conditional statement after the `if' wasn't used, thus you don't see
the value `60' anwhere in the code.)

> I'd kindly ask for answers in code space and also from speed point of
> view.

See above, it's probably always best to have a look at the generated
assembler code.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden         http://www.interface-systems.de/~j



reply via email to

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