Building and Running Boost Code with the C6000 Compiler

Important Note:

The software discussed on this site is available for download, but is no longer being actively developed. This wiki is in maintenance mode and the software is supported on TI Compiler E2E forum

Introduction

Boost is a collection of portable C++ libraries. Think of it as the STL squared, and you aren't too far wrong. Most of the libraries are supplied entirely as a set of header files. The header files contain templates in the same style as the STL. Code and data is auto-generated when the templates are instantiated in user code.

Configuring Boost

• Download and unpack this .zip file. You will get two files: ti.hpp and user.hpp.
• Replace boost_root with the root directory where you have installed Boost.
• Add ti.hpp to the directory boost_root/boost/config/compiler. Boost configuration details specific to the TI compiler are contained here.
• Replace boost_root/boost/config/user.hpp with the user.hpp from the .zip file. This file points to ti.hpp, among other details. The original file has everything commented out. Anything uncommented represents a change.
• Configuration for the platform (i.e. BIOS, Linux, Enea, etc.) has not been done. In fact, it is disabled by defining BOOST_NO_PLATFORM_CONFIG in user.hpp. Integration of BOOST with one of those platforms requires some work in this area. Though it is probably possible to run Boost code within the confines of a single thread in the no platform configuration.
• These files have held up under some testing. I am confident they are correct. Even so, a lot of Boost code has not been tested.

Version Information

• You must use C6000 compiler version 6.1.0 or higher.
• Boost library version 1.34.1 is used here. Later versions are likely to work equally well up to 1.37.0, though they have not been tested. From version 1.38.0, the building mechanism was changed and further work is needed.

Build Options

• Enable exceptions with --exceptions. Some Boost code will build without --exceptions, some will not. Note Boost docs recommend that exceptions be enabled.
• The stack and heap sizes need to be massive. I have not characterized how big. I currently set the heap to 0x80000 and the stack to 0x10000.
• Here is how I built one file:

      cl6x -i C:\boost_1_34_1 -mv64plus --exceptions PingPong.cpp -z -o pingpong.out -m pingpong.map -l rts64plus_eh.lib lnk_6455.cmd

Workarounds, Caveats, and Limitations

• You may get a compile time warning like this one. This could potentially cause runtime errors. However, I have never seen any.

"C:\boost_1_34_1\boost/function/function_template.hpp", line 655: warning #1369-D: 
          static local variables of extern inline function are not resolved to
          single copy. Not ANSI C++ Compliant
        static vtable_type stored_vtable(f);
                           ^

A full explanation can be found in the article C++ Inlining Issues.

• I modified the example code to not read input from STDIN. Though I did run it that way once under CCS. A dialog box popped up, I input the data one character at a time, and got the expected results. So, it works. But it is inconvenient.
• The linker has a feature where it can automatically pick the RTS library for you. When building for C64+, the library rts6200.lib tends to get picked (cite? This is believed to be fixed). It is compatible. However, this causes something about the resulting .out file to be different enough that CCS won't load it.
• Some examples need changes so they won't take so long to run. For instance, in the Statechart PingPong example, I changed the number of times the ball is bounced back and forth from 100,000 to 10.
• So that CCS will find the Boost source files when stepping you must include the drive letter in the -i path to boost. For example:

 -i C:\boost_1_34_1

Somehow, not having the drive letter (C:) causes CCS to not find the files.

• Note that if a class does not explicitly define a constructor and/or destructor, the compiler automatically generates one. When you step into such a function, CCS has no choice but to display the disassembly. There is no source code to display at that point. Boost examples often create classes that have no explicit constructors, but inherit from other classes that do. So, when stepping through the part of the constructor that comes from the base class, there is corresponding source code. CCS does not display that source code. Perhaps it should.