(57)【要約】後のオペランド・データを待っている間にそうでなければ課せられる非実行条件付命令の遅延はそのような命令がパイプライン・プロセッサを通して現在の通路上で実行しないであろうという初期の認識に基づいて軽減される。実行の前の適切な点において、条件に関する決定が行われる。命令がパイプラインを通る通路上で実行しないような条件のものであれば、条件付命令に関する保留は終結される、即ち全ての関連オペランド・データの受取りの完了前に省略、或いは停止される。パイプラインを通る非実行命令の流れは、例えば、条件付命令によって使用されるソース・オペランド・データを計算し、且つ書込むために初期の命令を待つ必要はない。【選択図】      図４
2008537208.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理段階を含むパイプライン・プロセッサを通して条件付命令の処理を制御する方法であって、
パイプラインの第一の段階において条件付命令を解読すること、
命令がパイプラインの後の段階によって実行されるべきであるかどうかを判定するために命令を実行するために要求される条件を解析すること、及び
命令が実行されるべきでないことを条件の解析が指示すれば、そうでなければ条件付命令の実行のために必要とされたであろうオペランド・データに関する待機の期間の少なくとも一部を省略することを含む方法。
【請求項２】
省略のステップはオペランド・データの受取りの完了を待たずに、それが実行されないであろうパイプラインの後の段階への条件付命令の通過を含む、請求項１記載の方法。
【請求項３】
省略のステップは条件付命令を非動作（ＮＯＰ）命令として示すこと、及びＮＯＰ命令をパイプラインの後の段階へ渡すことを含む、請求項１記載の方法。
【請求項４】
省略のステップは後の段階へ渡すことなくパイプラインから条件付命令を消去することを含む、請求項１記載の方法。
【請求項５】
条件付命令は命令が実行されるべきであれば、満たされるべき条件を指定する、そして
解析は条件が満たされるかどうかを判定するため指定条件を初期の命令によって書込まれた条件データと比較することを含む、請求項１記載の方法。
【請求項６】
解析ステップは、
パイプラインを通してまだ完全に実行されなかったいずれかの古い命令が条件付命令を実行するために必要とされる条件を設定するかどうかを判定すること、及び
パイプラインにおいてまだ実行されている古い命令が条件を設定しないことが判定されるとき、条件の解析を実行することを含む、請求項５記載の方法。
【請求項７】
パイプラインの後の段階において処理されない古い命令が条件付命令を実行するために必要とされる条件を設定することが判定される前に、そうでなければ条件付命令の実行のために必要とされたであろうオペランド・データの取得を始めること、及びオペランド・データの取得の完了を待つために通路から後の段階への条件付命令を保留すること、及び
パイプラインの後の段階において処理されている古い命令が条件付命令を実行するために必要とされる条件を設定しないことが判定され、そして条件付命令がパイプラインの後の段階によって実行されるべきであることを解析が条件から判定するとき、保留を終結させることをさらに含む、請求項６記載の方法。
【請求項８】
条件付命令は条件フィールド、及び条件付解析に基づいて実行される命令を含むフィールドを含む、請求項１記載の方法。
【請求項９】
条件付命令は、
満たされるべき条件を指定する第一の命令、及び
第一の命令において指定された条件が満たされる場合に実行されるべき動作を指定する第二の命令を含む、請求項１記載の方法。
【請求項１０】
請求項１の方法を実施するために構成されたパイプライン型プロセッサ。
【請求項１１】
パイプラインを通して命令を処理する方法であって、  
所望の系列においてメモリから命令をフェッチすること、  
各命令が連続してフェッチされるとき、各命令を解読すること、
複数の解読された命令の各々について、命令によって必要とされるオペランド・データを取得すること、及び
パイプラインの実行区域に命令を渡すことを含み、
そこでは、オペランド・データが取得され、且つオペランド・データの取得が複数の処理サイクルを必要とする解読命令の条件付命令について、その方法はさらに、
（ａ）命令がパイプラインの実行セクションによって実行されるべきであるかどうかを判定するため条件付命令を実行するために必要とされる条件を解析すること、
（ｂ）条件付命令がパイプラインを通る現在の通路上で実行されるべきであることを条件の解析が示すならば、条件付命令によって必要とされるオペランド・データの受取りを完了すること、及びパイプラインの実行段階を通して条件付命令、及び必要とされるオペランド・データを処理すること、及び
（ｃ）条件付命令がパイプラインを通る現在の通路上で実行されるべきでないことを条件の解析が示すならば、条件付命令に関してオペランド・データの取得に必要とされる処理サイクルの少なくとも一つを省略することを含む方法。
【請求項１２】
条件付命令に関するオペランド・データの取得はオペランド・データを取得するために必要とされる複数の処理サイクルの満了まで条件付命令の保留することを含み、そして
少なくとも一つの処理サイクルの省略は、複数の処理サイクルの満了の前に、その条件付命令が実行されるべきでないことを条件が示すという判定に基づく条件付命令について保留を停止することを含む、請求項１１記載の方法。
【請求項１３】
解析ステップは、
パイプラインを通してまだ完全に実行されなかったいずれかの古い命令が条件付命令を実行するために必要とされる条件を設定するかどうかを判定すること、及び
パイプラインにおいてまだ実行されている古い命令が条件を設定しないという判定に基づいて、条件の解析を実行することを含む、請求項１１記載の方法。
【請求項１４】
省略のステップは条件付命令が実行されるべきでないことを直ちに判定する際、それが実行されないであろうパイプラインの実行区域へ条件付命令を渡すことを含む、請求項１１記載の方法。
【請求項１５】
省略のステップは条件付命令を非動作（ＮＯＰ）命令として示すこと、及びＮＯＰ命令をパイプラインの実行区域へ渡すことを含む、請求項１１記載の方法。
【請求項１６】
省略のステップは実行区域へ渡すことなくパイプラインから条件付命令を消去することを含む、請求項１１記載の方法。
【請求項１７】
条件付命令は条件フィールド、及び条件付解析に基づいて実行される命令を含むフィールドを含む、請求項１１記載の方法。
【請求項１８】
条件付命令は、
満たされるべき条件を指定する第一の命令、及び
第一の命令において指定された条件が満たされる場合に実行されるべき動作を指定する第二の命令を含む、請求項１１記載の方法。
【請求項１９】
請求項１１記載の方法を実施するために構成されたパイプライン型プロセッサ。
【請求項２０】
命令を処理するためのパイプライン型プロセッサであって、
複数の処理命令の各々によって実行のために必要とされるオペランド・データを取得するレジスタ読取段階、
対応するオペランド・データに関して処理命令を実行する実行段階、  
実行段階によるその実行の前に、対応するオペランド・データの受取りの完了まで、複数の処理命令の各々を保留する手段、及び
処理命令の条件付命令について対応するオペランド・データの受取りの保留の完了の前に、条件付命令が実行されるであろうかどうかを判定し、且つ条件が実行されないであろうという判定に基づいて条件実行について保留を終結させる手段を含むパイプライン・プロセッサ。
【請求項２１】
パイプライン・プロセッサを通してまだ完全に実行されなかった何れかの古い命令が条件付命令を実行するために必要とされる条件を設定するかどうかを判定する手段をさらに含み、
その中で、必要とされる条件を設定するパイプライン・プロセッサを通してまだ完全に実行されなかった古い命令が全くないという判定に基づいて条件付命令が実行されるかどうかの判定が行われる、請求項２０記載のパイプライン型プロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本教示はその命令（instruction）が実行しないという条件であるところの条件付命令に関するオペランド・データの遅延待機を回避する技術に関係し、そしてそのような技術を実施するパイプライン型プロセッサに関係する。
【背景技術】
【０００２】
最近のマイクロプロセッサ及び他のプログラマブル・プロセッサ回路は実行速度を上げるためにしばしばパイプライン処理アーキテクチャに依存する。パイプライン型プロセッサはそれがパイプラインを通して移動する各命令を順次に処理するための多数の処理段階（processing stages）を含む。一つの段階が命令を処理している間、パイプラインに沿う他の段階は他の命令を同時に処理する。
【０００３】
パイプラインの各段階は各プログラム命令の全体の処理において必要な相異なる機能を実行する。順序及び／または機能は僅かに異なるかもしれないが、一般的な単純なパイプラインは命令フェッチ（Fetch）段階、命令解読（Decode）段階、レジスタ・ファイル・アクセスまたはレジスタ読取（Reg-read）段階、実行（Execute）段階、及び結果書戻し（Write-back）段階を含む。さらに進んだプロセッサ設計はこれらのいくつか、または全て段階をこれらの機能の小部分を実行するためにいくつかの個別の段階に分解する。スーパー・スカラー設計は並行パイプラインにおいて動作を同時に行うためにさらに機能を分解し、且つ／または複製機能を提供し、或いは特定の機能を特定のパイプラインに委任する。プロセッサ速度が増加するにつれて、或る段階はその機能を実行する時間が少なくなる。性能を維持し、あるいはさらに上げるために、各段階は細分化される。新しい各段階はあるサイクルの間あまり仕事をしないが、高クロック速度で同時に動作する多くの段階がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
高速アーキテクチャでは、命令が動作するために必要なデータ、即ち、対応するオペランド・データを取得することはプロセッサ・サイクル時間と比較してより多くの時間を必要とし、そして一以上の遅延サイクルをもたらすことになる。さらに、初期もしくは古い命令がそのオペランド・データを一般的に指定レジスタに書込んだ後で、 一つの命令がオペランド・データを取得しなければならないことはしばしば起こる。オペランド・データを書込む命令は（例えば、乗算について）いくつかの処理サイクルを要し、且つそのオペランド・データを使おうとする後の命令は古い命令が必要なオペランド・データを計算して、完了するまで待たなければならないとき、リード・アフター・ライト（read after write）の危険が発生する。後の命令はその演算を完了するために初期の命令からのデータを必要とするという点で真のデータ依存性がある。その結果、後の命令の処理はレジスタ読取段階において、或いは実行段階の開始におけるいずれかで失速する。
【０００５】
失速はますます処理サイクルを遅延させるので、オペランドを書込みつつある古い命令の待ち時間が増加するにつれてこのリード・アフター・ライト（ＲＡＷ）の危険の影響は増大する。パイプラインがただ一つの実行段階しか持っていなければ、後の命令はいずれにせよ実行を終えるために古い命令を常に待つから、その危険は実際に問題にはならないであろう。しかしながら、パイプラインはスーパー・スカラー・アーキテクチャにおける多重実行段階または並行実行段階を含むために深くなるので、後の命令は古い命令がそれの前で実行中であるとき、一以上の段階を通して進行するであろうが、後の命令の段階は初期の命令からのオペランド・データ結果に関して待機（時間稼ぎ）しなければならない。
【０００６】
一般的にオペランド・データがレジスタ・ファイルから取得されれば、データに関する待機はない。しかしながら、命令がレジスタ・ファイル読取段階において（もしくは、初期に）時間稼ぎすべきであればレジスタ・ファイルからのデータに関する待機があり、そしてレジスタ・ファイルを書込むために長い潜在オペランド・データに関する待機がある。この場合には、待機命令はそのデータを取得するためにレジスタ・ファイルを読取る（もしくは再読取りする）。他の結果生成段階からのオペランド・データ転送路が殆ど、或いは全くなければ、この方法だけが使用される。実質的に、全ての最近のプロセッサはオペランド転送ネットワークを持っており、そしてレジスタ・ファイルからＲＡＷオペランドを読取る必要がない。
【０００７】
条件付実行命令はいくつかの識別条件、通常は条件レジスタ中の一以上のビットによって指示された条件の状態（status）に基づいて、実行するかどうかという命令である。条件付実行命令は条件コード（ＣＣ）レジスタにおける一以上の条件コードが命令において指定された条件に合致する場合にその指定された機能の実行へ導く。その条件が満たされなければ、条件付命令は実行されないであろう。その場合には、命令は実行なしのパイプラインのさらなる段階を通過する「ＮＯＰ」命令として示され、或いは条件付実行命令はパイプライン中の命令の流れから取除かれる。一般に、条件付解析は実行処理の一部として行われる。
【０００８】
大部分の条件付命令、例えば、条件付加算、減算、乗算、除算、等々はそれぞれの条件が満たされるとき、指定された機能の実行のためのオペランド・データを要求する。条件付命令が実行されれば（条件が満たされれば）、さらなるその処理はレジスタ・ファイルから、またはパイプライン自身から結果転送ネットワークを介して、またはメモリから、取得されるべき必要なオペランド・データを待たなければならない。現存システムは条件が満たされるかどうかに関係なく、パイプラインを通して条件付命令の処理を止めてこの待機を強要する。
【０００９】
後の命令がオペランド・データを必要とするが、条件付である場合、その条件が満たされなければ、結果は実行されないであろう。その場合には、オペランド・データの読取のための待機は不必要な遅延を強要する。
【課題を解決するための手段】
【００１０】
ここにおける教示はＲＡＷの危険があるオペランド・データを待っている間にそうでなければ強要されるであろう非実行条件付命令に関する遅延を緩和する。実行の前の適切な点において、条件に関する判定が行われる。命令がパイプラインの間のこの通過（pass）に基づいて実行しないような条件であれば、条件付命令に関する保留が終結する、即ち、全ての関連するオペランド・データの受取の終了の前に省略、或いは停止される。
【００１１】
そのような教示の範囲は、例えば、いくつかの処理段階を含むパイプライン・プロセッサを通して条件付命令の処理を制御する方法を包含する。その方法はパイプラインの第一の段階で条件付命令を解読すること、及びその命令がパイプラインの後の段階によって実行されるべきであるかどうかを判定する命令を実行するために必要な条件を解析することを含む。その命令が実行されるべきでないことを条件の解析が指示するならば、まだ受取られてなかった、そうでなければ条件付命令の実行に必要とされたであろういずれかのオペランド・データの失速は短縮されるか、省略される。
【００１２】
非実行条件付命令はそのオペランド・データの全てを受取るのを待つ必要はない。例えば、前の命令が条件付命令に関するオペランド・データを計算して、書込むまで、もはや遅延はない。
【００１３】
一般的に、条件付命令の指定条件が満たされなければ、命令は実行しないであろう。しかしながら、指定条件が満たされても、条件付命令は実行しないように構造化される場合がある。
【００１４】
命令に関する実行なしで命令がパイプラインを通して進行することを可能にするいくつかの処理技術がある。例えば、その命令は非動作（ＮＯＰ）命令として示され、あるいは変換される。後の段階はＮＯＰを認識し、そして元の命令を実行しないであろう（ＮＯＰはＮＯＰとして実行されることに注目せよ）。代りに、長い待ち時間データの待機を回避するために全てのオペランド・データが受取られたかのようにその命令は示されるであろう。この後者の場合には、実行（Execute）段階が命令を処理するとき、それは条件がその命令が実行されるべきでなく、従って働くべきでなかったことを再び決定するであろう。
【００１５】
他の手法は命令が適用可能条件状態によって実行されない最初の決定に応じて完全にパイプラインからの非実行条件付命令を取除くであろう。条件付命令はその命令が実行しないであろうこと、或いはプロセッサが条件付命令を現在保留している段階において空の状態でクロック動作するであろうことを決定した段階において列になっている次の命令を重ね書きすることを可能にすることによって効果的に除去されるであろう。
【００１６】
条件付命令によって指定された条件が設定されない場合が発生する。初期の命令が必要なオペランド・データを書込むとき、初期の命令はまた特定の条件の状態を指定するコードまたはデータを設定する。条件が条件付命令の実行に導くであろうかどうかに関して決定が行われ得る前に、まだ処理中の初期のいずれかの命令は適切な条件に関して多分データを設定するかどうかを決定するためパイプラインにおける条件付命令を見通すことが必要である。適切な条件データを設定する初期の命令のそのような可能性がないならば、条件解析は条件付命令が実行するかどうか、そしてその命令の実行に必要なオペランド・データを待つかどうかを決定することができる。適切な条件データを設定するであろう初期の命令があれば、条件付命令が実行するであろうかどうかを決定し得る前に既知である条件データの更新を条件付命令は待たなければならない。
【００１７】
本教示はまたパイプライン型プロセッサを包含する。例えば、そのようなプロセッサは解読段階、レジスタ読取段階、及び実行区域（execution section）を含む。実行区域は多数の段階を含む。一つの命令の実行は一つの命令が指定条件の発生に基づいて実行されるという点で条件付である。一般的に、命令はデータ転送ネットワークによってすぐには解決し得ないＲＡＷの危険に遭遇するとき、その実行のために必要な全てのソース・オペランド・データを取得してしまうまで実行からそれを阻止して、保持される。しかしながら、条件付命令の実行前の保留は指定条件が発生しなかった決定に基づいて停止される。
【００１８】
さらなる目的、利点、及び新規の特徴は続いての記述の中で一部は説明され、そして一部は下記及び付随の図の吟味に基づいて当業者には明白になり、或いは実例の製造または動作から分かるであろう。本教示の目的及び利点は付加請求項で特に指摘される方法論、手段、及び組合せの実践あるいは使用によって実現、且つ達成される。
【００１９】
図面は本教示と一致する一以上の実施を限定する目的ではなく、実例の目的だけのために描いている。図面では、同じ数字は同じか、類似の要素を参照する。
【発明を実施するための最良の形態】
【００２０】
次の詳細な説明では、多数の特定の詳細が適切な教示の完全な理解を行うために実例として示される。しかしながら、本教示がそのような詳細な記述なしでも実践されることは当業者に明白であろう。他の場合には、周知の方法、手続き、要素、及び回路構成が不必要に本教示の形態を不明瞭にすることを避けるために詳細なしで比較的高水準で説明されてきた。
【００２１】
ここに開示した様々な技術は非実行条件付命令に関するオペランド・データの受取りを待つために、パイプラインにおいて条件付命令の失速を解消、または回避することに関係する。例えば、パイプラインを通してこのパス上で実行しないであろう条件付命令について、そのような技術はパイプラインを通して実行中である初期の命令によるオペランド・データの書込みの待ち時間を低減、または除去する。
【００２２】
条件付命令の実行、即ち、命令によって指定された処理の実行は条件コード（ＣＣ）レジスタにおいて一以上のビット集合で表されるような指定条件に依存する。指定条件が満たされれば条件付命令が実行しないように構造化される場合がある。しかしながら、実例のさらなる議論のために、条件付命令は条件が満たされれば実行し、そして指定条件が満たされなければ実行しない。
【００２３】
参照は付随の図に例示された実例に対して詳細に行われ、且つ下記で論じられる。図１はパイプライン型プロセッサ１０の単純化したブロック図である。議論を容易にするために、パイプライン１０の実例は本質的に一つのパイプを実施するスカラー設計である。しかしながら、ここに論じた条件付命令の処理はまた並行パイプラインを実施するスーパー・スカラー設計及び他のアーキテクチャに適用できることを当業者は理解するであろう。同じく、パイプライン（例えば、段階の数）の深さは単に代表的なものである。現実のパイプラインは実例のパイプライン１０より少ない段階、あるいは多い段階を有する。現実のスーパー・スカラーの例は二つ以上の並行パイプラインから成る。
【００２４】
単純化したパイプライン１０は五つの主要な範疇のパイプライン処理段階、フェッチ（Fetch）１１、解読（Decode）１３、レジスタ読取（Reg-read ）１５、実行（Execute）１７及び書戻し（Write-back）１９を含む。図の矢印は必ずしも物理的結合ではなく論理的データ・フローを示す。これらの段階はいずれも適切な機能の一部を実行する多数の段階に分解され、もしくはそのパイプラインは追加の機能を提供するために追加の段階を含むことを当業者は認識するであろう。議論のために、いくつかの主要な範疇の段階は一つの段階として示したが、一般的には各々は高速プロセッサに関して二つ以上の段階に分解される。条件付命令を考慮し、且つそのような命令のために必要なソース・オペランド・データの書込みの待ち時間を回避する処理の議論に役立つように、実行区域は多数の段階を含むとして示される。
【００２５】
典型的パイプライン１０において、最初の段階は命令フェッチ段階１１である。フェッチ段階１１は後の段階による処理のために命令を取得する。フェッチ段階１１はメモリ２１によって系統的に表されたメモリの序列（hierarchy）から命令を取得する。メモリ２１は一般的に命令またはレベル１（Ｌ１）キャッシュ、レベル２（Ｌ２）キャッシュ、及び主メモリを含む。命令は他の情報源、例えば、ブートＲＯＭまたはディスク装置から主メモリにロードされる。フェッチ段階１１は各命令を解読段階１３に供給する。命令解読段階１３の論理は受取った命令バイトを解読し、そしてその結果をパイプラインの次の段階に供給する。
【００２６】
条件付処理は実例１０では早くも解読段階１３に始まる。条件付処理は命令の処理を制御する条件が条件付命令の実行を必要とするかどうかを決定するために一つ以上の条件状態を示すデータの解析を必要とする。実例は条件コードを条件データとして使用する。条件コードは一般的に条件レジスタに設定されたビットである。例えば、ＡＲＭ表記は条件コード（ＣＣ）レジスタ２３を参照し、それは一般的にＮＺＣＶ条件ビットを含む。負（Ｎ）ビットは最後前に記録された（必ずしも全ての結果が記録されるとは限らないことに注目せよ）結果が負（negative）であるかどうかを示す。ゼロ（Ｚ）ビットは結果が全てゼロであったかどうかを示す。キャリー（Ｃ）ビットは最後の結果がキャリーアウトを包含したかどうかを示す。オーバフロー（Ｖ）ビットはその結果がオーバフローであったかどうかを示す。後で論じるように、その処理の一部として、解読段階１３の論理は各命令が条件付命令であるかどうかを判定するであろう。条件付であれば、条件付命令がプロセッサ１０のパイプラインを通るこの通過の際に実行するかどうかの最初の判定として、解読段階は様々な条件を示すＣＣレジスタ２３におけるビットの状態を調べる。
【００２７】
次の段階は段階１５で表される局部（local）レジスタ・アクセスまたはレジスタ読取（Reg-read）を行う。レジスタ読取段階１５の論理は多目的レジスタ（general purpose register：ＧＰＲ）ファイル２９中の指定レジスタにおけるオペランド・データにアクセスする。ファイル２９には番号０〜ｎ−１のｎ個のＧＰＲレジスタがある。いくつかの場合には、レジスタ読取段階１５の論理はメモリまたは他の情報源からオペランド・データを取得する。条件付命令に関して後でさらに詳しく論ずるように、条件付命令が実行するであろうかどうか判定するために、レジスタ読取段階１５の論理はまた様々な条件を示すレジスタ 23 においてビットの状態を調べる。
【００２８】
レジスタ読取段階１５は命令及び必要なオペランド・データを実行（Execute）機能を提供する段階１７の群に渡す。実行段階１７の群は本質的に取出された検索オペランド・データに関する各命令の特定の機能を実行し、そして結果を生成する。実行機能を提供する段階は、例えば、算術演算ユニット（arithmetic logic unit：ＡＬＵ）を実施する。実例では、パイプラインの実行区域１７は多数の段階を含む。そのような段階の数は異なるが、この例の目的のためには三つが示され、ＥＸＥ１段階３７、ＥＸＥ２段階３９及びＥＸＥ３段階４１として一般に参照される。
【００２９】
実行区域１７の最後の段階、この場合には、ＥＸＥ３段階４１は各命令の実行の結果を書戻し（Write-back）段階１９に供給する。勿論、ＥＸＥ段階３７及び３９から書戻し段階１９への「早期出力（early-out）」経路も同じくある。また、一般的にパイプラインを通過する最新の命令を送るために結果転送ネットワークもあるであろう。段階１９は結果をファイル２９におけるレジスタに、或いはメモリ（示されない）に書戻す。一つの命令によってＧＰＲレジスタに書込まれたデータは、オペランド・データとして読取られ、そしてプロセッサ１０のパイプラインを流れる後の命令に従って処理される。
【００３０】
別々に示されていないが、パイプライン１０の各段階は一般的に適切な論理機能を実施する状態機械、等々、及び命令及び／またはいずれかの処理結果を次の段階に、或いは元のＧＰＲレジスタ・ファイル２９へ渡す関連のレジスタを含む。
【００３１】
パイプライン１０を通して処理される大部分の命令は命令の実行の間に処理されるために、オペランド・データを必要とするであろう。初期または古い命令は一以上の段階３７、３９及び４１を通して実行したが、ＧＰＲファイル２９を書込まなかったか、その結果を従属命令がそれを行詰まらせることなく受取るのに間に合わせて転送ネットワークに置かなかったとき、しばしば、そのような命令は段階、ＥＸＥ１段階または初期の段階にオペランド・データを待機することを含む。このデータ依存性はリード・アフター・ライト（ＲＡＷ）の危険を引き起こす。
【００３２】
時々、オペランド・データを書込む初期の命令はその計算を完了し、そして結果を書戻すためにいくらかの処理サイクルを要する。例えば、乗算命令は乗算を完了するためにいくらかの処理サイクルを必要とする。これらのサイクルの間、オペランド・データ、例えば、乗算の結果を必要とする後の命令は古い命令が必要なオペランド・データを計算し、完了してしまうまで待たなければならない。別の例として、初期の命令の実行はデータを指定レジスタにロードするために演算を始動する結果となる。しかしながら、データ間違い（ロードされるべきデータがキャッシュにない）があれば、他のいくつかの資源からデータを読込むためにローディングは待ち行列に入れられる。ローディングを要求した命令の実行は完了するけれども、実際のローディング作業は必要なデータがレジスタにロードされ、そして後の命令によって使用するオペランド・データとして利用可能になるまでにいくらかの追加サイクルを要する。
【００３３】
必要なオペランド・データがそのような状況において利用可能になるために必要な時間の結果として、オペランド・データ失速を必要とする後の命令のための処理が停滞する。必要なオペランド・データの失速は解読（Decode）段階にあるであろう。一般的に、プロセッサ１０は一つのレジスタ読込み段階１５或いは最初の実行段階（ＥＸＥ１）３７の開始においてこの失速を課す。実例では、オペランド・データを待機する失速はオペランド・データを必要とするいずれかの条件付命令を含めて、ＥＸＥ１段階３７において各命令を保留する。
【００３４】
ここに教示したように、その命令において、或いはその命令のために指定された条件が満たされなければ、条件付命令は段階３７における失速を省略するか、失速の早期終了をもたらすであろう。条件が満たされれば、或いはその命令が条件付ではなければ、その命令は正常な方法で必要なオペランド・データの受取りを待つであろう。
【００３５】
条件付命令の正常な処理では、ＥＸＥ１段階３７のような一つの実行段階はレジスタ２３から段階３７へ矢印で表されたように条件付命令を処理している間に条件を調べる。段階３７〜４１における次の処理はレジスタ２３における条件コードＣＣと命令において指定された条件との比較に基づいていずれかのオペランド・データに関して命令の機能を実行することをしないであろう。
【００３６】
その上、条件付命令はパイプライン１０を下方に通過するので、パイプラインの一以上の初期の段階は同様の方法で条件を調べるであろう。実例では、最初の検査はレジスタ２３から解読段階１３への矢印で表されたように、解読段階１３における処理の間に行われる。レジスタ２３から解読段階１３への矢印で表されたように、その段階が条件付命令を処理している間、レジスタ読取段階１５はまたその条件が満たされるかどうかを判定するために条件レジスタ２３を調べる。これらの初期の検査のいずれかがパイプライン１０を通る条件付命令の特定の通過に関して、その条件が満たされないであろうことを判定すれば、そうでなければ条件付命令の実行のために必要とされたであろうが、まだ受取られなかったオペランド・データの受取りの完了に関して処理はＥＸＥ１における待機を終了するか、省略するであろう。
【００３７】
従って、条件付命令の処理は指定条件が満たされるかどうかを判定するために、命令が条件付であること及び条件状態を示す条件コードまたはビットを調べることを必要とする。命令は自身の中にそれが条件付であることを示すフィールドを持つか、命令の条件付が別の命令または機構によってそれに課せられる。その教示は様々なソフトウェアまたは命令フォーマットに適用可能である。しかしながら、簡潔にいくつかの実例を要約することは役に有用である。
【００３８】
いくつかのプロセッサ・アーキテクチャ、例えばアドバンスド・ライズ・マシン社によって認可された「ＡＲＭ」型プロセッサは条件付命令に対応する。ＡＲＭ命令セットは命令が条件付であるか、条件付でないかを判定する命令それ自身の一部であるフィールドを有する。アドバンスド・ライズ・マシン社はまたＴＨＵＭＢ-２命令セットを提供する。この後者の命令セットでは、命令の条件付は初期の命令によってそれに課せられる。ＴＨＵＭＢ-２命令セットは（If Thenに関して）ＩＴと呼ばれる条件賦課命令を有する。ＴＨＵＭＢ-２命令セットは１６及び３２ビット命令長の両方を有する。ＩＴ命令自身は僅か１６ビットである。その上、ＩＴ命令は次の四つの命令まで影響を及ぼし、その各々は１６または３２ビットである。
【００３９】
図２は通常のＡＲＭフォーマットにおける条件付命令のフォーマットを例示する。その命令は例示した表記ではビット３１からビット０まで番号がつけられ、３２ビット長である。ＡＲＭの条件付命令は４ビットの条件フィールド（ビット３１〜２８）、そして従来の命令について２８ビット（ビット２７〜０）を含む。条件フィールドは命令が条件付きであるかどうか、条件が満たされるかどうかを判定するためどのコードを考慮すべきか、そして恐らくはその条件がどのように満たされるかを実質的に指定する条件コードを含む。残りの２８ビットは条件が満たされれば実行されるべき命令を含む。図３に関して、ＴＨＵＭＢ-２モードにおいて、「条件付」命令は少なくとも二つの命令Ａ１及びＡ２を含む。第一の命令Ａ１は条件命令文を提供し、そして第一の命令Ａ１の条件が満たされれば次の命令（或いは、次のいくつかの命令）Ａ２が実行されるべきことを示すＩＴ型命令である。従って、第二の命令Ａ２の実行は第一の命令Ａ１によってそれに課せられた条件付命令にされる。上記で述べたように、Ａ２は第二の１６ビット命令として示されているが、ＩＴ命令Ａ１によって条件付きにされた次の各々の命令（ＴＨＵＭＢ-２の現行版における最大四つの次の命令）は１６または３２ビット長である。
【００４０】
どちらの場合でも、条件が満たされなければ命令が実行されず、アーキテクチャ的に明白な結果は条件が満たされなければ生成されないことを意味する。各々の場合において、パイプライン１０の一以上の段階における論理は条件フィールドにおけるコードから条件付命令を認識し、そして条件コード（ＣＣ）レジスタ２３におけるビットが指定条件を満たすかどうかを判定する。一般的に、その条件が満たされたかどうかの判定は全てのオペランド・データが取出された後でのみ行われた。
【００４１】
しかしながら、条件が特定の条件付命令について満たされるかどうかを判定するために、ＣＣレジスタ２３における条件データが初期の命令によって設定されなければならない場合があることは注目されるべきである。一以上の段階、例えば解読段階１３、レジスタ読取段階１５、またはＥＸＥ１段階３７の論理は現在の条件付命令に関して条件判定のために条件コード（ＣＣ）レジスタにおいて適切なビットの設定を実行する必要があるかどうかを見込むためにパイプラインを下まで見下ろす。実行されずに残っており、条件コード（ＣＣ）レジスタ２３における特定のビットを設定するであろう初期の命令がなければ、初期の段階の論理は条件がプロセッサ１０のパイプラインを通る条件付命令のこの通過に関して満たされるであろうかどうか判定することができる。この時、命令がこの通過に関して実行するかどうかに拘らず、それはその条件から判定することができる。そうでなければ、実行はないであろうし、オペランド・データを待つ必要はない。
【００４２】
適切な条件データを設定したであろう初期の命令に関する見通しは様々な方法で実施される。命令及び状態を追跡するための最適解は特定のパイプライン・アーキテクチャについて選択され、そして大抵はまだ必要なオペランド・データを書込み、或いはロードする初期の命令の検査に使用される手法に類似している。しかしながら、条件付データの設定に関する二、三の例を要約することは有用である。
【００４３】
実例として示したような単純な順序正しい（in-order）実行パイプラインは命令がパイプラインを通って流れるので連続して各命令を実行する。そのようなパイプラインでは、各々の実行段階は現在その段階における命令がその実行の一部として条件コードを設定するかどうかを示す制御ビットを含むであろう。条件付命令を処理する段階は条件付命令を実行するどうかをその段階が判定することを可能にするため、初期の命令が条件コードを設定しないであろうときを判定するそれらの制御ビットを考察する。例えば、条件付命令を処理するレジスタ読取段階１５は実行段階３７、３９及び４１の制御ビットに関するＯＲ論理を使用するであろう。全ての制御ビットが否定（no）を示せば、ＯＲ結果は否定であり、そしてレジスタ読取段階１５は実行段階３７、３９及び４１を通して実行中の初期の命令が実行しないであろうことを判定することができる。条件コードの転送が使用されなければ書戻し段階１９におけるいずれかの命令の検査がまた含まれるであろう。代りに、命令が条件コードを設定するであろうことを示す制御ビットに達することなく全ての実行段階を精査が通過するまで、条件付命令を処理する段階は初期の命令を実行する段階３７、３９及び４１を通して順次に精査する。
【００４４】
適切なオペランド・データが計算され、且つ書き戻しの必要があるかどうかの判定を見通すために使用されるそれらと類似した方法で、初期の命令が条件コード（或いは、条件コードにおける適切なビット）を設定するかどうかの判定を見通すために他の多くの手法が使用されることを当業者は認識するであろう。さらに複雑な手法がさらに複雑なプロセッサ・アーキテクチャ、例えば、レジスタ再配置を使用するスーパー・スカラー設計においてアプリケーションのために必要とされるであろう。例示した実例では、初期の命令がレジスタ２３においてコードを設定するかどうかが判定された。勿論、多数の条件レジスタがあり、且つ／または命令はレジスタにおける一以上のビットの部分集合のみを設定する。例えば、適切な条件レジスタまたは他のいくつかの条件データ配置における適切なビットを設定するために条件付命令解析はいずれかの初期命令に関して待機する必要がないことを確認するために、予測手法（look ahead scheme）が調べなければならない特定の条件設定及び特定の条件に適応される。
【００４５】
上記で概説したように、その論理は条件付命令がパイプラインを通して現在の通路上で実行しないであろうことを判定する。従って、プロセッサ論理はそうでなければオペランド・データの提供を実行するために一以上の初期の命令の待機を含むであろう失速を省略、或いは除去するステップを要する。例えば、その命令は非動作（ＮＯＰ）命令として示され、或いは変換されるであろう。ＮＯＰ命令はＥＸＥ１段階３７を直ちに通過し、そして後の段階がＮＯＰを認識し、そして元の命令を実行しないであろう。代りに、全てのオペランド・データが受取られ、且つ実行段階に渡されたかのように、その命令は示されるであろう。この後者の場合には、 実行段階３７が命令を処理するとき、その条件は命令が実行されるべきでなく、従って作動されるべきでないといった条件であったことを告げられるか、判定するであろう。他の方法は、命令が適用可能な条件状態によって実行されないであろうという最初の決定に応えてパイプラインから条件付命令を除去するであろう。条件付命令を現在保留する段階において次の命令がそれに重ね書きするか、きれいな状態でクロック動作することを可能にすることによって、条件付命令は効果的に除去されるであろう。
【００４６】
古い命令が適切な条件ビットを設定するかどうかの判定は特定の条件付命令に関して、初期の命令がＣＣレジスタ２３における関心のビットに影響するであろうかどうかを判定する、ビット解析であるであろう。実例では、条件コード（ＣＣ）レジスタ２３におけるいずれか１ビットを設定するであろういずれかの命令はそのレジスタにおける全てのビットを設定する。それ（命令）は新しい条件ビット・データによってそれが変えるいずれかのビットを設定するであろう。変わらないビットは古い値によって書き換えられる。そのような例では、初期の命令が関心のビットを条件付命令にもたらすかどうかを検査する論理は、どのビットが初期の命令によって設定されるかのビットごとの解析なしで、いずれかの古い命令がプロセッサ１０のパイプラインを通してまだ実行中であるかどうかを検査する必要がある。スーパー・スカラー設計では、関心の命令に対する条件付判定を行うために並行パイプラインにおいて実行中の命令が条件レジスタ及び条件レジスタ中の関心のビットを設定するであろうかどうかをまた判定する必要である。
【００４７】
条件コード（ＣＣ）レジスタ２３はオペランド・データが戻って来る前に設定されれば、プロセッサ１０は必要条件が満たされないと仮定すると条件付命令の失速を終結することができる。いくつかの場合には、実行中の古い命令は条件コード（ＣＣ）レジスタ２３を設定しないであろう。他の場合には、古い実行中の命令は条件コード（ＣＣ）レジスタを設定するであろうが、条件付命令に関する全てのオペランド・データが利用可能になる前に条件コード（ＣＣ）レジスタ２３を設定するであろう。双方の場合において、最近の到着オペランド・データを取得するために失速によって課せられたいくらかの、または全ての時間遅延は適切な条件が満たされないとする初期の判定によって除去される。
【００４８】
この点において、図４に関して、典型的処理の流れを考察することは有用である。図において描かれた処理の流れは処理パイプライン１０のいくつかの段階の機能を包含する。パイプライン１０の段階の論理において、例示した処理ステップの実施のための正確な場所はパイプライン型プロセッサ技術を経験した当業者の中にあるべき問題であり、そしてどの段階が特定のステップを実施するかに関する次の議論における記述はただ実例によって与えられる。
【００４９】
例示された処理は命令の最初の解読（Ｓ１）で始まる。上記で述べたように、ＡＲＭ命令または二つ（或いは、それ以上）のＴＨＵＭＢ-２命令の初期命令のフィールドは命令を条件付きとして識別する。従って、解読論理は或る命令が条件付命令であるかどうかを判定するため命令の適切な部分を吟味する（ステップＳ２）。その命令が条件付でなければ、処理はＳ２からＳ３へ進み、その点で後の段階がいずれかの必要なオペランド・データを含む適切な資源にアクセスを始める。オペランド・データを含む資源は一般的にレジスタ・ファイルである。オペランド・データの受取りはそれが完了するまでいくつかの処理サイクルを通って進行する。我々の初期の実例のパイプライン型プロセッサ１０では、ＥＸＥ１段階３７は命令に関して必要な全てのオペランド・データを含むと仮定する。そこから、プロセッサが他の段階から後でオペランド・データを転送することができれば命令は実行段階に早く前進するかもしれないが、命令及びオペランド・データは実行を完了するために残りの実行段階に進む（ステップＳ５）。
【００５０】
実例では、オペランド・データを取得するために（Ｓ３〜Ｓ４）、例えば、転送ネットワークからデータを受取るために必要とされるいくらかの時間期間があり、そこでは初期の命令からのデータがＲＡＷの危険に関して取得される。同様に、そのオペランドについては転送ネットワークがないので、レジスタ・ファイルがＲＡＷデータを取得するために使われるならば、いくらかの時間期間がレジスタ・ファイルを読出すために必要である。この期間は、例えば、ＥＸＥ１段階３７において待機し、或いはさらに遠隔の資源からデータをローディングする命令についてそれが取得される場所に初期の命令が必要なデータを書込むことを可能にする時間を含む。同様に、そのオペランドについては転送ネットワークがないので、レジスタ・ファイルがＲＡＷデータを取得するために使われるならば、いくらかの時間期間がレジスタ・ファイルを読出すために必要である。
【００５１】
さて処理ステップＳ２の考察に立ち戻ると、そこでそれが解読論理は条件付命令であるかどうかを判定するために命令の適切な部分を調べた。今度は現在の命令が条件付命令であると仮定する。従って、解読段階１３はその命令が条件付であることを判定し、そして処理はステップＳ２からステップＳ６へ進む。ステップＳ６では、別々に示されないが、後の段階はいずれかの必要なオペランド・データを含む適切な資源にアクセスを始める；そして、基本的にステップＳ３〜Ｓ４と同様に、オペランド・データの受取はそれが完了するまでいくつかの処理サイクルを通して継続する。しかしながら、その命令がＳ２において条件付であるという決定はオペランド・データを取得するのと同時に起こる条件付処理を実施するためにＳ６で始まるいくつかのステップを開始させる。
【００５２】
ステップＳ６で、一つの処理段階の論理はそれらの初期の命令のいずれが条件データを設定するであろうかどうか判定するために、現在の条件付命令より先に、パイプラインにおいてまだ実行中の初期の命令を見る。実例では、レジスタ２３は４ビットの「 条件コード」（ＣＣ）を保持し、そしてその論理は実行中の初期の命令の一つがレジスタ２３におけるコード値を書換えるであろうかどうかを判定する。前の命令が条件コードをレジスタ２３に設定するであろうならば、現在の条件付命令の処理はステップＳ７に示されたように設定されるべきそのコードを待つ必要があるであろう。
【００５３】
今度は、前の命令が条件コードをレジスタ２３に設定するであろうことをＳ６における判定で検知することを仮定する。その場合には、処理はＳ７へ進み、その中でその論理は初期の条件コード更新が完了したかどうかを判定する。条件コード更新が完了していれば、処理はＳ８へ進み、その命令がＮＯＰに定義、あるいは変換されたように実施されるべきかどうかを判定するために条件が試験される。
【００５４】
Ｓ６において、論理は条件コードをレジスタ２３に書込むパイプラインにおいてまだ実行中の初期の命令がないことを判定する。初期の命令が条件コードをレジスタ２３に設定しないであろうことを論理が判定すると、条件付命令において指定条件を検査することが今や可能である。従って、Ｓ６における処理は今やステップＳ８へ進む。
【００５５】
Ｓ８において、適切なパイプライン段階の論理はＣＣレジスタ２３における条件コードの試験及び条件フィールドによって指定された条件付命令の要求に基づいて、指定条件が満たされたかどうかを判定する。命令の条件フィールドは一つ、二つ或いはそれ以上のＣＣレジスタのビットを組合わせて参照する。例えば、そのフィールドは基本的に前の命令がＺビットを１に設定するかどうかを検査するために全てがゼロの条件を指定する。ＣＣレジスタ２３を設定する前の動作から由来する正数はＮビット（負でない）中の０及びＺビット（全てゼロとは限らない）中の０によって示されるであろう。従って、正である初期の結果に基づく条件付命令は、それらが双方共に０であることを判定するためにＮ及びＺビットを検査するであろう。
【００５６】
その条件が満たされれば、命令はパイプライン１０の段階３７〜４１において実行するであろう。従って、全部のオペランド・データが必要とされる。この場合には、全てのオペランド・データが受取られたかどうかを試験するために、処理はステップＳ３へ進む。全てのオペランド・データが受取られたならば、Ｓ３における処理はステップＳ５へ進み、命令及びオペランド・データが実行のために適切な段階に渡される。全てのオペランド・データが現在の命令についてまだ受取られてなかったならば、処理Ｓ３はＳ４に進み、全てのオペランドを受取るために少なくとも１処理サイクルをプロセッサに待たせることになる。全てのデータ・オペランドが受取られたとき、処理はステップＳ４からステップＳ５へ進み、命令及びオペランド・データは実行のために適切な段階に渡される。
【００５７】
ここで再びステップＳ８で始まる処理を考察する。その条件が満たされない（そして古い命令が条件コードを設定しないので満たされない）というＳ８における最初の判定に基づいて、処理はステップＳ９へ進むであろう。Ｓ９への移行はＳ３及Ｓ４を通る処理を終結、或いは迂回し、それは全てのオペランド・データが受取られるまで待機または失速を実施した。
【００５８】
先に述べたように、その条件が命令の非実行の起因となるであろうという判定の後、パイプラインを通る条件付命令の通過を再開するいくつかの方法がある。図４の例では、その命令はステップ９においてＮＯＰ（非動作）命令に示され、或いは変換される。その命令は（ステップＳ５において）実行段階に進む（それらの段階は実際には実行しないで命令を単に通過させるのだが）。
【００５９】
実例では、ＥＸＥ１段階３７におけるパイプライン論理はレジスタ２３における条件コードの吟味及び条件フィールドによって指定された条件付命令の要求に基づいてその条件が満たされるかどうかを判定するであろう。前の命令がＣＣレジスタ２３における条件コードを設定するであろうならば、この処理は設定されるべきそのレジスタにおけるコードを待つであろう。一旦、条件コードが設定されれば、その論理は条件付命令を実行しないこと、或いはコードに基づかないことを判定するであろう。しかしながら、そのような処理は実行しないであろう条件付命令に関する全てのオペランド・データの戻りを待つ必要がない。
【００６０】
実例では、条件はＥＸＥ１段階３７の間にＳ８において検査される。代りに、その条件は解読段階と同じく早期に検査されるであろう。
【００６１】
また条件が後の段階で検査されるいくつかの状況がある。例えば、条件が満たされ、且つ全てのオペランド・データがレジスタ読取段階１５に累積されるならば、条件付命令及びデータは実行段階へ通過する。それは条件が満たされることを判定すると、一以上の実行段階は条件を再検査し、その後、オペランド・データに関する命令を実行する。別の例として、条件が満たされない判定に基づいて失速が除去されれば、一つの方法は命令を「受取られた全データ」として示し、そしてその時間にＥＸＥ１段階３７に現れるすべての値と共に命令を実行段階に渡す。命令が実行段階３７、３９及び４１を通過するので、一以上のそれらの段階は条件が満たされず、且つ命令の実行を妨げるであろうことを再び認識するであろう。
【００６２】
前述の記載は何が最良の形態及び／または他の例であるか考察されることを述べてきたが、様々な改良がその中でなされること、ここに開示した主題が様々な形式及び実例において実施されること、及びその教示はここではそのいくつかしか述べなかったが多くのアプリケーションにおいて適用可能なことが理解される。本教示の真の範囲内にあるいずれかの及び全てのアプリケーション、改良及び変形を要求することは下記の請求項によって意図している。
【図面の簡単な説明】
【００６３】
【図１】パイプライン型プロセッサの単純化した実例の機能ブロック図で、それはここで論じた技術と合致する条件付命令処理を実行する。
【図２】ＡＲＭプロトコルと合致する条件付命令のフォーマットの図式表現である。
【図３】ＡＲＭプロトコルのＴＨＵＭＢ拡張と合致する条件付命令を共に形成する条件命令文及び関連の実行可能な命令のフォーマットの図式表現である。
【図４】条件付命令を処理するために適用される論理の実例を説明するのに有用なフローチャートである。
【図１】
2008537208.tif 000003
【図２】
2008537208.tif 000004
【図３】
2008537208.tif 000005
【図４】
2008537208.tif 000006
【国際調査報告】
2008537208.tif 000007
2008537208.tif 000008
2008537208.tif 000009