Yes, it's a known behavior, that the optimization delays popping function
arguments from stack. This way, there is only one single SP correction
at the end of a function instead of several.
I noticed it when having several SPRINTF calls on the 1232, which has
only 256 bytes ram - I got immediate stack overflows.
besides the increased stack usage, it will break compiler intrinsics
like the __BICs as it is outside C language and therefore not considered
when doing the optimizations
The solution is to cover the function call in a code block.
do { function(); } while(0);
This way, the stack is corrected at the end of the code block.
And no additoinal code is generated by the 'loop'.
JMGross
----- Ursprüngliche Nachricht -----
Von: Alex Shibakov
Gesendet am: 31 Dez 2010 17:26:57
Hi everybody!
I noticed that when I use __BIC_SR_ISR in an interrupt handler right
after calling a function and immediately before returning from the
interrupt handler, the optimizer delays popping the function's
arguments off the stack. In this case __BIC_SR_ISR is useless since it
simply changes a value on the stack at a fixed offset, which is now in
the wrong place.
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
