来自 Wiki 的困惑：C# 和 Java 是解释型的？
在 EN Wiki 上我读到 C# 和 Java 都是解释性语言，但至少对于 C# 我认为这不是真的。
许多解释语言首先被编译成某种形式的虚拟语言 机器代码，然后在运行时解释或编译 到本机代码。
根据我的理解，它被编译成 CIL 并在运行时使用 JIT 将其编译到目标平台。我还读到 JIT 是一个解释器，真的是这样吗？ 或者它们被称为解释型，因为它们使用中间代码？我不明白。 谢谢
On the EN Wiki I read that both C# and Java are interpreted languages, however at least for C# I think it is not true.
Many interpreted languages are first compiled to some form of virtual
machine code, which is then either interpreted or compiled at runtime
to native code.
From my understanding, it is compiled into CIL and when run, using JIT its compiled to target platform. I have also read that JIT is an interpreter, is that really so?
Or are they called interpreted as they are using intermediate code? I do not understand it.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
JIT 是一种编译为本机（机器）代码的形式。 通常（但不是必需的），CLI 和 JVM 的实现分两步进行编译：
确实存在。例如，微框架作为 IL 解释器运行。同样，像（在这里查看 .NET）NGEN 和“AOT”（单声道）这样的工具允许在开始时编译为本机/机器代码。
JIT is a form of compilation to native (machine) code. Typically (but not as a necessity), implementations of either the CLI and JVM are compiled in two steps:
However, interpreters for both do exist. Micro Framework operates as an IL interpreter, for example. Equally, tools like (looking .NET here) NGEN and "AOT" (mono) allow compilation to native/machine code at the start.
它们被视为不同于解释的 JIT 语言。 JIT 只是在执行过程中需要时编译为本机代码。常见的策略是预先编译成中间表示（字节码），这使得 JIT 更快。
然而，没有什么可以阻止它们被解释，甚至静态编译。语言只是语言——从语言的角度来看，它们如何执行是无关紧要的。
They are considered JIT languages which is different from interpreting. JIT simply compiles to native code when needed during execution. The common strategy is to compile into an intermediate representation (bytecode) beforehand which makes the JIT faster.
However, there is nothing that prevents them from being interpreted, or even statically compiled. Languages are simply languages - how they are executed is irrelevant from a language perspective.
您能提供链接吗？
可能解释这个词在这里的意思不同。这可能意味着这些语言首先被解释为将源代码转换为与平台无关的代码。（VM 特定）
我也这么认为。
JIT 是一个编译器。请参阅此
Can you pls provide the link?
May be the interpreted word means different here. It perhaps means that these languages are first interpreted to convert source code into platform-independent code.(VM Specific)
I too think so.
JIT is a compiler. See this
是否是“解释器”取决于讨论的上下文。
从纯粹抽象的角度来看，解释器可以定义为运行时存在的任何中间程序，它将用一种语言编写的程序代码动态翻译为其他语言的硬件/软件的目标代码。考虑一下在 x86 硬件上运行 java 字节码，或者在 CLR VM 上运行 Python（IronPython 到底是什么）。从这个角度来看，每个虚拟机都是某种解释器。由于它是运行时存在的程序，因此它与静态编译器或硬件实现的 VM 明显不同。
现在有许多不同的方法来实现此功能，其中重点是“动态”和“在运行时存在”。
在讨论 VM 的实现很重要时，人们明确区分了“经典”解释器和 JIT 解释器。经典解释器是为托管程序的每条指令发出目标代码例程的东西。这种设计构建起来很简单，但很难优化。 JIT 设计读取一堆原始代码指令，然后将所有这些指令转换为一个本机编译例程。所以它“解释”得更快。它就像虚拟机中的微型静态编译器。有许多不同的方法可以完成标记为 JIT 的行为，还有其他方法，例如跟踪编译器。
CLR、HotSpot 和 J9 JVM 等现代 VM 甚至比使用 JIT 或解释器等简单标签进行标记还要复杂。它们可以同时是静态编译器（AOT 执行）、经典解释器和 JIT 虚拟机。
例如，CLR 可以提前编译代码（静态编译器），并将本机代码作为一堆或多或少的可执行文件存储在磁盘上，以便将来更快地启动托管程序。我相信“ngen”是 Windows 中用于此功能的 AOT 进程。如果不使用 AOT，则 CLR 的行为与 JIT VM 相同。
J9 和 HotSpot 能够在运行时根据代码分析和当前负载在纯解释执行或 JIT 执行之间切换。所以这是一个相当灰色的区域。 J9甚至具有类似于CLR的AOT功能。
其他一些虚拟机（例如 Maxine JVM 或 PyPy）是所谓的“元循环”虚拟机。这意味着它们（大部分）是用它们托管的相同语言实现的（Maxine 是用 Java 编写的 JVM）。为了提供好的代码，他们通常会使用主机语言实现一些类似于 JIT 的行为，然后由非常低的、接近机器的解释器进行引导和优化。
因此，解释器的实际定义因讨论的上下文而异。当使用像 JIT 这样的标签时，就会明显强调正在讨论的 VM 的实现细节。
Is something "interpreter" or not depends on context of discussion.
From purely abstract view interpreter can be defined as any intermediate program present in runtime which dynamically translates program code written in one language to a target code of hardware/software of other language. Think about runing java bytecode on x86 hardware, or running Python on CLR VM what exactly IronPython is. In this view every virtual machine is an interpreter of some kind. As it is program present in runtime it clearly differs from static compilers or hardware implemented VM-s.
Now there are many different ways to achieve this functionality where accent is on "dynamically" and "present in runtime".
In discussions where implementation of VM matters, people make clear distinction between "classical" interpreter and JIT-ed one. Classical interpreter is something which for every instruction of hosted program emits routine of target code. This design is simple to build, but hard to optimize. JIT-ed design reads bunch of instruction of original code, and then translates all those instructions to a one native compiled routine. So it "interprets" faster. It is like micro static compiler within VM. There are many different ways to accomplish behavior labeled as JIT, and then there are other approaches like tracing compilers.
Modern VM's like CLR, HotSpot and J9 JVM's are even more complex than to be tagged with simple labels as JIT or Interpreter. They can be at a same time static compilers (AOT execution), classical interpreters and JIT-ed VMs.
For example CLR can compile code Ahead-Of-Time (static compiler), and store native code as bunch of more or less excutable files on disk to be used for faster future startups of hosted program. I believe "ngen" is AOT process used in windows for this functionality. If AOT is not used CLR behaves as JIT VM.
J9 and HotSpot are able to switch in runtime between purely interpreted execution or JIT-ed on depending of code analysis and current load. So it's is quite gray area. J9 even has AOT functionality similar to CLR.
Some other VMs like Maxine JVM or PyPy are socalled "metacircular" VM. This means they are (mostly) implemented in a same language they host (Maxine is JVM written in Java). In order to provided good code they usually have some JIT like behavior implemented in host language which is than bootstrapped and optimized by a very low, close to machine, interpreter.
So actual definition of interpreter varies on context of discussion. When labels like JIT are used then there is clear accent of discussion to an implementation details of VM being discussed.