Ti c64x 优化基本策略

Ti c64x 优化基本策略
以下摘自新浪博客

一、优化流程一般分为三个阶段。

阶段一：直接按照需要用C语言实现功能。在实际的DSP应用中，许多算法直接用汇编代码编写，虽然优化效率很高，可是实现的难度却很大，所以一般先用C语 言来实现，然后编译运行，利用C64X开发环境的profile; clock工具测试程序运行时间，若不能满足要求，则进行第二阶段。

阶段二：C语言级的优化。选择C64X开发环境提供的优化方式以及充分运用其他技巧，优化C代码，若还不能满足效率要求，则进行第三步。

阶段三：汇编级的优化。将上一阶段C程序中优化效率较低的部分提出来，用线性汇编语言编写，利用汇编优化器进行优化。汇编优化器的作用是让开发人员在不考 虑C64X流水线结构和分配其内部寄存器的情况下，编写线形汇编语言程序，然后汇编优化器通过分配寄存器和循环优化将汇编语言程序转化为利用流水线方式的 高速并行汇编程序。上述的三个阶段不是都必须经过，当在某一阶段获得了期望的性能，就不必进行下一阶段的优化。

二、选用C编译器提供的优化选项

● -o：使能软件流水和其他优化方法

● -pm：使能程序级优化

● -mt：使能编译器假设程序中没有数据存储混淆，可进一步优化代码。

● -mg：使能分析（profile）优化代码

● -ms：确保不产生冗余循环，从而减小代码尺寸

● -mh：允许投机执行

● -mx：使能软件流水循环重试，基于循环次数对循环试用多个方案，以便选择最佳方案。

三、减小存储器相关性为使指令达到最大效率

   C64X编译器尽可能将指令安排为并行执行。为使指令并行操作，编译器必须知道指令间的关系，因为只有不相关的指令才可以并行执行。当编译器不能确定 两条指令是否相关时，则编译器假定它们是相关的，从而不能并行执行。设计中常采用关键字const来指定目标，const表示一个变量或一个变量的存储单 元保持不变。因此，在代码中加入关键字const，可以去除指令间的相关性。例如下面的程序：

void vecsum(short *sum,short*in1,short*in2,unsigned int N)

{ int i;

   for(i=0;i

   sum=in1+in2;

}

写sum可能对指针in1、in2所指向的地址有影响，从而in1和in2的读操作必须等到写sum操作完成之后才能进行，降低了流水效率，为帮助编译器确定存储器的相关性，使用const关键字来指定一个目标，上面的源程序可改为含关键字const的优化源代码：

void vecsum(short *sum, const short*in1,const short*in2,unsigned int N)

{ int i;

for(i=0;i

    sum=in1+in2;

}

由于使用了关键字const，消除了指令之间的相关路径，从而使编译器能够判别内存操作之间的相关性，找到更好的指令执行方案。

四、 使用内联函数（intrinsics）

内联函数是C64X编译器提供的专门函数，它们与嵌入式的汇编指令是一一对应的，其目的是快速优化C源程序。在源程序中调用内联函数，与调用一般的函数相 同，只不过内联函数名称前有下划线作特殊标识。当汇编指令功能不易采用C语言表达时，可采用内联函数表示。例如在定点运算中经常要求出源操作数的冗余符号 位数，这一功能如果用C完成的话，需要的源程序代码冗长，有较多的逻辑操作和判断跳转，运行效率低下。若用内联函数，则是result =_norm(src1)，减少了代码长度，提高了运行效率。因此对于需要大量C代码才能表示的复杂功能，应该尽量用C64X的内联函数来表示。

五、short型数据的int处理

   C64XDSP具有双16bit扩充功能，芯片能在一个周期内完成双16bit的乘法、加减法、比较、移位等操作。在设计时，当对连续的short型 数据流操作时，应该转化成对int型数据流的操作，这样一次可以把两个16位的数据读入一个32位的寄存器，然后用内部函数来对它们处理（如_sub2 等），充分运用双16bit扩充功能，一次可以进行两个16bit数据的运算，速度将提升一倍。

六、尽量少进行函数调用

   函数调用的时候，要将PC和一些寄存器压栈保存，函数返回时，则将这些寄存器出栈返回，增加了一些不必要的操作。所以一些小的函数，最好是用适当的内 联函数代替直接写入主函数里，一些调用不多的函数，也可以直接写入主函数内，这样可减少不必要的操作，提高速度。但是这样往往会增加程序的长度，因此是一 种利用空间换取时间的办法。

七、 尽量使用逻辑运算代替乘除运算

   在DSP里，乘除运算指令的执行时间要远远超过逻辑移位指令，尤其是除法指令，在设计的时候，可以根据实际情况，进行一些调整，尽量用逻辑移位运算来代替乘除运算，这样可以加快指令的运行时间。

八、软件流水线技术的使用

   软件流水线技术用来对一个循环结构的指令进行调度安排，使之成为多重迭代循环并行执行。在编译代码时，可以选择编译器的-o2或-o3选项，则编译器 将根据程序尽可能地安排软件流水线。在DSP算法中存在大量的循环操作，因此充分地运用软件流水线方式，能极大地提高程序的运行速度。但使用软件流水线还 有下面几点限制：

● 循环结构不能包含代码调用，但可以包含内联函数。

● 循环计数器应该是递减的。

● 循环结构不能包含break，if语句不能嵌套，条件代码应当尽量的简单。

● 循环结构中不要包含改变循环计数器的代码。

● 循环体代码不能过长，因为寄存器（32个）的数量有限，应该分解为多个循环。

   在软件流水线的运用上，应该尽量使复杂的循环分解成简单的小循环，以避免寄存器的数量不够；对于过于简单的循环，应该适当的展开，以增加代码数量，增加流水线中的迭代指令。

九、 采用指令乱序技术

程序中，有些指令的执行顺序没有严格的要求，可以作出一些位置上的调整，因此可以适当的调整这些指令的位置，穿插于其他的指令之中，从而减小指令的相关 性，增加运行时的并行性。尤其在循环里，当循环体较小的时候，可以把多个循环的代码写在一个循环体里，合并成一个循环，从而减小循环内指令的相关性，增加 指令运行的并行性。但是要注意不要使循环过于复杂，以至不能进行软件流水线的优化。

于C语言编译出来的程序，不是最有效率的汇编语言，而没有办法达到实时播放。所以为了要使程序执行的速度能够加快，必须要做最佳化，使其能够达到实时播放 的速度。然而C6x 的编译器也提供了最佳化的指令，如在编译时加上-o3 的参数，它可以用软件来分析我们的程序是否有可以改进的地方，如此一来，在产生组语的汇编语言档案之前，编译器会对我们写的C语言程序不断的进行编译，也 会对程序中的循环部份重新编排，产生另一较有效率的核心循环，以最有效率的方式重新编排程序，来加快程序速度。

方法一; 把浮点运算改成定点运算

因为C6x DSP板并不支持浮点运算，但我们的原始程序代码是浮点运算的格式，所以必须改成定点运算，而其修改后的执行速度也会加快很多。我们采用 Q-format 规格来表示浮点运算。以下将介绍其相关原理。定点DSP使用固定的小数点来表示小数部份的数字，这也造成了使用上的限制，而为了要分类不同范围的小数点， 我们必须使用Q-format的格式。不同的Q-format表示不同的小数点位置，也就是整数的范围。表2呈现Q15数字的格式，要注意在小数点后的每 一位，表示下一位为前一位的二分之一，而MSB (most-significant-bit ) 则被指定成有号数 ( Sign bit )。由表2可以知道，当有号数被设成0而其余位设成1时，可得到最大的正数 (7FFFH ) ；而当有号数被设成1而其余位设成0时，可得到最大的负数（ 8000H ) 。所以Q15格式的范围从-1到0.9999694 (@1) ，因此我们可以藉由把小数点向右移位，来增加整数部份的范围，如表3所示，Q14格式的范围增为-2.0到1.9999694 (@2) ，然而范围

的增加却牺牲了精确度。

方法二; 建立表格 ( table )

原来程序的设计是除了要读AAC的档案外，在译码时，还要再另外读取一些C语言程序代码的内容再做计算，如读取一些数值做sin、cos、exp的运 算，但是为了加快程序的执行速度，故将这这些运算的结果建成表格，内建在程序中，可以不必再做额外的计算动做，以加速程序。

方法三; 减短程序的长度

   1.去除Debug的功能原本程序在Debug的阶段时，就加了许多用来侦测错误的部份，程序Debug完后，已经没有错误发生，所以就可以把这些部份给去除，以减少程序的长度，也可以减少程序执行时的时脉数，加快程序的速度。

   2.去除计算时脉 ( clock ) 功能原本程序可以计算执行程序所需的时脉数，我们也可以把这些部份给去除，如果有需要计算时脉时,我们可以用C6x的工具软件来作，功能更强大。

方法四; 减少I/O 过程

原本在做译码的动作时，是先读取AAC档案的一部份做译码，译码完成后再读取下一部份，再做译码。但是由于C6x的板子跟PC做档案读取时相当的缓慢， 读取的动作占了大部份的时间，所以就将程序改成先将AAC档案全部读到C6x的内存中，再做译码。或是将AAC建成表格(约1 MB)，以避免DSP板上的内存不足。

方法五; 减少子程序的呼叫

在呼叫子程序时，必须先将缓存器的内容放到堆栈 (stack) 中，而从子程序返回时，也要将这些缓存器原本的内容从堆栈中取出来。但是有些子程序的长度很短，而且被呼叫的次数又很多，往往几个时脉就可以完成却浪费时 间在存取堆栈的内容上，所以干脆将这些很短的子程序直接写在主程序当中，以减少时脉数。

方法六; 写汇编语言

虽然由C语言所编译出来的汇编语言可以正确无误的执行，但是这个汇编语言却不是最有效率的写法，所以为了增加程序的效率，于是在某些地方，例如一些被呼叫很多次且程序代码不长的函式(function)，必须改以自己动手写汇编语言来取代。

方法七; 利用平行处理的观念

   C6x是一颗功能强大的处理器，它CPU的内部提供了八个可以执行不同指令的单元，也就是说最多可以同时处理八个指令。所以如果我们可以用它来作平行处理，我们就可以大大的缩短程序执行的时间，最有效率的来利用它来作解碼的动作。

   最后还要知道：

第三级优化(-O3)，效率不高（经验），还有一些诸如用一条读32位的指令读两个相邻的16位数据等，具体情况可以看看C优化手册。但这些效率都不高 （虽然ti的宣传说能达到80%，我自己做的时候发现绝对没有这个效率！65%还差不多），如果要提高效率只能用汇编来做了。还有要看看你的c程序是怎么 编的，如果里面有很多中断的话，6000可以说没什么优势。

还有，profiler的数据也是不准确的，比实际的要大，大多少不好说。还有dsp在初始化的时候特别慢，这些时间就不要和pc机相比了，如果要比就比核心的部分。

关于profile：

   C6x的Debug工具提供了一个profile界面。在图9中，包括了几个重要的窗口，左上角的窗口是显示出我们写的C语言，可以让我们知道现在做 到了哪一步。右上角的窗口显示的是C6x所编译出来的汇编语言，同样的我们也可以知道现在做到了哪一步。左下角的窗口是命令列，是让我们下指令以及显示讯 息的窗口。而中间的profile窗口就是在profile模式下最重要的窗口，它显示出的项目如下表：表5：profile的各项参数字段意义被呼叫的 次数包含子程序的总执行clock数; 包含子程序的执行一次最大clock数不包含子程序的总执行clock数; 不包含子程序的执行一次最大clock数利用这个profile模式我们可以用来分析程序中每个函数被呼叫的次数、执行的时脉数等等。用这个分析的结果， 我们就可以知道哪个函数所花费的时脉最多，是可以再改进的，而针对它来作最佳化。

汇编代码级的优化

在经过C代码的优化之后，还不能满足性能上的要求，则可以通过clock工具找出效率很低的部分，使用线性汇编重新改写。再通过汇编优化器编译，汇编优化器从输入的线性汇编代码中，完成以下功能：

● 寻找可以平行执行的CPU指令。

● 在软件流水线期间，处理流水线标号。

● 分配寄存器的用法。

● 分配功能单元。

   TI提供的汇编优化器可以得到很高的效率，一般可以满足性能上的要求。

优化中的问题

在优化过程中，总是要对程序进行一定的改动，这样经常会出现一些问题。

   1) 优化结果的验证优化过的程序往往不知道是否运行正确，这就需要加以验证。一般采用的办法就是通过测试序列来验证。测试序列指的是对于不同的算法所取的一组 特殊的数据，这些数据可以准确的反映算法的特性。测试序列中每组数据包括输入数据和输出数据，通过对输入数据的运算，把结果与输出数据进行比较，判断程序 的正确性。一些常见的算法，一般都提供了测试序列。还有一些，没有测试序列。这时就需要根据算法的特点，自己构造测试序列，进行验证。构造的时候，注意序 列最好有几组，数据最好有一定的长度，这样验证的更准确。

   2) 内存泄漏的问题：C64X系列DSP的内部存储空间有1MB，其中程序和数据还有CPU的二级缓存将共享这片空间，因此当程序的运行不正常时，很有可能就是内存泄漏造成的。因此，在程序设计中，应尽量不用指针，同时注意进行边界检测。

程序设计的一些方法

   程序设计时，一切以满足实际的要求为目标。在实际的设计中，除了优化能够提高性能以外，还可以采取其他的办法，利用DSP的特性，提高程序的运行性能，满足实际的设计要求。

   1) 把程序和经常要用的数据放入片内RAM; 片内RAM与CPU; 工作在同一时钟频率，比片外RAM性能高得多。因此把程序放在片内可以大大提高运行的速度。同时对于一些经常要用到的数据，放入片内，也会节省处理时间。

   2) 通过DMA技术搬移数据; 对于C64X芯片，其片内RAM有1MB，但是对于一些大型的图像处理算法而言，仍可能是不够的，因此经常通过DMA技术，把需要用到的数据搬入片内，把不需要的搬到片外，可以大大的提高程序的运行速度。

   3) CACHE的使用增大CACHE，可以明显的提高性能。但是C64X系列DSP中程序和数据还有CACHE共享片内RAM，因此增大CACHE，就减小了实际的片内可用空间，设计中需要注意

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/henhen2002/archive/2009/09/14/4549936.aspx