ARM汇编实现选型：时钟周期与延迟相近的两种方案该如何决策？

当两种实现的单轮操作延迟接近时，可以从以下几个通用维度做选型判断：

• 指令流水线资源占用
  条件加法方案的3条指令（cmp、addlo、addhs）均为ALU运算指令，ARM架构CPU通常配备多组ALU执行单元，这类指令不会抢占Load/Store端口的资源。而查表法的ldrb属于访存指令，需要独占Load端口，如果转换逻辑周边还有其他内存读写操作，查表方案很容易和其他访存指令产生资源竞争，引发流水线停顿，最终的实际吞吐量会明显低于纯计算的条件加法方案。
• 缓存可靠性
  查表法依赖存储在内存中的16字节字符表，即使体积很小，在冷启动、低功耗休眠唤醒后的首次调用场景下，很可能出现L1数据缓存未命中，一次缓存未命中的延迟通常在几十到上百个时钟周期，远超过你预估的3周期开销。而条件加法是纯寄存器操作，完全不存在缓存相关的额外开销，在对实时性要求高的嵌入式场景下表现要稳定得多。
• 代码与存储开销
  条件加法方案不需要额外存储常量字符串，代码段体积更小，不需要占用额外的只读数据段空间。对于Flash、内存资源非常紧张的微控制器场景，纯计算方案能省掉不必要的常量存储开销。
• 特殊场景适配性
  条件加法的纯运算逻辑不需要访问数据段常量，在TrustZone安全域、固件签名校验等对数据段访问有权限限制的场景下，不需要额外配置只读数据段的访问权限，适配成本更低，也不会引入额外的安全风险。
• 后续扩展潜力
  如果后续需要把这套逻辑改造为NEON SIMD实现批量十六进制转换，条件判断的逻辑可以直接用向量比较指令并行处理多个数值，而查表方案在SIMD场景下需要实现向量gather操作，ARMv8.2之前的指令集没有原生的向量gather支持，实现复杂度更高，性能收益也更低。

如果你的使用场景固定在访存压力小、没有严格冷启动实时性要求的设备上，两种方案确实可以按编码偏好选择，否则优先选择条件加法方案。

内容的提问来源于stack exchange，提问作者David C. Rankin