Texas Instruments TMS320 DSP User Manual Page 19
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
2.3 Data Memory
Data Memory
void PRE_filter1(int input[], int length, int *z)
{
int I, tmp;
for (I = 0; I
< length; I++) {
tmp = input[i] - z[0] + (13 * z[1] + 16) / 32;
z[1] = z[0];
z[0] = input[i];
input[i] = tmp;
}
}
This technique of replacing references to global data with references to parameters illustrates a general
technique that can be used to make virtually any Code reentrant. One simply defines a "state object" as
one that contains all of the state necessary for the algorithm; a pointer to this state is passed to the
algorithm (along with the input and output data).
typedef struct
PRE_Obj { /* state obj for pre-emphasis alg */
int z0;
int z1;
} PRE_Obj;
void
PRE_filter2(PRE_Obj *pre, int input[], int length)
{
int I, tmp;
for (I = 0; I < length; I++)
{
tmp = input[i] - pre->z0 + (13 * pre->z1 + 16) /
32;
pre->z1 = pre->z0;
pre->z0 = input[i];
input[i] = tmp;
}
}
Although the C Code looks more complicated than our original implementation, its performance is
comparable, it is fully reentrant, and its performance can be configured on a "per data object" basis. Since
each state object can be placed in any data memory, it is possible to place some objects in on-chip
memory and others in external memory. The pointer to the state object is, in effect, the function's private
"data page pointer." All of the function's data can be efficiently accessed by a constant offset from this
pointer.
Notice that while performance is comparable to our original implementation, it is slightly larger and slower
because of the state object redirection. Directly referencing global data is often more efficient than
referencing data via an address register. On the other hand, the decrease in efficiency can usually be
factored out of the time-critical loop and into the loop-setup Code. Thus, the incremental performance cost
is minimal and the benefit is that this same Code can be used in virtually any system—independent of
whether the system must support a single channel or multiple channels, or whether it is preemptive or
non-preemptive.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root
of all evil." —Donald Knuth "Structured Programming with go to Statements," Computing Surveys, Vol. 6,
No. 4, December, 1974, page 268.
The large performance difference between on-chip data memory and off-chip memory (even 0 wait-state
SRAM) is so large that every algorithm vendor designs their Code to operate as much as possible within
the on-chip memory. Since the performance gap is expected to increase dramatically in the next 3-5
years, this trend will continue for the foreseeable future. The TMS320C6000 series, for example, incurs a
25 wait state penalty for external SDRAM data memory access. Future processors may see this penalty
increase to 80 or even 100 wait states!
SPRU352G – June 2005 – Revised February 2007 General Programming Guidelines 19
Submit Documentation Feedback
- User's Guide 1
- Submit Documentation Feedback 2
- Contents 3
- Read This First 7
- Related Documentation 8
- Text Conventions 8
- Overview 9
- 1.1 Scope of the Standard 10
- 1.1.1 Rules and Guidelines 11
- 1.3 Goals of the Standard 12
- 1.4 Intentional Omissions 12
- 1.5 System Architecture 13
- 1.5.1 Frameworks 13
- 1.5.2 Algorithms 14
- 1.5.3 Core Run-Time Support 14
- Chapter 2 15
- 2.1 Use of C Language 16
- 2.2 Threads and Reentrancy 16
- 2.2.1 Threads 16
- 2.2.3 Reentrancy 17
- 2.2.4 Example 18
- 2.3 Data Memory 19
- 2.3.1 Memory Spaces 20
- Data Memory 21
- 2.4 Program Memory 23
- 2.5 ROM-ability 23
- 2.6 Use of Peripherals 24
- Algorithm Component Model 25
- 3.1 Interfaces and Modules 26
- 3.1.1 External Identifiers 27
- 3.1.2 Naming Conventions 28
- 3.1.4 Module Instance Objects 28
- Interfaces and Modules 29
- 3.1.7 Module Configuration 30
- 3.1.8 Example Module 30
- 3.1.10 Interface Inheritance 32
- 3.1.11 Summary 32
- 3.2 Algorithms 33
- 3.3 Packaging 34
- 3.3.1 Object Code 34
- 3.3.2 Header Files 35
- 3.3.3 Debug Verses Release 35
- Packaging 36
- Chapter 4 37
- 4.1 Data Memory 38
- 4.1.1 Heap Memory 38
- 4.1.2 Stack Memory 39
- 4.2 Program Memory 40
- 4.3 Interrupt Latency 41
- 4.4 Execution Time 41
- 4.4.1 MIPS Is Not Enough 41
- 4.4.2 Execution Time Model 42
- Execution Time 43
- DSP-Specific Guidelines 45
- 5.1 CPU Register Types 46
- 5.2 Use of Floating Point 47
- 5.3.1 Endian Byte Ordering 47
- 5.3.2 Data Models 47
- 5.3.3 Program Model 47
- 5.3.4 Register Conventions 48
- 5.3.5 Status Register 48
- 5.3.6 Interrupt Latency 49
- 5.4.1 Data Models 49
- 5.4.2 Program Models 49
- 5.4.3 Register Conventions 51
- 5.4.4 Status Registers 51
- 5.4.5 Interrupt Latency 52
- 5.5.1 Stack Architecture 52
- 5.5.2 Data Models 52
- 5.5.3 Program Models 53
- 5.5.4 Relocatability 53
- 5.5.5 Register Conventions 54
- 5.5.6 Status Bits 55
- 5.6 TMS320C24xx Guidelines 57
- 5.6.1 General 57
- 5.6.2 Data Models 57
- 5.6.3 Program Models 57
- 5.6.4 Register Conventions 57
- 5.6.5 Status Registers 58
- 5.6.6 Interrupt Latency 58
- 5.7.1 Data Models 58
- 5.7.2 Program Models 59
- 5.7.3 Register Conventions 59
- 5.7.4 Status Registers 59
- 5.7.5 Interrupt Latency 60
- Use of the DMA Resource 61
- 6.1 Overview 62
- 6.2 Algorithm and Framework 62
- 6.4 Logical Channel 63
- 6.5 Data Transfer Properties 64
- 6.7 Abstract Interface 65
- 6.8 Resource Characterization 66
- 6.9 Runtime APIs 67
- 6.15.1 Non-Preemptive System 71
- 6.15.3 Preemptive System 72
- Rules and Guidelines 75
- A.1 General Rules 76
- A.3 DMA Rules 77
- A.4 General Guidelines 78
- A.5 DMA Guidelines 79
- Core Run-Time APIs 81
- Bibliography 83
- Glossary 85
- Glossary of Terms 86
© 2020, manymanuals.com. All rights reserved. | 2.868 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals