• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 57 subscribers
  • Views 3643 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.

Compiler: Case for C++?

Olli Mannisto
Expert 1750 points

Other Parts Discussed in Thread: MSP430FR5969

Tool/software: TI C/C++ Compiler

This is one of those bad questions, I know.

I have been writing my code in C as I suspect many of you do as well. I was thinking that I use a lot of global structures to store my buffers, settings and the like. These could just as well be converted to classes and objects, althought apparently some special hoops need to be jumped through to make the class go into FRAM and still contain some private variables.. Class in a class as it would be. Mostly the benefit I see would be to make the code somewhat more manageable with various functions being integrated as methods. I have no intention of doing polymorphism etc.  

C++ 11 seems to be slowly grinding to CC, beyond that, is the TI C++ compiler producing nice well-optimized code? Can I expect to take my well-behaved C99 code and compile it as C++ 2003 without breaking things and/or consuming more RAM/FRAM?

I'm writing for MSP430FR5969 which has 2kB ram and 64kB FRAM.

  • 0
    TI__Guru**** 253020 points

    Unfortunately, TI has no collateral which addresses this topic.  That said, others in the community are more than welcome to share their experience.

    Thanks and regards,

    -George

  • 0
    TI__Guru* 84285 points
    If your code is still valid C code, the compiler will generate nearly identical code if you compile it as C++. There are only a few spots where C++ is not a strict superset of C, and if your C99 code compiles and links without error, you probably haven't encountered any of these differences.
  • 0 in reply to Archaeologist
    Expert 1750 points
    I spent time going over the C99 vs C++ FAQ, it seems there's a major gotcha with function pointers. Otherwise it's fairly safe. I guess you could rephrase the question (all the more "bad") "Is the TI C++ compiler any good?". Writing that just makes my fingertips burn.. I'll presume you wouldn't have it for MSP430 family if you were not confident it produces good code.

    Anyways, I mentioned having to babysit classes to make them go to FRAM but I guess that's not really true, since FRAM is RW random access memory to start with. Doing the same thing with Flash would be entirely different.
  • 0 in reply to Olli Mannisto
    TI__Guru* 84285 points
    Well, I can tell you with confidence that the TI C/C++ compiler is as good at compiling C code in C++ mode as in C mode.
  • 0 in reply to Archaeologist
    Expert 1750 points

    CPP "Hello world" doesn't fit into the MSP430FR5969 Ram/Fram. I guess that answers my question whether C++ would bring benefits for my MSP430 project. 

    Pfft. 

  • 0 in reply to Olli Mannisto
    TI__Guru* 84285 points
    When you say 'CPP "Hello world"', do you mean you are using cout? cout is implemented with deep nested templates, which is a big challenge for any compiler. You might try using optimization level -O4 to see if it can do away with the extra code.

    Lots of programmers use C++ not for the object-oriented features, but as a "better C" with stronger type checking. If you stick to the simpler C++ features, you're not likely to see a C++ overhead.
  • 0 in reply to Archaeologist
    Expert 1750 points

    Yes, that was exactly what I did. You have to compile hello world, it says so in them rules.

    I did try -O4 which did cut down the memory allocation a bit but not enough. Care to try compiling this for MPS430FR5969?

    #include <iostream>
main(){
    std::cout << "Hello World!\n";
}

    Actually what the compiler (linker) says is:

    Description Resource Path Location Type
<a href="processors.wiki.ti.com/.../10099"> program will not fit into available memory. placement with alignment fails for section ".cinit" size 0x66 . Available memory ranges: lnk_msp430fr5969.cmd /test line 152 C/C++ Problem
<a href="processors.wiki.ti.com/.../10099"> program will not fit into available memory. placement with alignment fails for section ".const" size 0x2698 . Available memory ranges: lnk_msp430fr5969.cmd /test line 161 C/C++ Problem
<a href="processors.wiki.ti.com/.../10099"> program will not fit into available memory. placement with alignment fails for section ".text" size 0x17d88 . Available memory ranges: lnk_msp430fr5969.cmd /test line 168 C/C++ Problem

    And that .cinit and .const definitely should have fitted to the FRAM. That final .text is really obnoxious thought. 

  • 0 in reply to Olli Mannisto
    TI__Guru* 84285 points
    The foregoing discussion was about compiling C99 programs in C++ mode, not compiling a C++-flavor "hello world." I stand by my claim: If your code is still valid C code, the compiler will generate nearly identical code if you compile it as C++.

    You should definitely avoid using cout, etc when using C++ on an embedded device. That does not mean you can't use some C++ features to your advantage.
  • 0 in reply to Olli Mannisto
    Guru 92251 points

    Olli Mannisto said:
    That final .text is really obnoxious thought. 

    The large .text when using std::cout could be for the same reason as the outstanding defect CODEGEN-1458 "Consider splitting up unified_locale.cpp to save code space". While CODEGEN-1458 was raised on the TI ARM compiler I suspect the same issue will apply to the TI MSP430 compiler which shares common run-time library code.

    E.g. for the TI ARM v17.3.0 compiler a Cortex-M4 "hello world" example using std::cout required 125373 bytes of flash of which 92220 bytes were from the single unified_locale.obj object file from the compiler run-time library rtsv7M4_T_le_v4SPD16_eabi.lib.

  • 0 in reply to Chester Gillon
    Expert 1750 points

    Seems as if it's something like that. That's a pretty terse bug report, thought and the referred forum thread is dead.. I guess there's no workaround for this? 

    Anyways, embarassing that "hello world" falls over.. 

  • 0 in reply to Olli Mannisto
    Guru 42895 points
    "Anyways, embarassing that "hello world" falls over.. "
    Not on an embedded, "non hosted" system, it is almost to be expected, that is why the traditional "hello, world!" for an embedded processor is "blinky."

    Now, get off my lawn!
  • 0 in reply to Keith Barkley
    Expert 1750 points

    Yes, well.. It's still going to be THE first example on a C++ programming book/guide. I guess it's a good reality check for those CS majors who start hyperventilating at the thought of using C++ as "C+" to use classes for improved modularity and the like. RAII? No thanks.

    WRT led blinky, for sure, but nothing C++ oriended on that unless you make "led" an object and "blink" method thereof.

    Printf is useful for debugging thought. Sometimes the debugger is not WYSIWYG. I wonder if other C++ standard libraries (or standard template libraries) have similar issues as iostreams. 

  • 0 in reply to Olli Mannisto
    Guru 42895 points
    "Printf is useful for debugging thought"

    Absolutely, that is why Ti does so much debugger magic under the hood to get it to work.