Tool/software:
Background: I'm most familiar with IAR's icc430 C/C++ compilation environment and a newbie at using TI's CGT MSP430 environment.
In the IAR world, if I want to embed a bit of inline assembly language into an otherwise-C/C++ routine, I can say something like this:
Checksum_T Checksums::computeChecksum( uint32 const FirstByteInRegion_Address, uint32 const RegionBytecount, Checksum_T const Seed )
{
Checksum_T checksum = Seed;
U16ConstPointer20_T Byte_ptr = (U16ConstPointer20_T)FirstByteInRegion_Address;
uint32 remainingWords = RegionBytecount / 2UL;
while ( remainingWords != 0UL )
{
checksum += *Byte_ptr;
asm( "ADC.W %0" /* Add the end-around-carry to the accumulating checksum value (can be either %0 or %1) */
: "=r"( checksum ) /* %0 is our output parameter ("checksum") */
: "r"( checksum ) /* %1 is our input parameter ("checksum") */
: "cc" ); /* The list of clobbered resources (just the Condition Codes) */
Byte_ptr++;
remainingWords--;
}
return( checksum );
}
The %0, =r, r, and cc stuff creates an interface with the C compiler whereby the C compiler sets the assembly language pseudo-operand %0 to point to C's “checksum” data value. It also lets the C compiler know which of its resources my inline assembly code will affect or destroy so the compiler knows to avoid those/save those/accept values back from me.
Looking through SLAU132Y (the CGT Compiler manual) and SLAU131Y (the Assembler manual), I don't see any similar facility so it looks like I would need to read the assembly listings and customize my inline assembly code to access the correct resources (as determined by the C/C++ compiler). In fact, the Compiler manual states that what I'm asking is impossible:
The __asm statement does not provide any way to refer to local variables. If your assembly code
needs to refer to local variables, you will need to write the entire function in assembly code.
And later:
Do not change the value of a C/C++ variable when using an asm statement. This is because the
compiler does not verify such statements. They are inserted as is into the assembly code, and
potentially can cause problems if you are not sure of their effect.
Although I could imagine that if I were willing to accept a certain risk that the compiler could move things around “behind my back” (without notice), I could still write the code I'm proposing.
Do I understand the situation correctly? It's okay if this facility doesn't exist in CGT but it is one place where the IAR environment has a more-convenient implementation than does CGT environment.
Hi Atlant,
Typically to avoid the compiler to mess with my code, I will explicitly define the function and variables to not be adjusted by the compiler. You can use the volatile keyword on the variable itself to prevent it being optimized out
Another option is to also prevent optimization on the whole function see similar thread - https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/570641/compiler-msp430f147-how-do-i-turn-the-optimizer-off-for-a-specific-function
This app note will also help fill in the blanks for some of this linking aspects (as well as a couple code examples) - https://www.ti.com/lit/slaa140
Regards,
Luke
Thanks for pointing out that the IAR asm syntax is actually GCC syntax; I should have guessed this but didn't. ;-)
I haven't tried the GCC-style parameterization you mention with the TI compiler.
I just tried it.
For the line that contains asm( "ADC.W %0", the CGT compiler (running in mostly-default mode) says:
"hello.c", line 294: error: expected a ")"
So unless some qualifiers can change this behavior, the CGT compiler isn't willing to accept this GCC syntax.
(I also tried it with GCC and in that environment, it worked.)
Hi Atlant,
Were you able to apply the no optimization on your function and set the variable in use to not be optimized out? -
#pragma FUNCTION_OPTIONS(function_name, "--opt_level=off")
In that scenario the compiler shouldn't be adjusting the function which I would expect to allow your __asm to apply the 430 instructions onto the data.
Luke:
I didn't try that yet but I'm reasonably certain that you're correct and setting "no optimize" would help the situation.
Right now, my question was at least partially theoretical; I'm considering what it would take to port our code base (or portions thereof) from the IAR environment to the CGT environment and that bit of assembly code is the only stumbling block I've noticed so far. The code I've experimentally ported so far has required no adaptation except for the makefiles and the (expected) compiler and linker qualifiers.
Sounds good! I'll close the thread for now, but if you run into any difficulties while you're porting feel free to create another thread.
**Attention** This is a public forum