• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1839 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.

GNU __attribute__ support on TI ARM compiler

Paul Singh
Expert 2750 points


Hello,

   
I read in GCC manual that __attribute__ is its syntax, but found that the following code can also get compiled under TI ARM compiler v 4.9.4:
unsigned int  __attribute__((naked)) WidgetMutexGet(unsigned char *pcMutex)
   
Could anyone tell me how does would TI ARM compiler v 4.9.4 treat __attribute__((naked))?
   
I looked at section 5.16 GNU Language Extensions of SPNU151. In particular, section 5.16.1 Extensions mentioned that
“Most of the GCC language extensions are available in the TI compiler when compiling in relaxed ANSI mode (--relaxed_ansi) or if the --gcc option is used.”
   
I didn’t find these two options set in my ccs project properties but the project could still get compiled through with __attribute__((naked)) present. So is there something hidden that made the GNU support possible?
 
 
Paul
  • 0
    TI__Guru* 84285 points

    The TI compiler does not support the "naked" attribute

  • 0 in reply to Archaeologist
    Expert 2750 points
    Sorry that I was still studying the related manuals of different compilers.
       
    In,
    unsigned int  __attribute__((naked)) WidgetMutexGet(unsigned char *pcMutex)
    {
        // Acquire the mutex if possible.
        __asm("    mov   r1, #1\n"
              "    swpb  r1, r1, [r0]\n"
              "    mov      r0, r1\n"
              "    bx       lr\n"); 
     
        // The following keeps the TI compiler from optimizing away the code.
        return((unsigned int)(*pcMutex));   
    }
    #endif
    The comment says that the last “return” statement keeps TI compiler from optimizing away the code. What did this “return” statement actually do, and what it would be without this “return”?
       
    I think that the “bx” ARM v5 instruction already jumps back before the final “return” would have chance to finish, so in this sense the “bx” already completed the return by both

    1.    Put the return value in r0 (I guess that the resumed previous caller would fetch r0 as the return value, though not 100% sure about it)

    2.    Jump back to previous caller

        
    So what does the final “return” statement do? And how would TI arm compiler treat it together with the “asm()” instructions so as to “keeps the TI compiler from optimizing away the code”?
  • 0 in reply to Paul Singh
    TI__Guru* 84285 points

    The final return statement simply fetches the value at *pcMutex and returns it, making it appear to the compiler that the value of pcMutex is used.

    The compiler makes no guarantees about the interaction of inline assembly code with any other compiler feature or C code; for this reason, the compiler team recommends avoiding inline assembly code entirely.  The author clearly intends for those four assembly instructions to be the entire body of the function, which will only be guaranteed if this function is actually written as assembly source code.  Writing it as a C function with inline assembly will not make it inlinable.