Re: [avr-gcc-list] Generating code using sbis, sbic

[David Brown]

Hi,

Yes, I understand about integer promotion (although I have never been clear
on all the cases when it applies).  However, as far as I understand it,
there is nothing in the C standard that says you *actually* have to promote
to integer - just that the code should work as though it had been promoted.
If all the C code that handles the results of this function only look at the
low byte, then the high byte can be ignored.  I'm sure it's possible to
write some horrible code that actually relies on char -> int promotion
occuring in a function result, but I don't think it would be a problem for
most sane code.  A compiler flag to turn off integer promotion on the AVR
port would be a definite boost to code quality (on 16-bit and 32-bit
targets, however, it could well be a net loss - it would only help on a
target which can't work with integers properly).  I guess the other trick,
especially on a Tiny (using no library function), would be to compile
with -mint8.

Anyway, even with the integer promotion, the code is not optimal - is there
no peephole optimisation that would move the "ldi r25, hi8(1)" above the
test?  Better code would be:
    test2:
        clr r25            // If ANSI insists...
        clr r24
        sbic 54-0x20,1
            inc r24
        ret

Using c++ like this is an interesting idea - I haven't tried c++ on the AVR
as yet.  I guess if you collect some useful little classes like this in a
single header (with the member functions inlined), it should be quite
efficient.

But my real gripe is not so much the code generated for test2 (not optimal,
but not too bad), but with the code generated for test1, which is a complete
mess.

Regards,

David



----- Original Message -----
From: "Haase Bjoern (PT-BEU/EMT) *" <address@hidden>
To: "David Brown" <address@hidden>; <address@hidden>
Sent: Thursday, August 18, 2005 7:17 PM
Subject: AW: [avr-gcc-list] Generating code using sbis, sbic


> David Brown wrote
But the generated code for test2 itself is:
    test2:
        sbis 54-0x20,1
        rjmp .L9
        ldi r24, lo8(1)
        ldi r25, hi8(1)
        ret
    .L9:
        ldi r24, lo8(0)
        ldi r25, hi8(0)
        ret

Hardly optimal (does the result really have to be promoted to an
integer?),
but not bad.  The generated code for test1 is extraordinary:

Unfortunately: This integer promotion is prescribed by the c standard.

If you are using c++ you could overcome it by defining a class uint8_c
and by
Specifying this type as return parameter:


#include <inttypes.h>

class uint8_c {
  public:

  uint8_c (uint8_t initval)
  {
    value = initval;
  };

  uint8_c
  operator= (uint8_t initval)
  {
    value = initval;
    return *this;
  };

  operator uint8_t (void)
  {
    return value;
  };

  private:
  uint8_t value;
};


uint8_c
test (void)
{
  return 1;
}

uint8_t
Test (void)
{
  return 1;
}

Yields:


.type _Z4testv, @function
_Z4testv:
ldi r24,lo8(1)
ret


.size _Z4testv, .-_Z4testv
.global _Z5test2v
.type _Z5test2v, @function
_Z5test2v:
ldi r24,lo8(1)
ldi r25,hi8(1)
ret



_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list