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

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

[avr-gcc-list] Re: Why is gcc promoting on an unsigned char?


From: J.C. Wren
Subject: [avr-gcc-list] Re: Why is gcc promoting on an unsigned char?
Date: Tue, 23 Dec 2003 01:08:51 -0500
User-agent: KMail/1.5.4

OK, part of that was my fault, I had "i << 1" instead of "1 << i".  But 
nonetheless, we still see some extra code at 0x94, 0x9c, 0xa0, and 0xa4.  The 
compiler should be able to foresee the type of 'data', and not promote the 
intermediate results, right?

        --jc

      loop_until_bit_is_clear (CLKPIN, CLK);     // Receive first databit
  80: c8 99          sbic  0x19, 0  ; 25
  82: fe cf          rjmp  .-4         ; 0x80
      data |= (bit_is_set (DATAPIN, DATA) ? (1 << i) : 0);
  84: 33 27          eor   r19, r19
  86: c9 9b          sbis  0x19, 1  ; 25
  88: 0b c0          rjmp  .+22        ; 0xa0
  8a: 97 2f          mov   r25, r23
  8c: 86 2f          mov   r24, r22
  8e: 04 2e          mov   r0, r20
  90: 02 c0          rjmp  .+4         ; 0x96
  92: 88 0f          add   r24, r24
  94: 99 1f          adc   r25, r25
  96: 0a 94          dec   r0
  98: e2 f7          brpl  .-8         ; 0x92
  9a: 82 2b          or r24, r18
  9c: 93 2b          or r25, r19
  9e: 02 c0          rjmp  .+4         ; 0xa4
  a0: 93 2f          mov   r25, r19
  a2: 82 2f          mov   r24, r18
  a4: 28 2f          mov   r18, r24
      loop_until_bit_is_set (CLKPIN, CLK);
  a6: c8 9b          sbis  0x19, 0  ; 25
  a8: fe cf          rjmp  .-4         ; 0xa6
  aa: 4f 5f          subi  r20, 0xFF   ; 255
  ac: 48 30          cpi   r20, 0x08   ; 8
  ae: 40 f3          brcs  .-48        ; 0x80
   }

On Tuesday 23 December 2003 00:58 am, J.C. Wren wrote:
>       In this sample of code below, both i and data are defined as unsigned
> char. For some reason, GCC is effectively promoting i and data to an int
> for the operations.  The register tracking then fails to realize that it
> already has r18 loaded at 0x98, and moves r24 back to r18, inspite of
> having just moved r18 to r24.
>
>       By casting the (i << 1) to unsigned char, I can eliminate one 
> instruction,
> but no amount of casting can further reduce out the promotion to int side
> effects.
>
>       --jc
>
>
>       data |= (bit_is_set (DATAPIN, DATA) ? (i << 1) : 0);
>   80: 33 27          eor   r19, r19
>   82: c9 9b          sbis  0x19, 1  ; 25
>   84: 07 c0          rjmp  .+14        ; 0x94
>   86: 84 2f          mov   r24, r20
>   88: 99 27          eor   r25, r25
>   8a: 88 0f          add   r24, r24
>   8c: 99 1f          adc   r25, r25
>   8e: 82 2b          or r24, r18
>   90: 93 2b          or r25, r19
>   92: 02 c0          rjmp  .+4         ; 0x98
>   94: 93 2f          mov   r25, r19
>   96: 82 2f          mov   r24, r18
>   98: 28 2f          mov   r18, r24
>
> By casting the (i << 1) to unsigned char, I can eliminate one instruction
>
>       data |= (bit_is_set (DATAPIN, DATA) ? (unsigned char) (i << 1) : 0);
>   80: 33 27          eor   r19, r19
>   82: c9 9b          sbis  0x19, 1  ; 25
>   84: 06 c0          rjmp  .+12        ; 0x92
>   86: 84 2f          mov   r24, r20
>   88: 88 0f          add   r24, r24
>   8a: 99 27          eor   r25, r25
>   8c: 82 2b          or r24, r18
>   8e: 93 2b          or r25, r19
>   90: 02 c0          rjmp  .+4         ; 0x96
>   92: 93 2f          mov   r25, r19
>   94: 82 2f          mov   r24, r18
>   96: 28 2f          mov   r18, r24



reply via email to

[Prev in Thread] Current Thread [Next in Thread]