JP2000003295A

JP2000003295A - 回路、方法及びプロセッサ

Info

Publication number: JP2000003295A
Application number: JP11096431A
Authority: JP
Inventors: Elliott Levin Frank; フランク・エリオット・レヴィン; Stuart Moore Roy; ロイ・スチュアート・ムーア; Philip Ross Charles; チャールズ・フィリップ・ロス; Hugh Welbone Edward; エドワード・ヒュー・ウェルボン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-04-15
Filing date: 1999-04-02
Publication date: 2000-01-07
Anticipated expiration: 2019-04-02
Also published as: KR19990082730A; US6067644A; KR100309863B1; JP3537030B2

Abstract

(57)【要約】【課題】プロセッサ内での命令進行と監視するための
システム及び方法の提供。【解決手段】複数の内部ステージを介して命令を処理
するために動作可能なプロセッサが、各ステージで命令
の処理の結果を作るか、そのステージが命令を処理でき
なかった理由の理由コードを作る。結果または理由コー
ドは、後続のステージに渡され、後続ステージは、命令
の処理を試みる。第２ステージは、それ自体の結果を作
ることができず、遊休状態である時に、理由コードを転
送する。第２ステージは、遊休状態ではないが結果を作
ることができない時にはそれ自体の理由コードを生成
し、その理由コードを転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、全般的にはデータ
処理システムに適用され、具体的には、そのようなデー
タ処理システム内のパフォーマンス・モニタリングに適
用される。

【０００２】

【従来の技術】通常のコンピュータ・システムでは、ソ
フトウェア実行の最適化が、より高いシステム性能を提
供することによってより効率的なシステム設計をもたら
す。メモリ・システムの使用法は、改良のための重要な
機会を提供することができる領域である。メモリ階層ト
ラフィックの注意深い調査から、より高性能のソフトウ
ェア・アルゴリズムの開発を助けることのできる、シス
テム挙動の詳細が明らかになることがわかっている。パ
フォーマンス・モニタは、そのような調査に有用である
が、既存のパフォーマンス・モニタは、そのような目的
に関して短所を有する。

【０００３】パフォーマンス・モニタとは、コンピュー
タ・システムが有用な作業を実行する速度に影響する、
選択された内部特性を監視するのに使用される、コンピ
ュータ・システムに組み込まれた機能である。正しく構
成されている時には、パフォーマンス・モニタは、特定
の時点のコンピュータ・システムの内部状態を提供す
る。この測定手段は、これによらなければ入手が困難な
洞察を提供する。

【０００４】パフォーマンス・モニタは、通常は抽象的
なインターフェースによって隠蔽されているハードウェ
アの基礎的な詳細を明らかにするという点で重要であ
る。ソフトウェアの移植性を得るために努力する際に
は、抽象化されたインターフェースをソフトウェアに提
示して、ソフトウェアがシステムの詳細を扱う必要をな
くすことが望ましい。この抽象化は、移植性を高める際
には非常に価値があるが、これによって、最適性能を提
供するのに必須のシステム状態のいくつかが不明瞭にな
る。

【０００５】通常、パフォーマンス・モニタは、プロセ
ッサの命令実行制御および記憶域制御に関する実装依存
の情報を作成する。パフォーマンス・モニタの機能強化
によって、コンピュータのシステム・メモリからデータ
を取り出すのに必要な時間に関するコストに関するクリ
ティカルな情報が提供される。このような情報は、所与
のシステムの性能を強化する方法や新システムの設計で
の改良点の開発に関してシステム設計者の案内役にな
る。

【０００６】メモリ・システムの階層的な性質が原因
で、メモリからデータを取り出すのに必要な時間は一定
ではない。このタイミングを測定するためには、コンピ
ュータのメモリ構造の詳細の特別な考慮が必要になる。
ほとんどのソフトウェアでは、一部のデータが頻繁に使
用され、それ以外のデータはほとんど使用されない。ほ
とんどのコンピュータ・メモリ・システムは、小さいス
テージング区域を組み込むことによって、この事実を利
用している。このステージング区域には、頻繁に使用さ
れるデータが格納される。この区域は、通常は、システ
ム・メモリより小さく、より高速にアクセスできる。こ
れによって、システムは、作業をより高速に完了できる
ようになり、したがって、より高い性能を有する。同様
に、ステージング区域に保持されるいくつかの項目は、
他の項目より頻繁に使用される。これは、追加の二次ス
テージング区域の使用につながる。必要なデータが第１
ステージング区域にない場合、次に、第２ステージング
区域が検査される。項目が第２ステージング区域にない
場合、システム・メモリが検査される。必要なデータが
ステージング区域で見つかる確率が高いので、データの
取出の平均時間は、通常は、階層的に構成されたメモリ
・システムでは短い。その結果、現在のメモリ・システ
ムは、ステージング区域がアクセスの順序でより大きく
より低速になる形のステージング区域の階層として構成
される。

【０００７】最も頻繁に再利用されるデータを、使用の
点に最も近いステージング区域（以下では「キャッシ
ュ」と呼称する）に保持することが、明らかに望まし
い。これが達成される度合は、データ・アクセスの平均
時間に影響するので、システム性能にとって非常に重大
である。メモリ階層のこの態様は、所与のデータがキャ
ッシュ内の特定の点で見つからない確度を検討すること
によって定量化することができる。必要なデータがキャ
ッシュに「ない」アクセスを、「キャッシュ・ミス」と
呼ぶ。キャッシュ・アクセスに対するキャッシュ・ミス
の比率を、「キャッシュ・ミス率」と呼ぶ。キャッシュ
・ミス率に付随するのが、キャッシュにないデータを取
得するのに必要な時間の量である。階層キャッシュ・レ
ベルは、順次アクセスされる。第１キャッシュは、通常
は最も高速だが容量が最も少ない。後続キャッシュのそ
れぞれは、容量が大きくなるがアクセス速度が下がる。
所与のデータへのアクセスのコストの測定を可能にする
尺度は、キャッシュがアクセスされる順序を検討するこ
とによって定義される。最初にアクセスされるキャッシ
ュは、アクセスに必要な時間が最小であるという点で、
最も近いとみなされる。その後にアクセスされるキャッ
シュは、最初にアクセスされるキャッシュよりそれ相応
に遠いとみなされる。したがって、必要なデータにアク
セスするのに必要な時間は、そのデータを得るためにア
クセスしなければならないキャッシュの数に関してその
データがどれほど遠いかに依存する。

【０００８】

【発明が解決しようとする課題】階層メモリ・システム
を有するコンピュータでは、必要なデータの実際の位置
は、時間に依存し、本質的に予測不能である。その結
果、所与のデータを得るための時間が変動する。キャッ
シュ・ミスのコストを評価するのに使用される標準的な
方法では、キャッシュ・ミスの回数と、キャッシュ・ミ
スのそれぞれの総合持続時間（サイクル単位）の両方が
検討される。現在のコンピュータ・システムでは非常に
並列性の高い実行ハードウェアが使用されているので、
このアプローチは、その効果の正しい観察を提供しな
い。というのは、並列コンピュータ・システムでは、か
なりの度合のアウトオブオーダー（out-of-order）実行
が可能になっているからである。データ・アクセスに必
要な時間が、進行に対して予想されたものより小さい影
響を有することもしばしばである。これは、所与のデー
タにアクセスする間に他の有用な作業を行うことがで
き、したがって、さまざまなユニットで進行が発生する
可能性があるからである。したがって、キャッシュ・ミ
スが進行中のサイクル数を数えても、他のユニットが進
行を行っている可能性があるので、キャッシュ・ミスの
コストが正確には反映されない。したがって、イベント
を単純に数えるだけでは、計算機の状態の全体像は得ら
れない。この状況は、メモリ・データの取出に特有のも
のではなく、時間のかかる計算が進行を妨げる時に、同
様の状況が存在する。当業者に明白な上記および類似の
理由から、データ処理システム内でのイベントの発生の
原因および効果に関する追加情報を供給する、パフォー
マンス・モニタリングのための改良された方法およびシ
ステムを提供することが望ましい。

【０００９】

【課題を解決するための手段】本発明は、プロセッサ内
の実行ユニットのそれぞれに、各サイクルに、作られた
ものに関する標識と共に、結果または「理由コード」と
称するもののいずれかを作る能力を与えることによっ
て、前述の必要に対処する。「理由コード」は、所与の
ステージが使用可能な作業を有しない理由を識別する、
通常の命令フローの経路に沿って転送されるメッセージ
とみなすことができる。ユニットは、命令フロー内の後
続ステージに、処理の次の相のために準備ができている
命令か、命令を転送できない「理由」のいずれかを転送
する。

【００１０】これをサポートして、パフォーマンス・モ
ニタ制御レジスタは、パフォーマンス・モニタ・カウン
タが「通常選択コード」と「理由コード」のどちらを使
用してカウントしているかを示す新しいフラグを有す
る。１実施例では、モニタは、問題の「理由コード」
が、最も古い命令の完了ステージに関連する「理由コー
ド」と一致する時にカウンタを１つ増分する。

【００１１】本発明のアプローチは、命令タグを介して
「理由コード」を伝播することである。このアプローチ
は、所与のユニットに実行される命令が含まれる場合だ
けでなく、ユニットが命令を有しない場合にも命令タグ
が使用されるという点が新規である。実際の命令（すな
わち作業の単位）がない場合、タグの意味は、所与のサ
イクルにパイプラインを流れる命令がない理由に関する
「理由」情報になる。パイプライン内の各命令に関連す
る「理由コード」の追加によって、任意の時点でパイプ
ライン状態を記憶する手段が提供される。具体的に言う
と、「理由コード」によって、所与のユニットの命令が
なくなった理由が識別される。「理由コード」は、所与
の条件の原因と影響への貴重な洞察を提供し、特に、停
止の原因をより正確に識別できる。たとえば、データ依
存性は、ロード・ミスによるか、多数のサイクルを必要
とする除算によって引き起こされる可能性がある。理由
コードによって、この２つの事例が区別される。完了を
ブロックするさまざまな「理由コード」をカウントする
ことによって、特定のタイプのブロックのコストを識別
するための機構が提供される。

【００１２】前述の部分は、以下の本発明の詳細な説明
をよりよく理解できるようにするために、本発明の特徴
および技術的長所を大まかに示したものである。本発明
の追加の特徴および長所を、以下で説明する。以下は、
本発明の請求の対象を形成する。

【００１３】

【発明の実施の形態】以下の説明では、本発明の完全な
理解を提供するために、具体的なワード長やバイト長な
どの多数の具体的な詳細を開示する。しかし、そのよう
な具体的な詳細なしで本発明を実施できることは、当業
者には明白である。それ以外の場合では、無用な詳細で
本発明を不明瞭にしないために、周知の回路はブロック
図形式で示す。ほとんどの部分で、タイミングの検討な
どに関する詳細は、本発明の完全な理解を得るために必
要でなく、関連技術における通常の技術を有するものの
技術の範囲内である限り、省略した。

【００１４】これから図面を参照するが、図示の要素
は、必ずしも原寸通りではなく、同様または類似の要素
には、複数の図面を通じて同一の符号を付す。

【００１５】本発明には、命令タグだけではなく、所与
のサイクルに項目が命令パイプラインを流れない理由に
関する「理由コード」情報も含まれる。パイプラインの
概念によれば、命令は、より簡単に処理できる小さい部
分に分割される。これらの部分は、概念的には、ステー
ジまたはユニットからユニットへと流れ、各ユニット
は、その命令によって実行される全体的な動作の一部を
達成する。通常、動作ユニットは、あるクラスの命令か
らの動作を、１サイクルあたり１動作ずつ完了する。パ
イプライン内の各命令に関連する理由コードを追加する
ことによって、任意の時点のパイプライン状態を追跡で
きるようになる。

【００１６】ある命令の代わりに特定のサイクルに所与
の動作ユニットによって行われる動作には、３つの興味
深い結果がある。動作ユニットは、要求された動作を完
了している場合と、現在の動作を完了するのにさらに時
間を要する場合と、その動作を実行するのに必要な前提
条件資源がない場合がある。

【００１７】第１の場合では、動作ユニットは、対象の
動作を完了しており、別の命令を実行することができ
る。その動作が、パイプライン・ステージの後続ステー
ジが必要投する結果を実施する場合には、問題の動作ユ
ニットは、その結果を必要とするステージにその結果を
転送する準備ができており、一般に、次の動作要素自体
が次の動作または結果を受け入れることができる場合に
は、その結果を転送する。動作ユニットが作る「結果」
は、必ずしも数学的な結果という意味でのデータ値では
ないことを理解することが重要である。「結果」は、問
題の動作の完了に過ぎない場合がある。したがって、ど
の動作も、「結果」を作るとみなすことができ、その
「結果」の後続動作ユニットへの転送を、パイプライン
の流れとみなすことができる。

【００１８】第２の場合では、動作ユニットは、要求さ
れた動作を完了しておらず、要求された動作を完了する
にはさらに時間（通常は追加サイクル）が必要である。
この場合、概念上の結果の流れはブロックされる。した
がって、かなりの数の場合において、先行ユニットの
「結果」が前提条件である場合に後続ユニットにその先
行動作ユニットが「結果」を渡すことができない時に、
パイプラインの流れは、このサイクルでブロックされ
る。その１例が、メモリ階層内で必要なデータのアドレ
スを計算する責任を負う動作ユニットの場合である。一
般に、後続のメモリ・アクセス動作ユニットは、データ
にアクセスするためにそのデータのアドレスを必要と
し、したがって、この場合および他の場合に、所与の動
作ユニットのその部分での遅延が、後続ユニットを遊休
状態にさせることによって後続ユニットの進行に影響す
る。

【００１９】第２の場合のこの例の重要な点は、後続動
作ユニット自体が次の動作を受け入れることができる場
合に限って、必要なデータのアドレスの計算の遅延が、
後続ユニットを遊休状態にさせることである。後続ユニ
ットが新しい動作および結果を受け入れることができな
い場合、この例の遅延は、効果的に隠蔽される。

【００２０】第３の場合は、動作ユニットが、準備がで
きており、要求された動作を達成することができるが、
前提条件が欠けているので達成できない場合である。そ
の１例が、データのアドレスを得るまでメモリ・アクセ
ス・ユニットがデータを得られない時である。動作ユニ
ットは、データのアドレスなどの前提条件が欠けている
時には、後続の動作ユニットに結果を伝播することがで
きない。動作ユニットが後続動作ユニットのための結果
を作ることができず、後続ユニットが遊休状態になる場
合、遊休状態のユニットの連鎖が発生する可能性があ
る。このような遊休状態のユニットの連鎖を、パイプ内
の流体の流れの類推から、一般に「パイプライン・バブ
ル」と称する。最終ステージがバブルだけを作るサイク
ルが、遊休状態が露出されるサイクルである。本発明の
目的は、この「バブル」を意味のある形で使用すること
である。理由コードは、「パイプライン・バブル」を発
生させたユニットに、結果を作らない「理由」を作るこ
とによって「パイプライン・バブル」に「色を付ける」
ように要求することによって、「パイプライン・バブ
ル」の源と原因を把握できるようにするのに使用され
る。

【００２１】「バブル」を伝播するパイプラインの類推
に従って、あるユニットが、上流ユニットが結果を作ら
ないので遊休状態になっている場合に、遊休状態のユニ
ットは、上流ユニットから転送された「色付きバブル」
を受け取り、所与のユニットの「結果」に依存する下流
の依存ユニットに「理由」を転送する。後続の要素は、
「結果」または「理由」と共に転送される、提供された
フラグによって、「結果」と「理由」を区別する。やは
り、「色付きバブル」を伝播するパイプの類推が、これ
を理解するのに役立つ。転送の効果は、流れが最終ステ
ージ（通常は「完了」ユニット）に達するまで、流れの
方向へユニットからユニットへ継続される。

【００２２】「色付きバブル」の類推を使用すると、こ
の議論から、最終ユニットから発するバブルを観察する
ことによって遊休状態を把握できることが明白であり、
これによって、多数の簡単に実施されるアカウンティン
グ方式のための方法がもたらされる。１つの可能な実施
例では、カウンタのテーブルへの指標として「パイプラ
イン・バブル」を表す「理由コード」の数値を使用し、
したがって、ユニットと停止を引き起こす条件を一意に
関連付けるカウンタを１つ増分する。代替実施例では、
比較回路に結合された１つまたは複数のセレクタ・フィ
ールドが使用される。「パイプライン・バブル」に対応
する「理由コード」が、プログラム可能なセレクタの値
と一致する場合には、適当なカウンタを１つ増分する。

【００２３】理由コードは、所与の状態の原因および影
響に対する貴重な洞察を提供する。たとえば、データ依
存性は、ロード・ミスまたは多数のサイクルを必要とす
る除算によって引き起こされる可能性がある。理由コー
ドによって、この２つの場合が区別される。完了を妨げ
る異なる理由コードをカウントすることによって、特定
のタイプのブロックの正確な原因を識別できる。

【００２４】本発明の異なる展望を提供するために、組
立ラインのコンベヤ・ベルトとの類推を行うことができ
る。この類推では、上で述べた「パイプラインの流れ」
が、組立ラインのコンベヤ・ベルト上の製造品の流れに
類似する。この理想化された組立ラインでは、時間の１
「単位」ごとに、構成要素の追加（たとえば自動車の窓
ガラスの取付け）などの動作によって、物体が完了によ
り近い状態に移動される。そのような組立動作が完了し
た時に、物体は、コンベヤ・ベルト上で次のステーショ
ンに進む。所与のステーションが、要求された組立動作
を完了できない場合には、そのステーションは、一般
に、物体が組立の次の相に進むことを許可することがで
きない。通常は、ステーションが動作を完了しないこと
の有効な理由は、限られた数だけが存在する。組立ライ
ン出力の正味損失を引き起こす動作完了の失敗が必要な
場合、そのステーションは、コンベヤ・ベルトに沿って
メモを送り、そのステーションがその動作を完了しなか
った理由を示すことができる。そのステーションが動作
を完了できない理由が、内部的な理由であれ資源がない
からであれ、ステーションは、コンベヤ・ベルトに沿っ
て理由を転送する。

【００２５】その代わりに、理由が、入ってくる作業が
ない（前のステーションが次に加工される物体を提供し
なかった）ことである場合には、ステーションは、直前
のステーションから理由を記されたメモを受け取ること
になる。このメモは、コンベヤ・ベルトを介して次のス
テーションに伝播される。内部的な理由のためにステー
ションが動作を完了できない場合と、外部的な理由（す
なわち、加工すべき物体がこない）による場合の両方を
検討することが重要である。この場合、外部的な理由
は、支配的な理由として選択されなければならない。行
うべき作業がこない場合、そうでなくても作業を行うこ
とができないという事実は無関係である。

【００２６】所与の動作を完了するために複数の外部資
源が必要であり、１つまたは複数の資源が使用不能であ
る時に、重要な事例が発生する。その理由が、最も長期
にわたって欠けている資源（最初に使用不能になった資
源）である場合には、後から到着した理由は支配的でな
いので、最も以前に到着した理由を選択しなければなら
ない。したがって、新しい理由は、古い理由によって効
果的に「隠蔽」される。たとえば、バス動作を開始でき
ない時にバス動作の開始を必要とするキャッシュ・ミス
が検出された場合、正しい原因は、最も古い理由にな
る。この場合、バス動作はキャッシュ・ミスの直接の結
果であるから、キャッシュ・ミスが支配的な理由であ
る。

【００２７】上で、コンベヤ・ベルトに沿ったステーシ
ョンのすべてが従う処理を大まかに説明した。明らか
に、理由または物体は、完了した物体が集められる最終
ステーションに達するまで、コンベヤ・ベルト上を伝播
する。

【００２８】この最終ステーションでは、「アカウント
係」が、組立ラインの動作を監視する。「アカウント
係」は、到着した完了した物体を記録する（時間「単
位」ごとまたはタイム「スロット」ごとに１つ）だけで
はなく、完了した物体が到着しなかったタイム「スロッ
ト」も記録する。

【００２９】物体が作られなかったタイム「スロット」
には、その代わりに理由が到着する。理由は、その理由
カテゴリの移動カウントに適用できる。この形で、コン
ベヤ・ベルト／組立ライン上で停止したステーションを
正確に突き止めることができる。

【００３０】最終ステーションが完了するためにさまざ
まな資源が必要な時に、興味深い事例が発生する。これ
は、所与の物体が、完了のために複数のサブアセンブリ
を必要とする時に発生する可能性がある。たとえば、出
荷のためにパレットに置かれる、おそらくは完全に異な
る製品を作る複数の製造ラインの場合を検討されたい。
パレットの出荷を支配する規則が、未完了のパレットを
出荷できないというものである場合、パレットは、２つ
の理由（それぞれが異なる組立ラインから来る）で停止
する可能性がある。この場合、両方の理由をカウントす
ることが適当である。

【００３１】上記の変形では、最終動作を出荷動作とみ
なすことができ、この出荷動作では、出荷用コンテナ
が、出荷される物体に関してＬＩＦＯ（後入れ先出し）
順序で梱包される（たとえば、後部に扉が１つしかない
非常に長いデリバリ・バン）と想定されている。この観
点では、組立ラインからの物体を梱包できる事前に定め
られた順序が存在する出荷規則が予想される（たとえ
ば、配送経路の停止点のそれぞれで、コンテナに詰め込
まれたのと逆の順序で物体が取り出されるように、出荷
コンテナのそれぞれが、配送経路に送られる）。

【００３２】順序付きの場合には、停止したコンテナを
把握するための適切な方法が、梱包される物体のシーケ
ンスから欠けている最初の物体を探すことによるもので
あることは明白である。最初の欠けている物体に関連す
る理由は、それが最も緊急に必要とされる物体であるか
ら、最も関係の深い理由である。コンテナ内の最初の欠
けている物体が、組立ラインによって供給された時に、
前に２番目に欠けている物体が（あれば）、第１の欠け
ている物体になる。したがって、アカウンティングの処
理は、すべての欠けている物体が到着するまで、「欠け
ている」物体のそれぞれについて実行される。この類推
は、命令が特定の順序（すなわちプログラム順序）で終
了または完了することを保証する完了ステージを有する
プロセッサに最もよく一致する。命令をさまざまな順序
で実行することは許容可能であるが、完了の最終処理
は、プログラム順序で完了することができる。したがっ
て、組立ラインは、プロセッサのパイプライン・ステー
ジを相互接続する論理経路に関連し、最終ステーション
は、プロセッサの完了ユニットであり、固定サイズのＬ
ＩＦＯ出荷コンテナは、４命令を完了できるマイクロプ
ロセッサの完了ウィンドウを表す。本発明は、４命令よ
り多数または少数の命令を完了するシステムに適用可能
であることに留意されたい。

【００３３】この観点では、４つの所与のウィンドウの
うちの最初の２つだけが終了した場合、プログラム順で
の第３の命令は、完了が２つの命令だけを終了したこと
の理由を提供するはずである。やはり終了していない後
の命令に関連する「理由」は、後の命令がプログラム順
で最初の命令になるまでは重要でない。たとえば、所与
の完了ウィンドウ内の最初の２つの命令の両方が終了し
たが、第３の命令（進行中の除算）と第４の命令（キャ
ッシュ・ミスを伴うロード）が完了していないと仮定す
る。

【００３４】２つの命令を完了できない理由として適当
な理由は、除算の停止である。キャッシュ・ミスは、除
算の前に終了し、除算と共に完了するか、完了せず、次
の最初に停止した命令としてカウントされるかのいずれ
かになる。キャッシュ・ミスが先に終了する場合、これ
は、除算停止に隠蔽され、カウントされないはずであ
る。キャッシュ・ミスが除算の後に終了する場合、この
キャッシュ・ミスは、停止の露出された源になり、停止
の原因としてカウントされなければならない。停止サイ
クル数の最終的なカウントは、所与の動作がすべての機
会に「隠蔽」されるとは期待できないので、統計的にさ
まざまな停止の理由にまたがって分布するはずである。

【００３５】もう１つの興味深い例が、分岐誤予測が原
因で完了バッファ全体がパージされる場合である。パー
ジの次のサイクルには、完了バッファに命令がなく、理
由コードは、誤って予測された分岐に起因するものにな
る。

【００３６】「サンプル状態」を後処理することによっ
て、本発明は、異なるタイプのボトルネックのタイプと
頻度の詳細な判定を行うことができる。総合的なパイプ
ラインの状態は、完了時に捕捉されるので、完了を妨げ
る原因を観察することができる。パフォーマンス・モニ
タと共に実施されるＳＩＡＲ（Saved Instruction Addr
ess）レジスタが、完了を妨げる命令に対応するコード
を識別するので、サンプリングの反復を介して、サンプ
リングに何度も現れる「ホット・スポット」の典型的な
停止理由コードの正確な情況を得ることができる。特定
の「ホット・スポット」についてサンプルをグループ化
することによって、計算機の状態の分析を行うことがで
きる。たとえば、ブロックが、修正またはデータを以前
に読み取らせることによって軽減できる特定のキャッシ
ュ・ミスによって引き起こされていることを判定でき
る。分析から、正しい経路の実行をブロックしている誤
った経路への投機実行があることが示される場合、その
コードを更新して、この望ましくない効果を回避するこ
とができる。

【００３７】ここで図面、具体的には図１を参照する
と、請求項に示された発明によるプロセッサ１０の実施
例のブロック図が示されている。図示の実施例では、プ
ロセッサ１０に、単一の集積回路パイプライン式スーパ
ースカラ・マイクロプロセッサが含まれる。したがっ
て、下で述べるように、プロセッサ１０には、さまざま
な実行ユニット、レジスタ、バッファ、メモリおよび他
の機能ユニットが含まれ、これらのすべてが集積回路か
ら形成される。プロセッサ１０には、縮小命令セット・
コンピューティング（ＲＩＳＣ）技法に従って動作す
る、IBM Microelectronics社から入手できるＰｏｗｅｒ
ＰＣ（商標）系列のマイクロプロセッサのうちの１つ
（たとえばＰｏｗｅｒＰＣ（商標）６０４）を含めるこ
とができる。ＰｏｗｅｒＰＣ（商標）６０４プロセッサ
のアーキテクチャおよび動作に関する詳細は、参照によ
って本明細書に組み込まれる「PowerPC^TM 604 RISC Mic
roprocessor User's Manual」（注文番号MPR604UMU-01
としてIBM Microelectronics社から入手できる）に記載
されている。しかし、以下の説明から、本発明を他の適
当なプロセッサ内に組み込むことができることを、当業
者は諒解するはずである。

【００３８】図１からわかるように、プロセッサ１０
は、バス・インターフェース・ユニット（ＢＩＵ）１２
を介してシステム・バス１１に結合される。ＢＩＵ１２
は、プロセッサ１０と、システム・バス１１に結合さ
れ、プロセッサ１０およびシステム・バス１１と共にデ
ータ処理システムを形成する他の装置（たとえばメモリ
３９または別のプロセッサ）との間の情報の転送を制御
する。ＢＩＵ１２は、さらに、命令キャッシュ１４およ
びデータ・キャッシュ１６に接続され、命令キャッシュ
１４およびデータ・キャッシュ１６は、それに格納され
た局所データおよび命令の小さいセットへの比較的高速
のアクセス時間をプロセッサ１０が達成できるようにす
る。

【００３９】命令キャッシュ１４は、シーケンサ・ユニ
ット１８に接続され、シーケンサ・ユニット１８には、
シーケンシャル・フェッチャ２、命令待ち行列４、ディ
スパッチ・ユニット６および完了ユニット８が含まれ
る。シーケンシャル・フェッチャ２は、命令キャッシュ
１４から１サイクルあたり４つまでの命令を取り出し、
取り出した命令を、分岐処理ユニット（ＢＰＵ）２０お
よび命令待ち行列４の両方に送る。命令待ち行列４は、
８つまでの命令を保持する。分岐命令は、実行のために
ＢＰＵ２０によって保存され、命令待ち行列４から取り
消される。これに対して、順次命令は、ＢＰＵ２０から
取り消され、プロセッサ１０内の順次命令実行回路によ
る後続実行のために命令待ち行列４内で一時的に緩衝記
憶される。ディスパッチ・ユニット６は、実行資源の使
用可能性に応じて、命令待ち行列４からプロセッサ１０
の順次命令実行回路へ１サイクルあたり４つまでの命令
をディスパッチする。命令のディスパッチに必要な実行
資源の１つが、完了ユニット８内の１６項目のリオーダ
・バッファ９の使用可能な項目である。下で詳細に述べ
るように、リオーダ・バッファ９は、完了ユニット８に
よって、都合によってプログラム順と異なる順序で実行
された命令を、プログラム順に従って待避させるのに使
用される。

【００４０】図示の実施例では、プロセッサ１０の順次
命令実行回路に、固定小数点ユニットＡ（ＦＸＵＡ）２
２、固定小数点ユニットＢ（ＦＸＵＢ）２４、複合固定
小数点ユニット（ＣＦＸＵ）２６、ロード／ストア・ユ
ニット（ＬＳＵ）２８および浮動小数点ユニット（ＦＰ
Ｕ）３０が含まれる。これらの実行ユニットのそれぞれ
が、各サイクルに特定の命令クラスの１つまたは複数の
命令を実行する能力を有する。たとえば、ＦＸＵＡ２２
およびＦＸＵＢ２４は、加算、減算、ＡＮＤ、ＯＲ、Ｘ
ＯＲなどの数値演算および論理演算を実行する第１のク
ラスの固定小数点命令を実行し、ＣＦＸＵ２６は、固定
小数点乗除算などの命令を実行する第２のクラスの固定
小数点命令を実行し、ＦＰＵ３０は、浮動小数点乗除算
などの命令を実行する浮動小数点命令を実行し、ＬＳＵ
２８は、ロード命令およびストア命令を実行し、ＢＰＵ
２０は、分岐命令を実行する。

【００４１】プロセッサ１０は、ＢＰＵ２０、ＦＸＵＡ
２２、ＦＸＵＢ２４、ＣＦＸＵ２６、ＬＳＵ２８および
ＦＰＵ３０内の複数のパイプライン・ステージで複数の
命令を同時に処理することによって、高性能を達成す
る。このパイプライン式アーキテクチャでは、各命令が
ステージのシーケンスで処理され、各ステージでの処理
は、異なるステージの他の命令の処理と並列に実行され
る。図示の実施例では、命令は、通常は、取出、復号、
ディスパッチ、実行、完了およびライトバックの６ステ
ージで処理される。

【００４２】取出ステージの間に、シーケンシャル・フ
ェッチャ２は、命令キャッシュ１４内の１つまたは複数
のメモリ・アドレスから１つまたは複数の命令を選択的
に取り出す。取り出された命令のそれぞれは、シーケン
シャル・フェッチャ２によって一意の命令識別子（Ｉ
Ｄ）を関連付けられることが好ましい。

【００４３】その後、復号ステージの間に、ＢＰＵ２０
が、順次命令と分岐命令を区別するために、シーケンシ
ャル・フェッチャ２によって転送された命令を部分的に
復号する。さらに、命令待ち行列４内の実装依存の個数
の順次命令が、ディスパッチ・ユニット６によって並列
に復号される。

【００４４】ディスパッチ・ステージでは、ディスパッ
チ・ユニット６が、まずディスパッチされる命令と結果
のために固定小数点リネーム・バッファ３４または浮動
小数点リネーム・バッファ３８内の項目を予約し、ディ
スパッチされる命令ごとにリオーダ・バッファ９内の１
項目を予約した後に、プログラム順で４つまでの復号さ
れた命令をＢＰＵ２０、ＦＸＵＡ２２、ＦＸＵＢ２４、
ＣＦＸＵ２６、ＬＳＵ２８またはＦＰＵ３０のうちの適
当な実行ユニットに選択的にディスパッチする。ディス
パッチ・ステージの間に、ディスパッチされる命令のオ
ペランドも、選択された実行ユニットに供給される。た
とえば、ＦＰＵ３０は、浮動小数点レジスタ（ＦＰＲ）
３６または浮動小数点リネーム・バッファ３８から命令
オペランドを取り出すことができる。その一方で、ＦＸ
ＵＡ２２、ＦＸＵＢ２４およびＣＦＸＵ２６は、汎用レ
ジスタ（ＧＰＲ）３２、固定小数点リネーム・バッファ
３４またはキャリ・ビット・レジスタ４２から命令オペ
ランドを取り出すことができる。ＣＦＸＵ２６は、ＭＦ
ＳＰＲ（move from SPR）命令の受取に応答して、専用
レジスタ（ＳＰＲ）４０から命令オペランドを得ること
もできる。ＬＳＵ２８は、ディスパッチ・ユニット６か
らのＳＴＯＲＥ命令の受取に応答して、ＧＰＲ３２およ
びＦＰＲ３６のうちの選択された１つからデータを取り
出し、ディスパッチ・ユニット６からのＬＯＡＤ命令の
受取に応答して、データ・キャッシュ１６にデータ・オ
ペランドを要求する。ＬＳＵ２８が要求するＬＯＡＤオ
ペランドがデータ・キャッシュ１６内に常駐していない
場合には、要求されたデータは、ＢＩＵ１２およびシス
テム・バス１１を介してメモリ３９（または他の外部記
憶装置）から取り出される。

【００４５】実行ステージでは、ＢＰＵ２０、ＦＸＵＡ
２２、ＦＸＵＢ２４、ＣＦＸＵ２６、ＬＳＵ２８または
ＦＰＵ３０が、オペランドが使用可能になった時に、そ
れぞれにディスパッチされた命令をそれぞれの都合に合
わせて実行し、これによって、命令をプログラム順に対
してアウトオブオーダーに実行できるようになってい
る。ほとんどの命令の実行結果は、シーケンサ・ユニッ
ト１８によって各命令に割り当てられた固定小数点リネ
ーム・バッファ３４または浮動小数点リネーム・バッフ
ァ３８内の項目に格納される。さらに、ＣＦＸＵ２６
は、ＭＴＳＰＲ（move to SPR）命令の実行結果を、プ
ロセッサ１０内のＳＰＲ４０または他のＳＰＲに格納す
る。

【００４６】完了ステージでは、命令の実行が終了し、
先行する命令が完了したか同一サイクル中に完了する時
に、完了ユニット８が、命令が完了したことを示す。そ
の後、ライトバック・ステージの間に、完了ユニット８
は、固定小数点リネーム・バッファ３４からＧＰＲ３２
へまたは浮動小数点リネーム・バッファ３８からＦＰＲ
３６へのデータのコピーを指示する。プロセッサ１０
が、命令のライトバックに応答してアーキテクチャ的状
態を更新するのは、このライトバック・ステージの間で
ある。プロセッサ１０は、プログラム順に従って命令の
それぞれのライトバック・ステージを処理し、有利なこ
とに、命令の完了ステージとライトバック・ステージを
指定された情況で組み合わせる。図示の実施例では、各
命令は、命令処理のステージのそれぞれの完了に１機械
サイクルを必要とする。しかし、複合固定小数点命令な
どのいくつかの命令は、複数のサイクルを必要とする可
能性がある。したがって、先行する命令の完了に必要な
時間の変動に応答して、特定の命令の実行ステージと完
了ステージの間で遅延の変動が発生する可能性がある。

【００４７】さらに図１を参照すると、前に説明したプ
ロセッサ１０の動作を、パフォーマンス・モニタ５０を
使用して監視することができる。パフォーマンス・モニ
タ５０は、図示の実施例では、命令実行資源および記憶
域制御の利用を記述した詳細情報を提供することのでき
るソフトウェア・アクセス可能な機構である。図１には
図示されていないが、パフォーマンス・モニタ５０は、
プロセッサ１０の動作のすべての態様の監視を可能にす
るために、プロセッサ１０内の機能ユニットのそれぞれ
に結合される。このプロセッサ１０の動作の態様には、
イベントの間の関係の再構築、誤ったトリガの識別、性
能ボトルネックの識別、パイプライン停止の監視、遊休
サイクルの監視、ディスパッチ効率の判定、分岐効率の
判定、位置合せされていないデータ・アクセスの性能ペ
ナルティの判定、シリアライゼーション命令の実行の頻
度の識別、禁止された割込みの識別および性能効率の判
定が含まれる。

【００４８】図４および図８を参照すると、プロセッサ
１０の特徴は、パフォーマンス・モニタ５０である。パ
フォーマンス・モニタ５０は、ＰｏｗｅｒＰＣの命令実
行および記憶域制御の利用に関するかなりの粒度を有す
る詳細情報を提供する目的の、ソフトウェア・アクセス
可能な機構である。一般に、パフォーマンス・モニタ５
０には、実装依存の個数（たとえば２個ないし８個）
の、プロセッサ／記憶域関連のイベントのカウントに使
用されるカウンタ５１（たとえばＰＭＣ１ないしＰＭＣ
８）が含まれる。パフォーマンス・モニタ５０には、さ
らに、カウンタＰＭＣｎの機能を確立するモニタ・モー
ド制御レジスタ（ＭＭＣＲｎ）が含まれ、各ＭＭＣＲ
は、通常はある個数のカウンタを制御する。カウンタＰ
ＭＣｎおよびレジスタＭＭＣＲｎは、通常は、プロセッ
サ１０（たとえばＰｏｗｅｒＰＣ）に物理的に常駐する
専用レジスタである。これらの専用レジスタは、ｍｆｓ
ｐｒ（move from special purpose register）命令およ
びｍｔｓｐｒ（move to special purpose register）命
令を介して読書きのためにアクセスすることができ、書
込動作は、特権状態またはスーパーバイザ状態で許可さ
れ、読取は、専用レジスタの読取によってそのレジスタ
の内容が変更されないので、問題状態で許可される。異
なる実施例では、これらのレジスタは、Ｉ／Ｏ空間のア
ドレスなどの他の手段によってアクセス可能とすること
ができる。ＭＭＣＲｎレジスタは、イベント／信号選択
の記録／カウントを可能にするビット・フィールドに区
分される。イベントの許容可能な組み合わせの選択によ
って、複数のカウンタが同時に動作する。

【００４９】ＭＭＣＲｎレジスタには、カウンタ・イネ
ーブル・コントロール、カウンタ・ネガティブ割込みコ
ントロール、カウンタ・イベント選択、カウンタ・フリ
ーズ・コントロールなどのコントロールが、実装依存の
個数の、カウントのために選択できるイベントと共に含
まれる。これより大きいまたは小さいカウンタおよびレ
ジスタを使用して、特定のプロセッサおよびバス・アー
キテクチャに対応することができ、その結果、異なる個
数のＭＭＣＲｎおよびＰＭＣｎ用の専用レジスタを、本
発明の趣旨および範囲から逸脱せずに使用することがで
きる。

【００５０】パフォーマンス・モニタ５０は、タイム・
ベース機構５２と共に設けられ、タイム・ベース機構５
２には、計算機の状態を保管するための正確な時点を指
定するカウンタが含まれる。タイム・ベース機構５２に
は、通常はシステム・バス・クロックに基づく周波数を
有し、同期化されたタイム・ベースを提供するために複
数のプロセッサ１０を含むスーパースカラ・プロセッサ
・システムの必須の特徴であるクロックが含まれる。タ
イム・ベース・クロック周波数は、システム・バス・ク
ロックまたは、システム・バス・クロックのなんらかの
分数、たとえば１／４の周波数で供給される。

【００５１】タイム・ベース機構５２に含まれる６４ビ
ット・カウンタ内の所定のビットが、監視されるビット
の反転の間の時間の増分を制御できるように、監視のた
めに選択される。タイム・ベース機構５２の同期化によ
って、マルチプロセッサ・システム内の全プロセッサ
が、同期して動作を開始できるようになる。そのような
同期化を実行するための方法の例は、本発明と同一の譲
受人に譲渡され、参照によって本明細書に組み込まれる
関連米国特許出願通し番号第０８／６７５４２７号明細
書に記載されている。

【００５２】タイム・ベース機構５２は、さらに、マル
チプロセッサ・システムの各プロセッサ上で同時に発生
するイベントを追跡する方法を提供する。タイム・ベー
ス機構５２は、プロセッサ同期化のための単純な方法を
提供するので、マルチプロセッサ・システムのプロセッ
サのすべてが、選択された単一のシステム全域にわたる
イベントを同期化された形で検出し、これに反応する。
任意のビットまたはビットのグループから選択されたビ
ットの遷移が、複数のプロセッサ間の状態の同時カウン
トに使用され、ビットが反転した時またはイベントがカ
ウントされた回数だけ発生した時に割込み信号を発生す
ることができる。動作中には、所定のビットが反転した
時に、タイム・ベース機構５２からパフォーマンス・モ
ニタ５０に通知信号が送られる。パフォーマンス・モニ
タ５０は、計算機状態値を専用レジスタに保管する。異
なるシナリオでは、パフォーマンス・モニタ５０は、ネ
ガティブ・カウンタ（ビット０がオン）状態によって信
号が生成される「パフォーマンス・モニタ」割込みを使
用する。オペランドおよびアドレス・データを含む状態
情報を提示する処置は、プロセッサのうちの１つが割込
み処理を禁止されている場合には遅延することができ
る。割込みマスクに起因するデータの消失がないことを
保証するために、割込み状態を示す信号が生成される時
に、プロセッサは、実行中の「１」命令の命令およびオ
ペランド（存在する場合）の実効アドレスを捕捉し、割
込み解決論理５７に割込みを提示し、割込み解決論理５
７は、さまざまな割込み処理ルーチン７６、７７および
７９を使用する。これらのアドレスは、システム全域に
わたる信号生成の時のこの目的のために設計されたレジ
スタであるＳＤＡＲ（Saved Data Address）およびＳＩ
ＡＲ（Saved InstructionAddress）に保管される。さま
ざまな実行ユニットの状態も保管される。割込み信号が
生成された時点での、このさまざまな実行ユニットの状
態は、ＳＳＲ（saved state register）で提供される。
このＳＳＲは、割込みレジスタか、ソフトウェア的にア
クセス可能なＳＰＲとすることができる。したがって、
割込みが実際にサービスされる時には、これらのレジス
タの内容が、信号発生の時点でプロセッサ内で現在実行
中である現行命令に関する情報を提供する。パフォーマ
ンス・モニタ５０が、「サンプル・データ」を記録しな
ければならないことを示す通知をタイム・ベース機構５
２から受け取った時には、割込み信号が、ＢＰＵ２０に
出力される。それと同時に、サンプル・データ（計算機
状態データ）が、レジスタまたはＩ／Ｏ空間内のアドレ
スとして適当に提供されるＳＩＡＲ、ＳＤＡＲおよびＳ
ＳＲを含むＳＰＲ４０に置かれる。フラグを使用して、
ＭＭＣＲｎ内で定義された選択されたビット遷移に従う
割込み信号生成を示すことができる。もちろん、タイム
・ベース機構５２と選択されたビットの実際の実装は、
システムおよびプロセッサの実装の関数である。図５に
示されたものなどのブロック図は、パフォーマンス・モ
ニタリングを含むスーパースカラ・プロセッサ・システ
ム動作の本発明による全体処理の流れを示すものであ
る。この処理は、ブロック６１の、スーパースカラ・プ
ロセッサ・システム内の命令の処理から始まる。スーパ
ースカラ・プロセッサ・システム動作中に、パフォーマ
ンス・モニタリングは、モニタ・モード制御レジスタに
よるパフォーマンス・モニタ・カウンタの構成を介して
ブロック６３を介して選択された形で実施され、パフォ
ーマンス・モニタリング・データは、ブロック６５を介
して収集される。

【００５３】パフォーマンス・モニタ・カウントの値を
調節することによって、すなわち、あるイベントの所定
の回数の発生によって例外の信号が生成されるようにカ
ウンタの値を十分に高く設定することによって、システ
ム性能のプロファイルを得ることができる。さらに、こ
の開示の目的のために、パフォーマンス・モニタリング
割込みを、処理のうちの選択可能な点で発生させること
ができる。下で詳細に説明するように、所定の回数のイ
ベントは、停止点を選択するために適当に使用される。
たとえば、２つの命令の完了の後にカウンタが負になる
ようにすることによって、２つの命令の後に終了するよ
うにカウントをプログラミングできる。さらに、この開
示の目的のために、モニタリングが発生する時間は、既
知である。したがって、収集されたデータは、モニタリ
ングが実行された日、時、分などの数に関するコンテキ
ストを有する。下で説明するように、選択されたパフォ
ーマンス・モニタリングには、イベントの間の関係の再
構築、誤ったトリガの識別、性能ボトルネックの識別、
停止の監視、遊休の監視、ディスパッチ・ユニットの動
作の効率の判定、分岐ユニット動作の効率の判定、位置
合せされていないデータ・アクセスの性能ペナルティの
判定、シリアライゼーション命令の実行の頻度の識別、
禁止された割込みの識別および、効率を判定するためLi
ttleの法則の適用が含まれる。

【００５４】ブロック６７を介して、選択されたパフォ
ーマンス・モニタリング・ルーチンが完了し、収集した
データを分析して、システム性能強化の潜在的な領域を
識別する。ヒストグラムなどのプロファイリング機構
を、収集したデータを用いて構築して、性能を改善でき
るソフトウェアまたはハードウェアの具体的な領域を識
別する。さらに、停止の数、遊休の数など、監視された
イベントのうちで時間に敏感なイベントについて、経過
サイクルの既知の数に対してカウント数データを収集し
て、そのデータが、サンプリング期間に関するコンテキ
ストを有するようにする。収集されたデータの分析は、
「aixtrace」やグラフィカル・パフォーマンス・ビジュ
アライゼーション・ツール「pv」（どちらもIBM Corpor
ation社から入手可能）などのツールを使用することに
よって容易になることを諒解されたい。図６に、ＰＭＣ
カウンタ、たとえばＰＭＣ１およびＰＭＣ２などの動作
の制御に適したＭＭＣＲ０の構成の１つを表す例を示
す。この例からわかるように、ＭＭＣＲ０は、複数のビ
ット・フィールドに区分されており、各フィールドの設
定によって、カウントするイベントの選択、パフォーマ
ンス・モニタ割込みのイネーブル、カウントをイネーブ
ルする条件の指定、閾値（Ｘ）の設定を行う。

【００５５】閾値（Ｘ）は、変数であると同時にソフト
ウェア選択可能であり、その目的は、減少する閾値を超
えるアクセスのカウントを累算することによって、設計
者が衝突の明瞭な情況を得られるように、特定のデータ
の特徴を表せるようにすることである。閾値（Ｘ）を超
えたとみなされるのは、データ命令が完了する前にデク
リメンタが０に達した時である。逆に、デクリメンタが
０に達する前にデータ命令が完了した場合には、閾値を
超えたとはみなされない。もちろん、実行されるデータ
命令に応じて、「完了」の意味は異なる。たとえば、ｌ
ｏａｄ命令の場合、「完了」は、命令に関連するデータ
を受け取ったことを示し、「ｓｔｏｒｅ」命令の場合、
「完了」は、データが成功裡に書き込まれたことを意味
する。ＰＭＣ１などのユーザ読取可能なカウンタが、閾
値を超えるたびに適当にインクリメントされる。ユーザ
は、パフォーマンス・モニタ割込みの信号生成の前に閾
値を超えた回数を判定することができる。たとえば、ユ
ーザは、カウンタの初期値を設定して、指定された閾値
を超える１００回目のデータ・ミスの際に割込みを引き
起こすことができる。適当な値を用いることによって、
パフォーマンス・モニタ機構は、システム性能問題の識
別での使用に簡単に適するようになる。

【００５６】図６を参照すると、この例では、ＭＭＣＲ
０のビット０ないし４とビット１８によって、カウント
がイネーブルされるシナリオが決定される。たとえば、
ビット０は、ＦＣ（freeze count、カウント禁止）ビッ
トである。ハイの論理レベル（ＦＣ＝１）の時には、Ｐ
ＭＣｎカウンタの値は、ハードウェア・イベントによっ
て変更されない、すなわち、カウントが禁止される。ビ
ット０がロウの論理レベル（ＦＣ＝０）の時には、ＰＭ
Ｃｎの値が、選択されたハードウェア・イベントによっ
て変更される。ビット１ないし４は、カウントが禁止さ
れる他の具体的な条件を示す。

【００５７】たとえば、ビット１は、ＦＣＳ（freeze c
ounting while in a supervisor state、スーパーバイ
ザ状態中はカウントを禁止）ビットであり、ビット２
は、ＦＣＰ（freeze counting while in a problem sta
te、問題状態中はカウントを禁止）ビットであり、ビッ
ト３は、ＦＣＰＭ１（freeze counting while PM=1、Ｐ
Ｍ＝１の間はカウントを禁止）ビットであり、ビット４
は、ＦＣＰＭ０（freezecounting while PM=0、ＰＭ＝
０の間はカウントを禁止）ビットである。ＰＭは、計算
機状態レジスタ（ＭＳＲ）（図１のＳＰＲ４０）のビッ
ト２９のパフォーマンス・モニタ・マークド・ビットを
表す。ビット１とビット２について、スーパーバイザ状
態または問題状態は、ＭＳＲのＰＲ（特権）ビットの論
理レベルによって示される。これらのビットによるカウ
ント禁止のための状態は次の通りである。ビット１の場
合、ＦＣＳ＝１かつＰＲ＝０、ビット２の場合、ＦＣＰ
＝１かつＰＲ＝１、ビット３の場合、ＦＣＰＭ１＝１か
つＰＭ＝１、ビット４の場合、ＦＣＰＭ０＝１かつＰＭ
＝０。これらのビットによるカウント許可のための状態
は次の通りである。ビット１の場合、ＦＣＳ＝１かつＰ
Ｒ＝１、ビット２の場合、ＦＣＰ＝１かつＰＲ＝０、ビ
ット３の場合、ＦＣＰＭ１＝１かつＰＭ＝０、ビット４
の場合、ＦＣＰＭ０＝１かつＰＭ＝１。ビット５、１６
および１７は、ＰＭＣｎによってトリガされる割込み信
号の制御に使用される。ビット６ないし９は、時間また
はイベント・ベースの遷移の制御に使用される。閾値
（Ｘ）は、ビット１０ないし１５によって可変式に設定
される。ビット１８は、ロウの時にカウントがイネーブ
ルされ、ハイの時には、ＰＭＣ１のビット０がハイまた
はパフォーマンス・モニタリング例外の信号が生成され
るまでカウントがディスエーブルされる形で、ＰＭＣｎ
（ｎ＞１）のカウント・イネーブルを制御する。ビット
１９ないし２５は、ＰＭＣ１のイベント選択すなわち、
カウントされる信号の選択に使用される。

【００５８】図７は、本発明の実施例によるＭＭＣＲ１
の構成を示す図である。ビット０ないし４は、ＰＭＣ３
のイベント選択を適当に制御し、ビット５ないし９は、
ＰＭＣ４のイベント選択を制御する。同様に、ビット１
０ないし１４は、ＰＭＣ５のイベント選択を制御し、ビ
ット１５ないし１９は、ＰＭＣ６のイベント選択を制御
し、ビット２０ないし２４は、ＰＭＣ７のイベント選択
を制御し、ビット２５ないし２８は、ＰＭＣ８のイベン
ト選択を制御する。

【００５９】ＭＭＣＲ０のビット１９ないし２５および
ビット２６ないし３１やＭＭＣＲ１のビット０ないし２
８などのカウンタ選択フィールドは、具体的な実施態様
によって提供される選択可能なイベントのすべての領域
を指定するのに必要な数のビットを有することが好まし
い。

【００６０】性能分析のためにデータを捕捉するために
は、少なくとも１つのカウンタが必要である。カウンタ
が多ければ、それだけ高速かつ高精度の分析がもたらさ
れる。シナリオが厳密に繰り返し可能である場合には、
異なる項目を選択した状態で同一のシナリオを実行する
ことができる。シナリオが厳密に繰り返し可能ではない
場合には、統計データを収集するために同一の項目を選
択して複数回同一のシナリオを実行することができる。
シナリオの開始からの時間は、システム・タイム・サー
ビスを介して入手可能であり、その結果、異なるサンプ
ルと異なるイベントの相関に時間間隔を使用できるよう
になると仮定する。

【００６１】パフォーマンス・モニタリングの詳しい説
明については、参照によって本明細書に組み込まれる
「Performance Monitor, PowerPC 604 RISC Microproce
ssor User's Manual」ＩＢＭ１９９４年の第９章、第
９−１ページから９−１１ページを参照されたい。この
資料には、図６および図７に示されたレジスタなど、さ
まざまなカウンタＰＭＣｎに監視するイベントとその方
法を通知するＭＭＣＲｎレジスタ内の記憶域に関するコ
ード点を示す２つの表がある。次に図８を参照すると、
本発明を実施するための実施例が示されている。図８に
は、２つのＭＭＣＲｎレジスタであるカウンタ５１を図
示され、ＳＩＡＲレジスタおよびＳＤＡＲレジスタであ
るＳＰＲ４０、ＭＭＣＲｎレジスタのさまざまなビット
によって制御されるマルチプレクサ７２ないし７３によ
って供給される関連する加算器およびカウンタ制御論理
を有するＰＭＣ１ないしＰＭＣｎ（図ではカウンタ１な
いしカウンタＮと表記）を有するパフォーマンス・モニ
タ５０が示されている。マルチプレクサ７２ないし７３
は、スレッショルダ７１、タイム・ベース機構５２から
イベントを受け取り、マイクロプロセッサ内のさまざま
な実行ユニットおよび他のユニットから発する信号であ
る他のイベントを受け取る。パフォーマンス・モニタ５
０のこれらのさまざまな回路要素のすべてが、本明細書
および上で示した関連特許出願書に記載されており、し
たがって、これらの要素の動作をさらに詳細に説明する
ことはしない。

【００６２】本発明は、プログラムが非ベキ等演算の順
序付きリストとして指定され、したがって、フォン・ノ
イマン型プロセッサによって実行される命令ストリーム
がプログラム順で実行されるという要件を中心にすえて
いる。この制約は、おそらくはＣＰＵ内の作業が実際に
行われる形に影響しないが、命令が完了される形には実
際に影響する。

【００６３】一般に、ソフトウェア・システムでは、単
位ソフトウェア動作（命令）の実行が特定の順序で実行
される。もちろん例外が存在するが、全般的に、ソフト
ウェア・システムは、順序付きソフトウェア動作のスレ
ッドとして実施される傾向を有する。一般に、これらの
動作の効果が、プログラムによって指定される順序から
外れた状態でアーキテクチャ的に可視になることは許容
されない。

【００６４】たとえば、ソフトウェア・システムを介し
て項目をカウントする時には、現在のカウント値を取得
し、その値を更新し、正しい記憶位置にあるカウント値
を置換する必要がある。これらの動作をアウトオブオー
ダーで実行することは、このようなソフトウェア・シス
テムの所期の目的に役立たない。

【００６５】しかし、複数の関連しないソフトウェア機
能を達成しようとする場合には、それらの機能を含む基
本的なソフトウェア動作を、機能の境界にまたがって厳
密な順序で実行する必要がない（すなわち、独立な機能
の構成要素動作の順序をリオーダリングのために修正す
ることができる）ことがしばしばである。スーパースカ
ラ・プロセッサの重要な目的および機能は、関連のない
実行の絡み合ったスレッドをハードウェアで識別するこ
とである。

【００６６】一部のＣＰＵ編成は、ソフトウェア動作の
総合的な見掛けの実行順序が維持されることを保証する
ことによって、基礎ステップの実行のリオーダリングの
機会を利用できるように設計されている。そのようなＣ
ＰＵ編成の長所は、メモリからの値の取得に起因する遅
延がしばしば隠蔽され、したがって、ＣＰＵ性能が改善
されることである。

【００６７】しかし、この性能の長所が、測定における
短所を提示する。すなわち、基礎ソフトウェア動作のリ
オーダリングは、実際に必要になるより十分に前にメモ
リ値にアクセスできるようにすることによって、長いメ
モリ遅延のコストを削減する。したがって、メモリ・ア
クセスの完了に必要な時間を単純に測定するだけでは不
十分であり、これを行うとペナルティの過大評価がもた
らされる。

【００６８】投機実行をサポートするほとんどのパイプ
ライン・スーパースカラ計算機は、何らかのタイプのパ
イプライン制御シーケンサ（「ＰＣＳ」）を有する。命
令には、通常、ＰＣＳまたは命令ディスパッチャ構成要
素によって、何らかのタイプのタグまたは識別番号が与
えられる。命令は、パイプラインを通過する際に、この
割り当てられたタグによって参照される。これらのタグ
は、通常は短く、１時にパイプライン内に存在すること
のできる命令の最大個数を反映するのに十分なビットだ
けを有する。参照によって本明細書に組み込まれる米国
特許出願通し番号第０８／８８８７９８号明細書に、ソ
フトウェア分析のためにプロセッサの状態を捕捉するた
めのパイプライン・フロー・テーブル・アプローチが開
示されている。本発明では、必要な情報の捕捉を提供す
るためのもう１つのアプローチを定義する。

【００６９】次に図２を参照すると、各サイクルに、プ
ロセッサ１０内の各ユニットは、結果または理由コード
のいずれか２０１と標識（Ｉ）２０２を作り、これら
は、ユニットのそれぞれに含まれるレジスタ２００に格
納され、最終的に完了ユニット８内のレジスタであるリ
オーダ・バッファ９に収集される。図９を参照すると、
本発明による流れ図が示されている。ステップ８０１で
は、ユニットが前のユニットから命令（作業の単位）を
受け取ったかどうかを判定する。理由コードは必ず受け
取られる。作業を受け取った時には、空白コードが受け
取られる。ステップ８０２で、現在のユニットが、命令
に基づく作業を試みる。ステップ８０３で、ユニットが
結果を作ることができるかどうかを判定する。そうであ
る場合には、ステップ８０４でその結果を転送し、この
処理はステップ８０１に戻って、次のサイクルで次の作
業の単位を受け取る。ステップ８０３で、ユニットが結
果を作ることができない場合、この処理はステップ８０
５に進んで、ユニットが遊休状態であるかどうかを判定
する。ユニットが遊休状態である場合には、この処理は
ステップ８０６に進んで、前のユニットから受け取った
理由コードを転送する。その後、この処理は、次のサイ
クルのためにステップ８０１に戻る。

【００７０】ステップ８０５で、ユニットが遊休状態で
ない場合には、この処理はステップ８０７に進んで、ユ
ニットが結果を作れない理由を説明し、この説明を理由
コードとして符号化し、ステップ８０８で、この理由コ
ードを次のユニットに転送する。その後、この処理はス
テップ８０３に戻る。

【００７１】ステップ８０１で、前のステージから作業
を受け取っていない場合、この処理はステップ８０２を
スキップする。

【００７２】次の例で、図９に示された処理をさらに説
明する。この例では、３つのステージすなわち、命令を
ディスパッチするためのディスパッチ・ユニット、ディ
スパッチ・ユニットから並列にディスパッチされた命令
を実行するための第１および第２の実行ユニット（たと
えば固定小数点実行ユニットと浮動小数点実行ユニッ
ト）、および完了ユニットを検討する。ディスパッチ・
ユニットは、第１ステージとみなされ、第１および第２
の実行ユニットは、第２ステージにあるとみなされ、完
了ユニットは、第３ステージにあるとみなされる。図９
に示された処理を、第２ステージの第１および第２の実
行ユニットに関して説明する。ディスパッチ・ユニット
が停止し、命令をディスパッチできない場合、第１実行
ユニットは、ステップ８０１で作業を受け取らない。処
理はステップ８０３に進んで、第１実行ユニットが結果
を作ることができるか否かを判定する。この例では、第
１実行ユニットは、複数サイクルを必要とする除算演算
を実行している。この例では、ステップ８０３で、第１
実行ユニットが除算演算を完了しており、結果を作るこ
とができる。したがって、この第２ステージ・ユニット
は、ステップ８０４に進んで、除算演算の結果を完了ユ
ニットに転送する。

【００７３】第２実行ユニットは、ステップ８０３で、
やはり複数サイクルを必要とする動作を実行している
が、まだ結果を作ることができない（ディスパッチ・ユ
ニットは停止しているので、第２実行ユニットも、それ
を示す理由コードをディスパッチ・ユニットから受け取
っていることに留意されたい）。

【００７４】第２実行ユニットは、ステップ８０５に進
み、第２実行ユニットが遊休状態であるか否かの判定が
行われる。この場合、第２実行ユニットは、上で述べた
ように動作を実行しているので、遊休状態ではない。し
たがって、処理はステップ８０７に進み、第２実行ユニ
ットが結果を作ることができない理由を符号化した理由
コードが定式化される。この理由コードは、その後、ス
テップ８０８で完了ユニットに転送される。この処理
は、その後、次のサイクルにステップ８０３に戻って、
第２実行ユニットが結果を作ることができるか否かを判
定する。第２実行ユニットは、実行中の動作から結果を
作ることができるようになった後に、ステップ８０４で
その結果を転送する。

【００７５】この例で、第２実行ユニットが、ステップ
８０３で動作を実行していない場合には、ステップ８０
５で、第２実行ユニットが遊休状態であるかどうかが判
定され、この処理はステップ８０６に進んで、ディスパ
ッチ・ユニットから受け取った理由コードを転送する。

【００７６】この例で、ディスパッチ・ユニットが命令
（作業）をディスパッチできる場合には、ステップ８０
２で、命令を受け取った実行ユニットのすべてが、その
命令の実行を試みる。ステップ８０３で、実行ユニット
が結果を作ることができる場合には、この結果がステッ
プ８０４で転送される。実行ユニットが結果を作ること
ができない場合には、処理はステップ８０５に進む。実
行ユニットがまだ命令に対して動作中であり、したがっ
て遊休状態でない場合には、この処理はステップ８０７
に進み、実行ユニットは、そのクロック・サイクルに結
果を作ることができない理由（この例では、まだ命令に
対して動作中である）の理由コードを定式化し、ステッ
プ８０８でその理由コードを転送する。処理はステップ
８０３に戻って、実行ユニットが次のクロック・サイク
ルに結果を作ることができるか否かをもう一度判定す
る。

【００７７】図３を参照すると、取出しステージ３０
２、復号ステージ３０３、実行ステージ３０４および完
了ステージ３０５で、図２に示された結果または理由コ
ードが生成され、後続ユニットに渡される、パイプライ
ン式プロセッサを簡略化した図が示されている。理由コ
ードが生成される場合、後続ユニットは、操作すべき結
果を前のユニットから受け取らないので、結果を生成す
ることができない。これらの後続ユニットは、理由が存
在する場合でもそれ自体の理由コードを生成せず、単に
前のユニットから受け取った理由コードを後続ユニット
に渡す。完了ステージ３０５では、１つまたは複数のパ
フォーマンス・モニタ・カウンタ（図８参照）を実施し
て、特定の理由コードを受け取った回数を数えることが
できる。これは、完了ステージ３０５で観察された理由
と、レジスタに格納された所定の理由とを比較する、イ
ンデクシング可能なカウンタまたは比較器を用いて行う
ことができる。さらに、パフォーマンス・モニタのＰＭ
Ｉ機能を使用して、ある回数だけ理由が発生した時また
は特定の理由が発生した時に割込みを生成することがで
き、これによって、ＳＩＡＲ８０またはＳＤＡＲ８２に
プロセッサの状態を格納することができる。

【００７８】その結果、取出しステージ３０２、復号ス
テージ３０３、実行ステージ３０４および完了ステージ
３０５のうちの２つ以上をカウントし、停止条件の処理
後の比較を行うのではなく、完了ステージ３０５でのカ
ウントだけを行う必要があり、これによって、取出しス
テージ３０２、復号ステージ３０３、実行ステージ３０
４および完了ステージ３０５内で停止が発生した条件
が、パフォーマンス・モニタ出力の後処理の必要を減ら
しながら提供される。本発明とその長所を詳細に説明し
てきたが、請求項によって定義される本発明の趣旨およ
び範囲から逸脱せずに、さまざまな変更、置換および代
替を行うことができることを理解されたい。

【００７９】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００８０】（１）命令を処理するために動作可能な第
１および第２のシーケンシャル・ステージと、上記第１
ステージで上記命令の処理を試みるために動作可能な回
路と、上記第１ステージが上記命令を処理できない場合
に、上記第１ステージが上記命令を処理できない理由を
示す第１理由コードを上記第１ステージで生成するため
に動作可能な回路と、上記第１理由コードを上記第１ス
テージから上記第２ステージへ転送するために動作可能
な回路と、上記第２ステージの動作状態を示す第２理由
コードを上記第２ステージで作成するために動作可能な
回路と、上記第２ステージによって、上記第１理由コー
ドまたは上記第２理由コードのいずれかを第３ステージ
へ転送するために動作可能な回路とを含む回路。（２）さらに、上記第３ステージで受け取る上記理由コ
ードの機能としてカウント機能を実行するために動作可
能なパフォーマンス・モニタ・カウンタを含む、上記
（１）に記載の回路。（３）上記カウント機能が、上記理由コードが所定の理
由コードと一致する場合にカウンタを増分する、上記
（２）に記載の回路。（４）上記第２ステージが結果を作ることができず、遊
休状態である時に、上記第２ステージが、上記第１理由
コードを上記第３ステージに転送する、上記（１）に記
載の回路。（５）さらに、上記第２ステージに上記第２理由コード
を作らせる上記命令を識別するための回路を含む、上記
（１）に記載の回路。（６）上記第２ステージで上記命令の処理を試みるため
に動作可能な回路と、上記第２ステージが結果を作るこ
とができない時に、上記第２理由コードを第３ステージ
に転送するために動作可能な回路とをさらに含む、上記
（１）に記載の回路。（７）第１ステージで命令の処理を試みるステップと、
上記第１ステージが上記命令を処理できない場合に、上
記第１ステージが上記命令を処理できない理由を示す第
１理由コードを上記第１ステージで生成するステップ
と、上記第１ステージから第２ステージへ上記第１理由
コードを転送するステップと、上記第２ステージの後の
第２ステージへ上記第２ステージによって受け取られた
上記第１理由コードを転送するか、上記第２ステージが
結果を作ることができない理由の第２理由コードを作成
し、上記第２理由コードを上記第３ステージへ転送する
かのいずれかを行うステップとを含む方法。（８）さらに、理由コードを引き起こした上記命令を識
別し、出力するステップを含む、上記（７）の方法。（９）さらに、上記第３ステージで受け取られた上記理
由コードの機能としてカウント機能を実行するステップ
を含む、上記（７）に記載の方法。（１０）上記第２ステージが、遊休状態であり、結果を
作ることができない時に、上記第２ステージが、上記第
１理由コードを上記第３ステージへ転送する、上記
（７）に記載の方法。（１１）さらに、上記第２ステージが上記第１理由コー
ドを受け取った時であっても、上記第２ステージが結果
を作り、上記結果を上記第３ステージに転送するステッ
プを含む、上記（７）の方法。（１２）命令を処理するために動作可能な第１、第２お
よび第３のシーケンシャル・ステージと、上記第１ステ
ージで上記命令の処理を試みるために動作可能な回路
と、上記第１ステージで上記命令の上記処理の第１結果
を作るか、上記第１ステージが上記命令を処理すること
ができない場合に、上記第１ステージが上記命令を処理
できない理由を示す第１理由コードを上記第１ステージ
で生成するかのいずれかのために動作可能な回路と、上
記第１結果または上記第１理由コードのいずれかを上記
第１ステージから上記第２ステージへ転送するために動
作可能な回路と、上記第１結果を受け取る時に、上記第
２ステージで上記命令の処理を試みるために動作可能な
回路と、上記第２ステージで上記命令の上記処理の第２
結果を作るか、上記第２ステージが上記命令を処理でき
ない場合に、上記第２ステージが上記命令を処理できな
い理由を示す第２理由コードを上記第２ステージで生成
するかのいずれかのために動作可能な回路と、上記第２
ステージが上記第１ステージから上記第１理由コードを
受け取り、上記第２ステージが遊休状態である場合に、
上記第１ステージから受け取った上記第１理由コードを
上記第２ステージの後の第３ステージへ転送するために
動作可能な回路と、上記第２ステージが上記第１結果を
処理できない場合に、上記第２ステージの後の上記第３
ステージへ上記第２理由コードを転送するために動作可
能な回路とを含むプロセッサ。（１３）上記第３ステージが、完了ステージである、上
記（１２）に記載のプロセッサ。

【図面の簡単な説明】

【図１】本発明のシステムおよび方法を有利に利用でき
るデータ処理システムを示す図である。

【図２】理由コードを実施するためのレジスタの構成を
示す図である。

【図３】本発明の実施例を実施する、簡略化されたパイ
プライン式プロセッサを示す図である。

【図４】本発明のパフォーマンス・モニタリング態様の
ブロック図である。

【図５】パフォーマンス・モニタリングを含む処理シス
テム動作の、本発明による全体処理フローのブロック図
である。

【図６】複数のカウンタを管理するのに使用される、モ
ニタ制御レジスタ（ＭＭＣＲ０）を示す図である。

【図７】複数のカウンタを管理するのに使用される、モ
ニタ制御レジスタ（ＭＭＣＲ１）を示す図である。

【図８】本発明に従って構成されたパフォーマンス・モ
ニタのブロック図である。

【図９】本発明に従う流れ図である。

【符号の説明】

２シーケンシャル・フェッチャ４命令待ち行列６ディスパッチ・ユニット８完了ユニット９リオーダ・バッファ１０プロセッサ１１システム・バス１２バス・インターフェース・ユニット（ＢＩＵ）１４命令キャッシュ１６データ・キャッシュ１８シーケンサ・ユニット２０分岐処理ユニット（ＢＰＵ）２２固定小数点ユニットＡ（ＦＸＵＡ）２４固定小数点ユニットＢ（ＦＸＵＢ）２６複合固定小数点ユニット（ＣＦＸＵ）２８ロード／ストア・ユニット（ＬＳＵ）３０浮動小数点ユニット（ＦＰＵ）５０パフォーマンス・モニタ５２タイム・ベース機構８０ＳＩＡＲ８２ＳＤＡＲ

───────────────────────────────────────────────────── フロントページの続き (72)発明者フランク・エリオット・レヴィンアメリカ合衆国78729 テキサス州オースチンチャペル・ダウン・ストリート 9406 (72)発明者ロイ・スチュアート・ムーアアメリカ合衆国78660 テキサス州フリューガーヴィルポイント・ラン・コーブ 702 (72)発明者チャールズ・フィリップ・ロスアメリカ合衆国78729 テキサス州オースチンティチェスター・コート 13305 (72)発明者エドワード・ヒュー・ウェルボンアメリカ合衆国78730 テキサス州オースチンターキー・クリーク・ドライブ 3637

Claims

【特許請求の範囲】

【請求項１】命令を処理するために動作可能な第１およ
び第２のシーケンシャル・ステージと、上記第１ステージで上記命令の処理を試みるために動作
可能な回路と、上記第１ステージが上記命令を処理できない場合に、上
記第１ステージが上記命令を処理できない理由を示す第
１理由コードを上記第１ステージで生成するために動作
可能な回路と、上記第１理由コードを上記第１ステージから上記第２ス
テージへ転送するために動作可能な回路と、上記第２ステージの動作状態を示す第２理由コードを上
記第２ステージで作成するために動作可能な回路と、上記第２ステージによって、上記第１理由コードまたは
上記第２理由コードのいずれかを第３ステージへ転送す
るために動作可能な回路とを含む回路。
【請求項２】さらに、上記第３ステージで受け取る上記
理由コードの機能としてカウント機能を実行するために
動作可能なパフォーマンス・モニタ・カウンタを含む、
請求項１に記載の回路。
【請求項３】上記カウント機能が、上記理由コードが所
定の理由コードと一致する場合にカウンタを増分する、
請求項２に記載の回路。
【請求項４】上記第２ステージが結果を作ることができ
ず、遊休状態である時に、上記第２ステージが、上記第
１理由コードを上記第３ステージに転送する、請求項１
に記載の回路。
【請求項５】さらに、上記第２ステージに上記第２理由
コードを作らせる上記命令を識別するための回路を含
む、請求項１に記載の回路。
【請求項６】上記第２ステージで上記命令の処理を試み
るために動作可能な回路と、上記第２ステージが結果を作ることができない時に、上
記第２理由コードを第３ステージに転送するために動作
可能な回路とをさらに含む、請求項１に記載の回路。
【請求項７】第１ステージで命令の処理を試みるステッ
プと、上記第１ステージが上記命令を処理できない場合に、上
記第１ステージが上記命令を処理できない理由を示す第
１理由コードを上記第１ステージで生成するステップ
と、上記第１ステージから第２ステージへ上記第１理由コー
ドを転送するステップと、上記第２ステージの後の第２ステージへ上記第２ステー
ジによって受け取られた上記第１理由コードを転送する
か、上記第２ステージが結果を作ることができない理由
の第２理由コードを作成し、上記第２理由コードを上記
第３ステージへ転送するかのいずれかを行うステップと
を含む方法。
【請求項８】さらに、理由コードを引き起こした上記命
令を識別し、出力するステップを含む、請求項７の方
法。
【請求項９】さらに、上記第３ステージで受け取られた
上記理由コードの機能としてカウント機能を実行するス
テップを含む、請求項７に記載の方法。
【請求項１０】上記第２ステージが、遊休状態であり、
結果を作ることができない時に、上記第２ステージが、
上記第１理由コードを上記第３ステージへ転送する、請
求項７に記載の方法。
【請求項１１】さらに、上記第２ステージが上記第１理
由コードを受け取った時であっても、上記第２ステージ
が結果を作り、上記結果を上記第３ステージに転送する
ステップを含む、請求項７の方法。
【請求項１２】命令を処理するために動作可能な第１、
第２および第３のシーケンシャル・ステージと、上記第１ステージで上記命令の処理を試みるために動作
可能な回路と、上記第１ステージで上記命令の上記処理の第１結果を作
るか、上記第１ステージが上記命令を処理することがで
きない場合に、上記第１ステージが上記命令を処理でき
ない理由を示す第１理由コードを上記第１ステージで生
成するかのいずれかのために動作可能な回路と、上記第１結果または上記第１理由コードのいずれかを上
記第１ステージから上記第２ステージへ転送するために
動作可能な回路と、上記第１結果を受け取る時に、上記第２ステージで上記
命令の処理を試みるために動作可能な回路と、上記第２ステージで上記命令の上記処理の第２結果を作
るか、上記第２ステージが上記命令を処理できない場合
に、上記第２ステージが上記命令を処理できない理由を
示す第２理由コードを上記第２ステージで生成するかの
いずれかのために動作可能な回路と、上記第２ステージが上記第１ステージから上記第１理由
コードを受け取り、上記第２ステージが遊休状態である
場合に、上記第１ステージから受け取った上記第１理由
コードを上記第２ステージの後の第３ステージへ転送す
るために動作可能な回路と、上記第２ステージが上記第１結果を処理できない場合
に、上記第２ステージの後の上記第３ステージへ上記第
２理由コードを転送するために動作可能な回路とを含む
プロセッサ。
【請求項１３】上記第３ステージが、完了ステージであ
る、請求項１２に記載のプロセッサ。
【請求項１４】上記第３ステージが、理由コードを累算
するための回路を含む、請求項１２に記載のプロセッ
サ。