On 09.08.14 05:51, Thomas D. Dean wrote:
Is this a problem with -Os?
Good question. Is the second "if" restored with optimisation off?
It looks like the compiler has decided that cs is always zero in the code
below.
It's nearly midnight here, and I'm viewing the code from down under, but
ISTM that it thinks cs can never be zero.
The cs calculation appears correct.
Yep.
In spi_copy.c
...
uint8_t spi_copy_in(uint8_t *dest, uint8_t *source, unsigned int max_len) {
uint8_t cs;
uint8_t len;
uint8_t *ptr1, *ptr2;
cs = 0;
len = source[0];
if (len > max_len) return 0xff;
ptr2 = &source[1];
do {
cs += *ptr2++;
} while (--len);
if (cs == 0) {
len = source[0] - 1; // do not need the checksum
ptr2 = &source[1];
do {
*ptr1++ = *ptr2++;
} while (--len);
}
return cs;
}
...
# The way I see it:
0000077c <spi_copy_in>:
# len = source[0];
77c: fb 01 movw r30, r22
77e: 20 81 ld r18, Z
# if (len > max_len) return 0xff;
780: 82 2f mov r24, r18
782: 90 e0 ldi r25, 0x00 ; 0
784: 48 17 cp r20, r24
786: 59 07 cpc r21, r25
788: 38 f0 brcs .+14 ; 0x798 <spi_copy_in+0x1c>
# ptr2 = &source[1];
78a: 31 96 adiw r30, 0x01 ; 1
# cs = 0;
78c: 80 e0 ldi r24, 0x00 ; 0
# cs += *ptr2++;
78e: 91 91 ld r25, Z+
790: 89 0f add r24, r25
# while (--len);
792: 21 50 subi r18, 0x01 ; 1
794: e1 f7 brne .-8 ; 0x78e <spi_copy_in+0x12>
# Who took Tom's cheese?
# Does it deduce that cs cannot ever be zero?
796: 08 95 ret
798: 8f ef ldi r24, 0xFF ; 255
79a: 08 95 ret
That looks scary. Which version is it? (Others will ask. ;-)
Erik