cl2000 --cla_support=[cla0|cla1] [other options] file.cla

10.2.1 Characteristics

CLA implementation supports C only. The compiler produces an error if compiling for C++.

These data types are supported:

• Type char is 16 bits.
• Type short is 16 bits. A char/short should be limited to load/store operations.
• Types int, long, and long long are 32 bits.

Note that the int size for CLA is 32 bits versus 16 bits on C28x. To avoid ambiguity when sharing data between CLA and C28x, it is strongly recommended to use type declarations that include size information (for example, int32 and uint16).

• Types float, double, and long double are 32 bits.
• Pointers are 16 bits.

Pointer sizes for CLA are always 16-bits. This differs from C28x, which has 32-bit pointers.

NOTE

No 64-bit Types With CLA Compiler

The CLA compiler does not support 64-bit types.

CLA accepts the C28x pragmas except for FAST_FUNC_CALL.

The C standard library is not supported.

The far and ioport keywords are not recognized.

Access to the '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 intrinsics listed in Table 10-1 are supported. Additionally, the run-time library functions abs() and fabs() are implemented as intrinsics.

10.2.2 C Language Restrictions

There are several restrictions to the C language for CLA.

• Defining and initializing global/static 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, global/static data initialization must be done during program execution, either by the C28x driver code or within a CLA function.

Variables defined as const can be initialized globally. The compiler creates initialized data sections named .const_cla to hold these variables.

• Recursive function calls are not supported.
• The use of function pointers is not supported.

Most GCC extensions are now supported by the CLA compiler. Both the C and the CLA compiler have GCC extensions enabled by default. See the --relaxed_ansi option in Section 6.13.3 and the list of GCC language extensions in Section 6.14 for more information.

The interrupt function attribute described in Section 6.9.13 can be used with CLA interrupts, so long as you do not include any arguments to the interrupt attribute. The INTERRUPT pragma is also supported by the CLA compiler. For example, the following uses are supported:

__attribute__((interrupt)) void interrupt_name(void) {...} #pragma INTERRUPT(interrupt_name); void interrupt _name(void) {...}

10.2.3 Memory Model - Sections

Uninitialized global data is placed in section .bss_cla.

Initialized const data is placed in section .const_cla.

There is no C system heap for CLA, because there is no support for malloc().

Local variables and compiler temps are placed into a scratchpad memory area, which acts as the CLA C software stack. It is expected that the scratchpad memory area is defined and managed in the application's linker command file.

Instead of using a stack, each function has a generated function frame that is part of the .scratchpad section. Therefore, the only section that needs to be placed in the linker command file is the .scratchpad section. A scratchpad frame is designated for each function to hold local data, function arguments, and temporary storage. The linker determines which function frames can be overlaid in placement to save memory.

All function frames are placed in the .scratchpad section and are named in the form ".scratchpad:functionSectionName". Each function has its own subsection, and thus a unique section name. For example, if the source-level function name is "Cla1Task1", then the COFF function name will be "_Cla1Task1", the function section name will be "Cla1Prog:_Cla1Task1", and the function's scratchpad frame will be named ".scratchpad:Cla1Prog:_Cla1Task1". The function's scratchpad frame will use the base symbol "__cla_Cla1Task1_sp".

Note that if an assembly writer uses a different naming convention for the data space of a function, it cannot be overlaid nor placed within the .scratchpad section.

It is not necessary to specify a size for the .scratchpad section.

CLA object files compiled with compiler versions prior to 6.4 are compatible with newly generated object files so long as the linker command file supports both scratchpad naming conventions. However, the scratchpad section used for old object files cannot be overlaid with the new .scratchpad section and you must ensure that enough memory is available for both sections.

10.2.4 Function Structure and Calling Conventions

The CLA compiler supports multiple nested levels of function calls. The restriction to two levels of function calls has been removed. If you are using the new function call support, the CLA compiler now also supports calling functions with more than two arguments.

Pointer arguments are passed in MAR0 and MAR1. 32-bit values are passed in MR0, MR1, and MR2. 16-bit values are passed in MR0, MR1, and MR2. Any further arguments are passed on the function frame (function-local scratchpad space), starting at offset 0.

All registers except for MR3 are saved on call. MR3 is saved on entry.

When interfacing with CLA assembly language modules, use these calling conventions to interface with compiled CLA code.