I don't know if this has been covered already, but noe way to save space in interrupt handlers is to inline all the functions they call. Obviously is it not always practical, but if the functions are split out mainly for clarity this can be a big win. The main reason is that if the interrupt handler doesn't call *any* other functions it isn't obligated to save the caller-saves registers if it doesn't use them.
Also, I think someone else wanted to know why things sometimes did/did not get inlined. gcc tries to be clever about this, so if you want the final say, try this: #define NOINLINE __attribute__ ((__noinline__)) #define YESINLINE inline __attribute__ ((__always_inline__)) Make sure to declare the YESINLINE functions static if you don't want a callable copy for external references. Also, as far a general prologue bloat goes: I may have mentioned this before, but I think a lot of it comes from the fact that AVR GCC generates 16 and 32 bit math in parallel instead of series. For example, something like: int32 a, b, c; a = b | c; becomes: lds r24,b lds r25,(b)+1 lds r26,(b)+2 lds r27,(b)+3 lds r18,c lds r19,(c)+1 lds r20,(c)+2 lds r21,(c)+3 or r24,r18 or r25,r19 or r26,r20 or r27,r21 sts a,r24 sts (a)+1,r25 sts (a)+2,r26 sts (a)+3,r27 when it could be: lds r24,b lds r25,c or r24,r25 sts a,r24 ... using only 2 registers instead of 8. None of the load/store instructions set flag bits, so even math with carry can be done this way. I don't think it's a legitimate peephole optimization (though I haven't pondered it deeply) since qualifiers like 'volatile' would prevent the re-ordering of the memory accesses. -- Ben Jackson <[EMAIL PROTECTED]> http://www.ben.com/ _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list