命令パイプライン

パイプラインのメリットとデメリット

パイプラインのメリット

1. プロセッサのサイクルタイムが短縮され、命令のスループットが向上します。パイプラインは命令を完了させるのにかかる時間を短縮するのではなく、同時に処理できる命令の数を増やし（「一度に」）、完了した命令間の遅延を減らします（「スループット」と呼ばれています）。
   プロセッサのパイプラインステージが多ければ多いほど、「一度に」処理できる命令数が多くなり、完了した命令間の遅延が少なくなります。今日製造されている多くの
   汎用マイクロプロセッサは、少なくとも2段階のパイプラインを使用しており、最大で30～40段階のパイプラインを使用しています。
2. パイプラインを使用すれば、CPU演算ロジックユニットの設計は高速化できますが、より複雑なものになります。
3. パイプライン化は理論的には、パイプライン化されていないコアよりもステージ数の倍のパフォーマンスを向上させ（クロック周波数も同じ要因で増加すると仮定して）、コードはパイプライン実行に理想的です。
4. パイプラインCPUは一般的にRAMのクロック周波数よりも高いクロック周波数で動作します（2008年の技術では、RAMはCPUの周波数に比べて低い周波数で動作します）。

パイプラインのデメリット

パイプラインには多くの欠点がありますが、そのほとんどを克服するためにCPUやコンパイラの設計者が使用している多くのテクニックがあります; 以下は一般的な欠点のリストです。

1. 非パイプライン型プロセッサの設計はシンプルで製造コストが安く、非パイプライン型プロセッサは一度に単一の命令のみを実行します。これにより、分岐遅延（パイプラインでは分岐ごとに遅延が発生する）や、シリアル命令を同時に実行する場合の問題を防ぐことができます。
2. パイプライン・プロセッサでは、モジュール間にフリップフロップを挿入すると、非パイプライン・プロセッサに比べて命令のレイテンシが増加します。
3. パイプライン処理されていないプロセッサは、定義された命令スループットを持つことになります。パイプライン加工されたプロセッサの性能は、予測するのがはるかに難しく、プログラムによって大きく異なる可能性があります。
4. 多くの設計では、7、10、20、31、さらにはそれ以上のステージにも及ぶ長いパイプラインが含まれています。長いパイプラインの欠点は、プログラムが分岐すると、パイプライン全体をフラッシュ(クリア)しなければならないことです。実行されたコードに多くの分岐が含まれている場合、パイプラインの高いスループットは不足します。プロセッサは次の命令をどこで読むかを事前に知ることができず、分岐命令が終了するのを待たなければならず、後ろのパイプラインは空のままになります。この欠点は、条件付き分岐命令が前のアクティビティに基づいて分岐するかどうかを予測することで軽減できます。分岐が解決された後、その結果が利用可能になり、プロセッサが再び「作業」を再開する前に、次の命令がパイプラインを通過しなければなりません。このような極端なケースでは、パイプライン化されたプロセッサの性能は、非パイプライン化されたプロセッサよりも悪くなる可能性があります。
5. 残念ながら、すべての命令が独立しているわけではありません。単純なパイプラインでは、1 つの命令を完了するには 5 段階のステージが必要になる場合があります。パフ ォーマ ン ス で動作す る ためには、 このパ イ プ ラ イ ンでは、 最初の命令が完了す る 間に後続の独立 し た4 つの命令を実行す る 必要があ り ます。これら4 つの命令のいずれかが最初の命令の出力に依存する可能性があり、依存関係が解消されるまでパイプライン制御ロジックが待機し、パイプラインにストールや無駄なクロック サイクルを挿入することになります。幸いなことに、フォワーディングなどの技術により、失速が必要な場合を大幅に減らすことができます。
6. 自己修正プログラムは、パイプライン化されたアーキテクチャ上で、修正された命令が実行される命令の近くにある場合、正常に実行できないことがあります。これは、命令がすでにプリフェッチ入力キューに入っている可能性があり、そのため、修正が次回の命令実行に影響を与えない可能性があることが原因です。命令キャッシュはこの問題をさらに悪化させます。
7. 危険がある。プログラマ（またはコンパイラ）がアセンブリコードを書くとき、一般的に、各命令は次の命令が実行される前に実行されると仮定します。この仮定がパイプラインによって検証されず、プログラムが正しく動作しない場合、このような状況はハザードとして知られています。ハザードを解決したり、フォワーディングやディレイ（ストールや無駄なクロックサイクルを挿入する）などの回避方法が
   あります。

例としては、以下のようなものがあります。

汎用パイプライン

右側にあるのは、4つのステージを持つジェネリックパイプラインです。

1. フェッチ
2. デコード
3. 実行
4. ライトバック

上のグレーのボックスは実行待ちの命令のリスト、下のグレーのボックスは実行が完了した命令のリスト、真ん中の白いボックスはパイプラインです。

実行は以下の通りです。

時間	実行
0	4つの命令が実行されるのを待っています
1	緑色の命令がメモリからフェッチされます。
2	緑の命令がデコードされます。 紫の命令がメモリから取り出される
3	緑の命令が実行される（実際の動作が行われる 紫の命令が復号される 青色命令がフェッチされる
4	緑の命令の結果がレジスタファイルまたはメモリに書き戻されます。 紫の命令が実行されます 青色命令がデコードされる 赤色命令がフェッチされる
5	緑の指示が完了しました 紫式部は書き戻される 青色命令が実行される 赤色命令が復号化される
6	紫の指示が完成 青字の命令は書き戻される 赤字命令が実行される
7	青字指示完了 赤字命令は書き戻される
8	赤字指示完了
9	すべての命令が実行される

バブル

実行中に「ヒックアップ」（中断）が発生すると、パイプラインに「バブル」が作成され、その中では何も有益なことは起こりません。サイクル2では、紫命令のフェッチが遅延し、サイクル3のデコード段階ではバブルが発生します。紫の命令の後ろにあるものはすべて遅延しますが、紫の命令の前にあるものはすべて実行を継続します。

明らかに、上記の実行と比較すると、バブルは合計実行時間が 7 クロックティックではなく 8 クロックティックになります。

バブルスはストール（遅延）のようなもので、フェッチ、デコード、実行、ライトバックには何の役にも立たない。NOP（No OPerationの略）コードのようなものです。

例1

2つの数値を加算する典型的な命令はADD A, B, Cで、メモリロケーションAとBにある値を加算し、その結果をメモリロケーションCに格納します。

LOAD A, R1 LOAD B, R2 ADD R1, R2, R3 STORE R3, C LOAD ネクストインストラクション

R1,R2 は CPU のレジスタである。A'と'B'のメモリロケーションに格納されている値をこれらのレジスタにロード(コピー)し、加算した結果を'C'のメモリロケーションに格納する。

この例では、パイプラインはロード、実行、ストアの3つのステージに分かれています。それぞれのステップはパイプラインのステージと呼ばれています。

非パイプライン型プロセッサでは、次の命令を開始する前に全命令を完了させなければならないため、一度に1つのステージのみが動作することができます。パイプライン型プロセッサでは、すべてのステージが同時に異なる命令で動作することができます。したがって、この命令が実行段階にあるとき、2番目の命令はデコード段階にあり、3番目の命令はフェッチ段階にあります。

例2

この概念をより理解するために、理論的な3段パイプラインを見てみましょう。

ステージ	説明
ロード	メモリから命令を読み出す
実行	命令の実行
店舗	結果をメモリやレジスタに保存

と実行される疑似コードアセンブリの一覧を表示します。

このように実行されます。

時計1
ロード	実行	店舗
ロード

LOAD 命令はメモリからフェッチされます。

時計2
ロード	実行	店舗
ムーヴ	ロード

LOAD命令は実行され、MOVE命令はメモリからフェッチされます。

時計3
ロード	実行	店舗
追加	ムーヴ	ロード

LOAD命令はストア段階にあり、その結果（数字40）はレジスタAに格納されます。Aの内容をBに移動しなければならないので、LOAD命令の終了を待たなければなりません。

時計4
ロード	実行	店舗
ストア	追加	ムーヴ

STORE命令がロードされ、MOVE命令が終了してADDが計算されている間に、STORE命令がロードされます。

といった具合です。時には、ある命令が別の命令の結果に依存することがあることに注意してください（MOVEの例のように）。複数の命令がオペランドの特定の場所を参照している場合、オペランドを（入力として）読み込んだり、（出力として）書き込んだりする場合、元のプログラムの順序とは異なる順序でそれらの命令を実行すると、（上述した）危険な状況に陥る可能性があります。

一般的な4ステージのパイプライン、色付きのボックスは互いに独立した命令を表しています。


サイクル3のバブルが実行を遅らせる

関連ページ

• パイプライン（コンピューティング
• 並列計算
• 命令レベルの並列性