On Mon, Nov 28, 2011 at 6:38 AM, Paulo Marques <pmarq...@grupopie.com> wrote:
> [...]
> Does the problem still occur if you assign the variables later and not
> at declaration time, i.e., something like:
>
> unsigned char status, data;
> volatile static int slot = SEARCHING;
>
> status = UCSR0A;
> data = UDR0;
>
> I don't know from memory if the creation of local variables that are not
> [...]
The problem remains if I split the declaration and assignment of the variables:
ISR(USART0_RX_vect)
{
uint8_t status, data;
static int16_t slot = SEARCHING;
status = UCSR0A;
data = UDR0;
if (status & 0x10) {
...
ISR(USART0_RX_vect)
{
2da: 1f 92 push r1
2dc: 0f 92 push r0
2de: 0f b6 in r0, 0x3f ; 63
2e0: 0f 92 push r0
2e2: 11 24 eor r1, r1
2e4: 2f 93 push r18
2e6: 3f 93 push r19
2e8: 4f 93 push r20
2ea: 8f 93 push r24
2ec: 9f 93 push r25
uint8_t status, data;
static int16_t slot = SEARCHING;
status = UCSR0A;
data = UDR0;
2ee: 4c b1 in r20, 0x0c ; 12
if (status & 0x10) {
2f0: 5c 9b sbis 0x0b, 4 ; 11
2f2: 18 c0 rjmp .+48 ; 0x324 <__vector_18+0x4a>
if (slot == SEARCHING) {
2f4: 80 91 12 01 lds r24, 0x0112
2f8: 90 91 13 01 lds r25, 0x0113
2fc: 2f ef ldi r18, 0xFF ; 255
2fe: 8e 3f cpi r24, 0xFE ; 254
300: 92 07 cpc r25, r18
302: 89 f1 breq .+98 ; 0x366 <__vector_18+0x8c>
}
...
What is it about this construct that makes the compiler feel free to reorder ?
I assume this must be a very specific use case I've tripped over, if
volatiles were being reordered wholesale in 4.6.2, I'd expect there to
be many, many problems surfacing.
> And why is the "slot" variable volatile? It seems there is no reason for
> it and it makes the code a lot worse...
You are correct - it was a hangover from some debug while I was
looking into this problem.
--
Andy
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
