20

単純に、条件付きで実行される命令は、私には素晴らしいアイデアのように思えます。

ARM (および ARM に似た) 命令セット (Thumb2、Unicore、AArch64) について詳しく読むと、条件付き実行のためのビットがすべて欠けていることがわかります。

これらのそれぞれに条件付き実行がないのはなぜですか?

当時の条件付き実行は間違いでしたか、それともその後の変更により、命令ビットの無駄遣いになりましたか?

4

7 に答える 7

27

一般的な主張は、最新のシステムにはより優れた分岐予測子があり、コンパイラーははるかに高度であるため、命令エンコードスペースのコストが正当化されないというものです。

これはARMv8命令セットの概要からのものです

A64 命令セットには、述語実行または条件付き実行の概念が含まれていません。ベンチマークは、最新の分岐予測子が十分に機能することを示しており、命令の述語実行は、オペコード空間の重要な使用と高度な実装での実装コストを正当化するのに十分な利点を提供しません.

そして、それは続く

「条件付きデータ処理」命令の非常に小さなセットが提供されます。これらの命令は無条件で実行されますが、条件フラグを命令への追加入力として使用します。このセットは、条件分岐の予測が不十分な場合や、その他の理由で非効率な場合に有益であることが示されています。

ARMプロセッサでより多くのレジスタを獲得するための条件付き実行の取引というタイトルの別の論文は、次のように主張しています。

... 条件は 32 ビットの ARM 命令ごとに 4 ビットの条件コード セレクターにエンコードされるため、条件付き実行は貴重な命令スペースを占有します。さらに、最新の組み込みアプリケーションで実際に条件付きになっている命令の割合はごくわずかであり、条件付き実行は最新の組み込みプロセッサのパフォーマンスの向上にさえつながらない可能性があります。

于 2014-03-04T10:54:46.057 に答える
9

その理由の 1 つは、命令のエンコードが原因です。

経験上、レジスタ オペランドの 3 つの上位ビットを格納する十分なスペースがなく、わずか 8 つのレジスタのサブセットに縮小する必要がある場合、さらに4 ビットを狭い 16 ビット スペースに詰め込むことはできません。thumb2には、次の 4 つの命令の条件を選択するための別のIT(E)命令があることに注意してください。ただし、上記の理由により、同じ命令に条件を格納することはできません。

AArch64の場合、レジスタの数は 32 ビット ARM と比較して 2 倍になりましたが、レジスタの新しい 3 つの上位ビットには残りのビットがありません。古いエンコーディングを使用したい場合は、狭い 12 ビットの即値または 4 ビットの条件から「借用」する必要があります。12 ビットは、MIPS などの他の RISC アーキテクチャに比べてすでに小さすぎます。数を減らすとすべてが悪化するため、条件を削除することをお勧めします。分岐予測はますます高度になっているので、それほど問題にはなりません。また、名前を変更して気にすることが 1 つ少なくなるため、アウトオブオーダー実行の実装が容易になります。

于 2014-03-04T13:22:24.807 に答える
7

条件付き実行が ARMv8 に存在しないと言うのは、やや誤解を招きます。問題は、一部の命令を実行したくない理由を理解することです。おそらく初期の ARM では、実際に命令を実行しないことが重要でした (電力などのために) が、今日この機能の重要性は、たとえば a=(b> 0?1:2)。この種のことは想像以上に一般的です --- 概念的には、MAX/MIN や ABS のようなものです (一部の CPU では、これらの特定のタスクを実行するための指示がある場合があります)。

ARMv8 では、一般的な条件付きで実行される命令はありませんが、ここで説明する特定のタスクを実行する命令がいくつかあります。つまり、短いダム ジャンプの分岐を回避できます。CSEL が最もわかりやすい例ですが、その他の一般的なパターン (その場合は C の短絡的な式評価のパターン) を処理する他のケース (条件の条件設定など) があります。

IMHO ARM がここで行ったことは、最も理にかなっています。彼らは、最新の CPU のマイクロアーキテクチャに一致するように実装の詳細を変更しながら、最新の CPU (多くの分岐を回避する) で引き続き価値のある条件付き実行の機能を抽出しました。

于 2014-06-22T04:51:12.383 に答える
5

条件付き実行は、並べ替え、リストまたはツリー操作、数値から文字列への変換、sqrt または long 除算など、多くの補助ルーチンまたはビット操作ルーチンの実装に適しています。UART ドライバーを追加し、ルーターでビット フィールドを抽出することができます。それらは、分岐と非分岐の比率が高く、予測不可能性もやや高くなります。

ただし、最下位レベルのサービスを超えると (または、より高いレベルの言語を使用して抽象化レベルを上げると)、コードはまったく異なって見えます。条件のさまざまなブランチ内のコード ブロックは、データの移動とサブルーチンの呼び出しで構成されます。ここでは、これらの余分な 4 ビットの利点が急速に失われます。それは個人的な成長だけでなく、文化的なものでもあります。文化的にプログラミングは、非構造化 (Basic、Fortran、Assembler) から構造化へと発展しました。異なるプログラミング パラダイムは、異なる命令セット アーキテクチャでもより適切にサポートされます。

技術的な妥協点として、5 ビットの「cond.S」フィールドを、最も頻繁に使用される4 つまたは 3 つの組み合わせに圧縮する可能性がありました。

  • 一般的な SA-110 サム/ARM コンパイル ルーチンの電力、サイクル タイム、コード サイズ、および命令数のベンチマークを提供するプロファイル ガイド付きモード選択に関する論文。ARM モードの方が優れているルーチンもあれば、Thumb モードの方が優れているルーチンもあります。それはアルゴリズム、そして最終的にはコード/コンパイラに依存します。
于 2014-03-04T12:24:24.210 に答える
-1

mips の defer スロットが (当時) トリックであるのと同じように、arm での条件付き実行は (当時) トリックであり、pc が 2 命令先にあるのと同様です。将来的には、それらはどの程度の影響を与えるのでしょうか? ARMの分岐予測子は実際にそれほど大きな違いを生むでしょうか、それとも32ビット命令ワードでより多くのビットが必要だった本当の答えであり、親指のように最初に取り除くのが最も簡単なのは条件ビットです.

いくつかのパフォーマンス テストを実行して、分岐予測子が実際にどれだけ優れているかを確認することはそれほど難しくありません。arm11 の無条件分岐で試してみました。これは現在古いアーキテクチャですが、まだ広く使用されています。分岐予測を改善することはせいぜい困難であり、条件付き実行と競合することはできませんでした。私は、皮質-aファミリーのいかなるものについても、これらの経験を繰り返していません.

于 2014-03-04T16:16:19.457 に答える
-1

「条件付きで実行される命令が存在しないのはなぜですか...」

ウィキペディアの記事「Predication - Disadvantages」には、少しの情報が記載されています。

短所
Predication の主な欠点は、エンコーディングスペースが増加することです。一般的な実装では、すべての命令が、その命令がどのような条件下で効果を発揮するかを指定する述語用のビットフィールドを予約します。組み込みデバイスのように、使用可能なメモリが限られている場合、このスペース コストはただし、 Thumb -2 などの一部のアーキテクチャでは、この問題を回避できます (以下を参照)。

  • プレディケーションは、ロジックのレベルをクリティカル パスに追加することでハードウェアを複雑にし、クロック速度を低下させる可能性があります。
  • 述語ブロックにはすべての操作のサイクルが含まれているため、パスが短いほど時間がかかり、ペナルティを受ける可能性があります。

パスのバランスが取れている場合、または最も長いパスが最も頻繁に実行される場合、述語は最も効果的ですが、プロファイル情報が存在する場合でも、コンパイル時にそのようなパスを決定することは非常に困難です。

...

ARM アーキテクチャでは、元の 32 ビット命令セットが条件付き実行と呼ばれる機能を提供します。これにより、前の命令によって設定された 4 つの条件コードの組み合わせに基づく 13 の述語の 1 つによってほとんどの命令を述語にすることができます。ARM の Thumb 命令セット (1994 年) は、命令のサイズを縮小して 16 ビットに収まるように条件付き実行を削除しましたが、その後継である Thumb-2 (2003 年) は、命令を供給する以外に影響を与えない特別な命令を使用することで、この問題を克服しました。次の 4 つの命令の述語。ARMv8-A (2011) で導入された 64 ビット命令セットは、条件付き実行を条件付き選択命令に置き換えました。".

「Embedded Computing: A VLIW Approach to Architecture, Compilers and Tools」、ジョセフ A. フィッシャー、パオロ ファラボスキ、クリフ ヤング共著、172 ページ:

「...完全な述語は、ハードウェア、ISA、およびコンパイラを複雑にします。より深いパイプラインとより高速なクロックを好む投機とは異なり、述語はクリティカル パスにロジックのレベルを追加し、クロック速度を低下させる可能性があります。述語オペランドは、貴重なエンコーディング ビットを使用します。非循環または「制御指向」コードに対する述語の利点は、活発な学術的および商業的議論の対象となっており、述語の利点が完全な予測をサポートするための膨大なハードウェア コスト。

完全な述語と部分的な述語の間の議論は、さらに微妙です。完全な述語はより表現力があり、コンパイラーは操作の任意の組み合わせを含むブロックを述語できます。部分的述語には、積極的な投機が必要であり、いくつかの固有の制限が組み込まれています (たとえば、呼び出し操作を含むブロックを述語することはできません)。実装の複雑さに関しては、前述のように、完全な述語は命令エンコーディングとマイクロアーキテクチャに対する要求がはるかに高くなりますが、選択操作を伴う部分的な述語は、ほとんどのマイクロアーキテクチャとデータパスによく適合し、複雑さ、面積、または速度に影響を与えません。 .

組み込みドメインでの述語
組み込みドメインでは、述語レジスタの大規模なセットのコード サイズのペナルティを正当化することは困難です。完全な述語は、述語機構のコストが使用頻度に関係なく支払われる必要がある「前払い」の哲学を意味します。たとえば、64 個の述語に対処するために 6 個の述語ビットを追加すると、IPF エンコーディングを 42 ビットにプッシュするのに役立ちました。操作ごと - 組み込みプロセッサにとって法外に高価なアプローチ. ...".

コスト、TDP、特許、さらには競合製品を開発するために必要な技術レベルもすべて影響します。この場合、それは更新されたコーディング手法によって実現されたコスト上の利点であり、必要と考えられていたものが実際には使用されなかったか、少なくとも効果的ではありませんでした (その実装のコストについて)。

別の回答で説明されているように、ARM マニュアルはその理由についてほとんど述べておらず、RISC マニュアルよりも少ない理由について述べています。

" 3 A64
の概要 A64 命令セットは、AArch32 または ARMv7 の A32 および T32 命令セットと同様の機能を提供します。ただし、T32 命令セットへの 32 ビット命令の追加が ARM ISA の動作の一部を合理化したように、A64 命令セットは新しい命令セットのハイライトは次のとおりです。

  • ...

  • コンディショナリティの低減。条件フラグを設定できる命令が少なくなります。条件付き分岐と少数のデータ処理命令のみが条件フラグを読み取ります。条件付きまたは述語付きの実行は提供されず、T32 の IT 命令に相当するものはありません (§3.2 を参照)。

...

3.2 条件付き命令
A64 命令セットには、述語または条件付き実行の概念が含まれていません。ベンチマークは、最新の分岐予測子が十分に機能することを示しており、命令の述語実行は、オペコード空間の重要な使用と高度な実装での実装コストを正当化するのに十分な利点を提供しません.

「条件付きデータ処理」命令の非常に小さなセットが提供されます。これらの命令は無条件で実行されますが、条件フラグを命令への追加入力として使用します。このセットは、条件分岐の予測が不十分な場合や、その他の理由で非効率な場合に有益であることが示されています。

詳細については「4.3 条件コード」セクションを参照してください。

RISC-V ISA (関連のない最近設計された ISA) の設計者は、プロセッサの設計に何が必要かを説明しています ( http://riscv.org/spec/riscv-spec-v2.0.pdf 23 ページ)。

「条件付き分岐は、条件コード (x86、ARM、SPARC、PowerPC) を使用するのではなく、2 つのレジスタ間の算術比較演算 (PA-RISC、Xtensa、および MIPS R6 でも行われるように) を含むように設計されています。ゼロに対するレジスター (Alpha、MIPS)、または等しい場合のみの 2 つのレジスター (MIPS) この設計は、結合された比較分岐命令が通常のパイプラインに適合し、追加の条件コード状態または使用を回避するという観察によって動機付けられました。一時レジスターを削減し、静的コード サイズと動的命令フェッチ トラフィックを削減します。

...

条件付き移動命令と述語付き命令の両方が、順不同のマイクロアーキテクチャに複雑さを追加し、述語が false の場合に宛先アーキテクチャ レジスタの元の値を、名前が変更された宛先物理レジスタにコピーする必要があるため、暗黙的な 3 番目のソース オペランドを追加します。また、分岐の代わりに述語を使用するという静的なコンパイル時の決定は、コンパイラのトレーニング セットに含まれていない入力のパフォーマンスを低下させる可能性があります。

分岐の予測ミスでパイプラインをフラッシュするコストを回避するために、予測不可能な短い前方分岐を内部的に予測されたコードに動的に変換するさまざまなマイクロアーキテクチャ手法が存在し [6、10、9]、商用プロセッサに実装されていることに注意してください [17]。

最も単純な手法は、フェッチ パイプライン全体ではなくブランチ シャドウ内の命令のみをフラッシュするか、またはワイド命令フェッチまたはアイドル命令フェッチ スロットを使用して両側から命令をフェッチすることによって、誤った予測された短い前方分岐から回復するというペナルティを軽減するだけです。アウトオブオーダー コアのより複雑な手法では、分岐シャドウ内の命令に内部述語を追加し、分岐命令によって書き込まれた内部述語値を使用して、分岐および後続の命令を投機的に、アウトオブオーダーで実行できるようにします。他のコード [17]。

[6]ティモシー・H・ハイルとジェームズ・E・スミス。選択的なデュアル パスの実行。テクニカル レポート、ウィスコンシン大学マディソン校、1996 年 11 月。

[9]Hyesoon Kim、Onur Mutlu、Jared Stark、Yale N. Patt。ウィッシュ ブランチ: 適応的な述語実行のための条件分岐と述語の組み合わせ。マイクロアーキテクチャに関する第 38 回年次 IEEE/ACM 国際シンポジウムの議事録、MICRO 38、43 ～ 54 ページ、2005 年。

[10]A.クラウザー、T.オースティン、D.グルンワルド、B.カルダー。非述語命令セット アーキテクチャの動的ハンモック予測。1998 年並列アーキテクチャおよびコンパイル技術に関する国際会議の議事録、PACT '98、ワシントン DC、米国、1998 年。

[17]Balaram Sinharoy、R. Kalla、WJ Starke、HQ Le、R. Cargnoni、JA Van Norstrand、BJ Ronchetti、J. Stuecheli、J. Leenstra、GL Guthrie、DQ Nguyen、B. Blaner、CF Marino、E. Retter、およびP.ウィリアムズ。IBM POWER7 マルチコア サーバー プロセッサ。IBM 研究開発ジャーナル、55(3):1–1、2011 年。

64 ビット ARM で述語命令を削除すると、すべての命令のエンコードで 4 ビットが解放され、これにより各レジスタ フィールドに 1 ビットを追加できるようになり、レジスタの数が 2 倍になりました。

私の意見では、サーバー プロセッサがファブリックにピン留めされている場合にエリソン機能を省略するのは誤りですが、トレードオフが行われます。それは間違いではありません (適切に実装されているため)、高価であり、無駄ではありません (ビットは賢く、自分のビジネスを気にします)。条件は、より簡単でより良い選択でした。

これは、CPU 拡張や GPU の追加に似ています。ツールを上手に活用できれば、準備万端です。

ウィキペディアの引用: 「さまざまなベンチマークによると、TSX は特定のワークロードで約 40% 高速なアプリケーション実行と、1 秒あたりのデータベース トランザクション (TPS) の 4 ～ 5 倍の速度を提供できます。」.

これは「コストがかかる」(状況によっては) ですが、現在のプログラミング スタイルにとっては重要です。より悲観的に言えば、合成ベンチマークではるかに高いスコアを獲得するための手段でもあります。

いつの日か、レゴのように簡単になり、「それ」に自分で組み立てて、入札を依頼できるようになるでしょう。それまでは、プロセッサーはプログラマー (およびコンパイラー・ライター) の怠惰をサポートしなければなりません (MUST)。したがって、ほとんど GPU で実行できるプログラムはまれです (しかし、私たちはそこに到達しています)。

したがって、不要と考えられている、または費用対効果が高く競争力のある方法で実装されていない (優れた) 機能の削除。

したがって、現在の TSX ルールは次のとおりです。しかし、ARM CPU にはファブリック用のファンシー スレッドも必要です。

URL 参照:

AMD: https://en.wikipedia.org/wiki/Advanced_Synchronization_Facility

インテル: https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions

.

于 2015-08-10T03:20:07.593 に答える