図1は、本発明の実施の形態にかかわるソフトウェア処理システムの基本構成を示すブロック図である。
図1において、プロセッサ101がソフトウェア処理の実行を始めると、使用状況監視処理手段103は、プロセッサ101が使用するリソース102の使用状況を監視し、その出力を受けて、リソース102の使用状況の情報を取得する。リソース102の使用状況の情報の結果に応じて、ソフトウェア処理変更処理手段104は実行されるソフトウェアの処理方法を変更する。
なお、前記使用状況監視処理手段103および前記ソフトウェア処理変更処理手段104は、それぞれソフトウェアで実現したものを想定しているが、それぞれハードウェアで実現しても良く、少なくとも、リソースの使用状況を監視し、その情報を取得する機能、および、前記情報の出力を受けてソフトウェアの処理方法を変更する機能を有していれば良いものである。
以下、本発明の第1から第6までの実施の形態について、図を用いて説明する。
(第1の実施の形態)
以下、本発明の第1の実施の形態を図面に基づいて説明する。
図2は、本発明の第1の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。
図2において、1001はCPU、1002はCPU1001が使用するバス、1003はCPU1001の周辺回路、1004は外部メモリ、1005はバス1002上のバスアクセスの状態を記憶する使用状況監視装置である。
図3は、本発明の第1の実施の形態にかかわるソフトウェア処理システムのバス1002の使用状況監視装置1005の構成を示す図である。
図3において、1101はバス1002上でバスアクセスが起きているかどうかを特定の期間だけ識別するバスアクセス識別装置、1102はバスアクセス識別装置1101の出力を受けて、バスアクセスの状態を記録するバスアクセス状態レジスタである。
図4は、本発明の第1の実施の形態にかかわるソフトウェア処理システムのソフトウェアの構成を示す図である。
図4において、1201はCPU1001上で動作するプログラム、1202,1203,1204はプログラム1201中に記述される処理、1205,1206,1207は処理1202,1203,1204とそれぞれ同等の機能を持ち、バス1002を使用しないCPU1001用の処理である。
図5は、本発明の第1の実施の形態にかかわるソフトウェア処理システムにおけるコンパイルフローを示すフローチャートである。
図5において、1301はコンパイラがプログラム1201をコンパイルするコンパイル手段、1302はプログラム1201に記述される処理において、バス1002を使用する処理を識別する処理識別手段、1303は処理識別手段1302の出力を受けて、使用状況監視装置1005が持つバスアクセス状態レジスタ1102の値を読み取り、バスアクセスの情報を動的に判定するプログラムである使用状況判定処理、および、処理識別手段1302により識別された処理を、処理識別手段1302により識別された処理と等価な前記リソースを使用しない等価処理に置き換える置換処理を付加する処理付加手段である。
図6は、本発明の第1の実施の形態にかかわるソフトウェア処理システムにおけるバスアクセス識別装置1101が識別するバスアクセスの状態を示す図であり、図7は、そのソフトウェア処理システムにおける処理付加手段1303によるソフトウェアの変更を示す図である。
以下、第1の実施の形態のソフトウェア処理システムの動作について説明する。
本実施の形態においては、CPU1001によって、プログラム1201に記述される処理1202,1203,1204が、処理1202,処理1203,処理1204の順番に処理され、かつ、処理1202,1203はバス1002を使用する。
図4、図5に示すように、プログラム1201のコンパイルの際には、まず、処理1202,1203,1204はコンパイル手段1301によってコンパイルされる。また同時に、処理識別手段1302によってバス1002を使用する処理として処理1202,1203が識別される。次に、処理識別手段1302によって得られた処理1202と処理1203の実行の直前に使用状況判定処理および置換処理が行われるように、処理付加手段1303によって使用状況判定処理および置換処理が付加される。前記付加処理により、プログラム1201の処理は、処理1202が行われる直前において、使用状況判定処理および置換処理が実行されることとなる。
バスアクセス状態レジスタ1102に記録される値は、バスアクセス識別装置1101によって算出される。この算出される値は、図6に示すように、バスアクセスが発生していれば増加し、バスアクセスが発生していなければ減少し、値の増減の度合いは任意に設定することができる。
ここで、算出される値をαとし、αの増減の度合いをβとする。αの算出方法は、まず、αに1サイクル毎にβを掛けて、次に、その値(α×β)に、バスアクセスが発生していれば1を、バスアクセスが発生していなければ0を足す。つまり、nサイクル目でのαの値をα(n)とすると、
α(n)=β×α(n−1)+(1または0)
となる。例えば、βを0.9とした場合、αの値は0から10の間の値をとることになり、そのαの値がバスアクセスが頻繁に発生しているかどうかの目安の値となる。
βを0.9とした場合のバスアクセスの状態を表すαとサイクル数の関係は図6のように示される。αの値の変化が増加している箇所はバスサイクルが頻繁に発生しており、αの値が減少している箇所はバスアクセスが発生していない。
以上のように、バスアクセス識別装置1101は、バスアクセスが頻繁に発生しているかどうかの目安となるαの値を算出し、その結果をバスアクセス状態レジスタ1102へ記録する。
使用状況判定処理は、バスアクセス状態レジスタ1102に記録されている値αを読み取り、特定の値と比較してバスアクセスの状態を判定する。この特定の値は任意に設定することができる値であり、バスアクセスが頻繁に発生しているかどうかを判定する閾値となる。前述のβ=0.9の場合、αは0から10の値をとることになるので、前述の閾値を5と設定したとすると、αが5より大きければ、その時点でバスアクセスが頻繁に発生していると判定できる。逆にαが5以下であれば、バスアクセスは頻繁に発生していないと判定できる。
この判定の結果を受けて、置換処理は、処理1202を処理1205へ変更する。つまり、判定の結果、バス1002が頻繁に使用されていれば、置換処理によって処理1202の代わりに処理1205が行われる。逆に、判定の結果、バス1002が頻繁に使用されていなければ、処理1202がそのまま行われる。
処理識別手段1302によってバス1002を使用する処理であると識別された処理1203についても同様に、処理付加手段1303によって付加された使用状況判定処理および置換処理が行われ、バス1002が頻繁に使用されていれば、処理1203の代わりに処理1206が行われ、バス1002が頻繁に使用されていなければ、処理1203が行われる。
以上のように本実施の形態によれば、使用状況判定処理および置換処理によって、バス1002におけるバスアクセス競合の発生を軽減し、バス1002を効率良く使用することが可能となり、バスアクセスの競合の発生によるシステムの処理速度の低下の影響を軽減することができる。
なお、本実施の形態では、プロセッサを1つのCPU、リソースを1つのバスとしたが、それぞれ複数のCPU、バスでも良く、少なくとも1つのリソースとそのリソースを使用する少なくとも1つのプロセッサであれば良いものである。
なお、本実施の形態では、バスアクセス状態レジスタにαを求めているが、αの求め方あるいはバスのアクセス頻度を求める方法は本方法によらずともよく、指標として求めることができるものであれば同等の効果を得られる。
(第2の実施の形態)
第2の実施の形態によるソフトウェア処理システムを図8〜図15を用いて具体的に説明する。
図8は、第2の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。図8においてソフトウェア処理システムは、プロセッサ2001と、DSP2002と、プロセッサ2001とDSP2002で実行するソフトウェアを格納した記憶装置2003と、周辺回路2004と、バス調停回路2005と、外部メモリ2006と、共有バス2007で構成される。
図8では、プロセッサ2001はDSP2002を突き放し制御方式で制御しており、プロセッサ2001が記憶装置2003から読み出したソフトウェアがDSP2002で実行すべき処理の場合は、プロセッサ2001はDSP2002へ処理要求を発行し、DSP2002は処理要求を受けた後、処理を実行する。外部メモリ2006はプロセッサ2001、DSP2002が処理を実行する際に使用する共有メモリである。バス調停回路2005はバスアクセスを管理しており、共有メモリへのアクセス競合、すなわち共有バス2007のバス競合が発生した場合には、外部メモリ2006へアクセスする処理を実行するか否かを判定する。
ここで、バス調停回路2005の制御フローを図9に示す。図9において、2101は共有メモリである外部メモリ2006へのアクセス要求(読み出しまたは書き込み要求)が発生したか否かを判定するアクセス要求判定手段であり、2102は現在、外部メモリ2006がアクセス中か否かを判定するメモリ状態判定手段であり、2103はアクセス要求に対しバスを解放しメモリアクセスを促すメモリアクセス許可手段であり、2104は処理が終了したか否かを判定する処理終了判定手段である。
外部メモリ2006へのアクセス中に新たな外部メモリ2006へのアクセス要求が発生した場合、つまりバス競合が発生した場合、バス調停回路2005は、一旦、アクセス要求を受理し、実際の処理に関しては先の処理が終了するまで待機(wait)状態となる。外部メモリ2006へのアクセスが頻繁に発生すると、バス競合が発生し、バス調停回路2005により処理が待機(wait)状態となる。その結果、ソフトウェア処理システム全体の処理速度が低下する。そこで第2の実施の形態では、バス競合を避け、処理速度の低下を防ぐ。
本実施の形態におけるコンパイラは、処理記述言語で記述されたソフトウェアからオブジェクトコードを出力する通常のコンパイラとしての機能の他に、図10の処理フローに示す機能を有する。コンパイラは、まず、処理識別手段2201として外部メモリ2006へ頻繁にアクセスする処理を識別する。これは、処理識別手段2201が外部メモリ2006へアクセスする処理をあらかじめ認識していれば可能である。次に、識別した処理に対して、これと等価であるが、外部メモリ2006へのアクセスが少ない処理である等価処理があらかじめライブラリ等で用意されているか否かを判定する。もし用意されていれば、コンパイラは処理識別手段2201で識別した処理に対して等価処理、記憶処理、使用状況判定処理、置換処理を追加する。ここで、記憶処理とは外部メモリ2006へ頻繁にアクセスする処理の要求が発行されてから処理が終了するまでの処理時間を記録する処理であり、使用状況判定処理とは記憶処理で記憶した使用状況の情報からバス競合が発生しているか否かを判定する処理であり、置換処理とは処理識別手段2201で識別した処理を等価処理へ置き換える処理を示す。
図11は、図10の処理フローをもつコンパイラを使用したときの外部メモリ2006へ頻繁にアクセスする処理の変更を示す図である。図11では、外部メモリ2006へ頻繁にアクセスする処理を関数"mem_acs_many()"とし、この等価処理を"mem_acs_few()"としている。コンパイラは、あらかじめ外部メモリ2006へアクセスする処理を登録することで、処理識別手段2201を用いてソフトウェアの中から関数"mem_acs_many()"を識別する。
次に、コンパイラは処理識別手段2201で識別した処理に対して上記の等価処理、記憶処理、使用状況判定処理、置換処理を付加する。
まず、図11(b)の2行目では、ソフトウェアに使用状況判定処理を付加する。ここで"task_time"はプロセッサ2001が外部メモリ2006へ頻繁にアクセスする処理の要求を発行してから処理が終了するまでの処理時間であり、"DEFINED_TIME"はあらかじめ設定された設定値である。処理時間"task_time"は、過去に発生した外部メモリ2006へ頻繁にアクセスする処理の処理時間を表しており、現時刻に発生する外部メモリ2006へ頻繁にアクセスする処理を実行する前に"task_time"を参照し、設定値である"DEFINED_TIME"と比較することでバス競合を判定する。バス競合が発生中と判定された場合、図9の制御フローに従うバス調停回路2005では、バス競合の発生時に処理を待機状態とするため、そのときの処理時間は長くなる。つまり、外部メモリ2006へ頻繁にアクセスする処理の処理時間がある程度大きくなるとバス競合が発生したと推定できる。なお、設定値については、ソフトウェア処理システムの仕様に応じて的確な値を設定するのが望ましい。
次に、図11(b)の3行目から6行目は、記憶処理を示す。使用状況判定処理によりバス競合が発生していないと推定された場合、"mem_acs_many()"実行の前後のタイマーの値を参照し、その差を算出することで処理時間"task_time"を算出している。
図11(b)の8行目から10行目は、置換処理を示す。使用状況判定処理によりバス競合が発生していると推定された場合、さらにバス競合を発生させることを防ぐため、外部メモリ2006へのアクセスが少ない処理に置き換える。なお、置換処理で置換する処理は、処理の整合性を保つために機能的に等価であるが、外部メモリ2006へのアクセスが少ない処理が望ましい。
第2の実施の形態では、上述のコンパイラが追加した等価処理、記憶処理、使用状況判定処理、置換処理により、使用状況監視処理の過程およびソフトウェア処理変更処理の過程を実現する。つまり、使用状況監視処理の過程とは、記憶処理により処理時間"task_time"を記憶しており、使用状況判定処理へ処理時間"task_time"を出力する。ソフトウェア処理変更処理の過程とは、識別した処理を等価処理へ置き換える置換処理であり、使用状況監視処理の過程から出力される処理時間に基づいてバス競合を判定し、バス競合が発生していれば処理の置き換えを行う。
ここで、本実施の形態によるバス競合の判定フローを図12に示す。処理識別手段2201で識別した処理に対し、前回識別した処理を実行した際の処理時間"task_time"と設定値"DEFINED_TIME"を比較する。処理時間"task_time"が設定値"DEFINED_TIME"以上の場合には、使用状況判定処理はバス競合が発生中であると判定し、等価処理への置き換えを行う。逆に処理時間"task_time"が設定値"DEFINED_TIME"よりも小さい場合には、使用状況判定処理はバス競合が発生していないと判定し、処理識別手段2201で識別した処理を、処理時間"task_time"の記憶を行いながら実行する。
ここで、「前回識別した処理を実行した際の処理時間」とは、2つ考えられる。1番目の処理時間は、処理識別手段2201で識別した処理の中で、現時刻から1回前に記録した処理時間、つまり、記録した処理時間の中で最も新しいものが該当する。2番目の処理時間は、現時刻で識別した処理と同一の処理を過去に実行したときに記録した処理時間が該当する。1番目の処理時間では、処理時間は常に最新のものを1つだけ記憶するが、2番目の処理時間では、識別された処理毎に処理時間を記憶する必要がある。
以上、本実施の形態では、処理時間"task_time"と設定値"DEFINED_TIME"の比較結果より、バス競合が発生中か否かを判定し、バス競合が発生中と判定された場合は、外部メモリ2006へ頻繁にアクセスする処理を外部メモリ2006へのアクセスが少ない処理に自動で置換する。その結果、動的にバス競合を判定しながら自動で処理の割り当てを行うことができるとともに、新たなバス競合を避けることができ、処理速度の低下を防止できる。なお、第2の実施の形態における上記の発明内容を後述の発明と区別するために第1の手法とする。
さらに、第2の手法としての使用状況判定処理においては、バス調停回路2005から出力された競合情報である処理時間"task_time"と事前に設定しておいた設定値"DEFINED_TIME"との比較結果に加えて、乱数を使用することでバス競合の判定を行う。
図13は、処理時間"task_time"と設定値"DEFINED_TIME"の比に対する等価処理への置き換えを行う確率を示している。処理時間"task_time"が設定値"DEFINED_TIME"よりも小さい場合、言い換えれば、図13で処理時間"task_time"と設定値"DEFINED_TIME"の比が1より小さい場合、使用状況判定処理は第1の手法と同様にバス競合が発生していないと判定し、等価処理の置き換えを行わない。
しかし、処理時間"task_time"が設定値"DEFINED_TIME"以上の場合、言い換えれば、図13で処理時間"task_time"と設定値"DEFINED_TIME"の比が1以上の場合、図13の確率に従って等価処理への置き換えを行ったり、あるいは等価処理への置き換えは行わずに、処理時間を再計測し記憶する。これは、処理時間"task_time"が設定値"DEFINED_TIME"以上の場合、第1の手法では必ずバス競合が発生中と判定していたが、第2の手法では乱数を用いた確率に応じてバス競合を判定するので、第1の手法とは逆の判定結果を出力する可能性を持たせた。逆の判定結果とは、バス競合が発生していないという判定結果である。
そして、本実施の形態では図12に示すバス競合判定フローに従い、処理時間を再度記録することになる。つまり、バス競合の判定に乱数を加えることで判定を見直しする。これにより、実際にはバス競合が解消されたにもかかわらず、使用状況判定処理はバス競合がそのまま継続されている、といった間違った判断を避けることができる。
第2の手法は一連の処理の中でバス競合が頻繁に発生するシステムに対して有効である。なお、図13では、処理時間"task_time"と設定値"DEFINED_TIME"の比が大きければ大きいほど、つまり、処理時間"task_time"が設定値よりも大きな値をとればとるほど等価処理へ置き換える確率が小さくなっている。これは、処理時間"task_time"が長ければ長いほど近い未来にバス競合は解消されるということが一般的に考えられるからである。
なお、図13の発生確率の値については、対象システムの仕様に応じて適当な値を与える必要がある。
以上、第2の手法により使用状況判定処理におけるバス競合の判定精度を向上できる。
なお、本実施の形態の第2の手法では、バス競合の判定について乱数を用いた確率を使用したが、乱数を用いないバス競合の判定も考えられる。例えば、バス競合時における処理時間の平均値または最大値などの定数があらかじめ既知であれば、バス競合中と判定されてから一定周期ごとに処理時間の再計測及び記録を行うことも可能である。
次に、第3の手法について説明する。
外部メモリ2006へ頻繁にアクセスする処理が複数の箇所に存在する場合、その処理の呼び出し元(出現箇所)別にバス競合を判定すれば判定精度は向上する。第3の方法では、処理識別手段2201で識別した処理の出現箇所毎に処理時間を記憶し、それを使用することでバス競合の判定を高精度に行う。
図8のソフトウェア処理システムでは、複数の処理が記述された関数を実行する際には、現在のプログラムカウンタを退避レジスタに一時的に退避させた後、関数の処理を実行し、関数の処理が終了した後、退避レジスタからプログラムカウンタを読み出してプログラムカウンタを元の値に戻す操作を行う。第3の手法では、出現箇所識別処理が上述の退避レジスタからプログラムカウンタを読み出すことで処理識別手段2201で識別した処理の出現箇所を特定する。
図12の判定フローをもつ第1の手法に、さらに出現箇所識別処理を追加した場合のバス競合の判定フローを図14に示す。
まず、処理識別手段2201で識別された処理に対し、出現箇所識別処理により処理の出現箇所を調査する。上述したように退避レジスタを参照することで、出現箇所の特定は可能である。次に、出現箇所毎に記憶した処理時間を参照する。次に、出現箇所毎に記憶した処理時間を設定値と比較することでバス競合が発生中か否かを判定し、バス競合が発生中であれば等価処理に置き換えて処理を実行し、バス競合が発生していなければ、処理時間を記憶しながら識別した処理をそのまま実行する。なお、出現箇所毎に処理時間を記憶する部分に処理時間が記憶されていない場合は、バス競合が発生していないと判定されたとみなし、処理時間を計測しながら処理識別手段2201で識別された処理を実行し、計測した処理時間を新規に記憶する。
第3の手法は、ループ処理など同一の処理が繰り返して処理される場合、出現箇所別に判定した処理時間を参照することでバス競合の判定精度が向上する。
なお、本実施の形態における処理時間"task_time"を、第1の実施の形態の使用状況監視装置に記憶することでバス競合の判定を行うことも可能である。このときのバス競合の判定フローを図15に示す。処理時間を求めた後、第1の実施の形態における使用状況監視装置にも処理時間を記憶することにより、バス競合を動的に判定でき、バス競合に伴う処理速度の低下を防ぐことが可能である。
(第3の実施の形態)
図16は第3の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。図16において、ソフトウェア処理システムは、DSP4001とプロセッサ4002と、DSP使用状況監視装置4003と、DSP4001とプロセッサ4002で実行する処理である図17のオブジェクトコード4105を格納したメモリ4004で構成される。メモリ4004は、DSP4001とプロセッサ4002が処理を実行する際の共有メモリとして処理結果や処理データを記憶する。
図17は、本発明の第3の実施の形態にかかわるコンパイラの処理フローを示す。
図18は、本発明の第3の実施の形態にかかわるコンパイラによる処理の変更を示す。
図19は、本発明の第3の実施の形態にかかわるDSP競合の判定フローを示す。
図20は、本発明の第3の実施の形態にかかわるソフトウェア処理システムにおける処理の流れを示す。
第3の実施の形態によるソフトウェア処理システムを図16〜図20を用いて具体的に説明する。
図16では、プロセッサ4002はDSP4001を突き放し制御方式で制御しており、プロセッサ4002がメモリ4004から読み出したソフトウェアがDSP4001で実行する処理の場合は、プロセッサ4002はDSP4001へ処理要求を発行し、DSP4001は処理要求を受けた後、処理を実行する。ここで、DSP使用状況監視装置4003は、現在、DSP4001で処理が実行中か否かを記憶したレジスタ(記憶装置)であり、特定のアドレスが割り当てられているため、ソフトウェアの処理から読み出し可能である。
図17はソフトウェアのコンパイラのフローである。C言語などの処理記述言語で書かれたソースコード4102は、プロセッサ用ライブラリ4103とDSP用ライブラリ4104を用いて、オブジェクトコード4105に変換される。その結果、オブジェクトコード4105には実行に必要なプロセッサ用ライブラリ4106とDSP用ライブラリ4107が含まれる。
本実施の形態のコンパイラは、処理記述言語からオブジェクトコードを生成する通常のコンパイラの機能の他に、ソースコード4102からDSP4001で実行する処理を識別する処理識別手段と、処理識別手段で識別した処理に対し特定の処理を付加する処理付加手段を備える。処理識別手段および処理付加手段による処理の変更を図18に示す(左の数字は行番号)。ここで、図18(a)の処理記述言語で書かれたソースコードは、処理識別手段を用いて、ソースコード4102からDSP4001で実行されるとして識別された処理を表している。つまり、関数"func1()"、"func2()"、"func3()"は全てDSP4001で実行される処理である。なお、DSP4001で実行する処理をあらかじめ処理識別手段に登録することでソースコードからDSP4001で実行する処理を識別可能である。
図18(b)の処理記述言語で書かれたソースコードは、処理付加手段で付加された処理を示す。なお、便宜上、図18(b)では、処理付加手段はfunc2のみに特定の処理を付加しているが、処理付加手段は、処理識別手段で識別した全ての処理に対して特定の処理を付加しており、func1,func3についてもfunc2と同様に特定の処理が付加される。
処理付加手段により付加される特定の処理とは、使用状況判定処理と置換処理である。使用状況判定処理とは、DSP4001が処理を実行中か否かをDSP使用状況監視装置4003を読み出すことで判定する処理である。図18(b)では、8行目の"if(DSPが待ち状態)"が使用状況判定処理に相当する。ここで待ち状態とは、DSP4001は処理を実行しておらず、プロセッサ4002からの処理要求を待っている状態を表す。図18(b)では9行目から11行目が相当し、func2の処理内容として、DSP用ライブラリ4104を使用した場合を"func2_dsp()"、プロセッサ用ライブラリ4103を使用した場合を"func2_cpu()"としている。図18では、置換後の処理としてプロセッサで同等の機能をもつ処理を行った場合を示す。
つまり、本実施の形態では、DSP4001を使用する処理を識別し、その処理を実行する前にDSP使用状況監視装置4003を観測することでDSP4001の状態を判定する。そして、判定結果を受けて、DSP4001が待ち状態であれば、そのままDSP4001で処理を実行するが、DSP4001が他の処理を実行中の場合は、DSP4001を使用しない他の処理に置換する。このようなソフトウェア処理変更処理により、DSP競合を避けることができる。参考として、図19に本実施の形態のDSP競合の判定フローを示す。
次に具体例として、本実施の形態のソフトウェア処理システムにおける処理の流れを図20に示す。
図20(a)は、DSP競合が発生しない場合における本実施の形態のソフトウェア処理システムの処理の流れである。ソフトウェアには、func0,func1,func2,func3,func4,func5,func6の処理があり、func0,func2,func4については、プロセッサ4002からDSP4001へ処理要求を発行し、それぞれDSP用ライブラリ4104を用いてfunc0_dsp,func2_dsp,func4_dspをDSP4001上で実行する。また、DSP4001とプロセッサ4002は共有メモリを用いて互いの処理結果を受け渡しており、func0_dspとfunc2_dspとfunc4_dspとfunc5は処理結果を共有メモリ4004に格納し、格納された処理結果は、func3とfunc5が処理を実行する際に読み出す。図20(a)のようにDSP競合が発生しない場合には、プロセッサ4002とDSP4001の資源を無駄なく使用しながら処理を実行する。
しかし、図20(b)のようにfunc0_dspの処理時間が長くなった場合、func1がfunc2_dspの処理要求を発行した場合、DSP競合が発生し、func0_dspが終了するまでfunc2_dspは処理を開始できない。その結果、func2_dspの処理結果を用いるfunc3も実行できなくなり、処理全体の速度が遅くなってしまう。
そこで、本実施の形態のソフトウェア処理システムでは、func1がfunc2_dspの処理要求を発行した際に、DSP使用状況監視装置4003を観測することでDSP競合を認識し、func2と等価な機能でありDSP4001でなくプロセッサ4002上で処理を行うfunc2_cpuをfunc2_dspの代わりに実行する。つまり、図20(b)では、DSP4001で実行する処理の処理要求を発行する際にDSP4001の状態を監視し、処理をDSP4001かプロセッサ4002に的確に割り振るソフトウェア処理変更処理を用いる。これによりDSP競合を防ぐことができ、処理速度の低下を防ぐ。さらに、処理を的確に割り当てて待ち状態のプロセッサ4002を使用することで、資源を効率的に使用可能である。
なお、本実施の形態のコンパイラの処理識別手段、処理付加手段により、処理サイクル数は増えるが、DSP使用状況監視装置4003以外、新規にハードウェアを追加することなく、DSP競合を避け、処理速度の低下を防止できる。
(第4の実施の形態)
第4の実施の形態によるソフトウェア処理システムを図21〜図28を用いて具体的に説明する。
図21は、第4の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。図21においてソフトウェア処理システムは、プロセッサ5001と、DSP5002と、プロセッサ5001とDSP5002で実行するソフトウェアを格納した記憶装置5003と、周辺回路5004と、バス調停回路5007と、外部メモリ5005と、共有バス5006と、調停回路5008と、使用状況監視装置5009で構成される。図21では、プロセッサ5001はDSP5002を突き放し制御方式で制御しており、プロセッサ5001が記憶装置5003から読み出したソフトウェアがDSP5002で実行すべき処理の場合はプロセッサ5001はDSP5002へ処理要求を発行し、DSP5002は処理要求を受けた後、処理を実行する。外部メモリ5005はプロセッサ5001、DSP5002が処理を実行する際に使用する共有メモリである。調停回路5008は、DSP5002で処理を実行中に新たな処理要求が発行された場合、すなわちDSP競合が発生した場合に、新たに発行された処理が実行できるか否かを判定する。また、使用状況監視装置5009はDSP5002の使用状況を監視し、要求に応じて使用状況を出力する。
ここで、調停回路5008の制御フローを図22に示す。図22において、5101はDSP5002で実行する処理の処理要求が発生したか否かを判定する処理要求判定手段であり、5102は現在、DSP5002がプロセッサ5001からの処理要求を待っている待ち状態か否かを判定するDSP状態判定手段であり、5103は処理要求に対しDSP5002での処理の実行を促すDSP使用許可手段であり、5104は処理が終了したか否かを判定する処理終了判定手段である。DSP5002で処理を実行中に新たなDSP5002への処理要求が発生した場合、つまり、DSP競合が発生した場合、調停回路5008は、一旦、処理要求を受理し、実際の処理に関しては先の処理が終了するまで待機(wait)状態となる。DSP5002で実行する処理が頻繁に発生すると、DSP競合が発生し、調停回路5008により処理が待機(wait)状態となる。その結果、ソフトウェア処理システム全体の処理速度が低下する。そこで第4の実施の形態では、DSP競合を避け、処理速度の低下を防ぐ。
図23は、本発明の第4の実施の形態におけるソフトウェアのコンパイラの処理フロー図を示す。コンパイラは、まず、処理識別手段5201としてDSP5002で実行する処理を識別する。これは、処理識別手段5201がDSP5002で実行する処理をあらかじめ認識していれば可能である。次に、識別した処理に対して、これと機能的には等価であるが、プロセッサ5001で実行する処理である等価処理があらかじめライブラリ等で用意されているか否かを判定する。もし用意されていれば、コンパイラは処理識別手段5201で識別した処理に対して等価処理、記憶処理、使用状況判定処理、置換処理を追加する。ここで記憶処理とはDSP5002で実行処理の処理要求が発行されてから処理が開始するまでの待ち時間を記録する処理であり、使用状況判定処理とは記憶処理で記憶した使用状況の情報からDSP競合が発生しているか否かを判定する処理であり、置換処理とは処理識別手段5201で識別した処理を等価処理へ置き換える処理を示す。
図24は、図23の処理フローをもつコンパイラを使用したときのDSP5002で実行する処理に対する変更を示す図である。図24では、DSP5002で実行する処理を関数"dsp_task()"とし、この等価処理を"proc_dsptask()"としている。コンパイラは、あらかじめDSP5002で実行する処理を登録することで処理識別手段5201を用いてソフトウェアの中から関数"dsp_task()"を識別する。次に、コンパイラは処理識別手段5201で識別した処理に対して上記の等価処理、記憶処理、使用状況判定処理、置換処理を付加する。
まず、図24(b)の2行目では、ソフトウェアに使用状況判定処理を付加する。ここで"wait_time"はプロセッサ5001がDSP5002で実行する処理の処理要求を発行してから処理が開始するまでの待ち時間であり、"DEFINED_TIME"はあらかじめ設定された設定値である。待ち時間"wait_time"は、過去に発生したDSP5002で実行する処理の待ち時間を表しており、現時刻に発生するDSP5002で実行する処理要求を発行する前に"wait_time"を参照し、設定値である"DEFINED_TIME"と比較することでDSP競合を判定する。DSP競合が発生中と判定された場合、図22の制御フローに従う調停回路5008では、DSP競合の発生時に処理を待機状態とするため、そのときの待ち時間は長くなる。つまり、DSP5002で実行する処理の待ち時間がある程度大きくなるとDSP競合が発生したと推定できる。なお、設定値については、ソフトウェア処理システムの仕様に応じて的確な値を設定するのが望ましい。
次に、図24(b)の3行目から6行目は、記憶処理を示す。使用状況判定処理によりDSP競合が発生していないと推定された場合、処理要求を発行した時点と"dsp_task()"の実行が開始される時点のタイマーの値を参照し、その差を算出することで待ち時間"wait_time"を算出している。
図24(b)の9行目から11行目は、置換処理を示す。使用状況判定処理によりDSP競合が発生していると推定された場合、さらに、DSP競合を発生させることを防ぐため、プロセッサ5001で実行する等価処理に置き換える。なお、置換処理で置換する処理は、処理の整合性を保つために機能的に等価であるが、DSP5002で実行しない処理が望ましい。
第4の実施の形態では、上述のコンパイラが追加した等価処理、記憶処理、使用状況判定処理、置換処理により、使用状況監視処理の過程およびソフトウェア処理変更処理の過程を実現する。つまり、使用状況監視処理の過程とは、記憶処理により待ち時間"wait_time"を記憶しており、使用状況判定処理へ待ち時間"wait_time"を出力する。ソフトウェア処理変更処理の過程とは、識別した処理を等価処理へ置き換える置換処理であり、使用状況監視装置から出力される待ち時間に基づいてDSP競合を判定し、DSP競合が発生していれば処理の置き換えを行う。
ここで、本本実施の形態によるDSP競合の判定フローを図25に示す。処理識別手段5201で識別した処理に対し、前回識別した処理を実行した際の待ち時間"wait_time"と設定値"DEFINED_TIME"を比較する。待ち時間"wait_time"が設定値"DEFINED_TIME"以上の場合には、使用状況判定処理はDSP競合が発生中であると判定し、等価処理への置き換えを行う。逆に待ち時間"wait_time"が設定値"DEFINED_TIME"よりも小さい場合には、使用状況判定処理はDSP競合が発生していないと判定し、処理識別手段5201で識別した処理を待ち時間"wait_time"を記憶しながら実行する。
ここで「前回識別した処理を実行した際の待ち時間」とは、2つ考えられる。1番目の待ち時間は処理識別手段2201で識別した処理の中で、現時刻から1回前に記録した待ち時間、つまり、記録した待ち時間の中で最も新しいものが該当する。2番目の待ち時間は、現時刻で識別した処理と同一の処理を過去に実行したときに記録した待ち時間が該当する。1番目の待ち時間では、待ち時間は常に最新のものを1つだけ記憶するが、2番目の待ち時間では、識別された処理毎に待ち時間を記憶する必要がある。
以上、本実施の形態では、待ち時間"wait_time"と設定値"DEFINED_TIME"の比較結果より、DSP競合が発生中か否かを判定し、DSP競合が発生中と判定された場合は、DSP5002で実行する処理をプロセッサ5001で実行する処理に自動で置換する。その結果、動的にDSP競合を判定しながら自動で処理の割り当てを行うことができるとともに、新たなDSP競合を避けることができ、処理速度の低下を防止できる。なお、第4の実施の形態における上記の発明内容を後述の発明と区別するために第4の手法とする。
さらに、第5の手法としての使用状況判定処理においては、使用状況監視装置から出力される競合情報である待ち時間"wait_time"と事前に設定しておいた設定値"DEFINED_TIME"との比較結果に加えて、乱数を使用することでDSP競合の判定を行う。
図26は、待ち時間"wait_time"と設定値"DEFINED_TIME"の比に対する等価処理への置き換えを行う確率を示している。待ち時間"wait_time"が設定値"DEFINED_TIME"よりも小さい場合、言い換えれば、図26で待ち時間"wait_time"と設定値"DEFINED_TIME"の比が1より小さい場合、使用状況判定処理は第4の手法と同様にDSP競合が発生していないと判定し、等価処理の置き換えを行わない。
しかし、待ち時間"wait_time"が設定値"DEFINED_TIME"以上の場合、言い換えれば、図26で待ち時間"wait_time"と設定値"DEFINED_TIME"の比が1以上の場合、図26の確率に従って等価処理への置き換えを行ったり、あるいは等価処理への置き換えは行わずに待ち時間を再計測し記憶する。これは、処理時間"wait_time"が設定値"DEFINED_TIME"以上の場合、第4の手法では必ずDSP競合が発生中と判定していたが、第5の手法では乱数を用いた確率に応じてDSP競合を判定するので、第4の手法とは逆の判定結果を出力する可能性を持たせた。逆の判定結果とは、DSP競合が発生していないという判定結果である。
そして、本実施の形態では図25に示すDSP競合判定フローに従い、待ち時間を再度記録することになる。つまり、DSP競合の判定に乱数を加えることで判定を見直しする。これにより、実際にはDSP競合が解消されたにもかかわらず、使用状況判定処理はDSP競合がそのまま継続されている、といった間違った判断を避けることができる。
第5の手法は一連の処理の中でDSP競合が頻繁に発生するシステムに対して有効である。なお、図26では、待ち時間"wait_time"と設定値"DEFINED_TIME"の比が大きければ大きいほど、つまり、待ち時間"wait_time"が設定値よりも大きな値をとればとるほど等価処理へ置き換える確率が小さくなっている。これは、待ち時間"wait_time"が長ければ長いほど近い未来にDSP競合は解消されるということが一般的に考えられるからである。
なお、図26の発生確率の値については、対象システムの仕様に応じて適当な値を与える必要がある。
以上、第5の手法により使用状況判定処理におけるDSP競合の判定精度を向上できる。
なお、本実施の形態の第5の手法では、DSP競合の判定について乱数を用いた確率を使用したが、乱数を用いないDSP競合の判定も考えられる。例えば、DSP競合時における待ち時間の平均値または最大値などの定数があらかじめ既知であれば、DSP競合中と判定されてから一定周期ごとに待ち時間の再計測及び記録を行うことも可能である。
次に、第6の手法について説明する。
DSP5002で実行する処理が複数の箇所に存在する場合、その処理の呼び出し元(出現箇所)別にDSP競合を判定すれば判定精度は向上する。第6の方法では、処理識別手段5201で識別した処理の出現箇所毎に待ち時間を記憶し、それを使用することでDSP競合の判定を高精度に行う。
図21のソフトウェア処理システムでは、複数の処理が記述された関数を実行する際には、現在のプログラムカウンタを退避レジスタに一時的に退避させた後、関数の処理を実行し、関数の処理が終了した後、退避レジスタからプログラムカウンタを読み出してプログラムカウンタを元の値に戻す操作を行う。第6の手法では、出現箇所識別処理が上述の退避レジスタからプログラムカウンタを読み出すことで処理識別手段5201で識別した処理の出現箇所を特定する。
図25の判定フローをもつ第4の手法に、さらに出現箇所識別処理を追加した場合のDSP競合の判定フローを図27に示す。
まず、処理識別手段5201で識別された処理に対し、出現箇所識別処理により処理の出現箇所を調査する。上述したように退避レジスタを参照することで、出現箇所の特定は可能である。次に、出現箇所毎に記憶した待ち時間を参照する。次に、出現箇所毎に記憶した待ち時間を設定値と比較することでDSP競合が発生中か否かを判定し、DSP競合が発生中であれば等価処理に置き換えて処理を実行し、DSP競合が発生していなければ待ち時間を記憶しながら識別した処理をそのまま実行する。なお、出現箇所毎に記憶した待ち時間に待ち時間が記憶されていない場合は、DSP競合が発生していないと判定されたとみなし、待ち時間を計測しながら処理識別手段5201で識別された処理を実行し、計測した待ち時間を新規に記憶する。
第6の手法は、ループ処理など同一の処理が繰り返して処理される場合、出現箇所別に判定した待ち時間を参照することでDSP競合の判定精度が向上する。
なお、本実施の形態における待ち時間"wait_time"を、第3の実施の形態の使用状況監視装置に記憶することでDSP競合の判定を行うことも可能である。このときのDSP競合の判定フローを図28に示す。待ち時間を求めた後、第1の実施の形態における使用状況監視装置にも待ち時間を記憶することにより、DSP競合を動的に判定でき、DSP競合に伴う処理速度の低下を防ぐことが可能である。
(第5の実施の形態)
図29は第5の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。図29において、ソフトウェア処理システムは、DSP7001とプロセッサ7002と、DSP使用状況監視装置7003と、DSP7001とプロセッサ7002で実行する処理である図30のオブジェクトコードを格納したメモリ7004で構成される。メモリ7004は、DSP7001とプロセッサ7002が処理を実行する際の共有メモリとして処理結果や処理データを記憶する。
図30は第5の実施の形態にかかわるソフトウェア処理システムで実行するソフトウェアを示す。
図31は第5の実施の形態にかかわるDSP競合時の処理フローを示す。
図32は第5の実施の形態にかかわるソフトウェア処理システムにおける処理の流れを示す。
第5の実施の形態によるソフトウェア処理システムを図29〜図32を用いて具体的に説明する。
図29では、プロセッサ7002はDSP7001を突き放し制御方式で制御しており、プロセッサ7002はメモリ7004からソフトウェアをフェッチ、デコードし、DSP7001で実行する処理の場合、プロセッサ7002はDSP7001へ処理要求を発行することでDSP7001は処理を実行する。ここで、プロセッサ7002からDSP7001への処理要求の発行について、さらに詳しく説明する。
プロセッサ7002は、まず、DSP7001にあるコマンドバッファに処理コマンドおよび処理を行うのに必要なデータを書き込む。データ書き込みの終了後、プロセッサ7002はDSP7001へ処理の開始要求を発行し、それを受けたDSP7001は、コマンドバッファから処理コマンド、データを読み出すことで処理が実行される。つまり、第5の実施の形態において、プロセッサ7002からDSP7001への処理要求とは、DSP7001のコマンドバッファへの処理コマンド、データの書き込みおよび処理の開始要求の発行という一連の動作を意味する。
また、図29におけるDSP7001の使用状況監視装置7003は、DSP7001が現在処理を実行中か否かを監視するとともに、プロセッサ7002がDSP7001のコマンドバッファへ処理コマンドおよびデータの書き込みを行うか否かを監視する。そして、DSP7001が任意の処理を実行中にプロセッサ7002が処理要求を発行するためにDSP7001へのコマンドバッファへの書き込みを行った場合、DSP使用状況監視装置7003はプロセッサ7002へ割り込み信号を与える。DSP使用状況監視装置7003からの割り込み信号を受けたプロセッサ7002は、割り込みルーチンに分岐し、プロセッサ7002からDSP7001への処理の開始要求の発行を止める。その結果、DSP7001のコマンドバッファへは処理コマンド、データが格納されているが、DSP7001への処理の開始要求が止められるため、DSP7001は新たに処理を実行しない。つまり、割り込み信号により新規のDSP7001の処理要求がキャンセルされる。
さらに、割り込み信号を受けたプロセッサ7002は、DSP7001で実行する処理の代わりに代替処理を行う。ここで代替処理とは、DSP7001を使用しない処理であり、本実施の形態ではDSP7001で実行する予定だった処理と機能的には等価で、プロセッサ7002上で実行する処理とする。
以上の割り込み信号に対する動作を実現するために、本実施の形態のソフトウェア処理システムでは、DSP7001で実行する処理に対し、それと機能的に等価であるが、プロセッサ7002で実行する処理をそれぞれ用意する。そして、DSP使用状況監視装置7003による割り込み信号を受けた場合、プロセッサ7002はDSP7001への処理要求を止め、等価な処理をプロセッサ7002自身で代わりに実行する。
図30に本実施の形態のソフトウェア処理システムにおけるソフトウェアを示す(左の数字は行番号)。main関数の中にfunc1,func2,func3,func4,func5,func6,func7,func8があり、その中でDSP7001で実行する処理は、func2,func4,func6である。ソフトウェアにはプロセッサ7002上で実行する処理であるプロセッサ用ライブラリと、DSP7001上で実行する処理であるDSP用ライブラリが含まれており、図30におけるfunc2,func4,func6については、それぞれfunc2_dsp,func4_dsp,func6_dspというDSP用ライブラリを用いてDSP7001上で処理を実行できるし、func2_cpu,func4_cpu,func6_cpuというCPU用ライブラリを用いてプロセッサ7002上でも実行可能とする。
図31は、図30のソフトウェアを実行した際のDSP競合時の処理フローであり、先に説明したようにDSP7001が他の処理を実行中にDSP7001に対して新規に処理要求が発行されようとしている場合、プロセッサ7002へ割り込み信号を与え、DSP用ライブラリを使用する処理をCPU用ライブラリを使用する処理に置き換える。
図32は、本実施の形態のソフトウェア処理システムにおいて図30のソフトウェアを実行したときの処理の流れを示している。
図32(a)はDSP7001のタスクが競合しない場合を示す。プロセッサ7002でのfunc1を実行する。プロセッサ7002はfunc1を実行後、DSP7001に対しfunc2の処理要求を発行し、DSP7001ではfunc2_dspを実行する。一方、プロセッサ7002はfunc3を実行する。DSP7001はfunc2を実行後、処理結果をメモリ7004に書き込む。なお、メモリ7004はプロセッサ7002、DSP7001からアクセス可能な共有メモリである。プロセッサ7002でfunc3を実行後、DSP7001でfunc4の処理要求を発行し、DSP7001でfunc4_dspを実行し、プロセッサ自身はfunc5を実行する。DSP7001はfunc4を実行後、処理結果をメモリ7004に書き込む。プロセッサ7002はfunc5を実行後、DSP7001でfunc6の処理要求を発行し、DSP7001でfunc6_dspを実行し、プロセッサ自身はfunc7を実行する。DSP7001はfunc6を実行後、処理結果をメモリ7004に書き込む。プロセッサ7002は、以上の処理結果をメモリ7004から読み取り、func8を処理する。以上、図32(a)ではDSP7001のタスクが競合しないためプロセッサ7002とDSP7001の資源を効率良く使用できる。
図32(b)では、DSP7001のタスクが競合する場合を示す。ここではfunc2_dspが終了しないうちに、プロセッサ7002からfunc4の処理要求を発行され、DSP競合が起きている。その結果、func4の処理はfunc2_dspが終了するまで停止させられるのでシステムの処理速度が低下する。
そこで本実施の形態では、DSPの使用状況監視装置7003がDSP競合を判定し、func4の処理要求を発行しようとするプロセッサ7002へ割り込み信号を発生させる。それを受けたプロセッサ7002は、自身が実行中のfunc5を中断し、func4をCPU用ライブラリであるfunc4_cpuを用いてCPU上で処理し、メモリ7004に処理結果を書き込む。その後、プロセッサ7002は中断していたfunc5を再開する。
このように、本実施の形態のソフトウェア処理システムでは、処理を実行しながらDSP競合を判定し、処理をDSP7001かプロセッサ7002に的確に割り振ることによって、DSP競合を避け、処理速度の低下を防ぐ。さらに、DSPの使用状況監視装置7003というハードウェアで処理することによって、割り込みルーチンを用意することを除いてソースコード4102に対する記述の修正、追加がないため、アセンブラやオブジェクトコードで提供された場合にも対応できる。
(第6の実施の形態)
以下、本発明の第6の実施の形態を図面に基づいて説明する。
図33は、本発明の第6の実施の形態にかかわるソフトウェア処理システムのハードウェアの構成を示すブロック図である。
図33において、8001はCPU、8002はDSP、8003はバス、8004は外部メモリ、8005は周辺回路、8006はCPU8001が持つメモリ、8007はメモリ8006中のバンク形式であるDSP8002用のメモリバンク、8008はメモリ8006中のバンク形式であるCPU8001用のメモリバンク、8009はDSP8002が処理を行っているかどうかを監視する使用状況監視装置、8010はDSP用メモリバンク8007とCPU用メモリバンク8008とを切り替えるバンク切り替え装置である。
図34は、本発明の第6の実施の形態にかかわるソフトウェア処理システムのソフトウェアの構成を示す図である。
図34において、8101はCPU8001およびDSP8002上で動作するプログラム、8102,8103,8104はプログラム8101中に記述され、DSP8002を使用するコマンドを含んでライブラリ化された処理、8105,8106,8107は処理8102,8103,8104とそれぞれ同等の機能を持つ、CPU8001を使用するコマンドを含んでライブラリ化された処理である。
図35は、本発明の第6の実施の形態にかかわるソフトウェア処理システムにおけるコンパイルフローを示すフローチャートである。
図35において、8201はプログラム8101をコンパイルするコンパイル手段、8202はDSP8002で行われる処理を識別する処理識別手段、8203はDSP用メモリバンク8007またはCPU用メモリバンク8008にマッピングするマッピング手段である。
以上のように構成した本実施の形態の動作について説明する。
なお、図36は、本発明の第6の実施の形態にかかわるソフトウェア処理システムにおけるメモリバンクへのソフトウェアのマッピングを示す図である。
本実施の形態において、DSP8002はCPU8001からの処理要求を受付けることにより処理を実行し、CPU8001とDSP8002との間の制御方式は突き放し制御方式である。プログラム8101に記述される処理func1,func2,func3は、DSP8002またはCPU8001を使用するコマンドを含み、手順として処理func1、処理func2、処理func3の順番であって、それぞれの処理にはデータ依存がないものとする。
プログラム8101が、コンパイラが有するコンパイル手段8201によってコンパイルされる際、処理識別手段8202によってDSP8002を使用するコマンドを含んだ処理である処理func1,func2,func3を識別し、図36に示すように、メモリバンクのマッピング手段8203によって、DSP用メモリバンク8007にはDSP8002用のライブラリ化された処理8102,8103,8104がマッピングされる。同様に、CPU用メモリバンク8008にはCPU8001用のライブラリ化された処理8105,8106,8107がマッピングされる。このとき、処理8102と処理8105は同じアドレス番地を開始アドレスとする。処理8103と処理8106、処理8104と処理8107についても同様である。このようにコンパイラは同じ名前である別々のプロセッサ用の処理を認識してコンパイルすることが可能であるという特徴を持つ。
プログラム8101が処理される際、最初に処理func1が行われるとする。処理func1が呼び出され、処理func1がマッピングされている開始アドレスの命令がCPU8001によってフェッチされた瞬間に、バンク切り替え装置8010によってバンク切り替えのロックが実行される。このロックの実行によって、他の処理によるバンク切り替えが実行できないようになる。また、DSP8002が処理を行っているかどうかの情報が使用状況監視装置8009によって識別されていて、その情報はバンク切り替え装置8010への入力信号となり、バンク切り替え装置8010によってメモリ8006へバンク切り替えを実行するための要求が行われている。
まず、DSP8002が他の処理を行っていない場合、バンク切り替えは、表側がDSP用メモリバンク8007であり、裏側がCPU用メモリバンク8008である。先ほどのバンク切り替えのロックによって、このバンク切り替えの状態は維持される。バンク切り替えのロックが実行されている間は、バンク切り替えの表側がDSP用メモリバンク8007になっているので、CPU8001はDSP用メモリバンク8007から処理8102を取り出す。処理8102にはDSP8002を使用するコマンドが含まれていて、CPU8001によって、このDSP8002を使用するコマンドが発行され、DSP8002によって処理が行われる。DSP8002は突き放し制御であるので、このコマンドの処理が終了する時間を特定することはできない。処理func1の呼び出し元であるプログラム8101のmain関数へ戻る際、このmain関数へ戻る命令がCPU8001によってフェッチされた瞬間に、バンク切り替え装置8010によってバンク切り替えのアンロックが実行される。そして、メモリ8006へのバンク切り替え要求が受け付けられ、結果として、表側がCPU用メモリバンク8008となり、裏側がDSP用メモリバンク8007となる。
これとは逆の場合、つまり、処理func1が呼び出された際、DSP8002が他の処理を行っていた場合、バンク切り替えは、表側がCPU用メモリバンク8008であり、裏側がDSP用メモリバンク8007である。バンク切り替えのロックが実行されているので、このバンク切り替えの状態はアンロックが実行されるまで維持される。DSP8002が他の処理のよって使用されているので、バンク切り替え装置8010はメモリ8006へ、バンク切り替えを表側がCPU用メモリバンク8008、裏側がDSP用メモリバンク8007となるように要求することになる。
バンク切り替えは表側がCPU用メモリバンク8008となっているので、CPU8001はCPU用メモリバンク8008から処理8105を取り出す。処理8105は、DSP8002を使用するコマンドを含んだ処理8102と同等の機能を持っていて、CPU8001を使用するコマンドを含んでいるので、CPU8001によって処理が行われる。処理8105の処理が終了し、処理func1の呼び出し元であるプログラム8101のmain関数へ戻る際、このmain関数へ戻る命令がCPU8001によってフェッチされた瞬間に、バンク切り替え装置8010によってバンク切り替えのアンロックが実行される。そして、メモリ8006へのバンク切り替え要求が受け付けられ、結果として、表側がCPU用メモリバンク8008となり、裏側がDSP用メモリバンク8007となる。CPU8001が処理8105を行っている間に、DSP8002を使用していた他の処理が終了した場合は、使用状況監視装置8009の出力を受けて、バンク切り替え装置8010が、バンク切り替えの表側をDSP用メモリバンク8007とし、裏側をCPU用メモリバンク8008とする要求を行うことになる。しかし、この要求が受け付けられてバンク切り替えが実行されるのは、前述と同様にバンク切り替えのアンロックが実行されてからである。
次に、処理func1のDSP8002を使用する処理8102中のコマンドが、DSP8002によって処理が行われている間、次の処理である処理func2が呼び出されたとする。このとき、DSP8002は使用中であり、先ほどのバンク切り替えのアンロックはバンク切り替え装置8010によって実行されているので、バンク切り替えは表側がCPU用メモリバンク8008となり、裏側がDSP用メモリバンク8007となっている。処理func2が呼び出され、処理func2がマッピングされている開始アドレスの命令がCPU8001によってフェッチされた瞬間に、バンク切り替え装置8010によってバンク切り替えのロックが実行される。このロックの実行によって、他の処理によるバンク切り替えが実行できないようになる。
バンク切り替えは表側がCPU用メモリバンク8008となっているので、CPU8001はCPU用メモリバンク8008から処理8106を取り出す。処理8106は、DSP8002を使用するコマンドを含んだ処理8103と同等の機能を持っていて、CPU8001を使用するコマンドを含んでいるので、CPU8001によって処理が行われる。処理8106の処理が終了し、処理func2の呼び出し元であるプログラム8101のmain関数へ戻る際、このmain関数へ戻る命令がCPU8001によってフェッチされた瞬間に、バンク切り替え装置8010によってバンク切り替えのアンロックが実行される。そして、メモリ8006へのバンク切り替え要求が受け付けられ、結果として、表側がCPU用メモリバンク8008となり、裏側がDSP用メモリバンク8007となる。CPU8001が処理8106を行っている間に、DSP8002を使用していた処理8102中のコマンドが終了した場合は、先ほどの処理func1の処理を行う際にDSP8002が使用中であった場合と同様に、バンク切り替え装置8010によってメモリ8006へバンク切り替えの要求が行われ、バンク切り替えのアンロックが実行されてから、この要求が受け付けられることになる。
最後に処理func3が呼び出される。先ほどのDSP8002が使用中でない場合の処理func1の場合と同様に、バンク切り替え装置8010によって、バンク切り替えのロック、バンク切り替え要求が行われ、DSP用メモリバンク8007からDSP8002を使用するコマンドを含んだ処理8104がCPU8001によって取り出され、DSP8002を使用するコマンドは突き放し処理としてDSP8002によって実行される。プログラム8101のmain関数へ戻る際のバンク切り替えのアンロックの実行、バンク切り替えの表側をCPU用メモリバンク8008とし、裏側をDSP用メモリバンク8007とするバンク切り替えの実行についても同様である。
以上のように本実施の形態によれば、バンク切り替え装置8010を用いた方法によって、DSP8002におけるDSP競合の発生を軽減し、DSP8002を効率良く使用することが可能となる。この方法を実現するために、プログラム8101を修正する必要がなくそのまま適用できるので、ソフトウェアのオーバーヘッドがほとんどない。また、使用状況監視装置8009およびバンク切り替え装置8010という専用のハードウェアを用いることによって、バス8003の使用状況の監視およびソフトウェア処理変更を比較的高速に実現することができる。
なお、本実施の形態では、プロセッサを1つのCPU、リソースを1つのDSPとしたが、それぞれ複数のCPU、DSPでも良く、少なくとも1つのリソースとそのリソースを使用する少なくとも1つのプロセッサであれば良いものである。