为啥arm架构比x86 x64省电？ 第1页

原答案没有在原理上解释 ARM 为什么比 X86 更省电，所以我在做完本科毕业设计后准备重写一下该部分内容

我的本科毕业设计为在 FPGA 上使用 VerilogHDL 制作一个 CPU 软核，虽然做的是最简单的 RISC-V，但是其实在做的过程中多多少少也有了解 Intel X86 这边的 ISA 设计

下面我具体从原理上来分析一下 X86(IA-32) 存在的一些设计问(shi屎)题(shan山)

为了描述准确性并且与 x86_64 做区分，下文统一使用 IA-32 替代容易引起歧义的 X86，IA-32 通常指的是兼容 Intel 386 系列 CPU 的指令集，目前绝大部分 X86 CPU 都支持 IA-32 （即使这个 CPU 是 64-bit 的）

不定长指令

目前主流的 ARM，MIPS，RISC-V 几乎都是定长指令集

然而 IA-32 是著名的不定长指令集，意味着单发射架构下其取指令效率将会很低

来看看 IA-32 这边，opcode 存在 1-bit 或者 2-bit 的情况，mod-r/m 存在有和没有的情况，s-i-b byte 也存在有和没有的情况，后面的 address displacement 和 immdiate 不仅仅存在有和没有的情况，还存在 4，2，1，0 bytes 这 4 种情况。

然而你以为这就完了？

再来看看有 prefix 的情况

IA-32 是支持以上四种 prefix 同时附加在一条指令前面，甚至不要求顺序，意味着会有 4! 种情况

所以 Intel 的指令长度是不等长

有人说不等长好办，我解码出上一条指令，然后再根据上一条指令的长度计算下一条指令该从哪个内存地址取指令就好了呗。那你再想想，隔壁 ARM 如果用的双通道 2 * 64-bit = 128-bit 内存位宽，一个周期可以同时取出 4 条定长指令，你 IA-32 一个周期才取出一条，或者干脆连一条指令都取不完，例如四个 prefix 全上，immediate 是 full-size 的 32-bit，那你还得等下一个周期

其实这还不算最糟糕的，最糟糕的是不定长指令会经常导致内存不对齐，内存不对齐意味着上一条指令读取了 128-bit 里面的 112-bit，而下一条指令可能是 144-bit，意味着你得先取剩下的 16-bit，再取一个完整的 128-bit，再取一个 16-bit，如果内存是单通道 32-bit，那你算算需要跨多少个 DRAM 周期？

而定长指令集或者半定长指令集（例如只存在 32-bit 和 16-bit 两种长度的就叫半定长指令集）做内存对齐则方便很多，遇到 32-bit 和 16-bit 交错取指令的情况下，只需要编译器或者 CPU 自动插入一个 16-bit 的冒泡或者 NOP 指令，就能让下一条指令对齐

然而你会说，那我要速度，我做多发射总可以吧。当然可以。

那么问题就来了，同样是多发射，ARM 用 128-bit 的内存位宽可以一个 cycle 发射 4 条 32-bit 的指令，并且这里 的 4 发射 decoder 利用率是百分之百，即每个发射窗口的指令都确保是有效指令，即有效做功/总做功=100%。

IA-32 这边由于指令不定长，运气好如果全是 1-byte opcode 的单字节指令，128-bit 的内存位宽可以发射 128/8=16 条指令，速度比 ARM 快多了，这也是通常所说的 CISC 指令密度高的原因。

然而也有运气不好的时候，遇到一条 128-bit 的指令，只有 offset=0 的这个 decoder 能解码出一条有效指令并且发射到后端 EU（Execute Unit），剩下 15 个 decoder 全部都在做无用功，此时能耗效率为 1/16=0.0625，即 6% 的能耗效率，这耗电量，大家心里应该有个数吧。

8086 兼容模式（real mode，实地址模式）

成也萧何败也萧何。

Intel X86 系列 CPU 的发家本领就是极强的兼容性，碰上 Windows 这个同样及其看重兼容性的操作系统，wintel 这个软硬件组合才在多轮技术革新中存活到现在。没有客户，尤其是没有商业客户能够接受某一天更换到性能更好的 CPU 之后，之前写的一切软件都无法运行。

龙芯总设计师在论文中提到过，现代软件的设计成本极大，而相对来说 CPU 量产后的单位成本其实并不高，一块 CPU 几千块钱，然而一套工业软件的研发费用可能是数百甚至数千万，编译这些软件所使用的 gcc 等编译器又是无数社区工程师对某一特定指令集架构进行日积月累迭代优化完成的，相对来说在 CPU 层面做兼容比把成千上万的高价值软件和编译器重写一遍要更加划算。

而对 x86 16-bit real mode 的兼容一做就是几十年，一直保持到现在。

虽然现在 UEFI 已经有人提议可以脱离real mode，直接以保护模式运行，但是不怕一万就怕万一，IA-32 的 CPU 服务于全球客户，这里面无法避免会有需要用到 real mode 的客户，也无法避免现在还有的设备在用 CSM BIOS，CSM BIOS 在 POST 以及引导 OS 阶段仍然处于 real mode 下

这一系列兼容 real mode 的数字电路，包括经典的 Code Segment << 4 + IP，A20 地址线取模等 feature 都得一直保持兼容性直到现在

这些电路的存在，也会微小地增大面积和耗电

过时指令

BCD 编码是一种现在看来很过时的编码方式（有更好的解决方式，例如 SRAM LUT 查找表，软件译码）

但是 IA-32 为了兼容性仍然不得不继续保留这些过时的指令。

你可能会问，现在这些指令还有程序在用吗？其实你每时每刻每分每秒都在用它，因为电脑的时钟其实就是用 BCD 编码存储在主板的 CMOS 芯片内。还有很多上古时代的软件，谁知道他们还在不在用这些指令。CPU 仍然要为这些过时的指令做译码逻辑单元。

冗余的标志位

其实标志位仍然是为了增加指令密度而设计，例如 Zero Flag 配合 CX 专用寄存器可以使得某些指令的 opcode 变短并且无需携带立即数

像 RISC-V 就移除了标志位设计，因为 RISC-V 对程序员可见的通用寄存器高达 31 个，也不存在 CX 这种专用寄存器，完全可以在通用寄存器里面用条件判断和大小比较指令判断是否溢出或者结果是否为 0

由于 IA-32 没有类似于 ARM Cortex 的 bit-band 概念，所以同样不得不为这些 Flags 的 SET 和 RESET 操作单独设计多个 opcode，同样占用了宝贵的指令空间和芯片面积与功耗

非统一寻址

无论是 RISC-V 还是 ARM ，他们对外设都是统一寻址，即 将外设挂载到某个特定的内存地址上，若需要对这些外设进行操作，直接像读写普通内存一样读写这些地址即可。

然而同样是历史原因，Intel 选择了 I/O 和 Memory 非统一寻址。虽然 I/O 和 Memory 共用 address 和 data 总线，但是会通过 IO/M 引脚的高低电平进行寻址方式切换。

为了区分这两种寻址方式，IA-32 又不得不为这些内存地址设计一系列的指令，包括 byte，word 等不同宽度的指令，并且软件设计也将变得复杂

最令人头疼的是有一些设备是内存寻址，又有一些设备是 I/O 寻址，设计与管理非常割裂。

X87 FPU

早期集成电路资源紧张，很多客户又用不到浮点运算，所以 Intel 干脆把 FPU 单独做成一个 co-processor 协处理器。然而与这个协处理器通信又和普通外设还不太一样，IA-32 专门为它设计了一系列机制，包括 CPUID，中断错误，I/O 地址，功能引脚（PEREQ, BUSY, ERROR）等，毕竟自家的产品，搞特殊化嘛还是可以理解，只是没想到这个特殊化又成为了一个兼容性包袱，让本就复杂的 IA-32 指令集在复杂度上雪上加霜。

TSS 任务硬切换

其实 Linux 等主流 OS 似乎早就不再用 IA-32 的任务硬切换机制，改用软件实现了。然而这一系列复杂的指令仍然将一直存于 IA-32 之中。

其实 IA-32 的很多设计都有当时的历史原因，例如存储芯片价格昂贵导致很多指令是尽可能做更多事情或者隐式包含更多信息（例如DS，CX，AX等专用寄存器），并且由于兼容性，很多 feature 加上之后就不可能再移除了，导致无形之中为这些现在看起来很差劲的设计付出一些功耗和复杂度的取舍。

因为有些 feature 你不做，客户一定不会用到，但是你一旦做了，那么总有客户会用到，你就不能在后续的版本移除了。

像 AMD 仅仅移除了极少一部分指令，就导致 Win98 无法安装与运行，进而使得一些软硬件开发行业的客户不敢购买 AMD 的 CPU，因为指不定哪天又来个指令集上的缺斤短两导致程序运行出错或者不稳定，那就麻烦了，宁愿贵一点钱买 Intel ，就当买个保险。

ARM 相对来说有后发制人优势，抛弃了很多现在看来没有意义的烂设计。而且在服务器等对多核与能效比优先于单核性能领域的场景来说确实有更大优势。

当然现在无论是 ARM 还是 Intel CPU 后端实际上都是解码成 uop 进行运行，在后端上差别已经很小了。

IA-32 这些功耗上的问题，更多是针对超低功耗领域而言的，例如一个 100W 功耗的 CPU，多出 0.5W 功耗浪费在这些历史设计上其实无伤大雅，但是对于手机等嵌入式设备，总共满载才 1W，而这些过时的历史设计就浪费了 0.5W，相比来说一半的能源浪费还是非常值得重视的，这也是为什么你不会在智能手表等领域上看到有搭载 Intel X86 CPU 的情况发生。