Re: [avr-gcc-list] Optimiser bloats code
Hi Wouter, Why? Is this a bug or a feature? Am I doing something wrong or is an u08 return always promoted to an int? This is what the C Language specification says it must do, so that's what gcc does. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Optimiser bloats code
Dave Hylands [EMAIL PROTECTED] wrote: (integer promotion on function return values) Why? Is this a bug or a feature? Am I doing something wrong or is an u08 return always promoted to an int? This is what the C Language specification says it must do, so that's what gcc does. Well, the C language specification is an `as if' rule: the compiler must behave as if it were promoting it to `int'. This leaves it the freedom to not really promote it if it can recognize it's not necessary. However, early in the game of AVR-GCC, those who implemented it thought it would be useful to have the callee already perform the integer promotion, so the caller can use word instructions. In retrospect, this was probably not the most lucky decision, but the ABI is set into stone right now, at least until the day we have to break it for other reasons. That day will be a major version bump for everything. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Optimiser bloats code
Return values are promoted to an int.
Why? Is this a bug or a feature? Am I doing something wrong or is an u08
return always promoted to an int?
You probably already know this, but you could also do:
return PINB 5;
which returns the same answer using the following:
in r24,54-0x20
swap r24
lsr r24
andi r24,0x7
clr r25
ret
Yes I know, (it is written above my example) I wanted to point out how bad
the results is when compiler start to optimise this.
Just curious, is there any faster way to bit invert as in my foo3 example
(see below). It now takes 9 instructions which is good but less is always
better.
A loop requires more instructions and is much slower. Anyone an idea on
smaller bit inversion for just 3 bits? Because if this is the smallest
way, you cant tell the compiler to do so :(
HTH
Wouter
//Force the compiler and voila! Optimal!
//Not bit inverted or bit inverted, the result is the same
uint8_t foo3(void) { //good
e0: 88 27 eor r24, r24
uint8_t temp = 0;
asm volatile(clr %0 : =r (temp) :);
if(PINB (15)) temp |= (12);
e2: 1d 99 sbic0x03, 5 ; 3
e4: 84 60 ori r24, 0x04 ; 4
if(PINB (16)) temp |= (11);
e6: 1e 99 sbic0x03, 6 ; 3
e8: 82 60 ori r24, 0x02 ; 2
if(PINB (17)) temp |= (10);
ea: 1f 99 sbic0x03, 7 ; 3
ec: 81 60 ori r24, 0x01 ; 1
return temp;
}
ee: 99 27 eor r25, r25
f0: 08 95 ret
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
