c# - 编译IL还有其他用途吗

Question

我很确定将高级语言编译成一些字节码的一个原因是 VM（Java 或 .NET）可以生成机器相关的本机指令。

这是唯一的原因吗？如果有某种方法（理论上）可以在程序执行之前（在不同的计算机上）生成与机器相关的指令，那么编译成字节码有什么目的吗？我们可以直接编译成机器代码并在运行时执行这些指令吗？

要清除它：

如果编译器可以为每台计算机生成完美的指令，是否需要 IL？

Answer 1

它简化了编译器，因为现在我们可以只针对一种简单的汇编语言——CIL——而不是四五种复杂的。

您绝不能掉以轻心。x64 汇编，作为近 40 年前 8 位指令集扩展的扩展，充满了特殊情况和设计缺陷。相比之下，CIL 是神奇的独角兽彩虹。

它简化了开发，因为我们不再需要为了构建手机应用程序而设置复杂的交叉编译工具链。单个库可在桌面和移动设备上运行，无需重新编译。

是的，您可以将多个版本的代码（每个架构一个版本）捆绑到一个文件中。Apple在 PowerPC 到 Intel 的过渡中做到了这一点。但是生成的二进制文件通常很大，这不适用于移动设备。

它增加了优化的范围。AOT 编译器中的任何优化只会影响它编译的代码。但是 JIT 中的优化会加速所有程序。

JIT 还有一个额外的信息来源——正在运行的程序本身。通过观察程序如何运行，JIT 可以针对最需要它的代码区域。Java HotSpot VM 广泛使用这种技术。

我认为还有更多优势，但这些都是显而易见的。

Answer 2

CLR 程序集包含 IL/MSIL/CIL/现在的du jour术语。即使编译后的代码硬件和操作系统独立。只要目标系统支持指定版本的 CLR（并且代码没有使用 P/Invoke 等做任何有趣的事情），程序集就应该在目标系统上运行。当程序集被加载时，它会被 JIT 转换为本机机器代码（或者你可以ngen生成机器特定的二进制文件。

拥有可移植可执行文件的原因应该是相当明显的（参见 Java）。

Answer 3

所以你想知道为什么要使用中间语言？

字节码（IL、Java 字节码，甚至 VB6 的 p-code）提供了几个优势。这些来自字节码没有立即编译并在目标 CPU 上运行的事实。在 IL 的情况下，它是即时编译 (JIT) 以按需机器指令。

虽然这似乎本质上比直接编译为本机代码更复杂，但我们从中获得了许多有用的特性，如反射、垃圾收集、类型安全和异常处理。

您可以通过将 JITig C# 代码转换为本地代码，在没有 IL 的情况下获得那些漂亮的托管功能，但是您必须实现这些功能并为您想要的每种语言（C++/CLI、VB.NET 等）编写 JITer .

此外，为基于机器的语言编写这些托管特性然后尝试为主要为人类消费而设计的语言编写这些特性要容易得多。