JP4557748B2

JP4557748B2 - 演算処理装置

Info

Publication number: JP4557748B2
Application number: JP2005053396A
Authority: JP
Inventors: 到山崎; 竜生照山
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2005-02-28
Filing date: 2005-02-28
Publication date: 2010-10-06
Anticipated expiration: 2025-02-28
Also published as: US20060195679A1; TW200630876A; JP2006236245A; US7937562B2

Description

本発明は、演算処理装置に関するもので、特に、複数の演算リソース（演算パイプ）を共有し、複数の命令ストリーム（プログラム列）を同時に実行することが可能なＤＳＰ（ＤｉｇｉｔａｌＳｉｇｎａｌＰｒｏｃｅｓｓｏｒ）に関する。

近年、微細加工技術の進歩により、１つのＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）中に多くの回路を搭載させることが可能になってきている。このような大規模なＬＳＩにおいては、非常に多くの演算リソースをもち、より複雑な演算を高速に行うことができるようになっている（たとえば、非特許文献１参照）。

特に、複数の命令ストリームを同時に実行することができる高性能なＤＳＰでは、その性能を最大限に発揮させるために、１つの命令ストリームの実行が終了するまで、演算リソースを占有できるようにする必要がある。つまり、一旦、命令ストリームの実行が開始されると、命令ストリーム中のある命令が使用する演算リソースを、その命令ストリームの実行が終了するまで開放（パイプライン・ストール）しないようにすることにより、命令ストリームの処理スピードの高速化が図られている。

しかしながら、１つの命令ストリームの実行が終了するまで演算リソースを開放しないようなＤＳＰの場合、演算の効率が非常に悪いという問題があった。
ＤｙｎａｍｉｃａｌｌｙＡｌｌｏｃａｔｉｎｇＰｒｏｃｅｓｓｏｒＲｅｓｏｕｒｃｅｓｂｅｔｗｅｅｎＮｅａｒｂｙａｎｄＤｉｓｔａｎｔＩＬＰ，ＲａｊｅｅｖＢａｌａｓｕｂｒａｍｏｎｉａｎｅｔａｌ著，０−７６９５−１１６２−７／０１２００１ＩＥＥＥＩｎｔｅｒｎａｔｉｏｎａｌＳｙｍｐｏｓｉｕｍｏｎＣｏｍｐｕｔｅｒＡｒｃｈｉｔｅｃｔｕｒｅ

本発明は、上記の問題点を解決すべくなされたもので、その目的は、複数の演算リソースを有効に活用でき、複数の命令ストリームを高速に処理することが可能な演算処理装置を提供することにある。

本願発明の一態様によれば、複数の演算リソースを共有し、複数の命令ストリームを同時に実行することが可能な演算処理装置であって、前記複数の演算リソースのうちのいくつかを使用して、前記複数の命令ストリームをそれぞれ実行する実行ステージと、前記実行ステージによって、前記複数の命令ストリームのうちの最初の命令ストリームを実行した際に使用した演算リソースの数量をカウントする第１のリソースカウンタと、前記第１のリソースカウンタのカウント値を記憶する管理テーブルと、前記複数の演算リソースのうち、使用されていない演算リソースの数量データを保持する第２のリソースカウンタと、後続の命令ストリームを実行する際に、前記管理テーブルに記憶されている前記第１のリソースカウンタのカウント値を読み出し、そのカウント値を前記第２のリソースカウンタで保持されている前記数量データより減算した減算結果に応じて、前記後続の命令ストリームの実行の開始を制御する制御回路とを具備し、前記制御回路は、前記後続の命令ストリームの実行を開始する前に、前記減算結果から、その命令ストリームが必要とする数量の演算リソースを確保できるかどうかをチェックし、確保できる場合に前記後続の命令ストリームの実行を開始することを特徴とする演算処理装置が提供される。

上記の構成により、複数の演算リソースを有効に活用でき、複数の命令ストリームを高速に処理することが可能な演算処理装置を提供できる。

以下、本発明の実施の形態について図面を参照して説明する。

［第１の実施形態］
図１は、この発明の第１の実施形態にしたがった、演算処理装置（ＤＳＰ）の構成を示すものである。なお、ここでは、同一の命令ストリーム（プログラム列）を、データを変えながら最大で３つ同時に実行可能に構成した場合について説明する。また、命令ストリームの実行が開始されてから終了するまでの間に占有される演算リソース（ユニット）は１種類で、このＤＳＰ内に５つ存在するものとする。また、同一の命令ストリームを最大で３つ同時に実行するために使用される演算リソース以外のハードウェアはパイプライン化されているか、もしくは、３つの命令ストリームを並列に実行できるだけのハードウェアを備えているものとする。

図１において、命令ストリーム・アドレス・レジスタ１１は、実行予定の命令ストリームが格納されたメモリ（たとえば、後述する命令キャッシュ）の、格納先の先頭アドレスを登録するためのレジスタである。本実施形態の場合、最大で５つの命令ストリームの先頭アドレスを登録しておくことができるようになっている。なお、命令ストリームの先頭アドレスの登録は、たとえば外部の制御装置（図示していない）によって行われる。

演算リソース管理テーブル１２は、連想メモリ（ＣｏｎｔｅｎｔＡｄｄｒｅｓｓａｂｌｅＭｅｍｏｒｙ（ＣＡＭ））によって構成されている。このテーブル１２には、アドレスｎ（たとえば、ｎ＝０〜７）ごとに、「Ｔａｇ」、「Ｖａｌｉｄ」、および、「＃ｏｆＲｅｓ（ナンバーオブリソース）」のフィールドが設けられ、全部で８つのリソース管理情報を登録することが可能となっている。各リソース管理情報において、「Ｔａｇ」のフィールドは、対応する命令ストリームの先頭アドレスの一部もしくはすべてを格納する場所である。「Ｖａｌｉｄ」のフィールドは、その登録（リソース管理情報）が有効か否かを示す情報を格納するための場所である。「＃ｏｆＲｅｓ」のフィールドは、対応する命令ストリームを実行する際に必要とされる演算リソース数（必要演算リソース数）を格納するための場所である。

この演算リソース管理テーブル１２は、上記命令ストリーム・アドレス・レジスタ１１に登録された、命令ストリームの先頭アドレスを用いて検索される。この検索により、先頭アドレスと「Ｔａｇ」の値とが一致（ヒット）し、かつ、「Ｖａｌｉｄ」の値が“１”の場合に、対応する「＃ｏｆＲｅｓ」に格納されている必要演算リソース数が読み出される。なお、「Ｔａｇ」の値が命令ストリームの先頭アドレスの一部である場合には、同一の命令ストリームか否かの正確な判断は別の手段（たとえば、通常のマイクロプロセッサで使用されている命令キャッシュにヒットした場合に使用されるような手段）を用いて別途検査されるものとする。

制御回路であるウェイクアップ・ロジック（ＷａｋｅＵｐＬｏｇｉｃ）１３は、命令ストリーム・アドレス・レジスタ１１に登録された先頭アドレスをもとに、演算リソース管理テーブル１２の検索を行う。また、このウェイクアップ・ロジック１３は、命令ストリーム・アドレス・レジスタ１１に登録されている先頭アドレスの１つを、たとえば３つのカレント・プログラム・カウンタ（ＣｕｒｒＰＣ）１４ａ，１４ｂ，１４ｃのうちのいずれか１つにセットする。また、このウェイクアップ・ロジック１３は、必要演算リソース数に応じて、第２のリソースカウンタであるカレント・リソース・カウンタ（ＣｕｒｒＲｅｓＣｏｕｎｔｅｒ）１５のカウントアップおよびカウントダウンを制御する。さらに、このウェイクアップ・ロジック１３は、デコーダ（Ｄｅｃｏｄｅｒ）１６の出力にもとづいて、アップデート・ロジック（ＵｐｄａｔｅＬｏｇｉｃ）１７の制御などを行うようになっている。

アップデート・ロジック１７は、上記演算リソース管理テーブル１２へのリソース管理情報の登録、つまり、「Ｔａｇ」の格納、「Ｖａｌｉｄ」の設定、および、「＃ｏｆＲｅｓ」の格納などを行うものである。

カレント・リソース・カウンタ１５は、現時点で未使用となっている演算リソース数を管理するものである。

カレント・プログラム・カウンタ１４ａ，１４ｂ，１４ｃは、それぞれ、上記ウェイクアップ・ロジック１３によってセットされた命令ストリームの先頭アドレスにしたがって、たとえば命令キャッシュ（Ｉｎｓｔ＄）１８をアクセスするものである。

デコーダ１６は、上記命令キャッシュ１８より読み出された命令（プログラム）をデコードするものである。また、このデコーダ１６は、命令ストリームの実行が終了したことを検出し、上記ウェイクアップ・ロジック１３および上記アップデート・ロジック１７に通知するようになっている。さらに、このデコーダ１６は、デコードした命令が演算リソースを必要とするような命令であった場合に、第１のリソースカウンタとしてのリソース・カウンタ（ＲｅｓＣｏｕｎｔｅｒ）１９の値を１つインクリメントさせるものである。なお、上記命令キャッシュ１８からフェッチしてきた命令が演算リソースを使用しない命令の場合には、上記リソース・カウンタ１９でのインクリメントは行われない。

命令実行ステージ（Ｅｘｅｃｕｔｅ）２０は、上記デコーダ１６によってデコードされた命令の実行を行うものである。なお、図中の命令実行ステージ２０は一つのブロックとして示されているが、内部は複数のハードウェアによって構成されており、これらのハードウェアのうちの５つが、複数のサイクルを有し、かつ、命令ストリームが使用を開始すると終了するまでは開放されることのないような演算リソースとなっている。

ここで、データを変えながら同一の命令ストリームを複数回実行する場合、順次、命令ストリームが実行される。そして、デコーダ１６によって最初の命令ストリーム（１パス目）の実行の終了が検出されると、そのときのリソース・カウンタ１９の値が上記アップデート・ロジック１７に送られる。これにより、リソース・カウンタ１９の値が、アップデート・ロジック１７によって、演算リソース管理テーブル１２の「＃ｏｆＲｅｓ」のフィールドに格納される。また、「Ｖａｌｉｄ」の値が“１”に設定される。したがって、演算リソース管理テーブル１２の「＃ｏｆＲｅｓ」の値、および、カレント・リソース・カウンタ１５の値を参照することにより、次ぎの命令ストリームが必要とする演算リソース数の把握とともに、命令ストリームの並列実行が可能か否かの判断が容易となる。

次に、図２を参照しつつ、上記した構成の動作について説明する。なお、図２は、動作にかかる処理の流れを示すフローチャートである。

＜実施例１＞
この実施例１の説明では、実行予定のある命令ストリームを、たとえばＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３とする。命令ストリームＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３は同一の命令ストリームであり、たとえば図３に示すように、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿４および２つの命令ＩＮＳＴ＿Ａを含むものとする。なお、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿４は演算リソース（たとえば、ＵＮＩＴ＿Ａ）を必要としない命令であり、命令ＩＮＳＴ＿Ａは、一旦、命令ストリームの実行がスタートすると、その命令ストリームの実行が終了するまでは演算リソースを占有することが必要な命令である。すなわち、本実施例１の場合、ＤＳＰが備える５つの演算リソースＵＮＩＴ＿Ａのうち、上記各命令ストリームＳｔｒｅａｍ１−１，１−２，１−３は、それぞれ、２つの演算リソースＵＮＩＴ＿Ａを使用するプログラム列となっている。

また、命令ストリームＳｔｒｅａｍ１−１の先頭アドレスは命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに、命令ストリームＳｔｒｅａｍ１−２の先頭アドレスはＴ１＿ＰＣに、命令ストリームＳｔｒｅａｍ１−３の先頭アドレスはＴ２＿ＰＣに、おのおの登録されるものとして説明する。

まず、実行予定のある命令ストリームＳｔｒｅａｍ１−１，１−２，１−３の各先頭アドレスが、命令ストリーム・アドレス・レジスタ１１に登録されているとする（ステップＳＴ１１）。すると、ウェイクアップ・ロジック１３が、命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに登録された先頭アドレスをもとに、演算リソース管理テーブル１２の検索を行う（ステップＳＴ１２）。

本実施例１においては、今回が、この命令ストリームＳｔｒｅａｍ１−１の１回目の実行（１パス目）である場合を想定している。つまり、今回のこの命令ストリームＳｔｒｅａｍ１−１の実行より前にこの命令ストリームＳｔｒｅａｍ１−１を実行したことがない場合、テーブル１２上のどの登録（リソース管理情報）ともヒットしない（ステップＳＴ１３）。この場合、ウェイクアップ・ロジック１３からの指示により、命令ストリームＳｔｒｅａｍ１−１の先頭アドレスの一部またはすべてが、アップデート・ロジック１７によって演算リソース管理テーブル１２の、たとえばアドレス「ｎ」に対応する「Ｔａｇ」のフィールドに格納される（ステップＳＴ０１）。

この後、ウェイクアップ・ロジック１３は、カレント・リソース・カウンタ１５の値をチェックする（ステップＳＴ０２）。そして、すべての演算リソースＵＮＩＴ＿Ａが開放されていない場合には（ステップＳＴ０３）、すべての演算リソースＵＮＩＴ＿Ａが開放されるまで待機する。本実施例１においては、カレント・リソース・カウンタ１５の値が“５”の場合に、すべての演算リソースＵＮＩＴ＿Ａが開放されている、つまり、すべての演算リソースＵＮＩＴ＿Ａは未使用（未占有）の状態にあると判断される。

すべての演算リソースＵＮＩＴ＿Ａが開放されている場合には（ステップＳＴ０３）、ウェイクアップ・ロジック１３によって、命令ストリームＳｔｒｅａｍ１−１の先頭アドレスが、カレントＰＣ１４ａ，１４ｂ，１４ｃのうちのいずれか１つにセットされる（ステップＳＴ１６）。これにより、実行に応じてインクリメントされるアドレスに応じて、命令キャッシュ１８がアクセスされる（ステップＳＴ１７）。そして、命令キャッシュ１８より取り出された命令が、デコーダ１６によってデコードされる（ステップＳＴ１８）。このとき、その命令が演算リソースＵＮＩＴ＿Ａを必要とするような命令であった場合には（ステップＳＴ１９）、リソース・カウンタ１９の値が１つインクリメントされる（ステップＳＴ２０）。

こうして、すべての演算リソースＵＮＩＴ＿Ａの開放によって、先行するすべての命令ストリームの実行の終了が判断されると、命令実行ステージ２０にて、実際に命令の実行が行われる（ステップＳＴ２１）。その際、ウェイクアップ・ロジック１３により、命令ストリームＳｔｒｅａｍ１−１の実行に用いられる演算リソースＵＮＩＴ＿Ａの総数（２）に応じて、カレント・リソース・カウンタ１５の値が更新（５−２）される。

しかる後、デコーダ１６によって、命令ストリームＳｔｒｅａｍ１−１の実行の終了が検出される（ステップＳＴ２２）。すると、そのときのリソース・カウンタ１９の値（２）が、アップデート・ロジック１７に送られる。これにより、上記リソース・カウンタ１９の値（２）が、演算リソース管理テーブル１２上の、上記アドレス「ｎ」に対応する「＃ｏｆＲｅｓ」のフィールドに格納される（ステップＳＴ２３）。また、上記アドレス「ｎ」に対応する「Ｖａｌｉｄ」の値が“１”に変更される。こうして、演算リソース管理テーブル１２上に、命令ストリームＳｔｒｅａｍ１−１に対するリソース管理情報が登録される。

また、命令ストリームＳｔｒｅａｍ１−１の実行が終了されると、命令ストリームＳｔｒｅａｍ１−１の実行に用いられた演算リソースＵＮＩＴ＿Ａの開放が行われる（ステップＳＴ２４）。これにより、ウェイクアップ・ロジック１３によって、命令ストリームＳｔｒｅａｍ１−１の実行に用いられた演算リソースＵＮＩＴ＿Ａの総数（２）に応じて、カレント・リソース・カウンタ１５の値が更新（３＋２）される。

続いて、ウェイクアップ・ロジック１３により、すべての命令ストリームＳｔｒｅａｍ１−１，１−２，１−３の実行が終了したか否かが判断される（ステップＳＴ２５）。終わっている場合には、処理は終了される。

一方、終わっていない場合には、処理は上記ステップＳＴ１２に移行される。つまり、同一の命令ストリームを繰り返し実行する場合、たとえば、命令ストリームＳｔｒｅａｍ１−１の実行が終了した後、命令ストリームＳｔｒｅａｍ１−２の実行を開始するために、まず、ウェイクアップ・ロジック１３による演算リソース管理テーブル１２の検索が行われる（ステップＳＴ１２）。その際、ウェイクアップ・ロジック１３は、命令ストリーム・アドレス・レジスタ１１のＴ１＿ＰＣに登録されている命令ストリームＳｔｒｅａｍ１−２の先頭アドレスをもとに、演算リソース管理テーブル１２の検索を行う。このとき、演算リソース管理テーブル１２上には、すでに命令ストリームＳｔｒｅａｍ１−１のリソース管理情報が登録されている。すなわち、命令ストリームＳｔｒｅａｍ１−１および命令ストリームＳｔｒｅａｍ１−２は同一の開始アドレスのため、その命令ストリームＳｔｒｅａｍ１−１のリソース管理情報がヒットする（ステップＳＴ１３）。

ヒットしたリソース管理情報があると、そのリソース管理情報の「＃ｏｆＲｅｓ」の値（２）が、カレント・リソース・カウンタ１５の値（５）から減算される。減算の結果は、ウェイクアップ・ロジック１３に送られる（ステップＳＴ１４，ＳＴ１５）。減算の結果が負の値でないということは、命令ストリームＳｔｒｅａｍ１−２を実行するために必要な演算リソースＵＮＩＴ＿Ａがまだ残っていることを示している。

そこで、ウェイクアップ・ロジック１３は、命令ストリーム・アドレス・レジスタ１１のＴ１＿ＰＣに登録されている先頭アドレスを、使用されていないカレントＰＣ１４ａ，１４ｂ，１４ｃのいずれか１つにセットする（ステップＳＴ１６）。これ以降、上記したステップＳＴ１７〜の処理が繰り返される。これにより、命令ストリームＳｔｒｅａｍ１−２の実行が開始される。

なお、カレント・リソース・カウンタ１５は、減算の結果が負の値でない場合に限って更新される。もしも、減算の結果が負の値の場合、その命令ストリームＳｔｒｅａｍ１−２を実行するのに必要な数だけ演算リソースＵＮＩＴ＿Ａが残っていないことを示している。そのため、演算リソースＵＮＩＴ＿Ａが十分な数量となるまで、ウェイクアップ・ロジック１３は、新たな命令ストリームＳｔｒｅａｍ１−２の実行を開始させない。

本実施例１の場合、命令ストリームＳｔｒｅａｍ１−２の実行を開始できるかどうかをチェックする時点で、すでに命令ストリームＳｔｒｅａｍ１−１の実行が終了している。このため、カレント・リソース・カウンタ１５の値は“５”になっている。これに対し、命令ストリームＳｔｒｅａｍ１−２を実行するために必要な、演算リソースＵＮＩＴ＿Ａの総数は“２”である。したがって、ウェイクアップ・ロジック１３は、カレントＰＣ１４ａ，１４ｂ，１４ｃのいずれか１つに命令ストリームＳｔｒｅａｍ１−２の先頭アドレスをセットすることにより、命令ストリームＳｔｒｅａｍ１−２の実行を開始させることができる。

さて、演算リソース管理テーブル１２上にリソース管理情報が登録されている状態においては、命令ストリームＳｔｒｅａｍ１−２の実行を行っている最中に、並列的に命令ストリームＳｔｒｅａｍ１−３を実行できるか否かが判断される。つまり、命令ストリーム・アドレス・レジスタ１１に、さらに同一の命令ストリームＳｔｒｅａｍ１−３が登録されている場合、命令ストリームＳｔｒｅａｍ１−２の実行を行っている最中に、上記ステップＳＴ１２〜ＳＴ１５において、命令ストリームＳｔｒｅａｍ１−３の実行を開始できるかどうかのチェックが行われる。

この実施例１の場合、命令ストリームＳｔｒｅａｍ１−２の実行が開始された時点では、カレント・リソース・カウンタ１５の値は“３”となっている。そのため、命令ストリームＳｔｒｅａｍ１−２の実行に並列して、命令ストリームＳｔｒｅａｍ１−３の実行も可能ということになる。すなわち、ウェイクアップ・ロジック１３は、カレント・リソース・カウンタ１５の値（減算の結果）が負の値でないことがわかった時点で（ステップＳＴ１４，ＳＴ１５）、命令ストリームＳｔｒｅａｍ１−３の実行を開始させる。つまり、命令ストリーム・アドレス・レジスタ１１のＴ２＿ＰＣに登録されている先頭アドレスを、使用されていないカレントＰＣ１４ａ，１４ｂ，１４ｃのいずれか１つにセットする。これにより、命令ストリームＳｔｒｅａｍ１−１，１−２，１−３は、たとえば図３に示すようなタイミングによってそれぞれ実行される。

なお、カレント・リソース・カウンタ１５は減算の結果（３−２）によって更新され、命令ストリームＳｔｒｅａｍ１−３の実行が開始された時点の、カレント・リソース・カウンタ１５の値は“１”となる。

＜実施例２＞
この実施例２の説明では、実行予定のある命令ストリームを、たとえばＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３，Ｓｔｒｅａｍ１−４とする。命令ストリームＳｔｒｅａｍ１−４は、命令ストリームＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３と同一の命令ストリームであり、たとえば図４に示すように、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿４および２つの命令ＩＮＳＴ＿Ａを含むものとする。

また、命令ストリームＳｔｒｅａｍ１−１の先頭アドレスは命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに、命令ストリームＳｔｒｅａｍ１−２の先頭アドレスはＴ１＿ＰＣに、命令ストリームＳｔｒｅａｍ１−３の先頭アドレスはＴ２＿ＰＣに、命令ストリームＳｔｒｅａｍ１−４の先頭アドレスはＴ３＿ＰＣに、おのおの登録されるものとして説明する。

上述したように、たとえば命令ストリームＳｔｒｅａｍ１−３の実行が開始されている状態において、さらに、命令ストリームＳｔｒｅａｍ１−１，１−２，１−３と同一の命令ストリームＳｔｒｅａｍ１−４の先頭アドレスが、命令ストリーム・アドレス・レジスタ１１に登録されているとする。すると、実施例１の場合と同様にして、ウェイクアップ・ロジック１３により、命令ストリーム・アドレス・レジスタ１１のＴ３＿ＰＣに登録された先頭アドレスをもとに、演算リソース管理テーブル１２の検索が行われる（ステップＳＴ１２）。

本実施例２の場合も、演算リソース管理テーブル１２上にすでに登録されている命令ストリームＳｔｒｅａｍ１−１のリソース管理情報がヒットする（ステップＳＴ１３）。しかしながら、命令ストリームＳｔｒｅａｍ１−３の実行が開始された時点で、カレント・リソース・カウンタ１５の値は“１”となっている（ステップＳＴ１４）。この場合、カレント・リソース・カウンタ１５の値（１）から、ヒットしたリソース管理情報の「＃ｏｆＲｅｓ」の値（２）を減算した結果が負の値（−１）となる。そのため、演算リソースＵＮＩＴ＿Ａが十分な数量となるまで（ステップＳＴ１５）、ウェイクアップ・ロジック１３は、新たな命令ストリームＳｔｒｅａｍ１−４の実行を開始させない。

すなわち、命令ストリームＳｔｒｅａｍ１−２，１−３が実行されている最中においては、命令ストリームＳｔｒｅａｍ１−４を実行するのに必要な数の演算リソースＵＮＩＴ＿Ａが不足する。命令ストリームＳｔｒｅａｍ１−２の実行が終了した時点で、命令ストリームＳｔｒｅａｍ１−２が占有していた２つの演算リソースＵＮＩＴ＿Ａが開放される。すると、カレント・リソース・カウンタ１５の値が更新（１＋２）される。これにより、命令ストリームＳｔｒｅａｍ１−４を実行するのに必要な数の演算リソースＵＮＩＴ＿Ａを確保することが可能となる。その結果、たとえば図４に示すタイミングにより、命令ストリームＳｔｒｅａｍ１−４の実行が開始される。

＜実施例３＞
この実施例３の説明では、実行予定のある命令ストリームを、たとえばＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３，Ｓｔｒｅａｍ２−１とする。命令ストリームＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３は同一の命令ストリームであり、たとえば図５に示すように、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿４および２つの命令ＩＮＳＴ＿Ａを含むものとする。これに対し、命令ストリームＳｔｒｅａｍ２−１は、命令ストリームＳｔｒｅａｍ１−１，Ｓｔｒｅａｍ１−２，Ｓｔｒｅａｍ１−３とは異なる命令ストリームであり、たとえば図５に示すように、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿４および４つの命令ＩＮＳＴ＿Ａを含むものとする。すなわち、本実施例３の場合、ＤＳＰが備える５つの演算リソースＵＮＩＴ＿Ａのうち、上記命令ストリームＳｔｒｅａｍ１−１，１−２，１−３はそれぞれ２つの演算リソースＵＮＩＴ＿Ａを使用するプログラム列であり、上記命令ストリームＳｔｒｅａｍ２−１は４つの演算リソースＵＮＩＴ＿Ａを使用するプログラム列となっている。

また、命令ストリームＳｔｒｅａｍ１−１の先頭アドレスは命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに、命令ストリームＳｔｒｅａｍ１−２の先頭アドレスはＴ１＿ＰＣに、命令ストリームＳｔｒｅａｍ１−３の先頭アドレスはＴ２＿ＰＣに、命令ストリームＳｔｒｅａｍ２−１の先頭アドレスはＴ３＿ＰＣに、おのおの登録されるものとして説明する。

上述したように、たとえば命令ストリームＳｔｒｅａｍ１−３の実行が開始されている状態において、さらに、命令ストリームＳｔｒｅａｍ１−１，１−２，１−３とは異なる命令ストリームＳｔｒｅａｍ２−１の先頭アドレスが、命令ストリーム・アドレス・レジスタ１１に登録されているとする。すると、実施例２の場合と同様にして、ウェイクアップ・ロジック１３により、命令ストリーム・アドレス・レジスタ１１のＴ３＿ＰＣに登録された先頭アドレスをもとに、演算リソース管理テーブル１２の検索が行われる（ステップＳＴ１２）。

すなわち、上記した命令ストリームＳｔｒｅａｍ１−４ではなく、これまでに実行したことのない命令ストリームＳｔｒｅａｍ２−１の先頭アドレスが、命令ストリーム・アドレス・レジスタ１１に登録されている場合、演算リソース管理テーブル１２には、まだ、命令ストリームＳｔｒｅａｍ２−１のリソース管理情報が登録されていないので、演算リソース管理テーブル１２の検索はミス（ノーヒット）となる（ステップＳＴ１３）。この場合、命令ストリームＳｔｒｅａｍ２−１を実行するのに必要な演算リソース数がわからないため、すべての実行中の命令ストリームが終了するまで、命令ストリームＳｔｒｅａｍ２−１の実行を開始することができない。

したがって、実施例１で説明した通り、まず、演算リソース管理テーブル１２上に命令ストリームＳｔｒｅａｍ２−１のリソース管理情報を登録するために、ステップＳＴ０１〜の処理が行われる。これにより、命令ストリームＳｔｒｅａｍ２−１を実行するのに必要な演算リソース数の取得が行われる。つまり、命令ストリームＳｔｒｅａｍ２−１の実行は、たとえば図５に示すように、命令ストリームＳｔｒｅａｍ１−３の実行が終了した時点（ステップＳＴ０３）で開始される。

上記したように、同一の命令ストリームを、データを変えて複数回実行させるような場合に、ある命令ストリームの実行の途中において、別の命令ストリームの並列実行が可能かどうかを容易に判断できるようにしている。すなわち、同一の命令ストリームを複数回実行させる場合、まず、すべての演算リソースが空いている状態で、１パス目の命令ストリームを実行させ、そのときに使用した演算リソース量（数）をテーブル上に記憶しておき、それ以降、同一の命令ストリームを実行する際には、このテーブルを参照することによって、必要とする演算リソース数を自動的に把握できるようにしている。これにより、命令ストリームによって占有されるリソース数をいちいちユーザが設定したりすることなしに、並列実行が可能な命令ストリームのウェイクアップが容易に可能となる。しかも、演算リソースのパイプラインをストール可能なように設計した場合に、演算リソースの動作スピードが遅くなるといった不具合をも改善できるようになる。したがって、複数の演算リソースを有効に活用でき、複数の命令ストリームを高速に処理することが可能となるものである。

なお、上記した第１の実施形態においては、２つの命令ストリームを並列実行可能にした場合に限らず、たとえば３つ以上の命令ストリームを並列実行可能なように構成することも可能である。

［第２の実施形態］
図６は、この発明の第２の実施形態にしたがった、演算処理装置（ＤＳＰ）の構成を示すものである。なお、ここでは図１に示した構成のＤＳＰにおいて、さらに、演算リソースが必要なくなった時点で、命令ストリームの実行の終了を待つことなく、演算リソースを開放することができるように構成した場合について説明する。また、図１と同一部分には同一符号を付して、詳しい説明は割愛する。

また、この第２の実施形態においては、たとえば図７に示すように、実行予定のある命令ストリームを、Ｓｔｒｅａｍ１１−１，Ｓｔｒｅａｍ１１−２，Ｓｔｒｅａｍ１１−３，Ｓｔｒｅａｍ１１−４とする。命令ストリームＳｔｒｅａｍ１１−１，Ｓｔｒｅａｍ１１−２，Ｓｔｒｅａｍ１１−３，Ｓｔｒｅａｍ１１−４は同一の命令ストリームであり、たとえば、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿７および２つの命令ＩＮＳＴ＿Ａを含むものとする。なお、命令Ｉｎｓｔ＿１〜Ｉｎｓｔ＿７は演算リソース（たとえば、ＵＮＩＴ＿Ａ）を必要としない命令であり、命令ＩＮＳＴ＿Ａは演算リソースを必要とする命令で、たとえば、命令Ｉｎｓｔ＿４の実行が終了するまでは演算リソースを占有することが必要な命令となっている。

また、命令ストリームＳｔｒｅａｍ１１−１の先頭アドレスは命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに、命令ストリームＳｔｒｅａｍ１１−２の先頭アドレスはＴ１＿ＰＣに、命令ストリームＳｔｒｅａｍ１１−３の先頭アドレスはＴ２＿ＰＣに、命令ストリームＳｔｒｅａｍ１１−４の先頭アドレスはＴ３＿ＰＣに、おのおの登録されるものとして説明する。

この第２の実施形態の場合、たとえば図６に示すように、演算リソース管理テーブル１２ａ上の各リソース管理情報に対し、さらに、「Ｅｎｄ」のフィールドが追加されている。「Ｅｎｄ」のフィールドは、それぞれ、命令ストリームの実行が終了する前に、演算リソースの開放を可能にする時点の判断の基準となるデータを格納するための場所である。「Ｅｎｄ」のデータは、たとえば、演算リソースＵＮＩＴ＿Ａ内にデータを保持するレジスタがあると仮定すると、そのレジスタを最後にアクセスするような特殊な命令（本実施形態の場合、Ｉｎｓｔ＿４）のアドレスである。

デコーダ１６ａは、命令キャッシュ１８より読み出された命令（プログラム）をデコードするもので、たとえば入力された命令が演算リソースＵＮＩＴ＿Ａ内のレジスタをアクセスするような特殊な命令かどうかを判定する機能が付加されている。

レジスタ（ＲｅｆＡｄｒ）２１は特殊な命令のアドレスを記憶するためのもので、デコーダ１６ａによって特殊な命令がデコードされるたびに、その内容が更新されるものである。なお、同一の命令ストリームを、データを変えて複数回実行させるような場合において、１パス目の命令ストリームを実行した際に、このレジスタ２１に最終的に記憶されたアドレスが、アップデータ・ロジック１７によって、上記演算リソース管理テーブル１２ａの「Ｅｎｄ」のフィールドに格納される。

ウェイクアップ・ロジック１３は、１パス目以降の、同一の命令ストリームが実行されるごとに、必要演算リソース数（「＃ｏｆＲｅｓ」の値）とともに、対応する「Ｅｎｄ」のデータを、命令リソース管理テーブル１２ａから読み出す。そして、その「Ｅｎｄ」のデータとカレントＰＣ１４ａ，１４ｂ，１４ｃの値との比較を行い、両者が一致した場合に、カレント・リソース・カウンタ１５の値に、その実行中の命令ストリームの必要演算リソース数を加算し、カレント・リソース・カウンタ１５の値を更新する。こうすることによって、命令ストリームの実行の終了時ではなく、演算リソースの占有が必要なくなった時点で、演算リソースの開放を行うことが可能になる。

次に、図８を参照しつつ、上記した構成の動作について説明する。なお、図８は、動作にかかる処理の流れを示すフローチャートである。

まず、実行予定のある命令ストリームＳｔｒｅａｍ１１−１，１１−２，１１−３，１１−４の各先頭アドレスが、命令ストリーム・アドレス・レジスタ１１に登録されているとする（ステップＳＴ１１）。すると、ウェイクアップ・ロジック１３が、命令ストリーム・アドレス・レジスタ１１のＴ０＿ＰＣに登録された先頭アドレスをもとに、演算リソース管理テーブル１２ａの検索を行う（ステップＳＴ１２）。

今回が、命令ストリームＳｔｒｅａｍ１１−１の１回目の実行（１パス目）である場合、テーブル１２ａ上のどの登録（リソース管理情報）ともヒットしない（ステップＳＴ１３）。この場合、ウェイクアップ・ロジック１３からの指示により、命令ストリームＳｔｒｅａｍ１１−１の先頭アドレスの一部またはすべてが、アップデート・ロジック１７によって演算リソース管理テーブル１２ａの、たとえばアドレス「ｎ」に対応する「Ｔａｇ」のフィールドに格納される（ステップＳＴ０１）。

この後、ウェイクアップ・ロジック１３は、カレント・リソース・カウンタ１５の値をチェックする（ステップＳＴ０２）。そして、すべての演算リソースＵＮＩＴ＿Ａが開放されていない場合には（ステップＳＴ０３）、すべての演算リソースＵＮＩＴ＿Ａが開放されるまで待機する。本実施形態の場合においては、カレント・リソース・カウンタ１５の値が“５”の場合に、すべての演算リソースＵＮＩＴ＿Ａが開放されている、つまり、すべての演算リソースＵＮＩＴ＿Ａは未使用（未占有）の状態にあると判断される。

すべての演算リソースＵＮＩＴ＿Ａが開放されている場合には（ステップＳＴ０３）、ウェイクアップ・ロジック１３によって、命令ストリームＳｔｒｅａｍ１１−１の先頭アドレスが、カレントＰＣ１４ａ，１４ｂ，１４ｃのうちのいずれか１つにセットされる（ステップＳＴ１６）。これにより、その先頭アドレスに応じて、命令キャッシュ１８がアクセスされる（ステップＳＴ１７）。そして、命令キャッシュ１８より取り出された命令が、デコーダ１６ａによってデコードされる（ステップＳＴ１８）。このとき、その命令が演算リソースＵＮＩＴ＿Ａを必要とするような命令であった場合には（ステップＳＴ１９）、リソース・カウンタ１９の値が１つインクリメントされる（ステップＳＴ２０）。

また、デコーダ１６ａによって、デコードされた命令が演算リソースＵＮＩＴ＿Ａのレジスタをアクセスするような特殊な命令かどうかの判定が行われる（ステップＳＴ１１１）。もし、特殊な命令である場合には、その命令のアドレスの一部もしくはすべてがレジスタ２１にセットされる（ステップＳＴ１１２）。これにより、レジスタ２１は、デコーダ１６ａによって特殊な命令がデコードされるたびに、その内容が更新される。

こうして、すべての演算リソースＵＮＩＴ＿Ａの開放によって、先行するすべての命令ストリームの実行の終了が判断された場合にのみ、命令実行ステージ２０にて、実際に命令の実行が行われる（ステップＳＴ２１）。その際、ウェイクアップ・ロジック１３により、命令ストリームＳｔｒｅａｍ１１−１の実行に用いられる演算リソースＵＮＩＴ＿Ａの総数（２）に応じて、カレント・リソース・カウンタ１５の値が更新（５−２）される。

しかる後、デコーダ１６ａによって、命令ストリームＳｔｒｅａｍ１１−１の実行の終了が検出される（ステップＳＴ２２）。すると、そのときのリソース・カウンタ１９の値（２）が、アップデート・ロジック１７に送られる。これにより、上記リソース・カウンタ１９の値が、演算リソース管理テーブル１２ａ上の、上記アドレス「ｎ」に対応する「＃ｏｆＲｅｓ」のフィールドに格納される（ステップＳＴ２３）。同様に、そのときのレジスタ２１の内容（Ｉｎｓｔ＿４のアドレス）が、アップデート・ロジック１７に送られる。これにより、上記レジスタ２１の内容が、演算リソース管理テーブル１２ａ上の、上記アドレス「ｎ」に対応する「Ｅｎｄ」のフィールドに格納される（ステップＳＴ２３）。また、上記アドレス「ｎ」に対応する「Ｖａｌｉｄ」の値が“１”に変更される。こうして、演算リソース管理テーブル１２ａ上に、命令ストリームＳｔｒｅａｍ１１−１に対するリソース管理情報が登録される。

また、命令ストリームＳｔｒｅａｍ１１−１の実行が終了されると、命令ストリームＳｔｒｅａｍ１１−１の実行に用いられた演算リソースＵＮＩＴ＿Ａの開放が行われる（ステップＳＴ２４）。これにより、ウェイクアップ・ロジック１３によって、命令ストリームＳｔｒｅａｍ１１−１の実行に用いられた演算リソースＵＮＩＴ＿Ａの総数（２）に応じて、カレント・リソース・カウンタ１５の値が更新（３＋２）される。

続いて、ウェイクアップ・ロジック１３により、すべての命令ストリームＳｔｒｅａｍ１１−１，１１−２，１１−３，１１−４の実行が終了したか否かが判断される（ステップＳＴ２５）。終わっている場合には、処理は終了される。

一方、終わっていない場合には、処理は上記ステップＳＴ１２に移行される。つまり、同一の命令ストリームを繰り返し実行する場合、たとえば、命令ストリームＳｔｒｅａｍ１１−１の実行が終了した後、命令ストリームＳｔｒｅａｍ１１−２の実行を開始するために、まず、ウェイクアップ・ロジック１３による演算リソース管理テーブル１２ａの検索が行われる（ステップＳＴ１２）。このとき、演算リソース管理テーブル１２ａ上には、すでに命令ストリームＳｔｒｅａｍ１１−１のリソース管理情報が登録されている。すなわち、命令ストリームＳｔｒｅａｍ１１−１および命令ストリームＳｔｒｅａｍ１１−２は同一の開始アドレスのため、その命令ストリームＳｔｒｅａｍ１１−１のリソース管理情報がヒットする（ステップＳＴ１３）。

ヒットしたリソース管理情報があると、そのリソース管理情報の「＃ｏｆＲｅｓ」の値（２）および「Ｅｎｄ」のデータ（Ｉｎｓｔ＿４のアドレス）が読み出される。そして、「＃ｏｆＲｅｓ」の値が、カレント・リソース・カウンタ１５の値（５）から減算される。この減算の結果は、ウェイクアップ・ロジック１３に送られる（ステップＳＴ１４，ＳＴ１５）。

減算の結果が負の値でない場合、ウェイクアップ・ロジック１３は、命令ストリーム・アドレス・レジスタ１１のＴ１＿ＰＣに登録されている先頭アドレスを、使用されていないカレントＰＣ１４ａ，１４ｂ，１４ｃのいずれか１つにセットする（ステップＳＴ１６）。これ以降、上記したステップＳＴ１７〜の処理が繰り返される。これにより、命令ストリームＳｔｒｅａｍ１１−２の実行が開始される。

もし、減算の結果が負の値の場合、演算リソースＵＮＩＴ＿Ａが十分な数量となるまで、ウェイクアップ・ロジック１３は、新たな命令ストリームＳｔｒｅａｍ１１−２の実行を開始させない。

一方、命令ストリームＳｔｒｅａｍ１１−２の実行の途中において、演算リソース管理テーブル１２ａより読み出された、そのリソース管理情報の「Ｅｎｄ」のデータ（Ｉｎｓｔ＿４のアドレス）は、ウェイクアップ・ロジック１３によって、カレントＰＣ１４ａ，１４ｂ，１４ｃのいずれかにセットされ、実行にともなってインクリメントされる命令ストリームＳｔｒｅａｍ１１−１のアドレスと比較される（ステップＳＴ１１３）。「Ｅｎｄ」のデータとカレントＰＣ１４ａ，１４ｂ，１４ｃのいずれかにセットされているアドレスとが一致しない場合には、上記したステップＳＴ１７以降の処理が繰り返される。

これに対し、「Ｅｎｄ」のデータとカレントＰＣ１４ａ，１４ｂ，１４ｃのいずれかにセットされているアドレスとが一致した場合には、カレント・リソース・カウンタ１５の値に、その実行中の命令ストリームＳｔｒｅａｍ１１−２の必要演算リソース数を加算（３＋２）し、カレント・リソース・カウンタ１５の値を更新させる（ステップＳＴ２４）。こうすることによって、命令ストリームＳｔｒｅａｍ１１−２の実行の終了時ではなく、命令Ｉｎｓｔ＿４の実行が終了した時点、つまり、演算リソースＵＮＩＴ＿Ａの占有が必要なくなった時点で、演算リソースＵＮＩＴ＿Ａの開放を行うことが可能になる。

すなわち、本実施形態のように、各命令ストリームＳｔｒｅａｍ１１−１，１１−２，１１−３，１１−４の命令Ｉｎｓｔ＿４が、それぞれ、命令ＩＮＳＴ＿Ａが使用する演算リソースＵＮＩＴ＿Ａのレジスタをアクセスする最後の命令であるとした場合、この命令Ｉｎｓｔ＿４のアドレスを特殊な命令として管理することにより、命令ストリームＳｔｒｅａｍ１１−１，１１−２，１１−３，１１−４を実行している途中において、演算リソースＵＮＩＴ＿Ａの占有が必要なくなった時点を判断することが可能となる。たとえば、命令Ｉｎｓｔ＿４の実行が終了するまでは演算リソースＵＮＩＴ＿Ａの占有が必要であるが、それ以降の命令Ｉｎｓｔ５〜７では演算リソースＵＮＩＴ＿Ａの占有を必要としない命令ストリームＳｔｒｅａｍ１１−１，１１−２，１１−３，１１−４については、命令Ｉｎｓｔ＿４の実行が終了した時点で、演算リソースＵＮＩＴ＿Ａの開放が可能である。したがって、演算リソースＵＮＩＴ＿Ａの占有が必要な最後の命令Ｉｎｓｔ＿４を検出し、命令ストリームＳｔｒｅａｍ１１−２の実行が終了する前に演算リソースＵＮＩＴ＿Ａの開放を行うことにより、たとえば図７に示すように、後続の命令ストリームＳｔｒｅａｍ１１−３に限らず、命令ストリームＳｔｒｅａｍ１１−３に続く、命令ストリームＳｔｒｅａｍ１１−４の実行の開始をも早めることが可能となる。

なお、本実施形態の場合においても、ＤＳＰや命令ストリームの構成などに関しては、これに限定されるものではない。

その他、本願発明は、上記（各）実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記（各）実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、（各）実施形態に示される全構成要件からいくつかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（の少なくとも１つ）が得られる場合には、その構成要件が削除された構成が発明として抽出され得る。

本発明の第１の実施形態にしたがった、演算処理装置（ＤＳＰ）の構成例を示すブロック図。図１に示したＤＳＰの動作を説明するために示すフローチャート。実施例１にかかる動作を説明するために示す図。実施例２にかかる動作を説明するために示す図。実施例３にかかる動作を説明するために示す図。本発明の第２の実施形態にしたがった、演算処理装置の構成例を示すブロック図。図６に示したＤＳＰの動作を説明するために示す図。図６に示したＤＳＰの動作を説明するために示すフローチャート。

符号の説明

１１…命令ストリーム・アドレス・レジスタ、１２，１２ａ…演算リソース管理テーブル、１３…ウェイクアップ・ロジック、１４ａ，１４ｂ，１４ｃ…カレント・プログラム・カウンタ、１５…カレント・リソース・カウンタ、１６，１６ａ…デコーダ、１７…アップデート・ロジック、１８…命令キャッシュ、１９…リソース・カウンタ、２０…命令実行ステージ、２１…レジスタ。

Claims

複数の演算リソースを共有し、複数の命令ストリームを同時に実行することが可能な演算処理装置であって、
前記複数の演算リソースのうちのいくつかを使用して、前記複数の命令ストリームをそれぞれ実行する実行ステージと、
前記実行ステージによって、前記複数の命令ストリームのうちの最初の命令ストリームを実行した際に使用した演算リソースの数量をカウントする第１のリソースカウンタと、
前記第１のリソースカウンタのカウント値を記憶する管理テーブルと、
前記複数の演算リソースのうち、使用されていない演算リソースの数量データを保持する第２のリソースカウンタと、
後続の命令ストリームを実行する際に、前記管理テーブルに記憶されている前記第１のリソースカウンタのカウント値を読み出し、そのカウント値を前記第２のリソースカウンタで保持されている前記数量データより減算した減算結果に応じて、前記後続の命令ストリームの実行の開始を制御する制御回路と
を具備し、
前記制御回路は、前記後続の命令ストリームの実行を開始する前に、前記減算結果から、その命令ストリームが必要とする数量の演算リソースを確保できるかどうかをチェックし、確保できる場合に前記後続の命令ストリームの実行を開始することを特徴とする演算処理装置。
前記複数の命令ストリームは、データを変えながら繰り返し実行される同一の命令ストリームであることを特徴とする請求項１に記載の演算処理装置。
前記複数の演算リソースは、その演算リソースを使用する命令ストリームの実行が終了するまでは開放されないことを特徴とする請求項１に記載の演算処理装置。
前記第１のリソースカウンタは、前記最初の命令ストリームを実行する際にデコードした、演算リソースを必要とする命令の数をカウントするものであることを特徴とする請求項１に記載の演算処理装置。
さらに、
前記実行ステージによって、前記最初の命令ストリームを実行した際の、演算リソースを必要とする命令のアドレスにより更新されるレジスタと、
前記最初の命令ストリームの実行が終了した際に、前記レジスタで保持されている最終アドレスを、前記管理テーブルに格納するロジック回路と
を具備し、
前記制御回路は、後続の命令ストリームを実行する際に、前記管理テーブルに記憶されている前記最終アドレスを読み出し、その最終アドレスを前記後続の命令ストリームを実行する際にデコードした命令のアドレスと比較し、一致した場合に前記後続の命令ストリームが使用した演算リソースを開放するようにしたことを特徴とする請求項１に記載の演算処理装置。