• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 868 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.

MSP430 Intrinsic Legacy Change

Mark Swanson
Expert 3520 points

Hi Compiler Champs!

I have a customer who is upgrading their legacy code to the latest MSP430 compiler (16.9.1LTS) and noticed the Optimizing C/C++ Compiler User's Guide MSP430 Intrinsic list was slightly different from the code's - namely a single underscore was used in the code instead of a double underscore in the User's Guide to precede any intrinsic call (Section 6.8).

I notice this is addressed with intrinsics.h, with a note for 'Legacy Macros', but was there a particular reason for this intrinsic nomenclature change? Are there any risks in keeping these legacy intrinsics in current code?

Thank you for any insight you can provide!

Best Regards,

Mark-

  • 0
    TI__Guru**** 253360 points

    Mark Swanson said:
    but was there a particular reason for this intrinsic nomenclature change?

    I'm not entirely clear on that.  I think it has something to do with making it easier to write macros that invoke intrinsics, and work across multiple MSP430 compilers.

    Mark Swanson said:
    Are there any risks in keeping these legacy intrinsics in current code?

    No.  If something like that were to occur, we would view it as a bug in the compiler.

    Note any intrinsic that gets added will use the new naming convention (starts with two underscores).

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru* 84285 points
    The change was made to have a more consistent compiler builtin naming scheme (for better ease-of-use), to adhere more closely to the goal of avoiding collisions with legal user-defined identifiers, and to be a little bit more pedantically correct.

    The only risk you take in continuing to use the new names is that the compiler might no longer support them in a future release, in which case you'd need to switch to the new names. You could easily do this with a header file of macros remapping the names. However, I doubt the compiler will obsolete the old names for a very long time, and that certainly won't happen on a branch.