通用计算机乘法运算的硬件、算法及时钟周期成本咨询

主流商用核心的实际算法选型 #

很多人会把Baugh-Wooley和Booth当成两个对立的可选乘法算法，这是工程认知上的典型偏差——实际两者是互补搭配的关系，不存在二选一的场景：

• 从80386开始的所有x86通用核心，以及所有ARM架构的高性能硬核，整数乘法的带符号补码实现，核心都是 改良基4 Booth编码 + Baugh-Wooley符号位修正 + Wallace/Dadda加法树压缩 的组合架构，没有例外。
  • 基4 Booth的作用是把64位乘法原本需要生成64个带符号部分积的流程，压缩到只需要生成32个部分积，直接减半后续加法树的计算负载，是工程上平衡编码器延迟、部分积数量的最优选择——更高阶的基8、基16 Booth虽然能进一步减少部分积数量，但编码器本身的时序开销会快速上升，整体延迟反而没有优势，从来没在通用CPU里大规模商用过。
  • Baugh-Wooley逻辑的作用是把补码乘法里的负权值部分积的符号扩展逻辑统一简化，不需要对每个部分积单独做符号位重复扩展，能减少大概30%的加法树连线数量，是带符号补码乘法的标准电路优化方案，从来不会单独作为独立乘法算法使用。
• 浮点乘法的实现会复用整数乘法的硬件通路：因为IEEE754浮点数的尾数是无符号小数结构，只需要单独处理符号位异或、阶码加减，尾数部分的乘法依然走改良Booth加加法树的路线，不会单独搞一套乘法硬件。
• 没有硬件乘法器的低功耗嵌入式核心，才会用软件循环移位加的方式实现乘法，这部分不存在硬件算法选型的问题。

乘法运算的实际时钟周期开销 #

乘法的延迟完全和微架构的流水拆分深度绑定，没有全行业统一的固定值，但有明确的工程参考区间：

• 早期没有流水拆分的纯组合逻辑乘法器：16位乘法需要上百个时钟周期（比如8086的硬件乘法指令，16位带符号乘法最长需要154个时钟周期），32位乘法的延迟会到数百个周期。
• 90年代之后的流水线化硬件乘法器：32位整数乘法的延迟普遍降到3个时钟周期，吞吐量做到每周期1个乘法操作。
• 现代64位高性能通用核心（x86大核、ARM Neoverse系列）：
  • 64位整数乘法的典型延迟为3~4个时钟周期，大部分大核能做到每周期完成1个乘法，部分调度更宽的核心能做到每周期2个乘法的吞吐量。
  • 这里的核心设计逻辑是：把从Booth编码、部分积生成、加法树压缩到最终结果输出的全链路组合逻辑，拆成2~3级流水，每一级的延迟匹配核心的单周期时钟长度，既可以维持核心的高运行频率，又能让乘法的实际执行效率远高于未拆分的纯组合实现。

常见认知澄清 #

• 不要把Baugh-Wooley和Booth当成二选一的对立算法：前者解决带符号部分积的电路简化问题，后者解决部分积数量的压缩问题，两者是乘法电路里的不同功能模块，不存在替代关系。
• 现代CPU不会使用纯阵列乘法器：纯阵列乘法器的长连线延迟高、面积大，从90年代开始就被加法树压缩的架构替代，同等位宽下延迟比纯阵列低40%以上。
• 乘法的单周期实现从来不是通用CPU的设计目标：全链路组合逻辑延迟如果塞到单周期里，会把核心的最高运行频率拉低30%以上，整体性能反而不如拆流水的设计，所以哪怕是最低频率的嵌入式硬核，也很少做单周期的64位乘法器。

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