高水準言語を何らかのバイトコードにコンパイルする理由の 1 つは、VM (Java または .NET) がマシン依存のネイティブ命令を生成できるようにするためだと確信しています。
それが唯一の理由ですか？プログラムを実行する前に（異なるコンピューターで）マシン依存の命令を生成する（理論的に）何らかの方法があった場合、バイトコードにコンパイルする目的はありますか？マシンコードにコンパイルして、実行時にそれらの命令を実行することはできますか?
それをクリアするには：
コンパイラーがすべてのコンピューターに対して完璧な命令を生成できる場合、IL は必要ですか?
4 つまたは 5 つの複雑なアセンブリ言語ではなく、1 つの単純なアセンブリ言語 (CIL) のみをターゲットにできるため、コンパイラが簡素化されます。
この利益を軽視してはなりません。x64 アセンブリは、ほぼ 40 年前の 8 ビット命令セットの拡張の拡張として、特殊なケースと設計上の欠陥に満ちています。対照的に、CILは魔法のユニコーンの虹です。
電話アプリを構築するためだけに複雑なクロスコンパイル ツールチェーンをセットアップする必要がなくなるため、開発が容易になります。1 つのライブラリがデスクトップとモバイルの両方で動作し、再コンパイルは不要です。
はい、コードの複数のバージョン (アーキテクチャごとに 1 つ) を 1 つのファイルにバンドルできます。Appleは、PowerPC から Intel への移行でこれを行いました。しかし、結果として得られるバイナリはしばしば大きくなり、モバイルではうまく機能しません。
最適化の範囲が広がります。AOT コンパイラでの最適化は、コンパイルするコードにのみ影響します。しかし、JIT での最適化により、すべてのプログラムが高速化されます。
JIT には、実行中のプログラム自体という追加の情報源もあります。プログラムがどのように実行されるかを監視することで、JIT は最も必要なコード領域をターゲットにすることができます。Java HotSpot VM は、この手法を広範に使用しています。
他にもメリットはあると思いますが、これは明らかなメリットです。
では、なぜ中間言語を使用するのか疑問に思っていますか?
バイト コード (IL、Java バイト コード、さらには VB6 の p コード) には、いくつかの利点があります。これらは、バイトコードがすぐにコンパイルされず、ターゲット CPU で実行されないという事実に由来します。IL の場合、オンデマンドでマシン命令にジャスト イン タイム コンパイル (JIT) されます。
これは、すぐにネイティブ コードにコンパイルするよりも本質的に複雑に思えますが、リフレクション、ガベージ コレクション、タイプ セーフ、例外処理など、多くの便利な機能を利用できます。
JITig C# コードをネイティブ コードにすることで、IL を使用せずに優れた高度なマネージド機能を取得できますが、これらの機能を実装し、必要な言語 (C++/CLI、VB.NET など) ごとに JITer を作成する必要があります。 .
さらに、これらのマネージド機能を機械ベースの言語用に記述してから、主に人間が使用するように設計された言語用にこれらの機能を記述しようとする方がはるかに簡単です。