ARM Cortex-M3平台相同机器码函数执行速度差50%的原因排查

这是一个非常典型的基于SAM3X8E（Cortex-M3）Flash控制器预取机制的行为问题，结合你的测试数据、反汇编结果和补充验证，核心原因完全指向Flash预取单元（PFU）的行对齐策略与线性预取行为，下面拆解具体细节：

1. SAM3X8E Flash预取单元的核心特性 #

SAM3X8E的Flash控制器集成了一个预取缓冲单元，专门用于加速Cortex-M3内核的指令读取：

• Flash被划分为固定大小的预取行（通常为64字节，对应SAM3X的Flash访问粒度）
• 预取单元会自动从当前执行地址的下一个位置，预取整行指令到缓冲中，内核可以无等待地从缓冲读取指令
• 如果指令执行跨越预取行边界，或者函数起始地址导致指令分布在多个预取行，预取单元需要重新加载新的行，这会引入额外的Flash访问等待周期（SAM3X在48MHz主频下默认有1个等待周期，未命中时会叠加）

2. 你的测试结果与预取行为的对应关系 #

结合你给出的函数地址和测试点，我们可以逐一对应：

• 地址与预取行分布：你的calc（0x80149）和calc2（0x8017D）地址都在同一个64字节预取行（0x80140 ~ 0x8017F）内，但calc的起始地址靠近行开头，calc2靠近行末尾。calc的指令长度约52字节，从0x80149到0x8017D，完全在同一预取行内；而calc2从0x8017D开始，指令会延伸到下一个预取行（0x80180 ~ 0x801BF），执行后半段指令时需要加载新的预取行，等待周期累积后最终慢50%。
• 对齐调整测试：当你调整calc2的起始地址到预取行对齐位置时，它的指令可以被预取单元一次性加载到缓冲，命中率提升，速度自然接近calc；反之，给calc内部的.in递归标签加对齐，会让递归入口处于预取行边界，每次递归都需要重新加载预取行，直接拖慢了calc的速度。
• 位置交换测试：交换两个函数的Flash位置后，calc的指令会跨预取行，calc2的指令完全在一个预取行内，速度差异反转，这直接验证了预取行分布是核心因素。
• 单独运行测试：单独运行时，预取单元有足够时间提前加载整个函数的指令（包括跨行部分），而先后运行时，前一个函数的预取缓冲可能占用了资源，导致后一个函数的跨行部分需要重新加载，所以差异明显。

3. 为什么机器码一致却有差异？ #

你已经通过arm-none-eabi-objdump确认了机器码和调用约定完全一致，但指令在Flash中的物理位置（预取行内的偏移、是否跨行）直接决定了预取单元的命中率，这是与指令内容无关的硬件行为——相同的指令，放在不同的预取行位置，执行效率会因为预取等待周期的累积而产生巨大差异。

4. 验证与解决方案 #

如果要进一步验证或解决这个问题，可以：

• 用arm-none-eabi-readelf查看两个函数的起始地址对齐属性，确认calc是否被编译器自动添加了预取行对齐（编译器通常会给函数加上__attribute__((aligned(64)))或类似属性）
• 手动给calc2添加对齐属性：int calc2() __attribute__((aligned(64)));，重新编译后测试速度是否与calc一致

内容的提问来源于stack exchange，提问作者fscheidl