【发布时间】：2010-11-01 15:04:02
【问题描述】：
不要感到震惊。这是很多文字，但恐怕如果不提供一些详细信息，我将无法真正展示这一切的意义（并且可能会得到很多并不能真正解决我的问题的答案）。这绝对不是一项任务（正如某人在他的评论中荒谬地声称的那样）。
先决条件
由于这个问题可能根本无法回答，除非至少设置了一些先决条件，以下是先决条件：
- 应解释虚拟机代码。不禁止可能有 JIT 编译器，但设计应以解释器为目标。
- VM 应基于寄存器，而不是基于堆栈。
- 答案可能既不假设存在一组固定的寄存器，也不假设存在无限数量的寄存器，任何一种情况都可能是这样。
此外，我们需要更好地定义“更好”。有几个属性必须考虑：
- VM 代码在磁盘上的存储空间。当然，您可以随时放弃此处的所有优化，只压缩代码，但这会对 (2) 产生负面影响。
- 解码速度。如果将代码转换为可直接执行的代码需要很长时间，那么存储代码的最佳方式将毫无用处。
- 内存中的存储空间。此代码必须在有或没有进一步解码的情况下直接可执行，但如果涉及进一步解码，则在执行期间和每次执行指令时完成此编码（在加载代码时仅完成一次解码计入第 2 项）。
- 代码的执行速度（考虑到常见的解释器技术）。
- VM 的复杂性以及为其编写解释器的难度。
- VM 自身需要的资源量。 （如果 VM 运行的代码大小为 2 KB 并且执行速度比眨眼快，这不是一个好的设计，但是它需要 150 MB 来执行此操作，并且它的启动时间远高于代码的运行时间它执行）
现在举例说明我实际上所说的或多或少的操作码。看起来实际上设置了操作码的数量，因为每次操作需要一个操作码。然而，这并不容易。
同一操作的多个操作码
你可以有这样的操作
ADD R1, R2, R3
将 R1 和 R2 的值相加，将结果写入 R3。现在考虑以下特殊情况：
ADD R1, R2, R2
ADD R1, 1, R1
这些是许多应用程序中常见的操作。您可以使用已经存在的操作码来表达它们（除非您需要不同的操作码，因为最后一个操作码具有 int 值而不是寄存器）。但是，您也可以为这些创建特殊的操作码：
ADD2 R1, R2
INC R1
和以前一样。优势在哪里？ ADD2 只需要两个参数，而不是 3，INC 甚至只需要一个。因此，这可以在磁盘和/或内存中进行更紧凑的编码。由于将任何一种形式转换为另一种形式也很容易，因此解码步骤可以在两种方式之间转换以表达这些陈述。不过，我不确定这两种形式对执行速度的影响有多大。
将两个操作码组合成一个
现在假设您有一个 ADD_RRR（R 表示寄存器）和一个 LOAD 来将数据加载到寄存器中。
LOAD value, R2
ADD_RRR R1, R2, R3
您可以拥有这两个操作码并始终在整个代码中使用这样的结构...或者您可以将它们组合成一个新的操作码，命名为 ADD_RMR（M 代表内存）
ADD_RMR R1, value, R3
数据类型与操作码
假设您有 16 位整数和 32 位整数作为本机类型。寄存器是 32 位的，因此任何一种数据类型都适合。现在，当您添加两个寄存器时，您可以将数据类型作为参数：
ADD int16, R1, R2, R3
ADD int32, R1, R2, R3
例如，对于有符号和无符号整数也是如此。这样 ADD 可以是一个短操作码，一个字节，然后你有另一个字节（或者可能只是 4 位）告诉 VM 如何解释寄存器（它们是 16 位还是 32 位值）。或者你可以废弃类型编码，而是有两个操作码：
ADD16 R1, R2, R3
ADD32 R1, R2, R3
有些人可能会说两者完全相同 - 只需将第一种方式解释为 16 位操作码即可。是的，但是一个非常天真的解释器可能看起来完全不同。例如。如果每个操作码有一个函数并使用 switch 语句进行调度（不是最好的方法，函数调用开销，switch 语句也可能不是最优的，我知道），两个操作码可能如下所示：
case ADD16: add16(p1, p2, p3); break; // pX pointer to register
case ADD32: add32(p1, p2, p3); break;
每个函数都以某种添加为中心。第二个可能看起来像这样：
case ADD: add(type, p1, p2, p3); break;
// ...
// and the function
void add (enum Type type, Register p1, Register p2, Register p3)
{
switch (type) {
case INT16: //...
case INT32: // ...
}
}
将子交换机添加到主交换机或将子调度表添加到主调度表。当然，无论类型是否显式，解释器都可以做任何一种方式，但根据操作码设计，无论哪种方式感觉对开发人员来说都更加原生。
元操作码
由于没有更好的名字，我会这样称呼他们。这些操作码本身没有任何意义，它们只是改变了后面的操作码的含义。就像著名的 WIDE 运算符：
ADD R1, R2, R3
WIDE
ADD R1, R2, R3
例如在第二种情况下，寄存器是 16 位（因此您可以添加更多），在第一种情况下只有 8 个。或者，您不能有这样的元操作码，而有一个 ADD 和一个 ADD_WIDE 操作码。像 WIDE 这样的元操作码避免使用 SUB_WIDE、MUL_WIDE 等，因为您始终可以在所有其他正常操作码之前添加 WIDE（始终只有一个操作码）。缺点是单独的操作码变得毫无意义，您必须始终检查它之前的操作码是否是元操作码。此外，VM 必须为每个线程存储一个额外的状态（例如，我们现在是否处于宽模式）并在下一条指令后再次删除该状态。甚至 CPU 也有这样的操作码（例如 x86 LOCK 操作码）。
如何找到一个好的权衡？？？
当然，您拥有的操作码越多，开关/调度表就会变得越大，在磁盘或内存中表达这些代码所需的位数就越多（尽管您可以更有效地将它们存储在数据所在的磁盘上不必由 VM 直接执行）；此外，VM 将变得更加复杂并拥有更多的代码行——另一方面，操作码越强大：您越来越接近每个表达式，即使是复杂的表达式，都将在一个操作码中结束的地步。
选择小的操作码可以很容易地对 VM 进行编码，并且我猜会导致非常紧凑的操作码 - 另一方面，这意味着您可能需要大量的操作码来执行简单的任务以及每个不常用的表达式将不得不成为某种（本机）函数调用，因为它不能使用任何操作码。
我在 Internet 上阅读了很多关于各种 VM 的信息，但没有任何消息来源能够真正做出良好且公平的权衡。设计 VM 就像设计 CPU，有些 CPU 的操作码很少，它们速度很快，但您也需要很多这样的 CPU。并且有许多操作码的 CPU，有些非常慢，但你需要更少的操作码来表达相同的代码。看起来“越多越好”的CPU完全赢得了消费市场，而“越少越好”的CPU只能在服务器市场或超级计算机业务的某些部分生存。虚拟机呢？
【问题讨论】：
-
这不是问题，更像是一个作业。
-
@Javier：这是一个非常明确的问题：“更多操作码还是更少操作码？哪个更好？”。但是，如果没有先决条件，则无法回答（因为最佳答案很大程度上取决于这些）。我宁愿有一种感觉，你甚至连前十句话都没有读过，却做出了这样的嘲讽。我可以对您在此处发布的第二个问题提出相同的主张并投票支持关闭它。
标签： performance interpreter opcode vm-implementation