我一直在上编译器和工具课程（本学期）。我已经阅读了中间代码生成，并且还看到了 DAG 表示以获得最优性。编译器清楚的一点是，无论生成什么中间代码，它都必须映射到系统的指令集，这样我们才能运行我们的程序。
假设我为特定架构（比如 A）编写了一个编译器，其中两个数字之间的加法是ADD R1、R2、R3（来自 A 的指令集），其中 R1-是目标，R2、R3 是来源。我已经映射了这些指令，也就是说，当我想添加中间代码中表示的两个数字（无论其类型如何，为简单起见）时，我将运行ADD操作码！。
假设新架构已经上市，其中两个数字相加具有不同的指令集，例如AD R1,R2,R3。现在显然我的编译器不会添加数字！
现在我的问题是，当我为我的编程语言编写编译器时，我必须将所有架构与它们的指令集一起添加，以便我的编译器正确地完成它需要做的事情？如果是这样，有什么方法可以优化这个效果？因为添加所有指令集几乎会降低我的性能。
纠正如果我错了！
您为特定指令集构建编译器，该指令集是所选“指令集架构 (ISA)”的子集。（许多指令集都有 I/O 指令，但编译器几乎从不生成这些指令）。可能有几种不同的处理器设计来执行这种“指令集架构”，它们将与您选择的特定指令子集一起工作。
在实践中会发生三种进化事件。
您确定如果使用更多来自 ISA 的指令，您的编译器会更好。例如，您可能决定 MULTIPLY 指令将允许您的编译器生成比您过去用于乘法的子例程调用更快的代码。在这种情况下，您稍微扩展编译器。
ISA 的所有者（英特尔、AMD、IBM ......）将全新的指令集添加到 ISA。例如，对数据高速缓存行的数据并行操作（“SIMD 指令”）。您可以决定将其中一些添加到您的编译器中。这个事件可能很困难，因为新的指令系列通常会对数据的布局和处理方式做出不同的假设。
您会找到一些完全不同的 ISA 来处理。在这种情况下，您将重建编译器的后端，因为指令集在存在哪些寄存器、如何使用它们等方面完全不同。
编译器构建器通常构建编译器以分阶段运行。在生成实际机器代码之前的最后一个阶段通常将程序表示为对相当低级数据的一组抽象操作（例如，对固定字长值的操作），具有相当标准的抽象操作（ADD、MULTIPLY、COMPARE、JUMP、 CALL, STORE, LOAD, ...) 对实际 ISA 没有任何承诺（尤其是没有关于寄存器或特定机器指令的承诺）。这样做可以独立于 ISA 进行更高级别的优化；只需将其视为良好的模块化。最后几个阶段专门针对 ISA；通常在阶段分配寄存器，然后是模式匹配实际指令与抽象指令的阶段。
有整本书是关于更高层次的优化的，还有其他关于最终代码生成状态的书（而且通常是在单独的章节中讨论这两个问题的书）。[Aho&Ullman Dragon 的书和 Torczon 的 Engineering a Compiler 在这两个主题上都是相当不错的书）。有很多技术可以让人们写下最终的指令集和寄存器布局，并将生成大部分最后阶段；海湾合作委员会有这样的。那项技术很复杂，不适合这句话；最好去看看书。
一旦您以这种方式获得了适用于第一个 ISA 的编译器，您就可以使用相同的技术构建一个变体。您最终会得到两个物理编译器，每个 ISA 一个。他们共享所有前端逻辑和抽象代码生成和优化。它们在最后阶段完全不同。
您应该了解的是，构建编译器以利用指令集是一个复杂的过程。
这一切都取决于变化有多大。假设您有带有指令 ADD R1、R2、R3 的 ISA X 1.0。如果你得到一个新版本 X 1.1，它将指令 ADD R1、R2、R3 替换为 AD R1、R2、R3，则变化很小。本质上，您有不同名称的相同指令。您可以使用标志 cc -arch X1.1 来适应这种变化，该标志将发出“AD”而不是“ADD”。
如果更改较大，例如 AD R1、R2 (R2 <- R1 + R2)，则新指令与旧 ADD 不同。在这种情况下，您需要更改代码生成器并将此指令包含在您的可用指令集中。同样 cc -arch X1.1 应该让生成器知道该指令可用。
如果更改更大，例如将编译器重新定位到 ISA Y，那么您需要更改代码生成器生成的所有指令。这可能是很多工作。
现在，现有的低级编译器优化是否适用于新目标也是值得怀疑的。一般来说，定义良好的后端（如 gcc）可以支持许多 ISA。它使用低级中间表示（IR），您的指令具有多个属性，包括操作码名称（“ADD”或“AD”）。然而，低级优化器并不像指令的其他属性那样关心名称，即它有多少操作数？读/写哪些操作数？它访问内存吗？它会改变程序流程吗？等等
如果您可以将您的目标架构调整到编译器框架中，那么您可以成功地利用现有的优化。