MPLAB C Compiler for PIC24 MCUs and dsPIC DSCs ... - Microchip

16-Bit C Compiler User’s Guide
Acceptable control flow:
asm("cp0 _foo\n\t"
"bra nz, eek\n\t"
"; some assembly\n\t"
"bra eek_end\n\t"
"eek:\n\t"
"; more assembly\n"
"eek_end:" : /* outputs */
: /* inputs */
: "cc");
/* next statement */
This is acceptable, but may not function as expected, (i.e., the next statement is always
executed, regardless of any branch inside the asm statement). See further information
regarding labels in asm statements. Note that the code indicates that the status flags
are no longer valid in this statement by identifying cc as clobbered.
Lables and Control Flow:
Additionally, labels inside assembly statements can behave unexpectedly with certain
optimization options. The inliner may cause labels within asm statements to be defined
multiple times.
Also the procedural aggragator tool (-mpa) does not accept the local label syntax. See
the following example:
inline void foo() {
asm("do #6, loopend");
/* some C code */
asm("loopend: ");
return;
}
This is bad for a number of reasons. First, the asm statements introduce an implied
control flow that the compiler does not know about. Second, if foo() is inlined the label
loopend will be defined many times. Third, the C code could be badly optimized
because the compiler cannot see the loop structure. This example breaks the rule that
the asm statement should not interfere with the program flow; asm("loopend:") will
not always flow to the next statement.
A solution would be to use the local label syntax as described in the “MPLAB ® Assembler,
Linker and Utilties for PIC24 MCUs and dsPIC ® DSCs User’s Guide” (DS51317),
as in the following example:
inline void foo() {
asm("do #6, 0f");
/* some C code */
asm("0: ");
return;
}
The above form is slightly better; at least it will fix the multiply-defined label issue.
However the procedural aggregator tool (-mpa) does not accept the 0: form of label.
DS51284H-page 126 © 2008 Microchip Technology Inc.