[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] compilation results with avr-gcc 4.8.3
From: |
Christian Schmidt |
Subject: |
Re: [avr-gcc-list] compilation results with avr-gcc 4.8.3 |
Date: |
Thu, 25 Sep 2014 19:50:06 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 |
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
>