これを正しく理解していれば：
AMD や Intel などの現在の CPU 開発企業は、機械語 (1G 言語) の上に 2G 言語として見られるものとして、独自の API コード (アセンブリ言語) を持っています。
現在の API 呼び出しの代わりに、そのコアで IL 処理を実行する CPU を持つことは、(パフォーマンスまたはその他の点で) 可能または望ましいでしょうか?
5 に答える
24
Javaにも同様のテクノロジーが存在します.ARMは、これを実行できるさまざまなCPUを開発しており、「Jazelle」テクノロジーと呼んでいます。
ただし、.net IL オペコードで表される操作は、スタックに保持されている型情報と組み合わせて明確に定義されているだけであり、単独では定義されていません。これは Java バイトコードとの大きな違いであり、IL を実行するための適切なハードウェアを作成することははるかに困難になります。
さらに、IL は最終ターゲットへのコンパイルを目的としています。IL を吐き出すバックエンドのほとんどは、最適化をほとんど行わず、最終的なコンパイル ステップでの検証と最適化のためにセマンティック コンテンツを保持することを目的としています。ハードウェアの問題を克服できたとしても、結果はほぼ確実に、まともな最適化 JIT よりも遅くなります。
要約すると、不可能ではありませんが、他のアーキテクチャに比べて非常に難しく、ほとんど達成できません。
于 2009-01-24T12:22:34.967 に答える
15
あなたは、CPU の仕組みについて少し混乱しているようです。アセンブリは、マシン コードとは別の言語ではありません。それは単にそれの別の (テキスト) 表現です。
アセンブリ コードは、実行する命令を順番に並べたものです。マシンコードもまったく同じです。CPU がサポートするすべての命令には、実行を引き起こす特定のビット パターンがあり、アセンブリ コードで使用できるテキスト名もあります。
これをアセンブラで記述add $10, $9, $8して実行すると、add 命令のマシン コードが得られ、レジスタ 9 と 8 の値を取得して加算し、結果をレジスタ 10 に格納します。
アセンブラとマシンコードの間には 1 対 1 のマッピングがあります。
「API呼び出し」もありません。CPU は単純にアドレス X から読み取り、理解するすべての命令に対して後続のビットを照合します。このビット パターンに一致する命令が見つかると、その命令を実行し、次の命令の読み取りに進みます。
あなたが求めていることは、ある意味で不可能または矛盾しています。IL は Intermediate Language の略です。つまり、コンパイラによって出力されるが、まだマシン コードに変換されていない一種の疑似コードです。しかし、CPU がそれを直接実行できれば、それはもはや中間ではなく、機械語になります。
したがって、質問は「あなたの IL コードは、現在 CPU がサポートしているマシン コードよりも優れた、より効率的なプログラムの表現ですか?」ということになります。
そして、答えはおそらくノーです。MSIL (より一般的な用語である IL が意味するものだと思います) は、移植可能で、シンプルで、一貫性があるように設計されています。すべての .NET 言語は MSIL にコンパイルされ、すべての MSIL プログラムは、どこにいても任意の CPU のマシン コードに変換できる必要があります。つまり、MSIL は一般的かつ抽象的である必要があり、CPU について想定してはなりません。このため、私の知る限り、これは純粋にスタックベースのアーキテクチャです。データをレジスタに保持する代わりに、各命令はスタックの一番上でデータを処理します。これはきれいで一般的なシステムですが、あまり効率的ではなく、CPU の厳格な構造にうまく変換できません。(素晴らしい小さな高レベルの世界では、スタックが自由に成長できるふりをすることができます。CPU がスタックに高速にアクセスできるようにするには、有限サイズの小型で高速なオンチップ メモリに格納する必要があります。では、プログラムがスタックにあまりにも多くのデータをプッシュするとどうなるでしょうか?)
はい、 MSIL を直接実行する CPU を作成できますが、それによって何が得られるのでしょうか? 実行前にコードを JIT する必要がなくなるため、プログラムを初めて起動するときは、起動が少し速くなります。それとは別に？MSIL プログラムが JIT されると、マシン コードに変換され、最初にマシン コードで記述されたかのように効率的に実行されます。MSIL バイトコードはもはや存在せず、CPU が理解する一連の命令だけです。
実際、.NET を使用する前の状態に戻ることができます。非管理言語は、これがあなたの提案にあるように、マシンコードに直接コンパイルされます。唯一の違いは、非マネージ コードは、CPU 設計者によって CPU での実行に適したように設計されたマシン コードを対象とするのに対し、あなたの場合は、ソフトウェア設計者によって簡単に変換できるように設計されたマシン コードを対象とすることです。から。
于 2009-01-24T12:32:35.433 に答える
12
これは新しいアイデアではありません。Java についても同じことが予測されており、Lisp マシンも実際に実装されていました。
しかし、これらの経験は、それが実際には役に立たないことを示しています。専用の CPU を設計することによって、「従来の」CPU の進歩から恩恵を受けることはできず、Intel に勝てない可能性が非常に高いです。ウィキペディアの記事からの引用は、これをうまく説明しています。
安価なデスクトップ PC はすぐに、専用ハードウェアを使用しなくても、Lisp マシンよりもさらに高速に Lisp プログラムを実行できるようになりました。
ある種類のマシンコードから別の種類のマシンコードにオンザフライで変換することは、十分に理解されている問題であり、非常に一般的であるため (最新の CISC CPU は実際には RISC であるため、内部でそのようなことを行っています)、十分に効率的に行われていると推測できます。それを回避しても大きなメリットは得られません。従来の CPU の最先端技術から切り離さなければならない場合はそうではありません。
于 2009-01-24T12:10:33.853 に答える
6
私はノーと言うでしょう。
コンピュータ上で実行する必要がある実際の機械語命令は、IL よりも低レベルです。たとえば、IL では、メソッドの呼び出し方法、レジスタの管理方法、スタックへのアクセス方法、またはマシン コード レベルで必要なその他の詳細については実際には記述されていません。
したがって、マシンに IL を直接認識させることは、すべての JIT コンパイル ロジックをソフトウェアからハードウェアに単純に移動することになります。
そうなると、プロセス全体が非常に厳格で変更不可能になります。
機械の機能に基づく機械語と、プログラマーの意図を捉えることに基づく中間言語を使用することで、はるかに優れたシステムが得られます。マシンを定義する担当者は、効率的なコンピューター アーキテクチャの定義に専念でき、IL システムを定義する担当者は、表現力や安全性などに専念できます。
ツール ベンダーとハードウェア ベンダーの両方がすべてに対してまったく同じ表現を使用する必要がある場合、ハードウェア スペースまたはツール スペースのいずれかでのイノベーションが妨げられます。だから、私はそれらが互いに分離されるべきだと言います。
于 2009-01-24T12:11:45.647 に答える
0
私は2つの理由でそうは思わなかったでしょう:-
- ハードウェア処理 IL がある場合、そのハードウェアは新しいバージョンの IL を実行できません。JIT を使用すると、新しい JIT が必要になるだけで、既存のハードウェアで新しい IL を実行できます。
- IL はシンプルで、ハードウェアに依存しないように設計されています。IL は、既存のマシン コードのパフォーマンスに近づけるために、最も効率的な方法で操作を記述できるようにするために、はるかに複雑にする必要があります。しかし、それは、IL が非 IL 固有のハードウェアで実行するのがはるかに困難になることを意味します。
于 2009-01-24T12:10:55.303 に答える