(57)【要約】【課題】投機フェッチの実行が結果的にメモリアクセスのレーテンシを悪化させることを防ぐこと。【解決手段】ビジー制御部４５０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷状態を管理し、高負荷になった場合に、投機フェッチ発行部４４０にＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷であることを通知し、投機フェッチ発行部４４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷である場合に、投機フェッチの発行を抑止する。また、投機フェッチの応答データの転送先や待ち合わせ場所を指定して投機フェッチを実行する。【選択図】        図２
2006053857.tif 000002
【特許請求の範囲】
【請求項１】
メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、
前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、
を備えたことを特徴とするシステム制御装置。
【請求項２】
前記消費量判定手段により消費状況が監視されるハードウェア資源は、メモリフェッチを依頼するメモリ制御装置を接続するバスであることを特徴とする請求項１に記載のシステム制御装置。
【請求項３】
前記消費量判定手段により消費状況が監視されるハードウェア資源は、投機フェッチで使用するバッファであることを特徴とする請求項１に記載のシステム制御装置。
【請求項４】
前記投機フェッチ発行手段は、前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする請求項１に記載のシステム制御装置。
【請求項５】
前記投機フェッチ発行手段は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする請求項１または４に記載のシステム制御装置。
【請求項６】
前記投機フェッチ発行手段は、前記代替待ち合わせ場所として自装置を指定して投機フェッチを実行することを特徴とする請求項５に記載のシステム制御装置。
【請求項７】
メモリフェッチを行う際に、フェッチするデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行する情報処理装置であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、
前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、
を備えたことを特徴とする情報処理装置。
【請求項８】
メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置による投機フェッチ方法であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定工程と、
前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行工程と、
を含んだことを特徴とする投機フェッチ方法。
【請求項９】
前記投機フェッチ発行工程は、前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする請求項８に記載の投機フェッチ方法。
【請求項１０】
前記投機フェッチ発行工程は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする請求項８または９に記載の投機フェッチ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置、投機フェッチ方法および情報処理装置に関し、特に、投機フェッチの実行が結果的にメモリアクセスの待ち時間を悪化させることを防ぎ、メモリアクセスの待ち時間を改善することができるシステム制御装置、投機フェッチ方法および情報処理装置に関するものである。
【背景技術】
【０００２】
近年のＬＳＩの動作周波数の向上は目覚しく、ＬＳＩ内の処理時間に比べメモリへのアクセス時間が相対的に大きくなってきている。これを改善する解決策の一つとして、メモリフェッチ要求をＣＰＵやＩ／Ｏ制御装置（以下「ＩＯＰ」という。）から受け取ったシステム制御装置（以下「ＳＣ」という。）が、要求されたデータがキャッシュ内に記憶されているか否かが判明する前に、メモリ制御装置（以下「ＭＡＣ」という。）にメモリフェッチを要求する投機フェッチが行われている（例えば、特許文献１および２参照。）。
【０００３】
すなわち、システム制御装置は、ＣＰＵのキャッシュに記憶されているデータのアドレス、更新状態などの情報（以下「タグ情報」という）を全てのＣＰＵについて保持し、メモリフェッチ要求に対して、要求されたデータがキャッシュにあるか否かをタグ情報を検索して判定し、キャッシュにない場合にメモリにアクセスするのではなく、要求されたデータがキャッシュにあるか否かが判明する前の段階で、タグ情報の検索と同時に、投機的にメモリアクセスを行う。
【０００４】
この投機フェッチによって、メモリアクセスを早く開始することができ、キャッシュにデータがない場合に、メモリアクセスの待ち時間（以下「レーテンシ」という。）を改善することができる。
【０００５】
【特許文献１】特開２０００−２９７８６号公報
【特許文献２】特開２００１−１６７０７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
投機フェッチでは、メモリフェッチ要求の対象データがＣＰＵのキャッシュ内に存在する場合には、ＳＣは対象データを所有しているＣＰＵに対象データのムーブアウトを要求し、ムーブアウトデータを要求元装置に応答して、投機フェッチの応答データを破棄する。
【０００７】
ここで、投機フェッチの応答データを破棄することは、投機フェッチの実行にともなって消費されたバッファ、バスといったハードウェア資源について、着目しているメモリフェッチ要求以外の処理の実行を遅延させた可能性があるということを意味する。何故ならば、投機フェッチを行わなければ、他の処理が実行できたかもしれないからである。したがって、投機フェッチには、他の処理の実行を遅延させることによって、メモリアクセスのレーテンシを悪化させる場合があるという問題がある。
【０００８】
また、投機フェッチの応答データが先行してバスを使用したことで他のＣＰＵからのムーブアウトデータによる同バスの使用が待たされた場合には、投機フェッチの実行が結果的にメモリアクセスのレーテンシを悪化させるという問題もある。
【０００９】
また、一般にプログラムの性質から、メモリフェッチ要求は比較的近いアドレスに対して、集中してかつ短期間に発生しやすい傾向があり、投機フェッチはメモリフェッチ要求により起動されるため、投機フェッチもまた集中的に発生しやすい。したがって、アドレスインタリーブされた複数のＳＣのうちの一台のＳＣに負荷が集中し、他のＳＣの負荷が軽いといった状況が、投機フェッチ機構によってより一層発生しやすいという問題がある。
【００１０】
また、投機フェッチの応答データを使用するか否かは全ＣＰＵのキャッシュの検索結果によって決定される。したがって、キャッシュの検索結果が判明するまでは、投機フェッチの応答データをシステム内のどこかに保持し、キャッシュの検索結果との待ち合わせを行う必要がある。
【００１１】
ここで、投機フェッチの応答データが、キャッシュの検索結果よりも先に到着する場合には、投棄フェッチによるメモリレーテンシの改善を最大限に活用しようとするならば、待ち合わせ場所はメモリフェッチ要求を発行した装置に最も近いＳＣ（以下「末端ＳＣ」という。）がよい。
【００１２】
何故ならば、末端ＳＣは、応答データを要求元装置に転送する場合に、応答データの転送経路上のハードウェア資源を確保する必要がないため、キャッシュの検索結果により投棄フェッチの応答データを使用することが確定した場合にはすぐに要求元装置に転送できるからである。
【００１３】
しかし、末端ＳＣを待ち合わせ場所とすると、たとえキャッシュの検索結果によって投機フェッチの応答データを破棄することが判明した後でも、末端ＳＣまでは投棄フェッチの応答データを必ず転送しなければならない。したがって、末端ＳＣまでの転送経路の負荷が高い状況においては、破棄される予定の投棄フェッチの応答データがハードウェア資源をさらに消費し、さらに負荷を高めるという問題がある。
【００１４】
この発明は、上述した従来技術による問題点を解消するためになされたものであり、投機フェッチの実行が結果的にメモリアクセスの待ち時間を悪化させることを防ぎ、メモリアクセスの待ち時間を改善することができるシステム制御装置、投機フェッチ方法および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上述した課題を解決し、目的を達成するため、請求項１の発明に係るシステム制御装置は、メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置であって、前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、を備えたことを特徴とする。
【００１６】
この請求項１の発明によれば、投機フェッチで使用するハードウェア資源の消費状況を監視し、ハードウェア資源の消費量が所定の値以上であるか否かを判定し、ハードウェア資源の消費量が所定の値以上であると判定した場合には、投機フェッチの発行を抑止するよう構成したので、投機フェッチに起因するメモリアクセス待ち時間の悪化を防ぐことができる。
【００１７】
また、請求項２の発明に係るシステム制御装置は、請求項１の発明において、前記消費量判定手段により消費状況が監視されるハードウェア資源は、メモリフェッチを依頼するメモリ制御装置を接続するバスであることを特徴とする。
【００１８】
この請求項２の発明によれば、消費状況を監視するハードウェア資源は、メモリフェッチを依頼するメモリ制御装置を接続するバスであるよう構成したので、投機フェッチに起因してこのバスがより高負荷になることを防ぐことができる。
【００１９】
また、請求項３の発明に係るシステム制御装置は、請求項１の発明において、前記消費量判定手段により消費状況が監視されるハードウェア資源は、投機フェッチで使用するバッファであることを特徴とする。
【００２０】
この請求項３の発明によれば、消費状況を監視するハードウェア資源は、投機フェッチで使用するバッファであるよう構成したので、投機フェッチに起因してこのバッファがより高負荷になることを防ぐことができる。
【００２１】
また、請求項４の発明に係るシステム制御装置は、請求項１の発明において、前記投機フェッチ発行手段は、前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする。
【００２２】
この請求項４の発明によれば、ハードウェア資源の消費量が所定の値以上であると判定した場合に、このハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行するよう構成したので、投機フェッチで使用するハードウェア資源の消費量が大きい場合にも投機フェッチを実行することができる。
【００２３】
また、請求項５の発明に係るシステム制御装置は、請求項１または４の発明において、前記投機フェッチ発行手段は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする。
【００２４】
この請求項５の発明によれば、投機フェッチの応答データとタグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、その待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行するよう構成したので、投機フェッチに起因して待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量がより増加することを防ぐことができる。
【００２５】
また、請求項６の発明に係るシステム制御装置は、請求項５の発明において、前記投機フェッチ発行手段は、前記代替待ち合わせ場所として自装置を指定して投機フェッチを実行することを特徴とする。
【００２６】
この請求項６の発明によれば、代替待ち合わせ場所として自装置を指定して投機フェッチを実行するよう構成したので、自装置から待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量がより増加することを防ぐことができる。
【００２７】
また、請求項７の発明に係る情報処理装置は、メモリフェッチを行う際に、フェッチするデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行する情報処理装置であって、前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、を備えたことを特徴とする。
【００２８】
この請求項７の発明によれば、投機フェッチで使用するハードウェア資源の消費状況を監視し、ハードウェア資源の消費量が所定の値以上であるか否かを判定し、ハードウェア資源の消費量が所定の値以上であると判定した場合には、投機フェッチの発行を抑止するよう構成したので、投機フェッチに起因するメモリアクセス待ち時間の悪化を防ぐことができる。
【００２９】
また、請求項８の発明に係る投機フェッチ方法は、メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置による投機フェッチ方法であって、前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定工程と、前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行工程と、を含んだことを特徴とする。
【００３０】
この請求項８の発明によれば、投機フェッチで使用するハードウェア資源の消費状況を監視し、ハードウェア資源の消費量が所定の値以上であるか否かを判定し、ハードウェア資源の消費量が所定の値以上であると判定した場合には、投機フェッチの発行を抑止するよう構成したので、投機フェッチに起因するメモリアクセス待ち時間の悪化を防ぐことができる。
【００３１】
また、請求項９の発明に係る投機フェッチ方法は、請求項８の発明において、前記投機フェッチ発行工程は、前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする。
【００３２】
この請求項９の発明によれば、ハードウェア資源の消費量が所定の値以上であると判定した場合に、このハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行するよう構成したので、投機フェッチで使用するハードウェア資源の消費量が大きい場合にも投機フェッチを実行することができる。
【００３３】
また、請求項１０の発明に係る投機フェッチ方法は、請求項８または９の発明において、前記投機フェッチ発行工程は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする。
【００３４】
この請求項１０の発明によれば、投機フェッチの応答データとタグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、その待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行するよう構成したので、投機フェッチに起因して待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量がより増加することを防ぐことができる。
【発明の効果】
【００３５】
請求項１、７および８の発明によれば、投機フェッチに起因するメモリアクセス待ち時間の悪化を防ぐので、メモリアクセス待ち時間を改善することができるという効果を奏する。
【００３６】
また、請求項２の発明によれば、メモリ制御装置と接続するバスが投機フェッチに起因してより高負荷になることを防ぐので、メモリアクセス待ち時間を改善することができるという効果を奏する。
【００３７】
また、請求項３の発明によれば、投機フェッチに使用するバッファが投機フェッチに起因してより高負荷になることを防ぐので、メモリアクセス待ち時間を改善することができるという効果を奏する。
【００３８】
また、請求項４および９の発明によれば、投機フェッチで使用するハードウェア資源の消費量が大きい場合にも代替ハードウェアを用いて投機フェッチを実行するので、メモリアクセス待ち時間を改善することができるという効果を奏する。
【００３９】
また、請求項５および１０の発明によれば、投機フェッチに起因して待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量がより増加することを防ぐので、処理効率を向上することができるという効果を奏する。
【００４０】
また、請求項６の発明によれば、自装置から待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量がより増加することを防ぐので、処理効率を向上することができるという効果を奏する。
【発明を実施するための最良の形態】
【００４１】
以下に添付図面を参照して、この発明に係るシステム制御装置、投機フェッチ方法および情報処理装置の好適な実施例を詳細に説明する。
【実施例１】
【００４２】
まず、本実施例１に係る情報処理装置の構成について説明する。図１は、本実施例１に係る情報処理装置の構成を示す機能ブロック図である。同図に示すように、この情報処理装置は、ＣＰＵ0１０〜ＣＰＵ3４０で示される４台のＣＰＵと、ＳＣ0１００〜ＳＣ3４００で示される４台のＳＣと、ＭＡＣ0５００およびＭＡＣ1６００で示される２台のＭＡＣと、ＭＥＭＯＲＹ0５０およびＭＥＭＯＲＹ1６０で示される２台のメモリ群と、ＩＯＰ0７０およびＩＯＰ1８０で示される２台のＩＯＰとを有する。なお、全ＣＰＵのキャッシュのコヒーレンス処理はアドレスインタリーブされたＳＣ0１００〜ＳＣ3４００までの４台のＳＣによって分担されている。
【００４３】
また、各ＣＰＵはすべてのＳＣに対して専用バスを持ち、各ＳＣは他のすべてのＳＣに対して専用バスを持つ。そして、ＳＣ0１００およびＳＣ1２００の担当するメモリアクセス要求は、ＭＥＭＯＲＹ0５０の制御を担うＭＡＣ0５００によって処理される。同様に、ＳＣ2３００およびＳＣ3４００の担当するメモリアクセス要求は、ＭＥＭＯＲＹ1６０の制御を担うＭＡＣ1６００によって処理される。
【００４４】
一方、各ＩＯＰはおのおの１台のＳＣにのみ接続されている。したがって、各ＩＯＰからのメモリアクセス要求はそれぞれのＩＯＰが接続されたＳＣに対して発行され、メモリアクセス要求を受信したＳＣと要求アドレスを担当するＳＣが異なる場合には、メモリアクセス要求を受信したＳＣは要求アドレスを担当するＳＣに対してメモリアクセス要求を転送して処理を委託する。
【００４５】
次に、ＳＣの構成について説明する。なお、図１に示したＳＣ0１００〜ＳＣ3４００はいずれも同様の構成を有するので、ここではＳＣ3４００を例にとって説明する。
【００４６】
図２は、ＳＣ3４００の構成を示す機能ブロック図である。同図に示すように、ＳＣ3４００は、要求受付部４１０と、キャッシュ検索部４２０と、キャッシュ情報記憶部４３０と、投機フェッチ発行部４４０と、ビジー制御部４５０と、メモリアクセス部４６０と、待ち合わせ部４７０とを有する。
【００４７】
要求受付部４１０は、ＣＰＵ0１０〜ＣＰＵ3４０、ＩＯＰ1８０および他のＳＣからのメモリフェッチ要求を受け付ける処理部であり、受け付けたメモリフェッチ要求をキャッシュ検索部４２０および投機フェッチ発行部４４０に伝える。
【００４８】
キャッシュ検索部４２０は、要求受付部４１０から受け取ったメモリフェッチ要求で要求されたデータがＣＰＵのキャッシュに登録されているか否かを調べる処理部であり、調べた結果を待ち合わせ部４７０に伝える。
【００４９】
キャッシュ情報記憶部４３０は、全ＣＰＵのキャッシュのタグ情報を記憶する記憶部であり、キャッシュに登録されているデータのメモリアドレス、更新状況などの情報を記憶する。キャッシュ検索部４２０は、このキャッシュ情報記憶部４３０を検索することによって、要求されたデータがＣＰＵのキャッシュに登録されているか否かを調べることができる。
【００５０】
投機フェッチ発行部４４０は、ＭＡＣ1６００との間のバスの状況に基づいてＭＡＣ1６００に対して投機フェッチを発行する処理部である。すなわち、この投機フェッチ発行部４４０は、ＭＡＣ1６００との間のバスの負荷が低い場合には、投機フェッチを発行するが、ＭＡＣ1６００との間のバスの負荷が高い場合には、投機フェッチを発行しない。
【００５１】
この投機フェッチ発行部４４０が、ＭＡＣ1６００との間のバスの状況に基づいて投機フェッチを発行することによって、投機フェッチの実行によりＭＡＣ1６００との間のバスがさらに高負荷になることを防ぐことができる。
【００５２】
ビジー制御部４５０は、ＭＡＣ1６００との間のバスの負荷状態を管理する処理部であり、一定期間中のバスの使用率を計測することによってバスの負荷状態を管理する。このビジー制御部４５０は、バスの負荷が高い場合には、投機フェッチ発行部４４０に対してバスが高負荷であることを通知し、投機フェッチ発行部４４０は、ビジー制御部４５０からバスが高負荷であることを通知されると投機フェッチの発行を抑止する。
【００５３】
メモリアクセス部４６０は、ＭＡＣ1６００にメモリフェッチ要求を送信し、メモリフェッチ要求に応答してＭＡＣ1６００から送られてくるデータを受信する処理部である。
【００５４】
待ち合わせ部４７０は、キャッシュ検索部４２０によるキャッシュ情報記憶部４３０の検索結果と、投機フェッチによりＭＡＣ1６００から送られてくる応答データの待ち合わせを行う処理部である。
【００５５】
ただし、この待ち合わせ部４７０は、キャッシュ情報の検索結果と投機フェッチの応答データの待ち合わせ場所が他のＳＣである場合には、受け取ったキャッシュ情報の検索結果および投機フェッチの応答データを待ち合わせ場所であるＳＣに転送する。
【００５６】
すなわち、キャッシュ情報の検索結果と投機フェッチによるデータの待ち合わせ場所は、投機フェッチを発行したＳＣとは限らない。例えば、投機フェッチによるメモリレーテンシの改善を最大限に活用しようとするならば、待ち合わせ場所は、末端ＳＣがよい。したがって、待ち合わせ部４７０は、逆に、他のＳＣから待ち合わせ場所として指定されることもある。
【００５７】
次に、本実施例１に係る情報処理装置による投機フェッチ制御について説明する。図３は、本実施例１に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【００５８】
同図に示すように、本実施例１に係る情報処理装置は、ＩＯＰ0７０がＭＥＭＯＲＹ1６０に実装されたアドレスに対するメモリフェッチを実行する場合、ＩＯＰ0７０はＳＣ1２００に対してメモリフェッチ要求を発行（１）する。すると、アドレスインタリーブによって、ＳＣ1２００は、対象アドレスを担当するＳＣであるＳＣ3４００にメモリフェッチ要求を転送（２）して処理を委託する。
【００５９】
メモリフェッチ要求を受信したＳＣ3４００は、自装置内のキャッシュ検索部４２０と投機フェッチ発行部４４０にメモリフェッチ要求を伝える。これを受け、キャッシュ検索部４２０は全ＣＰＵのキャッシュ登録状態の調査を開始する。
【００６０】
一方、投機フェッチ発行部４４０は、ＳＣ3４００−ＭＡＣ1６００間バスＢＵＳ−ＳＣ3−ＭＡＣ1７１０についてビジー制御部４５０から通知されるビジー状態通知信号（３）に基づいて投機フェッチの発行を判断する。すなわち、投機フェッチ発行部４４０は、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高い場合には投機フェッチ要求の発行を抑止することでバスの負荷をさらに高めることを防止し、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が低い場合には投機フェッチ要求を発行することでメモリアクセスのレーテンシ改善を図る。
【００６１】
そして、投機フェッチ要求を受信したＭＡＣ1６００は、ＭＥＭＯＲＹ1６０に対してメモリフェッチを起動（５）し、その応答データ（６）をＳＣ3４００に転送（７）する。ただし、投機フェッチ要求を受信しなかった場合には、当然（５）、（６）および（７）が行われることはない。
【００６２】
このように、投機フェッチ発行部４４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０についてのビジー状態通知信号に基づいて投機フェッチを発行するか否かを判断することによって、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が過度に高まる可能性を小さくすることができる。
【００６３】
次に、本実施例１に係る情報処理装置による投機フェッチ制御処理の処理手順について説明する。図４は、本実施例１に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。なお、ここでは、ＳＣ3４００が投機フェッチを発行する場合を例として説明する。
【００６４】
図４に示すように、ＳＣ3４００は、メモリフェッチ要求を受信すると（ステップＳ１０１）、投機フェッチ発行部４４０が、資源の消費が大きいか否か、すなわち、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高いか否かを判定する（ステップＳ１０２）。
【００６５】
その結果、資源の消費が大きくない場合には、投機フェッチを発行し、発行済フラグに「１」をセットして投機フェッチを発行したことを記録する（ステップＳ１０３）。
【００６６】
そして、キャッシュ情報の検索が終了するのを待ち、キャッシュ情報の検索が終了すると（ステップＳ１０４、肯定）、待ち合わせ部４７０が、メモリフェッチ要求がキャッシュにヒットしたか否かを判定し（ステップＳ１０５）、キャッシュにヒットしない場合には、発行済フラグが「１」であるか否かを判定する（ステップＳ１０６）。
【００６７】
その結果、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを使用し（ステップＳ１０７）、発行済フラグが「１」でない場合には、投機フェッチを発行していない場合であるので、通常のメモリアクセスを発行し、その応答データを使用する（ステップＳ１０８）。
【００６８】
一方、キャッシュにヒットした場合には、発行済フラグが「１」であるか否かを判定し（ステップＳ１０９）、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを破棄する（ステップＳ１１０）。そして、キャッシュがヒットしたＣＰＵに対してムーブアウトを要求し、その応答データを使用する（ステップＳ１１１）。
【００６９】
このように、投機フェッチ発行部４４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高いか否かを判定し、負荷が高い場合には、投機フェッチの発行を抑止することによって、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が過度に高まる可能性を小さくすることができる。
【００７０】
上述してきたように、本実施例１では、ビジー制御部４５０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷状態を管理し、高負荷になった場合に、投機フェッチ発行部４４０にＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷であることを通知し、投機フェッチ発行部４４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷である場合に、投機フェッチの発行を抑止することとしたので、投機フェッチの発行に起因してＢＵＳ−ＳＣ3−ＭＡＣ1７１０がより高負荷になることを防ぎ、メモリアクセスのレーテンシを改善することができる。
【実施例２】
【００７１】
上記実施例１では、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷である場合には投機フェッチの発行を抑止するＳＣについて説明したが、ＳＣ3４００に負荷が集中してＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷である場合にも、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０に代わるバスを利用することによって、投機フェッチを実行することができる。そこで、本実施例２では、一部のＳＣに負荷が集中した場合に、投機フェッチの応答データの転送経路を動的に変更して投機フェッチを実行するＳＣについて説明する。
【００７２】
まず、本実施例２に係るＳＣ3の構成について説明する。なお、ここでは説明の便宜上、図２に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。
【００７３】
図５は、本実施例２に係るＳＣ3８００の構成を示す機能ブロック図である。同図に示すように、このＳＣ3８００は、図２に示したＳＣ3４００と比較すると、投機フェッチ発行部４４０の代わりに投機フェッチ発行部８４０を有し、ビジー制御部４５０の代わりにビジー制御部８５０を有する。
【００７４】
投機フェッチ発行部８４０は、ＭＡＣ1６００との間のバスＢＵＳ−ＳＣ3−ＭＡＣ1７１０の状況だけでなく、ＭＡＣ1６００とＳＣ2３００との間のバスＢＵＳ−ＳＣ2−ＭＡＣ1７２０の状況に基づいてＭＡＣ1６００に対して投機フェッチを発行する処理部である。  
【００７５】
すなわち、この投機フェッチ発行部８４０は、ＭＡＣ1６００との間のバスの負荷が高い場合に、バスＢＵＳ−ＳＣ2−ＭＡＣ1７２０の状況を調べ、バスＢＵＳ−ＳＣ2−ＭＡＣ1７２０が高負荷でない場合には、投機フェッチ要求に対する応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示して投機フェッチを発行する。
【００７６】
この投機フェッチ発行部８４０が、バスＢＵＳ−ＳＣ2−ＭＡＣ1７２０が高負荷でない場合には、投機フェッチ要求に対する応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示して投機フェッチを発行することによって、ＳＣ3８００に負荷が集中した場合に投機フェッチによってＳＣ3８００により負荷が集中することを防ぐことができる。
【００７７】
ビジー制御部８５０は、ＭＡＣ1６００との間のバスの負荷状態に加えて、ＭＡＣ1６００とＳＣ2３００との間のバスＢＵＳ−ＳＣ2−ＭＡＣ1７２０の負荷状況も管理する処理部であり、バスの負荷が高い場合には、投機フェッチ発行部８４０に対してバスが高負荷であることを通知する。
【００７８】
次に、本実施例２に係る情報処理装置による投機フェッチ制御について説明する。図６は、本実施例２に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【００７９】
同図に示すように、本実施例２に係る情報処理装置は、バスＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷状態にあっても、バスＢＵＳ−ＳＣ2−ＭＡＣ1７２０は比較的負荷が低いことがあるため、バスＢＵＳ−ＳＣ3−ＭＡＣ1７１０についてビジー制御部８５０によってビジー状態の通知（３）が行われた場合に、実施例１のように投機フェッチ要求の発行を抑止することをせずに、投機フェッチ要求の応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示しつつ投機フェッチ要求をＭＡＣ1６００に発行（４）する。
【００８０】
投機フェッチ要求を受信したＭＡＣ1６００は、ＭＥＭＯＲＹ1６０に対してメモリフェッチを起動（５）し、その応答データ（１６）をＳＣ2３００に転送（１７）する。投機フェッチ要求の応答データ（１７）を受信したＳＣ2３００は、ＳＣ1２００−ＳＣ2３００間バスＢＵＳ−ＳＣ1−ＳＣ2７４０あるいはＳＣ2３００−ＳＣ3８００間バスＢＵＳ−ＳＣ2−ＳＣ3７３０を用いて転送する。
【００８１】
このように、バスＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷状態にあっても、バスＢＵＳ−ＳＣ2−ＭＡＣ1７２０を用いることで、バスＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷をさらに高めることなしに投機フェッチを実行することができ、メモリアクセスのレーテンシを改善することができる。
【００８２】
次に、本実施例２に係る情報処理装置による投機フェッチ制御処理の処理手順について説明する。図７は、本実施例２に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。なお、ここでは、ＳＣ3８００が投機フェッチを発行する場合を例として説明する。
【００８３】
図７に示すように、ＳＣ3８００は、メモリフェッチ要求を受信すると（ステップＳ２０１）、投機フェッチ発行部８４０が、自資源の消費が大きいか否か、すなわち、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高いか否かを判定する（ステップＳ２０２）。
【００８４】
その結果、自資源の消費が大きくない場合には、投機フェッチを発行し、発行済フラグに「１」をセットして投機フェッチを発行したことを記録する（ステップＳ２０３）。一方、自資源の消費が大きい場合には、代替経路の資源の消費は大きいか否か、すなわち、ＢＵＳ−ＳＣ2−ＭＡＣ1７２０の負荷が高いか否かを判定し（ステップＳ２０４）、代替経路の資源の消費が大きくない場合には、投機フェッチ要求の応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示しつつ投機フェッチを発行し、発行済フラグに「１」をセットして投機フェッチを発行したことを記録する（ステップＳ２０３）。
【００８５】
そして、キャッシュ情報の検索が終了するのを待ち、キャッシュ情報の検索が終了すると（ステップＳ２０５、肯定）、待ち合わせ部４７０が、メモリフェッチ要求がキャッシュにヒットしたか否かを判定し（ステップＳ２０６）、キャッシュにヒットしない場合には、発行済フラグが「１」であるか否かを判定する（ステップＳ２０７）。
【００８６】
その結果、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを使用し（ステップＳ２０８）、発行済フラグが「１」でない場合には、投機フェッチを発行していない場合であるので、通常のメモリアクセスを発行し、その応答データを使用する（ステップＳ２０９）。
【００８７】
一方、キャッシュにヒットした場合には、発行済フラグが「１」であるか否かを判定し（ステップＳ２１０）、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを破棄する（ステップＳ２１１）。そして、キャッシュがヒットしたＣＰＵに対してムーブアウトを要求し、その応答データを使用する（ステップＳ２１２）。
【００８８】
このように、投機フェッチ発行部８４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高い場合に、ＢＵＳ−ＳＣ2−ＭＡＣ1７２０の負荷が高いか否かを判定し、負荷が低い場合には、投機フェッチ要求の応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示しつつ投機フェッチを発行することによって、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷をさらに高くすることなく投機フェッチを実行することができる。
【００８９】
上述してきたように、本実施例２では、ビジー制御部８５０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０に加えてＢＵＳ−ＳＣ2−ＭＡＣ1７２０の負荷状態を管理し、これらのバスが高負荷になった場合に、投機フェッチ発行部８４０にバスが高負荷であることを通知し、投機フェッチ発行部８４０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷である場合に、ＢＵＳ−ＳＣ2−ＭＡＣ1７２０が高負荷であるか否かを判定し、高負荷でない場合には、投機フェッチ要求の応答データをＳＣ2３００に送出することをＭＡＣ1６００に指示しつつ投機フェッチを発行することとしたので、投機フェッチの実行に起因してＢＵＳ−ＳＣ3−ＭＡＣ1７１０がより高負荷になることを防ぐとともに、投機フェッチを実行してメモリアクセスのレーテンシを改善することができる。
【実施例３】
【００９０】
上記実施例１および２では、キャッシュ情報の検索結果と投機フェッチの応答データとの待ち合わせ場所をＳＣ3とする場合について説明したが、待ち合わせ場所は末端ＳＣとすることがレーテンシ短縮のためには有効である。しかしながら、待ち合わせ場所を末端ＳＣとすると、たとえキャッシュの検索結果によって投機フェッチの応答データを破棄することが判明した後でも、末端ＳＣまでは投棄フェッチの応答データを必ず転送しなければならない。
【００９１】
したがって、末端ＳＣまでの転送経路の負荷が高い状況においては、破棄される予定の投棄フェッチの応答データがハードウェア資源をさらに消費し、さらに負荷を高めることとなる。そこで、本実施例３では、末端ＳＣをＳＣ1２００とし、ＳＣ1２００までの転送経路の負荷が高い場合には、待ち合わせ場所を末端ＳＣ以外のＳＣに動的に変更する場合について説明する。
【００９２】
まず、本実施例３に係るＳＣ3の構成について説明する。なお、ここでは説明の便宜上、図２に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。
【００９３】
図８は、本実施例３に係るＳＣ3９００の構成を示す機能ブロック図である。同図に示すように、このＳＣ3９００は、図２に示したＳＣ3４００と比較すると、投機フェッチ発行部４４０の代わりに投機フェッチ発行部９４０を有し、ビジー制御部４５０の代わりにビジー制御部９５０を有する。
【００９４】
投機フェッチ発行部９４０は、ＭＡＣ1６００との間のバスＢＵＳ−ＳＣ3−ＭＡＣ1７１０の状況だけでなく、ＳＣ3９００とＳＣ1２００との間のバスＢＵＳ−ＳＣ1−ＳＣ3７５０の状況に基づいてＭＡＣ1６００に対して投機フェッチを発行する処理部である。
【００９５】
具体的には、この投機フェッチ発行部９４０は、待ち合わせ場所であるＳＣ1２００に投機フェッチ要求の応答データを転送する場合に使用するＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高いときは、待ち合わせ場所をＳＣ1２００からＳＣ3９００へ変更し、ＳＣ3９００を待ち合わせ場所とすることを投機フェッチの発行とともにＭＡＣ1６００に通知する。
【００９６】
この投機フェッチ発行部９４０が、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高いときに、ＳＣ3９００を待ち合わせ場所とすることを投機フェッチの発行とともにＭＡＣ1６００に通知することによって、投機フェッチの応答データを破棄する場合に、ＢＵＳ−ＳＣ1−ＳＣ3７５０が無駄に使用されることを防ぐことができる。
【００９７】
ビジー制御部９５０は、ＭＡＣ1６００との間のバスの負荷状態に加えて、ＳＣ3９００とＳＣ1２００との間のバスＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷状況も管理する処理部であり、バスの負荷が高い場合には、投機フェッチ発行部９４０に対してバスが高負荷であることを通知する。
【００９８】
次に、本実施例３に係る情報処理装置による投機フェッチ制御について説明する。図９は、本実施例３に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【００９９】
同図に示すように、本実施例３に係る情報処理装置では、ＳＣ3９００の投機フェッチ発行部９４０が、ビジー制御部９５０から通知されたＢＵＳ−ＳＣ3−ＭＡＣ1７１０のビジー状態と、ＢＵＳ−ＳＣ1−ＳＣ3７５０のビジー状態とを参照（３）する。そして、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０が高負荷状態にあるときは、投機フェッチ要求の発行を抑止し、そうでなければ投機フェッチ要求を発行（４）する。
【０１００】
このとき、ＢＵＳ−ＳＣ1−ＳＣ3７５０が高負荷状態にあるときは、投機フェッチ要求の応答データとキャッシュの検索結果（８）の待ち合わせ場所として、ＳＣ1２００に代わりＳＣ3９００を待ち合わせ場所とすることを、投機フェッチ要求の発行とともにＭＡＣ1６００に通知する。
【０１０１】
投機フェッチ要求を受信したＭＡＣ1６００は、ＭＥＭＯＲＹ1６０に対してメモリフェッチ要求を起動（５）し、その応答データ（６）をＳＣ3９００に転送（７）する。このとき、ＭＡＣ1６００は投機フェッチ要求の発行時にＳＣ3９００で待ち合わせすることを通知されたことを同時に報告する。
【０１０２】
投機フェッチ要求の応答データを受信したＳＣ3９００は、ＳＣ3９００の待ち合わせ部４７０にて、投機フェッチ要求の応答データとキャッシュの検索結果（８）を待ち合わせる。そして、キャッシュの検索結果によって投機フェッチ要求の応答データを破棄することが判明した場合には、待ち合わせ部４７０にて破棄される。
【０１０３】
このように、待ち合わせ場所をＳＣ3９００に動的に変更することによって、投機フェッチの応答データを破棄する場合にＳＣ3９００とＳＣ1２００との間のバスＢＵＳ−ＳＣ1−ＳＣ3７５０の高負荷状態をさらに悪化させることを防ぐことができる。
【０１０４】
次に、本実施例３に係る情報処理装置による投機フェッチ制御処理の処理手順について説明する。図１０は、本実施例３に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。なお、ここでは、ＳＣ3９００が投機フェッチを発行する場合を例として説明する。
【０１０５】
図１０に示すように、ＳＣ3９００は、メモリフェッチ要求を受信すると（ステップＳ３０１）、投機フェッチ発行部９４０が、自資源の消費が大きいか否か、すなわち、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０の負荷が高いか否かを判定する（ステップＳ３０２）。
【０１０６】
その結果、自資源の消費が大きくない場合には、待ち合わせ場所に応答データを転送する場合に使用する資源の消費は大きいか否か、すなわち、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高いか否かを判定し（ステップＳ３０３）、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高い場合には、待ち合わせ場所を代替場所、すなわちＳＣ3９００とすることをＭＡＣ1６００に指示しつつ投機フェッチを発行し、発行済フラグに「１」をセットして投機フェッチを発行したことを記録する（ステップＳ３０４）。
【０１０７】
一方、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高くない場合には、待ち合わせ場所を末端ＳＣとして投機フェッチを発行し、発行済フラグに「１」をセットして投機フェッチを発行したことを記録する（ステップＳ３０５）。
【０１０８】
そして、キャッシュ情報の検索が終了するのを待ち、キャッシュ情報の検索が終了すると（ステップＳ３０６、肯定）、待ち合わせ場所として指定されたＳＣの待ち合わせ部４７０が、メモリフェッチ要求がキャッシュにヒットしたか否かを判定し（ステップＳ３０７）、キャッシュにヒットしない場合には、発行済フラグが「１」であるか否かを判定する（ステップＳ３０８）。
【０１０９】
その結果、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを使用し（ステップＳ３０９）、発行済フラグが「１」でない場合には、投機フェッチを発行していない場合であるので、通常のメモリアクセスを発行し、その応答データを使用する（ステップＳ３１０）。
【０１１０】
一方、キャッシュにヒットした場合には、発行済フラグが「１」であるか否かを判定し（ステップＳ３１１）、発行済フラグが「１」である場合には、投機フェッチを発行した場合であるので、投機フェッチの応答データを破棄する（ステップＳ３１２）。そして、キャッシュがヒットしたＣＰＵに対してムーブアウトを要求し、その応答データを使用する（ステップＳ３１３）。
【０１１１】
このように、投機フェッチ発行部９４０が、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高いか否かを判定し、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷が高い場合には、待ち合わせ場所を代替場所、すなわちＳＣ3９００とすることをＭＡＣ1６００に指示しつつ投機フェッチを発行することによって、ＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷をさらに高くすることなく投機フェッチを実行することができる。
【０１１２】
上述してきたように、本実施例３では、ビジー制御部９５０が、ＢＵＳ−ＳＣ3−ＭＡＣ1７１０に加えてＢＵＳ−ＳＣ1−ＳＣ3７５０の負荷状態を管理し、これらのバスが高負荷になった場合に、投機フェッチ発行部９４０にバスが高負荷であることを通知し、投機フェッチ発行部９４０が、投機フェッチを発行する場合に、ＢＵＳ−ＳＣ1−ＳＣ3７５０が高負荷であるか否かを判定し、高負荷である場合には、待ち合わせ場所をＳＣ3９００に変更することをＭＡＣ1６００に指示しつつ投機フェッチを発行することとしたので、投機フェッチの発行に起因してＢＵＳ−ＳＣ1−ＳＣ3７５０がより高負荷になることを防ぐことができる。
【０１１３】
また、本実施例１〜３では、ＩＯＰ0７０がＭＥＭＯＲＹ1６０に実装されたアドレスに対するメモリフェッチを実行する場合について説明したが、本発明はこれに限定されるものではなく、ＣＰＵや他のＩＯＰがＭＥＭＯＲＹ1６０またはＭＥＭＯＲＹ0５０に実装されたアドレスに対するメモリフェッチを実行する場合にも同様に適用することができる。また、ＣＰＵ、ＳＣ、ＭＡＣなどの数が異なる場合にも同様に適用することができる。
【０１１４】
また、本実施例１〜３では、バスの負荷状態に基づいて投機フェッチを制御する場合について説明したが、本発明はこれに限定されるものではなく、他のハードウェア資源、例えば、バッファの負荷状態に基づいて投機フェッチを制御する場合にも同様に適用することができる。ここで、バッファのビジー管理は、バッファ内の有効なエントリ数を数えることで管理することができる。
【０１１５】
（付記１）メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、
前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、
を備えたことを特徴とするシステム制御装置。
【０１１６】
（付記２）前記消費量判定手段により消費状況が監視されるハードウェア資源は、メモリフェッチを依頼するメモリ制御装置を接続するバスであることを特徴とする付記１に記載のシステム制御装置。
【０１１７】
（付記３）前記消費量判定手段は、前記バスの一定期間中の使用率を用いて該バスの消費量が所定の値以上であるか否かを判定することを特徴とする付記２に記載のシステム制御装置。
【０１１８】
（付記４）前記消費量判定手段により消費状況が監視されるハードウェア資源は、投機フェッチで使用するバッファであることを特徴とする付記１に記載のシステム制御装置。
【０１１９】
（付記５）前記消費量判定手段は、前記バッファ内の有効なエントリ数を用いて該バッファの消費量が所定の値以上であるか否かを判定することを特徴とする付記４に記載のシステム制御装置。
【０１２０】
（付記６）前記投機フェッチ発行手段は、前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする付記１に記載のシステム制御装置。
【０１２１】
（付記７）前記投機フェッチ発行手段は、自装置以外の他のシステム制御装置を利用することによって前記代替ハードウェア資源があるか否かを判定することを特徴とする付記６に記載のシステム制御装置。
【０１２２】
（付記８）前記投機フェッチ発行手段は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする付記１または６に記載のシステム制御装置。
【０１２３】
（付記９）前記投機フェッチ発行手段は、前記代替待ち合わせ場所として自装置を指定して投機フェッチを実行することを特徴とする付記８に記載のシステム制御装置。
【０１２４】
（付記１０）メモリフェッチを行う際に、フェッチするデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行する情報処理装置であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定手段と、
前記消費量判定手段により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行手段と、
を備えたことを特徴とする情報処理装置。
【０１２５】
（付記１１）メモリフェッチ要求により要求されたデータがキャッシュにあるか否かがキャッシュのタグ情報を検索することによって判明する前にメモリに対して投機フェッチを実行するシステム制御装置による投機フェッチ方法であって、
前記投機フェッチで使用するハードウェア資源の消費状況を監視し、該ハードウェア資源の消費量が所定の値以上であるか否かを判定する消費量判定工程と、
前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合には、投機フェッチの発行を抑止する投機フェッチ発行工程と、
を含んだことを特徴とする投機フェッチ方法。
【０１２６】
（付記１２）前記消費量判定工程により消費状況が監視されるハードウェア資源は、メモリフェッチを依頼するメモリ制御装置を接続するバスであることを特徴とする付記１１に記載の投機フェッチ方法。
【０１２７】
（付記１３）前記消費量判定工程は、前記バスの一定期間中の使用率を用いて該バスの消費量が所定の値以上であるか否かを判定することを特徴とする付記１２に記載の投機フェッチ方法。
【０１２８】
（付記１４）前記消費量判定工程により消費状況が監視されるハードウェア資源は、投機フェッチで使用するバッファであることを特徴とする付記１１に記載の投機フェッチ方法。
【０１２９】
（付記１５）前記消費量判定工程は、前記バッファ内の有効なエントリ数を用いて該バッファの消費量が所定の値以上であるか否かを判定することを特徴とする付記１４に記載の投機フェッチ方法。
【０１３０】
（付記１６）前記投機フェッチ発行工程は、前記消費量判定工程により前記ハードウェア資源の消費量が所定の値以上であると判定された場合に、該ハードウェア資源の代わりに使用することができる代替ハードウェア資源があるか否かを判定し、代替ハードウェア資源があるときは、代替ハードウェア資源を用いて投機フェッチを実行することを特徴とする付記１１に記載の投機フェッチ方法。
【０１３１】
（付記１７）前記投機フェッチ発行工程は、自装置以外の他のシステム制御装置を利用することによって前記代替ハードウェア資源があるか否かを判定することを特徴とする付記１６に記載の投機フェッチ方法。
【０１３２】
（付記１８）前記投機フェッチ発行工程は、投機フェッチの応答データと前記タグ情報の検索結果との待ち合わせを行う待ち合わせ場所への応答データの転送に使用するハードウェア資源の消費量が所定の値以上である場合には、該待ち合わせ場所に代わる代替待ち合わせ場所を指定して投機フェッチを実行することを特徴とする付記１１または１６に記載の投機フェッチ方法。
【０１３３】
（付記１９）前記投機フェッチ発行工程は、前記代替待ち合わせ場所として自装置を指定して投機フェッチを実行することを特徴とする付記１８に記載の投機フェッチ方法。
【産業上の利用可能性】
【０１３４】
以上のように、本発明に係るシステム制御装置、投機フェッチ方法および情報処理装置は、ストアイン方式のキャッシュを内蔵するＣＰＵを具備し、アドレスインタリーブされた複数のＳＣによってキャッシュのコヒーレンスを解決する計算機システムに有用であり、特に、投機フェッチに起因するメモリアクセスのレーテンシの悪化が顕著である場合に適している。
【図面の簡単な説明】
【０１３５】
【図１】本実施例１に係る情報処理装置の構成を示す機能ブロック図である。
【図２】ＳＣ3の構成を示す機能ブロック図である。
【図３】本実施例１に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【図４】本実施例１に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。
【図５】本実施例２に係るＳＣ3の構成を示す機能ブロック図である。
【図６】本実施例２に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【図７】本実施例２に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。
【図８】本実施例３に係るＳＣ3の構成を示す機能ブロック図である。
【図９】本実施例３に係る情報処理装置による投機フェッチ制御を説明するための説明図である。
【図１０】本実施例３に係る情報処理装置による投機フェッチ制御処理の処理手順を示すフローチャートである。
【符号の説明】
【０１３６】
１０    ＣＰＵ0
２０    ＣＰＵ1
３０    ＣＰＵ2
４０    ＣＰＵ3
５０    ＭＥＭＯＲＹ0
６０    ＭＥＭＯＲＹ1
７０    ＩＯＰ0
８０    ＩＯＰ1
１００    ＳＣ0
２００    ＳＣ1
３００    ＳＣ2
４００    ＳＣ3
４１０    要求受付部
４２０    キャッシュ検索部
４３０    キャッシュ情報記憶部
４４０，８４０，９４０    投機フェッチ発行部
４５０，８５０，９５０    ビジー制御部
４６０    メモリアクセス部
４７０    待ち合わせ部
５００    ＭＡＣ0
６００    ＭＡＣ1
７１０    ＢＵＳ−ＳＣ3−ＭＡＣ1
７２０    ＢＵＳ−ＳＣ2−ＭＡＣ1
７３０    ＢＵＳ−ＳＣ2−ＳＣ3
７４０    ＢＵＳ−ＳＣ1−ＳＣ2
７５０    ＢＵＳ−ＳＣ1−ＳＣ3
【図１】
2006053857.tif 000003
【図２】
2006053857.tif 000004
【図３】
2006053857.tif 000005
【図４】
2006053857.tif 000006
【図５】
2006053857.tif 000007
【図６】
2006053857.tif 000008
【図７】
2006053857.tif 000009
【図８】
2006053857.tif 000010
【図９】
2006053857.tif 000011
【図１０】
2006053857.tif 000012