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

Reply via email to