如果不解释 C#，那么为什么需要 VM？答案

【问题标题】：If C# is not interpreted, then why is a VM needed?如果不解释 C#，那么为什么需要 VM？
【发布时间】：2012-03-04 15:53:20
【问题描述】：

我读过很多关于 C# 的争议，有人说它是解释型的，有人说它不是。我确实知道它已编译到 MSIL 中，然后在运行时 JITed，具体取决于处理器等……但它不是仍以需要 VM (.NET) 运行的方式进行解释吗？

【问题讨论】：

谁曾经定义过“解释 == 需要 VM”？可以在不定义 VM 的情况下从源代码进行解释（一些 PLT 人员可能会争辩说每种语言都是 VM，但这不符合一般用法），可以有一个“VM”，它是抽象定义的，但只能通过编译来实现机器码方言。此外，如果有的话，MSIL 将被解释 - C# 显然被编译为 MSIL，甚至提前。
我想你可以问同样的关于 java 的问题
没有“争议”。争论意味着有争论。只有事实——.NET 使用 IL（以及一个用于 JIT 编译该 IL 的 VM）。如果您想将其称为解释，那很好，但您需要记住，与“解释性”（相对较差的性能、动态类型、后期绑定）的典型关联不适用于 .NET，因此这种分类的价值是可疑的。
这可能会有所帮助：blogs.msdn.com/b/ericlippert/archive/2011/11/18/why-il.aspx
@GETah，哈哈，如今 Java 几乎像砖一样便携。

标签： c# programming-languages

【解决方案1】：

VM 是微处理器的抽象。它只是一个定义，并不真正存在。 IE。你不能在虚拟机上运行代码；但是，您可以为其生成 IL 代码。优点是语言编译器不需要了解不同类型的真实处理器的详细信息。由于不同的 .NET 语言（如 C# 或 VB（以及更多））生成 IL，因此它们在此级别上是兼容的。例如，这与通用类型系统等其他约定一起，允许您在 C# 程序中使用从 VB 代码生成的 DLL。

当您在 Windows 上运行 .NET 应用程序时，IL 会及时编译，也可以在 Mono 中提前编译。在这两种情况下，都会为实际处理器生成本机机器代码。这个完全编译的代码在 REAL 微处理器上执行！

另一个方面是您必须编写的编译器数量。如果您有 n 种语言并且希望在 m 处理器架构上运行它们，则需要 n language-to-IL 编译器 + m IL-to-native-code 编译器。如果没有这个中间抽象层，您将需要 n × m 编译器，这可能比 n + m 的数量要大得多！

【讨论】：

"这个完全编译的代码是在 REAL 微处理器上执行的"...是的，但是附加的代码，不是从 IL 派生的，虚拟机的实现行为也会被执行（对于 C#，这将是 .NET 公共语言运行时）
是的，CLR 管理加载、链接 JIT 编译、安全方面、内存管理等内容。但我会把它比作一种操作系统，而不是虚拟机。

【解决方案2】：

简短的回答是否定的，对 VM 的要求并不表明它已被解释。

VM 包含将 IL 转换为本地机器代码的 JIT 编译器。它还包含 C# 程序所依赖的 .NET 类库。它还包含一些涉及动态链接等的其他机制（肯定建立在 Windows DLL 机制之上，但 .NET 具有超出 Windows 自身提供的功能，这些功能在 VM 中实现）。

【讨论】：

【解决方案3】：

您可能指的是CLR（规范CLI的实现）。

CLI 定义了特定的类型系统、对这些类型的所有操作的语义、内存模型和运行时元数据。

为了提供上述所有功能，必须对生成的代码进行一些检测。一个简单的例子是确保支持大于 32 位的数字，并且浮点运算的行为符合每种架构的规范。

此外，为确保内存分配的正确行为、元数据的正确管理、静态初始化、泛型类型实例化和类似的一些附加过程，必须在您的 CLR 代码的执行过程中出现。这一切都由 VM 负责，CPU 不容易提供。

引用维基百科，例如：

CLR 提供额外的服务，包括内存管理、类型安全和异常处理。

【讨论】：