• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 1393 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Unexpected 'SPM #0' instruction insertion

Chris Bayne
Prodigy 20 points


Tool/software: TI C/C++ Compiler

Hello All,

We are using CL2000 compiler version 6.4.6 and have noticed an unexplained and inconsistent insertion of assembler instruction 'SPM #0'.  This occurs when we place an asm("SETC INTM") or asm("CLRC INTM") macro in our C source code.  There are no multiplication or other arithmetic operations going on in our code, in the near vicinity.  Also, it is inconsistent.  We have one place in our codebase where an asm("SETC INTM") does *not* cause an 'SPM #0'.  We are performing compiler analysis as part of our strict DO178C related process i.e. to scrutinise the resulting assembler after compilation and need to justify this extraneous, but harmless instruction addition.  Our compiler flags, for the analysis task are set to:

-v28 -g -O2 -mf -ss -D"_DEBUG" -k -c --symdebug:none

Many Thanks

Chris  

  • 0
    TI__Guru* 84285 points
    The PM field is the implicit shift amount, used for certain instructions. The compiler keeps track of the value of this field and sets it when necessary. To minimize the number of times it needs to emit an SPM instruction, it may insert an SPM instruction in a place that covers multiple uses of the PM field, which might not be lexically close to the use. Now, the compiler doesn't like asm() statements. An asm() statement represents a big unknown to the compiler; it assumes the worst case, including that it contains an SPM instruction setting the PM field to an inappropriate value. Thus, the compiler may feel obligated to insert an SPM instruction after the asm() statement if there is a use of the PM field in the function, even if the asm() statement doesn't really touch the PM value.

    If, after accounting for the unknown caused by asm() statements, you feel the compiler is inserting SPM unnecessarily, we'd love to see a test case.
  • 0 in reply to Archaeologist
    Prodigy 20 points

    Many thanks for your response.  I had thought that this might be the case i.e. the compiler playing safe.