Java“虚拟机”与Python“解释器”说法？ [英] Java "Virtual Machine" vs. Python "Interpreter" parlance?

问题描述

在Java虚拟机中一直使用Python虚拟机似乎很少见。

It seems rare to read of a Python "virtual machine" while in Java "virtual machine" is used all the time.

两者都解释字节码;为什么称其为虚拟机而另一个为解释器？

Both interpret byte codes; why call one a virtual machine and the other an interpreter?

推荐答案

虚拟机是一个具有特定集合的虚拟计算环境原子定义良好的指令，独立于任何特定语言而受支持，通常被认为是一个沙箱。 VM类似于特定CPU的指令集，并且倾向于在更基本的级别上工作，这些指令（或字节代码）的非常基本的构建块独立于下一个。指令仅基于虚拟机的当前状态确定性地执行，并且不依赖于该时间点的指令流中的其他信息。

A virtual machine is a virtual computing environment with a specific set of atomic well defined instructions that are supported independent of any specific language and it is generally thought of as a sandbox unto itself. The VM is analogous to an instruction set of a specific CPU and tends to work at a more fundamental level with very basic building blocks of such instructions (or byte codes) that are independent of the next. An instruction executes deterministically based only on the current state of the virtual machine and does not depend on information elsewhere in the instruction stream at that point in time.

关于该指令的解释器另一方面更复杂，因为它被定制为解析某些语法的流，该语法是特定语言和必须在周围令牌的上下文中解码的特定语法。您不能孤立地查看每个字节甚至每一行，并确切知道下一步该做什么。语言中的标记不能像VM相对于VM的指令（字节代码）那样孤立。

An interpreter on the other hand is more sophisticated in that it is tailored to parse a stream of some syntax that is of a specific language and of a specific grammer that must be decoded in the context of the surrounding tokens. You can't look at each byte or even each line in isolation and know exactly what to do next. The tokens in the language can't be taken in isolation like they can relative to the instructions (byte codes) of a VM.

Java编译器将Java语言转换为字节码流与C编译器没有什么不同，它将C语言程序转换为汇编代码。另一方面，解释器并不真正将程序转换为任何明确定义的中间形式，它只是将程序操作作为解释源的过程。

A Java compiler converts Java language into a byte-code stream no different than a C compiler converts C Language programs into assembly code. An interpreter on the other hand doesn't really convert the program into any well defined intermediate form, it just takes the program actions as a matter of the process of interpreting the source.

VM和解释器之间差异的另一个测试是你是否认为它与语言无关。我们所知道的Java VM并不是特定于Java的。您可以使用其他语言生成编译器，从而生成可在JVM上运行的字节代码。另一方面，我认为我们不会真的想到将Python以外的其他语言编译到Python中以供Python解释器解释。

Another test of the difference between a VM and an interpreter is whether you think of it as being language independent. What we know as the Java VM is not really Java specific. You could make a compiler from other languages that result in byte codes that can be run on the JVM. On the other hand, I don't think we would really think of "compiling" some other language other than Python into Python for interpretation by the Python interpreter.

因为解释过程的复杂性，这可能是一个相对缓慢的过程....具体解析和识别语言令牌等，并理解源的上下文，以便能够在解释器内进行执行过程。为了帮助加速这种解释语言，我们可以在这里定义更容易直接解释的预解析，预标记化源代码的中间形式。这种二进制形式仍然在执行时被解释，它只是从一种人类可读的形式开始，以提高性能。但是，执行该表单的逻辑不是虚拟机，因为这些代码仍然不能孤立地进行 - 周围令牌的上下文仍然很重要，它们现在只是处于一种不同的计算机效率形式。

Because of the sophistication of the interpretation process, this can be a relatively slow process....specifically parsing and identifying the language tokens, etc. and understanding the context of the source to be able to undertake the execution process within the interpreter. To help accelerate such interpreted languages, this is where we can define intermediate forms of pre-parsed, pre-tokenized source code that is more readily directly interpreted. This sort of binary form is still interpreted at execution time, it is just starting from a much less human readable form to improve performance. However, the logic executing that form is not a virtual machine, because those codes still can't be taken in isolation - the context of the surrounding tokens still matter, they are just now in a different more computer efficient form.

这篇关于Java“虚拟机”与Python“解释器”说法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！