Hi,
My customer sent in the query below and MSP e2e referred me to this forum as the are not very familiar with the underlying compiler behavior:
As per of the technology investigation we’ve been carrying out to support our plans for developing a new software / hardware platform to base our future product ranges on I’ve been taking a look at the state of TI’s C++ tooling.
On the whole it seems to be pretty good, however the major issue I’m seeing is that the generated code size is 4-5 times greater than an equivalent C program! The map file shows that a significant part of this is the TI runtime library code.
The example project only makes use of statically allocated objects so seeing the free() function in the map file was a little surprising! Further research found the following forum thread that describes a similar scenario to the one I’m seeing: https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/785744/compiler-msp430fr5989-why-is-malloc-and-associated-functions-being-pulled-into-my-build?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending
The article was from ~5 years ago and the state of TI’s C++ compiler has progress to the point of supporting the C++14 standard (or as much as is feasible for the MSP430 architecture) so I’m hoping that there’s more that can be done to reduce the generated code size. For example, the difficulty detecting that the program never returns was cited as a reason that the calls to free() (including the preceding function calls that call free()) could not be optimised out. C++11, however, introduced the [[noreturn]] attribute to explicitly mark a function as never returning. Using this attribute on the main() function I am able to see that the code generation tooling is able to detect if main does / does not return, which suggests this specific limitation may no longer be valid.
Digging deeper into the C++ memory usage has raised some additional observations.
- The map file’s FRAM usage summary in the MEMORY CONFIGURATION section doesn’t seem to agree with the values elsewhere in the map file, e.g. The Grand Total in the MODULE SUMMARY section
- CCS’ Memory Allocation utility also seems to conflict with itself. The Total FRAM usage doesn’t match the sum of the section sizes that are contained within
I tried building with both the lc_sd and sc_sd memory models and the FRAM total, in both cases, was 864 bytes (0x0360) larger than the sum of the sections listed within it.
Is this an issue with the total reported FRAM usage, or is there something that isn’t being reported in the map file / Memory Allocation utility?
Looking at the map file for a compiled C program the numbers appear to be closer to what I’d expect and the Memory Allocation utility numbers add up exactly as I’d expect, which suggests a C++ nuance that the tooling isn’t handling.
In the meantime, I also tried stubbing out the functions that call free(), as was recommended in the thread I’ve linked to. Unfortunately, as was predicted in the thread, the libraries have moved on and the suggested stubs no longer prevent malloc / free from being called in my compiled project.
- I would really appreciate some insight into whether this is something that could be improved upon as C++ could help make our new software platform much simpler to implement.
- Some updated guidance on how to stub the library code to prevent the free() function (and supporting callees) from being compiled into the final executable would also be very useful so that I can proceed with my technical evaluation.
On a related note it would be really nice to see some official TI support on the experimental LLVM MSP430 backend: https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/MSP430, the TI and the Clang-ARM CGTs seem to have benefitted already. Having standardised tooling makes the life of us developers much easier, and also allows us to adopt modern CI/CD development practices with less effort.
Any help with this will be greatly appreciated.
Many Thanks,
Vanessa
