(57)【要約】【課題】  マイクロプロセッサにおける種々の命令タイプを対象とした統一のレジスタ・リネーム機構を提供する。【解決手段】  本ユニバーサル・リネーム機構は、単一のリネーム構造を使用して種々の命令タイプの宛先をリネームする。従って、浮動小数点レジスタ（ＦＲＰ）を更新する命令は、同じリネーム構造を使って汎用レジスタ（ＧＰＲ）またはベクトル・マルチメディア・エクステンション（ＶＭＸ）命令レジスタ（ＶＲ）を更新する命令と共にリネームされ得る。それは、ＧＰＲに対する設計された状態の数がＦＰＲおよびＶＲに対する設計された状態の数と同じであるためである。各宛先タグ（ＤＴＡＧ）が１つの宛先に割り当てられる。浮動小数点命令がＤＴＡＧに割り当てられ、固定小数点命令が次のＤＴＡＧに割り当てられる。ユニバーサル・リネーム機構の場合、すべての命令タイプに対して唯一のリネーム構造を持つことによって、かなりのシリコンおよび電力を節約することが可能である。【選択図】  図３
2008269601.tif 000002
【特許請求の範囲】
【請求項１】
ユニバーサル・レジスタ・リネーミングを行なうための方法であって、
マイクロプロセッサにおいて発行される命令に対して宛先タグを割付けるステップと、
前記マイクロプロセッサのリネーム・ステージにおいて前記命令に対する宛先タイプを論理レジスタ・アレイにセットするステップと、
前記宛先タイプに対応したリネーム・バッファに前記命令の結果が書込まれる場合、前記論理レジスタ・アレイにおいてリネーム・バッファ・ビットをアサートするステップと、
を含む、方法。
【請求項２】
前記命令が、先行の命令に適合するターゲット・レジスタをアクセスするかどうかを決定するステップと、
前記命令が、先行の命令に適合するレジスタをアクセスする場合、前記先行の命令に対する宛先タグを回復リンク・アレイにおける回復リンク・エントリに書込むステップと、
を更に含む、請求項１に記載の方法。
【請求項３】
前記回復リンク・アレイにおけるエントリの有効性を維持するステップを更に含む、請求項２に記載の方法。
【請求項４】
前記命令が、前記ターゲット・レジスタをアクセスする直近の命令であることを表すために前記命令に対する直近命令ビットをアサートするステップを更に含む、請求項２に記載の方法。
【請求項５】
前記先行の命令に対する直近命令ビットをアサート解除するステップを更に含む、請求項２に記載の方法。
【請求項６】
発行キューにおいて、発行命令が比較的直近の命令に従属するかどうかを決定するステップと、
前記発行命令が比較的直近の命令に従属しない場合、前記発行命令に対する前記発行キュー内の設計されたレジスタ・ビットをアサートするステップと、
前記発行命令が比較的直近の命令に従属する場合、前記発行命令に対する前記発行キュー内の前記設計されたレジスタをアサート解除するステップと、
を更に含む、請求項１に記載の方法。
【請求項７】
アサートされたリネーム・バッファ・ビットを有する発行命令に対して、論理レジスタ・ターゲット、１つまたは複数のディスパッチ・ソース・レジスタ・アドレス、宛先タグ、ソース宛先タグ、および前記発行命令に対する設計されたレジスタ・ビットを対応する実行ユニットに送るステップを更に含む、請求項６に記載の方法。
【請求項８】
前記発行命令に対する前記設計されたレジスタ・ビットがアサートされる場合、前記１つまたは複数のディスパッチ・ソース・レジスタ・アドレスを読取りアドレスとして使用して、前記発行命令の宛先タイプに対応する設計されたレジスタから１つまたは複数のオペランドを読取るステップと、
前記発行命令に対する前記設計されたレジスタ・ビットがアサート解除される場合、前記ソース宛先タグを読取りアドレスとして使用して、前記発行命令の宛先タイプに対応するリネーム・バッファから１つまたは複数のオペランドを読取るステップと、
を更に含む、請求項７に記載の方法。
【請求項９】
実行命令の実行時に、書込まれるべきオペランドの実行宛先タグを前記発行命令のソース宛先タグに比較するステップと、
前記書込まれるべきオペランドの実行宛先タグが前記発行命令のソース宛先タグに一致する場合、前記発行命令に対する発行キューにおけるリネーム・バッファ・ビットをアサートするステップと、
を更に含む、請求項７に記載の方法。
【請求項１０】
前記リネーム・ステージにおいて、前記実行宛先タグによって指定されたロケーションにおける前記論理レジスタ・アレイ内の前記リネーム・バッファ・ビットをアサートするステップを更に含む、請求項７に記載の方法。
【請求項１１】
前記実行宛先タグを書込みアドレスとして使用して、前記実行命令の宛先タイプに対応するリネーム・バッファに実行の結果を書込むステップを更に含む、請求項７に記載の方法。
【請求項１２】
完了時に、完了命令に対する完了宛先タグを前記発行キューおよび前記リネーム・ステージに送るステップを更に含む、請求項１１に記載の方法。
【請求項１３】
前記発行キューにおいて、発行命令のソース宛先タグを前記完了宛先タグと比較するステップと、
前記ソース宛先タグが前記完了宛先タグに一致する場合、前記発行キューにおける前記ソース宛先タグに対応する前記設計されたレジスタ・ビットをアサートするステップと、
を更に含む、請求項１２記載の方法。
【請求項１４】
前記リネーム・ステージにおいて、前記完了宛先タグによって指定されたロケーションにおいて直近命令ビットをセットするステップを更に含む、請求項１２に記載の方法。
【請求項１５】
前記完了宛先タグを使用して前記論理レジスタ・アレイから完了レジスタ・ターゲット・フィールドおよび宛先タイプ・ビットを読出すステップと、
前記完了宛先タグを使用して前記完了命令の宛先タイプに対応するリネーム・バッファから結果を読出すステップと、
前記完了命令の前記宛先タイプに対応する設計されたレジスタに前記結果を書込むステップと、
を更に含む、請求項１２に記載の方法。
【請求項１６】
新たなディスパッチ命令によって使用されるように前記完了宛先タグを割付け解除するステップを更に含む、請求項１５に記載の方法。
【請求項１７】
直近命令ビットを適切な状態に回復するために最も古いフラッシュ宛先タグを前記リネーム・ステージに送るステップと、
前記最も古いフラッシュ宛先タグに同等もしくはそれよりも直近の前記リネーム・ステージにおけるいずれの宛先タグもフラッシュ・アウトするステップと、
を更に含む、請求項１５に記載の方法。
【請求項１８】
ユニバーサル・レジスタ・リネーミング機能を備えたマイクロプロセッサであって、
発行キューと、
リネーム機構と、
複数の実行ユニットと、
完了ロジックと、
を含み、
前記発行キューは前記複数の実行ユニットに命令を発行し、
前記複数の実行ユニットは、命令を実行するための情報を前記発行キューおよび前記リネーム機構に送り、
前記完了ロジックは、完了した命令に関する情報を前記発行キューおよび前記リネーム機構に送り、
前記リネーム機構は、マイクロプロセッサにおいて発行される命令に対する宛先タグを割付け、前記命令に対する宛先タイプを論理レジスタ・アレイにセットし、前記命令の結果が前記宛先タイプに対応するリネーム・バッファに書込まれる場合、前記論理レジスタ・アレイにおけるリネーム・バッファ・ビットをアサートする、
マイクロプロセッサ。
【請求項１９】
前記リネーム機構は、前記命令が、先行の命令に適合するターゲット・レジスタをアクセスするかどうかを決定し、前記命令が、先行の命令に適合するレジスタをアクセスする場合、前記先行の命令に対する宛先を回復リンク・アレイにおける回復リンク・エントリに書込む、請求項１８に記載のマイクロプロセッサ。
【請求項２０】
前記リネーム機構は前記回復リンク・アレイにおけるエントリの有効性を維持する、請求項１９に記載のマイクロプロセッサ。
【請求項２１】
前記リネーム機構は、前記命令が、前記ターゲット・レジスタをアクセスする直近の命令であるということを表すために、前記命令に対する直近命令ビットをアサートする、請求項１９に記載のマイクロプロセッサ。
【請求項２２】
前記リネーム機構は前記先行の命令に対する直近命令ビットをアサート解除する、請求項１９に記載のマイクロプロセッサ。
【請求項２３】
前記発行キューは、発行命令が比較的直近の命令に従属するかどうかを決定し、
前記発行命令が比較的直近の命令に従属しない場合、前記発行キューは前記発行命令に対する前記発行キュー内の設計されたレジスタ・ビットをアサートし、
前記発行命令が比較的直近の命令に従属する場合、前記発行キューは前記発行命令に対する前記発行キュー内の前記設計されたレジスタ・ビットをアサート解除する、
請求項１８に記載のマイクロプロセッサ。
【請求項２４】
アサートされたリネーム・バッファ・ビットを有する発行命令に対して、前記発行キューは、論理レジスタ・ターゲット、１つまたは複数のディスパッチ・ソース・レジスタ・アドレス、宛先タグ、ソース宛先タグ、および前記発行命令に対する設計されたレジスタ・ビットを前記複数の実行ユニット内の対応する実行ユニットに送る、請求項２３に記載のマイクロプロセッサ。
【請求項２５】
前記発行命令に対する前記設計されたレジスタ・ビットがアサートされる場合、前記実行ユニットは、前記１つまたは複数のディスパッチ・ソース・レジスタ・アドレスを読取りアドレスとして使用して、前記発行命令の宛先タイプに対応する設計されたレジスタから１つまたは複数のオペランドを読取り、
前記発行命令に対する前記設計されたレジスタ・ビットがアサート解除される場合、前記実行ユニットは、前記ソース宛先タグを読取りアドレスとして使用して、前記発行命令の宛先タイプに対応するリネーム・バッファから１つまたは複数のオペランドを読取る、
請求項２４に記載のマイクロプロセッサ。
【請求項２６】
前記実行命令の実行時に、前記発行キューは、書込まれるべきオペランドの実行宛先タグを前記発行命令のソース宛先タグに比較し、前記書込まれるべきオペランドの実行宛先タグが前記発行命令のソース宛先タグに一致する場合、前記発行命令に対する発行キューにおけるリネーム・バッファ・ビットをアサートする、請求項２４に記載のマイクロプロセッサ。
【請求項２７】
前記リネーム機構は、前記実行宛先タグによって指定されたロケーションにおける前記論理レジスタ・アレイ内のリネーム・バッファ・ビットをアサートする、請求項２４に記載のマイクロプロセッサ。
【請求項２８】
前記実行ユニットは、前記実行宛先タグを書込みアドレスとして使用して、前記実行命令の宛先タイプに対応するリネーム・バッファに実行の結果を書込む、請求項２４に記載のマイクロプロセッサ。
【請求項２９】
完了時に、前記完了ロジックは、完了命令に対する完了宛先タグを前記発行キューおよび前記リネーム機構に送る、請求項２８に記載のマイクロプロセッサ。
【請求項３０】
前記発行キューは、発行命令のソース宛先タグを前記完了宛先タグと比較し、
前記ソース宛先タグが前記完了宛先タグに一致する場合、前記発行キューにおける前記ソース宛先タグに対応する前記設計されたレジスタ・ビットをアサートする、
請求項２９記載のマイクロプロセッサ。
【請求項３１】
前記リネーム機構は、前記完了宛先タグによって指定されたロケーションにおいて直近命令ビットをセットする、請求項２９に記載のマイクロプロセッサ。
【請求項３２】
前記リネーム機構は、前記完了宛先タグを使用して前記論理レジスタ・アレイから完了レジスタ・ターゲット・フィールドおよび宛先タイプ・ビットを読出し、前記完了宛先タグを使用して前記完了命令の宛先タイプに対応するリネーム・バッファから結果を読出し、前記完了命令の前記宛先タイプに対応する設計されたレジスタに前記結果を書込む、請求項２９に記載のマイクロプロセッサ。
【請求項３３】
前記リネーム機構は、新たなディスパッチ命令によって使用されるよう前記完了宛先タグを割付け解除する、請求項３２に記載のマイクロプロセッサ。
【請求項３４】
前記完了ロジックは、直近命令ビットを適切な状態に回復するために最も古いフラッシュ宛先タグを前記リネーム機構に送り、
前記リネーム機構は、前記最も古いフラッシュ宛先タグに同等もしくはそれよりも直近の前記リネーム機構におけるいずれの宛先タグもフラッシュ・アウトする、
請求項３２に記載のマイクロプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、データ処理システムおよび方法の改良に関するものである。特に、マイクロプロセッサにおける異なる命令タイプを対象としたユニバーサル・レジスタ・リネーム機構に関するものである。
【背景技術】
【０００２】
レジスタ・リネーミングは、命令を順不同で実行させることによってパフォーマンスを高めるために使用されるマイクロプロセッサ設計における一般的な技術である。プログラムは、価値基準に基づいて作用する命令から構成される。命令は、それらを相互に区別するためにこれらの価値に名前をつけなければならない。一般的な命令は、例えば、ＸおよびＹを加算し、結果をＺに入れるというように表わすことができる。この命令では、Ｘ、Ｙ、およびＺは記憶ロケーションの名前である。コンパクトな命令符号化を行うために、ほとんどのプロセッサ命令セットは、直接に命名され得る特別なロケーションの小さいセットを有する。小型のプロセッサでは、これらのロケーションの名前がレジスタ・ファイルの要素に直接相当する。
【０００３】
命令が異なると、かかる時間も異なる。例えば、メイン・メモリからの１回のロードが進行中である間に、プロセッサは何百もの命令を実行することができるであろう。ロードが未決である間に実行される短い命令が最初に終了するであろう。従って、命令はオリジナル・プログラムの順から外れて終了しようとする。最近の高性能ＣＰＵでは、何らかの速度利得を得るために、順不同の実行が使用されている。
【０００４】
順不同のＣＰＵ上で実行されるコードのこの部分を考察すると、
１．レジスタ１をメモリ・ロケーション１０２４からロードする、
２．数値２をレジスタ１に加える、
３．レジスタ１をメモリ・ロケーション１０３２に保存する、
４．レジスタ１をメモリ・ロケーション２０４８からロードする、
５．数値４をレジスタ１に加える、
６．レジスタ１をメモリ・ロケーション２０５６に保存する。
命令４、５、および６は命令１、２、および３とは無関係であるが、命令３が間違った値を書込むことがあるため、プロセッサは、命令３が行われるまで命令４を終わらせることができない。
【０００５】
レジスタ・リネーミングは、幾つかのレジスタの名前を変更することによってこの制限を排除することができる。例えば、
１．レジスタ１をメモリ・ロケーション１０２４からロードする
２．数値２をレジスタ１に加える
３．レジスタ１をメモリ・ロケーション１０３２に保存する
４．レジスタ２をメモリ・ロケーション２０４８からロードする
５．数値４をレジスタ２に加える
６．レジスタ２をメモリ・ロケーション２０５６に保存する
今、命令４、５、および６は命令１、２、および３と並行して行うことができるので、プログラムはより速く実行することができる。
【０００６】
可能な場合、コンパイラはこのリネーミングを行う。コンパイラは、多くの方法で、主に命令セット内のレジスタ名を有限数に規制される。多くの高性能マイクロプロセッサは、更なる並列処理を受けさせるためにハードウェアでレジスタをリネームする。
【０００７】
一般的には、マイクロプロセッサにおける各宛先タイプに対して異なるリネーム構造が必要である。例えば、汎用レジスタ（ＧＰＲ）固定小数点宛先は、浮動小数点レジスタ（ＦＰＲ）宛先とは異なるリネーム構造を必要とするであろう。これらのリネーム構造およびロジックはすべて非常に複雑であり、消費電力およびシリコンのために一般に高価である。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、従来技術の欠点を認識し、マイクロプロセッサにおける種々の命令タイプのターゲットに対して統一されたレジスタ・リネーム機構を提供することにある。本ユニバーサル・リネーム機構は、単一のリネーム構造を使用して種々の命令タイプの宛先をリネームする。従って、浮動小数点レジスタ（ＦＲＰ）を更新する命令は、同じリネーム構造を使って汎用レジスタ（ＧＰＲ）またはベクトル・マルチメディア・エクステンション（ＶＭＸ）命令レジスタ（ＶＲ）を更新する命令と共にリネームされ得る。それは、ＧＰＲに対する設計された状態の数がＦＰＲおよびＶＲに対する設計された状態の数と同じであるためである。各宛先タグ（ＤＴＡＧ）が１つの宛先に割り当てられる。浮動小数点命令がＤＴＡＧに割り当てられ、固定小数点命令が次のＤＴＡＧに割り当てられてもよい。ユニバーサル・リネーム機構の場合、すべての命令タイプに対して唯一のリネーム構造を持つことによって、かなりのシリコンおよび電力を節約することが可能である。
【課題を解決するための手段】
【０００９】
１つの実施例では、ユニバーサル・レジスタ・リネーミングを行うための方法が、マイクロプロセッサにおいて発行される命令に対して宛先タグを割付けるステップと、マイクロプロセッサのリネーム・ステージにおいて命令に対する宛先タイプを論理レジスタ・アレイにセットするステップと、宛先タイプに対応したリネーム・バッファに命令の結果が書込まれる場合、論理レジスタ・アレイにおいてリネーム・バッファ・ビットをアサートするステップとを含む。
【００１０】
本方法の１つの実施例は、更に、命令が、先行の命令と適合するターゲット・レジスタをアクセスするかどうかを決定するステップと、命令が、先行の命令と適合するターゲット・レジスタをアクセスする場合、先行の命令に対する宛先タグを回復リンク・アレイにおける回復リンク・エントリに書込むステップとを含む。本方法の別の実施例は、更に、回復リンク・アレイにおけるエントリの有効性を維持するステップを含む。本方法の更なる実施例は、命令が、ターゲット・レジスタをアクセスする直近の命令であるということを表すためにその命令に対する直近命令ビットをアサートするステップを更に含む。本方法の更なる実施例は、先行の命令に対する直近命令ビットをアサート解除するステップを更に含む。
【００１１】
本方法の更なる実施例は、更に、発行キューにおいて、発行命令が比較的直近の命令に依存するかどうかを決定するステップを含む。本方法の実施例は、更に、発行命令が比較的直近の命令に依存しない場合、その発行命令に対する発行キュー内の設計されたレジスタ・ビットをアサートするステップと、発行命令が比較的直近の命令に依存する場合、その発行命令に対する発行キュー内の設計されたレジスタ・ビットをアサート解除するステップとを含む。
【００１２】
本方法の更なる実施例は、更に、アサートされたリネーム・バッファ・ビットを有する発行命令に対して、論理レジスタ・ターゲット、１つまたは複数のディスパッチ・ソース・レジスタ・アドレス、宛先タグ、ソース宛先タグ、および発行命令に対する設計されたレジスタ・ビットを対応する実行ユニットに送るステップを含む。
【００１３】
本方法の更なる実施例は、発行命令に対する設計されたレジスタ・ビットがアサートされる場合、１つまたは複数のディスパッチ・ソース・レジスタ・アドレスを読取りアドレスとして使って、発行命令の宛先タイプに対応する設計されたレジスタから１つまたは複数のオペランドを読取るステップを更に含む。本方法は、発行命令に対する設計されたレジスタがアサート解除される場合、ソース宛先タグを読取りアドレスとして使って発行命令の宛先タイプに対応するリネーム・バッファから１つまたは複数のオペランドを読取るステップを更に含む。
【００１４】
本方法の更なる実施例は、実行命令の実行時に、書込まれるべきオペランドの実行宛先タグを発行命令のソース宛先タグに比較するステップと、書込まれるべきオペランドの実行宛先タグが発行命令のソース宛先タグに一致する場合、発行命令に対する発行キューにおけるリネーム・バッファ・ビットをアサートするステップとを更に含む。本方法の更に別の実施例は、リネーム・ステージにおいて、実行宛先タグによって指定されたロケーションにおける論理レジスタ・アレイ内のリネーム・バッファ・ビットをアサートするステップを含む。
【００１５】
本方法の別の実施例は、実行宛先タグを書込みアドレスとして使用して、実行命令の宛先タイプに対応するリネーム・バッファに実行の結果を書込むステップを更に含む。本方法更なる実施例は、完了時に、完了命令に対する完了宛先タグを発行キューおよびリネーム・ステージに送るステップを更に含む。本方法の更なる実施例は、発行キューにおいて、発行命令のソース宛先タグを完了宛先タグと比較するステップと、ソース宛先タグが完了宛先タグと一致する場合、発行キューにおけるソース宛先タグに対応する設計されたレジスタ・ビットをアサートするステップを更に含む。本方法の更なる実施例は、リネーム・ステージにおいて、完了宛先タグによって指定されたロケーションにおいて直近の命令ビットをセットするステップを更に含む。
【００１６】
本方法の更なる実施例は、完了宛先タグを使用して論理レジスタ・アレイから完了レジスタ・ターゲット・フィールドおよび宛先タイプ・ビットを読出すステップと、完了宛先タグを使用して完了命令の宛先タイプに対応するリネーム・バッファから結果を読出すステップと、完了命令の宛先タイプに対応する設計されたレジスタにその結果を書込むステップとを更に含む。
【００１７】
本方法の更なる実施例は、新たなディスパッチ命令によって使用されるように完了宛先タグを割付け解除するステップを更に含む。本方法の更なる実施例は、直近の命令ビットを適切な状態に回復するために最も古いフラッシュ宛先タグをリネーム・ステージに送るステップと、最も古いフラッシュ宛先タグに同等またはそれよりも直近のそのリネーム・ステージにおけるいずれの宛先タグもフラッシュ・アウトするステップとを更に含む。
【００１８】
本発明の別の実施例では、ユニバーサル・レジスタ・リネーミング機能を備えたマイクロプロセッサが発行キュー、リネーム機構、複数の実行ユニット、および完了ロジックを含む。発行キューは、複数の実行ユニットに命令を発行する。複数の実行ユニットは、命令を実行するための情報を発行キューおよびリネーム機構に送る。完了ロジックは、完了した命令に関する情報を発行キューおよびリネーム機構に送る。リネーム機構は、マイクロプロセッサにおいて発行される命令に対する宛先タグを割付け、命令に対する宛先タイプを論理レジスタ・アレイにセットし、命令の結果が宛先タイプに対応するリネーム・バッファに書込まれる場合、論理レジスタ・アレイにおけるリネーム・バッファ・ビットをアサートする。
【００１９】
１つの実施例では、リネーム機構は、命令が先行の命令と適合するターゲット・レジスタをアクセスするかどうかを決定し、命令が、先行の命令に適合するレジスタをアクセスする場合、先行の命令に対する宛先タグを回復リンク・アレイにおける回復リンク・エントリに書込む。更なる実施例では、リネーム機構は、回復リンク・アレイにおけるエントリの有効性を維持する。更なる実施例では、リネーム機構は、命令が、ターゲット・レジスタをアクセスする直近の命令であるということを表すためにその命令に対する直近命令ビットをアサートする。別の実施例では、リネーム機構は、先行の命令に対する直近命令ビットをアサート解除する。
【００２０】
別の実施例では、発行キューは、発行命令が比較的直近の命令に従属するかどうかを決定する。発行命令が比較的直近の命令に従属しない場合、発行キューは、発行命令に対する発行キュー内の設計されたレジスタ・ビットをアサートする。発行命令が比較的直近の命令に従属する場合、発行キューは、発行命令に対する発行キュー内の設計されたレジスタ・ビットをアサート解除する。
【００２１】
別の実施例では、アサートされたリネーム・バッファ・ビットを有する発行命令に対して、発行キューは、論理レジスタ・ターゲット、１つまたは複数のディスパッチ・ソース・レジスタ・アドレス、宛先タグ、ソース宛先タグ、および発行命令に対する設計されたレジスタ・ビットを複数の実行ユニット内の対応する実行ユニットに送る。
【００２２】
更なる実施例では、発行命令に対する設計されたレジスタ・ビットがアサートされる場合、実行ユニットは、１つまたは複数のディスパッチ・ソース・レジスタ・アドレスを読取りアドレスとして使用して、発行命令の宛先タイプに対応する設計されたレジスタから１つまたは複数のオペランドを読取る。発行命令に対する設計されたレジスタ・ビットがアサート解除される場合、実行ユニットは、ソース宛先タグを読取りアドレスとして使用して、発行命令の宛先タイプに対応するリネーム・バッファから１つまたは複数のオペランドを読取る。
【００２３】
更なる実施例では、実行命令の実行時に、発行キューは、書込まれるべきオペランドの実行宛先タグを発行命令のソース宛先タグに比較し、書込まれるべきオペランドの実行宛先タグが発行命令のソース宛先タグに一致する場合、発行命令に対する発行キューにおけるリネーム・バッファ・ビットをアサートする。
【００２４】
別の実施例では、リネーム機構は、実行宛先タグによって指定されたロケーションにおける論理レジスタ・アレイ内のリネーム・バッファ・ビットをアサートする。
【００２５】
１つの実施例では、実行ユニットは、実行宛先タグを書込みアドレスとして使用して、実行命令の宛先タイプに対応するリネーム・バッファに実行の結果を書き込む。更なる実施例では、完了時に、完了ロジックは、完了命令に対する完了宛先タグを発行キューおよびリネーム機構に送る。更なる実施例では、発行キューは、発行命令のソース宛先タグを完了宛先タグと比較し、ソース宛先タッグが完了宛先タグに一致する場合、発行キューにおけるソース宛先タグに対応する設計されたレジスタ・ビットをアサートする。
【００２６】
別の実施例では、リネーム機構は完了宛先タグによって指定されたロケーションにおいて直近命令ビットをセットする。
【００２７】
別の実施例では、リネーム機構は、完了宛先タグを使用して論理レジスタ・アレイから完了レジスタ・ターゲット・フィールドおよび宛先タイプ・ビットを読出し、完了宛先タグを使用して完了命令の宛先タイプに対応するリネーム・バッファから結果を読出し、完了命令の宛先タイプに対応する設計されたレジスタにその結果を書込む。更なる実施例では、リネーム機構は、新たなディスパッチ命令によって使用されるように完了宛先タグを割付け解除する。
【００２８】
更なる実施例では、完了ロジックは、直近命令ビットを適切な状態に回復させるために、最も古いフラッシュ宛先タグをリネーム機構に送る。リネーム機構は、最も古いフラッシュ宛先タグに同等またはそれよりも直近のそのリネーム機構におけるいずれの宛先タグもフラッシュ・アウトする。
【００２９】
本発明のこれらの並びに他の特徴および利点は、本発明の実施例に関する下記の詳細な記載において説明される。
【発明を実施するための最良の形態】
【００３０】
図面、特に、図１および図２を参照すると、本発明の実施例を具現化し得るデータ処理環境の概略図が示される。図１および図２が単なる例示であること、並びに、本発明の諸態様および実施例を具現化し得る環境に関して如何なる限定の主張または示唆することを意図するものでもないということは理解されるべきである。本発明の趣旨および範囲から逸脱することなく、図示の環境に対する多くの修正を施すことが可能である。
【００３１】
図１を参照すると、本発明を具現化し得るデータ処理システムの概略図が実施例に従って示される。システム・ユニット１０２、ビデオ・ディスプレイ端末１０４、キーボード１０６、フロッピー（登録商標）・ドライブおよび他のタイプの永続的および取外し可能記憶媒体を含み得る記憶装置１０８、並びにマウス１１０を含むコンピュータ１００が示される。パーソナル・コンピュータ１００は、例えば、ジョイスティック、タッチパッド、タッチ・スクリーン、トラックボール、マイクロホン等のような更なる入力装置を含み得る。コンピュータ１００は、米国ニューヨーク州アーモンクにあるインターナショナル・ビジネス・マシーンズ・コーポレーション（ＩＢＭ社）の製品である IBM eServer コンピュータまたはIntelliStation コンピュータのような任意の適切なコンピュータを使用して具現化し得る。図示されたものは１つのコンピュータを示すが、ネットワーク・コンピュータのような他のタイプのデータ処理システムにおいて本発明の別の実施例を具現化することも可能である。望ましくは、コンピュータ１００は、オペレーション時にコンピュータ可読媒体に常駐するシステム・ソフトウェアを用いて具現化し得るグラフィカル・ユーザ・インターフェース（ＧＵＩ）を更に含む。
【００３２】
図２を参照すると、実施例の諸局面を具現化し得る例示的なデータ処理システムのブロック図が示される。データ処理システム２００は、本発明の実施例の例示的な諸局面を実施し得る図１のコンピュータ１００のようなコンピュータの一例である。
【００３３】
図示の例では、データ処理システム２００は、ノース・ブリッジおよびメモリ・コントローラ・ハブ（ＮＢ／ＭＣＨ）２０２と、サウス・ブリッジおよび入出力（Ｉ／Ｏ）コントローラ・ハブ（ＳＢ／ＩＣＨ）２０４とを含むハブ・アーキテクチャを使用する。処理ユニット２０６、メイン・メモリ２０８、およびグラフィックス・プロセッサ２１０が、ＮＢ／ＭＣＨ２０２に接続される。グラフィックス・プロセッサ２１０は、アクセラレイテッド・グラフィックス・ポート（ＡＧＰ）を介してＮＢ／ＭＣＨ２０２に接続されてもよい。
【００３４】
図示の例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２が、ＳＢ／ＩＣＨ２０４に接続している。オーディオ・アダプタ２１６、キーボードおよびマウス・アダプタ２２０、モデム２２２、読取り専用メモリ（ＲＯＭ）２２４、ハードディスク・ドライブ（ＨＤＤ）２２６、ＣＤ−ＲＯＭドライブ２３０、ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよび他の通信ポート２３２、並びに、ＰＣＩ／ＰＣＩｅ装置２３４がバス２３８およびバス２４０を介してＳＢ／ＩＣＨ２０４に接続している。ＰＣＩ／ＰＣＩｅ装置２３４は、例えば、イーサネット（登録商標）・アダプタ、アドイン・カード、および、ノート型コンピュータ用のＰＣカードを含み得る。ＰＣＩはカード・バス・コントローラを使用するが、ＰＣＩｅはそれを使用しない。ＲＯＭ２２４は、例えば、フラッシュ・ベーシック入出力システム（ＢＩＯＳ）であってもよい。
【００３５】
ハードディスク・ドライブ（ＨＤＤ）２２６およびＣＤ−ＲＯＭドライブ２３０はバス２４０を介してＳＢ／ＩＣＨ２０４に接続している。ハードディスク・ドライブ２２６およびＣＤ−ＲＯＭドライブ２３０は、例えば、統合ドライブ・エレクトロニクス（ＩＤＥ）またはシリアル・アドバンスト・テクノロジ・アタッチメント（ＳＡＴＡ）インターフェースを使用し得る。スーパーＩ／Ｏ（ＳＩＯ）装置２３６がＳＢ／ＩＣＨ２０４に接続されてもよい。
【００３６】
オペレーティング・システムが処理ユニット２０６上で作動する。オペレーティング・システムは、図２におけるデータ処理システム２００内の種々のコンポーネントの制御を調整および提供する。クライアントとしてのオペレーティング・システムは、Microsoft Windows XPのような市販のオペレーティング・システムであってもよい(Microsoft およびWindows は、米国のマイクロソフト社（Microsoft Corporation）の商標である)。Java（商標）プログラミング・システムのようなオブジェクト指向プログラミング・システムが、オペレーティング・システムと関連して作動し得るし、データ処理システム２００上で実行されるJavaプログラムまたはアプリケーションからオペレーティング・システムへの呼び出しを行ない得る（Javaは、米国のサン・マイクロシステムズ社（Sun Microsystems Inc.）の商標である）。
【００３７】
サーバのようなオペレーティング・システム２００は、例えば、アドバンスト・インタラクティブ・エグゼクティブ（ＡＩＸ）オペレーティング・システムまたはＬＩＮＵＸオペレーティング・システムを作動する IBM eServer pSeries コンピュータ・システムであってもよい（eServer、pSeries、およびＡＩＸはＩＢＭ社の商標であり、ＵＮＩＸは米国のLinus Torvalds の商標である）。データ処理システム２００は、プロセッサ・ユニット２０６内に複数のプロセッサを含む対称マルチプロセッサ（ＳＭＰ）システムであってもよい。代替として、シングル・プロセッサ・システムが使用されてもよい。
【００３８】
オペレーティング・システム、オブジェクト指向プログラミング・システム、および、アプリケーションまたはプログラムのための命令は、ＨＤＤ２２６のような記憶装置に置かれ、処理ユニット２０６による実行のためにメイン・メモリ２０８にロードされ得る。本発明の実施例のプロセスは、例えば、メイン・メモリ２０８、ＲＯＭ２２４のようなメモリ、或いは、１つまたは複数の周辺装置に置かれているコンピュータ使用可能プログラム・コードを使って処理ユニット２０６によって遂行されてもよい。
【００３９】
図２に示されるバス２３８またはバス２４０のようなバス・システムは１つまたは複数のバスで構成されてもよい。もちろん、バス・システムは、種々のコンポーネントまたは装置の間のデータ転送に備えた任意のタイプの通信ファブリックまたはアーキテクチャを使用して具現化することが可能である。図２のモデム２２２或いはネットワーク・アダプタ２１２のような通信ユニットは、データを送受信するために使用される１つまたは複数の装置を含み得る。メモリは、例えば、メイン・メモリ２０８、ＲＯＭ２２４、または、図２におけるＮＢ／ＭＣＨ２０２において見られるようなキャッシュであってもよい。
【００４０】
図１および図２におけるハードウェアが具現化方法次第で変わり得るということは当業者には明らかであろう。フラッシュ・メモリ、同等の不揮発性メモリ、または光ディスク・ドライブ等ような他の内部ハードウェア或いは周辺装置が、図１および図２に示されたハードウェアに加えて或いはそのハードウェアの代わりに使用されてもよい。更に、実施例のプロセスは、本発明の趣旨および範囲から逸脱することなく、前述のＳＭＰシステムとは別のマルチプロセッサ・データ処理システムに適用することも可能である。
【００４１】
更に、データ処理システム２００は、クライアント・コンピューティング装置、サーバ・コンピューティング装置、タブレット・コンピュータ、ラップトップ・コンピュータ、電話または他の通信装置、パーソナル・デジタル・アシスタント（ＰＤＡ）等を含む、任意の多種のデータ処理システムの形式を取り得る。或る例では、データ処理システム２００は、例えば、オペレーティング・システム・ファイルおよび／またはユーザ生成データを格納するための不揮発性メモリを提供するためにフラッシュ・メモリによって構成されるポータブル・コンピューティング装置であってもよい。本質的には、データ処理システム２００は、アーキテクチャ上の制限のない任意の既知のまたは今後開発されるデータ処理システムであってもよい。
【００４２】
実施例では、処理ユニット２０６はユニバーサル・レジスタ・リネーム機構を有するマイクロプロセッサであってもよい。ユニバーサル・リネーム機構は、単一のリネーム構造を使用して種々の命令タイプの宛先をリネームする。従って、浮動小数点レジスタ（ＦＰＲ）を更新する命令は、同じリネーム構造を使って汎用レジスタ（ＧＰＲ）またはベクトル・マルチメディア・エクステンション（ＶＭＸ）命令レジスタ（ＶＲ）を更新する命令と共にリネームすることが可能である。これは、ＧＰＲに対する設計された状態の数がＦＰＲおよびＶＲに対する設計された状態の数と同じであるためである。各宛先タグ（ＤＴＡＧ）が１つの宛先に割り当てられる。浮動小数点命令は、ＤＴＡＧに割り当てることが可能であり、固定小数点命令は次のＤＴＡＧに割り当てることが可能である。ユニバーサル・リネーム機構の場合、すべての命令タイプに対して１つのリネーム構造しか持たないことによって、かなりのシリコンおよび電力を節約することができる。
【００４３】
図３は、実施例に従って、ユニバーサル・レジスタ・リネーム機構を有するマイクロプロセッサの一部を示すブロック図である。このマイクロプロセッサは、例えば、図２における処理ユニット２０６であってもよい。マイクロプロセッサは、命令デコードおよび発行ロジック３１０を含み、そのロジック３１０は、命令を受け取り、命令をデコードし、命令を実行ユニット３１２、３１４、３１６に発行する。１つの実施例では、実行ユニット３１２、３１４、３１６は異なる命令タイプを実行し得る。例えば、実行ユニット３１２は汎用命令を実行し得るし、実行ユニット３１４は浮動小数点命令を実行し得るし、実行ユニット３１６はベクトル・マルチメディア・エクステンション（ＶＭＸ）命令を実行し得る。ユニバーサル・リネーム機構３５０は、単一のリネーム構造を使用して、種々の命令タイプの宛先をリネームする。
【００４４】
バス３２２は実行ユニット３１２〜３１６をレジスタ・ファイル３２０に接続する。バス３３２は実行ユニット３１２〜３１６をメモリ３３０にも接続する。メモリ３３０は、プロセッサの内部にあるキャッシュ・メモリのような読取り専用メモリ（ＲＯＭ）であってもよい。これとは別に、メモリ３３０はシステム・メモリのようなプロセッサの外部にあってもよい。図３は、実行ユニット３１２〜３１６をレジスタ・ファイル３２０およびメモリ３３０に接続する共用バス３２２および３３２を示すが、他の実施例では、各実行ユニットがレジスタ・ファイル３２０およびメモリ３３０に対するそれ自身の独立した接続体を持ち得るということも明らかであろう。
【００４５】
実行ユニット３１２〜３１６は命令デコードおよび発行ロジック３１０およびユニバーサル・リネーム機構３５０に接続している。実行ユニット３１２〜３１６が命令の実行を終了するとき、更に詳細に後述するように、それらは、情報を更新するために情報を命令デコードおよび発行ロジック３１０およびユニバーサル・リネーム機構３５０に返送し得る。完了ロジック３４０は、命令をフラッシュするというような命令実行の完了を処理する。完了ロジック３４０は命令デコードおよび発行ロジック３１０およびユニバーサル・リネーム機構３５０に接続している。完了時に、完了ロジック３４０は、更に詳細に後述するように、情報を更新するために情報を命令デコードおよび発行ロジック３１０およびユニバーサル・リネーム機構３５０に返送し得る。
【００４６】
図４は、実施例に従ってレジスタ・リネーム機構のデータ・フローを示す。固定小数点ユニット（ＦＸＵ）命令は汎用レジスタ（ＧＰＲ）を更新することができる。浮動小数点ユニット（ＦＰＵ）命令は浮動小数点レジスタ（ＦＰＲ）を更新することができる。ベクトル・マルチメディア・エクステンション（ＶＭＸ）命令はＶＭＸレジスタを更新することができる。
【００４７】
宛先タグ（ＤＴＡＧ）は、命令がどの物理レジスタに結果を書込み得るかを示すために、各命令に対するディスパッチ時に割付けられる。ＤＴＡＧは、特定の論理レジスタ（ＬＲ）４０２のリネームされたレジスタを表す。ＤＴＡＧは、ディスパッチ時に逐次に割付けられ、完了時に割付け解除される。論理レジスタ（ＬＲ）４０２は、命令の設計された宛先レジスタ、即ち、レジスタ・ターゲット（ＲＴ）である。ＬＲは、完了時に結果を書くために、レジスタ・ファイルへの書込みアドレスとして使用される。
【００４８】
論理レジスタ４０２における各エントリは、宛先タイプＧＰＲビット（ＧＲ）、宛先タイプＦＰＲビット（ＦＲ）、および宛先タイプＶＲビット（ＶＲ）を含む。ＧＲビットは、それがアクティブであるとき、ＤＴＡＧがＦＸＵ命令（ＧＰＲを更新する）に割り当てられるということを表わす。ＦＲビットは、それがアクティブであるとき、ＤＴＡＧがＦＰＲ命令（ＦＰＲを更新する）に割り当てられるということを表わす。ＶＲビットは、それがアクティブであるとき、ＤＴＡＧがＶＭＸ命令（ＶＲを更新する）に割り当てられるということを表わす。
【００４９】
Ｙビット４０６は、どのＤＴＡＧが、特定の宛先レジスタ（ＲＴ）を更新するための直近の命令であるか、を表す。同じＲＴフィールドを更新する必要がある複数の命令が存在するとき、直近の命令だけがこのビットを１にアサートさせることを許される。Ｙビット４０６がアサートされるとき、いずれの新しい従属の命令もこの特定のＤＴＡＧを待つであろうし、アサート解除されたＹビット４０６を有する他のすべての命令を無視するであろう。各ＤＴＡＧロケーションに対して１つのＹビット４０６が存在するであろう。この共通のＹビットはすべての命令タイプによって使用される。Ｙ＝１および宛先タイプＧＰＲ＝１の場合、ＤＴＡＧはＦＸＵ命令に属する。Ｙ＝１および宛先タイプＦＰＲ＝１の場合、ＤＴＡＧはＦＰＵ命令に属する。Ｙ＝１および宛先タイプＶＲ＝１の場合、ＤＴＡＧはＶＭＸ命令に属する。
【００５０】
Ｗビット４１０は、ＲＴが特定のＤＴＡＧにリネームされるということを表わす。Ｗ＝０およびＹ＝１である場合、結果がリネーム・バッファ４２２、４３２、或いは４４２に書込まれる。Ｗ＝１である場合、結果が、リネーム・バッファ４２２、４３２、或いは４４２に既に書込まれている。
【００５１】
回復リンク４０８は、ディスパッチ命令と同じＲＴを更新する先行の命令のためのＤＴＡＧおよびＶビットを含む。回復リンク４０８は、フラッシュされた命令と同じＲＴロケーションを更新する前の未フラッシュＤＴＡＧに対するＹビットの回復のために使用される。Ｖビットは、回復リンク４０８におけるエントリが有効であること、即ち、このエントリにおけるＤＴＡＧが依然としてリネームされた状態にあることを表わす。
【００５２】
ＧＰＲリネーム・バッファ４２２、ＦＰＲリネーム・バッファ４３２、およびＶＲリネーム・バッファ４４２は、命令の完了時に、設計された機構へ送られる前の一時的結果を保持するためのレジスタ・セットを形成する。ＧＰＲ、ＦＰＲ、およびＶＲに対して、通常、ＤＴＡＧ（０乃至Ｎ）当たり１つのリネーム・バッファ・エントリが存在する。
【００５３】
更に詳しく後述するように、比較ロジック４０４は、新たにディスパッチされたＤＴＡＧがＹビットを更新するための特定タイプの比較的直近の命令であるかどうか、実行された命令がＹビットを読み出すためのソースＤＴＡＧと一致するかどうかを決定するためにＤＴＡＧを比較する。
【００５４】
図示の例では、命令タイプは、固定小数点命令（ＦＸＵ）、浮動小数点命令（ＦＰＵ）およびベクトル・マルチメディア・エクステンション（ＶＭＸ）命令である。レジスタ・タイプは、それぞれ、汎用レジスタ（ＧＰＲ）４２４、浮動小数点レジスタ（ＦＰＲ）４３４、およびＶＭＸレジスタ（ＶＲ）４４４である。しかし、命令タイプおよびレジスタ・タイプが具現化態様に依存して変わり得るということは当業者には明らかであろう。更に、ユニバーサル・リネーム機構は、もっと多くの命令タイプまたはもっと少ない命令タイプも処理し得る。本発明の趣旨および範囲内でべつの修正を行うことも可能である。
【００５５】
発行キュー（図示されてない）では、Ａビットは、Ａ＝１である場合、結果が設計されたレジスタ内にあることを表す。Ａ＝０である場合、結果はリネーム済み状態にある。発行キューにおける各ＤＴＡＧロケーションに対して１つのＡビットが存在するであろう。この共通のＡビットはすべての命令タイプによって使用される。Ａ＝１および宛先タイプＧＰＲ（Destination_type_GPR）＝１である場合、ＤＴＡＧはＦＸＵ命令に属する。Ａ＝１および宛先タイプＦＰＲ（Destination_type_FPR）＝１である場合、ＤＴＡＧはＦＰＵ命令に属する。Ａ＝１および宛先タイプＶＲ（Destination_type_VR）＝１である場合、ＤＴＡＧはＶＭＸ命令に属する。
【００５６】
初期リネーム状態に対して、論理レジスタ・アレイ４０２におけるＲＴフィールドが０にセットされ、Ｙビット４０６が０にセットされ、すべてのＷビット４１０が０にセットされ、回復リンク４０８におけるＶビットが０にセットされる。リネーム構造は、ＤＴＡＧ先頭ポインタ（図示されていない）およびＤＴＡＧ末尾ポインタ（図示されていない）によって管理されることも可能である。ＤＴＡＧ先頭ポインタは最も古い未完了のＤＴＡＧを指す。ＤＴＡＧはディスパッチ時に順次に割付けられ、完了時に割付け解除される。フリーＤＴＡＧの数は、ＤＴＡＧ先頭ポインタおよびＤＴＡＧ末尾ポインタの状態を調べることによって決定することが可能である。
【００５７】
ディスパッチ時に、先頭／末尾ポインタ・ロジック（図示されていない）は、ディスパッチ命令に割り当てるために利用し得るＤＴＡＧの数を決定することができる。すべてのＤＴＡＧが既に命令に割付けられている場合、ディスパッチは停止し、ＤＴＡＧが利用可能になるのを待たなければならない。割付けられるべき利用可能なＤＴＡＧが存在する場合、ディスパッチ・ロジックがディスパッチ命令にＤＴＡＧを割付ける。新たに割付けられたＤＴＡＧは、ＤＴＡＧ先頭ポインタ・プラスＮから得ることができる。この場合、０〜Ｎは利用可能なＤＴＡＧを表す。ＤＴＡＧをディスパッチ命令に割付けた後、ＤＴＡＧ先頭ポインが次のフリーＤＴＡＧに進められる。
【００５８】
フラッシュ時、ＤＴＡＧ先頭ポインタが、最も古い未フラッシュＤＴＡＧプラス１の位置に戻らなければならない。言い換えれば、ＤＴＡＧ先頭ポインタは、割付けられるべき次のフリーＤＴＡＧに戻らなければならない。フラッシュ時に、フラッシュＤＴＡＧ（flush_DTAG）（そのフラッシュＤＴＡＧ（Destination_type_VR）に同等或いはそれよりも比較的直近の任意のＤＴＡＧ）が先頭／末尾ポインタ管理ロジックに送られる。しかる後、フラッシュＤＴＡＧ（Destination_type_VR）は、現在のＤＴＡＧ先頭ポインタを新しいＤＴＡＧ先頭ポインタとして置換する。
【００５９】
完了時に、ＤＴＡＧ末尾ポインタは、完了ＤＴＡＧを割付け解除するために前進しなければならない。完了時に、完了ＤＴＡＧのカウントが先頭／末尾管理ロジックに送られる。ＤＴＡＧ末尾ポインタ・ロジックは完了ＤＴＡＧのカウントに基づいて前進（割付け解除）するであろう。例えば、４つのＤＴＡＧが完了するものであった場合、ＤＴＡＧ末尾ポインタは、これらに４つのＤＴＡＧを割付け解除するために４スロットだけ前進するであろう。
【００６０】
図５は、実施例に従って命令に関するディスパッチ時の、ユニバーサル・リネーム機構を有するマイクロプロセッサのオペレーションを示すフローチャートである。フローチャートのブロックが、指定された機能を遂行する手段の組合せおよび指定された機能を遂行するためのステップの組合せを支援する、ということは言うまでもないであろう。フローチャートの各ブロックおよびフローチャートにおけるブロックの組合せが、指定された機能或いはステップを遂行する特殊目的のハードウェア・ベースのコンピュータ・システムによって具現化され得るということも云うまでもないであろう。
【００６１】
更に、フローチャートは、実施例において遂行されるオペレーションを示すために提供される。フローチャートは、特定のオペレーションに関する限定、特に、オペレーションの順序に関する限定を表すことまたは示唆することを意味するものではない。フローチャートのオペレーションは、本発明の趣旨および範囲から逸脱することなく、特定の実施態様に適するように修正されてもよい。
【００６２】
図５を参照すると、オペレーションが開始し、マイクロプロセッサが、宛先（例えば、ＧＰＲ、ＦＰＲ、またはＶＲ）を更新する命令に対して宛先タグ（ＤＴＡＧ）を割り付ける（ステップ５０２）。マイクロプロセッサは、１つの宛先当たり１つのＤＴＡＧを割り付ける。マイクロプロセッサは、その割り付けられたＤＴＡＧを使って、ディスパッチ命令の宛先レジスタ・フィールドまたはレジスタ・ターゲット（ＲＴ）フィールドを論理レジスタ・アレイに書込む（ブロック５０４）。同じロケーションにおいて、マイクロプロセッサはその命令に対する宛先タイプをセットする（ブロック５０６）。例えば、マイクロプロセッサは、命令がＦＸＵ命令である場合、宛先タイプＧＰＲ（Destination_type_GPR）を１にセットし、命令がＦＰＵ命令である場合、宛先タイプＦＰＲ（Destination_type_FPR）を１にセットし、或いは、命令がＶＭＸ命令である場合、宛先タイプＶＲ（Destination_type_VR）を１にセットする。図示の例では、１つのＤＴＡＧ当たり１つ宛先タイプ・ビットしかアクティブになり得ない。
【００６３】
ＤＴＡＧロケーションにおいて、マイクロプロセッサはＷ＝０およびＹ＝１をセットする（ブロック５０８）。Ｗ＝０をセットすることは、結果がリネーム・バッファにまだ書込まれていないことを表す。Ｙ＝１をセットすることは、命令が、特定のＲＴロケーションを更新する直近の命令であることを表す。
【００６４】
マイクロプロセッサは、ＲＴのディスパッチを使用して論理レジスタ・アレイにおけるすべてのエントリを比較する（ブロック５１０）。マイクロプロセッサは、命令タイプが一致するかどうか決定する（ブロック５１２）。命令タイプが一致する（例えば、ディスパッチ命令がＦＸＵ命令であり、宛先タイプＧＰＲ（Destination_type_GPR）＝１である）場合、一致したロケーションにおいて、マイクロプロセッサは、その一致したＤＴＡＧを、回復リンク・アレイにおけるディスパッチＤＴＡＧによって指摘されたロケーションに保存する（ブロック５１４）。更に、ブロック５１４では、このロケーションに保存されたＤＴＡＧが依然としてリネーム状態であるということを表すために、マイクロプロセッサは、回復リンク・アレイにおけるこのロケーションにＶ＝１をセットする。従って、新たなディスパッチＤＴＡＧは、それを用いて、同じＲＴロケーションを更新する先行のＤＴＡＧへのリンクを所持するであろう。更に、一致したロケーションにおいて、マイクロプロセッサは、その一致したロケーションにおけるＤＴＡＧが、最早、このＲＴを更新する直近の命令ではない、ということを表すためにＹ＝０にリセットする（ブロック５１６）。
【００６５】
しかる後、または、ブロック５１２において命令タイプが一致しない場合、マイクロプロセッサは、ディスパッチ・ソース・レジスタ（ＲＡ、ＲＢ、ＲＣ）を使って論理レジスタ・アレイ（５１８を閉鎖する）におけるすべてのエントリと比較させる（ブロック５１８）。マイクロプロセッサは、命令タイプが一致するかどうか決定する（ブロック５２０）。命令タイプが一致する場合（例えば、ディスパッチ命令がＦＸＵであり、宛先タイプＧＰＲ（Destination_type_GPR）＝１である場合）、Ｙ＝１を有する一致したロケーションにおいて、マイクロプロセッサは、「ヒット・ソースＤＴＡＧ（hitsource_DTAG）」を形成するように比較の結果をエンコードする（ブロック５２２）。次に、マイクロプロセッサは発行キューにその結果を送る（ブロック５２４）。ソースＤＴＡＧ（source_DTAG）は、ＲＡ／ＲＢが依存する古い命令のＤＴＡＧである。Ｙ＝１を有するＲＴフィールドは１つしか存在しないので、ＲＡまたはＲＢ当たりの一致した比較は１つしか存在しないということに留意されたい。比較の残りは一致しないであろう。従って、ＲＡまたはＲＢに関して、比較の結果は、「ソースＤＴＡＧ（source_DTAG）」を形成するようにエンコードされ得る「ホット１」フィールドになるであろう。
【００６６】
しかる後、または、ブロック５２０において命令タイプが論理レジスタ・アレイにおける別の命令と一致しない場合、マイクロプロセッサは、ディスパッチＤＴＡＧ、ソースＤＴＡＧ（source_DTAG）、Ｗビット、およびＡビットを発行キューに送る（ブロック５２６）。次に、命のディスパッチが終了し、オペレーションは図６に進む。図６に関しては更に詳細に後述される。
【００６７】
次の情報、即ち、Ｗビット、ディスパッチＤＴＡＧ（これは、結果が書込まれる宛先である）、ノーヒット・インジケータが発行キューに送られる。一致（ヒット）の場合、ソースＤＴＡＧ（source_DTAG）が発行キューに送られるので、命令は、リネーム・バッファから読取るべきロケーションを知ることができる。不一致（ノーヒット）の場合、データは設計されたレジスタにあるので、ソースＤＴＡＧ（source_DTAG）は「無配慮（don’t care）」値である
【００６８】
図６および図７は、実施例に従って、リネーム・バッファを有するマイクロプロセッサの発行キューのオペレーションを示すフローチャートである。図６を参照すると、オペレーションが開始し、リネーム・ステージから来るノーヒット（no-hit）・インジケータが１であるかどうかを発行キュー・ロジックが決定する（ブロック６０２）。ノーヒット・インジケータが１である場合、発行キュー・ロジックは発行キューにおけるＡビットおよびＷビットを１にセットする（ブロック６０４）。これは、命令が如何なる古い命令にも依存しないのでその命令が発行される準備ができていることを表し、オペランドは、設計されたレジスタから得ることが可能である。
【００６９】
ＷビットおよびＡビットの両方が１であることがある。例えば、Ｗビットは発行のための命令を選ぶために使用することができるが、Ａビットはデータのロケーション（リネーム・レジスタまたは設計されたレジスタのいずれかにおけるロケーション）を決定するために使用することができる。例えば、Ｗ＝０である場合、命令は発行のために選択され得ない。Ｗ＝１およびＡ＝０である場合、命令は発行され得るが、データはリネーム・バッファに書込まれる。Ｗ＝１およびＡ＝１である（これは、古い命令が既に完了しているが、従属の命令が最近ディスパッチされたか或いは依然として発行キュー内に残っていて発行されるのを待っているときに起こり得る）場合、命令は発行され得るが、データは設計されたレジスタにある。ブロック６０２においてノーヒット・インジケータが０である場合、発行キュー・ロジックがＡ＝０をセットし、リネーム・ステージから得られたＷビットを発行キューに書込む（ブロック６０６）。
【００７０】
ブロック６０４またはブロック６０６の後、発行キューは、実行ユニットから生じたＤＴＡＧをスヌープする（ブロック６０８）。マイクロプロセッサは、Ｗ＝１であるかどうかを決定する（ブロック６１０）。発行キューは、Ｗ＝１であるとき、命令を発行することができる。Ｗ＝１である場合、発行キュー・ロジックは命令を発行し、オペレーションは、更に詳細に後述される図７に進む。
【００７１】
ブロック６１０においてＷ＝０である場合、マイクロプロセッサは、実行ＤＴＡＧがソースＤＴＡＧ（source_DTAG）と一致するかどうか、および命令タイプが一致するかどうかを決定する（ブロック６１２）。実行ＤＴＡＧがソースＤＴＡＧ（source_DTAG）と一致し且つ命令タイプが一致する場合（ディスパッチ命令がＦＸＵ命令であり、宛先タイプＧＰＲ（Destination_type_GPR）＝１である場合）、一致したロケーションにおいて、マイクロプロセッサはＷ＝１をセットし（ブロック６１６）、オペレーションが更に詳細に後述される図７のブロック６１８に進む。ブロック６１２において、実行ＤＴＡＧがソースＤＴＡＧ（source_DTAG）と一致しないか、または命令タイプが一致しない場合、発行キュー・ロジックは命令を発行せず（ブロック６１４）、オペレーションはブロック６０８に戻る。
【００７２】
次に図７を参照すると、発行ステージにおいて、発行ロジックは、論理ＲＴ、ＲＡ、ＲＢ、ＤＴＡＧ、ソースＤＴＡＧ（source_DTAG）、およびＡビットを、発行命令と共に適切な実行ユニットに送る（ブロック６１８）。
【００７３】
ＧＰＲに関しては、ブロック６２０においてＷ＝１である場合、マイクロプロセッサは、ソースＤＴＡＧ（source_DTAG）を読取りアドレスとして使用してＧＰＲリネーム・バッファからオペランドを読取る（ブロック６２２）。しかる後、オペレーションは終了する。ブロック６２０においてＡ＝１である場合、マイクロプロセッサは、ＲＡ／ＲＢフィールドを読取りアドレスとして使用して、設計されたＧＰＲからオペランドを読取る（ブロック６２４）。しかる後、発行キューのオペレーションは終了し、オペレーションは、更に詳細に後述される図８に進む。
【００７４】
ＦＰＲに関しては、ブロック６２６においてＷ＝１である場合、マイクロプロセッサは、ソースＤＴＡＧ（source_DTAG）を読取りアドレスとして使用してＦＰＲリネーム・バッファからオペランドを読取る（ブロック６２８）。しかる後、オペレーションは終了する。ブロック６２６においてＡ＝１である場合、マイクロプロセッサは、ＲＡ／ＲＢフィールドを読取りアドレスとして使用して、設計されたＦＰＲからオペランドを読取る（ブロック６３０）。しかる後、発行キューのオペレーションは終了し、オペレーションは、更に詳細に後述される図８に進む。
【００７５】
ＶＲに関しては、ブロック６３２においてＷ＝１である場合、マイクロプロセッサは、ソースＤＴＡＧ（source_DTAG）を読取りアドレスとして使用してＶＲリネーム・バッファからオペランドを読取る（ブロック６３４）。しかる後、オペレーションは終了する。ブロック６３２においてＡ＝１である場合、マイクロプロセッサは、ＲＡ／ＲＢフィールドを読取りアドレスとして使用して、設計されたＶＲからオペランドを読取る（ブロック６３６）。しかる後、発行キューのオペレーションは終了し、オペレーションは、更に詳細に後述される図８に進む。
【００７６】
図８は、実施例に従って、ユニバーサル・リネーム機構を有するマイクロプロセッサの、実行／書き戻し時におけるオペレーションを示すフローチャートである。オペレーションは終了時に開始し、実行ユニットが、Ｗビットを更新するために、発行キューおよびリネーム・ステージにＤＴＡＧ（execution_DTAG）を返送する（ブロック７０２）。発行キューにおいて、マイクロプロセッサはソースＤＴＡＧ（source_DATG）を実行ＤＴＡＧ（execution_DATG）と比較する（ブロック７０４）。マイクロプロセッサは、実行ＤＴＡＧ（execution_DTAG）がソースＤＴＡＧ（source_DTAG）と一致するかどうか、および、命令タイプが一致するかどうかを決定する（ブロック７０６）。実行ＤＴＡＧ（execution_DTAG）がソースＤＴＡＧ（source_DTAG）と一致し、命令タイプが一致する場合（例えば、ディスパッチ命令がＦＸＵ命令であり、ディスパッチ・タイプＧＰＲ（Destination_type_GPR）＝１である場合）、オペランドが今やリネーム・バッファからデータを読取ることができることを表すために、その一致したロケーションにおいてマイクロプロセッサはＷ＝１をセットする（ブロック７０８）。
【００７７】
リネーム・ステージにおいて、マイクロプロセッサは、実行ＤＴＡＧ（execution_DTAG）によって指定されたロケーションにおいてＷ＝１をセットする（ブロック７１０）。Ｗ＝１であるとき、ＲＴに従属するいずれの比較的直近の命令もリネーム・バッファからそのオペランドを読取らなければならないであろう。
【００７８】
ＧＰＲに関しては、マイクロプロセッサは実行ＤＴＡＧ（execution_DTAG）を書込みアドレスとして使用してＧＰＲリネーム・バッファに実行結果を書込む（ブロック７１２）。しかる後、オペレーションは終了する。
【００７９】
ＦＰＲに関しては、マイクロプロセッサは実行ＤＴＡＧ（execution_DTAG）を書込みアドレスとして使用してＦＰＲリネーム・バッファに実行結果を書込む（ブロック７１４）。しかる後、オペレーションは終了する。
【００８０】
ＶＲに関しては、マイクロプロセッサは実行ＤＴＡＧ（execution_DTAG）を書込みアドレスとして使用してＶＲリネーム・バッファに実行結果を書込む（ブロック７１６）。しかる後、オペレーションは終了する。
【００８１】
図９および図１０は、実施例に従って、ユニバーサル・リネーム機構を有するマイクロプロセッサの完了時におけるオペレーションを示すフローチャートである。図９に関して、完了時にオペレーションが開始し、完了ロジックが完了ＤＴＡＧ（completing_DTAG）を発行キューおよびリネーム・ステージに送ってＷビットを更新させる（ブロック８０２）。発行キューにおいて、マイクロプロセッサは、ソースＤＴＡＧ（source_DTAG）を完了ＤＴＡＧ（completing_DTAG）と比較する（ブロック８０４）。マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）がソースＤＴＡＧ（source_DTAG）と一致するかどうかおよび命令タイプが一致するかどうかを決定する（ブロック８０６）。完了ＤＴＡＧ（completing_DTAG）がソースＤＴＡＧ（source_DTAG）と一致し、命令タイプが一致する場合（ディスパッチ命令がＦＸＵ命令であり、宛先タイプＧＰＲ（Destination_type_GPR）＝１である場合）、一致したロケーションにおいて、マイクロプロセッサはＡ＝１をセットして、オペランドが、設計されたレジスタから読取ることが可能であることを表示させる（ブロック８０８）。
【００８２】
しかる後、またはブロック８０６において完了ＤＴＡＧ（completing_DTAG）がソースＤＴＡＧ（source_DATG）と一致しない場合、リネーム・ステージにおいて、マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）によって指定されたロケーションにＹ＝０をセットする（ブロック８１０）。マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）を使用して回復リンク・アレイにおけるすべてのＤＴＡＧと比較させる（ブロック８１２）。マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）のいずれも回復リンク・アレイにおけるいずれかのＤＴＡＧと一致するかどうかを決定する（ブロック８１４）。いずれかの一致がある場合、一致したロケーションにおいて、マイクロプロセッサはＶビットを０にリセットして、これらのロケーションが完了したということを表示させる（ブロック８１６）。しかる後、または、ブロック８１４において一致がない場合、オペレーションは図１０におけるブロック８１８に進む。ブロック８１８では、マイクロプロセッサは、完了ＤＴＡＧ（comleting_DTAG）を使用して論理レジスタ・アレイから完了ＲＴ（completing_RT）フィールドおよび宛先タイプ・ビットを読み出す。
【００８３】
宛先タイプがＧＰＲである場合、マイクロプロセッサは、読取るために完了ＤＴＡＧ（completing_DTAG）を使用してＧＰＲリネーム・バッファから結果を読み出し、その結果をＧＰＲに書込む（ブロック８２０）。マイクロプロセッサは、完了ＲＴ（completing_RT）フィールドをＧＰＲ書込みアドレスとして使用する。宛先タイプがＦＰＲである場合、マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）を使用してＦＰＲリネーム・バッファから結果を読み出し、その結果をＦＰＲに書込む（ブロック８２２）。マイクロプロセッサは、完了ＲＴ（completing_RT）フィールドをＦＰＲ書込みアドレスとして使用する。宛先タイプがＶＲである場合、マイクロプロセッサは、完了ＤＴＡＧ（completing_DTAG）を使用してＶＲリネーム・バッファから結果を読み出し、その結果をＶＲに書込む（ブロック８２４）。マイクロプロセッサは、完了ＲＴ（completing_RT）フィールドをＶＲ書込みアドレスとして使用する。
【００８４】
ブロック８２０、ブロック８２２、またはブロック８２４において、マイクロプロセッサは、設計されたレジスタに結果を書込んだ後、新しいディスパッチ命令によって再使用されるように完了したＤＴＡＧを割付け解除する（ブロック８２６）。しかる後、オペレーションは終了する。
【００８５】
図１１は、実施例に従って、ユニバーサル・リネーム機構を有するマイクロプロセッサの、フラッシュ時におけるオペレーションを示すフローチャートである。オペレーションが開始し、完了ロジックが最も古いフラッシュＤＴＡＧをリネーム・ステージに送って、Ｙビットを適切な状態に回復させる（ブロック９０２）。次に、完了ロジックは、最も古いフラッシュＤＴＡＧに同等またはそれよりも比較的直近のいずれのＤＴＡＧもフラッシュする（ブロック９０４）。次に、マイクロプロセッサは、完了ロジックから生じたＤＴＡＧ先頭ポインタおよび最も古いフラッシュＤＴＡＧを使用して、フラッシュＤＴＡＧベクトルを生成する（ブロック９０６）。
【００８６】
次に、マイクロプロセッサは、最も古いフラッシュＤＴＡＧに同等またはそれよりも比較的直近の回復リンク・アレイにおいてＶ＝１を有する任意のＤＴＡＧをフラッシュしたエントリと見なす（ブロック９０８）。言い換えれば、ＤＴＡＧ先頭ポインタとその最も古いフラッシュＤＴＡＧとの間にあってその最も古いフラッシュＤＴＡＧを含むいずれのエントリもフラッシュ・アウトされる。マイクロプロセッサは、Ｙビットを回復するためのそのフラッシュされたエントリにおけるＤＴＡＧを読み出す（ブロック９１０）。これらのＤＴＡＧは、回復ＤＴＡＧ（restore_DTAG）と呼ばれる。すべてのフラッシュされたエントリからＤＴＡＧが読み出され、比較的直近の命令ストリームをディスパッチする前に回復されなければならない。しかる後、オペレーションは終了する。
【００８７】
図１２は、実施例に従って、回復機能のオペレーションを示すフローチャートである。オペレーションが開始し、プロセッサが、回復リンク・アレイにおける各エントリに対するオペレーションに入る（ブロック１００２）。マイクロプロセッサは、このエントリがフラッシュされていることおよび内容が読み出されなければならないことを表すためにフラッシュＤＴＡＧベクトルからの関連するビットに対してＶビットをビット単位でＡＮＤする（ブロック１００４）。次に、マイクロプロセッサは、回復リンクにおいてＤＴＡＧをデコードすることによって回復エントリに関する内容を読み出し、ホット「１」ベクトルを形成する（ブロック１００６）。次に、マイクロプロセッサは、ブロック１００４から形成されたビット単位のＡＮＤの結果とホット「１」とをＡＮＤする（ブロック１００８）。これは、各エントリに対する回復ＤＴＡＧ（restore_DTAG）を形成する。マイクロプロセッサは、Ｙビット・ベクトルに対する書込みアドレスとして回復ＤＴＡＧ（restore_DTAG）を使用して回復ロケーションにおいてＹ＝１をセットする（ブロック１０１０）。次に、マイクロプロセッサは、回復リンク・アレイにおける次のエントリを考察し（ブロック１０１２）、回復リンク・アレイのすべてのエントリが考察されるまで、オペレーションはブロック１００２に戻る。
【００８８】
全Ｙビットが回復された後、マイクロプロセッサは、フラッシュＤＴＡＧベクトルを用いてその新たに回復されたＹビット・ベクトルにおけるＹビット間でビット単位のＡＮＤを行ってブロック１００４〜１０１０から回復された、フラッシュされた命令のすべてのＹビット片付ける（ブロック１０１４）。一致したロケーションでは、マイクロプロセッサはＹビットを０にリセットする（ブロック１０１６）。これは、同じ論理ＲＴレジスタに対して複数のＹビットが１にセットされないようにする。言い換えれば、回復ＤＴＡＧ（restore_DTAG）がフラッシュされたエントリを指定する場合、そのエントリに対するＹビットは１にセットする代わりに０にリセットされなければならない。しかる後、オペレーションは終了する。図１２に示された回復機能は、フラッシュ後に新たにディスパッチされた命令が、従属するべき直近のＲＴを知ることを保証する。
【００８９】
従って、実施例は、マイクロプロセッサにおける種々の命令タイプのターゲットに対して１つの統一されたレジスタ・リネーム機構を提供することによって、従来技術の欠点を解決する。そのユニバーサル・リネーム機構は、単一のリネーム機構を使用して種々の命令タイプの宛先をリネームする。従って、浮動小数点レジスタ（ＦＰＲ）を更新する命令は、汎用レジスタ（ＧＰＲ）に関する設計された状態の数が浮動小数点レジスタ（ＦＰＲ）およびベクトル・マルチメディア・エクステンション（ＶＭＸ）命令レジスタ（ＶＲ）に対する設計された状態の数と同じであるので、ＧＰＲまたはＶＲを更新する命令と共にリネームされ得る。各宛先タグ（ＤＴＡＧ）が１つの宛先に割り当てられる。浮動小数点命令はＤＴＡＧに割り当てられ得るし、固定小数点命令は次のＤＴＡＧに割り当てられ得る。ユニバーサル・リネーム機構の場合、すべての命令タイプに対して１つのリネーム構造しか持たないことによって、かなりのシリコンおよび電力を節約することができる。
【００９０】
実施例が、全体的にハードウェアの実施例、全体的にソフトウェアの実施例、或いはハードウェア要素およびソフトウェア要素の両方を含む実施例の形式を取り得るということは明らかであろう。１つの実施例では、その実施例の機構が、ファームウェア、常駐のソフトウェア、マイクロコード等を含むがそれに限定されないソフトウェアにおいて具現化される。
【００９１】
更に、実施例は、コンピュータ或いは任意の命令実行システムによって或いはそれに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスし得るコンピュータ・プログラム製品の形式を取ることも可能である。説明の便宜上、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって或いはそれに関連して使用するためのプログラムを含むこと、格納すること、通信すること、伝播すること、または搬送することができる任意の装置であってもよい。
【００９２】
その媒体は、電子的システム、磁気的システム、光学的システム、電磁気的システム、赤外線システム、半導体システム（または装置、またはデバイス）、或いは伝播媒体であってもよい。コンピュータ可読媒体の例は、半導体メモリまたはソリッド・ステート・メモリ、磁気テープ、取外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクを含む。光ディスクの現在の例は、コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク・リード／ライト（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。
【００９３】
プログラム・コードを格納および／または実行するに適したデータ処理システムは、システム・バスを介してメモリ素子に直接的或いは間接的に接続された少なくとも１つのプロセッサを含むであろう。メモリ素子は、プログラム・コードの実際の実行中に使用されるローカル・メモリ、大容量記憶装置、および、プログラム・コードが実行中に大容量記憶装置から検索されるべき回数を減らすために少なくとも幾つかのプログラム・コードの一時的記憶装置を提供するキャッシュ・メモリを含み得る。
【００９４】
入出力装置、即ち、Ｉ／Ｏ装置（キーボード、ディスプレイ、ポインティング装置等を含むが、それに限定されない）は、システムに直接に、或いは介在するＩ／Ｏコントローラに直接にまたはそれを介して、接続することが可能である。ネットワーク・アダプタは、データ処理システムが介在の専用ネットワークまたは公衆ネットワークを介して他のデータ処理システム或いは遠隔のプリンタまたは記憶装置に接続されることを可能にするようにシステムに接続されてもよい。モデム、ケーブル・モデム、およびイーサネット（登録商標）・カードは、わずかな現在利用可能のタイプのネットワーク・アダプタである。
【００９５】
本実施例に関する記述は、図解および説明を目的として示されたものであり、網羅的であること或いは開示された形式における発明に限定されることを意図するものではない。多くの修正および変更が当業者には明らかであろう。実施例は、本発明の原理および実用的な応用例を最もよく説明するために、および、特定の意図した用途に適する種々の修正を伴う種々の実施例に関して当業者が本発明を理解することを可能にするために、選択され、記述された。
【図面の簡単な説明】
【００９６】
【図１】実施例に従って本発明を具現化し得るデータ処理システムの概略図である。
【図２】本発明の諸局面を具現化し得る例示的なデータ処理システムのブロック図である。
【図３】実施例に従ってユニバーサル・レジスタ・リネーム機構を有するマイクロプロセッサの一部を示すブロック図である。
【図４】実施例に従ってレジスタ・リネーム機構のデータフローを示す図である。
【図５】実施例に従ってユニバーサル・リネーム機構を有するマイクロプロセッサの、ディスパッチ時におけるオペレーションを示すフローチャートである。
【図６】実施例に従ってユニバーサル・リネーム・バッファを有するマイクロプロセッサの発行キューのオペレーションを示すフローチャートである。
【図７】図６に続くオペレーション示すフローチャートである。
【図８】実施例に従ってユニバーサル・リネーム機構を有するマイクロプロセッサの、実行／書き戻し時におけるオペレーションを示すフローチャートである。
【図９】実施例に従ってユニバーサル・リネーム機構を有するマイクロプロセッサの、完了時におけるオペレーションを示すフローチャートである。
【図１０】図９に続くオペレーション示すフローチャートである。
【図１１】実施例に従ってユニバーサル・リネーム機構を有するマイクロプロセッサの、フラッシュ時におけるオペレーションを示すフローチャートである。
【図１２】実施例に従って回復機能のオペレーションを示すフローチャートである。
【図１】
2008269601.tif 000003
【図２】
2008269601.tif 000004
【図３】
2008269601.tif 000005
【図４】
2008269601.tif 000006
【図５】
2008269601.tif 000007
【図６】
2008269601.tif 000008
【図７】
2008269601.tif 000009
【図８】
2008269601.tif 000010
【図９】
2008269601.tif 000011
【図１０】
2008269601.tif 000012
【図１１】
2008269601.tif 000013
【図１２】
2008269601.tif 000014