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) *" <[EMAIL PROTECTED]> To: "David Brown" <[EMAIL PROTECTED]>; <avr-gcc-list@nongnu.org> 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 AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list