口译员如何解释代码?

时间:2015-01-25 10:17:30

标签: java compilation interpreter bytecode interpreted-language

为简单起见,想象一下这个场景,我们有一台2位计算机,它有一对2位寄存器,称为r1和r2,只适用于立即寻址。

让我们说比特序列 00 意味着添加到我们的cpu。此外 01 表示将数据移至r1, 10 表示将数据移至r2。

因此,这台计算机和汇编程序有一个汇编语言,其中的示例代码将被编写为

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

简单地说,当我将此代码汇编为本机语言时,文件将类似于:

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?如果是,它已经在本机代码中了,那为什么说JIT只是经过多次启动?如果它没有完全转换为0101 1010 0001,那么它会做什么?它如何使cpu做添加?

我的假设可能存在一些错误。

我知道解释很慢,编译代码更快但不便携,虚拟机“解释”代码,但是如何?我正在寻找“如何完全/技术解释”。欢迎使用任何指针(例如书籍或网页)而不是答案。

4 个答案:

答案 0 :(得分:20)

遗憾的是,您所描述的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代码编译器发出的代码有很大不同。以下是C编译器可能将上述内容转换为(pseudo-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分配给寄存器,将常量表的访问替换为移动常量到寄存器(movl %eax, $1),并将堆栈访问重定向到正确的机器寄存器。忽略通常会做的一些优化(复制传播,常量折叠和死代码消除),最终可能会得到这样的代码:

movl %ebx, $1 # ldc 0
movl %ecx, $2 # 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

答案 1 :(得分:2)

Java中的一个重要步骤是编译器首先将.java代码转换为包含Java字节码的.class文件。这很有用,因为您可以获取.class个文件并在任何理解此中间语言的计算机上运行它们,然后逐行进行转换,或者通过chunk-by进行转换。 -chunk。这是java编译器+解释器最重要的功能之一。您可以直接将Java源代码编译为本机二进制文件,但这否定了编写原始代码一次并能够在任何地方运行它的想法。这是因为编译的本机二进制代码将仅在与其编译的相同硬件/ OS体系结构上运行。如果要在另一个体系结构上运行它,则必须在该体系结构上重新编译源代码。通过编译到中级字节码,您不需要拖动源代码,而是字节码。这是一个不同的问题,因为您现在需要一个可以解释和运行字节码的JVM。因此,编译到中间级字节码(然后解释器运行)是该过程不可或缺的一部分。

至于代码的实际实时运行:是的,JVM最终将解释/运行一些二进制代码,这些代码可能与本机编译的代码相同或不同。在一个单行的例子中,它们看起来可能是表面上相同的。但是解释通常不会预先编译所有内容,而是通过字节码并逐行转换为二进制或逐块转换。这有利有弊(与本机编译的代码相比,例如C和C编译器)和许多在线资源以进一步阅读。请参阅我的回答here,或thisthis一个。

答案 2 :(得分:2)

并非所有计算机都具有相同的指令集。 Java字节码是一种世界语 - 一种改善通信的人工语言。 Java VM将通用Java字节码转换为其运行的计算机的指令集。

那么JIT如何在这里找到? JIT编译器的主要目的是优化。通常有不同的方法将某段字节码转换为目标机器码。性能最理想的翻译通常不明显,因为它可能取决于数据。程序在不执行算法的情况下分析算法的程度也有限制 - halting problem是众所周知的此类限制,但不是唯一的限制。因此,JIT编译器所做的是尝试不同的可能转换,并测量它们与程序处理的真实数据执行的速度。因此,在JIT编译器找到完美的翻译之前,需要执行大量的操作。

答案 3 :(得分:1)

简化,解释器是一个无限循环,里面有一个巨大的开关。 它读取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 ++中)。 编译通常比解释慢得多,但必须只进行一次,并且只针对所选方法。