Texas Instruments TMS320 DSP Manuale Utente

Almost all recently developed software modules follow these common sense guidelines already, so this
chapter just formalizes them. In addition to these guidelines, we also develop a general model of data
memory that enables applications to efficiently manage an algorithm's memory requirements.

All algorithms will follow the run-time conventions imposed by the C programming language. This ensures
that the system integrator is free to use C to "bind" various algorithms together, control the flow of data
between algorithms, and interact with other processors in the system easily.

All algorithms must follow the run-time conventions imposed by TI’s implementation of the C
programming language.

It is very important to note that this does not mean that algorithms must be written in the C language.
Algorithms may be implemented entirely in assembly language. They must, however, be callable from the
C language and respect the C language run-time conventions. Most significant algorithms are not
implemented as a single function; like any sophisticated software, they are composed of many interrelated
internal functions. Again, it is important to note that these internal functions do not need to follow the C
language conventions; only the top-most interfaces must obey the C language conventions. On the other
hand, these internal functions must be careful not to cause the top-most function to violate the C run-time
conventions; e.g., no called function may use a word on the stack with interrupts enabled without first
updating the stack pointer.

Because of the variety of frameworks available for DSP systems, there are many differing types of
threads, and therefore, reentrancy requirements. In this section, we try to precisely define the types of
threads supported by this standard and the reentrancy requirements of algorithms.

A thread is an encapsulation of the flow of control in a program. Most people are accustomed to writing
single-threaded programs; i.e., programs that only execute one path through their code "at a time."
Multi-threaded programs may have several threads running through different code paths "simultaneously."

Why are some phrases above in quotes? In a typical multi-threaded program, zero or more threads may
actually be running at any one time. This depends on the number of CPUs in the system in which the
process is running, and on how the thread system is implemented. A system with n CPUs can, intuitively
run no more than n threads in parallel, but it may give the appearance of running many more than n
"simultaneously," by sharing the CPUs among threads. The most common case is that of n equal to one;
i.e., a single CPU running all the threads of an application.

Why are threads interesting? An OS or framework can schedule them, relieving the developer of an
individual thread from having to know about all the other threads in the system. In a multi-CPU system,
communicating threads can be moved among the CPUs to maximize system performance without having
to modify the application code. In the more common case of a single CPU, the ability to create
multi-threaded applications allows the CPU to be used more effectively; while one thread is waiting for
data, another can be processing data.

Virtually all DSP systems are multi-threaded; even the simplest systems consist of a main program and
one or more hardware interrupt service routines. Additionally, many DSP systems are designed to manage
multiple "channels" or "ports," i.e., they perform the same processing for two or more independent data
streams.

16

SPRU352G – June 2005 – Revised February 2007