[avr-gcc-list] globals vs structures

[Marlin Unruh]

I never thought about some of the issues you have presented. I was having
some problem with not using 'volatile' variables in regards to interrupts. I
also compiled the code with Volker Oth's 2.95 and the problem was identical
as with 3.1. All I did was group the timing variables together into a
structure, changed the syntax to reference the structure and it worked. I am
currently using only 210 bytes of SRAM of 512. I assume the stack works from
0x1ff -> 0x1fe..... on the 8515. I suspect your answer 3. is right.

I general look at the *.lst files and altering my 'C' style of writing to
produce more efficient code. I try to keep the 'pushes' and 'pops' down, if
possible. Sometimes just changing the order that variable are worked with
helps.

Regards,
Marlin

-----Original Message-----
From: Larry Barello [mailto:address@hidden
Sent: Friday, March 30, 2001 8:06 AM
To: Marlin Unruh
Cc: AVR GCC List
Subject: Re: [avr-gcc-list] AVR+gcc and CAN-bus


It is hard to say what the problem is.  I have never noticed had any issues
of structs vs individual statics/globals on code stability.  Code size is
another matter.  Dereferencing through a pointer is very efficient on GCC.
Some possibilities for your problems:

1. If you are using the latest snapshot (3.1) -O3 is broken.

2. you (or the compiler) might have some issues with things being/not being
'volatile' between the interrupt handler and the main code.  In other
words, you have to be aware of things changing w/o the compiler knowing
(e.g. an interrupt handler modifying a global variable used by main() or a
subroutine) because the compiler can optimize repeat accesses to variables
out of existence.  This also applied to subroutines that return stuff -
both real and inline.

3. by changing the access method you might have simply shifted timing away
from some race condition.

4. For random events, the stack is always suspect.  You gave no hints on
how you changed your code... Perhaps your stack needs went down?