我很确定将高级语言编译成某个字节码的一个原因是VM（Java或.NET）可以生成依赖于机器的本机指令。
这是唯一的原因吗？如果在程序执行之前（在不同的计算机上）有某种方式（理论上）生成机器相关指令，那么编译到字节码是否有任何目的？我们可以编译成机器代码并在运行时执行这些指令吗？
清除它：
如果编译器只能为每台计算机生成完美的指令，那么需要IL吗？
答案 0 :(得分：1)
简化了编译器，因为现在我们只能使用一种简单的汇编语言 - CIL - 而不是四五种复杂语言。
你不能轻易接受这个好处。 x64程序集作为近四十年前8位指令集扩展的扩展，充满了特殊情况和设计缺陷。相比之下，CIL是神奇的独角兽彩虹。
简化开发，因为我们不再需要设置复杂的交叉编译工具链来构建手机应用程序。单个库可以在桌面和移动设备上运行，无需重新编译。
是的，您可以将您的代码的多个版本（每个架构一个版本）捆绑到一个文件中。 Apple在他们的PowerPC到英特尔的过渡中做到了这一点。但由此产生的二进制文件通常很大，这对移动设备来说效果不佳。
增加优化范围。 AOT编译器中的任何优化只会影响它编译的代码。但是JIT中的优化将加速所有程序。
JIT还有一个额外的信息来源 - 正在运行的程序本身。通过观察程序如何运行，JIT可以针对最需要它的代码区域。 Java HotSpot VM广泛使用这种技术。
我认为有更多的优点，但那些是显而易见的。
答案 1 :(得分：0)
CLR程序集包含IL / MSIL / CIL /这些日子里的任何术语 du jour 。那就是使编译的代码硬件和操作系统独立。只要目标系统支持CLR的指定版本（并且代码没有用P / Invoke等做任何有趣的事情），程序集就应该在目标系统上运行。加载程序集时，它会被JIT转换为本机机器代码（或者你可以ngen生成一个特定于机器的二进制代码。
拥有可移植可执行文件的原因应该是相当明显的（参见Java）。
答案 2 :(得分：0)
所以你想知道为什么要使用中间语言？
字节代码（IL，Java字节代码，甚至VB6的p代码）提供了几个优点。这些来自以下事实：字节代码不会立即编译并在目标CPU上运行。在IL的情况下，它是按时编译（JIT）按需加工指令。
虽然这似乎比仅仅编译到本机代码本质上更复杂，但我们从中获得了许多有用的功能，如反射，垃圾收集，类型安全和异常处理。
你可以通过JITig C＃代码获得那些漂亮的花哨托管功能，但是你必须实现这些功能并为你想要的每种语言编写一个JITer（C ++ / CLI，VB.NET，等等。）。
此外，为基于机器的语言编写这些托管功能要容易得多，然后尝试为主要为人类消费而设计的语言编写这些功能。