Code size increases with usage of MSP430 Library

EABI has a different startup code than COFF. One of the differences is a loop that clears uninitialized data space, which won't happen on COFF. Sure this loop doesn't take 100 bytes, so there are probably other differences too.

As for the second case, well, it is possible that in EABI format, the linker is a bit smarter and excludes code form the build that is is the same compilation unit as otehr code bu tnot used at all. Usually, whole compilation units are included, whether all of their content is used or not.

To be sure, the generated output must be analyzed further. Since I don't use CSS, that's beyond my capabilities.

paddu1 said:

please let me know which Output format is recommended?

Well, generally said, it depends on your requirements. Starting with version 4.0.0 TI's MSP430 compiler supports the new EABI in addition to the current COFFABI. As JMO already noted it has a different startup code. I would recommend you to read the file named readme.txt included to the compiler. Here are some important excerpts:

2.1) Features
-------------

MSP430 EABI is an ABI for the MSP430 architecture based on the ELF object file format.  The major features are:

 - ELF object format
 - DWARF3 debug format
 - Improved "GPP parity"

The advantage of EABI is that it provides a modern, well-documented ABI that is well-supported.  Many newer C++ language features, such as template instantiation and "extern inline," can be implemented more effectively.

Future development of TI's MSP430 compiler will be primarily implemented within EABI.  We encourage users to consider switching to EABI at their earliest convenience.

[...]

2.3) 64-bit "double"
--------------------

In EABI mode, the C standard type "double" is 64 bits.  In COFF ABI mode, the "double" type remains 32 bits.

Because the C standard requires the compiler to treat unsuffixed floating-point constants as type "double," the compiler is required use double-precision arithmetic for expressions involving such constants. Programs which use such constants may run a little slower in EABI.  This performance can be reclaimed by changing the constants to have the suffix "f".

2.4) Table-Driven Exception Handling
------------------------------------

MSP430 compiler version 4.0.0 supports table-driven exception handling for ELF executables.  Table-driven exception handling is more time-efficient than setjmp/longjmp support when exceptions are not thrown.

The user interface is almost entirely the same as the COFFABI support; use the option --exceptions and link with an RTS which has exception handling enabled. For EABI only, if you have any 'extern "C"' functions which need to throw exceptions, you must use the option "--extern_c_can_throw".

The underlying implementation is very different.  No support will be provided for migrating assembly files generated using the COFF scheme to the EABI environment; such files should be recompiled from the original C++ files.

[...]

 2.6) Migration from COFF to ELF
-------------------------------

To take advantage of MSP430 EABI, users must explicitly request it using the "--abi=eabi" command-line option.  Object files generated with this option will not be compatible with object files generated for COFFABI.  However, most C source files will not require modification, and most assembly source files will require only trivial modification.

The major differences between EABI and COFFABI are:

 - Different name mangling
 - C++ names are mangled using IA64 name mangling scheme
 - Different C auto-initialization

However, there are many more details.  Review the MSP430 EABI Migration document for these migration details.

Users need to take specific steps to migrate their projects to EABI:

 - COFF objects and libraries are not compatible with EABI objects; programs and libraries must be recompiled from source. There is no COFF to ELF conversion utility.

Please refer to the MSP430 EABI Migration document for details.

Since it can be expected that future major releases of TI's MSP430 compiler support the EABI format only, I followed those recommendations of TI. I already use the new EABI format in all my current projects. Of course, as long as you don't use those new features provided by the EABI format, then you can use the COFF format also.

Jens-Michael Gross said:

As for the second case, well, it is possible that in EABI format, the linker is a bit smarter and excludes code form the build that is is the same compilation unit as otehr code bu tnot used at all. Usually, whole compilation units are included, whether all of their content is used or not.

paddu1 said:

And shown above with the output format EABI(ELF) the code size reduces in case of Driver Library sample code [...]

Indeed, the conditional linking paradigm is different under COFF compared to ELF. In COFF, you must mark a section to make it eligible for removal during conditional linking. In ELF, all sections are considered eligible for removal through conditional linking. Under COFF, a section that has been marked for conditional linking is removed from the program only, if it is never referenced by any other section in the program. Under ELF, a section that is never referenced by any other section in the program is removed from the program automatically, unless it is marked to retain. See slau132 - "MSP430 Optimizing C/C++ Compiler v4.1 User's Guide" - for more details about both ABIs.