(57)【特許請求の範囲】
【請求項１】
キャッシュメモリと、
ギャザーロード命令の処理対象となる全ての要素データについて、予め決められた複数の要素データにグループ分割して、同じグループに含まれる複数の要素データが同時にアクセス可能であるか否かに依らず各グループ１回の前記キャッシュメモリに対するキャッシュ要求を発行する発行部と、
前記ギャザーロード命令の処理対象となる各要素データのアドレスを比較し、同じグループに含まれる要素データが同時にアクセス可能であるかを判定する比較部と、
前記発行部から発行されたキャッシュ要求を登録するロードキューに登録されたキャッシュ要求に応じて前記キャッシュメモリにアクセスするとともに、前記比較部により同時にアクセス可能であると判定された全ての要素データを１回のアクセスにより処理するキャッシュ制御部とを有する演算処理装置。
【請求項２】
前記キャッシュ制御部は、前記グループ内に前記比較部により同時にアクセス可能ではないと判定された対象要素データが含まれる場合、処理した要素データに応じて前記ロードキューに登録された該グループのキャッシュ要求の情報を更新し、更新した情報に基づいて前記対象要素データが含まれるグループ内に属する同時にアクセス可能ではないと判定された他の要素データに係るアクセスを行う請求項１記載の演算処理装置。
【請求項３】
前記演算処理装置はさらに、前記ギャザーロード命令の処理対象となる各要素データについてロードが必要であるか否かを示すマスク情報を保持するマスクレジスタを有し、
前記キャッシュ制御部は、前記マスク情報に基づき、ロードが必要であると示された要素データに係るアクセスだけを行う請求項１又は２記載の演算処理装置。
【請求項４】
前記キャッシュ制御部は、前記グループ内に前記マスク情報に基づき、ロードが必要であると示された要素データがない場合、前記ロードキューに前記キャッシュ要求を処理完了状態で登録し、前記キャッシュメモリへのアクセスを実行しない請求項３記載の演算処理装置。
【請求項５】
前記キャッシュ制御部はさらに、ストアデータを登録するストアキューを有し、同じグループに含まれる要素データのうち、後続のロード対象の要素データのアドレスを前記ストアキューに登録し、後続のロードを行う場合、前記ストアキューからアドレスを読み出して前記ロードキューに登録する該グループのキャッシュ要求の情報を更新する請求項１〜４の何れか１項に記載の演算処理装置。
【請求項６】
前記キャッシュ制御部は、前記キャッシュメモリへのアクセスを行う複数の処理部を有し、前記キャッシュ要求を投入し実行する前記処理部と前記グループとの対応を、前記要素データのサイズに応じて切り替える請求項１〜５の何れか１項に記載の演算処理装置。
【請求項７】
前記演算処理装置はさらに、
前記ギャザーロード命令の処理対象となる各要素データのアドレスを生成するアドレス生成部と、
要素データ毎に複数のオフセットアドレスを保持するとともに、前記要素データのサイズに応じて、前記複数のオフセットアドレスのいずれかを出力するベクトルレジスタを有し、
前記アドレス生成部は、前記要素データのサイズに応じて前記ベクトルレジスタから出力される各要素データに対応するオフセットアドレスを用いて、前記ギャザーロード命令の処理対象となる各要素データのアドレスを生成する請求項１〜６の何れか１項に記載の演算処理装置。
【請求項８】
キャッシュメモリを有する演算処理装置の制御方法において、
前記演算処理装置が有する発行部が、ギャザーロード命令の処理対象となる全ての要素データについて、予め決められた複数の要素データにグループ分割して、同じグループに含まれる複数の要素データが同時にアクセス可能であるか否かに依らず各グループ１回の前記キャッシュメモリに対するキャッシュ要求を発行し、
前記演算処理装置が有する比較部が、前記ギャザーロード命令の処理対象となる各要素データのアドレスを比較し、同じグループに含まれる要素データが同時にアクセス可能であるかを判定し、
前記演算処理装置が有するキャッシュ制御部が、前記発行部から発行されたキャッシュ要求を登録するロードキューに登録されたキャッシュ要求に応じて前記キャッシュメモリにアクセスするとともに、前記比較部により同時にアクセス可能であると判定された全ての要素データを１回のアクセスにより処理する演算処理装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演算処理装置及び演算処理装置の制御方法に関する。
【背景技術】
【０００２】
近年、演算処理装置としてのプロセッサの演算機能についてのベクトル化及びＳＩＭＤ（Single Instruction, Multiple Data）化によってアプリケーションの性能向上が図られている。ロードの対象となる複数の要素データの演算を一つの命令で同時実行することで、プロセッサは、演算スループットが上がりプロセッサとしての性能も向上する。アプリケーションをＳＩＭＤ化するには、主記憶メモリとレジスタとの間のデータのやりとりもＳＩＭＤ化する必要がある。ここで、「要素データ」とは、ロードの対象となる個々のデータのことを指す。
【０００３】
メモリ上の連続する領域に記憶されたデータとレジスタとの間でのデータのやり取りをＳＩＭＤ化するのは容易であるが、アプリケーションのメモリアクセスは必ずしも連続する領域へのアクセスとはならない。例えば、科学技術計算の中には、疎行列演算やデータ構造体を扱うアプリケーションも多く、メモリ上で非連続な領域に記憶されたデータに対してもＳＩＭＤ化して高速化を図りたいという要望がある。
【０００４】
従来、メモリ上の非連続な領域に記憶されたデータとレジスタとの間でのデータのやり取りは、シフト命令、データ挿入命令、及びレジスタ上のデータ移動命令等の複数の命令を使ってプログラムされていたため、プログラミングが複雑になる上、性能も出ないという問題点がある。そのため、近年では、メモリ上で非連続な領域にそれぞれ記憶された複数のデータを一つのレジスタに集約してロードする命令として、キャザーロード（ＧＡＴＨＥＲ−ＬＯＡＤ）命令を持つプロセッサが登場してきている。
【０００５】
ＧＡＴＨＥＲ−ＬＯＡＤ命令は、自由度が高くプログラミングを容易にするが、ハードウェアとして高速に処理することは難しく、実際には十分な性能が得られていないという問題点がある。また、キャッシュアクセスやメモリアクセスできるデータサイズ及びデータ範囲は、物理的なハードウェア構成によって制約を受け、例えばキャッシュラインが異なるデータは同時にアクセスできないのが一般的である。
【０００６】
ＧＡＴＨＥＲ−ＬＯＡＤ命令は、複数のロードの対象である全要素データがそれぞれ全く違うアドレスをアクセスする可能性があるため、最悪ケースを想定すると１要素データずつの処理に分解して各要素データを並列にロードする実装方法が考えられる。しかし、１要素データずつ処理を行った場合、ＧＡＴＨＥＲ−ＬＯＡＤ命令の処理としてはＳＩＭＤ化のスループット性能効果は得られない。
【０００７】
ＧＡＴＨＥＲ−ＬＯＡＤ命令のスループット性能を上げようとすると、複数の要素データを同時にアクセス可能な場合には同時にロードすることで、キャッシュアクセスの回数を減らすことが考えられる。具体的には、ロードの対象となる要素データ毎にロードする必要があるか否かを示すマスク情報と組み合わせて、同時にロードできる要素データから順番に処理していくことが考えられる。
【０００８】
この方式では、まずロードする必要がある（マスク情報が１である）先頭要素データに対する要求を発行してロード処理を行う。その際、ロードする必要のある先頭要素データと同一のキャッシュラインにある後続要素データとを同時に処理し、処理が完了した各要素データのマスク情報を０に落として処理済の状態に更新する。次に、先頭側から見て最初にマスク情報が１（ロード処理を実行する必要あり）の要素データに対して再実行して後続のロード処理を行う。
【０００９】
上記の処理を、ロードする必要がある（マスク情報が１である）要素データが存在する間は複数回の再実行を繰り返して実行し、ロードする必要がある要素データがなくなる（マスク情報が全て０）になったらＧＡＴＨＥＲ−ＬＯＡＤ命令全体が終了したことになる。この方式では、前回の処理結果によってマスク情報と次に処理すべき要素データが決まるため、逐次処理になり全体のレイテンシが長くなり性能が出ないという問題がある。
【００１０】
この方式をハードウェアで実装する例として、特許文献１に記載のような方法があるが、ＧＡＴＨＥＲ制御部に全要素データのアドレス、マスク、オフセットを保持するハードウェア資源が必要になり、回路の物量が大幅に増加してしまう。また、この方式をプログラムレベルで複数回のＧＡＴＨＥＲ−ＬＯＡＤ命令を再実行するようにしてソフトウェアで実装することも考えられるが、ロード対象のアドレス範囲が複数のキャッシュラインに跨る場合には、ＧＡＴＨＥＲ−ＬＯＡＤ命令を何回も逐次処理することとなり、レイテンシが非常に大きくなってしまう。
【００１１】
また、前の要素データの処理完了に伴うマスク情報の更新と次の要素データに係るアドレス生成とを、ハードウェア内部的には命令発行部・命令演算部のレベルで逐次的な複数処理に分割しているプロセッサにおいて、次のような方法が提案されている（特許文献２参照）。複数処理ベクトルレジスタから変換したアドレスオフセットとマスク情報とを持つインデックステーブルをアドレス生成器の近くに持つことで、前の要素データの処理完了に伴うマスク情報の更新と次の要素データのためのアドレス生成を同時に処理し、ハードウェア内部で分割している逐次的な複数処理の数を減らすことで性能向上を図っている。また、アドレスオフセットが全く同一の要素データが存在する場合、先頭要素データとして読んだデータをベクトルレジスタの全要素データにブロードキャストしておき、実際の書き込み信号を複数同時にアサートして同時に処理することで高速化を図っている。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許出願公開第２０１２／０２５４５４２号明細書
【特許文献２】米国特許出願公開第２０１５／００７４３７３号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１３】
１つの側面では、本発明の目的は、高スループット及び低レイテンシでギャザーロード命令を実行することが可能な演算処理装置を提供することにある。
【課題を解決するための手段】
【００１４】
演算処理装置の一態様は、キャッシュメモリと、ギャザーロード命令の処理対象となる全ての要素データについて、予め決められた複数の要素データにグループ分割して、同じグループに含まれる複数の要素データが同時にアクセス可能であるか否かに依らず各グループ１回のキャッシュメモリに対するキャッシュ要求を発行する発行部と、ギャザーロード命令の処理対象となる各要素データのアドレスを比較し、同じグループに含まれる要素データが同時にアクセス可能であるかを判定する比較部と、発行部から発行されたキャッシュ要求を登録するロードキューに登録されたキャッシュ要求に応じてキャッシュメモリにアクセスするキャッシュ制御部とを有する。キャッシュ制御部は、比較部により同時にアクセス可能であると判定された全ての要素データを１回のアクセスにより処理する。
【発明の効果】
【００１５】
発明の一態様においては、複数の要素データからなるグループ内で同時にアクセス可能な要素データを１回のアクセスにより処理することで、高スループット及び低レイテンシでギャザーロード命令を実行することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態における演算処理装置の構成例を示す図である。
【図２】図１に示したロードキューのエントリの構成例を示す図である。
【図３】図１に示した演算処理装置における処理例を示すフローチャートである。
【図４】本発明の実施形態における演算処理装置の他の構成例を示す図である。
【図５】図４に示したロードキューのエントリの構成例を示す図である。
【図６】図４に示した演算処理装置における処理例を示すフローチャートである。
【図７】本実施形態における演算処理装置の動作例を示すタイムチャートである。
【図８】演算処理装置の動作例を示すタイムチャートである。
【図９】本実施形態における演算処理装置の動作例を示すタイムチャートである。
【図１０】本実施形態における演算処理装置の動作例を示すタイムチャートである。
【図１１】図４に示す例でのストアキューのエントリ登録情報の例を示す図である。
【図１２】図４に示す例でのストアキューのエントリ登録情報の他の例を示す図である。
【図１３】本実施形態における演算処理装置の動作例を示すタイムチャートである。
【図１４】ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部、アドレス保持ラッチ、及びアドレス比較回路の回路例を示す図である。
【図１５】ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部、アドレス保持ラッチ、及びアドレス比較回路の回路例を示す図である。
【図１６】ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部、アドレス保持ラッチ、及びアドレス比較回路の回路例を示す図である。
【図１７】ＧＡＴＨＥＲ−ＬＯＡＤ命令の処理を２要素データでグループ化した例を示す図である。
【発明を実施するための形態】
【００１７】
本発明の実施形態を図面に基づいて説明する。
【００１８】
以下に説明するように本発明の実施形態においては、演算処理装置としてのプロセッサが実行するギャザーロード（ＧＡＴＨＥＲ−ＬＯＡＤ）命令の処理を、１要素データずつ分解して並列処理するのではなく、複数の要素データのグループ単位に分解して処理する。各グループの単位で一次データキャッシュ要求の発行、ロードキューの獲得、及びパイプライン実行を行い、異なるグループの処理は並列に処理する。
【００１９】
本実施形態では、同じグループの複数の要素データがすべて同時にキャッシュアクセス可能な場合、一度に複数の要素データのロード処理を行うことで、ＧＡＴＨＥＲ−ＬＯＡＤ命令全体のスループット性能の向上を図る。また、各要素データをロードする必要があるか否かを示すマスク情報が定義されている場合、同じグループの全ての要素データがロードする必要がない場合、そのグループについては処理部としてのキャッシュパイプラインを消費せずに即座に処理を完了する。同じグループの複数の要素データが同時にキャッシュアクセスできない場合、同時にキャッシュアクセスできる要素データ毎に、ロードキューから再実行してキャッシュアクセスを行う。
【００２０】
図１７に、ＧＡＴＨＥＲ−ＬＯＡＤ命令の処理を２要素データでグループ化した例を示す。図１７（Ａ）には、８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令を２要素単位でグループ化した例を示しており、１７１０−１、１７１０−２、１７１０−３、１７１０−４、１７１０−５がそれぞれ１回のキャッシュアクセスで読み出せる範囲を示している。メモリ上で非連続な領域に記憶された要素データ００〜要素データ０７の８個の要素データをベクトルレジスタ１７１１にロードする際、例えば要素データ００と要素データ０１とをグループ０、要素データ０２と要素データ０３とをグループ１、要素データ０４と要素データ０５とをグループ２、要素データ０６と要素データ０７とをグループ３にグループ分割する。
【００２１】
グループ１の要素データ０２と要素データ０３は、１回のキャッシュアクセスで読み出せる範囲内にないため、２回のキャッシュアクセスが必要となる。一方、グループ０の要素データ００と要素データ０１、グループ２の要素データ０４と要素データ０５、グループ３の要素データ０６と要素データ０７は、１回のキャッシュアクセスで読み出せる範囲内にあるため、１回のキャッシュアクセスにより処理することができる。したがって、合計５回のキャッシュパイプラインの実行で要素データ００〜要素データ０７の処理を完了することができ、１要素データずつ処理する場合（合計８回）と比較してＧＡＴＨＥＲ−ＬＯＡＤ命令に係るスループットを向上させることができる。
【００２２】
図１７（Ｂ）には、４バイト×１６ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令を２要素単位でグループ化した例を示しており、１７２０−１、１７２０−２、１７２０−３、１７２０−４、１７２０−５がそれぞれ１回のキャッシュアクセスで読み出せる範囲を示している。メモリ上で非連続な領域に記憶された要素データ００〜要素データ１５の１６個の要素データをベクトルレジスタ１７２１にロードする際、例えば要素データ００と要素データ０１とをグループ０、要素データ０２と要素データ０３とをグループ１、要素データ０４と要素データ０５とをグループ２、要素データ０６と要素データ０７とをグループ３、要素データ０８と要素データ０９とをグループ４、要素データ１０と要素データ１１とをグループ５、要素データ１２と要素データ１３とをグループ６、要素データ１４と要素データ１５とをグループ７にグループ分割する。
【００２３】
グループ４の要素データ０８と要素データ０９は、１回のキャッシュアクセスで読み出せる範囲内にないため、２回のキャッシュアクセスが必要となる。一方、グループ０の要素データ００と要素データ０１、グループ１の要素データ０２と要素データ０３、グループ２の要素データ０４と要素データ０５、グループ３の要素データ０６と要素データ０７、グループ５の要素データ１０と要素データ１１、グループ６の要素データ１２と要素データ１３、グループ７の要素データ１４と要素データ１５は、１回のキャッシュアクセスで読み出せる範囲内にあるため、１回のキャッシュアクセスにより処理することができる。したがって、合計９回のキャッシュパイプラインの実行で要素データ００〜要素データ１５の処理を完了することができ、１要素データずつ処理する場合（合計１６回）と比較してＧＡＴＨＥＲ−ＬＯＡＤ命令に係るスループットを向上させることができる。
【００２４】
図１は、本発明の実施形態における演算処理装置（プロセッサ）の構成例を示す図である。図１には、本実施形態における演算処理装置が有する構成のうちＧＡＴＨＥＲ−ＬＯＡＤ命令の処理に係る構成だけを図示している。本実施形態における演算処理装置は、命令発行部１１０、命令実行部１２０、及び一次キャッシュ部１３０を有する。
【００２５】
ＧＡＴＨＥＲ−ＬＯＡＤ命令の実行時には、ＧＡＴＨＥＲ−ＬＯＡＤアドレス計算指示が命令発行部１１０から命令実行部１２０に出る。ＧＡＴＨＥＲ−ＬＯＡＤ命令では、ベースアドレスが指示されるとともにオフセットアドレスが要素データ毎に指示される。図１に示した例では、ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部１２３が、スカラレジスタ１２１から供給されるベースアドレス及びベクトルレジスタ１２２から供給される要素データ毎のオフセットアドレスに基づいて、全要素データのアドレスを計算する。計算された全要素データのアドレスは、アドレス保持ラッチ１２４に保持されてアドレス比較回路１２５に供給される。
【００２６】
アドレス比較回路１２５は、供給された各要素データのアドレスを基に、同じグループに含まれる要素データが同時にキャッシュアクセス可能であるかどうかを判定する。また、アドレス比較回路１２５は、命令発行部１１０からグループ単位に一次データキャッシュ要求が発行されるのとタイミングをあわせて、そのグループの全要素データのアドレス及びアドレス比較結果を一次キャッシュ部１３０に出力する。また、命令実行部１２０では、アドレス計算と並行してマスクレジスタ１２６からマスク情報が読み出されて一次キャッシュ部１３０に出力される。
【００２７】
制御部としての一次キャッシュ部１３０は、命令発行部１１０からの一次データキャッシュ要求と命令実行部１２０からの一次データキャッシュ要求のグループ情報（各要素データのアドレス、マスク情報、アドレス比較結果）をロードキュー１３１に登録する。図１に示した例では、８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令を２要素データずつの４つのグループに分割して一次データキャッシュ要求を発行した例を示しており、ロードキュー１３１のエントリ＜Ｎ＞、エントリ＜Ｎ＋１＞、エントリ＜Ｎ＋２＞、エントリ＜Ｎ＋３＞の４つのエントリに図２に示すように登録されている。
【００２８】
図２は、図１に示したロードキュー１３１のエントリの構成例を示す図である。状態フラグ２０１は、エントリの状態を示すフラグである。状態フラグ２０１は、例えば２ビットで“００”がエントリの情報が無効であることを示し、“０１”がキャッシュパイプラインに投入不可の状態を示し、“１０”がキャッシュパイプラインに投入可能であることを示し、“１１”がキャッシュパイプラインで処理中であることを示している。キャッシュパイプラインに投入不可の状態は、例えば一次データキャッシュミスで二次キャッシュに要求している状態であり、二次キャッシュからデータがくると状態フラグ２０１は“１０”に遷移してキャッシュパイプライン投入待ちとなる。
【００２９】
要素データサイズ２０２は、各要素データのサイズを示す情報であり、グループ番号２０３は複数の要素データをグループ化したグループＩＤを示す情報である。アドレス比較結果２０４は、アドレス比較回路１２５でのアドレス比較結果であり、処理完了フラグ２０５は、各要素データの処理完了を示すフラグである。本実施形態では、処理完了フラグ２０５は、例えば２ビットで“００”が２要素データとも処理が未完了であることを示し、“１０”が先頭要素データのみ処理が完了したことを示し、“０１”が後続要素データのみ処理が完了したことを示し、“１１”が２要素データとも処理が完了したことを示す。
【００３０】
マスクフラグ２０６は、各要素データについてロードが必要であるか否かを示すフラグである。本実施形態では、マスクフラグ２０６は、例えば２ビットで“００”が２要素データともロードが不要であることを示し、“１０”が先頭要素データのみロードが必要であることを示し、“０１”が後続要素データのみロードが必要であることを示し、“１１”が２要素データともロードが必要であることを示す。先頭要素アドレス２０７は先頭要素データを読み出すためのアドレスであり、後続要素アドレス２０８は後続要素データを読み出すためのアドレスである。
【００３１】
ロードキュー１３１に登録された各グループの要求は、一次データキャッシュパイプライン＜０＞１３２又は一次データキャッシュパイプライン＜１＞１３３に投入されて一次データキャッシュメモリ１３４に対するアクセスが実行され、同時に返せる全要素データを同時に処理する。パイプライン実行が終わると、処理要求の情報（ロードキュー番号、一次データキャッシュ処理の結果)を基に、対応するロードキュー１３１のエントリの情報を更新する。
【００３２】
図３は、図１に示した演算処理装置におけるＧＡＴＨＥＲ−ＬＯＡＤ命令の処理例を示すフローチャートである。まず、ステップＳ３０１にて、グループ単位で命令発行部１１０から一次キャッシュ部１３０に要求が発行される。ステップＳ３０２にて、一次キャッシュ部１３０は、対象のグループの全要素データの中に処理すべき要素データ（マスク情報が１である要素データ）が存在するか否かを判定する。処理すべき要素データがない（マスク情報が全て０である）場合、ステップＳ３０３へ進み、一次キャッシュ部１３０は、キャッシュパイプラインには処理投入を行わずにロードキュー１３１に処理完了状態で登録する。
【００３３】
一方、処理すべき要素データがある（マスク情報が１の要素データがある）場合、ステップＳ３０４へ進み、一次キャッシュ部１３０は、キャッシュパイプラインにキャッシュアクセス処理を投入する。キャッシュパイプライン処理では、ステップＳ３０５にて、一次キャッシュ部１３０は、処理すべき要素データ（マスク情報が１の要素データ）に、同時に処理できない要素データが含まれているか否かを判定する。判定の結果、同時に処理できない要素データがない場合（ステップＳ３０５のＮＯ）、ステップＳ３０６にて、一次キャッシュ部１３０は、同時にキャッシュアクセスしてデータ応答を返してロードキュー１３１に処理完了状態で登録する。
【００３４】
ステップＳ３０５での判定の結果、同時に処理できない要素データがある場合（ＹＥＳ）、ステップＳ３０７にて、一次キャッシュ部１３０は、同時にキャッシュアクセスして返せるデータ応答し、ロードキュー１３１の該グループのキャッシュ要求の情報を更新する。その後、ステップＳ３０４へ戻り、キャッシュパイプラインに再投入して、処理できなかった要素データのパイプライン処理を継続し、ステップＳ３０５で全要素データがデータ応答完了と判定されるまで繰り返す。
【００３５】
このようにして、各要素データに対応してロード処理する必要かあるかどうかの情報であるマスク情報に応じて、対象のグループの全要素データが実行する必要がない場合、一次データキャッシュ要求の発行と同時に処理完了扱いでロードキュー１３１に登録し、キャッシュアクセスの実行は行わないように制御する。これによって、実行する必要のない要素データ数が多い場合には、無駄に一次データキャッシュパイプラインを消費しないことで、他の処理が投入可能となりパイプラインの利用効率を向上させることができる。
【００３６】
また、同じグループの中に同時に読み出しできない要素データが存在した場合、パイプライン実行結果に応じてロードキュー１３１が更新された後に、さらに処理すべき後続要素データのキャッシュアクセス処理を一次データキャッシュパイプラインに再投入して、複数回のキャッシュアクセスで対象のグループの全要素データの処理を行う。すべての要素データが処理完了したら、一次キャッシュ部１３０から命令発行部１１０に完了報告が行われる。本実施形態では、ロードキュー１３１から再投入して一次キャッシュ部１３０内で回転することで、後続要素データが再実行される際のオーバーヘッドを抑えることができる。
【００３７】
各グループの後続要素データのキャッシュアクセス処理を再投入するためには、後続要素データのアドレスが必要になり、図１に示した例では各グループ単位で割り当てられるロードキュー１３１のエントリに後続要素データのアドレスを保持している。図４に示すように全グループの後続要素データのアドレスをストアキュー１３５に登録することで、ロードキュー１３１のハードウェア物量の増加を抑えることが可能となる。この場合、処理する必要のある先頭要素データが一次データキャッシュパイプライン処理している間に、次の要素データのアドレスをストアキュー１３５から選択しておき、ロードキュー１３１に登録するアドレスを上書き更新する。
【００３８】
図４は、本実施形態における演算処理装置（プロセッサ）の他の構成例を示す図である。図４において、図１に示した構成要素と同一の機能を有する構成要素には同一の符号を付し、重複する説明は省略する。図１に示した例との違いは、ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部１２３が計算したＧＡＴＨＥＲ−ＬＯＡＤ命令の各グループ内の後続要素データのアクセスアドレスをロードキュー１３１に登録するのではなく、従来はストア命令で使用するストアキュー１３５に登録する。
【００３９】
ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部１２３で計算された全要素データのアドレスのうち、全グループの後続要素データのアドレスをストアデータバス経由で転送してストアキュー１３５に登録しておく。図４に示す例では、ＧＡＴＨＥＲ−ＬＯＡＤ命令全体は４つのグループに分割されて一次データキャッシュ要求が発行されているが、ストアキューはＧＡＴＨＥＲ−ＬＯＡＤ命令全体で１つのエントリを確保している。
【００４０】
ロードキュー１３１から複数のキャッシュラインアクセスを再投入する必要がある場合、ストアキュー読み出し回路１３６が、パイプライン実行されている一次データキャッシュ要求の情報（ストアキュー番号、後続要素データ情報)を基にストアキュー１３５から必要な後続アドレス情報を読み出してロードキュー１３１を上書き更新する。その後に、後続要素データの処理要求がロードキューから一次データキャッシュパイプライン１３２、１３３に再投入する。
【００４１】
図４に示した例を、図１に示した例と比較すると、ロードキュー１３１の回路の物量が削減される。なお、ストアキュー１３５や後続要素データのアドレスを転送するバス及びストアキュー書き込み回路は、通常のストア命令で必要となる機能であるので、本実施形態のために追加される構成ではない。また、ストアキュー読み出し回路１３６については、本実施形態のために追加される場合もあるが、演算処理装置によっては依存のある先行のストア処理と後続のロード処理との間でストアキュー１３５からデータを読み出して転送するストア−フォワーディング（Store-Fetch-Bypassとも言う）機能を実装している場合には、ストアキュー読み出し回路を共有すれば本実施形態における回路の物量は増加しない。
【００４２】
図５は、図４に示したロードキュー１３１のエントリの構成例を示す図である。図５において、図２に示した構成要素と同一の機能を有する構成要素には同一の符号を付し、重複する説明は省略する。処理要素アドレス５０１は、処理対象の要素データを読み出すためのアドレスである。処理要素アドレス５０１は、命令発行部１１０からの一次データキャッシュ要求時には先頭要素データのアドレスが登録され、同時に処理できない後続要素データがある場合、先頭要素データの処理が完了すると同時にストアキュー１３５から読み出した後続要素データのアドレスで上書き更新される。後続要素アドレス５０２は、先頭要素データと同時に処理できる場合に後続要素データとしてどの位置のデータを返すべきかを示す情報である。ストアキュー番号５０３は、後続要素データのアドレスをストアキュー１３５のどのエントリから読み出すかを示す情報である。
【００４３】
図６は、図４に示した演算処理装置におけるＧＡＴＨＥＲ−ＬＯＡＤ命令の処理例を示すフローチャートである。まず、ステップＳ６０１にて、グループ単位で命令発行部１１０から一次キャッシュ部１３０に要求発行される。ステップＳ６０２にて、一次キャッシュ部１３０は、対象のグループの全要素データの中に処理すべき要素データ（マスク情報が１である要素データ）が存在するか否かを判定する。処理すべき要素データがない（マスク情報が全て０である）場合、ステップＳ６０３へ進み、一次キャッシュ部１３０は、キャッシュパイプラインには処理投入を行わずにロードキュー１３１に処理完了状態で登録する。
【００４４】
一方、処理すべき要素データがある（マスク情報が１の要素データがある）場合、ステップＳ６０４へ進み、一次キャッシュ部１３０は、キャッシュパイプラインにキャッシュアクセス処理を投入する。キャッシュパイプライン処理では、ステップＳ６０５にて、一次キャッシュ部１３０は、処理すべき要素データ（マスク情報が１の要素データ）に、同時に処理できない要素データが含まれているか否かを判定する。判定の結果、同時に処理できない要素データがない場合（ステップＳ６０５のＮＯ）、ステップＳ６０６にて、一次キャッシュ部１３０は、同時にキャッシュアクセスしてデータ応答を返してロードキュー１３１に処理完了状態で登録する。
【００４５】
ステップＳ６０５での判定の結果、同時に処理できない要素データがある場合（ＹＥＳ）、ステップＳ６０７にて、一次キャッシュ部１３０は、同時にキャッシュアクセスして返せるデータ応答をすると同時に、同時に処理できなかった後続要素データのアドレスをストアキュー１３５から読み出してロードキュー１３１を上書き更新する。その後、ステップＳ６０４へ戻り、キャッシュパイプラインに再投入して、処理できなかった要素データのパイプライン処理を継続し、ステップＳ６０５で全要素データがデータ応答完了と判定するまで繰り返す。
【００４６】
本実施形態によれば、複数の要素データをグループ単位に分割して要求の発行及びパイプライン処理することで、同じグループの複数の要素データが１回のキャッシュアクセスにより処理できる場合にはスループット性能が向上する。Ｎ個の要素データのＧＡＴＨＥＲ−ＬＯＡＤ命令に対してＭ個の要素データ単位でグループ分割をすれば（Ｎ÷Ｍ）個のグループに分割でき、一次データキャッシュ要求の発行も（Ｎ÷Ｍ）回で行う。例えば、同じグループの複数の要素データがすべて同時にキャッシュアクセス可能であれば、キャッシュパイプラインを使うのも（Ｎ÷Ｍ）回で済むため、１要素データずつＮ回のパイプラインを使うのに比べてＭ倍に性能向上する。
【００４７】
また、（Ｎ÷Ｍ）個のグループのうち、マスク情報の指示で処理すべき要素データがないグループはキャッシュパイプライン投入しないため、例えば１個のグループのみが処理すべき要素データを持つ場合にはパイプラインを使うのは１回ですむため、さらにキャッシュパイプラインの効率が向上する。
【００４８】
このように本実施形態では、例えば粗密性のある疎行列演算を行うような大規模科学計算・数値シミュレーションや、データベースのような間接参照を伴うアプリケーションのように、メモリ上で非連続な領域に記憶されているデータに対してＧＡＴＨＥＲ−ＬＯＡＤ命令を高スループット、低レイテンシで実行することができ、演算処理装置の性能向上を図ることができる。
【００４９】
また、本実施形態では、任意の要素データ間でアドレス比較して同時処理するのではなく、単純なグループ分割の仕方に絞って同時処理を行うため、アドレス比較回路等のハードウェア物量の増加を抑えた実装が可能である。さらに、後続要素データのアドレスを保持するのにストアキューを活用したり、異なる要素データサイズや要素データ数のＧＡＴＨＥＲ−ＬＯＡＤ命令が混在した場合のハードウェア資源の競合や物量増加を抑えている。
【００５０】
以下、図４に示した演算処理装置を例に、本実施形態におけるＧＡＴＨＥＲ−ＬＯＡＤ命令の処理例を説明する。図７は、ＧＡＴＨＥＲ−ＬＯＡＤ命令を２要素データ単位でグループ化した場合の命令発行及びキャッシュアクセスを示すタイムチャートの例を示している。命令発行部１１０は、命令フェッチ（ＩＦ１、ＩＦ２）、命令デコード（ＩＤ１、ＩＤ２）、資源割当（ＤＳ１、ＤＳ２）をパイプライン処理する。命令発行されるとオペランドレジスタ読み出し（ＯＰ１）した情報を使って命令実行部１２０で全要素データのアドレス計算（ＡＧ１、ＡＧ２）を行う。アドレス計算にタイミングを合せて、分割グループ単位で命令発行部１１０から一次キャッシュ部１３０に一次データキャッシュ要求が発行され（ＤＲ０）、各々の一次データキャッシュ要求はキャッシュパイプラインに投入されてキャッシュアクセス（ＤＣ１、ＤＣ２）を行う。本実施形態では、一次データキャッシュパイプラインが２つ存在して並列に処理している。
【００５１】
８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令の場合、まず、要素データ００と要素データ０１への要求がパイプライン＜０＞に、要素データ０２と要素データ０３への要求がパイプライン＜１＞に同時に発行される。同様に、次サイクルには、要素データ０４と要素データ０５への要求がパイプライン＜０＞に、要素データ０６と要素データ０７への要求がパイプライン＜１＞に同時に発行される。８要素データ分の処理に対して４回の一次データキャッシュ処理要求が発行され、全グループの２要素データが同時にキャッシュアクセスできれば４回のパイプライン実行でＧＡＴＨＥＲ−ＬＯＡＤ命令が完了する。
【００５２】
４バイト×１６ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令の場合も同様に、１６要素データ分の処理に対して、８回の一次データキャッシュ処理要求及びパイプライン実行でＧＡＴＨＥＲ−ＬＯＡＤ命令が完了する。したがって、図８に示すように１要素データずつ処理する場合と比べて、パイプラインの使用回数は１／２になり、スループット性能は二倍出ることになる。図８は、１要素データずつ処理してＧＡＴＨＥＲ−ＬＯＡＤ命令を実行した場合の命令発行及びキャッシュアクセスのタイムチャートの例を示している。図８では、８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令では８回の一次データキャッシュ処理要求及びパイプライン実行が行われ、４バイト×１６ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令では１６回の一次データキャッシュ処理要求及びパイプライン実行が行われている。
【００５３】
図９は、ＧＡＴＨＥＲ−ＬＯＡＤ命令を隣接する２要素データでグループ化した場合の、グループ０（先頭の２要素データ）以外が処理する必要がない（マスク情報が０である）場合のタイムチャートの例を示している。一次データキャッシュ処理要求の発行（ＤＲ０）は、図７に示した例と同じであるが、グループ０（要素データ００及び要素データ０１）のみがパイプライン投入され、残りのグループについてはパイプライン実行せずに処理完了状態でロードキューに登録している。この場合には、パイプラインの負荷が下がるため、他の命令の処理やキャッシュミス操作などを行うことが可能となる。
【００５４】
図１０は、ＧＡＴＨＥＲ−ＬＯＡＤ命令を隣接する２要素データでグループ化した場合に全グループの２要素データが別のキャッシュラインであった場合のタイムチャートの例を示している。全要素データのアドレス計算（ＡＧ１／ＡＧ２）を行ったら、後続要素データのアドレスをストアキューに転送（ＳＥＴ）し、その次のサイクルからストアキュー上に後続要素データのアドレスが有効な状態で保持される。一次データキャッシュ要求（ＤＲ０）は、図７に示した例と同様に発行されるが、一回目のパイプライン実行（ＤＣ１、ＤＣ２）で２要素データを同時にキャッシュアクセスできなかったため、再度、後続要素データの処理のためにパイプライン投入・実行（二回目のＤＣ１、ＤＣ２）がされており、１回の一次データキャッシュ処理要求当たり、二度のパイプライン実行で処理を完了している。
【００５５】
図１１に、図４に示した例でのストアキュー１３５のエントリ登録情報の例を示している。通常のストア命令である場合にはエントリ０（ＥＮＴ０）のようにストア命令のデータを保持している。８バイト×８ＳＩＭＤに対応しているプロセッサでは、８バイト×８ＳＩＭＤ＝６４バイト分のデータレジスタを各エントリが備える。図１１に示す例では、８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令の実行時には、エントリ１（ＥＮＴ１）に示すように全要素データのアドレスをストアキュー１３５の１エントリに保持する。
【００５６】
４バイト×１６ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令の実行時には、エントリ２（ＥＮＴ２）に示すように後続要素データのアドレスとしてすべての奇数要素データのアドレスを保持する。各グループの先頭要素データ（偶数要素データ）のアドレスは、命令発行部１１０からの一次データキャッシュ処理要求の発行時にロードキュー１３１に登録されているため、ストアキュー１３５に保持するのは後続要素データのアドレスのみで動作は可能である。先頭要素データ（偶数要素データ）を処理する際に、先頭要素データ（偶数要素データ）と後続要素データ（奇数要素データ）が同時にアクセスできない場合、ストアキュー１３５から後続要素データのアドレスを選択読み出しする。
【００５７】
図１０に示したタイムチャートのようにパイプラインが使われる場合には、パイプライン＜０＞で実行中の一次データキャッシュ要求が読み出す後続要素データのアドレスは右下がり斜線、パイプライン＜１＞で実行中の一次データキャッシュ要求が読み出す後続要素データのアドレスは左下がり斜線で示している。８バイト×８ＳＩＭＤの場合と４バイト×１６ＳＩＭＤの場合とで、同じストアキュー１３５のデータを読むパイプラインが異なり読み出し競合する場合があるため、図１１にはパイプライン＜０＞及びパイプライン＜１＞の両パイプラインから、任意のデータを読み出せる構成の例を示している。
【００５８】
まず、エントリ選択回路１１０１が、パイプライン＜０＞で実行中の要求のストアキュー番号情報ＳＴＱ＿ＩＤ０に応じてセレクタＳＥＬＡ１０で選択を行い、パイプライン＜１＞で実行中の要求のストアキュー番号情報ＳＴＱ＿ＩＤ１に応じてセレクタＳＥＬＡ１１で選択を行うことでパイプライン毎に二系統選択する。その後に、要素間選択回路１１０２で、パイプライン＜０＞で実行中の要求の後続要素データの情報ＮＵＭ０に応じてセレクタＳＥＬＢ１０で選択を行い、パイプライン＜１＞で実行中の要求の後続要素データの情報ＮＵＭ１に応じてセレクタＳＥＬＢ１１で選択を行うことで８個の要素データのアドレスから１つの後続要素データのアドレスＳＡＤＲ０、ＳＡＤＲ１をそれぞれ選択している。
【００５９】
図１２及び図１３は、図１０及び図１１に示した構成で発生するストアキュー１３５の読み出し競合を回避するためのエントリ登録情報及びタイムチャートの例を示している。２つのパイプライン間で同一要素データの読み出し競合がなくなるように、４バイト×１６ＳＩＭＤでのパイプライン割り当てを変更している。具体的には、図１１に示した例と比べて、図１２ではエントリ２（ＥＮＴ２）のデータのパイプライン割り当てが変更になっており、パイプライン＜０＞が読み出す４要素データと、パイプライン＜１＞が読み出す４要素データを分けることができている。
【００６０】
そのため、エントリ選択回路１２０１もセレクタＳＥＬＡ２０による一系統ですみ、要素選択回路１２０２もセレクタＳＥＬＢ２０、ＳＥＬＢ２１により４個の要素データのアドレスから１つの後続要素データのアドレスを選択すれば良いため、ストアキュー１３５の読み出しポート数や選択回路を減らすことができる。図１０と対応したタイムチャートの例が図１３である。４バイト×１６ＳＩＭＤの発行パイプラインが一部入れ替わっている点が異なっている。具体的には、４バイト×１６ＳＩＭＤのグループ０及びグループ１が割り当てられるパイプラインが変更になっている。同様にグループ４及びグループ５が割り当てられるパイプラインも変更になっている。
【００６１】
図１４及び図１５は、２要素データ単位でグループ分割した場合のＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部１２３、アドレス保持ラッチ１２４、及びアドレス比較回路１２５の回路例を示している。図１４においては８バイト×８ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令を実行する場合に必要となる回路例を、図１５においては４バイト×１６ＳＩＭＤのＧＡＴＨＥＲ−ＬＯＡＤ命令を実行する場合に必要となる回路例を示している。
【００６２】
図１４に示す８バイト×８ＳＩＭＤの例では、スカラレジスタ１２１からのベースアドレスと、ベクトルレジスタ１２２からの各要素データのオフセットアドレスとを入力に、アドレス生成部１２３の加算器で８要素データ分の加算を行ってアドレスを生成する。そして、アドレス保持ラッチ１２４に結果を保持した後、アドレス比較回路１２５の比較器で同じグループ割り当てされている隣接する２要素データの間でアドレス比較を行い、同時にキャッシュアクセスできるかどうかを判定する。
【００６３】
したがって、要素データ数分のアドレス生成用加算器とアドレス保持ラッチ、要素データ数÷２個分のアドレス比較用比較器が必要となる。８ＳＩＭＤに対応している演算処理装置では、８ＳＩＭＤ分の命令実行部に加算器を実装しており、アドレス計算に通常の加算器を共用して使うことでハードウェアコストを抑える実装も考えられる。また、図１５に示す例では、４バイト×１６ＳＩＭＤに対応するために、アドレス生成用加算器、アドレス保持ラッチ、アドレス比較用比較器が、図１４に示した例と比較して二倍必要になっているのと、各回路とラッチの間のデータバスが二倍必要になっている。
【００６４】
図１６は、要素データのサイズが小さく要素データの数が多いＧＡＴＨＥＲ−ＬＯＡＤ命令である場合に、複数サイクルでアドレス計算することでハードウェアコストを抑える構成例を示している。また、図１４及び図１５においては、それぞれの要素データのサイズのみに対応するための回路例を示したが、図１６では８バイトの要素データと４バイトの要素データとを両方実現する回路例を示している。
【００６５】
図１６に示す例では、８バイト×８ＳＩＭＤである場合に１サイクル、４バイト×１６ＳＩＭＤである場合に２サイクルで処理する。４バイト×１６ＳＩＭＤである場合、１サイクル目は先頭要素データ、２サイクル目は後続要素データのアドレスを計算するために、アドレス生成回路１２３では加算器より前に、要素データのサイズに応じてベクトルレジスタ１２２のオフセットアドレスを各々択一的に選択する選択回路が追加になっている。この例では、ベクトルレジスタ１２２は各要素データ対応して、２つのオフセットアドレスをそれぞれ保持し、要素データのサイズに応じていずれかのオフセットアドレスをそれぞれ選択する。図１５に示した例と比べて、オフセットアドレスを選択した後のデータバス及び加算器は半分になり、図１４に示した例と同等のハードウェアコストになっている。
【００６６】
図１６に示す例では、アドレス保持ラッチ１２４は１６要素データ分が必要になるが、８バイト×８ＳＩＭＤであるのか４バイト×１６ＳＩＭＤであるのかに応じて、アドレス比較回路１２５に入力するアドレス選択をすることで、８バイト×８ＳＩＭＤと４バイト×１６ＳＩＭＤの両方に対応できる形でアドレス比較回路１２５の比較器を８個持つ形になっている。このようにすることで、アドレス生成及びアドレス比較に係るハードウェアコストを抑えることができる。
【００６７】
なお、前記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００６８】
１１０  命令発行部
１２０  命令実行部
１２１  スカラレジスタ
１２２  ベクトルレジスタ
１２３  ＧＡＴＨＥＲ−ＬＯＡＤアドレス生成部
１２４  アドレス保持ラッチ
１２５  アドレス比較回路
１２６  マスクレジスタ
１３０  一次キャッシュ部
１３１  ロードキュー
１３２、１３３  一次データキャッシュパイプライン
１３４  一次データキャッシュメモリ
１３５  ストアキュー
１３６  ストアキュー読み出し回路
【図１】
0006493088.tif 000002
【図２】
0006493088.tif 000003
【図３】
0006493088.tif 000004
【図４】
0006493088.tif 000005
【図５】
0006493088.tif 000006
【図６】
0006493088.tif 000007
【図７】
0006493088.tif 000008
【図８】
0006493088.tif 000009
【図９】
0006493088.tif 000010
【図１０】
0006493088.tif 000011
【図１１】
0006493088.tif 000012
【図１２】
0006493088.tif 000013
【図１３】
0006493088.tif 000014
【図１４】
0006493088.tif 000015
【図１５】
0006493088.tif 000016
【図１６】
0006493088.tif 000017
【図１７】
0006493088.tif 000018