(57)【要約】ホストプロセッサの内部状態を判断するための方法及び装置である。テストデータはサービスプロセッサ140の出力ポート152にロードされる。サービスプロセッサ140はホストプロセッサ10に記録される有効ビットをポーリングする。有効ビットはクリアな状態であるとの判断後、サービスプロセッサ140はテストデータをホストプロセッサに送信し、且つ有効ビットをセットする。ステートデータはテストデータに応答して生成される。ステートデータはホストプロセッサ10の出力ポート104に書き込まれる。サービスプロセッサ140はホストプロセッサ10の出力ポート104からデータを受信する。ホストプロセッサ10の状態を判断する演算はホストプロセッサ10の命令の実行を妨げることなく実行される。
2006514349.tif 000002
【特許請求の範囲】
【請求項１】
ホストプロセッサの状態を判断する方法であって、
前記ホストプロセッサに配置された第１入力レジスタに、第１有効ビットをその第１有効ビットがクリアな状態になるまでポーリングし（５０２）、
サービスプロセッサに配置された第１出力レジスタにテストデータをロードし（５０６）、
前記テストデータを前記第１出力レジスタから前記第１入力レジスタへ送信し（５０８）、
前記送信完了後に前記第１有効ビットをセットし（５１０）、かつ、
前記第１有効ビットのセットの検出に応答して前記テストデータを前記第１入力レジスタから読み出し（５１２）、
前記ロード、前記ポーリング、前記送信、前記セット、及び前記読み出しは、前記ホストプロセッサで実行される命令ストリームに割り込みを行わないものである、方法。
【請求項２】
前記テストデータに基づきホストプロセッサの状態を判断し、かつ、
前記サービスプロセッサへステートデータを出力し、前記ステートデータはホストプロセッサの状態を示すものであり、前記判断及び前記出力は、ホストプロセッサクロックに対し非同期的に実行される、請求項１記載の方法。
【請求項３】
前記出力は、
第２有効ビットを、前記第２有効ビットがクリアな状態になるまで第２出力レジスタにポーリングし（５５２）、
前記第２出力レジスタにステートデータをロードし（５５６）、
前記サービスプロセッサに配置された第２入力レジスタに、前記第２出力レジスタから前記ステートデータを送信し（５５８）かつ、
前記第２入力レジスタから前記ステートデータを出力する（５６２）、請求項２記載の方法。
【請求項４】
前記第１有効ビットは、前記テストデータの読み出しに応答してクリアな状態にされる、請求項３記載の方法。
【請求項５】
前記第２有効ビットは、前記第２入力レジスタのロードに続いてセットされる、請求項３記載の方法。
【請求項６】
ホストプロセッサ（１０）及びサービスプロセッサ（１４０）を有し、前記ホストプロセッサは第１入力レジスタ（１０２）を、サービスプロセッサは第１出力レジスタ（１５２）をそれぞれ備え、かつ、前記ホストプロセッサは第２出力レジスタ（１０４）を、サービスプロセッサは、第２入力レジスタ（１５４）をそれぞれ備え、
前記サービスプロセッサは、前記ホストプロセッサの前記状態を判断するために構成され、
前記判断では、
前記第１入力レジスタの第１有効ビットを前記第１有効ビットがクリアな状態になるまでのポーリング、
前記第１出力レジスタへのテストデータのロード、
前記第１出力レジスタから前記第１入力レジスタへの前記テストデータの送信、
前記送信完了後での前記第１有効ビットのセット、がなされ、
前記ホストプロセッサは、前記第１有効ビットに応答して、前記第１入力レジスタから前記テストデータを読み出すように構成されたものであり、かつ、
前記ロード、前記ポーリング、前記送信、前記セット、前記読み出しは、前記ホストプロセッサで実行する命令ストリームに割り込みを行わないものである、システム。
【請求項７】
前記ホストプロセッサは、更に、
前記テストデータに基づきホストプロセッサの状態を判断し、かつ、
前記サービスプロセッサにステートデータを出力するよう構成されたものであり、前記ステートデータは、ホストプロセッサの状態を示し、前記判断及び出力は、前記ホストプロセッサクロックに対し非同期的に実行される、請求項６記載のシステム。
【請求項８】
前記ホストプロセッサは、更に、
前記第２出力レジスタの第２有効ビットを前記第２有効ビットがクリアな状態になるまでポーリングし、
前記第２出力レジスタにステートデータを保存し、
前記第２出力レジスタから前記第２入力レジスタへとステートデータを送信するように構成され、前記サービスプロセッサは、前記第２入力レジスタにより受信される前記ステートデータを出力するように構成される、請求項７記載のシステム。
【請求項９】
前記ホストプロセッサは、前記テストデータの読み出しに応答して、前記第１有効ビットをクリアな状態にするように構成される、請求項８記載のシステム。
【請求項１０】
前記ホストプロセッサは、前記第２出力レジスタのステートデータの保存に応答して、前記第２有効ビットをセットするように構成される、請求項８記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプロセッサに関し、さらに具体的にはプロセッサの状態を判断するための方法及び装置に関するものである。
【背景技術】
【０００２】
新しいコンピュータシステム及びシステムソフトウエアの設計時には様々な技術が用いられ、システムプロセッサにより命令が実行される間に様々なハードウエア機構がどのように動くか測定される。システムハードウエアの動作の測定形態の一つとして、プログラムを実行する様々な段階においてプロセッサの状態を判断することが挙げられる。プロセッサの状態を判断することとしてはプロセッサにデータを送ることによりプロセッサを照会することが挙げられる。プロセッサより受信されるデータには処理がなされ、またプロセッサの状態を示す追加データを生成する。そのようなデータには、レジスタやリザベーションステーションなどのコンテンツが含まれる。次いでこの追加データは観察のためにプロセッサから送信される。これに代えて、プロセッサはが部ソースへデータを定期的に送信するように構成されてもよく、データはプロセッサの状態あるいはその他の情報を判断するために用いられる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
プロセッサにクエリーを送り、プロセッサの状態を判断するために様々なツールが開発されている。これらのツールはテストデータがプロセッサに入力されること、ステートデータがテストデータを受信するプロセッサに応答して生成されること、ステートデータが観察のためにプロセッサから送信されることをそれぞれ許容する。そのようなツールでの１つの難点として、プロセッサを照会する間の命令の実行が挙げられる。典型的には、そのようなツールは、プロセッサの演算がプロセッサクエリの間に割り込みすなわちインタラプトの発生を要求する。プロセッサにより実行される命令ストリームはテストデータを入力するため、ステートデータを生成するため、及びステートデータを出力するために割り込みが必要となる。テストデータを入力すること及びステートデータを出力することは既存の入力及び出力ポートの使用を要求し、その結果プロセッサへの、あるいはプロセッサからのその他のデータの入力及び出力に割り込みが生じる。更に、テストデータの入力はプロセッサが別のサービスルーティンへ切り替える結果をもたらし、このことは現在実行されている命令ストリームを保留する結果をもたらす。これらの要因は特定のルーティンがプロセッサで実行する速度を確定することを困難にする。更に、別のサービスルーティンへの送信はプロセッサクエリから真のプロセッサの状態を判断できなくする結果をもたらす。
【課題を解決するための手段】
【０００４】
ホストプロセッサの状態を判断するための方法及び装置が開示されている。一実施例では、サービスプロセッサは、ホストプロセッサのレシーバのレジスタに記録される有効ビットをポーリングする。有効ビットがクリアな状態であると判断されると、サービスプロセッサは出力レジスタにテストデータをロードし、ホストプロセッサへテストデータを送信し、送信が完了すると有効ビットをセットする。有効ビットがセットされたとホストプロセッサで判断されたことに応答して、レシーバのレジスタからテストデータが読み出される。テストデータに応答してホストプロセッサの状態を表すステートデータが生成される。ホストプロセッサは、その出力ポートのトランスミッタのレジスタの有効ビットをポーリングでき、また有効ビットはクリアな状態であるとの検出に応答してトランスミッタのレジスタにデータを保存する。次いでデータはサービスプロセッサのレシーバへ送信され、また有効ビットは既述の送信に応答してセットされる。ホストプロセッサへのデータ送信およびホストプロセッサからのデータ読み出しの演算は命令の実行を割り込むことなく実施される。更に、ホストプロセッサによるデータの送信及び受信はそれぞれ独立して発生する。
【０００５】
一実施例では、ホストプロセッサは入力ポート及び出力ポートを備えている。ホストプロセッサの入力ポートはサービスプロセッサの出力ポートと結合されるために構成される。一方で出力ポートはサービスプロセッサの入力ポートと結合されるために構成される。両ホスト及びサービスプロセッサの入力ポート及び出力ポートはそれぞれ多くのビットを記録するように構成されるレジスタを含む。各レジスタはセットされる際に記録されるデータは有効であることを表す有効ビットを記録するように構成される。入力ポートのレジスタは有効ビットがクリアな状態であるときにだけデータを受信するように構成される。データが出力ポートから入力ポートへ送信される際に、有効ビットは入力ポートのレジスタにセットされる。両ホストプロセッサ及びサービスプロセッサは、有効ビットがセットされるとの検出に応答してそれぞれの入力ポートのレジスタから読み出されるように構成される。
【０００６】
サービスプロセッサの一実施例ではデータは出力ポートのレジスタにロードされ、あるいはIEEE１１４９．１規格と一致する境界走査試験アクセスポート（バウンダリースキャンテストアクセスポート）（ＴＡＰ）を通って入力ポートから読み出される。データはテストデータ入力（ＴＤＩ）ピンを通ってサービスプロセッサの出力ポートのレジスタへ順次ロードされる。同様にデータはテストデータ出力（ＴＤＯ）ピンを通ってサービスプロセッサの出力ポートのレジスタから順次シフトされる。
【０００７】
多くの実施例では、入力ポート及び出力ポートを組み合わせたオペレーションは、互いに別々に動作する。つまりサービスプロセッサの出力ポートは、ホストプロセッサの出力ポートからサービスプロセッサの入力ポートへのいずれのデータ送信からも独立してホストプロセッサの入力ポートへデータを送信する。更に異なる実施例ではデータはプロセッサへあるいはプロセッサから定期的に送信され、あるいはデータは個々の照会に応答してプロセッサから送信される。
【０００８】
本発明は、様々な改良を行い、また、他の形態で実施することができるが、ここに説明されている特定の実施例は、例示として示さたものであり、以下にその詳細を記載する。しかし当然のことながら、ここに示した特定の実施例は、本発明を開示されている特定の形態に限定するものではなく、むしろ本発明は添付の請求項によって規定されている発明の範疇に属する全ての改良、等価物、及び変形例をカバーするものである。
【発明を実施するための最良の形態】
【０００９】
図１に、プロセッサ１０の一実施例のブロック図が示されている。別の実施例も可能であり、検討される。図１に示されているように、プロセッサ１０はプリフェッチ／プレデコードユニット１２、分岐予測ユニット１４、命令キャッシュ１６、命令整合ユニット１８、複数のデコードユニット２０A−２０C、複数のリザベーションステーション２２A−２２C、複数のファンクショナルユニット２４A−２４C、ロード／ストアユニット２６、データキャッシュ２８、レジスタファイル３０、リオーダーバッファ３２、ＭＲＯＭユニット３４、及びバスインターフェースユニット３７を含む。文字の後に続く特定の参照番号を備えた、本明細書に参照される要素は単独の参照番号により集合的に参照される。例えばデコードユニット２０A−２０Cは集合的にデコードユニット２０として参照される。
【００１０】
プリフェッチ／プレデコードユニット１２は、バスインターフェースユニット３７から命令を受信するために結合されている。また更にプリフェッチ／プレデコードユニット１２は命令キャッシュ１６及び分岐予測ユニット１４と結合される。同様に、分岐予測ユニット１４は命令キャッシュ１６と結合される。また更に分岐予測ユニット１４はデコードユニット２０及びファンクショナルユニット２４と結合される。命令キャッシュ１６は、更に、ＭＲＯＭユニット３４及び命令整合ユニット１８と結合される。命令整合ユニット１８は順にデコードユニット２０と結合される。各デコードユニット２０A−２０Cはロード／ストアユニット２６と、及びそれぞれのリザベーションステーション２２A−２２Cと結合される。リザベーションステーション２２A−２２Cは更にそれぞれのファンクショナルユニット２４A−２４Cと結合される。加えてデコードユニット２０及びリザベーションステーション２２はレジスタファイル３０及びリオーダーバッファ３２と結合される。ファンクショナルユニット２４もまたロード／ストアユニット２６、レジスタファイル３０、及びリオーダーバッファ３２と結合される。データキャッシュ２８はロード／ストアユニット２６と、及びバスインターフェースユニット３７と結合される。バスインターフェースユニット３７は更にL２キャッシュへのＬ２インターフェースとバスとに結合される。最後にＭＲＯＭユニット３４はデコードユニット２０と結合される。
【００１１】
命令キャッシュ１６は高速キャッシュメモリであり、命令を記録するために提供される。命令は命令キャッシュ１６から取り出されつまりフェッチされ、デコードユニット２０へ送られる。一実施例では命令キャッシュ１６は６４バイトライン（１バイトは８バイナリバイトより成る）を有する２ウエイセットアソシエイティブ構造の６４キロバイトを上限とする命令を記録するように構成される。あるいはその他いずれの所望の構造及びサイズが用いられてよい。例えば、命令キャッシュ１６はフルアソシエイティブ、セットアソシエイティブ、あるいはダイレクトマップ構造として実施されてよいことに留意されたい。
【００１２】
命令はプリフェッチ／プレデコードユニット１２により命令キャッシュ１６に記録される。命令はプリフェッチスキームにより、命令キャッシュ１６からその要求前にプリフェッチされる。プリフェッチ／プレデコードユニット１２により様々なプリフェッチスキームが用いられる。プリフェッチ／プレデコードユニット１２は命令キャッシュ１６に命令を送信するので、プリフェッチ／プレデコードユニット１２は命令に対応するプレデコードデータを生成する。例えば一実施例では、プリフェッチ／プレデコードユニット１２は命令の各バイトに対し３つのプレデコードビットを生成する。それらはスタートビット、エンドビット、及びファンクショナルビットである。プレデコードビットは各命令の境界を示すタグを形成する。プレコードタグはまた、所定の命令がデコードユニット２０により直接デコードされ得るかどうか、あるいは命令はＭＲＯＭユニット３４により制御されるマイクロコードプロシージャを呼出して実行されるかどうか、などの付加的な情報も送信する。更にまた、プリフェッチ／プレデコードユニット１２は分岐命令を検出するように構成され、また分岐命令に対応する分岐予測情報を分岐予測ユニット１４に記録するように構成される。その他の実施例は所望に応じていずれの適切なプレデコードスキームを用いてもよく、またプレデコードを用いなくてもよい。
【００１３】
可変バイト長の命令セットを用いるプロセッサ１０の実施例に対するプレデコードタグの符号化の１つが以下に解説される。可変バイト長の命令セットは異なる命令が異なるバイト数を占める命令セットである。プロセッサ１０の一実施例により用いられる典型的な可変バイト長命令セットはｘ８６命令セットである。
【００１４】
典型的な符号化では、所定のバイトが命令の第１バイトの場合、そのバイトに対するスタートビットがセットされる。バイトが命令の最後のバイトの場合、そのバイトに対するエンドビットがセットされる。デコードユニット２０により直接デコードされる命令は“高速経路”命令として参照される。残りのｘ８６命令は一実施例によればＭＲＯＭ命令として参照される。高速経路命令に対しては、命令に含まれる各プレフィックスバイトに対してファンクショナルビットがセットされ、その他のバイトに対してはクリアな状態にされる。代わりに、ＭＲＯＭ命令に対しては、ファンクショナルビットは各プレフィックスバイトに対してクリアな状態にされ、その他のバイトに対してはセットされる。命令の種類はエンドバイトに対応するファンクショナルビットを調べることにより判断される。そのファンクショナルビットがクリアな状態の場合、命令は高速命令である。反対にそのファンクショナルビットがセットされる場合、命令はＭＲＯＭ命令である。命令のオペレーションコードはそれにより命令の第１のクリアファンクショナルビットに関連するバイトとしてデコードユニット２０により直接デコードされる命令に配置される。例えば２プレフィックスバイト、ＭｏｄＲ／Ｍバイト、イミディエイトバイト(immediate byte)を含む高速経路命令は以下のようなスタート、エンド、ファンクショナルビットを有する。
スタートビット          １００００
エンドビット            ００００１
ファンクショナルビット  １１０００
【００１５】
ＭＲＯＭ命令は、デコードユニット２０によりデコードするには複雑すぎると判断される命令である。ＭＲＯＭ命令はMROMユニット３４を呼出すことにより実行される。更に具体的には、ＭＲＯＭ命令を受けると、MROMユニット３４は決められた高速経路命令のサブセットへ命令を解析し発行し、所望の演算を達成する。ＭＲＯＭユニット３４はデコードユニット２０へ高速経路命令のサブセットを送る。
【００１６】
プロセッサ１０は、分岐予測を用いて条件付分岐命令に続いて投機的に命令をフェッチする。分岐予測ユニット１４は分岐予測演算を実行するために含まれる。一実施例では、分岐予測ユニット１４は分岐ターゲットバッファを用いる。分岐ターゲットバッファは、命令キャッシュ１６に、キャッシュラインの１６バイト部ごとに、２つを上限とする分岐ターゲットアドレス及びそれに対応した採用された／採用されなかった予測をキャッシュする。分岐ターゲットバッファは例えば２０４８のエントリあるいはその他の適切な数のエントリを有す。プリフェッチ／プレコードユニット１２は特定の行がプレデコードされる際、初期の分岐ターゲットを判断する。続いてキャッシュラインと対応する分岐ターゲットへのアップデートが、キャッシュラインの命令を実行することにより発生する。命令キャッシュ１６は、フェッチされている命令アドレスの指示を与えて、分岐予測ユニット１４が分岐予測を形成するためにどの分岐ターゲットアドレスを選択するかを決定できるようにする。デコードユニット２０及びファンクショナルユニット２４は分岐予測ユニット１４へアップデート情報を送る。デコードユニット２０は分岐予測ユニット１４により予測されなかった分岐命令を検出する。ファンクショナルユニット２４は分岐命令を実行し、予測された分岐方向が間違っているかどうかを判断する。分岐方向が“採用され”た場合、続く命令は分岐命令のターゲットアドレスからフェッチされる。反対に、分岐方向は“採用されない”場合、次の命令は分岐命令に続いてメモリ位置からフェッチされる。誤予測分岐命令が検出されると、誤予測分岐に続く命令はプロセッサ１０の様々なユニットから破棄される。他の構成として、分岐予測ユニット１４はデコードユニット２０及びファンクショナルユニット２４の代わりにリオーダーバッファ３２と結合され、且つ、リオーダーバッファ３２から分岐誤予測情報を受信する。様々な適切な分岐予測アルゴリズムは分岐予測ユニット１４により用いられる。
【００１７】
命令キャッシュ１６からフェッチされる命令は、命令整合ユニット１８に伝達される。命令は命令キャッシュ１６からフェッチされるので、対応するプレデコードデータは走査され、フェッチされる命令に関し命令整合ユニット１８（及びＭＲＯＭユニット３４）へ情報が送られる。命令整合ユニット１８は走査データを利用し、各デコードユニット２０へ命令を整合する。一実施例では、命令整合ユニット１８は３セットの８命令バイトからデコードユニット２０へ命令を整合する。デコードユニット２０Aはデコードユニット２０B及び２０C（プログラム順序で）により同時に受信される命令よりも前の命令を受信する。同様にデコードユニット２０Bはプログラム順序でデコードユニット２０Cにより同時に受信される命令よりも前の命令を受信する。いくつかの実施例では（例：固定長の命令セットを用いた実施例）、命令整合ユニット１８はなくされる。
【００１８】
デコードユニット２０は命令整合ユニット１８から受信される命令をデコードするように構成される。レジスタオペランド情報は検出され、レジスタファイル３０及びリオーダーバッファ３２へ送られる。加えて、１つ以上のメモリ演算の実施を命令が要求する場合、デコードユニット２０は、メモリ演算をロード／ストアユニット２６へ送る。各命令はファンクショナルユニット２４に対する一連のコントロール値にデコードされ、またこれらのコントロール値は命令に含まれる置換えあるいは即値データとオペランドアドレス情報とともにリザベーションステーション２２へ送られる。１つの具体的な実施例では、各命令はファンクショナルユニット２４Ａ−２４Ｃにより別々に実施される２つを上限とする演算にデコードされる。
【００１９】
プロセッサ１０は、アウトオブオーダー実行をサポートする。従ってリオーダーバッファ３２を用いてレジスタリード及びライト演算に対しオリジナルプログラムのシーケンスの経過を追い、レジスタリネームを実施し、投機的な命令の実行と分岐誤予測回復を許容し、“正確な”例外（precise exceptions）となるよう促進する。リオーダーバッファ３２内の一時的な記録場所はレジスタのアップデートを含む命令をデコード後にリザーブされ、その結果投機的なレジスタの状態を記録する。分岐予測が間違いの場合、誤予測経路に沿った投機的に実行される命令の結果はレジスタファイル３０に書き込まれる前にバッフアにて無効にされうる。同様に、特定の命令が例外を引き起こす場合、特定の命令に続く命令は破棄される。このような方法で例外は“正確”である（すなわち、例外を引き起こす特定の命令に続く命令は例外の前には完了されない）。ここで留意すべきは、特定の命令というのはプログラムの順序で特定の命令に先行する命令の前に実行される場合は投機的に実効されることである。先行する命令は分岐命令あるいは例外を引き起こす命令であり、いずれの場合にも投機的な結果はリオーダーバッファ３２により破棄される。
【００２０】
デコードユニット２０の出力において送られるデコードされる命令はそれぞれのリザベーションステーション２２へ直接送られる。一実施例では各リザベーションステーション２２は対応するファンクショナルユニットへの発行を待つ上限６つの保留命令に対し命令情報（例：オペランド値、オペランドタグ及び／あるいは即値データと同様、デコードされる命令）を保持することができる。ここで留意すべきは、図１の実施例に対して、各リザベーションステーション２２は専用のファンクショナルユニットと関連付けられている点である。したがって３つの専用”発行部（issue portion）”、はリザベーションステーション２２及びファンクショナルユニット２４により形成される。つまり、発行部０はリザベーションステーション２２Ａ及びファンクショナルユニット２４Ａにより形成される。リザベーションステーション２２Ａへ整合され、また送られる命令はファンクショナルユニット２４Ａにより実行される。同様に、発行部１はリザベーションステーション２２Ｂとファンクショナルユニット２４Ｂにより形成される。発行部２はリザベーションステーション２２Ｃとファンクショナルユニット２４Ｃにより形成される。
【００２１】
特定の命令をデコード後、所望のオペランドがレジスタ位置にある場合、レジスタアドレス情報はリオーダーバッファ３２とレジスタファイル３０へ同時に送られる。レジスタファイル３０はプロセッサ１０により実施される命令セットに含まれる各々の設計されたレジスタに対し記録場所を有す。追加の記録場所はＭＲＯＭユニット３４により用いられるためにレジスタファイル３０に含まれる。リオーダーバッファ３２は、これらのレジスタのコンテントを変更する結果に対し一時的な記録場所を有し、その結果アウトオブオーダー実行を許容する。リオーダーバッファ３２の一時的な記録場所は各命令に対しリザーブされ、各命令はデコード後に実レジスタの１つのコンテントを修正するために判断される。従って、特定のプログラムを実行する間、様々なポイントでは、リオーダーバッファ３２は１つ以上の場所を有し、それらは所定のレジスタの投機的に実施されるコンテントを含む。所定の命令のデコードに続いて、リオーダーバッファ３２が前の場所あるいは所定の命令でオペランドとして用いられるレジスタに割振られた場所を有すると判断される場合、リオーダーバッファ３２は  １）直前に割振られた場所の値、あるいは２）最終的に前の命令を実行するファンクショナルユニットにより値が生成されていない場合に、直前に割振られた場所に対するタグ、のどちらか一方を対応のリザベーションステーションへフォーワードする。リオーダーバッファ３２が所定のレジスタに対しリザーブされる場所を有する場合、オペランド値（あるいはリオーダーバッファタグ）がレジスタファイル３０からではなくリオーダーバッファ３２から送られる。リオーダーバッファ３２にて要求されるレジスタに対しリザーブされる場所を有さない場合、値はレジスタファイル３０から直接取られる。オペランドがメモリ位置に対応する場合、オペランド値はロード／ストアユニット２６を通ってリザベーションステーションに送られる。
【００２２】
１つの具体的な実施例では、リオーダーバッファ３２はユニットとして同時にデコードされる命令を記録し処理するように構成される。この構成は“行型”として本明細書に参照される。いくつもの命令を一緒に処理することにより、リオーダーバッファ３２に用いられるハードウエアを単純化することができる。例えば本実施例に含まれる行型のリオーダーバッファは１つ以上の命令がデコードユニット２０により送られるときは、いつでも３つの命令（各デコードユニット２０から１つ）に関する命令情報に対し十分な記録を割振る。それに対し、可変長の記録は、実際に送られる命令の数に応じて従来のリオーダーバッファに割振られる。相対的に大きな数の論理ゲートが可変長の記録を割振るために必要とされる。同時にデコードされる命令の各々が実行される場合、命令の結果はレジスタファイル３０に同時に記録される。次いで記録は別の一連の同時にデコードされる命令へ自由に割振ることができる。加えて命令ごとに用いられる制御論理回路の総数は、制御論理が様々な同時にデコードされる命令上に償却されるため、低減される。特定の命令を識別するデコーダーバッファタグは二つのフィールドに分割される。ラインタグとオフセットタグである。ラインタグは特定の命令を含む一連の同時にデコードされる命令を識別し、またオフセットタグはセットのどの命令が特定の命令と対応するかを識別する。留意すべきは命令を記録することはレジスタファイル３０をもたらし、対応の記録を自由にすることは命令を”リタイアする”として参照されることである。更に留意すべきはいずれのリオーダーバッファ構成もプロセッサ１０の様々な実施例において用いられることである。
【００２３】
先に述べたように、リザベーションステーション２２は対応のファンクショナルユニット２４により命令が実行されるまで命令を記録する。命令は（ｉ）命令のオペランドが提供されている場合；及び（ｉｉ）オペランドが同じリザベーションステーション２２Ａ−２２Ｃにあるとともにプログラム順序で命令の前にある命令が提供されていない場合、実行するよう選択される。命令がファンクショナルユニット２４の１つにより実行される場合、その命令の結果はその結果を待ついずれのリザベーションステーション２２へ直接パスされ、同時に結果はリオーダーバッファ３２をアップデートするためにパスされる（この技術は、一般にリザルトフォワーディング（result forwarding）と称される）。命令は実行するために選択され、クロックサイクルの間、関連する結果がフォーワードされるファンクショナルユニット２４Ａ−２４Ｃへパスされる。リザベーションステーション２２はこの場合、フォワードされる結果をファンクショナルユニット２４へ送る。命令が、ファンクショナルユニット２４により実行される様々な演算にデコードされるという実施例では、演算はそれぞれ別々にスケジュールされる。
【００２４】
一実施例では、各ファンクショナルユニット２４はシフト、送信、論理演算、ブランチ演算と同様に、加算及び引き算の整数算術演算を実施するように構成される。演算はデコードユニット２０により特定の命令に対しデコードされるコントロール値に応答して実施される。浮動小数点ユニット（図示せず）もまた用いられ、浮動小数点演算に適応される。浮動小数点ユニットはＭＲＯＭユニット３４あるいはリオーダーバッファ３２から命令を受信し、その後リオーダーバッファ３２と通信し命令を完了するコプロセッサとして、オペレーションがなされる。加えて、ファンクショナルユニット２４はロード／ストアユニット２６により実施されるロード及びストアメモリ演算に対しアドレス生成を実施するように構成される。１つの特定の実施例では、各ファンクショナルユニット２４はアドレスを生成するためのアドレス生成ユニット及び残りのファンクションを実施するための実行ユニットを有す。２つのユニットはクロックサイクルの間、異なる命令あるいは演算から独立してオペレーションがなされる。
【００２５】
各ファンクショナルユニット２４は、また分岐予測ユニット１４への条件付分岐命令の実行に関して情報を送る。分岐予測が間違いであった場合、分岐予測ユニット１４は命令処理パイプラインに入った誤予測ブランチの後に命令を流し、そして命令キャッシュ１６あるいはメインメモリから要求される命令をフェッチさせる。留意すべきはそのような状況において、投機的に実施された、及び一時的にロード／ストアユニット２６およびリオーダーバッファ３２に記録されるものを含む、誤予測分岐命令の破棄後に発生するオリジナルプログラムシーケンスの命令の結果は破棄されるということである。さらに留意すべきはブランチ実行の結果はファンクショナルユニット２４によりリオーダーバッファ３２へ送られることであり、それはファンクショナルユニット２４への分岐誤予測を表す。
【００２６】
ファンクショナルユニット２４により生成される結果はレジスタ値がアップデートされる場合はリオーダーバッファ３２へ送られ、またメモリ位置のコンテントが変更される場合はロード／ストアユニット２６へ送られる。結果がレジスタに記録されるものである場合、リオーダーバッファ３２は命令がデコードされた際にレジスタの値に対してリザーブされる位置に結果を記録する。複数のリザルトバス３８は、ファンクショナルユニット２４及びロード／ストアユニット２６から結果をフォーワードするために含まれる。リザルトバス３８は実行される命令を認識するリオーダーバッファタグと同様、生成される結果を運ぶ。
【００２７】
ロード／ストアユニット２６は、ファンクショナルユニット２４とデータキャッシュ２８との間にインターフェースを提供する。一実施例ではロード／ストアユニット２６は第１ロード／ストアバッファと第２ロードストア／バッファを有する。第１ロード／ストアバッファはデータキャッシュ２８にアクセスしていない保留のロードあるいはストアに対しデータ及びアドレス情報に対する記録場所を有して構成される。第２ロード／ストアバッファはデータキャッシュ２８にアクセスしたロード及びストアに対するデータ及びアドレス情報に対する記録場所を有して構成される。例えば第１バッファは１２の場所を有し、第２バッファは３２の場所を有する。デコードユニット２０はロード／ストアユニット２６へのアクセスのために調停する。第１バッファがフルの状態であるとき、デコードユニットは保留のロードあるいはストアの要求情報に対しロード／ストアユニット２６が空きを有するまで待たなければならない。ロード／ストアユニット２６はまた保留のストアメモリ演算に対してロードメモリ演算のためにディペンデンシーチェックを行い、データの一貫性が維持されていることを確認する。メモリ演算はプロセッサ１０とメインメモリサブシステムとの間のデータ送信である（送信はデータキャッシュ２８で達成されるが）。メモリ演算はメモリに記録されるオペランドを利用する命令の結果である。あるいはデータの送信を引き起こすがその他の演算は引き起こさないロード／ストア命令の結果である。
【００２８】
データキャッシュは、ロード／ストアユニット２６とメインメモリサブシステムとの間に送信されるデータを一時的に記録するために設けられる高速のキャッシュメモリである。一実施例では、データキャッシュ２８は２ウエイセットアソシエイティブ構造で６４キロバイトを上限とする記録容量を有する。データキャッシュ２８はセットアソシエイティブ構造、フルアソシエイティブ構造、ダイレクトマップ構造、及びその他の適切な構造の適切なサイズを含む様々な具体的なメモリ構造で実施される。
【００２９】
バスインターフェースユニット３７はプロセッサ１０とバスを介するコンピュータシステムのその他のコンポーネントとの間を通信するように構成される。例えばバスはデジタル  イクイップメント  コーポレーション（Ｄｉｇｉｔａｌ  Ｅｑｕｉｐｍｅｎｔ  Ｃｏｒｐｏｒａｔｉｏｎ）により開発されたＥＶ−6バスと互換性がある。その他、パケットベース、単方向あるいは双方向リンクなどを含むいずれの適切な相互接続構造を用いることが出来る。任意のＬ２キャッシュインターフェースもまたレベル２キャッシュへインターフェース接続のため、同様に用いられる。
【００３０】
留意すべきは、図１の実施例はスーパースカラ実行であるが、その他の実施例はスカラ実行を用いてもよいということである。更に、ファンクショナルユニットの数は実施例により異なる。その他の実施例は図１に示されている個々のリザベーションステーションではなくセントラルリザベーションステーションを用いてもよい。更にその他の実施例は図１のリザベーションステーション及びリオーダーバッファではなくセントラルスケジューラを用いる。
【００３１】
プロセッサ１０は、メールボックス１００としてここに示されるようにポートを含む。ポートは命令ストリームを実行する間、照会されるのを許容する。メールボックスポート１００はプロセッサ１０の外側にあるサービスプロセッサあるいはデバッグプロセッサと結合されるために構成される。プロセッサ１０の状態を照会するために用いられるテストデータはメールポート１００を介して受信される。同様に、照会から生じるプロセッサ１０の状態を示すステートデータはメールボックスポート１００からサービスプロセッサあるいはデバッグプロセッサへ送信される。メールボックスポート１００はデコードユニット２０Ａ−２０Ｃ、レジスタファイル３０、命令キャッシュ１６、ファンクショナルユニット２４Ａ−２４Ｃなど１つ以上のプロセッサ１０のユニットと結合される。情報はメールボックスポート１００から送信あるいは受信される。
【００３２】
図２に、プロセッサの状態を判断するシステムの一実施例のブロック図が示されている。この実施例は、プロセッサ１０、以後ホストプロセッサ１０はサービスプロセッサ１４０と結合される。いくつかの実施例では、サービスプロセッサ１４０はホストプロセッサ１０が実施されるコンピュータシステムに結合されるもうひとつのコンピュータシステムに配置される。その他の実施例では、サービスプロセッサ１４０はホストプロセッサが配置されるコンピュータシステムの周辺スロットに挿入されるボード上に配置される、あるいはホストプロセッサと同じボードに取り付けられる。
【００３３】
先に述べたように、ホストプロセッサ１０は、メールボックスポート１００を含む。メールボックスポート１００はメールボックス入力ポート１０２及びメールボックス出力ポート１０４を含む。メールボックス入力ポート１０２はサービスプロセッサ１４０のコンプリメンタリ出力ポート１５２と結合するように構成される。同様にメールボックス出力ポート１０４はサービスプロセッサ１４０のコンプリメンタリ入力ポート１５４と結合するように構成される。
【００３４】
ホストプロセッサ１０のメールボックス入力ポート１０２はサービスプロセッサ１４０から送信されるテストデータを受信する。テストデータはサービスプロセッサ１４０の出力ポート１５２からホストプロセッサ１０のメールボックス入力ポート１０２へ送信される。同様に、サービスプロセッサ１４０はホストプロセッサ１０からステートデータを受信するように構成される。ステートデータはホストプロセッサ１０のメールボックス出力ポート１０４からサービスプロセッサ１４０の入力ポート１５４へ送信される。入力／出力ポートの各コンプリメンタリペアは互いに独立して機能する。つまり出力ポート１５２はメールボックス出力ポート１０４から入力ポート１５４へのステートデータのいずれの送信からも独立して、メールボックス入力ポート１０２へテストデータを送信する。
【００３５】
テストデータはサービスプロセッサ１４０の出力ポート１５２へ、テストアクセスポート（ＴＡＰ）の一部であるテストデータ入力（ＴＤＩ）ピンを介して、連続的にロードされる。テストアクセスポートはＩＥＥＥ規格１１４９．１と互換性のある境界走査（バウンダリスキャン）ポートである。同様にステートデータはテストデータ出力ピンを介して入力ポート１５４から連続的にシフトされる。サービスプロセッサ１４０からのテストデータのロード及びステートデータのアンロードについての追加の詳細は以下に解説される。
【００３６】
図３はサービスプロセッサ出力ポートに結合されるホストプロセッサ入力ポートの一実施例を例示したブロック図である。実施例ではホストプロセッサ１０のメールボックス入力ポート１０２はサービスプロセッサ１４０のメールボックス出力ポート１５２と結合されている。メールボックス入力ポート１０２は入力レジスタ１１２を含む。入力レジスタ１１２はテストデータを受信及び記録するように構成されている。テストデータは出力ポート１５２に配置される出力レジスタ１６２から受信される。両出力レジスタ１６２及び入力レジスタ１１２は様々な大きさである。一実施例では、出力レジスタ１６２及び入力レジスタ１１２は３２ビットのデータと１つの有効ビットを記録するように構成される。多様なレジスタ（両メールボックス入力ポート及び両メールボックス出力ポートに対して）と同様、異なるレジスタサイズを有するその他の実施例も可能であり、検討される。
【００３７】
ホストプロセッサ１０の状態を判断するため、入力レジスタ１１２の有効ビットは出力レジスタ１６２へのテストデータのローディングに続いて、照会されなければならない。
先に述べたように、データはＩＥＥＥ１１４９．１規格と互換性のある境界走査ＴＡＰを介してメールボックス出力ポート１５２へロードされる。示されている一実施例では、出力レジスタ１６２はＴＤＩピンと結合される。テストデータは連続的にＴＤＩピンを介して出力レジスタ１６２にシフトされる。テストデータに加えて、有効ビットもまたＴＤＩピンを介して出力レジスタにセットされる。
【００３８】
入力レジスタ１１２へテストデータを送信するため、有効ビットをポーリングしてクリアな状態であることを確認することがまず必要である。このビットはホストプロセッサのクロックドメインにあるので、まずサービスプロセッサのクロックドメインへ同期化させる必要がある。同期化されたバージョンの有効データは出力レジスタ１６２に取り込まれ、試験のために順次シフトアウトされる。有効データは試験のために順次シフトアウトされる間、テストデータは出力レジスタ１６２へ順次ロードされる。
【００３９】
入力レジスタ１１２の有効ビットをポーリングする間に有効ビットがセットされると判断される場合はテストデータがメールボックス入力ポート１０２にロードされたが、ホストプロセッサ１０により読み出されていないことを表している。従って、出力レジスタ１６２へテストデータをローディングし、及び続いて入力レジスタ１１２への送信はこの有効ビットがセットされる間は禁止される。テストデータの読み出し後、有効ビットは入力レジスタ１１２からホストプロセッサによりクリアな状態にされる。入力レジスタ１１２に記録される有効ビットはクリアな状態であるとの検出に応答して、出力ポート１５２は入力レジスタ１１２へテストデータの送信を開始する。この実施例では、別々のＴＡＰ命令が用いられ有効ビットがセットされる。この命令を用いることにより出力レジスタ１６２から入力レジスタ１１２へデータの同期ローディングをさせる（図３の“Ａ”を参照のこと）。
【００４０】
ホストプロセッサ１０のプロセッサコアは入力レジスタ１１２の有効ビットのポーリングも行う。入力レジスタ１１２へのテストデータの正常ローディングを示す有効ビットのセットを検出後、プロセッサコアはテストデータを読み出す。次いでテストデータが用いられ、ステートデータを生成し、サービスプロセッサへと戻される。更なる詳細を以下に解説する。
【００４１】
入力ポート及び出力ポート間の送信及び受信用プロトコルは両ホストプロセッサ１０及びサービスプロセッサ１４０に対し同じである。以下の表１に、入力／出力ポートを組み合わせた一実施例に対するプロトコルを例示する。
表１
│トランスミッタ            │レシーバ                        │
│                          │                                │
│１．クリアな状態になるまで│１．セットされるまでホストプロセ│
│ホストプロセッサの有効ビッ│ッサの有効ビットをポーリングす  │ 
│トをポーリングする。      │る。                            │ 
│                          │                                │
│２．レジスタにデータを保存│２．データを読み出す。          │ 
│する。                    │                                │ 
│                          │                                │
│３．ホストプロセッサの有効│３．ホストプロセッサの有効ビット│
│ビットをセットする。      │をクリアな状態にする。          │ 
【００４２】
概して、システムのトランスミッタ（すなわち、出力ポート）はレシーバへデータを送信する前にホストプロセッサの有効ビットをポーリングする必要がある。ホストプロセッサの有効データがクリアな状態であるとの検出後、データは出力レジスタに保存され、レシーバの入力レジスタに送信される。トランスミッタからレシーバへのデータが正常送信されたことは、入力レジスタの有効ビットをセットすることにより表される。システムのレシーバ（すなわち入力ポート）は、ホストプロセッサがセットされるまでホストプロセッサの有効ビットをポーリングする。ホストプロセッサの有効ビットがセットされたことは、有効データが入力レジスタに存在することを示し、従って、レシーバがデータを読み出すのを許容する。データの読み出しに続き、ホストプロセッサの有効ビットはクリアな状態にされる。
【００４３】
様々な実施例では、サービスプロセッサのレシーバは入力レジスタからデータを定期的にシフトし、且つ、先述のシフト（有効ビットはシフトアウトされるデータの一部であるので）に続いて有効ビットを調べ、データが有効であるかどうかを判断する。
【００４４】
図４に、サービスプロセッサの入力ポートに結合されるホストプロセッサの出力ポートの一実施例のブロック図を示す。示されている実施例では、ホストプロセッサ１０のメールボックス出力ポート１０４は、サービスプロセッサ１４０の入力ポート１５４と結合されている。メールボックス出力ポート１０４は出力レジスタ１１４を含み、出力レジスタ１１４はホストプロセッサ１０のプロセッサコアから受信するステートデータを記録するように構成される。出力レジスタ１１４に受信されるステートデータは先に入力されるテストデータに応答して生成される。メールボックス出力ポートは出力レジスタ１１４を含み、一方で入力ポート１５４は入力レジスタ１６４を含む。
【００４５】
出力レジスタ１１４にいずれのデータ送信を行うにしても、その前に、出力レジスタ１１４に記録される有効ビットをポーリングし、クリアであるかどうかを判断する必要がある。有効ビットがクリアな状態であるとの判断後、メールボックス出力ポート１０４は、出力レジスタ１１４にステートデータを保存し、続いて出力レジスタ１１４に有効ビットをセットする。入力レジスタ１６４へのデータ送信はサービスプロセッサ１４０により開始される。これはＴＡＰコントローラのキャプチャ・ＤＲ（Capture-DR）ステートにおいて行われる。ステートデータ及び有効ビットが入力レジスタ１６４に送信されると、有効ビットは調べられ、データはテストデータ出力（Test Data Out:ＴＤＯ）ピンを介してシフトアウトすることにより読み出される。有効ビットがセットされる場合、サービスプロセッサ１４０は有効ビットとともにシフトアウトされたデータは実行可能である（すなわち有効データ）ということを判断する。
【００４６】
メールボックス入力ポートへの、及び出力ポートへからのデータ送信は、両サービスプロセッサ及びホストプロセッサに対する一連の命令により制御される。一実施例においては、サービスプロセッサに対するＴＡＰ命令は、ＭＢＯＸＩＮ、ＭＢＯＸＩＮＳＥＴＶ、ＭＢＯＸＯＵＴ、及びＭＢＯＸＯＵＴＣＬＲＶである。ＭＢＯＸＩＮ命令はサービスプロセッサ１４０により用いられ、出力ポート１５２からメールボックス入力ポート１０２へのテストデータの送信が達成される。サービスプロセッサ１４０は、テストデータの送信に応答してＭＢＯＸＩＮＳＥＴＶ命令を実行する。従って、入力レジスタ１１２に有効ビットをセットし、有効データが存在することをホストプロセッサ１０に示す。ＭＢＯＸＯＵＴ命令はホストプロセッサ１０からサービスプロセッサ１４０へステートデータの送信を開始するために実行される。ＭＢＯＸＯＵＴＣＬＲＶ命令は出力レジスタ１１４に記録される有効ビットをクリアな状態にするために実行される。
【００４７】
ホストプロセッサ１０により実行される命令はニーモニックＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＩＮ及びＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＯＵＴに対し、モデルスペシフィックレジスタ（ＭＲＳ）リード及びライト命令を含む。ＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＩＮのＭＳＲリードはメールボックス入力レジスタ１１２へアクセスを開始し、レジスタからテストデータを読み出す。ＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＩＮに対するＭＳＲライトは有効ビットをクリアな状態にするために用いられる。ＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＯＵＴにたいするＭＳＲライトはメールボックス出力レジスタ１１４へアクセスを開始し、ステートデータを保存あるいは有効ビットをセットする。ＵＣ＿ＳＰＲＥＧ＿ＭＢＯＸ＿ＯＵＴのＭＳＲリードは有効ビットがクリアな状態であることを検出するために用いられる。
【００４８】
留意すべきは、様々な命令と関連付けられるニーモニックは、１つの特定の実施例に対する具体例であることである。入力及び出力ポートとともに用いられる特定の命令を解説するその他のニーモニックを有する実施例は可能であり、検討される。
【００４９】
留意すべきは、サービスプロセッサ１４０の出力レジスタ１６２及び入力レジスタ１６４はＴＤＩピンとＴＤＯピンのとの間のＴＡＰのいずれのシフトレジスタであってよく、いずれのシフトレジスタもテスト／ステートデータ及び少なくとも１つの有効ビットを記録するのに十分な数のビット位置を有するということである。更に留意すべきは、プロセッサ１４０のその他の実施例もまた可能であり、検討されるということであり、テストデータがロードされ、上述のＴＡＰの他に機構を介してステートデータが読み出される。加えてこの解説の目的のため、サービスプロセッサ及びデバッグプロセッサという用語は互換性があり、デバッグプロセッサはサービスプロセッサに代用でき、本明細書の解説に従い構成される。
【００５０】
図５Ａに、ホストプロセッサを照会する方法の一実施例のフロー図を示す。方法５００はホストプロセッサ（アイテム５０２）の入力レジスタに有効ビットをポーリングすることから開始する。ポーリングの間、有効ビットがクリアな状態であるかあるいはセットされるかどうかについて判断される（アイテム５０４）。有効ビットがセットされている場合、ポーリングは継続する。セットされる有効ビットはホストプロセッサの入力レジスタがまだ読み出されていない有効データを含むことを表す。テストデータのシリアルローディングは上述のようにＴＤＩピンを介してなされる。テストデータが並列にローディングされるという他の実施例も可能であり、検討される。出力レジスタへのテストデータのローディングに続き、サービスプロセッサの出力ポートはホストプロセッサの入力レジスタにデータを送信し（アイテム５０８）また有効ビットをセットする（アイテム５１０）ことができる。ホストプロセッサの入力レジスタに有効ビットをセットすることは有効データが存在し、読み出しの準備ができていることをプロセッサに示す。有効ビットのセットの検出に応答して、ホストプロセッサはテストデータを読み出し、テストデータに基づきステートデータを生成する（アイテム５１２）。メールボックス入力ポートの入力レジスタに記録される有効ビットは、ホストプロセッサによるテストデータの読み出しに続いてホストプロセッサによりクリアな状態にし得る。
【００５１】
図５Ｂは、ホストプロセッサからステートデータを出力するための方法の一実施例を示したフロー図である。ステートデータは図５Ａで解説された方法及び図１−４において解説された機構により生成される。方法５５０はホストプロセッサの出力レジスタの有効ビットをポーリングすることから開始する（アイテム５５２）。図５Ａを参照して解説された方法と同様に、有効ビットのポーリングは有効ビットがクリアな状態であると判断されるまで継続される（アイテム５５４）。有効ビットはクリアな状態であると判断されると、ホストプロセッサはステートデータをそのメールボックス出力ポートの出力レジスタに保存する（５５６）。出力レジスタへのステートデータのローディングに続いて、ホストプロセッサは出力レジスタに有効ビットをセットする（アイテム５６０）。サービスプロセッサはCapture-DRステートの有効ビット及びデータを送信し、次いでそれを入力レジスタからシフトする（アイテム５６２）。送信される有効ビットがセットされる場合、次いでデータは有効であるものとして識別される。入力レジスタからステートデータの読み出しに応答して、ホストプロセッサの有効ビットはクリアすることができ、その結果、追加のステートデータをホストプロセッサから送ることが可能となる。特に、図５Ｂを参照して解説される演算は、図５Ａを参照して解説された演算とは独立して発生可能であることが重要である。
【００５２】
留意すべきは本明細書にて用いられている“テストデータ”という用語は所望の応答を受信するためにホストプロセッサ１０に入力されるいずれの種類のデータを参照するということである。同様に、“ステートデータ”という用語はホストプロセッサ１０のオペレーションに関する情報を提供するのに用いられるいずれの種類のデータを参照する。加えて更に留意すべきは、テストデータのローディング及び／あるいはステートデータの読み出しはプロセッサの個々の照会に応答するもの、あるいは定期的に実施される演算のうちのどちらか一方である。代替の実施例は可能であり、検討され、有効ビットをポーリングし、データを送信する特定の順序はここに解説されたものと異なってもよい。
【００５３】
本発明は特定の実施例に関して解説されているが、実施例は例示的なものであり、発明の範囲は限定されないことが理解されるであろう。実施例のいずれの変形、修正、追加及び改良は可能である。これらの変形、修正、追加、改良は以下のクレームで解説されるように発明の範囲内に収まるものである。
【産業上の利用可能性】
【００５４】
本発明は、該してプロセッサに応用できる。
【図面の簡単な説明】
【００５５】
【図１】プロセッサの一実施例のブロック図。
【図２】プロセッサの状態を判断するためのシステムの一実施例のブロック図。
【図３】サービスプロセッサの出力ポートに結合されるホストプロセッサの入力ポートの一実施例を例示したブロック図。
【図４】サービスプロセッサの入力ポートに結合されるホストプロセッサの出力ポートの一実施例のブロック図。
【図５Ａ】ホストプロセッサを照会する方法の一実施例のフロー図。
【図５Ｂ】ホストプロセッサからステートデータを出力するための方法の一実施例のフロー図。
【図１】
2006514349.tif 000003
【図２】
2006514349.tif 000004
【図３】
2006514349.tif 000005
【図４】
2006514349.tif 000006
【図５Ａ】
2006514349.tif 000007
【図５Ｂ】
2006514349.tif 000008
【国際調査報告】
2006514349.tif 000009
2006514349.tif 000010