www.ti.com
Packaging
Rule 13
Each of the IALG methods implemented by an algorithm must be independently relocatable.
In practice, this simply means that each method should either be implemented in a separate file or placed in a separate COFF output section. By placing each of these methods in a separate file or output section, the linker can be used to eliminate those methods that are unnecessary in systems that do not require
In some cases, it is awkward to place each function in a separate file. For example, doing so may require making some identifiers globally visible or require significant changes to an existing Code base. The TI C compiler supports a pragma directive that allows you to place specified functions in distinct COFF output sections. This pragma directive may be used in lieu of placing functions in separate files. The table below summarizes recommended section names and their purpose
Section Name | Purpose |
.text:algActivate | Implementation of the IALG algActivate method |
.text:algAlloc | Implementation of the IALG algAlloc method |
.text:<name> | Implementation of the IALG <name> method |
In other words, an algorithm'simplementation of the IALG method <name> should be placed in a COFF section named ".text:<name>".
Since the IALG interface does not define methods that can be used to actually run an algorithm, it is important that each abstract algorithm interface extend (or "derive") from the IALG interface. Thus, every algorithm has considerable flexibility to define the methods that are appropriate for the algorithm. By deriving from IALG, we can ensure that all implementations of any algorithm implement the IALG interface.
Rule 14
All abstract algorithm interfaces must derive from the IALG interface.
3.3Packaging
In this section, we cover the details necessary for a developer to bundle a module into a form that can be delivered into any TMS320 DSP Algorithm Standard development system. It is important to recall that a module'simplementation may consist of many object files and at least one C header file. By following these conventions, algorithm developers can be sure that their components can be seamlessly integrated into any TMS320 DSP Algorithm Standard development environment. Moreover, these conventions are designed to enable TMS320 DSP Algorithm Standard development environments to easily manage an arbitrary collection of
In many cases, the TMS320 DSP Algorithm Standard requirements simply amount to file naming conventions. In order to ensure that a single component can be used in both UNIX and Windows development environments, it is necessary to
∙never create two files whose names only differ in case, and
∙always treat file names as being
3.3.1 Object Code
Rule 15
Each
All of the object Code files for a module should be archived into a library with the following name:
<module><vers>_<vendor>.l<arch>
where
34 | Algorithm Component Model | SPRU352G |
