Jump to content
Sign in to follow this  
MattTheGeek

TI Compiler ABI

Recommended Posts

Seems like the TI MSP430 Compiler (V4.1.1) prefers using EABI now over the legacy COFF ABI. Any advantage on using EABI for small memory size devices? From what i've seen it prefers to use Flash over ram.

 

Optimization level 4, Optimize for size (0).

COFF ABI:

Text: 534 bytes

Data: 46 bytes

 

EABI:

Text: 670 bytes

Data: 12 bytes

Share this post


Link to post
Share on other sites

My understanding was that COFF can't express some C++ semantics (e.g. templates) properly hence EABI is default. COFF and EABI also have different approach to initialization of globals which may be the reason for size differences.

Share this post


Link to post
Share on other sites

EABI will load 0's into static/global variables by default, COFFABI will not.  You will need to supply a "no init" pragma or something like it to prevent EABI from doing this.

 

It is also my experience that EABI has better support for inline function linking and linker file commands, but CL430 (via CCS) may not have complimentary support for this.  MSPGCC does, however.

Share this post


Link to post
Share on other sites

Sorry for the noobie question, but does this affect the way the MSP430 is actually flashed, or is this just an intermediate format? When you're talking about the TI compiler, you mean CCS? So this does not affect pragrams made in IAR or GCC (energia)? Can the compiler (and IDE) be set to the older output format?

Share this post


Link to post
Share on other sites
  • EABI is the linker format.  When you flash a device, it is with some type of hex file, so you could indeed call the linker object files "intermediate."
  • CL430 is the name of TI's compiler, which is used in CCS.
  • CCS can be set to use COFFABI, the original linker format.  In fact, I generally use COFFABI because I don't need the features of EABI.

One of the other added benefits of EABI in CCS is that it *should* support standard EABI linker scripting, and EABI is used almost universally for 

Cortex M toolchains.  So, potentially I could have more commonality in my linker scripts across MSP430 and Cortex M builds of the same thing.  That would be nice.  I haven't tried it yet, though.

Share this post


Link to post
Share on other sites

So in the end it shouldn't matter which cind of compiler output you use, since the linker would link either to an identical hex/s19/bin file? Then why would it give any drawbacks to use the "extended" version?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...