(57)【要約】   【課題】  オペランドの値において、ある部分に連続して同一の値が現れる場合に、使用するレジスタファイルの記憶領域を有効に利用する。  【解決手段】  プロセッサは、物理レジスタＩＤに対応したオペランドを記憶する複数のレジスタファイル１６−１、１６−２を備え、それぞれが、オペランドをデータ方向に分割したサブワードのうちの何れかを記憶する。プロセッサは、ＡＬＵ１８の出力を入力として、いずれかのサブワードの全てのビットが同一値であることを判断し、同一値であるサブワードを除き、他のサブワードについて、それぞれ、レジスタファイル中のレジスタエントリを割り当て、同一値であるサブワードについて、同一値を与えることを示すデータを保持する。これにより、レジスタファイル中のレジスタエントリから、サブワードが読み出され、読み出されたサブワードと、同一値を与えるべきサブワードとを組み合わせてオペランドが生成される。【選択図】  図１
2006139564.tif 000002
【特許請求の範囲】
【請求項１】
物理レジスタＩＤに対応したオペランドを記憶する複数のレジスタファイルであって、それぞれのレジスタファイルが、前記オペランドをデータ方向に分割したサブワードのうちの何れかを記憶するように構成されたレジスタファイルを備えたプロセッサのレジスタファイル制御方法であって、
ＡＬＵの出力において、いずれかのサブワードの全てのビットが同一値であることを判断するステップと、
前記同一値であるサブワードを除き、他のサブワードについて、それぞれ、前記レジスタファイル中のレジスタエントリを割り当てるステップと、
前記同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するステップと、
前記物理レジスタＩＤに対応したレジスタファイル中のレジスタエントリから、前記サブワードを読み出すステップと、
前記読み出されたサブワードと、前記保持されたデータに基づき同一値を与えるべきサブワードとを組み合わせてオペランドを生成するステップと、
前記生成されたオペランドを、前記ＡＬＵに入力するステップと、を備えたことを特徴とするレジスタファイルの制御方法。
【請求項２】
前記レジスタファイルのエントリを読み出すための物理レジスタＩＤを記憶するレジスタＩＤ記憶領域に、前記サブワードごとに前記レジスタエントリを特定する情報、および、前記情報の有効無効を示すフラグのデータの組を設け、
前記同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するステップにおいて、当該サブワードに関するレジスタＩＤ記憶領域のデータの組において、前記フラグを無効に設定するステップを備えたことを特徴とする請求項１に記載のレジスタファイルの制御方法。
【請求項３】
前記レジスタＩＤ記憶領域に記憶されるデータの組に、前記サブワードの順序を規定するデータを設け、
前記オペランドを生成するステップが、前記順序を規定するデータに基づいて、前記読み出されたサブワードと、同一値を与えるべきサブワードとを組み合わせるステップを備えたことを特徴とする請求項２に記載のレジスタファイルの制御方法。
【請求項４】
前記サブワードの全てのビットが同一値であることを判定した場合に、コミットに先立って、当該サブビットに関するレジスタエントリを解放し、当該レジスタエントリの物理レジスタＩＤを、解放されたレジスタエントリの物理レジスタＩＤの情報を格納するフリープールに書き込むステップを備えたことを特徴とする請求項１ないし３の何れか一項に記載の制御方法。
【請求項５】
前記物理レジスタのレジスタエントリごとの状態を管理する状態テーブルであって、前記状態と、前記レジスタエントリ中、最下位のサブワードに割り当てられたエントリの部分に相当するマスタエントリ以外のサブワードに割り当てられたエントリの部分に相当するスレーブエントリの、それぞれの有効性を示す状態ビットとを有する状態テーブルを設けるステップと、
前記状態テーブルにおいて、前記状態がフリーである物理レジスタのレジスタエントリが、ある命令のデスティネーションレジスタとして割り当てられた際に、当該レジスタエントリの状態を、エントリ無効とするとともに、マスタエントリに関して、スレーブエントリのそれぞれの状態ビットをリセットするステップと、
前記コミットに先立つサブビットに関するレジスタエントリの解放に伴って、前記状態テーブルにおいて、前記スレーブエントリの状態を、フリーにするとともに、当該スレーブエントリに関連するマスタエントリの状態を、エントリ有効にするステップと、
前記状態テーブルにおいて、エントリ有効となったマスタエントリに関して、前記開放されたスレーブエントリの状態ビットをセットするステップと、を備え、
前記スレーブエントリの有効性を、前記関連するマスタエントリの状態ビットを参照することで判断するように構成されたことを特徴とする請求項４に記載の制御方法。
【請求項６】
さらに、ウェイクアップ動作において、
命令の実行の結果、演算結果のデスティネーションオペランドの準備ができた場合に、そのオペランドのレジスタエントリの物理レジスタＩＤをブロードキャストするステップと、
前記ブロードキャストされた物理レジスタＩＤと、ソースオペランドの物理レジスタＩＤとが一致した場合に、そのソースオペランドについて、命令キューに用意された、ソースオペランドごとの準備状況を示すレディ・ビットがセットされていない場合には、当該レディ・ビットをセットし、その一方、既にレディ・ビットがセットされている場合には、前記レジスタＩＤ記憶領域中、当該ソースオペランドの物理レジスタＩＤに関する情報の有効無効を示すフラグを無効に設定するステップと、を備えたことを特徴とする請求項２または３に記載の制御方法。
【請求項７】
アーキテクチャレジスタのレジスタＩＤと物理レジスタＤとを関連付けたマップテーブル、命令キュー、レジスタファイルおよびＡＬＵを有し、マップテーブルから出力される物理レジスタＩＤが命令キューを経てレジスタファイルに与えられ、当該レジスタファイルから対応するオペランドが読み出されて、ＡＬＵに入力されるプロセッサにおいて、
前記物理レジスタＩＤに対応したオペランドを記憶する複数のレジスタファイルであって、それぞれが、前記オペランドをデータ方向に分割したサブワードのうちの何れかを記憶するように構成された複数のレジスタファイルと、
前記ＡＬＵの出力を入力として、いずれかのサブワードの全てのビットが同一値であることを判断する同一値判断手段と、
前記同一値であるサブワードを除き、他のサブワードについて、それぞれ、前記レジスタファイル中のレジスタエントリを割り当てる割り当て手段と、
同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するサブワード情報保持手段と、を備え、
前記物理レジスタＩＤに対応したレジスタファイル中のレジスタエントリから、前記サブワードを読み出し、読み出されたサブワードと、保持されたデータに基づき同一値を与えるべきサブワードとを組み合わせてオペランドを生成するオペランド生成手段と、を備え、
前記生成されたオペランドが、前記ＡＬＵに入力されるように構成されたことを特徴とするプロセッサ。
【請求項８】
前記サブワード情報保持手段が、前記レジスタファイルのエントリを読み出すための物理レジスタＩＤを記憶するレジスタＩＤ記憶領域に、前記サブワードごとに前記レジスタエントリを特定する情報、および、前記情報の有効無効を示すフラグのデータの組を有し、かつ、同一値判断手段により、同一値であると判断されたサブワードについて、前記サブワード情報保持手段が、当該サブワードに関するレジスタＩＤ記憶領域のデータの組において、前記フラグを無効に設定するように構成されたこと特徴とする請求項７に記載のプロセッサ。
【請求項９】
前記サブワード情報保持手段が、サブワードの順序に基づいて、前記レジスタＩＤ記憶領域に記憶されるデータの組に、前記サブワードの順序を規定するデータを格納するように構成され、かつ、
前記オペランド生成手段が、前記順序を規定するデータに基づいて、前記読み出されたサブワードと、同一値を与えるべきサブワードとを組み合わせるように構成されたことを特徴とする請求項８に記載のプロセッサ。
【請求項１０】
前記同一値判断手段が、前記サブワードの全てのビットが同一値であると判定した場合に、コミットに先立って、当該サブビットに関するレジスタエントリを解放し、当該レジスタエントリの物理レジスタＩＤを、解放されたレジスタエントリの物理レジスタＩＤの情報を格納するフリープールに書き込む早期レジスタエントリ解放手段を備えたことを特徴とする請求項７ないし９の何れか一項に記載のプロセッサ。
【請求項１１】
さらに、前記物理レジスタのレジスタエントリごとの状態を管理する状態テーブルであって、前記状態と、前記レジスタエントリ中、最下位のサブワードに割り当てられたエントリの部分に相当するマスタエントリ以外のサブワードに割り当てられたエントリの部分に相当するスレーブエントリの、それぞれの有効性を示す状態ビットとを有する状態テーブルを備え、
前記早期レジスタエントリ解放手段が、前記状態テーブルにおいて、前記状態がフリーである物理レジスタのレジスタエントリが、ある命令のデスティネーションレジスタとして割り当てられた際に、当該レジスタエントリの状態を、エントリ無効とするとともに、マスタエントリに関して、スレーブエントリのそれぞれの状態ビットをリセットし、
前記コミットに先立つサブビットに関するレジスタエントリの解放に伴って、前記状態テーブルにおいて、前記スレーブエントリの状態を、フリーにするとともに、当該スレーブエントリに関連するマスタエントリの状態を、エントリ有効にし、かつ、
前記状態テーブルにおいて、エントリ有効となったマスタエントリに関して、前記開放されたスレーブエントリの状態ビットをセットするように構成され、
前記スレーブエントリの有効性を、前記関連するマスタエントリの状態ビットを参照することで判断するように構成されたことを特徴とする請求項１０に記載のプロセッサ。
【請求項１２】
さらに、命令キューが、ウェイクアップ動作において、命令の実行の結果、演算結果のデスティネーションオペランドの準備ができた場合に、そのオペランドのレジスタエントリの物理レジスタＩＤをブロードキャストし、
前記ブロードキャストされた物理レジスタＩＤと、ソースオペランドの物理レジスタＩＤとが一致した場合に、そのソースオペランドについて、命令キューに用意された、ソースオペランドごとの準備状況を示すレディ・ビットがセットされていない場合には、当該レディ・ビットをセットし、その一方、既にレディ・ビットがセットされている場合には、前記レジスタＩＤ記憶領域中、当該ソースオペランドの物理レジスタＩＤに関する情報の有効無効を示すフラグを無効に設定するように構成されたことを特徴とする請求項８または９に記載のプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセッサ中のレジスタファイルのサイズを削減するレジスタ制御方法、および、プロセッサに関する。
【背景技術】
【０００２】
動的命令スケジューリング・多命令同時発行を行うマイクロプロセッサでは、命令レベル並列性（ＩＬＰ）を活用するために、大容量かつ多ポートのレジスタファイルが必須である。近年では、さらなるＩＬＰ活用のために命令ウィンドウサイズや同時発行命令数を増加させる傾向にあるが、それにともないレジスタファイルのサイズ・ポート数も増加している。しかし、レジスタファイルの大容量・多ポート化は、アクセス時間や消費電力の増大という問題を引き起こす。
【０００３】
これら問題への対処を目的として、アクセスすべきレジスタのサイズ・ポート数を削減するための手法がこれまでにも多く提案されている。たとえば、要求されるサイズ削減のために、物理レジスタファイルの割り当てを遅らせる手法（非特許文献１、２）、同じ値を持つオペランドを１つのレジスタエントリで共有化する手法（非特許文献３、４）、階層化レジスタファイル（非特許文献５、６）などが提案されている。
【非特許文献１】A. Gonzalez他著、“Virtual-Physical Registers”、In Proc. The 4th HPCA、第１７５頁〜第１８４頁、１９９８年２月
【非特許文献２】T.Montreal他著、“Delaying Physical Register Allocation Throughvirtual-Physical Registers”、In Proc. The 32nd MICRO、第１８６頁〜第１９８頁、１９９９年１１月
【非特許文献３】J.Jourdan他著、“A Novel Renaming Scheme to Exploit Value TemporalLocality through Physical Register Reuse and Unification”、In proc. The 31stMICRO、第２１６頁〜第２２５頁、１９９８年１１月
【非特許文献４】S.Balakrishnan、G.S.Sohi共著、“Exploiting Value Locality in PhysicalRegister Files”、In Proc. 36th MICRO、第２６５頁〜第２７６頁、２００３年１２月
【非特許文献５】J.L.Cruz他著、“Multiple-Banked Register File Architectures”、In Proc.27th ISCA、第３１６頁〜第３２５頁、２０００年６月
【非特許文献６】R.Balasubramonian他著、“Reducing the Complexity of the Register File inDynamic Superscalar Processor”、In Proc. 34th MICRO、第２３７頁〜第２４８頁、２００１年１１月
【非特許文献７】Jurij Silc、Borut Roic、Theo Ungerer共著、“ProcessorArchitecture From Dataflow to Superscalar and Beyond”Springer、第１８０頁、第１９７頁、(ISBN 3-540-64798-8)、１９９９年６月
【発明の開示】
【発明が解決しようとする課題】
【０００４】
一般的にワークステーションやパーソナルコンピュータに搭載されるマイクロプロセッサは３２ビット、或いは、６４ビット幅のデータパスを持ち、３２または６４ビット演算を行うことが可能である。しかし、実際のプログラム実行の際には、多くのオペランドはそれらのビット幅よりも実効ビット幅が小さく、上位ビット全て０（負の場合には１）であることが多い。
【０００５】
従来のプロセッサでは有効ビット幅が小さなデータに対しても、フルビット幅のレジスタエントリを割り当てているため、それらのエントリの上位ビット部分は無駄に使われていた。たとえば、非特許文献７には、従来のプロセッサ（「Ａｌｐｈａ２１２６４」、「ＭＩＰＳ  Ｒ１００００」の構成が開示されている。このような従来のプロセッサにおいて、図６に示すように、フェッチ（Ｆｅｔｃｈ）、デコード（Ｄｅｃｏｄｅ）された命令のソースレジスタＩＤは、リネーム（Ｒｅｎａｍｅ）ステージにおいて、マップテーブルを参照することで、物理レジスタＩＤに変換される。また、それと同時にその命令のデスティネーションレジスタとして新しい物理レジスタエントリがフリープールから割り当てられる。フリープールから取得された物理レジスタＩＤは、デスティネーションレジスタＩＤに対応するマップテーブルのエントリに登録される。なお、図６において、実線がソースレジスタＩＤの流れを示し、破線がデスティネーションレジスタＩＤの流れを示す。また、太実線はデータの流れを示す。
【０００６】
また、各命令のコミット（Ｃｏｍｍｉｔ）を命令順序通りに行うため、リネーム（Ｒｅｎａｍｅ）ステージでは全ての命令の情報がリオーダバッファに命令順序どおりに記憶される。この際、命令のデスティネーションレジスタＩＤと、それ以前にそのＩＤに割り当てられていた物理レジスタＩＤがリオーダバッファに登録される。命令がコミット（Ｃｏｍｍｉｔ）される際には、リオーダバッファの該当エントリに登録されていた物理レジスタエントリが解放されフリープールに戻される。
【０００７】
各命令は、リネーム（Ｒｅｎａｍｅ）ステージで得られたソース・デスティネーション物理レジスタ番号と共に、キュー（Ｑｕｅｕｅ）ステージで、命令キュー（ｉｎｓｔｒｕｃｔｉｏｎ  ｑｕｅｕｅ）に登録され、なお、この登録の際に、状態テーブルがアクセスされて、その時点においてオペランドが既にアクセス可能であるかの情報も、命令キューに登録される。
【０００８】
キューに登録された命令は、すべてのオペランドが揃い次第、発行（Ｉｓｓｕｅ）される。発行された命令は、レジスタに読み込まれ（Ｒｅｇｉｓｔｅｒ  Ｒｅａｄ）、ＡＬＵにおいて演算が実行される（Ｅｘｅｃｕｔｅ）。演算結果は、ライトバック（Ｗｒｉｔｅｂａｃｋ）ステージでレジスタに書き込まれる。
【０００９】
たとえば、従来の６４ビットプロセッサにおいては、６４ビット幅のレジスタファイルが設けられる。図２（ａ）は、従来のレジスタファイルの例を示す。この例は、６４ビット幅、８０エントリのレジスタファイルを示す。図２（ａ）において、アーキテクチャレジスタＲ４のアクセスおよびアーキテクチャレジスタＲ８のアクセスが求められる場合を考える。ここで、アーキテクチャレジスタＲ４のオペランドの値は有効ビット幅が大きく（符号２１１参照）、Ｒ８のオペランドの値は有効ビット幅が小さく、せいぜい、下位３２ビットのみに有効な値を持つと考える（符号２１２参照）。
【００１０】
また、従来のレジスタファイル（符号２００参照）において、アーキテクチャレジスタＲ４が物理レジスタＰ１に割り当てられ、アーキテクチャレジスタＲ８が物理レジスタＰ３に割り当てられていると考える。ここで、Ｒ８のオペランドは有効ビット幅が小さく、上位側の値が全て０であるにもかかわらず、６４ビット幅のエントリが与えられる。すなわち、Ｒ４およびＲ８の両オペランドを保存するためには、１２８ビットの記憶領域が必要となる。
【００１１】
本発明は、上述したようにオペランドの値において、ある部分に連続して同一の値が現れる場合に、使用するレジスタファイルの記憶領域を有効に利用することができるプロセッサ、および、プロセッサのレジスタファイル制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、データ（オペランド）のビット方向に分割した複数のレジスタファイルを設け、有効ビット幅が小さなオペランドに対しては、必要な分だけ、所定のレジスタファイルのレジスタバンクを割り当てることで、レジスタファイルの記憶領域の有効利用を図る。
【００１３】
より詳細には、本発明の目的は、物理レジスタＩＤに対応したオペランドを記憶する複数のレジスタファイルであって、それぞれのレジスタファイルが、前記オペランドをデータ方向に分割したサブワードのうちの何れかを記憶するように構成されたレジスタファイルを備えたプロセッサのレジスタファイル制御方法であって、
ＡＬＵの出力において、いずれかのサブワードの全てのビットが同一値であることを判断するステップと、
前記同一値であるサブワードを除き、他のサブワードについて、それぞれ、前記レジスタファイル中のレジスタエントリを割り当てるステップと、
前記同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するステップと、
前記物理レジスタＩＤに対応したレジスタファイル中のレジスタエントリから、前記サブワードを読み出すステップと、
前記読み出されたサブワードと、前記保持されたデータに基づき同一値を与えるべきサブワードとを組み合わせてオペランドを生成するステップと、
前記生成されたオペランドを、前記ＡＬＵに入力するステップと、を備えたことを特徴とするレジスタファイルの制御方法により達成される。
【００１４】
好ましい実施態様においては、前記レジスタファイルのエントリを読み出すための物理レジスタＩＤを記憶するレジスタＩＤ記憶領域に、前記サブワードごとに前記レジスタエントリを特定する情報、および、前記情報の有効無効を示すフラグのデータの組を設け、
前記同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するステップにおいて、当該サブワードに関するレジスタＩＤ記憶領域のデータの組において、前記フラグを無効に設定するステップを備えている。
【００１５】
より好ましい実施態様においては、前記レジスタＩＤ記憶領域に記憶されるデータの組に、前記サブワードの順序を規定するデータを設け、
前記オペランドを生成するステップが、前記順序を規定するデータに基づいて、前記読み出されたサブワードと、同一値を与えるべきサブワードとを組み合わせるステップを備えている。
【００１６】
別の好ましい実施態様においては、前記サブワードの全てのビットが同一値であることを判定した場合に、コミットに先立って、当該サブビットに関するレジスタエントリを解放し、当該レジスタエントリの物理レジスタＩＤを、解放されたレジスタエントリの物理レジスタＩＤの情報を格納するフリープールに書き込むステップを備えている。
【００１７】
さらに好ましい実施態様においては、前記物理レジスタのレジスタエントリごとの状態を管理する状態テーブルであって、前記状態と、前記レジスタエントリ中、最下位のサブワードに割り当てられたエントリの部分に相当するマスタエントリ以外のサブワードに割り当てられたエントリの部分に相当するスレーブエントリの、それぞれの有効性を示す状態ビットとを有する状態テーブルを設けるステップと、
前記状態テーブルにおいて、前記状態がフリーである物理レジスタのレジスタエントリが、ある命令のデスティネーションレジスタとして割り当てられた際に、当該レジスタエントリの状態を、エントリ無効とするとともに、マスタエントリに関して、スレーブエントリのそれぞれの状態ビットをリセットするステップと、
前記コミットに先立つサブワードに関するレジスタエントリの解放に伴って、前記状態テーブルにおいて、前記スレーブエントリの状態を、フリーにするとともに、当該スレーブエントリに関連するマスタエントリの状態を、エントリ有効にするステップと、
前記状態テーブルにおいて、エントリ有効となったマスタエントリに関して、前記開放されたスレーブエントリの状態ビットをセットするステップと、を備え、
前記スレーブエントリの有効性を、前記関連するマスタエントリの状態ビットを参照することで判断するように構成されている。
【００１８】
また、好ましい実施態様においては、さらに、ウェイクアップ動作において、
命令の実行の結果、演算結果のデスティネーションオペランドの準備ができた場合に、そのオペランドのレジスタエントリの物理レジスタＩＤをブロードキャストするステップと、
前記ブロードキャストされた物理レジスタＩＤと、ソースオペランドの物理レジスタＩＤとが一致した場合に、そのソースオペランドについて、命令キューに用意された、ソースオペランドごとの準備状況を示すレディ・ビットがセットされていない場合には、当該レディ・ビットをセットし、その一方、既にレディ・ビットがセットされている場合には、前記レジスタＩＤ記憶領域中、当該ソースオペランドの物理レジスタＩＤに関する情報の有効無効を示すフラグを無効に設定するステップと、を備えている。
【００１９】
また、本発明の目的は、アーキテクチャレジスタのレジスタＩＤと物理レジスタＤとを関連付けたマップテーブル、命令キュー、レジスタファイルおよびＡＬＵを有し、マップテーブルから出力される物理レジスタＩＤが命令キューを経てレジスタファイルに与えられ、当該レジスタファイルから対応するオペランドが読み出されて、ＡＬＵに入力されるプロセッサにおいて、
前記物理レジスタＩＤに対応したオペランドを記憶する複数のレジスタファイルであって、それぞれが、前記オペランドをデータ方向に分割したサブワードのうちの何れかを記憶するように構成された複数のレジスタファイルと、
前記ＡＬＵの出力を入力として、いずれかのサブワードの全てのビットが同一値であることを判断する同一値判断手段と、
前記同一値であるサブワードを除き、他のサブワードについて、それぞれ、前記レジスタファイル中のレジスタエントリを割り当てる割り当て手段と、
同一値であるサブワードについて、当該サブワードに同一値を与えることを示すデータを保持するサブワード情報保持手段と、を備え、
前記物理レジスタＩＤに対応したレジスタファイル中のレジスタエントリから、前記サブワードを読み出し、読み出されたサブワードと、保持されたデータに基づき同一値を与えるべきサブワードとを組み合わせてオペランドを生成するオペランド生成手段と、を備え、
前記生成されたオペランドが、前記ＡＬＵに入力されるように構成されたことを特徴とするプロセッサによっても達成される。
【００２０】
好ましい実施態様においては、前記サブワード情報保持手段が、前記レジスタファイルのエントリを読み出すための物理レジスタＩＤを記憶するレジスタＩＤ記憶領域に、前記サブワードごとに前記レジスタエントリを特定する情報、および、前記情報の有効無効を示すフラグのデータの組を有し、かつ、同一値判断手段により、同一値であると判断されたサブワードについて、前記サブワード情報保持手段が、当該サブワードに関するレジスタＩＤ記憶領域のデータの組において、前記フラグを無効に設定するように構成されている。
【００２１】
より好ましい実施態様においては、前記サブワード情報保持手段が、サブワードの順序に基づいて、前記レジスタＩＤ記憶領域に記憶されるデータの組に、前記サブワードの順序を規定するデータを格納するように構成され、かつ、
前記オペランド生成手段が、前記順序を規定するデータに基づいて、前記読み出されたサブワードと、同一値を与えるべきサブワードとを組み合わせるように構成されている。
【００２２】
別の好ましい実施態様においては、前記同一値判断手段が、前記サブワードの全てのビットが同一値であると判定した場合に、コミットに先立って、当該サブビットに関するレジスタエントリを解放し、当該レジスタエントリの物理レジスタＩＤを、解放されたレジスタエントリの物理レジスタＩＤの情報を格納するフリープールに書き込む早期レジスタエントリ解放手段を備えたことを特徴とする請求項７ないし９の何れか一項に記載のプロセッサ。
【００２３】
また、より好ましい実施態様においては、さらに、前記物理レジスタのレジスタエントリごとの状態を管理する状態テーブルであって、前記状態と、前記レジスタエントリ中、最下位のサブワードに割り当てられたエントリの部分に相当するマスタエントリ以外のサブワードに割り当てられたエントリの部分に相当するスレーブエントリの、それぞれの有効性を示す状態ビットとを有する状態テーブルを備え、
前記早期レジスタエントリ解放手段が、前記状態テーブルにおいて、前記状態がフリーである物理レジスタのレジスタエントリが、ある命令のデスティネーションレジスタとして割り当てられた際に、当該レジスタエントリの状態を、エントリ無効とするとともに、マスタエントリに関して、スレーブエントリのそれぞれの状態ビットをリセットし、
前記コミットに先立つサブワードに関するレジスタエントリの解放に伴って、前記状態テーブルにおいて、前記スレーブエントリの状態を、フリーにするとともに、当該スレーブエントリに関連するマスタエントリの状態を、エントリ有効にし、かつ、
前記状態テーブルにおいて、エントリ有効となったマスタエントリに関して、前記開放されたスレーブエントリの状態ビットをセットするように構成され、
前記スレーブエントリの有効性を、前記関連するマスタエントリの状態ビットを参照することで判断するように構成されている。
【００２４】
別のより好ましい実施態様においては、さらに、命令キューが、ウェイクアップ動作において、命令の実行の結果、演算結果のデスティネーションオペランドの準備ができた場合に、そのオペランドのレジスタエントリの物理レジスタＩＤをブロードキャストし、
前記ブロードキャストされた物理レジスタＩＤと、ソースオペランドの物理レジスタＩＤとが一致した場合に、そのソースオペランドについて、命令キューに用意された、ソースオペランドごとの準備状況を示すレディ・ビットがセットされていない場合には、当該レディ・ビットをセットし、その一方、既にレディ・ビットがセットされている場合には、前記レジスタＩＤ記憶領域中、当該ソースオペランドの物理レジスタＩＤに関する情報の有効無効を示すフラグを無効に設定するように構成されている。
【発明の効果】
【００２５】
本発明によれば、オペランドの値において、ある部分に連続して同一の値が現れる場合に、使用するレジスタファイルの記憶領域を有効に利用することができるプロセッサ、および、プロセッサのレジスタファイル制御方法を提供することが可能となる。
【発明を実施するための最良の形態】
【００２６】
以下、添付図面を参照して本発明の実施の形態について説明する。図１は、本発明の実施の形態にかかるプロセッサのブロックダイヤグラムである。本実施の形態においては、従来のレジスタファイル（たとえば、８０エントリと考える。）をビット方向に２分割してブロックを形成させる。分割されたレジスタファイルの各ブロックをバンクと称し、オペランドの６４ビットワードを２つに分割した場合のそれぞれをサブワードと称する。ここで、ビット方向に分割しても、分割後の各バンクのエントリ数は８０で変わらず、両バンク合計で１６０エントリとなる。したがって、従来のレジスタファイルと比較すると、同じ記憶容量のもとで、エントリ数が増えることになる。本実施の形態にかかるプロセッサ１０においては、オペランドの有効ビット幅に合わせて必要なエントリだけを割り当てることにより、レジスタファイルの記憶領域を有効に利用する。その一方、６４ビットのデータも、複数のエントリを用いて記憶できるため、プロセッサの論理的動作には影響を与えない。
【００２７】
図１に示すように、プロセッサ１０は、マップテーブル１２、命令キュー１４、第１のレジスタファイル（バンク０）１６−１、第２のレジスタファイル（バンク１）１６−２、ＡＬＵ１８、０（ゼロ）検出器２０、第１のフリープール（バンク０）２２−１、および、第２のフリープール（バンク１）２２−２、リオーダバッファ２４、および、状態テーブル２５を備えている。なお、図１において、図６と同様に、実線がソースレジスタＩＤの流れ、破線がデスティネーションレジスタＩＤの流れ、太実線がデータの流れを、それぞれ示す。
【００２８】
マップテーブル１２には、アーキテクチャレジスタと物理レジスタとの関係（割り当て）を示す情報が記憶され、アーキテクチャレジスタのレジスタＩＤを入力として、物理レジスタのレジスタＩＤ（物理レジスタＩＤ）を出力する。
【００２９】
図２（ｂ）は、本実施の形態にかかるレジスタファイルの構成の例を示す図である。図２（ｂ）に示すように、レジスタファイル１６−１、１６−２は、それぞれ、３２ビット幅、８０エントリとなっている。レジスタファイル１６−１、１６−２は、それぞれ、物理レジスタＩＤを入力として、３２ビット幅のサブワードを出力する。たとえば、レジスタファイル１６−１、１６−２の双方からサブワードが出力された場合、第１のレジスタファイル（バンク０）１６−１の出力が、６４ビット幅のデータ中の下位３２ビット、第２のレジスタファイル（バンク１）１６−２からの出力が、６４ビット幅のデータ中の上位３２ビットを構成する。
【００３０】
０（ゼロ）検出器２０は、ＡＬＵから出力された３２ビット幅のサブワードを入力として、それぞれのサブワードの全ての値が「０（ゼロ）」であるかを判断する。本実施の形態においては、全ての値が「０（ゼロ）」であることを検出しているが、負の値を考える場合には、全ての値が「１」であることを検出できるように構成しても良い。
【００３１】
第１のフリープール２２−１、第２のフリープール２２−２は、れれぞれ、命令がコミット（Ｃｏｍｍｉｔ）された後、或いは、後述するように、コミットされるよりも前に解放された、バンク０、バンク１の物理レジスタエントリを記憶するために利用される。
【００３２】
リオーダバッファ２４は、（１）プロセッサ内に存在する命令を、プログラム順にしたがって記憶するとともに、（２）当該命令の書き込み先のアーキテクチャレジスタに、それまでに割り当てられていた物理レジスタＩＤが記憶されている。
【００３３】
上記（１）の機能について説明する。本実施の形態にかかるマイクロプロセッサにおいては、多段のパイプライン処理や、複数命令の同時実行を実現するために、ある瞬間の時刻を切り出しても、多くの命令が内部で処理されている。さらに、ダイナミックスケジューリング、すなわち命令の演算は、プログラムの順序どおりではなく、演算可能なものから随時実行されるような高速化が行われている。だたし、ダイナミックスケジューリングの下においても、論理的に順番通り命令演算処理を行ったのと同様に振舞う必要がある。そこで、リオーダバッファ２４は、プログラムの順序の命令列を記憶しておき、上記論理的に順番どおりの命令演算処理が行われたことを保障する。このために、ある命令が全ての処理を終えて、コミット（Ｃｏｍｍｉｔ）する際に、当該コミットは、リオーダバッファ２４に記憶された順に行われる。
【００３４】
また、上記リオーダバッファの（２）の機能について、以下の命令を例として説明する。たとえば、
Ｒ１←Ｒ２＋Ｒ３  （アーキテクチャレジスタＲ２とＲ３との加算結果を、アーキテクチャレジスタＲ１に書き込む。）
Ｒ４←Ｒ５−Ｒ１
Ｒ１←Ｒ６＋Ｒ４
という命令列があり、これらオペランドが物理レジスタにマッピングされて、以下のような命令列となる場合を考える。
【００３５】
Ｐ２０←Ｐ１１＋Ｐ１２
Ｐ２１←Ｐ１３−Ｐ２０
Ｐ２２←Ｐ１４＋Ｐ２１
この場合に、１番目の書き込み先の物理レジスタＰ２０が解放される（フリーとなる）のは、３番目の命令がコミットされた場合となる。これは、１番目および３番目の命令は、同じアーキテクチャレジスタを書き込み先として持っているが、３番目の命令がコミットされれば、今後いっさいＰ２０の値を使うことがないことが保証できるからである。この例では、リオーダバッファ２４には、３番目の命令の情報とＰ２０というレジスタＩＤが対となって記憶される。
【００３６】
また、状態テーブル２５は、物理レジスタエントリの状態が、物理レジスタＩＤごとに保持される。さらに、本実施の形態においては、後述するように、物理レジスタＩＤごとに、「ペア・ビット」と称するフラグを有している（図１３の符号１３０１参照）。
【００３７】
このように構成されたプロセッサ１０の動作について説明する。本実施の形態にかかるプロセッサ１０のパイプラインは従来のものと同様である（図３（ａ）の符号３００参照）。図３（ａ）および（ｂ）に示すように、まず、リネーム（Ｒｅｎａｍｅ）ステージにおいて、各命令のデスティネーションレジスタに対して、２バンク分の物理レジスタエントリが割り当てられる（ステップ３１１）。これは、リネーム（Ｒｅｎａｍｅ）ステージにおいては、その命令のオペランドの有効ビット幅がわからないためである。
【００３８】
マップテーブル１２、命令キュー１４など、物理レジスタＩＤを記憶するための構成部分においては、２バンク分のＩＤが記憶できるような構成となっている。図４（ａ）に示すように、従来のマップテーブルや命令キューは、物理レジスタＩＤ（ＰｒｅｇＩＤ）を記憶できるような構成であれば足りた（符号４０１参照）。これに対して、図４（ｂ）に示すように、本実施の形態において、物理レジスタＩＤフィールドには、バンク０およびバンク１のそれぞれの物理レジスタＩＤを記憶する必要がある（符号４１０参照）。
【００３９】
図４（ｂ）において、「ＰｒｅｇＩＤｘ（ｘ＝０，１）」は、バンクｘ用の物理レジスタＩＤであり、「Ｖｘ（ｘ＝０，１）」は、このレジスタエントリが有効か無効かを示すヴァリッドビットを示す。ヴァリッドビットＶｘがセットされている場合に、このオペランドは有効な値を保持し、セットされていない場合には有効な値を保持していない、つまり、全ビットが「０（ゼロ）」であることを意味する。さらに、本実施の形態においては、物理レジスタＩＤフィールドには、何れのバンクが下位ビット側であるかを示すＬＳＢＰ（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂａｎｋ  Ｐｏｉｎｔｅｒ）が設けられる（符号４１１参照）。
【００４０】
なお、本明細書において、「無効」ないし「無効化」とは、以下のような意味を有する。
【００４１】
一つは、レジスタが割り当てられて、その命令が実行されるまで、そのエントリが「無効」であるという意味（状態テーブルの「エントリ無効」など）である。これは、オペランドがまだ準備できていない（ｒｅａｄｙでない）という状態を意味し、従来のプロセッサでも存在する「レジスタ無効」という状態を意味する。
【００４２】
その一方、レジスタを後述するＥＲＤにより解放した場合に、レジスタのエントリを「無効」にするという意味もある。これは、本実施の形態にかかるレジスタファイルに特有な状態である。上述したヴァリッドビットに関連する「無効」は、後者に属する。
【００４３】
命令キュー１４から発行（Ｉｓｓｕｅ）された命令（ステップ３１２参照）に基づき、２つのバンクのレジスタファイル１６−１、１６−２からソースオペランドが読み出され（ステップ３１３）、ＡＬＵ１８にて命令が実行される（ステップ３１４）。実行結果（ＡＬＵ１８）の出力（２つのサブワード）は、それぞれ、０（ゼロ）検出器２０にも与えられる。０（ゼロ）検出器２０は、サブワードごとに、全てのビットが「０（ゼロ）」であるか否かを判断し、全てのビットが「０（ゼロ）」であった場合には、そのサブワードに割り当てられていた物理レジスタエントリが、ライトバック（Ｗｒｉｔｅｂａｃｋ）ステージで解放され、その物理レジスタＩＤが該当バンクのフリープールに書き込まれる（ステップ３１５）。
【００４４】
一般的に、物理レジスタエントリの解放は、その物理レジスタＩＤと関連付けられたアーキテクチャレジスタＩＤを、デスティネーションレジスタに持つ次の命令がコミット（Ｃｏｍｍｉｔ）した時点で実行される。ここで、本実施の形態において、物理レジスタエントリを早い段階で（つまり、コミットした次点より前に）解放することを、ＥＲＤ（Ｅａｒｌｙ  Ｒｅｇｉｓｔｅｒ  Ｄｅａｌｌｏｃａｔｉｏｎ）と称する。ＥＲＤにより、そのレジスタエントリを、別の命令のデスティネーションレジスタとして用いることができるため、レジスタファイルの使用効率を向上させることができ、その結果、レジスタファイルのサイズが小容量であっても高性能を達成することが可能となる。
【００４５】
次に、図５を参照して、本実施の形態にかかるレジスタファイル１６−１，１６−２からＡＬＵ１８のデータパスについてより詳細に説明する。図５に示すように、第１のレジスタファイル（バンク０）１６−１、および、第２のレジスタファイル（バンク１）１６−１の次段には、それぞれ、マルチプレクサ（ＭＵＸ）３２、３０が設けられる。ＭＵＸ３２、３０の次段には、それぞれ、さらに、ＭＵＸ３６、３４が設けられる。ＭＵＸ３６の出力が、ＡＬＵの一方の入力（ここでは「Ａ入力」）の下位のサブワードとなり、その一方、ＭＵＸ３４の出力が、ＡＬＵの一方の入力（Ａ入力）の上位のサブワードとなる。なお、図５においては、ＡＬＵの入力のうち一方（Ａ入力）に関するデータパスを示したが、他方（Ｂ入力）についても同様の構成を有している。
【００４６】
第１のレジスタファイル（バンク０）１６−１および第２のレジスタファイル（バンク１）１６−２は、ＰＲｅｇＩＤＡ０、ＰＲｅｇＩＤＡ１によって並列にアクセスされる。ここで、ＰＲｅｇＩＤＡ０、ＰＲｅｇＩＤＡ１は、それぞれ、Ａ入力にかかるバンク０用、バンク１用の物理レジスタＩＤを示す。
【００４７】
レジスタファイルの次段のＭＵＸ３２、３０は、それぞれ、ヴァリッドビットＶＡ０、ＶＡ１がセットされていれば、読み出された値を、そうでなければ全ビット「０（ゼロ）」の値を選択する。さらに次段のＭＵＸ３６、３４において、ＬＳＢＰＡ（つまり、Ａ入力用のＬＳＢＰ）に依存して、上位サブワードと下位サブワードとを入れ替える。たとえば、ＬＳＢＰＡがセットされていなければ、ＭＵＸ３４において、ＭＵＸ３０の出力が選択され、かつ、ＭＵＸ３６において、ＭＵＸ３２の出力が選択される。つまり、バンク１のサブワードが上位、バンク０のサブワードが下位となる。その一方、ＬＳＢＰＡがセットされていれば、ＭＵＸ３４において、ＭＵＸ３２の出力が選択され、ＭＵＸ３６において、ＭＵＸ３０の出力が選択される。つまり、バンク０のサーブサードが上位、バンク１のサブワードが下位となる。このようにして、２つのサブワードが結合された状態で、ＡＬＵの入力となる。
【００４８】
なお、上記ＭＵＸ３０〜３６およびインバータ３８は、本実施の形態において追加されるロジック回路であり、クリティカルパス遅延を増加させる可能性がある。しかしながら、この動作は、図５に示すように、実行（Ｅｘｅｃｕｔｅ）のステージで実現できる。現在のプロセッサにおいて、クリティカルパスは、発行（Ｉｓｓｕｅ）ステージや、レジスタリード（Ｒｅｇｉｓｔｅｒ  Ｒｅａｄ）ステージで生じることが多く、実行（Ｅｘｅｃｕｔｅ）ステージでの多少のロジック回路の追加は、プロセッサの周波数には悪影響を及ぼさない。さらに、元々ＡＬＵに備わっている符号拡張やオペランドシフトロジックを拡張することで上記動作を実現できるため、ハードウェアの複雑さの増大も問題とはならない。
【００４９】
なお、ＥＲＤは、プロセッサにおいて、以下の動作をなすことにより実現することができる。
（１）マップテーブル１２、リオーダバッファ２４、命令キュー１４、状態テーブル２５の、解放するレジスタエントリの無効化
（２）その上で、フリープール２２−１、２２−２に解放する物理レジスタＩＤの書き込み
これを実現する機構については、後に詳述する。
【００５０】
図２（ｂ）は、図２（ａ）の例を本実施の形態で実現した場合を示す図である。この例では、アーキテクチャレジスタＲ４の下位のサブワードは、第１のレジスタファイル（バンク０）１６−１の物理レジスタＰ１、上位のサブワードは、第２のレジスタファイル（バンク１）１６−２の物理レジスタＰ８２に割り当てられていると考える。したがって、第２のレジスタファイルおよび第１のレジスタファイルからそれぞれ読み出された、上位のサブワード（符号２２１−２）と、下位のサブワード（符号２２１−１）とを結合したものが、ＡＬＵの入力として与えられる。
【００５１】
また、もう一つの例では、アーキテクチャレジスタの下位のサブワードのみ、第１のレジスタファイル（バンク０）の物理レジスタＰ３に割り当てられると考える。この場合には、マルチプレクサの選択により、全ビットが「０（ゼロ）」である上位のサブワード（符号２２２−２）と、第１のレジスタファイルから読み出された下位のサブワード（符号２２２−１）とを結合したものが、ＡＬＵの入力として与えられる。
【００５２】
次に、ＥＲＤについてより詳細に説明する。ＥＲＤにより、物理レジスタのエントリをコミット時よりも早い段階で解放するために、上述したように、マップテーブル、リオーダバッファ、命令キューに登録されているレジスタエントリを無効化するのは簡単ではなく、ハードウェアの複雑化や消費電力の増大という問題が生じる。そこで、上記要素のレジスタ情報を無効化せずに、低コストでＥＲＤを実現するために、本実施の形態においては、以下の構成を備えた。
【００５３】
まず、サブワードが全て「０（ゼロ）」であった場合に、ＥＲＤによって解放できるエントリを、「最も下位のサブワード以外のバンクに割り当てられたエントリ」に制限する。ここで、オペランドの最も下位のサブワードに割り当てられたエントリを、マスタエントリ、それ以外の上位サブワードに割り当てられているエントリを、スレーブエントリと称する。
【００５４】
マスタエントリは、そのサブワードが全て「０（ゼロ）」であっても解放されることはないため、あるオペランドの生存期間中は、マスタエントリは必ず存在することが保証される。そこで、スレーブエントリが、ＥＲＤにより解放されたかどうかを、状態テーブル２５に記録される各オペランドのマスタエントリに付随する状態として管理する。
【００５５】
従来のプロセッサにおいては、物理レジスタの状態を管理するため、その各エントリに対して、４つの状態（フリー、エントリ無効、エントリ有効、および、アーキテクチャレジスタ（ＡＲ）状態）が定義されている。図１４は、従来のプロセッサの状態遷移を示す図である。図１４において、「ＡＲ」とは、「アーキテクチャレジスタ状態」を示す。アーキテクチャレジスタ状態とは、その時点で論理レジスタとして定義できるオペランドを持っている物理レジスタエントリであることを意味している。たとえば、命令セットで定義されているレジスタ、つまり、論理レジスタが、アウトオブオーダ実行などの目的で物理レジスタに変換されて実行される。ここで、論理レジスタ数が３２個のアーキテクチャの場合であれば、物理レジスタ数が何個あっても、論理的な動作という観点では、プロセッサのある時刻をみたときの、論理レジスタを持っている物理レジスタエントリは３２個存在する。つまり、「アーキテクチャレジスタ状態」は、このような論理的な状態を考えた場合に、論理レジスタの内容を持っている物理レジスタエントリを表わす状態となる。
【００５６】
より具体的に、
Ｒ１←Ｒ２＋Ｒ３
Ｒ４←Ｒ５−Ｒ１
Ｒ１←Ｒ６＋Ｒ４
という命令列があり、以下のように物理レジスタにマッピングされる場合を考える。
【００５７】
Ｐ２０←Ｐ１１＋Ｐ１２
Ｐ２１←Ｐ１３−Ｐ２０
Ｐ２２←Ｐ１４＋Ｐ２１
１番目の命令がコミットされた時点で、物理レジスタのＰ２０が、論理レジスタＲ１を表わすレジスタとして「アーキテクチャレジスタ状態」となる。また、３番目の命令がコミットされた時点で、物理レジスタのＰ２２が論理レジスタのＲ１を表わすレジスタとして「アーキテクチャレジスタ状態」となる。したがって、Ｐ２０は、リクレーム（解放）されて、フリーとなる。
【００５８】
図１３は、本実施の形態にかかるプロセッサの状態遷移を示す図である。図１３に示すように、本実施の形態においては、スレーブエントリが有効であるか（すなわちＥＲＤで解放されたかどうか）の状態を示す「ペア・ビット」という状態ビットが追加される（図３の符号１３０１参照）。したがって、状態テーブル２５には、物理レジスタＩＤごとに、その状態およびペア・ビットが含まれる。ペア・ビットは、そのエントリがマスタエントリである場合にのみ機能する。なお、ペア・ビットの幅は、スレーブエントリの数と同じ、すなわち、「バンク数−１」となる。このビットには、該当するスレーブエントリが有効であれば（つまり解放されていない場合には）「０（ゼロ）」、無効化された場合（つまり解放された場合）には「１」がセットされる。
【００５９】
図１３を参照して、本実施の形態にかかるプロセッサにおける状態遷移について説明する。「フリー」状態のレジスタが、ある命令のデスティネーションレジスタとして割り当てられた際に、その状態は、「エントリ無効」に移行する。同時に、マスタエントリのペア・ビットは「０（ゼロ）」に初期化される。命令が実行され、スレーブエントリがＥＲＤにより解放された場合には、当該スレーブエントリの状態は「フリー」状態となる。その一方、マスタエントリは、この時点では解放されることがないため、その状態は、「エントリ有効」に移項する。ここで、スレーブエントリが解放されたことを示すために、該当するペア・ビットに「１」がセットされる。
【００６０】
マップテーブル１２およびリオーダバッファ２４に登録されているレジスタエントリは、状態テーブル２５を参照することで管理することができる。前述したように、リネーム（Ｒｅｎａｍｅ）ステージで、論理レジスタから物理レジスタに変換が行われる際に、状態テーブル２５が参照されるため、スレーブエントリが有効であるかどうかは、状態テーブル２５に登録されているマスタエントリのペア・ビットを参照することにより判断可能である。
【００６１】
同様に、リオーダバッファ２４についても、コミット（Ｃｏｍｍｉｔ）ステージにおいて、状態テーブル２５を参照することで、スレーブエントリの有効性が判断でき、二重解放などを防止することも可能である。したがって、マップテーブル１２およびリオーダバッファの物理レジスタを無効化することなく、状態テーブル２５の状態を参照することで、解放されるエントリの状態を管理することが可能となる。
【００６２】
次に、命令キュー１４に登録されている命令のソースオペランドのエントリが、ＥＲＤによって解放された場合について説明する。命令キューの場合、発行（Ｉｓｓｕｅ）ステージで命令が発行されたすぐ後に、レジスタをアクセスする必要があるため、状態テーブル２５を参照する時間的な余裕がない。そこで、ＥＲＤによって解放する物理レジスタエントリに対して、実際に解放するにもかかわらず、一時的に、たとえば、「０（ゼロ）」の値を書き込む。これにより、既に命令キューにある命令のソースオペランドが解放されたエントリであった場合にも、「０（ゼロ）」の値を実際にレジスタエントリから読み出すことができる。したがって、命令キューの無効化という動作が不要となる。
【００６３】
しかしながら、以下の場合に限り、命令キューに登録されている、ＥＲＤで解放されたエントリの無効化が必要となる。
（１）解放されたエントリに割り当てられたオペランドをソースオペランドとする命令が、命令キューに存在する。
（２）解放された物理レジスタエントリが、後にフェッチされた命令のデスティネーションオペランドとして再び割り当てられる。
（３）上記（２）の命令が、（１）の命令よりも先に実行される。
【００６４】
この場合、（１）の命令は、レジスタから全ての「０（ゼロ）」の値を読み出す予定であったが、（２）の命令により、そのレジスタエントリが上書きされてしまう。したがって、この場合には、図５に示す前段のＭＵＸ（符号３０、３２参照）において、レジスタの値ではなく、全て「０（ゼロ）」の値が選択されるように、上記（１）の命令に該当するレジスタの有効ビットを無効化しておかなければならない。そこで、通常のウェイクアップ動作を拡張することで、この無効化を実現する。
【００６５】
従来のプロセッサにおけるウェイクアップ動作について簡単に説明する。命令キューに保存されている命令は、全てのオペランドがそろい次第発行されるが、全てのオペランドが揃ったかどうかを検出するために、ソースオペランドごとに準備状況を示すレディ・ビット（ｒｅａｄｙ  ｂｉｔ）が用意されている。ある命令が実行され、その演算結果のデスティネーションオペランドの準備ができた場合、そのオペランドの物理レジスタＩＤが、命令キュー中の全ての命令にブロードキャストされる。各命令は、ブロードキャストされた物理レジスタＩＤが、自分のソースレジスタの物理レジスタＩＤと一致した場合に、そのソースオペランドが準備できたことがわかり、レディ・ビットをセットする。
【００６６】
上述した（１）の命令を無効化しなければならないのは、既にレディ状態となっているレジスタエントリの物理レジスタＩＤが、再び、ウェイクアップによりブロードキャストされた場合のみである。そこで、命令キュー中の各命令について、レディ・ビットがセットされていないときに、そのレジスタＩＤがブロードキャストされ、レジスタＩＤが一致した場合には、レディ・ビットがセットされる。既に、レディ・ビットがセットされているにもかかわらず、再びレジスタＩＤがブロードキャストされた場合には、前述した上書きの問題が生じるため、該当する有効ビットを無効化する。このような構成を採用すれば、ウェイクアップ時のレジスタＩＤのブロードキャストのための機構自体を拡張する必要がなく、ハードウェアのコスト増大を著しく小さく実現することができる。
【００６７】
次に、本実施の形態にかかるプロセッサの評価について説明する。本実施の形態にかかるプロセッサの性能を調べるため、ＳｉｍｐｌｅＳｃａｌａｒ  Ｔｏｏｌ  Ｓｅｔ（“ＳｉｍｐｌｅＳｃａｌａｒ：Ａｎ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ｆｏｒ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｍｏｄｅｌｉｎｇ”、Ｔ．Ａｕｓｕｔｉｎ他、ＩＥＥＥ
Ｃｏｍｐｕｔｅｒ、Ｖｏｌ．３５、Ｎｏ．２、第５９頁〜第６７頁、２００２年２月）を用いて評価した。なお、レジスタアクセス評価のため、ＳｉｍｐｌｅＳｃａｌａｒのマイクロアーキテクチャモデルを以下のように変更した。
・ＲＵＵ（Ｒｅｇｉｓｔｅｒ  Ｕｐｄａｔｅ  Ｕｎｉｔ）方式から分散命令キュー方式への変更
・Ｍｅｒｇｅｄ  Ａｒｃｈｉｔｅｃｔｕｒａｌ  ａｎｄ  Ｒｅｎａｍｅ  Ｒｅｇｉｓｔｅｒ構成
・ＭＩＳＰ  Ｒ１００００やＡｌｐｈａ２１２６４とほぼ同様の構成。
【００６８】
ＳＰＥＣ  ＣＰＵ２０００を評価プログラムとして用いた。ＳＰＥＣ  ＣＰＵベンチマークには、「ｒｅｆインプットセット」を用い、最初の１０億命令実行後の２００万命令を評価した。また、Ｍｅｄｉａ  Ｂｅｎｃｈも評価プログラムとして用い、各プログラムの実行の最初から最後までを評価した。図７は、評価における仮定を示す。また、プロセッサは、０．１８μｍプロセス、１６リード／８ライトポートを仮定した。なお、０（ゼロ）検出器は、ＡＬＵの演算結果だけではなく、ロード命令のオペランドにも適用するものとして評価した。
【００６９】
図８は、レジスタファイルのサイズを変化させた場合の、ＩＰＣ（ｃｏｍｍｉｔｅｄ  Ｉｎｓｔｒｕｃｔｉｏｎ  Ｐｅｒ  Ｃｙｃｌｅ）の全プログラム平均を示すグラフである。横軸に、レジスタファイルサイズを示す。図中、「ｎｏｒｍａｌ」は、従来のプロセッサを表わし、「２−バンク」は、本実施の形態のように、レジスタファイルを２バンクで構成した場合、「４−バンク」は、レジスタファイルを４バンクで構成した場合を示す。図８に示すように、レジスタファイルのサイズが増加するにしたがってＩＰＣが向上していることがわかる。これは、レジスタエントリが多い場合、命令キューにおいて発行すべき候補の命令数が増え、よりＩＬＰが活用できるためである。レジスタファイルのサイズが十分でないと、リネーム（Ｒｅｎａｍｅ）ステージにおいて、フリープールからデスティネーションレジスタに割り当てるべきレジスタエントリがなくなり、割り当て可能なエントリが確保できるまで、キュー（Ｑｕｅｕｅ）ステージ以前のパイプラインをストールさせなければならない。その結果、少ないレジスタエントリではＩＬＰが十分に活用できなくなる。
【００７０】
しかしながら、ある程度までレジスタファイルのサイズが増えると、ＩＰＣは飽和し、全ての場合でほぼ同じＩＰＣに収束する。これは、レジスタファイルのサイズが性能上のボトルネックでなくなったときには、他の機構（命令キューなど）の制限から、それ以上にＩＰＣが向上しなくなるためである。
【００７１】
ここで注目すべき点は、本実施の形態においては、従来のプロセッサ（ｎｏｒｍａｌ）に比べて、レジスタファイルのサイズが小さくても高性能を達成できる点である。従来のプロセッサにおいては、９０或いは８０エントリ付近で最高ＩＰＣに到達するのに対して、２バンク、或いは、４０バンクにおいては、５０エントリ程度で、同じくらいのＩＰＣを達成することができる。本実施の形態（２バンク）やレジスタファイルを４バンクで構成した場合には、有効ビット幅の小さいオペランドが検出された時点で必要の無いレジスタエントリを解放するため、より多くのエントリを新たなオペランドのために用いることができ、効率的にレジスタを使うことができた結果である。
【００７２】
図９は、デアロケートできたレジスタサイズを示すグラフである。図９に示すように、本実施の形態（２バンク構成）では、毎サイクル６４ビット程度のストレージを解放している。また、４バンク構成においては、毎サイクル  ７０ビット余のストレージを解放している。
【００７３】
次に、プログラム毎の結果を見るため、ベンチマークプログラムごとの従来のプロセッサ（ｎｏｒｍａｌ）に対する性能向上率について説明する。図１０は、本実施の形態（２バンク構成）および４バンク構成の性能向上率を示すグラフである。図１０においては、本実施の形態（２バンク構成）でほぼ性能が飽和する、レジスタファイルのサイズが５０エントリの場合を示している。図１０に示すように、「１７６．ｇｃｃ」を除くすべてのベンチマークで、従来のプロセッサと比較すると、ＩＰＣが向上していることがわかる。特に、ＭｅｄｉａＢｒａｎｃｈのアプリケーションでは、性能向上率が高い。メディア系のアプリケーションでは、処理すべきデータの有効ビット幅が小さいため、２バンク構成或いは４バンク構成が有効に機能していることが理解できる。
【００７４】
図１１および図１２は、それぞれ、レジスタファイルのサイズを変化させた場合の、アクセスタイムおよび消費エネルギーを示すグラフである。アクセスタイムは、ＣＡＣＴＩ３．０（“ＣＡＣＴ３．０：Ａｎ  Ｉｎｔｅｇｒａｔｅｄ  Ｃａｃｈｅ  Ｔｉｍｉｎｇ，  Ｐｏｗｅｒ，  ａｎｄ  Ａｒｅａ  Ｍｏｄｅｌ”、ＷＲＬ  Ｒｅｓｅａｒｃｈ  Ｒｅｐｏｒｔ  ２００１／２、コンパックコンピュータ、Ｐ．Ｓｈｉｖａｋｕｍａｒ  Ｎ．Ｐ．Ｊｏｕｐｐｉ共著、２００１年８月）を、消費エネルギーは、Ｗａｔｔｃｈ（“Ｗａｔｔｃｈ：Ａ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  Ａｒｃｈｉｔｅｃｔｕｒａｌ−ｌｅｖｅｌ  Ｐｏｗｅｒ  Ａｎａｌｙｓｉｓ  ａｎｄ  Ｏｐｔｉｍｉｚａｔｉｏｎｓ”、Ｉｎ  ｐｒｏｃ．  ２７ｔｈ．  ＩＳＣＡ，第８３頁〜第９４頁、Ｄ．Ｂｒｏｏｋｓ他著、２０００年６月）を拡張して評価した。
【００７５】
図１１および図１２に示すように、レジスタファイルのサイズ（レジスタエントリ数）が増えるごとに、アクセスタイムおよび消費エネルギーが増加していることがわかる。また、多くのバンクに分割することで消費エネルギーが増加する傾向にあるが、これは、バンク毎にアドレスデコードの回路が必要であり、それによる消費エネルギーが増えるためである。
【００７６】
図８に示すように、飽和するまでのＩＰＣを達成するためには、従来のプロセッサでは９０エントリであるのに対して、２バンク構成或いは４バンク構成では、５０エントリであれば足りた。図１１および図１２から、９０エントリの従来のプロセッサと比較して、５０エントリの２バンク構成では、アクセス時間が２６％、消費エネルギーが２８％ほど改善されている。また、８０エントリの従来のプロセッサと比較しても、２バンク構成において、アクセスタイムおよび消費エネルギーが、それぞれ、２２％、２６％程度削減されている。
【００７７】
このように、本実施の形態（２バンク構成）や４バンク構成を採用することにより、ＩＰＣ性能を低下させずに、レジスタアクセス時間や消費エネルギーを大きく削減することが可能となる。
【００７８】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【００７９】
たとえば、前記実施の形態においては、ビット方向に２分割した２バンク構成の、２つのレジスタファイルが利用されたがこれに限定されるものではなく、２バンクより大きなバンク構成（たとえば、４バンク）を採用しても良い。この場合にも、本実施の形態と同様に、ＬＳＢＰおよびその値に応じて動作するマルチプレクサを含む、サブセット位置の判定機構により、それぞれの分割されたサブセットが、データ中のどこに位置するかが、プロセッサにおいて把握され、判定機構にしたがって、適切にサブセットが整列された状態で、ＡＬＵに入力される構成を採用するのが望ましい。
【００８０】
しかしながら、前記実施の形態のように、サブセット位置の判定機構が設けられていなくても良い。この場合には、２つのバンクのサブセットは、上位側のサブセットおよび会側のサブセットとして固定的に使用される。２バンクより大きなバンク構成を採用した場合にも同様である。
【図面の簡単な説明】
【００８１】
【図１】図１は、本発明の実施の形態にかかるプロセッサのブロックダイヤグラムである。
【図２】図２（ａ）は、従来のレジスタフファイルの構成の例を示す図、図２（ｂ）は、本実施の形態にかかるレジスタファイルの構成の例を示す図である。
【図３】図３（ａ）、（ｂ）は、それぞれ、本実施の形態にかかるプロセッサのパイプライン、および、当該プロセッサにて実行される処理を示す図である。
【図４】図４（ａ）は、従来の物理レジスタＩＤフィールド、図４（ｂ）は、ホン実施の形態にかかる物理レジスタＩＤフィールドの例を示す図である。
【図５】図５は、本実施の形態にかかるプロセッサのレジスタファイルおよびＡＬＵのデータパスを寄り詳細に示す図である。
【図６】図６は、従来のプロセッサのブロックダイヤグラムである。
【図７】図７は、本実施の形態にかかるプロセッサを評価するための仮定を示す表である。
【図８】図８は、レジスタファイルのサイズを変化させた場合の、ＩＰＣの全プログラム平均を示すグラフである。
【図９】図９は、デアロケートできたレジスタサイズを示すグラフである。
【図１０】図１０は、本実施の形態（２バンク構成）および４バンク構成の性能向上率を示すグラフである。
【図１１】図１１は、レジスタファイルのサイズを変化させた場合の消費エネルギーを示すグラフである。
【図１２】図１２は、レジスタファイルのサイズを変化させた場合の消費エネルギーを示すグラフである。
【図１３】図１３は、本実施の形態にかかるプロセッサおけるＥＲＤを実現したときの状態遷移を示す図である。
【図１４】図１４は、従来のプロセッサにおける状態遷移を示す図である。
【符号の説明】
【００８２】
１０      プロセッサ
１２      マップテーブル
１４      命令キュー
１６−１  第１のレジスタファイル
１６−２  第２のレジスタファイル
１８      ＡＬＵ
２０      ０（ゼロ）検出器
２２−１  第１のフリープール
２２−２  第２のフリープール
２４      リオーダバッファ
２５      状態テーブル
【図１】
2006139564.tif 000003
【図２】
2006139564.tif 000004
【図３】
2006139564.tif 000005
【図４】
2006139564.tif 000006
【図５】
2006139564.tif 000007
【図６】
2006139564.tif 000008
【図７】
2006139564.tif 000009
【図８】
2006139564.tif 000010
【図９】
2006139564.tif 000011
【図１０】
2006139564.tif 000012
【図１１】
2006139564.tif 000013
【図１２】
2006139564.tif 000014
【図１３】
2006139564.tif 000015
【図１４】
2006139564.tif 000016