【发布时间】：2009-09-21 09:56:23
【问题描述】：
我打算为德州仪器达芬奇平台编写一些图像处理程序。有适合用 C 语言编程的工具，但我想知道是否真的可以在不求助于汇编语言的情况下充分利用 DSP 处理器。您知道在这个 DSP 平台上用 C 和汇编程序编写的程序之间的速度比较吗？
【问题讨论】：
标签： assembly performance signal-processing texas-instruments davinci
【发布时间】：2009-09-21 09:56:23
【问题描述】：
我用过一些其他的 TI DSP，C 通常没问题。通常的方法是先用 C 语言编写所有内容，然后分析代码以查看是否需要手动优化。
您通常也可以在 C 中进行优化，方法是调整 C 代码，直到获得所需的汇编输出。了解 DSP 的工作原理以及哪些工作方式更快或更慢非常重要。
【讨论】：
-
“您通常也可以在 C 中进行优化，方法是调整 C 代码，直到获得所需的汇编输出”——尤其是这种技术在索尼硬件上对我来说一直很有效。
-
@Crash：我也是。这就是我真正想要编译器做的所有事情——让我不必编写 ASM。我不喜欢那些假设我真的不知道自己在做什么的“保姆语言”。
用于 OMAP3 上的 C64x/C64x+ DSP 的 TI 编译器包括对 TI 所谓的“内在”函数调用的支持。它们并不是真正的函数调用，它们只是一种告诉编译器使用什么汇编操作码进行可能无法在 C 中直接表达的操作的方法。它对于利用 C64x/C64x+ DSP 中的 SIMD 操作码特别有用C.
一个例子可能是：
A = _add2(B, C);
此 SIMD 指令将 B 和 C 的低/高 16 位相加，并将结果存储在 A 的低/高 16 位中。您无法在常规 C 中表达这一点，但您可以使用内在函数来做到这一点C 操作码。
我已经使用内部 C 来非常接近使用成熟的汇编语言所能做的事情（在 5-10% 之内）。它对于过滤和运动补偿（_dotpsu4！）等视频功能特别有用。
我通常使用 -al 开关进行编译并查看管道以尝试确定哪些功能单元被重载，然后查看我的内在函数以查看是否可以重新平衡循环（如果我使用了太多的 S 单元，我可能会看看是否可以将操作码更改为使用 M 单元）。
此外，记住 C64x DSP 有 64 个寄存器会很有帮助，因此请加载局部变量并从不将指令的输出分配回同一个变量-- 它会对编译器正确流水线的能力产生负面影响。
【讨论】：
通常 C 是一个很好的起点。您可以快速摆脱整体框架和算法，并编写在真实数学之间移动数据的大部分管道。一旦到位并且您对自己的数据结构正确感到满意，您就可以在分析器中查看并确定哪些例程需要手动压缩。
【讨论】：
-
@Crash：对。我经常发现的是：你知道什么是真正需要时间的（至少在你第一次写的时候）？不是数学。数据结构！
-
我同意。我经常通过重新考虑数据的布局来获得更高的性能。
C 编译器（据我测试）没有充分利用架构。
但您可以侥幸逃脱，因为 DSP 可能足够快，可以完成您需要执行的操作。
因此，归结为测试和分析您的代码，以查看必须加速以使系统正常工作的部分。
【讨论】：
-
是的，不完整，但是你在 C 和 asm 之间得到了什么效率差异？
-
@Michael：如果您想要一个更快的通用答案，我认为这不是一个好问题，因为它始终取决于您正在谈论的特定代码。这就是为什么你需要测试、分析、单步，等等。如果在特定代码中您看到大部分时间都花在特定代码上，并且您可以看到 C 生成了什么，并且您可以看到如何使用 ASM 做得更好，那么这就是 ASM 可以击败 C 的时候。没有通用的答案.
取决于 C 编译器和您对“足够快”的定义。标准 C 编译器通常难以有效利用特殊的 DSP 硬件，例如：
- 多个内存库，可以 并行访问
- 定点数据类型
- 循环缓冲区
【讨论】：
速度的简单比较毫无意义。如果比汇编程序更方便，肯定是 c。您必须衡量系统的时间成本，如果 c 代码满足您对速度的要求，则不必使用汇编程序。如果速度不够，你可以分析你的代码，找出循环代码等最耗时的源代码，然后进行优化！
【讨论】：
我会坚持使用 C，直到我知道有一个热点可以从汇编编码中受益。 This is the "profiling" method I use. 你可能会感到惊讶的是，有一些方法可以加速代码，它们不是热点，而是可以删除的中间函数调用。
【讨论】：
使用 -O3 优化编译。它非常强大。
如果它不够好，您可以根据自己的喜好进一步优化生成的汇编代码，而不是自己在 ASM 中从头开始编写所有代码。
【讨论】：