ジャストインタイムコンパイラは、プログラム内(JIT)
の各共通中間言語(CIL)
命令を実際に基盤となるプロセッサにマッピングしopcodes
ますか?
もしそうなら、CILをアセンブリ言語と呼び、JITをアセンブラーと呼ぶことができますか?
注:ウィキペディアでは、アセンブリ言語のリストにCILがアセンブリ言語としてリストされていません
ジャストインタイムコンパイラは、プログラム内(JIT)
の各共通中間言語(CIL)
命令を実際に基盤となるプロセッサにマッピングしopcodes
ますか?
もしそうなら、CILをアセンブリ言語と呼び、JITをアセンブラーと呼ぶことができますか?
注:ウィキペディアでは、アセンブリ言語のリストにCILがアセンブリ言語としてリストされていません
この質問はすべて定義に関するものなので、用語を適切に定義しましょう。まず、アセンブリ言語:
アセンブリ言語は、コンピューター、マイクロプロセッサー、マイクロコントローラー、およびその他のプログラム可能なデバイス向けの低水準プログラミング言語であり、各ステートメントは単一の機械語命令に対応しています。アセンブリ言語は、一般に複数のシステムに移植可能なほとんどの高級プログラミング言語とは対照的に、特定のコンピュータアーキテクチャに固有のものです。
さて、CIL:
Common Intermediate Languageは、Common Language Infrastructure(CLI)仕様で定義されている、人間が読める形式の最低レベルのプログラミング言語であり、.NETFrameworkおよびMonoで使用されます。CLI互換のランタイム環境を対象とする言語はCILにコンパイルされ、CILはバイトコードスタイルの形式のオブジェクトコードにアセンブルされます。
さて、この部分は技術的に正しくありません。たとえば、C#コンパイラはバイトコードに直接コンパイルされ、CIL(人間が読める言語)を経由しませんが、理論的には、それが起こっていることを想像できます。
これらの2つの定義では、CILはアセンブリ言語です。これは、CIL内の各ステートメントが単一のバイトコード命令にコンパイルされるためです。そのバイトコードを直接実行できる物理コンピュータがないという事実は問題ではありません。
定義によると、各アセンブリ言語は「特定のコンピュータアーキテクチャに固有」です。この場合、アーキテクチャはCLR仮想マシンです。
JITについて:JITコンパイラはアセンブラとは見なされません。人間が読める形式からバイトコードへの1:1変換は行いませんilasm
。
JITコンパイラは、最適化を行いながら、バイトコードからネイティブマシンコード(実行中のISA / CPUに関係なく)にコンパイルする最適化コンパイラです。
アセンブリは、特定のプロセッサのマシンコード命令のニーモニックで構成されています。コアにコードを実行させる1と0の直接表現ですが、人間が簡単に使用できるようにテキストで記述されています。これはCILとは非常に異なります。
最後の箇条書きは重要なものです。CILをバイトコードと大きく異なるものにする設計上の決定は、CIL命令が型なしであるということです。ADD命令は1つだけですが、プロセッサには多くのバージョンがあります。byte、short、int、long、float、およびdoubleオペランドをとる特定のもの。プロセッサコアのさまざまな部分が追加の実行に使用されるため、必須です。ジッタは、以前のCIL命令から推測したオペランドのタイプに基づいて、適切なものを選択します。
C#言語の+演算子と同様に、さまざまなオペランドタイプでも機能します。CILのLを本当に重要なものにしているのは、言語です。単純なものですが、ジッターを簡単に記述できるようにするのは簡単です。
CIL
線は実際にはかなりぼやけています... 「アセンブリ言語」を呼び出すことに対して私が見た議論は、実際にはほとんど同じように当てはまりx86
ますx86-64
。
IntelとAMDは、(もしあれば)数十年で放出されたとおりにアセンブリ命令を実行するプロセッサを作成していません。したがって、いわゆる「ネイティブ」コードでさえ、バイトコードがx86
/で指定されている仮想マシンで実行するのと大差ありませんx86-64
。
x86
/x86-64
は一般的な開発者がアクセスできる最低レベルのものであるため、足を踏み入れてエコシステム内の何かを「アセンブリ言語」と呼ぶ必要がある場合、それが勝ちます。CIL
バイトコードは最終的にx86
/x86-64
命令を実行できるようにする必要があるためです。そのファミリのプロセッサでは、実際にカウントする必要があるように「感じ」ないというかなり強力なケースがあります。
したがって、ある意味では、どちらも「アセンブリ言語」とは見なされない可能性があります。x86
/プロセッサを参照する場合、他の何か(つまり、マイクロコードが実行するもの)に変換せずに/x86-64
を実行するプロセッサを参照することはほとんどありません。x86
x86-64
さらに別のしわを追加するために、x86
/x86-64
プロセッサが特定の命令シーケンスを実行する方法は、マイクロコードを更新するだけで変更できます。簡単に検索すると、Linuxではソフトウェアでこれを自分で簡単に実行できることがわかります。
だから私は、ここにそれらを2つの別々のカテゴリーに入れることを正当化できる基準があります:
CIL
バイトコードを実行する現在のすべてのマシンがソフトウェアに実装されていることは重要ですか?x86
ソフトウェアで指示された後、同じハードウェアが同じ/x86-64
命令を異なる方法で解釈できることは重要ですか?x86
現在、マイクロコードをバイパスして/x86-64
プロセッサの物理ユニットに直接コマンドを発行する方法がないことは重要ですか?したがって、「CIL
アセンブリ言語である」という質問に関して、私ができる最善の答えは、「状況によって異なります」(科学者の場合)と「かなり」(エンジニアの場合)です。
CILは、アセンブリ言語というよりもバイトコードです。特に、アセンブラ言語とは異なり、人間が読める形式ではありません(おそらく、CILはバイトコードファイルの形式も定義します)。
MSIL JITは、そのバイトコード用の仮想マシンの実装です。実装(MicrosoftまたはMonoから)がCILをマシンコードに変換する方法は、実装の詳細であり、実際には重要ではありません(Microsoft VMはおそらくプロプライエタリであるため、どのように行われるかはわかりません)。Mono(CILのフリーソフトウェア実装)はLLVMを使用していると思うので、おそらく一度に各バイトコードを変換するのではなく、メソッドまたは関数全体を変換する可能性があります。