Texas Instruments TMS320 DSP manual External Identifiers, Rule

www.ti.com

Interfaces and Modules

Rule 7

All header files must support multiple inclusions within a single source file.

The general technique for insuring this behavior for C header files is illustrated in the Code below.

/*

*======== fir.h ========

*/

#ifndef FIR_ #define FIR_

0

#endif /* FIR_ */

A similar technique should be employed for assembly language headers.

;

;======== fir.h54 ========

.if ($isdefed("FIR_") = 0) FIR_ .set 1

0

.endif

3.1.1 External Identifiers

Since multiple algorithms and system control Code are often integrated into a single executable, the only external identifiers defined by an algorithm implementation (i.e., symbols in the object Code) should be those specified by the algorithm API definition. Unfortunately, due to limitations of traditional linkers, it is sometimes necessary for an identifier to have external scope even though this identifier is not part of the algorithm API. Thus, in order to avoid namespace collisions, it is important that vendor selected names do not conflict.

Rule 8

All external definitions must be either API identifiers or API and vendor prefixed.

All external identifiers defined by a module'simplementation must be prefixed by "<module>_<vendor>_", where

<module>	is the name of the module (containing characters from the set [A-Z0-9]),
<vendor>	is the name of the vendor (containing characters from the set [A-Z0-9]).

For example, TI'simplementation of the FIR module must only contain external identifiers of the form FIR_TI_[a-zA-Z0-9]+. On the other hand, external identifiers that are common to all implementations do not have the "vendor" component of the name. For example, if the FIR module interface defined a constant structure that is used by all implementations, its name simply has the form FIR_[A-Z0-9]+.

In addition to the symbols defined by a module, we must also standardize the symbols referenced by all modules. Algorithms can call HWI disable and HWI restore functions as specified in the DSP/BIOS API References Guides (SPRU403 and SPRU404). These operations can be used to create critical sections within an algorithm and provide a processor-independent way of controlling preemption when used in a DSP/BIOS framework. To use the same algorithm in a non-DSP/BIOS based application, an implementation of these HWI functions can be provided by the framework.

Rule 9

All undefined references must refer either to the operations specified in Appendix B (a subset of C runtime support library functions and a subset of the DSP/BIOS HWI API functions) or TI’s DSPLIB or IMGLIB functions, or other eXpressDSP-compliant modules.

SPRU352G –June 2005 –Revised February 2007 Algorithm Component Model 27

Submit Documentation Feedback