SW006012 Microchip Technology, SW006012 Datasheet - Page 123

• Manufacturer Part Number: SW006012
• Description: C COMPILER FOR DSPIC30F FAMILY
• Manufacturer: Microchip Technology
• Type: MPLAB® C30 Compilerr
• Series: PIC24 & DsPICr

Specifications of SW006012

• Supported Families: PIC24, DsPIC30F And DsPIC33F
• Core Architecture: PIC, DsPIC
• Kit Contents: Software And Docs
• Mcu Supported Families: PIC24 MCUs And DsPIC DSCs
• Tool Type: Compiler
• Processor Series: PIC24, dsPIC
• Lead Free Status / RoHS Status: Not applicable / Not applicable
• For Use With/related Products: dsPIC30F
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant

© 2007 Microchip Technology Inc.
Various optimizations or reloading could cause operands 0 and 1 to be in different
registers. For example, the compiler might find a copy of the value of foo in one
register and use it for operand 1, but generate the output operand 0 in a different
register (copying it afterward to foo’s own address).
EXAMPLE 8-8:
It is also possible to specify input and output operands using symbolic names that can
be referenced within the assembler code template. These names are specified inside
square brackets preceding the constraint string, and can be referenced inside the
assembler code template using %[name] instead of a percentage sign followed by the
operand number. Using named operands, the above example could be coded as
follows:
asm ("add %[foo],%[bar],%[foo]"
: [foo] "=r" (foo)
: "0" (foo), [bar] "r" (bar));
EXAMPLE 8-9:
You can prevent an asm instruction from being deleted, moved significantly, or
combined, by writing the keyword volatile after the asm. For example:
#define disi(n) \
asm volatile ("disi #%0" \
: /* no outputs */ \
: "i" (n))
In this case, the constraint letter “i” denotes an immediate operand, as required by the
disi instruction.
EXAMPLE 8-10:
There are special precautions that must be taken when making control flow changes
within inline assembly statements.
There is no way, for example, to tell the compiler that an inline asm statement may
result in a change of control flow. The control should enter the asm statement and
always proceed to the next statement.
Good control flow:
This is acceptable because after calling foo, the next statement will be executed. The
code tells the compiler that some registers do not survive this statement; these
represent the registers that will not be preserved by foo.
Bad control flow:
This is unacceptable as the compiler will assume that the next statement, return 0,
is executed when it may not be. In this case, the asm("error: ") and following state-
ments will be deleted because they are unreachable. See further information regarding
labels in asm statements.
Mixing Assembly Language and C Modules
asm("call _foo" : /* outputs */
/* next statement */
asm("bra OV, error");
/* next statement */
return 0;
asm("error: ");
return 1;
NAMING OPERANDS
VOLATILE ASM STATEMENTS
MAKING CONTROL FLOW CHANGES
: /* inputs */
: "w0", "w1", "w2", "w3", "w4", "w5",
"w6", "w7");
DS51284F-page 117