基于TMS320C6416的DRM音频解码实现及优化

最简单的执行优化的方法是用cl6x编译程序[5]，在命令行设置-On选项即可。n是优化的级别(n为0、1、2或3)，它控制优化的类型和程度。-O3级别下，编译器可对循环代码实现软件流水[6]，优化器将会充分利用处理器的8个功能单元，尽可能多地生成并行指令，使最后的可执行代码运行速度达到最高，以达到优化代码的目的。
软件流水是用来安排循环指令并使这个循环多次迭代并行执行的一种技术。简单循环情况下，软件流水能够正常的发挥作用，但在多层嵌套循环情况下，软件流水往往会失败。简化循环是充分发挥软件流水的通用而有效的办法。如本文中一个函数reordered_spectral_data( )中存在多达5层嵌套的for循环，有的循环中还有条件分支函数，在-O3优化情况下，解一个超帧10次调用这个函数之后，共花费7 613 426个周期，与其他函数开销相比如图3(a)所示。这是因为优化器只能对最内层的循环进行软件流水操作，而外层的循环只能按照原语句执行，于是大量语句只能以最慢的方式执行。

经过对这个函数中的循环语句进行分析和调试，同时参照AAC标准，在保证功能正确实现的基础上对该函数做如下改进：这个函数的功能是将打乱顺序的霍夫曼码字重新排序，并进行霍夫曼解码。在码字重新排序的过程中有码书查找的步骤，编码时码书的选择是有优先级别的，解码时需要从最高级到最低级依次判断是否存在以这个码书编码的码字，如果有就进行解码，没有就判断下一个码书，每判断一个码书就是一次大循环。事实上，码书级别都很低，先前大部分循环中判断的码书都是错误的，所以可以另外用一个小的循环检查出级别最高的码书，这样就会在真正解码的嵌套循环中省去许多无用的循环。另外在嵌套的for循环中，有一层是针对窗组进行的循环，即有几个窗组需要解码，就循环几次。事实上，窗组往往只有一个，多窗组的情况极为少见，所以这层for循环在大部分情况下可以去除。但多窗组的情况毕竟存在，可以事先用一个if条件判断窗组个数，再根据结果条件执行相应的程序。这就使程序在大多数情况下能够节省大量的运行时间，因为它会执行软件流水生成的代码，而在极少情况下会执行效率最慢的未经优化的代码。
按照上述的分析进行优化之后，结果如图3(b)所示。reordered_spectral_data()函数优化之后的开销为：10次调用这个函数共花费1 029 512周期，与优化前的7 613 426周期相比，运行速度提高了7倍多。

(3)消除存储器相关性。如果C6416编译器可以确定两条指令是不相关的，则安排它们并行执行，否则安排指令串行执行。有几个方法可以帮助编译器确定哪些指令不相关：使用restrict关键字声明指针；一起使用-pm选项和-O3选项确定程序优先级，在程序优先级中，所有源文件都被编译成一个模块，从而使编译器更有效地消除相关性；使用-mt选项向编译器说明代码不存在存储器相关性，即允许编译器在无存储器相关性的假设下进行优化。
　(4)使用内联函数。C6416编译器提供的内联函数是直接映射为内联指令的特殊函数，内联函数的代码高效、长度短。可以使用内联函数并行优化C代码。
(5)在循环前加上#pragma MUST_ITERATE(, ,)，向编译器传递循环次数信息，编译器会生成更好的循环代码，或消除因不知道循环次数而产生的冗余循环以便减小整个代码量。
4 DRM音频解码器的测试结果
通过实施上述各种优化方法，从算法程序上的等效替代到充分利用编译的优化功能，音频解码程序运行效率有了明显的提高。下面是同一个超帧解码中每个子帧花费的周期数，总计数周期为2 641 488，与优化前程序花费的27 855 831个周期相比，运行时间不到原来的1/10。
子帧1：396 470 子帧2：250 626
子帧3：247 983 子帧4：226 120
子帧5：254 623 子帧6：224 668
子帧7：231 056 子帧8：254 901
子帧9：277 520 子帧10：279 424
(共计2 641 488周期)
从表1可以看出，优化后一些函数的访问次数为0，这是由于优化采用了内联函数的功能，它们的代码被内联在一些较大的函数中，如faad_getbits( )函数；另一种情况：如对于pns_decode( )函数，由于DRM系统的音频编码标准中的SBR技术提供了相当于PNS的功能，所以AAC中的PNS模块没有使用，优化中被删除。对比表1中优化前后数据可知，很多函数花费的周期大大减少，如decode_scale_factors函数等。

本文给出了DRM音频解码器在TMS320C6416上的实现方案，并结合TMS320C6416的特性，从去除无用函数、内联函数替换、循环体优化等多方面对音频解码程序进行了优化。在