gcc - 使用 ARM 周期计数后处理 `objdump --disassemble`

Question

是否有脚本可用于对一些 objdump --disassemble 输出进行后期处理以使用循环计数进行注释？特别是对于 ARM 系列。 大多数情况下，这只是模式匹配与计数表查找。我猜可能需要像 +5M 这样的注释来表示五个内存周期。 Perl、python、bash、C 等都可以。我认为这可以通用地完成，但我对 ARM 很感兴趣，它有一个正交 指令集。这是 68HC11 上的一个主题做同样的事情。该脚本需要一个 CPU model 选项来选择合适的周期数；我认为这些计数已经存在于 gcc 机器描述中。

我认为没有用于此的 objdump 开关，但 RTFM 会很棒。

编辑:澄清一下，当代码从缓存中执行时，最佳情况内存子系统等假设是可以的。目标不是像某些正在运行的机器那样 100% 准确的循环计数。有可能得到一个合理的估计，否则编译器设计是不可能的。

作为DWelch指出，像最近的 Cortex 芯片一样，深度流水线架构无法实现简单的总计。 objdump 后处理必须查看周围的操作码。 gcc 插件更有可能实现这一点，因为它是新的 (4.5+)，我认为这样的东西不存在。 ARM926 的脚本当然是可能的，而且相当简单。

内存延迟无关紧要。内存 Controller 就像另一个 CPU。当 CPU 正在做算术等时，它正在做它的事情。一个好的/调整好的算法将 parallel内存访问与计算。通过计算加载/存储和周期，您可以确定在使用计时器主动分析时完成了多少并行性。由于寄存器之间的互锁，流水线很重要，但是 basic blocks 的循环计数即使在现代 ARM 处理器上也可以可靠地计算和使用；这对于一个简单的脚本来说太复杂了。

Answer 1

在现代高端 ARM 上，仅通过查看指令无法评估周期计数。有很多运行时状态会影响指令在现实世界中的退出率。缓存中是否存在它需要的数据？该指令是否依赖于先前的指令结果？如果是这样，转发单元消除了哪些延迟？加载/存储缓冲区有多满？它涉及什么样的内存映射？该指令需要的处理器流水线有多满？流中是否有同步指令？猜测是否提出了它所依赖的一些数据？寄存器重命名器的状态是什么？条件指令是否已填满流水线，或者解码器是否足够聪明以完全跳过它们？核心时钟与总线和内存时钟之间的比率是多少？分支预测表的大小是多少？

如果没有完整的处理器模拟，您所能得到的只是猜测。这些数字对您是否有意义取决于您试图用它们完成什么。