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

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

Re: [avr-gcc-list] Extremly confusing behaviour... (Suspect compiler?, o


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Extremly confusing behaviour... (Suspect compiler?, optimization error?)
Date: Wed, 14 May 2003 21:42:01 +0200
User-agent: Mutt/1.2.5i

As Mike Panetta wrote:

> Please explain to me why the return value needs to be declared
> volatile?  That makes no sense, ...

You are right in that, and i didn't notice from the large posting you
wrote that your actual problem was about a return value.

>                       retval = srf08_read(1, 0, pingdata, 2);
>      1fe:     65 e0           ldi     r22, 0x05       ; 5
>      200:     c6 2e           mov     r12, r22
>      202:     d1 2c           mov     r13, r1
>      204:     cc 0e           add     r12, r28
>      206:     dd 1e           adc     r13, r29
>      208:     02 e0           ldi     r16, 0x02       ; 2
>      20a:     10 e0           ldi     r17, 0x00       ; 0
>      20c:     20 e0           ldi     r18, 0x00       ; 0
>      20e:     30 e0           ldi     r19, 0x00       ; 0
>      210:     a6 01           movw    r20, r12
>      212:     60 e0           ldi     r22, 0x00       ; 0
>      214:     81 e0           ldi     r24, 0x01       ; 1
>      216:     0e 94 9c 04     call    0x938
>                       PORTA &= ~(_BV(PA1));
>      21a:     d9 98           cbi     0x1b, 1 ; 27
>                       PORTB = retval;
>      21c:     68 bb           out     0x18, r22       ; 24
>               } while (retval != 2);
>      21e:     60 17           cp      r22, r16
>      220:     71 07           cpc     r23, r17
>      222:     82 07           cpc     r24, r18
>      224:     93 07           cpc     r25, r19
>      226:     71 f6           brne    .-100           ; 0x1c4

The return value is used perfectly here.  Apparently, your srf08_read()
function returns a 32-bit int value, passed up in r22...r25.  It is
compared quite fine against the literal value 2 that has been stored
previously in r16...r19.

However, i think there's a bug in the code generation here (and sorry
Marek, for Cc'ing you again ;-): according to the register usage
description, r18 and r19 belong to the list of registers that might be
clobbered by a called function.  It seems to me that the optimizer
attempted to re-use the value 2 that was already necessary to call
srf08_read(), but didn't notice that part of the registers are not
being preserved.
-- 
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]