MattTheGeek 99 Posted August 20, 2012 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 Quote Share this post Link to post Share on other sites
yugr 0 Posted August 20, 2012 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. Quote Share this post Link to post Share on other sites
jpnorair 340 Posted January 3, 2013 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. Quote Share this post Link to post Share on other sites
roadrunner84 466 Posted January 4, 2013 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? Quote Share this post Link to post Share on other sites
jpnorair 340 Posted January 4, 2013 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. 1 bluehash reacted to this Quote Share this post Link to post Share on other sites
roadrunner84 466 Posted January 4, 2013 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? Quote Share this post Link to post Share on other sites
jpnorair 340 Posted January 4, 2013 As mentioned, there are subtle differences in the code generation for data allocations and inline functions. Quote Share this post Link to post Share on other sites
