Hi again,
I did some more testing and found that using
int main (void) {
uint8_t reg;
do {
reg = PINx(I2C_PORT); // macro translates to PIND
6a: 80 b3 in r24, 0x10 ; 16
} while (((uint8_t) ~reg) & I2C_MASK);
6c: 80 95 com r24
6e: 88 71 andi r24, 0x18 ; 24
70: e1 f7 brne .-8 ; 0x6a <main>
produces the intended result. Is it fair to conclude that the ~
operator, applied to an unsigned char, does produce an int as output
instead of the input type?
Could that be considered a bug, or is this in line with the C specification?
Regards,
Christian
On 25/09/14 18:20, Christian Schmidt wrote:
> Hi everyone,
>
> I am currently porting some assembly code to C, using avr-gcc 4.8.3 on
> GNU/linux. While comparing the output I found some strangeness that
> persisted regardless of -Os, -O2 or -O3 optimization settings:
>
> avr-objdump -h -S main.elf (abbreviated)
>
> #include <avr/io.h>
>
> int main (void) {
> unsigned char reg;
> do {
> reg = PIND;
> 38: 80 b3 in r24, 0x10 ; 16
> } while ((~reg) & 0x18);
> 3a: 90 e0 ldi r25, 0x00 ; 0
> 3c: 80 95 com r24
> 3e: 90 95 com r25
> 40: 88 71 andi r24, 0x18 ; 24
> 42: 99 27 eor r25, r25
> 44: 89 2b or r24, r25
> 46: c1 f7 brne .-16 ; 0x38 <main>
> }
>
> All those operations involving R25 are equivalent to NOPs? That's about
> half the instructions in this small example. Are there any compiler
> flags beyond general optimization levels I could set to avoid this?
>
> Please CC: me on replies, as I am not subscribed to the list.
>
> Best regards,
> Christian
>
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
