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

[J.C. Wren]

        This is interesting.  If I declare 'unsigned char zero = 0', and 
replace the 
0 in the : clause with 'zero', it generates the following code.  However, by 
declaring 'const unsigned char zero = 0', it produces the second case.

        This says to me that the compiler does not effectively demote 0 to 
unsigned 
char, even when told to (which may or may not be "legal"), and that the 
optimizer misses an opportunity to remove dead code.

        It's a little surprising that the 'const' keyword makes it worse, as 
one 
could argue that using const is more appropriate than not, in this case.

        --jc

With 'unsigned char zero = 0;'

   for (data = 0, i = 0; i <= 128; i <<= 1)
  7a: 20 e0          ldi   r18, 0x00   ; 0
  7c: 82 2f          mov   r24, r18
   {
      loop_until_bit_is_clear (CLKPIN, CLK);     // Receive first databit
  7e: c8 99          sbic  0x19, 0  ; 25
  80: fe cf          rjmp  .-4         ; 0x7e
      (unsigned char) data |= (unsigned char) ((unsigned char) bit_is_set 
(DATAPIN, DATA) ? i : zero);
  82: c9 9b          sbis  0x19, 1  ; 25
  84: 02 c0          rjmp  .+4         ; 0x8a
  86: 28 2b          or r18, r24
  88: 01 c0          rjmp  .+2         ; 0x8c
  8a: 29 2b          or r18, r25
      loop_until_bit_is_set (CLKPIN, CLK);
  8c: c8 9b          sbis  0x19, 0  ; 25
  8e: fe cf          rjmp  .-4         ; 0x8c
  90: 88 0f          add   r24, r24
  92: 81 38          cpi   r24, 0x81   ; 129
  94: a0 f3          brcs  .-24        ; 0x7e
   }

With 'const unsigned char zero = 0;'

   for (data = 0, i = 0; i <= 128; i <<= 1)
  78: 20 e0          ldi   r18, 0x00   ; 0
  7a: 42 2f          mov   r20, r18
   {
      loop_until_bit_is_clear (CLKPIN, CLK);     // Receive first databit
  7c: c8 99          sbic  0x19, 0  ; 25
  7e: fe cf          rjmp  .-4         ; 0x7c
      (unsigned char) data |= (unsigned char) ((unsigned char) bit_is_set 
(DATAPIN, DATA) ? i : zero);
  80: 33 27          eor   r19, r19
  82: c9 9b          sbis  0x19, 1  ; 25
  84: 05 c0          rjmp  .+10        ; 0x90
  86: 84 2f          mov   r24, r20
  88: 99 27          eor   r25, r25
  8a: 82 2b          or r24, r18
  8c: 93 2b          or r25, r19
  8e: 02 c0          rjmp  .+4         ; 0x94
  90: 93 2f          mov   r25, r19
  92: 82 2f          mov   r24, r18
  94: 28 2f          mov   r18, r24
      loop_until_bit_is_set (CLKPIN, CLK);
  96: c8 9b          sbis  0x19, 0  ; 25
  98: fe cf          rjmp  .-4         ; 0x96
  9a: 44 0f          add   r20, r20
  9c: 41 38          cpi   r20, 0x81   ; 129
  9e: 70 f3          brcs  .-36        ; 0x7c
   }

On Tuesday 23 December 2003 12:18 pm, Neil Johnson wrote:
> Hi,
>
> Of course, it could just be a bug in the GCC optimizer...
>
> Having tracked through the C standard a little bit it does look like an
> oversight: the type of the conditional expression should be unsigned char,
> which together with the unsigned-char'ness of "data" the compiler should
> spot the types in the bitwise OR as "unsigned char OR unsigned char".
>
> BTW, I *hate* ?: operator, version 1 --- using a side-effect in a
> conditional expression.  Yuck :-(  At least with the if..then version it
> is very obvious what your intention is.
>
> Cheers,
> Neil
>
> --
> Neil Johnson :: Computer Laboratory :: University of Cambridge ::
> http://www.njohnson.co.uk          http://www.cl.cam.ac.uk/~nej22
> ----  IEE Cambridge Branch: http://www.iee-cambridge.org.uk  ----