C2000 C/C++ CODE GENERATION TOOLS Release Notes 6.1.9 July 2014 ******************************************************************************* Table of Contents ******************************************************************************* 1. Compiler Support for the Control Law Accelerator (CLA) 1.1. How to Invoke the CLA Compiler 1.2. How to setup CCS to use CLA Compiler 1.3. CLA C-Language Implementation 2. Compiler support for __fsat Intrinsic ============================================================================== 1. Compiler Support for the Control Law Accelerator (CLA) ============================================================================== The 6.1.0 version of the C2000 Code Generation Tools includes compiler support for the Control Law Accelerator. Code intended to be executed on the CLA can be written using a subset version of the C Language and be compiled/linked with C28x code into a single executable. ============================================================================== 1.1. How to Invoke the CLA Compiler ============================================================================== The CLA compiler is invoked using the same shell used for C28x (cl2000[.exe]). Files that have a .cla extension will be recognized by the shell as CLA C files. The shell will invoke separate CLA versions of the compiler passes to generate CLA-specific code. The object files generated by the compile can then be linked with C28x objects files to create a C28x/CLA program. Usage: cl2000 -v28 --cla_support=cla0 [other options] file.cla NOTE! The compiler does not support compiling CLA AND C28X C files in one invocation. ============================================================================== 1.2. How to setup CCS to use CLA Compiler ============================================================================== Currently CCS does not recognize files with a .cla extension as C source files. They can be added to a C28x project but will not compile as part of the build. To have .cla files treated as C source files, from the CCS Menu: 1. Select Window->Preferences 2. Expand C/C++ tree 3. Select File Types. A list of extension mappings will appear on right. 4. Click 'New...' button 5. Enter '*.cla' as the Pattern and choose 'C Source File' as the Type and click Ok. The linker command file associated with the CCS project must be updated to allocate the expected sections generated by the CLA Compiler (see next section) ============================================================================== 1.3. CLA C Language Implementation ============================================================================== I. Characteristics * Supports C only. Compiler will error if compiling for C++. No GCC support. * Data Types Supported - char/short - 16 bits. Should only be used for load/store operations - int,long, long long - 32 bits - float, double, long double - 32 bits - pointers - 16 bits NOTE!!! The size differences between CLA int/pointer types vs C28x * Pragmas - Accepts C28x pragmas except for FAST_FUNC_CALL * C standard library is not supported. * The 'far', and 'ioport' keywords are not recognized * Access to "MMOV32 MSTF,mem32" and "MMOV32 mem32,MSTF" instructions is provided using the 'cregister' keyword. To access these MSTF instructions include the following declaration: extern cregister volatile unsigned int MSTF; * The following intrinsics are supported: float __meisqrtf32(float) float __meinvf32(float) float __mminf32(float, float) float __mmaxf32(float, float) void __mswapf(float, float) short __mf32toi16r(float) float __mfracf32(float) float __sqrt(float) unsigned short __mf32toui16r(float) __mdebugstop() __meallow() __medis() __msetflg(unsigned short, unsigned short) __mnop() Additionally, the runtime library functions abs() and fabs() are implemented as instrinsics. II. C Language Restrictions * Defining and initializing global data is not supported. Since the CLA code is executed in an interrupt driven environment there is no C system boot sequence. As a result, definitions of the form 'int global_var = 5;' are not allowed for variables that are defined globally (outside the scope of a function). Initialization of global data must either be done by the C28x driver code or within a function. Variables defined as 'const' can be initialized globally. The compiler will create initialized data sections named .const_cla to hold these variables. The same restriction applies to variables declared as 'static'. Even if the variable is defined within a function. * IMPORTANT!! Local variables and compiler temps are expected to be placed into a scratchpad memory area and accessed directly using the symbols '__cla_scratchpad_start' and '__cla_scratchpad_end'. It is expected that the user will manage this area and define these symbols using a linker command file. The following is an example of what needs to be added to a linker command file to define the CLA compiler scratchpad memory: CLA_SCRATCHPAD_SIZE = 0x100; : : : CLAscratch : { . += CLA_SCRATCHPAD_SIZE; } > CLARAM1, START(__cla_scratchpad_start), END(__cla_scratchpad_end), PAGE = 1 CLA_SCRATCHPAD_SIZE is a linker defined symbol that can be added to the application's linker command file or defined using the linker --define option to designate the size of the scratchpad memory. A SECTION's directive can reference this symbol to allocate the scratchpad area. For example, above the SECTION's directive reserves a 0x100 word memory hole to be used as the compiler scratchpad area. The value of CLA_SCRATCHPAD_SIZE can be changed based on the application. This scratchpad area functions as the C software stack. * Currently only 2 levels of call stack depth is supported. See 'Calling Conventions' below for details. * Recursive function calls are not supported. * The following operations are currently not supported due to lack of instruction set support making them expensive to implement. Integer divide, modulus Integer unsigned compares II. Memory Model - Sections * The CLA compiler will place CLA code into section "Cla1Prog" as per the current convention used for CLA assembly. * Uninitialized global data will be placed in section ".bss_cla" * Initialized const data will be placed in section ".const_cla" * There is no C system heap for CLA (no support for malloc()) III. Function Structure and Calling Conventions * The compiler supports 2 level of function calls. Functions declared as interrupts may call leaf functions only. Leaf function may not call other functions. Functions not declared as interrupt will be considered leaf functions. * Register Calling Convention - Compiler supports calling functions with up to 2 arguments. Pointer arguments are passed in MAR0/MAR1. Integer/float arguments are passed in MR0,MR1. Integer and float return value from functions are passed in MR0. Pointer or return by reference value from functions are passed in MAR0. * All registers except for MR3 are saved on call. MR3 is saved on entry. * A static scratchpad area is used as a stack for locals and compiler temporary variables. The user is responsible for ensuring the scratchpad area is allocated into the memory map and is large enough. This is done using the linker command file (see above). * When interfacing with CLA assembly language modules use the calling conventions defined above to interface with compiled CLA code. ============================================================================== 2. Compiler support for __fsat Intrinsic ============================================================================== The 6.1.0 version of the C2000 compiler adds support for the __fsat intrinsic: double __fsat(double val, double max, double min); Return val if min < val < max; else return min if val < min; else return max if val > max. Result undefined if max < min.