(57)【要約】【課題】  同時マルチスレッディングを行なうCPUによるスレッド実行時間の予測精度を向上させる。【解決手段】  CPU内で、各スレッドの優先度が設定され、原則として上位優先度のスレッドが下位優先度のスレッドより優先的に処理されるよう、複数スレッドの命令の処理順序／頻度が制御される。それにより、同時処理されるスレッド間の資源の競合が調停される。加えて、CPU内で各スレッドの実行命令数の目標値が設定され、一定周期で各スレッドの周期当たり実行命令数がカウントされ、そして、実行命令数と目標値との比較に基づくフィードバック制御動作により、優先度を用いた命令処理順序／頻度が修正される。それにより、どのようなスレッドの組み合わせで複数スレッドの同時処理が行われても、各スレッドの実行時間（またはIPC）が所望値近傍に安定して保たれる。【選択図】図３
2006343872.tif 000002
【特許請求の範囲】
【請求項１】
複数のスレッドを並列的に処理するマルチスレッド中央演算装置において、
各スレッドの優先度を記憶する優先度記憶手段と、
前記各スレッドの優先度を用いて、前記複数のスレッドの命令の処理の順序または頻度を制御する第1の制御手段と、
各スレッドの命令実行目標を記憶する目標記憶手段と、
前記各スレッドの命令実行状態を監視し、前記実行命令状況と前記命令実行目標を用いたフィードバック制御動作により、前記複数のスレッドの命令の処理の順序または頻度を制御する第２の制御手段と
を備えたマルチスレッド中央演算装置。
【請求項２】
請求項１記載の装置において、
前記第1の制御手段が、前記優先度を用いて、前記複数のスレッドの命令のフェッチ、発行および実行のそれぞれの順序または頻度を制御するマルチスレッド中央演算装置。
【請求項３】
請求項１記載の装置において、
前記第1の制御手段が、通常の状況下では上位優先度のスレッドの命令が下位優先度のスレッドの命令より先に処理され、前記上位優先度のスレッドが処理資源を無駄にするか非効率的に使用するような所定状況下では、前記下位優先度のスレッドの命令が前記上位優先度のスレッドの命令より先に処理されるように制御を行うマルチスレッド中央演算装置。
【請求項４】
請求項１記載の装置において、
前記第２の制御手段が、前記フィードバック動作によって、前記複数のスレッドの命令のフェッチおよび／または発行の順序または頻度を制御するマルチスレッド中央演算装置。
【請求項５】
請求項１記載の装置において、
前記第２の制御手段が、或るスレッドの前記命令実行状態が前記命令実行目標を満たさない場合、前記或るスレッドより下位の優先度をもつ他のスレッドの命令の処理頻度を抑制するマルチスレッド中央演算装置。
【請求項６】
請求項１記載の装置において、
前記第２の制御手段が、前記フィードバック動作によって、前記第1の制御手段の制御動作を変化させるための操作値を調整するマルチスレッド中央演算装置。
【請求項７】
請求項６記載の装置において、
前記第２の制御手段が、或るスレッドの前記命令実行状態が前記命令実行目標を満たさない場合、前記或るスレッドの命令の処理の頻度を増加させるように前記操作値を変化させ、前記操作値を変化させた後に、前記或るスレッドの前記命令実行状態に前記操作値の変化に応じた改善が現れない場合、前記操作値を元に戻すマルチスレッド中央演算装置。
【請求項８】
同時マルチスレッディングの制御方法において、
各スレッドの優先度をもつステップと、
前記各スレッドの優先度を用いて、前記複数のスレッドの命令の処理の順序または頻度を制御するステップと、
各スレッドの命令実行目標をもつステップと、
前記各スレッドの命令実行状態を監視するステップと、
前記各スレッドの前記命令実行状態と前記命令目標を用いたフィードバック制御動作により、前記複数のスレッドの命令の処理の順序または頻度を制御するステップと
有する同時マルチスレッディング制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には中央演算装置（CPUまたはMPU）（以下、単に「プロセッサ」と呼ぶ）に関わり、特に、プロセッサ内で複数のスレッドを並列処理できるマルチスレッドプロセッサおよび同時マルチスレッディングを制御するための方法に関する。
【０００２】
本発明は、特に、各種ロボット、自動車、プラント、ホームオートメーション等の実時間処理を行うアプリケーションにおいて、各スレッドに課された時間制約を守りつつプロセッサのスループットを向上するために好適なマルチスレッドプロセッサに関する。
【背景技術】
【０００３】
実時間処理を行うリアルタイムシステムでは、各スレッドの時間制約を守るために、オペレーティングシステム（OS）のスケジューラは各スレッドの実行周期や時間制約により、各スレッドに優先度を付与する。そして、付与された優先度を基に、優先度の高いスレッドから順番に演算資源を割り当てて実行を行う。ここで、「スレッド」とは、プログラムの実行単位であり、通常、一つのアプリケーションプログラムは多数のスレッドから構成される。
【０００４】
図１に、一時に１スレッドのみを実行する従来のシングルスレッドプロセッサを用いて実時間処理を行った場合の例を示す。この例では、スレッド#0の優先度が最も高く、スレッド#7の優先度が最も低いとする。また、リリース時刻はそのスレッドが実行可能になる時刻、期限はそのスレッドの時間制約（その実行が完了されるべき最終期限）を示す。
【０００５】
図１に示された例では、最初にスレッド#1、スレッド#2およびスレッド#3が実行可能になる。これら実行可能なスレッド#1、#2および#3の中で最も優先度の高いスレッド#1にプロセッサ資源が与えられ、スレッド#1が実行される。スレッド#1の実行が完了すると、次に優先度の高いスレッド#2の実行を行うために、プロセッサ外のメモリとプロセッサとの間でコンテキストスイッチが起こる。コンテキストスイッチでは、現在実行しているスレッド#1のコンテキスト（すなわち、そのスレッドを実行するために必要なプロセッサ内のプログラムカウンタ、レジスタファイル、ステータスレジスタ等の各種資源）をプロセッサ外のメモリに退避させ、次に実行するスレッド#2のコンテキストをメモリからプロセッサ内に復帰させる。その後、プロセッサはスレッド#2の実行を開始する。スレッド#2の実行が完了すると、コンテキストスイッチが起こり、スレッド#2のコンテキストがメモリに退避し、スレッド#3のコンテキストがメモリからプロセッサ内に復帰した後、スレッド#3の実行が開始される。スレッド#3の実行中に、より優先度の高いスレッド#0が実行可能になると、スレッド#3の実行が中断され、コンテキストスイッチが起こり、スレッド#3のコンテキストがメモリに退避し、スレッド#0のコンテキストがプロセッサ内に復帰して、スレッド#0の実行が先に行われる。スレッド#0の実行が完了すると、コンテキストスイッチにより、スレッド#0のコンテキストがメモリに退避し、スレッド#3のコンテキストがプロセッサ内に復帰することにより、中断していたスレッド#3の実行が再開する。
【０００６】
このように従来のシングルスレッドプロセッサを用いた処理では、優先度の高いスレッドの実行が完了した場合や、現在実行しているスレッドよりもより優先度の高いスレッドが実行可能になった場合は、コンテキストスイッチが発生する。OSは、現在実行しているスレッドのコンテキストをメモリに退避し、次に実行するスレッドのコンテキストをプロセッサ内に復帰させなければならない。リアルタイムシステムでは、このコンテキストスイッチが大きなオーバヘッドとなる。一方、コンテキストスイッチのオーバヘッドを削減する技術として、プロセッサ内で複数のスレッドを並列処理するマルチスレッドプロセッサがある。マルチスレッドプロセッサは、プロセッサ内に複数スレッド分のコンテキストを保持し、これらをプロセッサ内のハードウェアで切り替えながらそれぞれのスレッドを実行するため、コンテキストスイッチを行わずに複数のスレッドを実行することが可能である（例えば、特許文献１参照）。
【０００７】
また、実時間処理に適したマルチスレッドプロセッサのスループット向上のための別の制御技術として、各スレッドに割り当てられた優先度に応じて、複数のスレッドの命令の実行順序をリザベーションステーションにて入れ替える技術が知られている（例えば、特許文献２参照）。
【０００８】
【特許文献１】特開２００４−２２００７０号公報
【特許文献２】特開２００４−２９５１９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
マルチスレッドプロセッサにおいて、複数のスレッドを並列に実行するとき、キャッシュアクセスや演算器等の演算資源においてスレッド間の競合が起こり得る。演算資源の競合が起こると、1スレッド単体の実行時間が増加する。そして、プロセッサ内で並列的に実行される複数のスレッドの組み合わせが異なれば、演算資源の競合の仕方や頻度が異なってくるため、各スレッドの実行時間が異なってくる。その結果、各スレッドの実行時間の予測精度が低下する。特にリアルタイムシステムでは、各スレッドに時間制約があるため、各スレッドの実行をその時間制約内に完了させ得るよう、スケジューラによりスレッド実行のスケジューリングがなされる。しかし、マルチスレッドプロセッサを用いたシステムでは、上記理由から時間予測精度が低いために、スレッドの時間制約を守れるようなスケジューリングが難しい。
【００１０】
従って、本発明の目的は、マルチスレット゛プロセッサにおいて、時間予測精度の低下の原因であるスレッド実行時間の変動を抑制することにある。
【００１１】
本発明の別の目的は、マルチスレッドプロセッサのスループットを向上させることにある。
【課題を解決するための手段】
【００１２】
本発明に従えば、複数のスレッドを並列的に処理するマルチスレッド中央演算装置は、各スレッドの優先度を記憶し、各スレッドの優先度を用いて、複数のスレッドの命令の処理の順序または頻度を制御する。加えて、このマルチスレッド中央演算装置は、各スレッドの命令実行目標を記憶し、各スレッドの時間当たりの実行命令数を監視し、そして、実行命令数と目標値を用いたフィードバック制御動作により、複数のスレッドの命令の処理の順序または頻度を制御する。
【００１３】
このマルチスレッド中央演算装置によれば、各スレッドに付与された優先度を用いた命令処理順序／頻度の制御により、命令処理に必要な各種資源のスレッド間での競合が、各スレッドの優先度に応じて調停される。それに加えて、各スレッドの命令実行状態(例えば所定周期当りの実行命令数、IPCあるいはCPIなど）の監視に基づくフィードバック制御により、同時に処理されている他のスレッドからの影響が減り、各スレッドの実行時間の変動が抑制される。引いては、各スレッドの実行時間の予測精度の向上につながり、実時間処理の時間制約を守りつつ、プロセッサ全体のスループットを向上することが可能となる。
【００１４】
好適な実施形態では、パイプラインの命令フェッチ、発行および実行のそれぞれのステージにおける順序／頻度が、各スレッドの優先度に基づいて制御される。原則として、上位優先度のスレッドの命令が下位優先度のスレッドの命令より先に処理されるように制御が行われる。しかし、上位優先度のスレッドが処理資源を無駄にするか、または非効率的に使用するような所定の状況下（例えば、キャッシュミスの発生、分岐予測ミスの発生または高い発生可能性、またはリザベーションステーションの占領など）では、下位優先度のスレッドの命令が上位優先度のスレッドの命令より先に処理されるように制御される。
【００１５】
また、好適な実施形態では、各スレッドの命令実行状態を制御するために、特に命令フェッチおよび／または発行のステージにおいて、優先度による制御動作に変化が加えられる。例えば、或るスレッドの命令実行状況が目標を満たさない場合、そのスレッドより下位の優先度をもつ他のスレッドの命令のフェッチおよび／または発行の頻度が抑制される。優先度による制御動作を変化させるために、所定の操作値が増減される。しかし、その操作値を変化させても、その変化に応じた命令実行状態の改善が現れない場合には、操作値が元に戻される。
【発明の効果】
【００１６】
本発明によれば、マルチスレッドプロセッサにおいて、各スレッドの実行時間またはIPCの変動を小さくすることが可能となる。これにより、実時間処理のためのより良いスケジューリングが容易となり、ひいては、プロセッサ全体のスループットの向上に貢献できる。
【発明を実施するための最良の形態】
【００１７】
以下、図２から図６を参照して、本発明の一実施形態について説明する。
【００１８】
図２は、本発明の一実施形態にかかるマルチスレッドプロセッサの主要部のブロック構成を示す。
【００１９】
図２に示されるマルチスレッドプロセッサ(以下、単に「プロセッサ」という）１０は、SMT（Simultaneous Multi Threading：同時マルチスレッディング）アーキテクチャを採用し、複数（例えば最大８つ）のスレッドを同時に処理することができるとともに、より多く（例えば最大４０）のスレッドのコンテキストを内部に保持して、外部のメモリとの間でのコンテキストスイッチなしに多数のスレッドを処理することができる。図示のように、このプロセッサ１０は発行ユニット１２、キャッシュユニット１４および実行ユニット１６を備える。これらのユニット１２，１４および１６の基本的な機能は次のとおりである。キャッシュユニット１４は、外部のメモリ（図示省略）にアクセスし、その外部メモリから命令をフェッチしてキャッシュし、外部メモリからデータ（オペランド）をロードしてキャッシュし、また、ストアされるべきデータをキャッシュして外部メモリへストアする。実行ユニット１６は、メモリアクセスユニットや各種の演算器等の演算資源を有し、発行ユニット１２から発行された命令をアウトオブオーダで実行し、命令の実行結果を発行ユニット１２へライトバックする。発行ユニット１２は、複数のスレッドを並列的に処理できるよう、複数のスレッドのコンテキストを内部で保持し、それら複数のスレッドの命令をキャッシュユニット１４からフェッチし、その命令をデコードし、その命令（その命令のデコード結果の動作指示）を実行ユニット１６へ発行し、実行ユニット１６からライトバックされた命令実行結果を受け、そして、その命令をコミットする。
【００２０】
上述した基本的な機能の上に、このプロセッサ１０は、本発明の原理に従う次のような特筆すべき２つの機能を有する。一つは、優先度による調停機能である。すなわち、それは、複数のスレッドに予め割り当てられた優先度に基づいて複数のスレッド間での資源の競合を調停する機能である。別の一つは、各スレッドのIPC（Instructions per Clock Cycle: クロックサイクル当り命令実行数）の変動を抑えできるだけ所望値で一定に保つためのIPC制御機能である。すなわち、それは、スレッド毎の一定時間当たりの実行命令数を監視し、各スレッドの実行命令数が各スレッドに予め割り当てられた実行命令数の目標値にできるだけ一致するように、複数のスレッドの命令の実行頻度を調整する機能である。この２つの機能は融合され同時に働く。ここで、各スレッドの優先度や命令実行数目標値は、例えば、OSのスケジューラやプログラマからプロセッサ１０に対して設定される。
【００２１】
優先度による調停機能を実現するために、発行ユニット１２は、各スレッドに予め割り当てられた優先度を予め記憶する。その優先度はキャッシュユニット１４および実行ユニット１６にも通知される。発行ユニット１２、キャッシュユニット１４および実行ユニット１６は、個別に、複数のスレッドの優先度に基づいて、複数のスレッドのそれぞれに提供される命令フェッチ、発行、実行およびコミットのための資源の量を制御する。なお、この目的のために、上位優先度のスレッドの実行が下位優先度のスレッドにより阻害されないようにするだけでなく、上位優先度のスレッドの性能を低下させずに、下位優先度のスレッドも実行されるような制御方法が実装される。
【００２２】
さらに、IPC制御機能を実現するために、発行ユニット１２は、各スレッドに予め割り当てられた実行命令数の目標値を予め記憶する。発行ユニット１２は、一定の繰返し周期でスレッド毎の実際の実行命令数（コミットされた命令の数）をカウントし、それを予め記憶している目標値と比較する。或るスレッドの実際の実行命令数が目標値に達してなければ、そのスレッドの命令のフェッチおよび／または発行の頻度が増えるように、上述した優先度による資源競合調停の制御をフィードバック制御により修正する。例えば、或るスレッドの命令のフェッチおよび／または発行の頻度を増加させるために、そのスレッドより下位優先度のスレッドのフェッチおよび／または発行が抑制される。逆に、例えば、或るスレッドの命令のフェッチおよび／または発行の頻度を低下させるために、そのスレッドより下位優先度のスレッドのフェッチおよび／または発行が促進される。
【００２３】
以下、図２を参照しつつ、プロセッサ１０のより具体的な構成と機能、とりわけ、優先度による調停機能とIPC制御機能に関わる部分に重点をおいて説明する。
【００２４】
発行ユニット１２は、スレッドコントロールユニット２０、同時処理可能なスレッドの最大数分（例えば８つ）のPC（プログラムカウンタ）コントロールユニット２２、フェッチスレッドセレクタ２４、命令デコーダ２６、命令アナライザ２８、命令バッファ３０、命令発行セレクタ３２、リネームレジスタ３４、同時処理可能なスレッドの最大数分（例えば８つ）のレジタファイル３６、およびリオーダバッファ４０を有する。キャッシュユニット１４は、命令MMU(メモリマネジメントユニット）４２、命令キャッシュ４４、命令ヴィクティムキャッシュ４６、命令ウェイトバッファ４８、データMMU５０、データリード／ライトバッファ５２、データキャッシュ５４、データヴィクティムバッファ５６およびデータウェイトバッファ５８を有する。実行ユニット１６は、所定の複数個（例えば４つ）のリザベーションステーション６０と各種の演算資源６２−８０を有する。演算資源６２−８０には、メモリアクセスユニット６２、複数のブランチユニット６４、整数除算器６６、複数の整数演算ユニット６８、FP（浮動小数点）除算器７０、複数のFP演算ユニット７２、６４ビット整数演算ユニット７４、ベクタ整数演算ユニット７８およびベクタFP演算ユニット８０などがある。同時処理されるスレッドが同じ演算資源を同時に使おうとする可能性は低いので、リザベーションステーションの個数や各演算資源の個数は、同時処理可能なスレッドの最大数（例えば８つ）よりは少なく、資源の無駄な冗長を避けている。
【００２５】
以下では、命令が処理される流れにほぼ沿って、各部の機能と動作を説明する。
【００２６】
スレッドコントロールユニット２２は、複数スレッドの並列的な処理を制御するためのコアとして働くユニットであり、その内部に複数のスレッドの優先度を記憶し保持し、そして、その優先度をプロセッサ１０全体に配布する。ここで、スレッドコントロールユニット２２に記憶され得る優先度のスレッド数は、好ましくは、このプロセッサ１０が内部に保持し得るコンテキストのスレッドの最大数（例えば４０）以上である。複数のPCコントロールユニット２２は、プロセッサ１０内で同時処理され得る複数のスレッドにそれぞれ割り当てられ、それぞれのスレッドからのプログラムカウンタの値をフェッチスレッドセレクタ２４に与える。複数スレッド間の競合は、まず命令キャッシュアクセスにおいて生じる。そこで、フェッチスレッドセレクタ２４は、命令キャッシュアクセスを要求しているスレッドの中から、各スレッドの優先度を用いて、一つのスレッドを選択し、選択されたスレッドのプログラムカウンタを命令MMU(メモリマネジメントユニット）４２に送る。ここで、フェッチスレッドセレクタ２４は、原則として命令キャッシュアクセスを要求しているスレッドの中で最上位優先度をもつスレッドを選択する。しかし、常に最上位優先度のスレッドが選択されるわけではなく、最上位優先度のスレッドの実行が圧迫されない所定の状況下では、最上位優先度のスレッドに代えて下位優先度のスレッドが選択される場合もある。
【００２７】
命令MMU４２は、命令キャッシュ４４をアクセスして、上記選択されたスレッドの命令を命令キャッシュ４４から命令デコーダ２６に渡させる。ここで命令キャッシュミスが発生した場合、外部のメモリ（図示省略）をアクセスしキャッシュラインを読み込む必要がある。メモリアクセスはキャッシュアクセスに比べてレイテンシが大きいため、キャッシュミスが続くと、命令ウェイトバッファ４８にて複数のメモリアクセス要求が待たされる。この場合、命令ウェイトバッファ４８は、各スレッドの優先度に基づいて、原則として最上位優先度のスレッドのメモリアクセス要求から先に処理する。それにより、より上位の優先度をもつスレッドの実行が優先される。しかし、常に優先度の高いスレッドのメモリアクセス要求が優先されるわけではなく、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドよりも下位優先度のスレッドのメモリアクセス要求が先に処理される場合もある。
【００２８】
命令キャッシュ４４から命令デコーダ２６へ、複数（キャッシュの１ライン分である例えば８つ）の命令が同時に送られる。命令デコーダ２６は、命令キャッシュ４４から同時にフェッチした複数命令を同時にデコードし、それら複数命令のデコード結果（これも、以下の説明では便宜上「命令」という）は同時に命令バッファ４０に入れられる。その際、命令アナライザ２８が、同時デコードされた複数命令の命令タイプ（どのスレッドの命令であるか、どの演算資源を使用するか、および命令間の依存関係はどうかなどの判断を行うために必要な、スレッド、オペコードおよびオペランドなどに関する情報）を把握し、その命令タイプを命令発行セレクタ３２に与える。命令発行セレクタ３２は、リオーダバッファ４０、リネームレジスタ３４およびリザベーションステーション６０の空きや、命令バッファ３０内の命令間の依存関係を調べ、その結果に基づいて、命令バッファ３０の中からリザベーションステーション６０に発行可能な命令を選択する。所定数（同時処理可能なスレッド最大数より少ない例えば４つ）の命令が同時に命令バッファ３０から発行され得る。その際、命令発行セレクタ３２は、命令バッファ３０内に発行可能な命令が複数（とりわけ、上記所定数（４つ）より多く）ある場合、各スレッドの優先度に応じて、原則としてより上位の優先度をもつスレッドの命令から先に発行する。しかし、後述するように、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドよりも下位の優先度のスレッドの命令が先に発行される場合もある。
【００２９】
各リザベーションステーション６０に接続された整数演算ユニット６８やFP演算ユニット７２等の各種の演算ユニットについても、スレッド間で競合が発生する。そこで、各リザベーションステーション６０でも、各スレッドの優先度を用いた競合の調停が行なわれる。各リザベーションステーション６０は、そこで待機している命令を、演算に必要なオペランドがそろった命令から順に、アウトオブオーダで演算ユニットに送る。その際、各リザベーションステーション６０は、複数の命令が同時に演算可能になった場合、各スレッドの優先度に基づいて、原則として優先度の高いスレッドの命令から先に演算ユニットに送ることにより、優先度の高いスレッドの実行を優先する。しかし、常に優先度の高いスレッドの命令が優先されるわけではなく、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドに代えて下位の優先度のスレッドの命令が先に演算ユニットに送られる場合もある。
【００３０】
データキャッシュアクセスにおいても競合が発生する。そこで、データリード／ライトバッファ５２は、各スレッドの優先度に基づいて、原則として上位優先度のスレッドのデータキャッシュアクセスから先に実行することにより、上位優先度のスレッドの実行を優先する。しかし、常に優先度の高いキャッシュアクセスが優先されるわけではなく、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドに代えて下位の優先度のスレッドのキャッシュアクセスが先に処理される場合もある。また、データキャッシュミスが起こった場合、外部のメモリ（図示省略）をアクセスしキャッシュラインを読み込む必要があるが、命令キャッシュの場合と同様に、データウェイトバッファ５８が、各スレッドの優先度に基づいて、原則として上位優先度のスレッドのメモリアクセス要求から先に処理することにより、優先度の高いスレッドの実行を優先する。しかし、ここでも、常に優先度の高いスレッドのメモリアクセスが優先されるわけではなく、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドに代えて下位の優先度のスレッドのメモリアクセスが先に処理される場合もある。
【００３１】
リオーダバッファ４０は、アウトオブオーダで実行された命令の実行結果を一時的に保持し、インオーダで命令をコミットする。所定数（同時処理可能なスレッド最大数より少ない例えば４つ）の命令が同時にコミットされ得る。その際、リオーダバッファ４０は、複数（とりわけ、上記所定数（４つ）より多く）の命令がコミット可能であれば、原則として上位優先度のスレッドの命令から先にコミットする。しかし、ここでも、常に優先度の高いスレッドが優先されるわけではなく、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のスレッドに代えて下位の優先度のスレッドが先にコミットされる場合もある。
【００３２】
レジスタファイル３６は、同時処理され得るスレッド最大数（例えば８つ）だけ存在し、それぞれ、同時処理される複数のスレッドに割り当てられる。各レジスタファイル３６には、各スレッドのコンテキストが格納される。コンテキストキャッシュ３８は、より多くのスレッド数（例えば３２スレッド）分のコンテキストが格納できる。コンテキストキャッシュ３８内の任意のスレッドのコンテキストと任意のレジスタファイル３６内のコンテキストとを高速に交換することができる。従って、このプロセッサ１０では、レジスタファイル３６の数（例えば８つ）のスレッドがコンテキストスイッチを行うことなしに処理でき、コンテキストキャッシュ３８がサポートするスレッド数（例えば３２個）のスレッドが、高速にコンテキストスイッチを行うことができる。
【００３３】
上述したように、プロセッサ１０内における命令のフェッチ、発行、実行およびコミットのステージにそれぞれ関わる諸ユニットにおいて、複数のスレッドの優先度を用いて、スレッド間での資源競合を調停するための命令の処理順序または処理頻度の制御が行われる。これにより、上位優先度のスレッドが優先的に実行され、かつ、上位優先度のスレッドの性能を低下させないようにして下位優先度のスレッドも実行されることになる。
【００３４】
さて、上記制御に加えて、各スレッドの実行時間の予測を容易にするために、各スレッドのIPCの変動を抑えてそれをできるだけ所望値の近傍に維持するためのIPC制御が、プロセッサ１０で行われる。この実施形態では、スレッドコントロールユニット２０、フェッチスレッドセレクタ２４および命令発行セレクタ３２が、このIPC制御に直接的に関与する。スレッドコントロールユニット２０は、複数のスレッドの各々に予め割り当てられた実行命令数の目標値を記憶し保持する。ここで、スレッドコントロールユニット２２に記憶され得る目標値のスレッド数は、好ましくは、このプロセッサ１０が内部に保持し得るコンテキストのスレッドの最大数（例えば４０）以上である。スレッドコントロールユニット２０は、一定の監視周期毎（例えば、数百クロックサイクル毎）にスレッド毎の実際の実行命令数（IPC x １監視周期中のクロックサイクル数）をカウントし、カウントされた実行命令数と記憶されている目標値とを比較し、そして、その比較の結果に基づくフィードバック制御の方法で、フェッチスレッドセレクタ２４および命令発行セレクタ３２による各スレッドの命令フェッチと命令発行の頻度を制御する。
【００３５】
図３は、このIPC制御を行なう機構の構成を示す。
【００３６】
図３において、ブロック１００は、プロセッサ１０内における上述された複数スレッドの命令のパイプライン処理を行う機構を示し、そこでは、上述されたように、各スレッドの優先度を用いて、スレッド間の資源競合の調停制御が行われる。IPC制御機構は、実行命令数監視部１０２、比較部１０４および制御関数部１０６を有し、図２に示されたスレッドコントロールユニット２０に組み込まれる。
【００３７】
実行命令数監視部１０２は、一定の監視周期毎に、並列処理されている複数スレッドの各々の実行命令数をカウントする。比較部１０４は、スレッド毎に、カウントされた実際の命令実行数と、予め記憶されている目標値とを比較する。後述するように、この実施形態では、後述するような状態遷移に従う制御を行う関係から、比較部１０４は、実際の命令実行数と目標値との比較だけでなく、次のような比較も行なう。すなわち、スレッド毎に、前回の監視周期において実際の実効命令数が実行されるべきであった命令数に足りなかった命令数（繰越命令数）が計算され、その繰越命令数と目標値とが加算されて繰越残値（つまり、現在の監視周期で実行されるべきである命令数）が計算され、その繰越残値と今回の実際の命令実行数とが比較される。
【００３８】
制御関数部１０６は、比較部１０４による比較の結果に基づいて、所定のフィードバック制御動作を行って、各スレッドの命令フェッチと命令発行の頻度を調節するための操作値を決定し、その操作値をパイプライン処理機構１００に適用する。ここで、フィードバック制御動作には、PD制御やPID制御などを用いることも可能であるが、この実施形態では、後に図４を参照して説明されるような、状態遷移に従って操作値を制御する制御動作が採用される。操作値としては、後に図４を参照して説明されるような、スレッド毎に用意されたインフレ値というパラメータが採用される。
【００３９】
制御関数部１０６から出力されるスレッド毎のインフレ値は、パイプライン処理機構１００中の命令フェッチと命令発行の頻度を制御するユニット、すなわち、この実施形態では図２に示されたフェッチスレッドセレクタ２４および命令発行セレクタ３２に与えられる。各スレッドのインフレ値は、各スレッドの実行命令数と目標値および繰越残値との比較結果に応じて、制御関数部１０６により所定の可変レンジ内で漸次的に増減される。インフレ値が増加すると命令フェッチや命令発行の頻度が増し、インフレ値が低いと命令フェッチや命令発行の頻度が減少するように、フェッチスレッドセレクタ２４および命令発行セレクタ３２が、インフレ値に応じて、優先度を用いた制御動作を調整する。例えば、或るスレッドのインフレ値が増加すると、フェッチスレッドセレクタ２４および命令発行セレクタ３２は、それぞれ、そのスレッドより下位の優先度をもつスレッドの命令フェッチおよび命令発行の頻度を抑制し、その結果、そのスレッドの命令フェッチおよび命令発行の頻度が増える。逆に、例えば、或るスレッドのインフレ値が減少すると、フェッチスレッドセレクタ２４および命令発行セレクタ３２は、それぞれ、そのスレッドより下位の優先度をもつスレッドの命令フェッチおよび命令発行の頻度を促進させ、その結果、そのスレッドの命令フェッチおよび命令発行の頻度が低下する。
【００４０】
図４は、制御関数部１０６の状態遷移とインフレ値増減の動作を示す。
【００４１】
制御関数部１０６は、複数のスレッドのそれぞれについて図４に示された動作を並列的に行う。図４において、「目標値」は、上述したように、１監視周期における実行命令数の目標値（= IPC目標値 x１監視周期中のクロックサイクル数)であり、各スレッドについて予め指定された値である。「繰越残値」は、現在の監視周期で実行(コミット）されるべき命令数(= 前回の周期で実行されるべきであった命令数 + 目標値 − 前回の周期で実際に実行した命令数)である。
【００４２】
「ノーマル」１１０は、実際の実行命令数が目標値を満たしており、繰越残値も完全に消化している状態であり、換言すれば、そのスレッドの性能が保証されている状態である。今まで状態が「ノーマル」１１０であったところ、現在の監視周期で実行した命令数が繰越残値と目標値の両方を満たせなかった場合、状態は「IPCフェイリング」１１２に遷移し、他方、繰越残値のみを満たせなかった場合には、状態は「リクエストフェイリング」１１４に遷移する。また、ある回数以上の監視周期にわたり「ノーマル」１１０が続いた場合には、インフレ値が減少され、その結果、そのスレッドの命令フェッチおよび命令発行の頻度が抑制される。
【００４３】
「リクエストフェイリング」１１４は、実際の実行命令数が目標値を満たしているが、繰越残値を満たしていない状態である。この状態がある回数以上の監視周期にわたり続く場合、インフレ値が増加され、そして、状態は「リソースアップチェック」１１６に遷移する。他方、「リクエストフェイリング」１１４において、現在の実行命令数が繰越残値を満たした場合は、状態は「ノーマル」１１０へ遷移する。
【００４４】
「IPCフェイリング」１１２は、実際の実行命令数が繰越残値と目標値を共に満たしていない状態である。この状態がある回数以上の監視周期にわたり続く場合、インフレ値が増加させられ、状態は「リソースアップチェック」１１６に遷移する。他方、「IPCフェイリング」１１２において、繰越残値と目標値が共に満たされた場合は、状態は「ノーマル」１１０に遷移する。
【００４５】
「リソースアップチェック」１１６は、インフレ値を増加させた後、インフレ値の増加に見合うIPCの向上があったかどうかをチェックするための状態である。この状態において、前回の監視周期と比較した現在の監視周期の実行命令数の増分が予め設定された閾値を上回ったが、まだ繰越残値が満たされていない場合は、インフレ値がさらに増加される。他方、繰越残値が満たされた場合は、状態は「ノーマル」１１０に遷移する。また、「リソースアップチェック」１１６において、上記増分が上記閾値を上回らなかった場合は、インフレ値は減少させられ、状態は「リソースダウン」１１８に遷移する。
【００４６】
「リソースダウン」１１８は、インフレ値の増加に見合ったIPCの向上が認められなかった場合に相当する状態である。この状態に入ると、インフレ値が減少させられ、状態は「リソースダウンチェック」１２０に遷移する。
【００４７】
「リソースダウンチェック」１２０は、インフレ値を減少させた後、IPCが大幅に低下していないかどうかをチェックするための状態である。この状態において、前回の監視周期と比較した現在の監視周期の実行命令数の増分が予め設定された閾値を上回った場合、インフレ値が増加される。他方、上記増分が上記閾値を上回らなかった場合は、インフレ値は増加されず、状態は「IPCフェイリング」１１２か「リクエストフェイリング」１１４に遷移する。状態が「IPCフェイリング」１１２と「リクエストフェイリング」１１４のいずれに遷移するかは、実行命令数と目標値および繰越残値との比較結果により決まる。
【００４８】
以上のように、各スレッドについて、IPCが所望値を満たせていない状態が続くと、インフレ値が増加させられる。ただし、インフレ値を増加した場合であっても、その増加に見合ったIPCの向上が得られない場合は、インフレ値を元に戻す。その理由は、プログラムの最大性能が時間と共に変化することに対応するためである。
【００４９】
上記のIPC制御により、各スレッドのIPCが所望値近くに維持されることになるので、各スレッドの実行時間の予測の精度が向上する。その結果、実時間処理において、複数スレッドを並列に実行していても時間制約を守ることができるようなスケジューリングが容易になる。
【００５０】
図５は、上述した優先度による調停を行なうマルチスレッドプロセッサを用いて実時間処理を行った場合の例を示す。なお、図５の例では、説明の都合上、上述したプロセッサ１０のような複数スレッドを同時処理できるSMTプロセッサではなく、同時処理できるスレッドは１つのみであるシングルパイプラインのマルチスレッドプロセッサを用いた場合を想定する。
【００５１】
図５に示される例では、スレッド#0の優先度が最も高く、スレッド#7の優先度が最も低いとする。この例では、最初にスレッド#1、スレッド#2およびスレッド#3が実行可能になる。ここで、優先度による資源の調停を行なわない従来のマルチスレッドプロセッサでは、スレッド#1、スレッド#2およびスレット#3が並列的に実行されることになる。これに対し、優先度による資源の調停を行なうマルチスレッドプロセッサでは、優先度による演算資源の調停により、原則として、最も優先度の高いスレッド#1の実行が優先される。そのためスレット#1が先に実行される。スレッド#1の実行が完了すると、優先度による調停により、次に優先度の高いスレッド#2が優先的に実行される。このとき、スレッド#2のコンテキストがプロセッサ内に保持されているため、スレッド#2はコンテキストスイッチを行うことなく直ちに実行される。スレッド#4の実行中に、より優先度の高いスレッド#0が実行可能になった場合においても、優先度による演算資源の調停によりスレッド#0の実行が優先される。このときも、スレッド#0はコンテキストスイッチを行うことなく直ちに実行される。スレッド#0の実行が完了すると、次にスレッド#4に演算資源が割り当てられて、スレッド#4が直ちに実行を再開する。
【００５２】
マルチスレッドプロセッサは、一般に1つのスレッドがキャッシュミスなどでストールしている場合でも、別のスレッドを実行することにより、プロセッサ全体のスループットを高く維持できる。この側面に関して、本発明に従うマルチスレッドプロセッサでは、優先度の高いスレッドがストールした場合、次に優先度の高いスレッドを実行するように、優先度による調停を行うことができ、それにより、スループットを向上することが可能である。
【００５３】
図６は、優先度による調停と共にIPC制御を行なうSMTプロセッサより複数スレッドの同時実行を行った場合の例を示す。図６の例は、最大２つのスレッドを同時処理できるダブルパイプラインのプロセッサを使用する場合である。
【００５４】
この例では、スレッド#0の優先度が最も高く、スレッド#7の優先度が最も低いとする。この例では、最初にスレッド#1、スレッド#2およびスレッド#3が実行可能になる。優先度による演算資源の調停により、実行可能なスレッド#1、スレッド#2およびスレッド#3中で最も優先度の高いスレッド#1の実行が優先される。スレッド#1がキャッシュミスなどでストールする場合は、次に優先度の高いスレッド#2を実行する。スレッド#2のコンテキストはプロセッサ内に保持されているため、コンテキストスイッチを行うことなく直ちにスレッド#2を実行することができる。このため、スレッド#1とスレッド#2が同時並列的に実行されるようになる。スレッド#2は演算資源を使用するため、優先度のより高いスレッド#1の実行時間に影響を与える。その結果、IPC制御を採用しない場合には、スレッド#1の時間予測精度が低下する。これに対して、IPC制御を採用することにより、同時に実行されている各スレッド#1、#2の実行命令数（IPC）をそれぞれの目標値にできるだけ良く保つように、各スレッド#1、#2の実行の頻度が制御される。よって、複数スレッドを同時実行した場合でも、時間予測精度が低下することがない。そのため、時間制約を守りつつ、プロセッサ全体のスループットを向上することが可能となる。
【００５５】
さて、以下では、図２に示したSMTアーキテクチャを採用したプロセッサ１０における、優先度による資源調停とIPC制御のより具体的で詳細な制御方法を説明する。
【００５６】
まず、優先度による資源調停の制御方法を説明する。
【００５７】
この制御は、複数のスレッドを同時に実行する場合における、命令フェッチスロット、命令発行スロット、演算ユニットなどの各演算資源におけるスレッド間の競合を調停し解決するものである。そこでは、スケジューラが付与した優先度を、スレッド間の競合解決のために使用する。プロセッサ１０内で生じるスレッド間の競合解決に優先度を用いることで、優先度の低いスレッドが優先度の高いスレッドの実行を阻害することを防ぎ、優先度の高いスレッドの実行を保証する。ただし、優先度を単純に全ての競合処理に導入すると、システム全体の性能が低下してしまい、マルチスレッドによるレイテンシの隠蔽の効果を得ることができない。そこで、優先度の高いスレッドの性能を低下させずに、優先度の低いスレッドを実行する機構が採用される。SMTアーキテクチャは、スーパースカラアーキテクチャを採用するので、単一スレッドの性能が通常のシングルパイプラインと比較して高い。ただし、単一スレッドの性能をできるだけ高くするには、実行資源をスレッド間で共有化し、全ての実行資源を一つのスレッドが利用できるようにする必要がある。実行資源を共有化すると、単一のスレッドの性能の向上が期待できるが、スレッド間で性能に影響を与えやすくなるので、優先度の低いスレッドが優先度の高いスレッドの性能に悪影響を与えてしまう。その対策として、フェッチスロットや発行スロットといったスロットの優先度制御に加え、共有資源の占有率の制御も実装することができる。また、フェッチスレッド選択でのボトルネックをできるだけ回避し、命令供給機構全体を制御するような制御方法が採用される。その際、ソフトリアルタイムタスクとハードリアルタイムタスクの性質の違いに着目し、単一スレッドの性能に大きく比重を置く制御方法と、単一スレッドの性能の低下を抑制しつつ全体の性能に比重を置く制御方法とを実装することができる。
【００５８】
フェッチスレッド選択では、最上位優先度スレッドの性能低下をできるだけ抑制しつつ、他のスレッドのフェッチを行うことができる制御方法を採用することができる。最上位優先度スレッドの性能低下をできるだけ抑えることに主眼を置く場合、所定の状況下で最上位優先度スレッドにより無駄にされる（使用されない）スロットを、他の下位優先度スレッドが使用することで、ある程度のシステム全体の性能向上が期待できる。そのような制御方法として次のものを挙げることができる。
【００５９】
(1)  命令フェッチでのキャッシュミス
キャッシュミスした後に同じスレッドが命令フェッチを行うことはハードウェアを不必要に複雑化するのみである。キャッシュから命令が返ってくるまでは他のスレッドがフェッチを行う。
【００６０】
(2)  分岐予測ミスからの回復
分岐予測ミスによるパイプライン中の命令の破棄はその分岐命令のコミット時に行われる。分岐命令がライトバックされたときにはその予測の成否がわかるので、もし予測ミスしていた場合にはそれ以後のフェッチは無駄になる。そこでライトバックした分岐命令が予測ミスしていた場合には、その命令がコミットするまで他のスレッドからフェッチを行う。
【００６１】
(3)  命令バッファ中の命令数
最上位優先度スレッドの性能を落さないためには、実行機構への発行を可能な限り絶やさない必要がある。そのためには、命令バッファ中に常に命令が格納されている必要がある。図２に示したプロセッサ１０の場合、命令発行まで５ステージあるので、スレッド選択の際に最上位優先度スレッドの命令が命令バッファ３０内に６クロック分あれば、そのクロックに他のスレッドからフェッチを行ったとしても命令バッファ中の命令が不足することはない。４命令の同時発行のため、２４命令が命令バッファ３０内に存在する場合に、優先度の低いスレッドからフェッチを行う。ただし次に最上位優先度スレッドがフェッチした命令中にいくつの有効な命令があるかはこの時点では不明であるのに加え、次の命令フェッチがキャッシュミスを起こす可能性があるので、それを考慮にいれると、さらに命令数を増やした方が性能の低下は防げる。
【００６２】
以上の３つの制御方法は、最上位優先度スレッドが無駄にするスロットを使用して下位優先度スレッドの命令を格納するという方法である。それに対し、優先度の高いスレッドが実行資源を非効率的に使うと予測して、優先度の低いスレッドのフェッチを行うという制御方法も採用し得る。その例を以下に挙げる。
【００６３】
(1)  パイプライン中の条件分岐命令数
条件分岐命令を多く実行するほど分岐予測ミスの可能性が高くなり、実行資源を無駄にする可能性が高くなる。そのため、パイプライン中の条件分岐命令の数が閾値を越えた場合に優先度の低いスレッドからフェッチを行う。
【００６４】
(2)  パイプライン中の命令数
パイプライン中に命令数が多くなると、それが依存するデータを待つ命令が多くなり、実行スロットを埋めることが難しくなる。特に単一のスレッドの命令数が多くなったときに、この現象は顕著になる。そのため、パイプライン中の命令数が閾値を越えた場合に優先度の低いスレッドからフェッチを行う。
【００６５】
(3)  命令バッファ中の命令数
前述した制御方法では、常に最大限命令が発行されると仮定したが、リザベーションステーション６０などの問題で最大限命令を発行できないことがある。そこで、閾値を上述した２４命令よりも低く設定する。閾値が低い程、優先度の高いスレッドの性能が落ちると考えられる。
【００６６】
(4)  フェッチ制御ユニット内の占めているステージ数
デコード時に用いられる分岐予測器と比較して、BTB（Branch Target Buffer:  分岐ターゲットバッファ、図示省略）は分岐命令があるかどうかという情報がない分、予測精度が大きく劣る。そのため、BTBによる投機フェッチ数を制限する。フェッチ制御パイプライン中のステージ数によって制御することで、連続するフェッチ回数を抑える。
【００６７】
(5)  リザベーションステーション内の待ち命令数
使われる実行ユニットに偏りがある場合や、命令間に強い依存関係がある場合、パイプライン中の命令数による制御ではリザベーションステーション６０を一杯にしてしまう可能性がある。そこで、リザベーションステーション６０内の命令数を数え、閾値を越えた場合に優先度の低いスレッドからフェッチを行う。
【００６８】
以上の５つの制御方法は、システム全体の性能を向上させることを重視している。
【００６９】
さて、発行命令選択では、命令実行ユニット１６に直接命令を供給するために、命令フェッチ機構から十分な命令が来ている場合には、スレッドの性能に大きな影響を及ぼすと考えられる。そこで、優先度の高いスレッドの性能の低下を抑制するために、命令発行機構では発行できる限り優先度の高いスレッドの命令を発行する。優先度による発行命令選択ではフェッチスレッド選択と同様に、次のような方法で優先度の低いスレッドの命令を発行する。
【００７０】
(1)  対象のリザベーションステーションが一杯の場合
優先度の低いスレッドの命令に他のリザベーションステーションを利用する命令が含まれている場合はその命令を発行する。
【００７１】
(2)  リオーダバッファやリネームレジスタが一杯の場合
これらの実行資源をスレッド毎に所持している場合は他のスレッドの命令を発行する。
【００７２】
(3)  投機実行が禁止されている命令の場合
コントロールレジスタへの書き込み命令のように、投機実行が禁止されている命令の場合はその命令より前の命令が全てコミットされない限り命令発行を止める。
【００７３】
(4)  分岐予測ミスからの回復の場合
フェッチスレッド選択と同様に、ライトバックされた分岐命令が予測ミスをしていた場合にその命令がコミットするまで命令発行を止める。
【００７４】
対象のリザベーションステーション６０が一杯の場合は、優先度の高いスレッドと低いスレッドの利用するユニットがそれぞれ偏っていてなおかつ異なる場合でない限り、優先度の低いスレッドから多くの命令を発行できるわけではない。また、リオーダバッファ４０やリネームレジスタ３４をスレッド間で共有する構成にした場合には、優先度の低いスレッドからの命令発行は行うことが出来なく、投機実行が禁止されている命令は通常のプログラムにおいては頻度が低い。つまり、キャッシュミスが起こり得るフェッチスレッド選択と比較して、優先度の低いスレッドの命令が発行される可能性が低い。複数スレッドの並列実行によるレイテンシの隠蔽には、更なる制御方法が採用される。さらに、システム全体の性能に重きを置き、次のパラメータ、
・パイプライン中の条件分岐命令数
・パイプライン中の命令数
・リザベーションステーション内の待ち命令数
を参照して優先度の高いスレッドの命令発行を止める。
【００７５】
以上、命令フェッチ、発行といったパイプライン中のスロットに関する競合を解決する制御方法について述べた。それに加え、SMTアーキテクチャでは複数スレッドで実行資源が共有されるため、その競合制御についても考慮にいれる必要がある。ここでいう実行資源とは、典型的には、
・命令バッファ３０
・リネームレジスタ３４
・リオーダバッファ４０
などを指す。これらの実行資源は、スレッドごとに用意されるか、または共有化されるかの２通りの実装方法がある。
【００７６】
実行資源がスレッドごとに用意される場合、スレッド間の影響を低く抑えることが可能である。或るスレッドがストールしても、他のスレッドは容易に実行できる。しかし、一つのスレッドが使える量が小さく抑えられるので、単一のスレッドの性能が低くなる。一方、実行資源がスレッド間で共有された場合、単一のスレッドを優先して実行した場合に、実行資源を十分に利用できるので性能が高くなる。しかしスレッド間の影響が大きくなるため、低い優先度のスレッドが高い優先度のスレッドを阻害してしまう。またスレッドがストールしたときに他のスレッドが実行できないことがある。
【００７７】
このようにスレッド間の影響を考えると、スレッド毎に実行資源を用意する方法の方が好ましいが、チップサイズの制限があるのでスレッドあたりの資源の量は小さく抑えられてしまう。そのため、優先度の高いスレッドの性能が低くなるので、ソフトリアルタイム処理に耐え得る高い性能という面で問題がある。そこで、図２に示されたプロセッサ１０では、実行資源を共有化することで、単一のスレッドの性能向上を目指す。
【００７８】
各バッファをパーティション化(幾つかの単位に分割)することにより、ハードウェアの複雑化を防ぐことができる。一つのパーティションを単一のスレッドのみが使用するように設計することで、スレッドごとにパーティションの使用順番とパーティション内の現在位置だけ記憶しておけば良いので、ハードウェアが単純になる。
【００７９】
各バッファを共有することで、優先度の低いスレッドがバッファを占有することにより優先度の高いスレッドの実行を阻害してしまう。そこで、共有バッファにおけるスレッド間の性能に対する影響を抑えるために、各スレッドが使用できるバッファのエントリ数をソフトウェアによりパーティション単位で設定する。これに関し、次の２通りの制御方法が採用できる。
【００８０】
(1)  資源予約
制御レジスタを用いてスレッド毎にパーティション使用権を設定する。同じパーティションを複数のスレッドが利用することができる。
【００８１】
(2)  最大数設定
制御レジスタを用いてスレッド毎に使用できる最大のパーティション数を設定する。
【００８２】
資源予約方式では、スレッド毎に利用できる資源を個別に指定できるので、安定した性能が期待できるが、周期タスクが実行を終え、次の周期を待っている場合など、スレッドが実行できない場合に対応がしづらく、実行資源を有効に使うことができない。最大数設定方式では、他のスロットの制御を優先度制御で行っているために、優先度の高いスレッドから指定された最大限の量まで実行資源を利用することができ、状況に応じて最大限に実行資源を利用しやすい。ただし、各スレッドの最大数の合計がパーティション総数を上回っている場合には、優先度の低いスレッドが優先度の高いスレッドの実行を阻害してしまう。資源予約方式は静的に性能の予測ができ、最大数設定方式は、動的に実行資源の利用の効率化を計ることができる。しかし、これらの制御方法のみでは最上位優先度スレッドの性能を維持することは難しい。例えば優先度の高いスレッドがスケジューリング可能な状態になり、最上位優先度スレッドが切り替わる場合には、それまで実行されていた優先度の低いスレッドが実行資源を占有しており、優先度の高いスレッドの実行が阻害されてしまう。そこで、優先度の高いスレッドの命令が格納されているパーティションの数が閾値以下で、空きパーティションがない場合に、現在その資源を利用しているスレッドの中から最も優先度の低いスレッドの命令を破棄する。命令バッファ３０の場合ではそのスレッドの先頭の命令からフェッチし直し、リオーダバッファ４０では分岐予測ミスの場合と同様の機構を用いてパイプライン中の命令を破棄する。
【００８３】
SMTアーキテクチャでは、優先度による制御を行っていても、同時に実行されるスレッドによっては最上位優先度の実行に影響を与える場合がある。そこで、プロセッサの性能の予測性、及び全体スループットの改善のために、各スレッドが優先度に従った量の命令バッファを確保するように制御する。これにより下位優先度スレッドがフェッチ権を獲得しやすくなるため、最上位優先度スレッドの性能が多少低下する可能性があるが、性能の変動は小さくなり、予測性が高まるものと考えられる。また、命令バッファの利用効率の改善により全体性能の向上が期待できる。まず命令フェッチについて述べる。以後の説明には以下の記号を用いる。
【００８４】
Ti: 各スレッド;
Gj: 同じ優先度を与えられたスレッド群。グループ間の優先度はGj > Gj+1 であるとする;
ThreadOfMinIQ(T0, T1, . . .): 命令バッファ占有数が最小のスレッド;
IQNUM(T): T が占有する命令バッファ数;
IQSUM(T0, T1, . . .): 各スレッドが占有する命令バッファの合計;
MINIQ(T0, T1, . . .): 命令バッファ占有数の最小値;
THNUM(Gj): Gj のスレッド数;
FREQj: Gj のフェッチ要求;
FETCHj: FREQj が認められた場合にフェッチが行われるスレッド。
【００８５】
FETCHj 、FREQj は以下のように決まる。
FETCHj = ThreadOfMinIQ(Gj)
FREQj = MINIQ(Gj) ≦ IQSUM(Gj+1) or IQSUM(Gj) ≦ MIN_IQ_THRESH × THNUM(Gj)
ここで、MIN_IQ_THRESH は、各スレッドの命令バッファが空になる頻度を低くすることを目的とした値であり、スレッドの命令バッファ占有数がこの値を下回ると、各スレッドは無条件にフェッチ要求を出すことができる。これは以下の値、
・1回のフェッチでフェッチされる命令数
・フェッチ開始から命令発行までに要する最短サイクル数
・1サイクルの最大命令発行数
によって決まる。
【００８６】
プロセッサ１０では、1サイクルで８つの命令がフェッチされ、フェッチ開始から命令発行まで6サイクルを要する。1サイクルで４命令が発行されるため、最低でも命令バッファに２４命令あれば命令供給が絶える頻度を減らすことができる。命令バッファ３０の1エントリに４命令が保持されるため、MIN_IQ_THRESHの値は６とすることができる。
【００８７】
以上により、FETCHj 、FREQj が決定されるが、プロセッサ１０では、1サイクルでフェッチできるスレッド数は1つであり、複数のフェッチ要求から1つのスレッドを選択しなければならない。最上位優先度スレッドの実行を優先するために、最上位優先度のグループのフェッチ要求を選択し、フェッチスレッドを決定するような制御方法が採用される。また、フェッチスレッドとして選択されたスレッドがキャッシュミス等を起こしフェッチを行えない場合であっても、下位のスレッドにフェッチ権を譲ることはないようにしてもよい。これは、資源占有量の逆転を防ぎ下位優先度スレッドが上位優先度スレッドの性能を圧迫しないようにするためである。
【００８８】
この制御方法では、下位優先度スレッドがフェッチ権を得やすくなっており、プロセッサの全体性能が向上すると考えられる。一方で、プログラムの特性によらず高優先度スレッドほど多くの命令バッファを獲得できるように制御されており、後述の命令発行の制御方法との組み合わせにより、低優先度スレッドに多くの命令バッファが割かれる問題や、長期間命令バッファが占有される問題は生じにくいと考えられる。また、この制御方法では、同じ優先度のスレッドが複数あった場合には、それらの中で最も命令バッファ占有数が少ないスレッドからフェッチを行う。
【００８９】
次に命令発行の制御方法について述べる。
【００９０】
プロセッサ１０では、1サイクルで最大で４つのスレッドから計４命令が発行されるため、命令フェッチと異なり最大で８つのスレッドから４つのスレッドを選択しなくてはならない。以降の説明では以下の記号を用いる。
【００９１】
Tj,k: Gj に属するスレッド;
RSNUM(T): T のリザベーションステーション占有数;
RSSUM(T0, T1, . . .): リザベーションステーション占有数の合計;
IREQj,k: Tj,k の命令発行要求。
【００９２】
IREQj,k は以下のように決まる。
IREQj,k = RSNUM(Tj,k) ≦ RSSUM(Gj+1)
【００９３】
命令フェッチと異なり、同じグループの複数のスレッドから命令発行要求が来る場合がある。命令発行では、命令発行要求を出しているスレッドを以下の順で優先順位付けし、優先順位の上位４スレッドを発行スレッドとする。
・スレッドに与えられた優先度順
・同じ優先度のスレッド間ではリザベーションステーション６０の占有数が少ない順
【００９４】
命令発行の制御方法は、前述の命令フェッチのそれとよく似たものである。相違点は、命令バッファ３０のエントリ数の代わりにリザベーションステーション６０を用いる点と、MIN_IQ_THRESHに対応する条件が無い点である。発行スレッド選択の基準にリザベーションステーション６０を用いる理由は次の通りである。すなわち、発行スレッドとして選択されたスレッドが実際には発行できない場合が存在する。これは主に次のような場合である。
・リオーダバッファ４０に空きがない
・リネームバッファ３４に空きがない
・発行先の実行ユニットのリザベーションステーション６０に空きがない
プロセッサ１０では、リオーダバッファ４０とリネームバッファ３４は連動しており、実際に制約となるのはリオーダバッファ４０かリザベーションステーション６０である。このうち、実際上は、リザベーションステーション６０に空きがなく命令発行が行えない場合が多い。そのため、より貴重な資源を高優先度スレッドに割り当てるためスレッド選択の基準にリザベーションステーション６０が用いられる。
【００９５】
次に、IPC制御の具体的方法を説明する。
【００９６】
リアルタイム処理においてはタスクの実行時間の予測性が重要である。そこで、前述の命令フェッチ、命令発行機構にIPCを制御する機構を加える。IPC 制御では、一定の間隔で各スレッドの実行命令数を監視し、それが指定された目標値に満たない場合には命令フェッチ、発行が行われる頻度を高くする。また、スレッドの性質によっては時間によって性能が大きく変化することがあり、本制御ではその点についても考慮される。
【００９７】
まず、前述の命令フェッチ、発行の制御方法が以下のように変更される。
FREQj = MINIQ(Gj) ≦ IQSUM(Gj+1) + inflationj × THNUM(Gj) or IQSUM(Gj) ≦ MIN_IQ_THRESH × THNUM(Gj)
IREQj,k = RSNUM(Tj,k) ≦ RSSUM(Gj+1) + inflationj
ここで、inflationは上述したインフレ値であり、0 ≦ inflation ≦32の範囲で、Gj の現在の性能によって増減される。Gj が指定されたIPC を得られていない場合には、インフレ値が上昇し、下位スレッドのフェッチ、発行を抑制し、Gjのスレッドの性能を上昇させる。インフレ値が０から３２の範囲であるのは、命令バッファ３０およびリザベーションステーション６０が３２エントリをもつことに基づいている。IPC制御では、プログラムのIPCをある一定の監視周期PERIODで監視する。プログラマは実現したいIPCをipcとし、「PERIOD× ipc」の値を目標値として各スレッドのIPC設定レジスタに書き込む。IPC制御では、設定された目標値を満たせていない状態が続いた場合、インフレ値を増加させる。インフレ値の増加に際しては、インフレ値の増加に見合った性能の向上が得られたことを確認し、その性能向上が得られていない場合にはインフレ値を元に戻す。これは、プログラムの最大性能が時間と共に変化することに対応するためである。
【００９８】
以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例示にすぎず、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。
【図面の簡単な説明】
【００９９】
【図１】従来のシングルスレッドプロセッサによる実時間処理の例を示すタイムチャート図。
【図２】本発明に従うマルチスレッドプロセッサの一実施形態の主要部の構成を示すブロック線図。
【図３】スレッドのIPCを制御するための構成を示すブロック線図。
【図４】スレッドのIPCを制御するための制御関数の状態遷移とインフレ値増減の動作を示すブロック線図。
【図５】優先度による調停を行なうマルチスレッドプロセッサを用いて実時間処理を行った場合の例を示すタイムチャート。
【図６】優先度による調停と共にIPC制御を行なうSMTマルチスレッドプロセッサによる実時間処理の例を示すタイムチャート。
【符号の説明】
【０１００】
１０  マルチスレッドプロセッサ
１２  発行ユニット
１４  キャッシュユニット
１６  実行ユニット
２０  スレッドコントロールユニット
２４  フェッチスレッドセレクタ
３２  命令発行セレクタ
３６  レジスタファイル
３８  コンテキストキャッシュ
４０  リオーダバッファ
４４  命令キャッシュ
４８  命令ウェイトバッファ
５２  データリード／ライトバッファ
５８  データウェイトバッファ
６０  リザベーションステーション
１００  パイプライン処理機構
１０２  実行命令数監視部
１０４  比較部
１０６  制御関数部
【図１】
2006343872.tif 000003
【図２】
2006343872.tif 000004
【図３】
2006343872.tif 000005
【図４】
2006343872.tif 000006
【図５】
2006343872.tif 000007
【図６】
2006343872.tif 000008