ARM 处理器（新旧）是否使用微代码？如果是，那么用于什么？它们的指令不够简单，可以直接执行而无需转换为微操作吗？
答案1
TL,DR;虽然 ARM 处理器使用与微编码 CPU 类似的概念（例如，有一个硬件块将指令解码为一个或多个微操作）， 他们是不是 传统意义上的微码使用 ROM 来存储每条微指令，并且这些微指令/操作在实际硬件中产生后无法被修改。事实上，ARM 处理器使用硬线控制在指令解码器中生成微操作。
然而，在实践中，修改指令解码器类似于修改微码处理器，因为 ARM 授权硬件描述语言（高密度脂蛋白) 向各个制造商提供其 CPU 架构的源代码，从而使硬件级修改更容易实现。请参阅指令译码器部分在微处理器设计 Wikibook 中可以了解典型的 RISC 和 CISC 指令解码器之间的更多区别。
虽然 ARM 架构本身不是传统意义上的微代码，单独的指令是 解码为更小的微操作。现代 ARM 处理器远非“简单”——尽管指令本身非常正交，但现代 A9 核心拥有许多现代技术（例如流水线、超标量指令、乱序执行、缓存、扩展复杂指令，如浮点单元或 NEON 指令）。事实上，任何处理器都可以足够简单，无需转换为微操作即可执行，但这本质上是把“所有鸡蛋都放在一个篮子里”——您无法纠正指令集中可能存在的任何错误，也无法在生产后对其进行扩展/修改。
然而，如果我们只谈论指令解码阶段，那么确实许多 ARM 处理器不是微代码化的方式允许事后修改，尽管这可能是因为大多数获得 ARM 技术许可的制造商都有权访问实际的硬件源代码（以 HDL 编写）。这降低了功耗，因为不需要微代码阶段，但各个指令被“编译”到实际的硬件块中。这也允许每个制造商进行错误更正。
事实上，即使在基于CISC的CPU（例如x86）中，也没有要求对于使用微代码。然而，在实践中，指令集的复杂性，加上许可、功耗和应用程序的各种差异，使得微代码的选择对于 x86 的情况来说是理想的。然而，在 ARM 的情况下，它不太有用，因为对指令集（解码器）的更改在硬件本身方面更容易实现和控制（因为它可以由制造商定制）。
虽然在某些情况下微代码实际上可以简化处理器的设计（因为每条指令都以“微程序”的形式存在，而不是实际的硬件），但这实际上只是一个指令解码器（例如Thumb-2 扩展，通过添加一个允许可变长度指令存在单独的指令译码器与 ARM 指令解码器一致）。虽然从功能上讲，这些单元可以使用微代码实现，但从功耗的角度来看，这并不明智，因为您需要在 CPU 本身中定义每个控制信号的输出，即使这不是必需的。这确实不是与实际 CPU 本身的“复杂程度”有任何关系，因为 ARM 内核具有人们所期望的所有现代构造（流水线、指令/数据缓存、微 TLB 缓冲区、分支预测、虚拟内存等...）。
对于 ARM，考虑到指令集的正交性，实施这种微编码方法的复杂性将超过直接在指令解码器块中更改相关硬件所带来的好处。虽然这当然是可能的，但最终会“重新发明轮子”，因为您能够直接修改（并编译/测试/模拟）硬件中的更改。
在这种情况下，您可以将 ARM 源代码本身“视为”一种微编码，尽管它们不是将每个微操作/微程序存储在事后可以修改的 ROM 中，而是直接在指令解码器的硬件中实现。鉴于指令解码器本身是用 VHDL/Verilog 编写的，对现有指令进行更改就像修改源代码、重新编译和测试新硬件（例如在 FPGA 或模拟器上）一样简单。这与现代 x86 硬件的复杂性形成了鲜明对比，后者在开发过程中测试/模拟要困难得多，在生产后修改则更加困难（因为晶体管的尺寸远远超过了即使在最昂贵的现代 FPGA 中也能运行的尺寸，因此使用微代码存储增加了优势）。当然，同样的事实也适用于 ARM，但不同之处在于开发 - 人们可以对处理器硬件进行更改，然后直接查看/测试更改身体的使用 FPGA 的硬件。