What follows is a pretty typical sequence for a vararg function on the XMEGA. In particular, why does the code generator do the funky double "call" rather than just subtract the right number from the SP? I am guessing this is a left-over code from the early XMEGA stack handling.
Also typical, the compiler loads a second pointer to the stack just to poke out the address of the sprintf buffer - even though the information was already in Z. I see that kind of sequence a lot in my code. I always figured the compiler was making the least expensive choice when deciding to recomputed vs. store a pointer, but now I am not so sure. Finally, I suppose if it was simple it would have been done already: if there are multiple calls to "printf" and friends, the entire sequence of setting up and tearing down the stack occurs over and over again - and that is on top of any setup and teardown performed for the function (say, a buffer on the stack). In general, this kind of code inefficiency doesn't bother me much because I usually factor the routines to minimize the code, and the processor is so blazingly fast I don't care about the cycles. I just noticed this while looking for code sequences that might cause stack corruption. PS. this is the alpha CC1 Eric gave me that corrects the XMEGA SP handling... 122 0098 00D0 rcall . 123 009a 00D0 rcall . 124 009c EDB7 in r30,__SP_L__ 125 009e FEB7 in r31,__SP_H__ 126 00a0 3196 adiw r30,1 127 00a2 ADB7 in r26,__SP_L__ 128 00a4 BEB7 in r27,__SP_H__ 129 00a6 1196 adiw r26,1 130 00a8 ED92 st X+,r14 131 00aa FC92 st X,r15 132 00ac 1297 sbiw r26,1+1 133 00ae 80E0 ldi r24,lo8(__c.6529) 134 00b0 90E0 ldi r25,hi8(__c.6529) 135 00b2 8283 std Z+2,r24 136 00b4 9383 std Z+3,r25 137 00b6 8091 0000 lds r24,Params+6 138 00ba 9091 0000 lds r25,(Params+6)+1 139 00be 8483 std Z+4,r24 140 00c0 9583 std Z+5,r25 141 00c2 0E94 0000 call sprintf_P 142 .LM10: 143 00c6 8DB7 in r24,__SP_L__ 144 00c8 9EB7 in r25,__SP_H__ 145 00ca 0696 adiw r24,6 146 00cc 8DBF out __SP_L__,r24 147 00ce 9EBF out __SP_H__,r25 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
