c# - 设计一个可以直接处理 IL 的 CPU 有什么意义吗？

Question

如果我理解正确：

当前的 CPU 开发公司，如 AMD 和 Intel，拥有自己的 API 代码（汇编语言），他们认为是机器代码（1G 语言）之上的 2G 语言

是否有可能或希望（性能或其他）拥有一个在其核心执行 IL 处理而不是当前 API 调用的 CPU？

Answer 1

Java 确实存在类似的技术——ARM 提供了一系列可以做到这一点的 CPU，他们称之为“Jazelle”技术。

但是，.net IL 操作码所表示的操作仅结合堆栈中保存的类型信息进行了良好定义，而不是单独定义。这是与 Java 字节码的主要区别，并且会使创建合理的硬件来执行 IL 变得更加困难。

此外，IL 旨在编译为最终目标。大多数吐出 IL 的后端很少进行优化，而是旨在保留语义内容以在最终编译步骤中进行验证和优化。即使可以克服硬件问题，结果几乎肯定仍会比体面的优化 JIT 慢。

所以，总结一下：虽然这不是不可能的，但与其他架构相比，这将是不成比例的困难，而且收效甚微。

Answer 2

您似乎对 CPU 的工作方式有些困惑。汇编不是与机器代码分开的语言。它只是它的不同（文本）表示。

汇编代码只是要执行的指令的顺序列表。和机器码完全一样。CPU 支持的每条指令都有一个特定的位模式来执行它，它还有一个可以在汇编代码中使用的文本名称。

如果我add $10, $9, $8通过汇编程序编写并运行它，我会得到 add 指令的机器代码，获取寄存器 9 和 8 中的值，将它们相加并将结果存储在寄存器 10 中。

汇编程序和机器代码之间存在一对一的映射。

也没有“API 调用”。CPU 简单地从地址 X 读取，并将后续位与它理解的所有指令进行匹配。一旦找到与该位模式匹配的指令，它就会执行该指令，然后继续读取下一条指令。

你所问的在某种意义上是不可能的或矛盾的。IL代表Intermediate Language，即一种由编译器发出但尚未翻译成机器码的伪代码。但是如果 CPU 可以直接执行它，那么它就不再是中间代码，而是机器代码。

所以问题变成了“你的 IL 代码是否比 CPU 现在支持的机器代码更好、更有效地表示程序？”

答案很可能是否定的。MSIL（我假设这就是您所说的 IL，这是一个更笼统的术语）被设计为可移植、简单且一致。每种 .NET 语言都编译为 MSIL，并且每个 MSIL 程序都必须能够被翻译成任何地方的任何 CPU 的机器代码。这意味着 MSIL 必须是通用的和抽象的，而不是对 CPU 做出假设。出于这个原因，据我所知，它是一个纯粹的基于堆栈的架构。每条指令不是将数据保存在寄存器中，而是处理堆栈顶部的数据。这是一个非常干净和通用的系统，但它的效率不是很高，并且不能很好地转化为 CPU 的刚性结构。（在你美妙的高级小世界里，你可以假装堆栈可以自由增长。为了让 CPU 快速访问它，它必须存储在一些有限大小的小型快速片上存储器中。那么如果你的程序在堆栈上推送了太多数据会发生什么？）

Yes, you could make a CPU to execute MSIL directly, but what would you gain? You'd no longer need to JIT code before execution, so the first time you start a program, it would launch a bit faster. Apart from that, though? Once your MSIL program has been JIT'ed, it has been translated to machine code and runs as efficiently as if it had been written in machine code originally. MSIL bytecode no longer exists, just a series of instructions understood by the CPU.

事实上，您将回到 .NET 之前的位置。非托管语言直接编译为机器代码，就像您的建议一样。唯一的区别是，非托管代码的目标机器代码是由 CPU 设计人员设计的，适合在 CPU 上执行，而在您的情况下，它的目标机器代码是由软件设计人员设计的，易于翻译成和从。

Answer 3

这不是一个新想法——Java 也有同样的预测，Lisp 机器甚至已经实现了。

但这些经验表明它并不是真正有用 - 通过设计专用 CPU，您无法从“传统” CPU 的进步中受益，而且您很可能无法在自己的游戏中击败英特尔。维基百科文章中的一句话很好地说明了这一点：

很快，便宜的台式电脑就能够比 Lisp 机器更快地运行 Lisp 程序，而无需使用专用硬件。

即时从一种机器代码转换为另一种机器代码是一个很好理解的问题，而且很常见（现代 CISC CPU 甚至在内部做类似的事情，因为它们真的是 RISC），我相信我们可以假设它已经足够高效地完成了避免它不会产生显着的好处 - 这意味着您必须将自己与传统 CPU 的最新技术脱钩。

Answer 4

我会说不。

需要在计算机上运行的实际机器语言指令的级别低于 IL。例如，IL 并没有真正描述应该如何进行方法调用、应该如何管理寄存器、应该如何访问堆栈，或者机器代码级别所需的任何其他细节。

因此，让机器直接识别 IL 将简单地将所有 JIT 编译逻辑从软件转移到硬件中。

这将使整个过程非常僵化和不可改变。

通过拥有基于机器功能的机器语言和基于捕获程序员意图的中间语言，您将获得一个更好的系统。定义机器的人可以专注于定义高效的计算机架构，定义 IL 系统的人可以专注于表现力和安全性。

如果工具供应商和硬件供应商都必须对所有内容使用完全相同的表示，那么硬件空间或工具空间的创新都会受到阻碍。所以，我说它们应该彼此分开。

Answer 5

我不会这么认为有两个原因：-

1. 如果您有硬件处理 IL，则该硬件将无法运行更新版本的 IL。使用 JIT，您只需要一个新的 JIT，然后现有硬件就可以运行更新的 IL。
2. IL 很简单，并且设计为与硬件无关。IL 必须变得更加复杂，才能以最有效的方式描述操作，以便接近现有机器代码的性能。但这意味着 IL 将更难在非 IL 特定硬件上运行。