但是今天再来看这所有的一切是完全不一样了。首先是DSP的应用范围越来越广，客户越来越多的希望用同一颗芯片，在同一个平台上实现更多的设计和应用。这对DSP的设计，DSP和MCU的融合都带来重大影响。DSP和MCU之间也不是过往那井水不犯河水的安宁。随着DSP和MCU的主频先后突破1GHz，在很多应用中DSP和MCU相伴相生的场景也开始被一颗强壮的芯代替，或者DSP或者MCU。在这样的应用中，操作系统，文件系统，USB协议栈，TCP/IP，海量数据存储，样样都会用到。数字信号处理也从骨灰级的滤波器变成全系列音视频处理，OFDM基带处理，天线阵列信号处理，彩色图像重建… 试想一下这些应用哪一个不是成千上万行代码。汇编语言在编程复杂度，可移植性和可维护性上真的是遇到了前所未有的挑战。而与此相对应的是C语言和C语言编译器的蓬勃发展。今天您可以很容易找到上面提到所有这些应用和算法的C语言实现，而C语言编译器在编译效率和成熟度上都有很大的突破。也让C语言在DSP上的应用得以受到愈来愈高的重视。
我用的是28XX系列的，不知道经验对你有没有用，因为不同系列的芯片多少有些差别。TI提供的库已经相当可以了，兼顾易用与效率。我当时做过这样的测试
1. 用IQMATH实现
2. 直接C语言实现
3. C语言优化实现
4. 原生汇编实现
IQMATH的运行周期在1000左右，比方案3快几十个周期，比方案4慢几个周期，方案2是10000多个周期。
另外，因为只是单独测的算法，汇编之所以快是快在寄存器的使用上，操作数可以直接入寄存器，但是考虑到程序其他部分是用C语言编写的话，把操作栈的时间也加上，并不比方案1快。毕竟我对TI的汇编吃的也不透。
在编写上，无疑是方案1提供了最接近C语言风格的实现，几乎不用考虑ISA方面的问题。
另外对于执行效率，我觉得主要考虑三点：
1.分支的使用
CCS对C语言的优化我没做过太多比对。其实单从反汇编的结果看，我接触过的嵌入式开发环境的编译器都能做出很好的优化。但是几乎每个编译器都会在逻辑的优化上有欠缺——它只能对一些显而易见的判断条件进行优化，而在写程序的过程中，我们经常出于易读性的考虑，或者稳定性的考虑，或者其他的考虑加入几乎不会发生的分支，这样的分支判断会消耗一定比率的代码段执行效率，视乎代码段内有用功能的长度而定，越长这个比率越小，越短这个比率越高。
2.一般操作，就是各种赋值操作
在一般的操作上，编译器的优化已经很令人满意了，基本上可以作为编写汇编的范本。我觉得所谓效率能达到90%就是针对这个部分说的。
3.特殊操作，比如对整块内存的操作，或者是浮点运算上。
在一些特殊的操作上，就要看是否有现成的库，或者看硬件是否支持。比如对整块内存操作就别用循环一个字节一个字节的搬了。
以上三点都能考虑到的话，相信执行效率方面已经没有太大的提升空间了。
另外如果你的代码发生在初始化部分，也就是只在系统运行开始的时候运行一次，那么优化不优化其实没有太大的必要，除非你对系统初始化的时间有严格的要求。但是如果你的代码是作为任务要被反复运行的，那就有优化的必要了。
在CCS里有代码消耗时钟周期的统计，如果你觉得某段代码效率低下的话，可以先分段进行消耗时钟周期的计算，这样优化比较有针对性。
