解释器如何解释代码？

Question

为简单起见，想象一下这种情况，我们有一台 2 位计算机，它有一对 2 位寄存器，称为 r1 和 r2，并且只能使用立即寻址。

假设位序列 00 意味着 add 到我们的 cpu。 01 表示将数据移动到 r1，10 表示将数据移动到 r2。

所以这台计算机有一个汇编语言和一个汇编程序，示例代码可以这样写

mov r1,1
mov r2,2
add r1,r2

简单地说，当我 assemble 将此代码转换为本地语言时，文件将类似于：

0101 1010 0001

上面的 12 位是以下的本机代码：

Put decimal 1 to R1, Put decimal 2 to R2, Add the data and store in R1.

所以这基本上就是编译代码的工作原理，对吧？

假设有人为此架构实现了 JVM。在 Java 中，我将编写如下代码：

int x = 1 + 2;

JVM 将如何解释这段代码？我的意思是最终必须将相同的位模式传递给 cpu，不是吗？所有 cpu 都有许多它可以理解和执行的指令，它们毕竟只是一些位。假设编译后的 Java 字节码看起来像这样：

1111 1100 1001

或其他什么..这是否意味着解释在执行时将此代码更改为 0101 1010 0001？如果是，那么它已经在Native Code中了，那么为什么说JIT只是在多次之后才开始呢？如果它没有将它准确地转换为 0101 1010 0001，那么它会做什么呢？它如何使 cpu 进行加法运算？

可能我的假设有一些错误。

我知道解释很慢，编译后的代码更快但不可移植，虚拟机 "interprets" 一个代码，但是如何？我正在寻找 "how exactly/technically interpreting" 完成了。欢迎任何指针（例如书籍或网页）而不是答案。

Answer 1

Java 中的一个重要步骤是编译器首先将 .java 代码翻译成 .class 文件，其中包含 Java 字节码。这很有用，因为您可以在任何理解这种 中间语言 的机器上获取 .class 文件和运行它们，然后在现场逐行翻译行，或逐块。这是java编译器+解释器最重要的功能之一。您可以直接将 Java 源代码编译为本机二进制文件，但这否定了一次编写原始代码并能够运行在任何地方使用它的想法。这是因为编译后的本机二进制代码只会运行在编译它所针对的相同 hardware/OS 架构上。如果你想运行它在另一种架构上，你必须重新编译那个架构上的源代码。编译到中级字节码，不用拖源码，拖字节码。这是一个不同的问题，因为您现在需要一个可以解释和运行字节码的 JVM。因此，编译为中级字节码，解释器然后运行s，是该过程的一个组成部分。

至于实际的实时运行代码：是的，JVM 最终会 interpret/run 一些二进制代码，这些代码可能与本机编译代码相同，也可能不同。在一个单行示例中，它们表面上看起来是一样的。但是解释通常不会预编译所有内容，而是遍历字节码并逐行或逐块转换为二进制。这有利也有弊（与本机编译的代码相比，例如 C 和 C 编译器）并且有很多在线资源可供进一步阅读。看我的回答here, or this, or this一个

Answer 2

并非所有计算机都具有相同的指令集。 Java 字节码是一种世界语——一种改善交流的人工语言。 Java VM 将通用 Java 字节码翻译成它运行的计算机的指令集。

那么 JIT 在这里是如何计算的呢？ JIT 编译器的主要目的是优化。将一段特定的字节码翻译成目标机器码通常有不同的方法。性能最理想的翻译通常是不明显的，因为它可能取决于数据。程序在不执行算法的情况下可以分析算法的程度也有限制 - halting problem 是一个众所周知的限制，但不是唯一的限制。因此，JIT 编译器所做的是尝试不同的可能翻译，并测量它们对程序处理的真实世界数据的执行速度。因此，在 JIT 编译器找到完美的翻译之前需要多次执行。

Answer 3

不幸的是，您描述的 CPU 体系结构太过局限，无法通过所有中间步骤使这一点真正清楚。相反，我将编写伪 C 和伪 x86 汇编程序，希望以一种清晰的方式编写，而不用非常熟悉 C 或 x86。

编译后的 JVM 字节码可能如下所示：

ldc 0 # push first first constant (== 1)
ldc 1 # push the second constant (== 2)
iadd # pop two integers and push their sum
istore_0 # pop result and store in local variable

解释器在一个数组中有这些指令的（二进制编码），以及一个指向当前指令的索引。它还有一个常量数组，一个用作堆栈的内存区域和一个用于局部变量的内存区域。然后解释器循环看起来像这样：

while (true) {
    switch(instructions[pc]) {
    case LDC:
        sp += 1; // make space for constant
        stack[sp] = constants[instructions[pc+1]];
        pc += 2; // two-byte instruction
    case IADD:
        stack[sp-1] += stack[sp]; // add to first operand
        sp -= 1; // pop other operand
        pc += 1; // one-byte instruction
    case ISTORE_0:
        locals[0] = stack[sp];
        sp -= 1; // pop
        pc += 1; // one-byte instruction
    // ... other cases ...
    }
}

这 C代码被编译成机器码和运行。如您所见，它是高度动态的：它会在每次执行指令时检查每个字节码指令，并且所有值都会通过堆栈（即 RAM）。

虽然实际的加法本身可能发生在寄存器中，但围绕加法的代码与 Java-to-machine code 编译器发出的代码有很大不同。以下是 C 编译器可能将上述内容转换为（伪 x86）的摘录：

.ldc:
incl %esi # increment the variable pc, first half of pc += 2;
movb %ecx, program(%esi) # load byte after instruction
movl %eax, constants(,%ebx,4) # load constant from pool
incl %edi # increment sp
movl %eax, stack(,%edi,4) # write constant onto stack
incl %esi # other half of pc += 2
jmp .EndOfSwitch

.addi
movl %eax, stack(,%edi,4) # load first operand
decl %edi # sp -= 1;
addl stack(,%edi,4), %eax # add
incl %esi # pc += 1;
jmp .EndOfSwitch

您可以看到加法的操作数来自内存而不是硬编码，即使对于 Java 程序而言它们是常量。那是因为对于解释器，它们不是常数。解释器编译一次，然后必须能够执行各种程序，而无需生成专门的代码。

JIT 编译器的目的就是：生成专用代码。 JIT 可以分析堆栈用于传输数据的方式、程序中各种常量的实际值以及执行的计算顺序，以生成更高效地执行相同操作的代码。在我们的示例程序中，它将局部变量 0 分配给一个寄存器，将对常量 table 的访问替换为将常量移入寄存器 (movl %eax, )，并将堆栈访问重定向到正确的机器寄存器.忽略一些通常会完成的优化（复制传播、常量折叠和死代码消除），最终可能会得到这样的代码：

movl %ebx,  # ldc 0
movl %ecx,  # ldc 1
movl %eax, %ebx # (1/2) addi
addl %eax, %ecx # (2/2) addi
# no istore_0, local variable 0 == %eax, so we're done

Answer 4

简单来说，解释器是一个无限循环，里面有一个巨大的开关。它读取 Java 字节码（或一些内部表示）并模拟 CPU 执行它。这样真实的 CPU 执行解释器代码，模拟虚拟的 CPU。这是痛苦的缓慢。添加两个数字的单个虚拟指令需要三个函数调用和许多其他操作。单个虚拟指令需要执行几条真实指令。这也降低了内存效率，因为您同时拥有真实和模拟的堆栈、寄存器和指令指针。

while(true) {
    Operation op = methodByteCode.get(instructionPointer);
    switch(op) {
        case ADD:
            stack.pushInt(stack.popInt() + stack.popInt())
            instructionPointer++;
            break;
        case STORE:
            memory.set(stack.popInt(), stack.popInt())
            instructionPointer++;
            break;
        ...

    }
}

当某些方法被多次解释时，JIT 编译器会启动。它将读取所有虚拟指令并生成一个或多个执行相同操作的本机指令。在这里，我使用文本程序集生成字符串，这需要额外的程序集到本机二进制转换。

for(Operation op : methodByteCode) {
    switch(op) {
        case ADD:
            compiledCode += "popi r1"
            compiledCode += "popi r2"
            compiledCode += "addi r1, r2, r3"
            compiledCode += "pushi r3"
            break;
        case STORE:
            compiledCode += "popi r1"
            compiledCode += "storei r1"
            break;
        ...

    }
}

生成本机代码后，JVM 会将其复制到某处，将此区域标记为可执行，并指示解释器在下次调用此方法时调用它而不是解释字节码。单个虚拟指令可能仍需要多个本机指令，但这几乎与提前编译为本机代码（如 C 或 C++）一样快。编译通常比解释慢得多，但只需执行一次并且只针对选定的方法。

解释器如何解释代码？

How does an interpreter interpret the code?

java

interpreter

bytecode

interpreted-language

compilation