User`s guide

C for DSP56800E
User Stack Allocation
121Targeting MC56F83xx/DSP5685x Controllers
4. You must not overwrite the compiler’s stack allocation by decreasing the SP into
the compiler allocated stack space.
Point 1 above is required when you think about an if-then-else type statement. If one
branch of a decision point modifies the SP one way and the other branch modifies SP
another way, then the value of the SP is run-time dependent, and the compiler is
unable to determine where stack-based variables are located at run-time. To prevent
this from happening, the User Stack Allocation feature traverses the control flow
graph, recording the inline assembly SP modifications through all program paths. It
then checks all control flow merge points to make sure that the SP has been modified
consistently in each branch converging on the merge point. If not, a warning is emitted
citing the inconsistency.
Once the compiler determined that inline SP modifications are consistent in the
control flow graph, the SP’s offsets used to reference local variables, function
arguments, or temps are fixed up with knowledge of inline assembly modifications of
the SP. Note, you may freely allocate local stack storage:
1. As long as it is equally modified along all branches leading to a control flow
merge point.
2. The SP is properly aligned. The SP must be modified by an amount the compiler
can determine at compile time.
A single new pragma is defined.
#pragma check_inline_sp_effects
[on|off|reset]
will generate a warning if the user specifies an inline assembly
instruction which modifies the SP by a run-time dependent amount. If the pragma is
not specified, then stack offsets used to access stack-based variables will be incorrect.
It is the user’s responsibility to enable
#pragma check_inline_sp_effects, if
they desire to modify the SP with inline assembly and access local stack-based
variables. Note this pragma has no effect in function level assembly functions or
separate assembly only source files (
.asm files).
In general, inline assembly may be used to create arbitrary flow graphs and not all can
be detected by the compiler.
For example:
REP #3
ADDA #2,SP
This example would modify the SP by three, but the compiler would only see a
modification of one. Other cases such as these might be created by the user using
inline jumps or branches. These are dangerous constructs and are not detected by the
compiler.