(57)【特許請求の範囲】
【請求項１】
ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解するベクトル要素分解手段と、
前記ベクトル要素分解手段から該ベクトル命令または該ベクトル命令のアドレスに関する情報（以下、アドレス情報と言う。）を受け取り、該ベクトル命令に先行して受け取った少なくともひとつ以上の先行ベクトル命令と該ベクトル命令との依存関係を示す命令依存情報を作成する依存解析手段と、
前記ベクトル要素分解手段から該要素、および、前記依存解析手段から該命令依存情報を受け取り、該命令依存情報を基に該要素を調停に参加させる前に待ち処理が必要かどうかを決定し、待ち処理が必要と決定した場合は所定の待ち処理を行った後に、または、必要が無いと決定した場合は前記待ち処理を行わずに、該要素を調停に参加させる調停参加調整手段とを備え、
さらに、前記依存解析手段は、受け取った該アドレス情報を保存する保存手段を備え、
前記保存手段に保存する該アドレス情報は、少なくとも、該ベクトル命令のアドレス指定の方向と最後の要素のアドレスとを含むことを特徴とするデータアクセス装置。
【請求項２】
前記依存解析手段は、該ベクトル命令の要素のアドレスと、前記先行ベクトル命令の要素のアドレスとの重なりを基に該命令依存情報を作成することを特徴とする請求項１に記載のデータアクセス装置。
【請求項３】
前記保存手段に保存する該アドレス情報は、少なくとも、該ベクトル命令の最初の要素のアドレスと最後の要素のアドレスとを含むことを特徴とする請求項２に記載のデータアクセス装置。
【請求項４】
前記調停参加調整手段における前記所定の待ち処理は、全ての先行ベクトル命令の調停処理が終了するまで待つことを特徴とする請求項１ないし請求項３のいずれかに記載のデータアクセス装置。
【請求項５】
前記調停参加調整手段から調停に参加する該要素を受け取り調停処理まで保存する要素保持手段と、
該要素の調停処理を行う調停処理手段と、
前記調停処理手段により調停された該要素を受け取り、所定の送信先に送り出す送信手段とを備えることを特徴とする請求項１ないし請求項４のいずれかに記載のデータアクセス装置。
【請求項６】
ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解するステップと、
該ベクトル命令に先行する少なくともひとつ以上の先行ベクトル命令または該先行ベクトル命令のアドレスに関する情報と、該ベクトル命令または該ベクトル命令のアドレスに関する情報（以下、アドレス情報と言う。）とを基にベクトル命令の依存関係を示す命令依存情報を作成するステップと、
該命令依存情報を基に該要素の調停処理において待ち処理が必要かどうかを決定するステップと、
待ち処理が必要と決定した場合には所定の待ち処理を行った後、または、必要ないと決定した場合には前記所定の待ち処理を行わずに、該要素を調停処理に発行するステップと、
該アドレス情報を保存するステップとを含み、
保存する該アドレス情報は、少なくとも、該ベクトル命令のアドレス指定の方向と最後の要素のアドレスと
を含むことを特徴とするデータアクセス制御方法。
【請求項７】
該ベクトル命令の要素のアドレスと、前記先行ベクトル命令の要素のアドレスとの重なりを基に該命令依存情報を作成すること特徴とする請求項６に記載のデータアクセス制御方法。
【請求項８】
保存する該アドレス情報は、少なくとも、該ベクトル命令の最初の要素のアドレスと最後の要素のアドレスとを含むことを特徴とする請求項７に記載のデータアクセス制御方法。
【請求項９】
前記所定の待ち処理は、全ての先行ベクトル命令の調停処理が終了するまで待つことを特徴とする請求項６ないし請求項８のいずれかに記載のデータアクセス制御方法。
【請求項１０】
調停処理のために発行された該要素を受け取り、調停処理まで保存するステップと、
該要素の調停処理を行うステップと、
調停された該要素を受け取り取り、所定の送信先に送り出すステップとを含むことを特徴とする請求項６ないし請求項９のいずれかに記載のデータアクセス制御方法。
【請求項１１】
ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解する処理と、
該ベクトル命令に先行する少なくともひとつ以上の先行ベクトル命令または該先行ベクトル命令のアドレスに関する情報と、該ベクトル命令または該ベクトル命令のアドレスに関する情報（以下、アドレス情報と言う。）とを基にベクトル命令の依存関係を示す命令依存情報を作成する処理と、
該命令依存情報を基に該要素の調停処理において待ち処理が必要かどうかを決定する処理と、
待ち処理が必要と決定した場合には所定の待ち処理を行った後、または、必要ないと決定した場合には前記所定の待ち処理を行わずに、該要素を調停処理に発行する処理と、
該アドレス情報を保存する処理とをコンピュータに実行させ、
保存する該アドレス情報は、少なくとも、該ベクトル命令のアドレス指定の方向と最後の要素のアドレスとを含むことを特徴とするデータアクセス装置のデータアクセス制御プログラム。
【請求項１２】
該ベクトル命令の要素のアドレスと、前記先行ベクトル命令の要素のアドレスとの重なりを基に該命令依存情報を作成すること特徴とする請求項１１に記載のデータアクセス制御プログラム。
【請求項１３】
保存する該アドレス情報は、少なくとも、該ベクトル命令の最初の要素のアドレスと最後の要素のアドレスとを含むことを特徴とする請求項１２に記載のデータアクセス制御プログラム。
【請求項１４】
前記所定の待ち処理は、全ての先行ベクトル命令の調停処理が終了するまで待つことを特徴とする請求項１１ないし請求項１３のいずれかに記載のデータアクセス制御プログラム。
【請求項１５】
調停処理のために発行された該要素を受け取り、調停処理まで保存する処理と、
該要素の調停処理を行う処理と、
調停された該要素を受け取り取り、所定の送信先に送り出す処理とを含むことを特徴とする請求項１１ないし請求項１４のいずれかに記載のデータアクセス制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムに使用されるデータアクセス装置に関し、特に、ベクトル命令を処理するデータアクセス装置に関する。
【背景技術】
【０００２】
コンピュータシステムにおいて、データを加工処理等を行う中央処理装置に接続し、データの保存や取出し等を行うデータアクセス装置は、中央処理装置に比べ、データの処理性能が遅い場合が多い。そのため、データアクセス装置の性能が、コンピュータシステム全体の処理性能を制限する要因のひとつとなっている。特にデータアクセス装置の処理回数が多いベクトル命令の処理においては、データアクセス装置の性能の向上が重要となっている。
【０００３】
この対策のため、データアクセス装置は、キャッシュを備えることが多い。
【０００４】
さらに、データアクセス装置の装置内部での処理の改善が図られている。
【０００５】
例えば、ベクトル命令の各要素の振り分け（調停処理）を行うクロスバスイッチでの改善として、各要素のクロスバスイッチへの調停参加タイミングをリクエストにより変更するものがある。（例えば、特許文献１参照）
また、ストア命令とロード命令との追越制御の処理を改善することにより、性能向上を図ったものも有る。（例えば、特許文献２及び特許文献３参照）
さらに、ひとつのリクエストを複数個のリクエストに分割し、分割したリクエスト毎に待ち処理を行うことにより、リクエスト全体をひとつにまとめたときの待ち処理に比べ、待ち時間を短くすることなどが行われていた。（例えば、特許文献４参照）
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１０２６０７号公報
【特許文献２】特開２００５−２３５１３５号公報
【特許文献３】特開平０９−２３１２０３号公報
【特許文献４】特開昭６３−２８４６７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、特許文献１に記載の発明は、リクエストの処理により、個別の待ち処理を改善することはできるが、複数の命令間の関係については考慮していないため、命令間で発生する待ち処理を改善することができない。
【０００８】
特許文献２乃至特許文献３に記載の発明は、ストア命令とロード命令との関係に対応した発明のため、例えば、ベクトルストア命令が連続した場合など、同一命令が連続した場合の待ち処理を改善することができない。
【０００９】
従って、特許文献１乃至特許文献３に記載の発明では、図１７に示すように、同じ種類の命令が連続する場合、命令の順序を保証するため、先行するベクトル命令の全ての要素の処理が終了するまで、後続するベクトル命令の調停処理への参加を待たすことが必要であった。（以下、この調停への参加を待たす処理（待ち処理）をホールドオールと言うこともある。）
また、特許文献４に記載の発明では、分割後の各要素のリクエスト毎の待ち処理は発生するため、待ち処理を完全に無くすことができなかった。
【００１０】
科学技術計算で多数発生する、連続アクセス処理（例えば、連続したアドレスに対するロード/ストア命令などの処理）は、もっとも基本的なアクセス処理であり、バンド幅を最大限に使用したい処理である。しかし特許文献４に記載の発明では、命令の切れ目のたびに待ち処理が入るため、無駄な隙間があいてしまい、バンド幅を使い切れなかった。
【００１１】
本発明の目的は、上述の問題点を解決し、ベクトル命令が連続した場合における命令間の待ち処理を改善した、データアクセス装置、データアクセス制御方式、及び、データアクセス制御プログラムを提供することにある。
【課題を解決するための手段】
【００１２】
本発明のデータアクセス装置は、ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解するベクトル要素分解手段と、前記ベクトル要素分解手段から該ベクトル命令または該ベクトル命令のアドレスに関する情報を受け取り、該ベクトル命令に先行して受け取った少なくともひとつ以上の先行ベクトル命令と該ベクトル命令との依存関係を示す命令依存情報を作成する依存解析手段と、前記ベクトル要素分解手段から該要素、および、前記依存解析手段から該命令依存情報を受け取り、該命令依存情報を基に該要素を調停に参加させる前に待ち処理が必要かどうかを決定し、待ち処理が必要と決定した場合は所定の待ち処理を行った後に、または、必要が無いと決定した場合は前記待ち処理を行わずに、該要素を調停に参加させる調停参加調整手段とを備えることを特徴とする。
【００１３】
本発明のデータアクセス制御方法は、ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解するステップと、該ベクトル命令に先行する少なくともひとつ以上の先行ベクトル命令または該先行ベクトル命令のアドレスに関する情報と、該ベクトル命令または該ベクトル命令のアドレスに関する情報とを基にベクトル命令の依存関係を示す命令依存情報を作成するステップと、該命令依存情報を基に該要素の調停処理において待ち処理が必要かどうかを決定するステップと、待ち処理が必要と決定した場合には所定の待ち処理を行った後、または、必要ないと決定した場合には前記所定の待ち処理を行わずに、該要素を調停処理に発行するステップとを含むことを特徴とする。
【００１４】
本発明のコンピュータに実行させるデータアクセス装置のデータアクセス制御プログラムは、ベクトル命令を受け取り、該ベクトル命令を個別の要素に分解する処理と、該ベクトル命令に先行する少なくともひとつ以上の先行ベクトル命令または該先行ベクトル命令のアドレスに関する情報と、該ベクトル命令または該ベクトル命令のアドレスに関する情報とを基にベクトル命令の依存関係を示す命令依存情報を作成する処理と、該命令依存情報を基に該要素の調停処理において待ち処理が必要かどうかを決定する処理と、待ち処理が必要と決定した場合には所定の待ち処理を行った後、または、必要ないと決定した場合には前記所定の待ち処理を行わずに、該要素を調停処理に発行する処理とをコンピュータに実行させることとを実行することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、ベクトル命令が連続した場合に、命令間の必要の無い待ち処理を削減したベクトル命令の処理を行う効果が得られる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態のデータアクセス装置の構成を示すブロック図である。
【図２】本発明の第１の実施形態における、ベクトルストア命令の一例を示す図である。
【図３】本発明の第１の実施形態における、ベクトルストア命令を個別に要素に分解した一例を示す図である。
【図４】本発明の第１の実施形態における、要素が調停に送り出される一例を示す図である。
【図５】本発明の第１の実施形態における、複数の命令の要素が調停に送り出される一例を示す図である。
【図６】本発明の第２の実施形態のデータアクセス装置の構成を示すブロック図である。
【図７】本発明の第２の実施形態のアドレス情報を保存するバッファの一例を示す図である。
【図８】本発明の第２の実施形態の動作を示すフローチャートである。
【図９】本発明の第２の実施形態のデータアクセス装置の構成を示すブロック図である。
【図１０】本発明の第３の実施形態のアドレス情報を保存するバッファの一例を示す図である。
【図１１】本発明の第３の実施形態の動作を示すフローチャートである。
【図１２】本発明の第３の実施形態で待ち処理が発生しない連続命令の第１の例を示す図である。
【図１３】本発明の第３の実施形態で待ち処理が発生しない連続命令の第２の例を示す図である。
【図１４】本発明の第３の実施形態で待ち処理が発生する連続命令の第１の例を示す図である。
【図１５】本発明の第３の実施形態で待ち処理が発生する連続命令の第２の例を示す図である。
【図１６】本発明の第３の実施形態で待ち処理が発生する連続命令の第３の例を示す図である。
【図１７】調停における待ち処理を伴って送り出される要素の一例を示す図である。
【発明を実施するための形態】
【００１７】
次に、本発明の実施形態について図面を参照して説明する。
【００１８】
なお、以下の実施形態の説明では、ベクトル命令の代表としてベクトルストア命令についての説明をするが、勿論、他のベクトル命令、例えばベクトルロード命令などに関しても同様に本発明は適用可能である。
（第１の実施形態）
最初に、本発明の第１の実施形態の構成および動作について図１−図５を参照して詳細に説明する。
【００１９】
図１は、第１の実施形態の係るデータアクセス装置１の構成を示すブロック図である。
【００２０】
図１に示されているデータアクセス装置１は、ベクトル要素分解部２１、依存解析部２２、及び調停参加調整部３１を備え、図示しない中央処理装置などからベクトルストア命令を受け取り、要素に分解し、実際に調停処理を行う調停部４に送り出している。
【００２１】
さらに、詳細な説明を行う。
【００２２】
ベクトル要素分解部２１は、ベクトルストア命令を受け取り、個別の要素に分解し、各要素を調停参加調整部３１に発行する。ベクトル要素分解部２１から発行される各要素は、ベクトルストア命令で指定された順に発行されるが、第１の実施形態では、データ処理のスループットを向上させるため、８本のポートに分けて発行されている。なお、第１の実施形態では、説明の便宜上、ポートの数を８本としているが、この数に限定されず、７本以下でも、９本以上でもよい。
【００２３】
また、ベクトル要素分解部２１は、ベクトルストア命令の要素のアドレスに関係する情報（以下、アドレス情報と言う場合も有る。）を依存解析部２２に送っている。
【００２４】
依存解析部２２は、ベクトル要素分解部２１から受け取ったアドレス情報を基に、命令間の依存関係を解析し、依存関係を示す命令依存情報を出力する。なお、依存解析部２２は、命令間の依存関係を解析するため、必要に応じて、過去に受け取ったベクトル命令のアドレス情報などを図示しないメモリなど記憶装置に保存してもよい。
【００２５】
調停参加調整部３１は、ベクトル要素分解部２１から分解後の要素を受け取り、調停参加許可となるまで保存する。また、依存解析部２２から、命令依存情報も受け取る。そして、調停参加調整部３１は、実際に調停を行う調停部４に空きが発生すると調停に参加させる要素を送り出す。ただし、後ほど動作について詳細に説明をするが、調停参加調整部３１は、命令依存情報を基に、必要な場合はホールドオールなど待ち処理を行った後、必要が無い場合は待ち処理を行わずに、各要素の送り出し処理を行う。
【００２６】
続いて、第１の実施形態の動作について説明する。
【００２７】
図２は、ベクトルストア命令の一例を示している。
【００２８】
図２では、一例として、１要素当り８バイトデータのストアをリクエストする６４個の要素からなるベクトルストア命令が、連続して３つ続く場合を示している。図２の各箱が個別の要素となっている。各要素のアドレスは、命令１の最初の要素（図２の左上の要素番号０）の番地を０として示している。各要素は、８バイトデータのストアをリクエストしているため、要素ひとつで番地が８つ増えることとなる。そのため、例えば要素８では番地６４（＝８×８）となる。なお、図２に示す３つのベクトルストア命令は、連続したアドレスを指定しており、相互のアドレスに重なりが無い、つまり依存関係が無い場合を示している。
【００２９】
このようなベクトルストア命令を受け取ったベクトル要素分解部２１は、ベクトルストア命令を各要素に分解し、調停参加調整部３１に発行する。第１の実施形態では、上述のとおり８ポートを使用しているため、図３に示すように各要素は、８個ずつ調停参加調整部３１に発行されることとなる。図３においても各箱が個別の要素を示している。最初のクロックサイクル（サイクル１）では、８個の要素、つまり命令１の要素番号０〜７の要素が発行され、次のクロックサイクル（サイクル２）では、命令１の要素番号８〜１５の要素が発行され、以下順に、命令１の要素番号１６以降の要素が発行される。命令１が終了すると、命令２の要素番号０〜７の要素が発行される（サイクル９）。このように要素の発行処理が継続され、命令３の要素番号５６〜６３の要素まで順番に発行される。
【００３０】
さらに、ベクトル要素分解部２１は、受け取ったベクトルストア命令で指定されている次に示す３つの情報から、各々の要素のアドレスを計算する。
【００３１】
（ａ）ベースアドレス（命令の開始アドレス、つまり、要素番号０のアドレスで、図２の命令１では”０”、命令２なら”５１２”となっている）
（ｂ）ディスタンス値（各要素間の距離、図２では”８”となっている）
（ｃ）ベクトル長（各命令の要素の数、図２では”６４”となっている）
各要素のアドレスは、例えば、次の式により求めることが出来る。
【００３２】
要素のアドレス＝ベースアドレス＋ディスタンス値×要素番号
（なお、ベクトル長は、直接上記計算式に出てこないが、アドレス計算の終了判定に使用する。）
第１の実施形態では、依存解析部２２の解析動作で使用するため、この要素のアドレスのうち、最初の要素のアドレスと最後の要素のアドレスが、ベクトル要素分解部２１から依存解析部２２に送られる。
【００３３】
依存解析部２２は、ベクトル要素分解部２１からの最初の要素のアドレスと最後の要素のアドレスとを受け取る。依存解析部２２は、受け取ったベクトルストア命令のアドレス情報を過去に受け取ったベクトルストア命令のアドレス情報と比較し、依存関係、例えば、過去に受け取ったベクトルストア命令のアドレスと重なるかどうかを調べる。そして、もしアドレスに一部でも重なりがあった場合は、依存関係があると決定する。そして、その結果から命令依存情報を作成し、調停参加調整部３１に発行する。
【００３４】
調停参加調整部３１は、ベクトル要素分解部２１からの要素と依存解析部２２からの命令依存情報とを受け取る。そして、調停参加調整部３１は、調停部４に空きが発生すると、各要素を調停に参加させるため、順番に各要素を実際に調停作業を行う調停部４に送り出す。
【００３５】
なお、調停参加調整部３１は、既に述べたとおり、ベクトル要素分解部２１から１サイクル当り８要素ずつ受け取っている。そのため、第１の実施形態の調停参加調整部３１は、各要素を調停部４に送り出すときに、１ポート当り８要素ずつとしている。
【００３６】
なお、第１の実施形態における調停部４は、説明の便宜上、次のような調停部４として説明するが、これに限定されるわけではない。
【００３７】
まず、調停先には、キャッシュまたはメモリが接続され、ある単位でインタリーブされた構成とする。
【００３８】
そして、第１の実施形態では、キャッシュが１ライン＝６４バイトとし、６４バイトずつインタリーブされた構成とする。
【００３９】
その結果、
最初の８要素は
要素番号０：アドレス０
要素番号１：アドレス８
要素番号２：アドレス１６
要素番号３：アドレス２４
要素番号４：アドレス３２
要素番号５：アドレス４０
要素番号６：アドレス４８
要素番号７：アドレス５６
となり、いずれの要素もポート０へ向おうとするため競合が発生する。その結果として、図５に示すように１ポートずつ開始サイクルがずれることになる。
【００４０】
一方、第１の実施形態では、ポートが空いていることの確認を、８ポート全て１サイクルで行っている。例えば、ベースアドレス０、ディスタンス６４バイトというベクトル命令であれば、
最初の８要素は
要素番号０：アドレス０        →  ポート０へ
要素番号１：アドレス６４      →  ポート１へ
要素番号２：アドレス１２８    →  ポート２へ
要素番号３：アドレス１９２    →  ポート３へ
要素番号４：アドレス２５６    →  ポート４へ
要素番号５：アドレス３２０    →  ポート５へ
要素番号６：アドレス３８４    →  ポート６へ
要素番号７：アドレス４４８    →  ポート７へ
となり、それぞれ行先が異なるため、１サイクルで８要素同時に調停部４に送り出すことが可能である。
【００４１】
続いて、複数の命令の処理について説明する。
【００４２】
要素の処理が別の命令に跨る場合、調停参加調整部３１は、命令依存情報を確認する。もし、命令依存情報に命令間の依存関係が無いと設定されている場合、調停参加調整部３１は、ホールドオールなどの待ち処理を行わず、図５に示すように、継続して、次の命令の要素も調停部４に送り出す。
【００４３】
ここで、図５と図１７とを比較すると、図１７で３０サイクル掛かっていた命令２の終了が、図５では２３サイクル、つまり７サイクル改善できていることが解る。
【００４４】
なお、図５では、２個の命令の例を示しているが、ベクトルストア命令が３個以上の場合も、同様に命令依存情報を確認し、依存関係が無い場合は、要素の送り出し処理を継続することにより、待ち処理を行わない要素の出力を得ることができる。
【００４５】
このようして送り出された各要素は、その後、調停部４で調停が行われ、各メモリバンクに送り出される。
【００４６】
一方、依存関係を検出すると、調停参加調整部３１は、図１７で示したように、ホールドオールなど待ち処理を行い、依存関係を崩さないために、（例えば、同一アドレスへのロード・ストア命令があった場合にこの順序が調停通過前後で崩れないように、）先行命令の全要素が、調停部４を通過するまで、後続命令の調停参加を保留する待ち処理（ホールドオール処理）を行う。
【００４７】
以上のように、本発明の第１の実施形態におけるデータアクセス装置１は、依存関係の無いベクトルストア命令が連続する場合に、必要ない待ち処理を行わず、その結果として、データアクセス装置の処理性能を向上する効果を得ることが出来る。
【００４８】
その理由は、依存解析部２２において、ベクトルストア命令の要素の依存関係を解析し、その結果を受け取った調停参加調整部３１が、待ち処理が必要ない場合に、待ち処理を実行せずにベクトルストア命令の各要素を調停に参加させることが出来るためである。
（第２の実施形態）
次に、本発明の第２の実施形態の構成および動作について、図６−図９を参照して詳細に説明する。
【００４９】
図６は、第２の実施形態の係るデータアクセス装置１の構成を示すブロック図である。
【００５０】
図６において、データアクセス装置１は、第１の実施形態のベクトル要素分解部２１と依存解析部２２を備えたデータ命令発行部２と、調停参加調整部３１と調停部４に相当する構成とを備えたデータアクセス調停部３とを含んで構成されている。
【００５１】
さらに、第２の実施形態の依存解析部２２は、ベクトル命令の依存関係を解析するために過去のベクトル命令のアドレス情報などを保存する解析バッファ２３を備え、調停参加調整部３１は、命令依存情報を受け取り保存するフラグ３５を備えている。
【００５２】
データアクセス調停部３の調停部４に相当する構成についても説明する。調停参加ステージ３２は、調停参加調整部３１から要素を受け取り、クロスバスイッチ３３での調停処理に参加するまで、各要素を保管し、調停参加調整部３１とクロスバスイッチ３３とのバッファの役目を果たす。クロスバスイッチ３３は、調停に参加した要素の調停処理、具体的には割り振り処理などを行う。転送ポート３４は、クロスバスイッチ３３から調停処理後の各要素を受け取り、所定のメモリバンクに送り出す。
【００５３】
続いて、第２の実施形態の動作について説明する。
【００５４】
ベクトル要素分解部２１の動作および調停参加調整部３１の送り出しの動作は、第１の実施形態と同じため、詳細な説明書を省略し、第２の実施形態に新たに加わった構成に関連する動作について説明する。
【００５５】
まず、解析バッファ２３を含めた依存解析部２２の動作について説明する。
【００５６】
図７に、第２の実施形態の解析バッファ２３の概要を示す。
【００５７】
ここで、第２の実施形態の解析バッファ２３のエントリの数が８個としているのは、同時に調停に参加した８要素が８サイクル後には全て調停を通過する（通過できる調停方式を採用する）ことを前提としているためである。つまり、あるひとつの要素が調停に参加しようとする瞬間に調停に参加している８要素が全て違う命令だった場合でも、それより前の命令は既に調停を通過していることになる。そのため、命令間のアドレスの依存解析は、先行する８命令に対して行えば十分であるため、第２の実施形態ではエントリを８個とした。
【００５８】
ただし、調停に参加するポートに優先順位付けがあるような場合は異なってくる。
【００５９】
例えば、ポート７が他ポートより優先順位が低いというような制限がある場合は、ポート７から調停に参加した要素が調停に負け続けずっと残ることが発生する可能性がある。このような場合は、先行する８命令分の依存の解析では足りないことになる。従って、この例のようにポートに優先順位がある場合は、エントリの数は８ではなく、適切な数に変更することが必要である。
【００６０】
また、例えば、メモリバンクへの送り出しが、何かの問題で滞るなど、クロスバスイッチ３３の調停に遅延などが発生することを考慮したり、他の構成の処理などを考慮して適切な値を採用してもよい。
【００６１】
解析バッファ２３は、エントリのデータが有効かどうかを示す「登録Ｖａｌｉｄビット（図７のＶ）」と、ベクトル要素分解部２１から受け取った「最初の要素のアドレス」と、「最後の要素のアドレス」とを保存する領域を備えている。
【００６２】
依存解析部２２は、ベクトル要素分解部２１から次に処理するベクトルストア命令の最初の要素のアドレスと最後の要素をアドレスを受け取ると、解析バッファ２３に保存してある有効、つまり登録Ｖａｌｉｄビットが設定されているエントリのデータと比較する。もし、今回受け取った命令のアドレスの範囲が、既にエントリに保存されているアドレスの範囲と重なる場合は、依存関係が有りと決定し、どのエントリのアドレス範囲とも重なりが無い場合は依存関係が無しと決定する。
【００６３】
図８に、依存解析部２２の動作のフローチャートを示す。
【００６４】
最初に、依存解析部２２は、ベクトル要素分解部２１から最初の要素のアドレスと最後の要素のアドレスとを受け取る（ステップ４１）。次に、解析バッファ２３の最初のエントリの登録Ｖａｌｉｄビットを確認する（ステップ４２）。登録Ｖａｌｉｄビットが有効なら、アドレスの依存関係の確認に移動し、無効なら残りのエントリの確認に移動する（ステップ４３）。エントリが有効ならアドレスの依存関係の確認を行う（ステップ４４）。第２の実施形態では、エントリに保存されている最初の要素のアドレスと最後の要素のアドレスとの間に、受け取ったベクトルストア命令のアドレスが一部でも入っている否かを確認している。受け取ったベクトルストア命令のアドレスが、一部でも入っている場合は依存関係が有りとし、まったく入っていない場合は依存関係が無しと決定している。依存関係が無し場合は、残りのエントリの確認に移動し、依存関係が有りの場合は、フラグの解除に移動する（ステップ４５）。なお、ここでのフラグは、図６のフラグ３５のことであり、命令依存情報を保存する。第２の実施形態では、フラグが設定されると、依存関係が無し、つまり待ち処理の必要が無いことを示し、フラグが解除されていると、依存関係が有り、つまり待ち処理が必要なことを示すとしている。これは、安全のため、初期状態、つまりフラグに何も設定されていない状態を依存関係有りとしたためであり、勿論、逆としてもよい。依存関係が無しの場合は、残りのエントリが有るかどうかの確認を行う（ステップ４６）。残りのエントリが無い場合は、依存関係のフラグを設定する処理に移動し、残りのエントリがある場合は、次のエントリの確認に移動する（ステップ４７）。全てのエントリを確認しても依存関係が無しの場合は、過去の命令と今回の命令とは依存関係が無いため、フラグを設定する（ステップ４８）。一方、エントリのデータのうち一つでも依存関係が見つかった場合は、依存関係が有りとして、依存フラグを解除する（ステップ４９）。最後に、新しく受け取ったアドレスをエントリに登録する（ステップ５０）。この際、登録Ｖａｌｉｄビットも設定しておく。
【００６５】
なお、第２の実施形態では、各要素を８バイトとしているため、要素の最初のデータのアドレスは、その要素の最後のデータのアドレスより７番地少くなっている。このため、要素のデータの数が異なるベクトルストア命令が有る場合などを考慮し、依存関係の決定の比較対象として、最後の要素のアドレスではなく、最後のデータのアドレスを使用するようにしてもよい。
【００６６】
また、ベクトルストア命令は、必ずしも小さいアドレスから大きなアドレスを指定する命令だけではなく、大きなアドレスから小さなアドレスを指定する命令もある。従って、第２の実施形態の依存解析部２２は、解析バッファ２３のエントリにアドレス情報を登録する場合に、命令の最初の要素のアドレスと最後の要素のアドレスとの大きさを確認する。そして、エントリに登録する最初の要素のアドレスとしては小さいアドレスを、最後の要素のアドレスとしては大きいアドレス登録するようにしている。
【００６７】
ただし、エントリの登録時には、アドレスの大小を判定した入れ替えを行わず、命令の最初のアドレスと最後のアドレスをそのまま登録し、依存関係の決定時にアドレスの大小を考慮して決定するようにしてもよい。
【００６８】
また、図８のフローチャートには、説明が煩雑となるため省略しているが、もし有効なエントリが一つもなかった場合は、受け取ったベクトルストア命令の前に、ベクトルストア命令が無い、つまり、別の命令が行われていたこととなる。従って、この場合は、第２の実施形態では、前の命令との依存関係の解析が行えず、必ず待ち処理を行う必要があり、フラグを解除することとしている。
【００６９】
さらに、受け取ったアドレス情報をエントリに登録しようとしたときに、全てのエントリーが登録されている場合は、最も必要性が低いエントリのデータを削除して、新しいアドレス情報を登録する。この処理には、一般的なＦＩＦＯでもよく、キャッシュなどの使用されているデータ吐き出し方法、例えばＬｅａｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ（ＬＲＵ）などを使用してもよく、詳細な説明は省略する。
【００７０】
なお、第２の実施形態では、依存解析部２２の解析バッファ２３のエントリに保存するデータをベクトル要素分解部２１から受け取った要素のアドレス情報としている。しかし、例えば、依存解析部２２がベクトル要素解析部２１からベクトルストア命令を受け取り、依存解析部２２で最初の要素のアドレスと最後の要素のアドレスとを求めて保存および決定を行うようにしてもよい。
【００７１】
続いて、データアクセス調停部３の動作について説明する。
【００７２】
まず、ベクトル要素分解部２１で分解された要素は、調停参加調整部３１に送られる。調停参加調整部３１では、第１の実施形態と同様に、調停参加ステージ３２に参加できる空きが見つかると、フラグ３５を使用して依存関係の確認を行い、命令の依存関係が有れば待ち処理を行った後、依存関係が無ければすぐに、要素を送り出す。
【００７３】
このようして、調停参加ステージ３２に送り出された各要素は、クロスバスイッチ３３に空きが見つかるまで調停参加ステージ３２に一時保管される。保管された要素は、クロスバスイッチ３３に空きが見つかると、クロスバスイッチ３３に送り出され、クロスバスイッチ３３により調停が行われた後、転送ポート３４に振り分けられる。転送ポート３４は、受け取った各要素を所定の各メモリバンクに送り出す。
【００７４】
以上のように、本発明の第２の実施形態におけるデータアクセス装置１は、依存関係のないベクトルストア命令が連続する場合に、待ち処理を実行せずにベクトルストア命令の処理を行うことができ、その結果、スループットを向上する効果を得ることが出来る。
【００７５】
その理由は、データ命令発行部２が、ベクトルストア命令のアドレス範囲に基づいて命令の依存関係を解析し、その結果を基にデータアクセ調停部３が、待ち処理が必要のない命令では待ち処理を行わずに要素を調停に参加させることが出来るためである。
【００７６】
なお、第２の実施形態として各処理を別構成として説明してきたが、図９（Ａ）に示すように、データ命令発行部２およびデータアクセス調停部３をそれぞれのコンピュータなどで構成し、各構成をコンピュータの内部処理としてもよい。
【００７７】
さらに、図９（Ｂ）に示すようにデータ命令発行部２およびデータアクセス調停部３もひとつのコンピュータ上のソフトウェアとしてもよい。
【００７８】
また、コンピュータのプログラムではなく、図９（Ａ）または図９（Ｂ）のように機能をまとめたＩＣチップとして実現してもよい。
【００７９】
また、解析用に保存するデータを、解析バッファ２３における最初の要素のアドレスと最後の要素のアドレスではなく、ベクトルストア命令としてもよい。通常、ベクトルストア命令は、多くの要素からなるため、解析バッファ２３のエントリより多くの記憶領域が必要となる。しかし、図９（Ａ）または図９（Ｂ）に示すように、ひとつのコンピュータまたは、ＩＣチップで実現したデータアクセス装置１では、受け取ったベクトルストア命令を保存している装置で、同時に依存関係の解析を行うこととなる。データアクセス装置１は、受け取った命令をすぐには消さず、ある程度の数は履歴として保存している。つまり、図９（Ａ）または図９（Ｂ）に示すデータアクセス装置１では、先行するベクトルストア命令を保存するために、新たな記憶領域を必要としない。
【００８０】
従って、図９（Ａ）または図９（Ｂ）に示されるデータアクセス装置１において、ベクトルストア命令から依存関係を求めるようにすることにより、記憶領域を削減する効果を得ることが出来る。
【００８１】
その理由は、既に保存している命令を使用することにより、エントリを使用しないで依存関係を決定できるため、エントリのための記憶領域が不要となり、削減することができるためである。
（第３の実施形態）
次に、発明の第３の実施形態に関して、図１０−図１６を使用して説明する。
【００８２】
第３の実施形態の構成は、第２の実施形態の解析バッファ２３が、図１０に示す第２の解析バッファ２４に変更になった以外は同じ構成のため、データアクセス装置１の構成の詳細な説明は省略し、第２の解析バッファ２４の構成と動作を中心に説明を行う。
【００８３】
図１０は、第２の実施形態の解析バッファ２４を示す図である。
【００８４】
図１０の解析バッファ２４は、図７の解析バッファ２３に比較し、エントリ内に保存するデータが、最初の要素のアドレスの替わりに、前の命令のアドレス指定の方向を示す方向ビットに変更されている。要素のアドレスは、通常複数ビットで構成されるため、方向ビットに変更することにより、必要なハードウェアを削減している。
【００８５】
第３の実施形態では、エントリを一つとすることにより、さらに、ハードウェア量を削減している。
【００８６】
図１１を使用して、第３の実施形態の動作について説明する。
【００８７】
まず、依存解析部２２は、ベクトル要素分解部２１から、ベクトルストア命令の最初の要素のアドレスと最後の要素をアドレスを受け取る（ステップ６１）。最初の要素のアドレスと最後の要素のアドレスとから命令の方向を求める（ステップ６２）。次に、エントリのデータが有効かどうかを決定する（ステップ６３）。もし、エントリのデータが無効なら、依存関係の決定が出来ないため、依存有りとして、フラグの解除に移動し、データが有効なら依存関係の解析に移動する（ステップ６４）。
【００８８】
第３の実施形態における依存関係の解析は、次の２条件により決定する（ステップ６５）。
【００８９】
条件１：受け取った命令の方向とエントリに保存されている方向とが一致するかどうかを決定する。つまり、アドレスが大きくなる命令の連続か、または、小さくなる命令の連続かを決定する。命令の方向が一致しない場合は、次の条件の解析は行わず、依存関係が有りと決定して解析を終了する。
【００９０】
条件２：条件１が成立した場合は、受け取ったベクトルストア命令の最初のアドレスとエントリに保存されいる最後の要素のアドレスとの大小を比較し、次の条件を満たすかどうかを決定する
大きくなる方向の命令：命令の最初のアドレス＞エントリの最後の要素のアドレス
小さくなる方向の命令：命令の最初のアドレス＜エントリの最後の要素のアドレス
上記条件が満たされる場合は、依存関係が無しと決定し、それ以外は依存関係が有りと決定する。
【００９１】
続いて、解析の結果に基づき、依存関係が有りの場合はフラグの解除に、依存関係が無しの場合はフラグの設定に移動する（ステップ６６）。フラグの設定（ステップ６７）およびフラグの解除（ステップ６８）は、図８で示した第２の実施形態と同じため、詳細な説明は省略する。フラグ操作が終了したら、ステップ６２で求めた方向ビットと最後の要素のアドレスとをエントリに保存し、エントリのＶａｌｉｄビットを有効に設定して終了する（ステップ６９）。
【００９２】
このような構成により、図１２及び図１３に示すような、アドレスが昇順又は降順で連続するベクトルストア命令のおいて、依存関係が無いことを決定できる。以下、詳細に説明を行う。なお、図１２及び図１３では、矢印の根元が開始アドレス、矢印の先端が終了アドレスを示している。
【００９３】
図１２では、アドレスが大きくなるベクトルストア命令が、依存関係が無く連続する場合の一例を示してる。
【００９４】
命令１の終了後、解析バッファ２４の命令の方向には「大」が、最後の要素のアドレスには、「命令１の最後の要素のアドレス（終了アドレス１）」が保存される。次に、命令２が発行されると、条件判定を行う。命令２も命令１と同様に命令の方向が「大」であるため、上記の条件１が満たされる。さらに、命令２の最初の要素のアドレス（開始アドレス２）が、エントリの最後の要素のアドレス（終了アドレス１）より大きいため、条件２も満足する。その結果、依存関係が無しと決定され、フラグが設定され、待ち処理を行わずにベクトルストア命令の処理が行われる。命令３に関しても同様である。
【００９５】
図１３は、図１２の逆、つまりアドレスが小さくなるベクトルストア命令が、依存関係が無く連続的に発行される場合の一例を示している。
【００９６】
図１３の場合は、例えば、命令２が発行された場合、エントリに保存される方向も受け取った命令の方向も「小」となり、条件１が満たされる。さらに、受け取った命令２の最初のアドレス（開始アドレス２）は、保存されているエントリの最後の要素のアドレス（終了アドレス１）より小さく、条件２も満足する。従って、図１３に示す場合も、図１２と同様に依存関係が無いとの決定が行われ、待ち処理を行わずにベクトルストア命令が処理されることとなる。
【００９７】
一方、図１４に示すように、同じ方向でもアドレスが重なっているベクトルストア命令が続いた場合について説明する。図１４の命令２を受け取った場合、エントリに保存されている方向は「大」で、命令２と同じ方向のため、条件１は満足する。しかし、エントリに保存されている命令１の最後の要素のアドレス（終了アドレス１）が、命令２の最初の要素のアドレス（開始アドレス２）より大きいため、条件２が満足されない。その結果、依存関係が有りと決定され、待ち処理が行われる。
【００９８】
次に、図１５に示すように、方向が異なるベクトルストア命令が依存関係があるアドレスで発行された場合について説明する。例えば、図１５の命令２を受け取ったとき、エントリに保存されている方向は命令１の方向で「大」となる。しかし、受け取った命令２の方向は「小」であるため、条件１を満足せず、依存関係が有りと決定され、待ち処理を行うこととなる。命令３を受け取ったときも、命令の方向が反対になり、同様に依存関係が有りと決定され、待ち処理を行うこととなる。
【００９９】
以上より、これら依存関係がある場合については、必要な待ち処理が実行されることとなる。
【０１００】
なお、図１６に示すような、命令の方向は変更になっているが、実際のアドレスは重ならない場合についても説明する。図１６に示すような関係の命令が連続する場合、第２の実施形態では、最初のアドレスと最後のアドレスを基に決定するため、依存関係が無しと決定できる。一方、第３の実施形態では、命令の方向が異なるため、依存関係が有りとの決定となる。
【０１０１】
つまり、第３の実施形態は、第２の実施形態では発生しない不必要な待ち処理（ペナルティ）が発生する可能性がある。
【０１０２】
そのため、例えば、第２の実施形態の解析バッファ２３を採用するか、第３の実施形態の解析バッファ２４を採用するかとの選択を、必要なハードウェア量、ペナルティの発生頻度、および、必要な処理性能などを基に決めることが可能である。
【０１０３】
また、階層化したメモリシステムに適用する場合に、上位層で高速性が必要なデータアクセス装置では、第２の実施形態を採用し、下位層のそれほど高速性を要求されないデータアクセス装置では、第３の実施形態を採用する、といった構成なども可能である。
【０１０４】
以上のように、第３の実施形態では、依存関係のないアドレスが昇順又は降順で連続するベクトルストア命令において、待ち処理を実行せずに、スループットを向上する効果を得ることが出来る。
【０１０５】
その理由は、ベクトルストア命令の方向と、前の命令の最後の要素のアドレスと今回の命令の最初のアドレスとの比較結果を基に依存関係の有無を決定し、必要の無い待ち処理を実行せずに各要素を調停に参加させることが出来るためである。
【０１０６】
さらに、第３の実施形態では、解析バッファのハードウェアも削減する効果も得られる。
【０１０７】
その理由は、「最初の要素のアドレス」に比較してデータ量の少ない「方向ビット」を使用したためである。
【符号の説明】
【０１０８】
１    データアクセス装置
２    データ命令発行部
３    データアクセス調停部
４    調停部
２１  ベクトル要素分解部
２２  依存解析部
２３、２４  解析バッファ
３１  調停参加調整部
３２  調停参加ステージ
３３  クロスバスイッチ
３４  転送ポート
３５  フラグ
【図１】
0005549179.tif 000002
【図２】
0005549179.tif 000003
【図３】
0005549179.tif 000004
【図４】
0005549179.tif 000005
【図５】
0005549179.tif 000006
【図６】
0005549179.tif 000007
【図７】
0005549179.tif 000008
【図８】
0005549179.tif 000009
【図９】
0005549179.tif 000010
【図１０】
0005549179.tif 000011
【図１１】
0005549179.tif 000012
【図１２】
0005549179.tif 000013
【図１３】
0005549179.tif 000014
【図１４】
0005549179.tif 000015
【図１５】
0005549179.tif 000016
【図１６】
0005549179.tif 000017
【図１７】
0005549179.tif 000018