(57)【要約】【課題】１つのチップの中に複数のＣＰＵコアがある場合でも、プログラムの順序どおりのステップ実行を行うことができるマルチプロセッサ、デバッグ装置およびデバッグ方法を提供する。【解決手段】ＣＰＵ２ａ、ＣＰＵ２ｂ、ＣＰＵ２ｃを内蔵したマルチプロセッサ１において、ステップ動作時にモニター状態に遷移させるために、ＣＰＵ２ａ、ＣＰＵ２ｂ、ＣＰＵ２ｃそれぞれの命令をデコーダ２１でデコードして、モニター状態に遷移可能な命令の場合はモニター遷移可能信号を出力し、全てのＣＰＵがモニター遷移可能信号を出力した場合に、各ＣＰＵをモニター状態に遷移させる。【選択図】図１
2010033323.tif 000002
【特許請求の範囲】
【請求項１】
ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサにおいて、
前記複数のＣＰＵそれぞれで実行している命令を監視する監視手段と、
前記ＣＰＵに前記ブレーク命令が入力されている際に、前記監視手段が全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させる遷移手段と、
を有していることを特徴とするマルチプロセッサ。
【請求項２】
前記遷移手段が、前記ＣＰＵに含まれていることを特徴とする請求項１に記載のマルチプロセッサ。
【請求項３】
前記複数のＣＰＵのうちから前記モニター状態に遷移するＣＰＵを選択する選択手段を有していることを特徴とする請求項１または２に記載のマルチプロセッサ。
【請求項４】
ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサと、前記マルチプロセッサをデバッグするデバッグ手段と、を有するデバッグ装置において、
前記複数のＣＰＵそれぞれで実行している命令を監視する監視手段と、
前記ＣＰＵに前記ブレーク命令が入力されている際に、前記監視手段が全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させる遷移手段と、
を有していることを特徴とするデバッグ装置。
【請求項５】
ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサをデバッグするデバッグ方法において、
前記複数のＣＰＵそれぞれで実行している命令を監視し、前記ＣＰＵに前記ブレーク命令が入力されている際に、全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させることを特徴とするデバッグ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
複数のＣＰＵ（Central Processing Unit）をコアとして内蔵したマルチプロセッサ及びそれをデバッグするデバッグ装置並びに前記マルチプロセッサをデバッグするデバッグ方法に関する。
【背景技術】
【０００２】
近年、ＬＳＩ（Large Scale Integration）の処理能力を向上させるために、１チップ内に複数のＣＰＵコアを内蔵するマルチプロセッサ構成を取るものが多くなってきた。複数のＣＰＵコアを含むプロセッサのデバッグにおいては、複数のＣＰＵコアが同期して動作しているため、それぞれのＣＰＵコアで実行しているプログラムの時系列に従ってデバッグを行うことが必要である。デバッグの際にはプログラマーの意図通り動作していないＣＰＵコアがある場合には、対象となるＣＰＵコアのプログラム上にブレークポイントを設定し、そこで各ＣＰＵコアをプログラム実行状態からモニター状態と呼ばれるデバッグモードに移行させ、その近傍で１命令ずつステップ実行動作を行わせながらレジスタやメモリに格納されている値をチェックしていくということが行われている。
【０００３】
複数のコアを同時にモニター状態へ移行させることに関しては、特許文献１ないし特許文献５などに開示されている。
【０００４】
また、マルチプロセッサ構成において、命令を１命令ずつ実行していくステップ実行については特許文献６に開示されている。特許文献６には、複数のＣＰＵコアの動作周波数が異なる場合に、周波数に反比例させた命令数を実行させることで複数のＣＰＵコアを同時にステップ実行可能としていることが記載されている。
【特許文献１】特開２００５−１２２３７５号公報
【特許文献２】特開２００７−１４１２００号公報
【特許文献３】特許第２７７４７７０号公報
【特許文献４】特開平１０−１９８５７８号公報
【特許文献５】特開平４−１１４２４１号公報
【特許文献６】特開２００６−５３８３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、ＲＩＳＣ（Reduced Instruction Set Computer）プロセッサにおいては遅延分岐や遅延ロードというパイプライン構成があり、この遅延分岐や遅延ロードはデスティネーションレジスタの更新が１サイクル以上遅延するために、ステップ実行している命令が遅延分岐もしくは遅延ロードを伴う命令である場合はプログラム通りにレジスタの値が更新しなくなるという問題がある。
【０００６】
上述した問題を図７ないし図９を参照して詳細に説明する。図７ないし図９は、最も代表的なプロセッサのパイプラインの流れを示している。つまり、命令フェッチ（Instruction Fetch）、命令デコード（Instruction Decode）およびレジスタ読み出し（Register Read）、演算（Execute）、メモリアクセス（Memory Access）、レジスタ書き込み（Write Back）の５段階で構成されている。
【０００７】
図７ないし図９のパイプラインを持つプロセッサにおいて、例えば、以下のような連続する３つの命令列がある場合を考える。
命令１：ＬＤ  ［ａｄｄ］，Ｒ０（メモリのアドレスａｄｄからデータをロードし、Ｒ０レジスタに格納する）
命令２：ＡＤＤ  Ｒ０，Ｒ１，Ｒ２（Ｒ０レジスタとＲ１レジスタの和をＲ２レジスタに格納する）
命令３：ＡＤＤ  Ｒ０，Ｒ３，Ｒ４（Ｒ０レジスタとＲ３レジスタの和をＲ４レジスタに格納する）
【０００８】
上述した命令列は、図７に示すように実行していくことになるが、命令１でＲ０レジスタに値が格納されるよりも前に命令２、命令３でＲ０レジスタの読み出しを行うため、データハザードと呼ばれるパイプライン障害が発生する。命令３ではメモリから読み出した値を直接ＡＬＵに供給するForwardingと呼ばれるバイパス経路を開いて対応するが、命令２は絶対に間に合わないため更新前の値をＲ０レジスタの値として演算を行うことになる。つまり命令１（ＬＤ命令）はデスティネーションレジスタの更新が１サイクルの遅延を持っている命令であると言える。ＲＩＳＣプロセッサでは動作速度の向上のために、この状況をプログラムのスケジューリングに委ね、ハードウェアでは解決しないということが行われている。これを遅延ロードと呼ぶ。つまりこの場合プログラマーは、命令２は命令１によって更新される前のＲ０レジスタの値を使って演算を行うことを期待してプログラムを作成しているということになる。
【０００９】
ここで命令１をステップ実行する場合を説明する。ステップ実行は、対象となる命令（この場合命令１）の次の命令（命令２）をデバッグ装置のホストコンピュータ上に退避しておき、これをソフトウェアブレーク命令（ＥＢＲＫ命令）に差し替えることで実現されるが、ステップ実行の場合は図８に示すように命令１はパイプラインの最後まで実行されて停止するために、次の命令２をステップ実行する際にはＲ０レジスタの値が更新されてしまい、プログラム通りにデバッグ出来ないことになる。遅延分岐の場合も同様にステップ実行がプログラム通りに行われない。
【００１０】
このような問題を回避するためにチップの中に１つしかＣＰＵコアがないプロセッサでは、ステップ実行の際に命令２をＥＢＲＫ命令に差し替えるのではなく、図９のように命令３をＥＢＲＫ命令に差し替えることでこの問題を回避している。
【００１１】
しかし１つのチップの中に複数のＣＰＵコアがあるようなマルチプロセッサにおいて、各コアが独立してこの回避策を取ってしまうと、遅延ロード、遅延分岐を含む命令を実行しているＣＰＵコアと、そうでないＣＰＵコアとで同時にステップ実行を行うことが出来ないという問題があった。
【００１２】
本発明はかかる問題を解決することを目的としている。
【００１３】
すなわち、本発明は、１つのチップの中に複数のＣＰＵコアがある場合でも、各ＣＰＵコアが同期してプログラムどおりの動作となるステップ実行を行うことができるマルチプロセッサ及びそれをデバッグするデバッグ装置並びに前記マルチプロセッサをデバッグするデバッグ方法を提供することを目的としている。
【課題を解決するための手段】
【００１４】
請求項１に記載された発明は、ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサにおいて、前記複数のＣＰＵそれぞれで実行している命令を監視する監視手段と、前記ＣＰＵに前記ブレーク命令が入力されている際に、前記監視手段が全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させる遷移手段と、を有していることを特徴とするマルチプロセッサである。
【００１５】
請求項２に記載された発明は、請求項１に記載された発明において、前記遷移手段が、前記ＣＰＵに含まれていることを特徴とするものである。
【００１６】
請求項３に記載された発明は、請求項１または２に記載された発明において、前記複数のＣＰＵのうちから前記モニター状態に遷移するＣＰＵを選択する選択手段を有していることを特徴とするものである。
【００１７】
請求項４に記載された発明は、ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサと、前記マルチプロセッサをデバッグするデバッグ手段と、を有するデバッグ装置において、前記複数のＣＰＵそれぞれで実行している命令を監視する監視手段と、前記ＣＰＵに前記ブレーク命令が入力されている際に、前記監視手段が全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させる遷移手段と、を有していることを特徴とするデバッグ装置である。
【００１８】
請求項５に記載された発明は、ブレーク命令によって実行状態からモニター状態に遷移し、同一周波数で動作するＣＰＵを複数有するマルチプロセッサをデバッグするデバッグ方法において、前記複数のＣＰＵそれぞれで実行している命令を監視し、前記ＣＰＵに前記ブレーク命令が入力されている際に、全ての前記ＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、前記複数のＣＰＵを前記モニター状態に遷移させることを特徴とするデバッグ方法である。
【発明の効果】
【００１９】
請求項１に記載の発明によれば、監視手段で複数のＣＰＵそれぞれで実行している命令を監視し、ＣＰＵにブレーク命令が入力されている際に、監視手段が全てのＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、複数のＣＰＵをモニター状態に遷移させているので、複数のＣＰＵの中でステップ実行中の命令が遅延分岐や遅延ロードなどモニター状態に移行することでプログラム通りの動きを再現できないような命令であるものが１つでもある場合には、モニター状態に移行せずに次の命令を実行するようにすることで、全てのＣＰＵが同期してモニター状態に遷移することができるので、プログラム通りの動きを再現できるステップ実行をすることができる。また、ハードウェアで制御しているので、ステップ実行時のデバッグ用ホストコンピュータの処理の負荷を軽減することができる。
【００２０】
請求項２に記載の発明によれば、遷移手段が、ＣＰＵに含まれているので、監視手段と遷移手段との間の配線が短くなり高速に動作させる際に有利となる。
【００２１】
請求項３に記載の発明によれば、複数のＣＰＵのうちからモニター状態に遷移するＣＰＵを選択する選択手段を有しているので、他のＣＰＵとの依存関係の無い物を除外することができ、それによってステップ実行を行う際の１ステップの命令数を少なくすることができる。
【００２２】
請求項４に記載の発明によれば、監視手段で複数のＣＰＵそれぞれで実行している命令を監視し、ＣＰＵにブレーク命令が入力されている際に、監視手段が全てのＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、複数のＣＰＵをモニター状態に遷移させているので、複数のＣＰＵの中でステップ実行中の命令が遅延分岐や遅延ロードなどモニター状態に移行することでプログラム通りの動きを再現できないような命令であるものが１つでもある場合には、モニター状態に移行せずに次の命令を実行するようにすることで、全てのＣＰＵが同期してモニター状態に遷移することができるので、プログラム通りの動きを再現できるステップ実行をすることができる。
【００２３】
請求項５に記載の発明によれば、複数のＣＰＵそれぞれで実行している命令を監視し、ＣＰＵにブレーク命令が入力されている際に、全てのＣＰＵがモニター状態に遷移可能な命令を実行していることを検出した場合は、複数のＣＰＵをモニター状態に遷移させているので、複数のＣＰＵの中でステップ実行中の命令が遅延分岐や遅延ロードなどモニター状態に移行することでプログラム通りの動きを再現できないような命令であるものが１つでもある場合には、モニター状態に移行せずに次の命令を実行するようにすることで、全てのＣＰＵが同期してモニター状態に遷移することができるので、プログラム通りの動きを再現できるステップ実行をすることができる。
【発明を実施するための最良の形態】
【００２４】
［第１実施形態］
以下、本発明の第１の実施形態を、図１ないし図３を参照して説明する。図１は、本発明の第１の実施形態にかかるマルチプロセッサのブロック図である。図２は、図１に示したマルチプロセッサの変形例を示したブロック図である。図３は、図１に示したマルチプロセッサのチップレイアウトの例を示した説明図である。
【００２５】
図１に示したマルチプロセッサ１は、ＣＰＵ２ａ、２ｂ、２ｃと、ブレーク生成装置３と、を備え、１チップのＬＳＩで構成されている。
【００２６】
ＣＰＵ（ＣＰＵコア、コアＣＰＵ或いは単にコアともいう）２ａは、デコーダ２１、ＡＮＤ回路２２、２３と、を備えている。また、ＣＰＵ２ａは、図示しないが、プログラム格納用のプログラムＲＡＭ、演算データ格納用のデータＲＡＭ、プログラムのアドレスを保持するプログラムカウンタ、プログラムＲＡＭから読み出した命令を格納する命令レジスタ、演算回路および各種レジスタも備えている。なお、ＣＰＵ２ｂ、２ｃも同様の構成である。また、ＣＰＵ２ａ、２ｂ、２ｃは同一周波数のクロックで動作する。
【００２７】
監視手段としてのデコーダ２１は、命令レジスタに格納された命令をデコードするデコーダであり、本実施形態では、モニター状態に遷移できる命令である場合はモニター遷移移行可能信号を出力する。モニター状態とは、プログラムを実行している状態である実行状態から遷移する状態であり、この状態でプログラムのステップ実行やデータメモリなどの読み出しなどのデバッグを行うことができる。また、モニター状態に遷移できる命令とは、ＣＰＵ２ａ、２ｂ、２ｃに実装されている命令のうち遅延ロード、遅延分岐を伴う命令以外の命令を示す。
【００２８】
遷移手段としてのＡＮＤ回路２２は、ＣＰＵ２ａ、２ｂ、２ｃのモニター遷移可能信号の論理積をとって、全てのモニター遷移可能信号がアクティブ（例えばハイレベル）になるとアクティブレベルの信号（例えばハイレベル）を出力する。
【００２９】
遷移手段としてのＡＮＤ回路２３は、後述するブレーク生成装置３から出力されるハードウェアブレーク信号とＡＮＤ回路２２の出力との論理積をとって、双方ともアクティブ（例えばハイレベル）になると出力であるモニター状態移行信号をアクティブ（例えばハイレベル）とする。
【００３０】
ブレーク生成装置３は、マルチプロセッサ１の外部などからの信号などによってハードウェアブレーク信号を生成し出力する。
【００３１】
次に、図１に示したマルチプロセッサ１におけるステップ動作を説明する。説明を平易にするためにＣＰＵ２ａ、２ｂをステップ実行する場合について説明することとし、一例として以下のプログラムでそれぞれ命令１をステップ実行する場合を考える。
【００３２】
ＣＰＵ２ａのプログラム
命令１：ＬＤ  ［ａｄｄ］，Ｒ０（メモリのアドレスａｄｄからデータをロードし、Ｒ０レジスタに格納する）
命令２：ＡＤＤ  Ｒ０，Ｒ１，Ｒ２（Ｒ０レジスタとＲ１レジスタの和をＲ２レジスタに格納する）
命令３：ＡＤＤ  Ｒ０，Ｒ３，Ｒ４（Ｒ０レジスタとＲ３レジスタの和をＲ４レジスタに格納する）
命令４：ＮＯＰ（何もしない）
【００３３】
ＣＰＵ２ｂのプログラム
命令１：ＬＤ  ［ａｄｄ］，Ｒ０（メモリのアドレスａｄｄからデータをロードし、Ｒ０レジスタに格納する）
命令２：ＬＤ  ［ａｄｄ］，Ｒ１（メモリのアドレスａｄｄからデータをロードし、Ｒ１レジスタに格納する）
命令３：ＡＤＤ  Ｒ１，Ｒ６，Ｒ７（Ｒ１レジスタとＲ６レジスタの和をＲ７レジスタに格納する）
命令４：ＡＤＤ  Ｒ１，Ｒ９，Ｒ１０（Ｒ１レジスタとＲ９レジスタの和をＲ１０レジスタに格納する）
【００３４】
まず命令１をそれぞれのＣＰＵのデコーダ２１でデコードすると、ＣＰＵ２ａ、ＣＰＵ２ｂともに遅延ロード命令であるためモニター遷移可能信号はアクティブとならない。次に命令２をそれぞれのＣＰＵのデコーダ２１でデコードするとＣＰＵ２ａは遅延ロードでも遅延分岐でもないのでＣＰＵ２ａのモニター遷移可能信号はアクティブとなるが、ＣＰＵ２ｂが遅延ロード命令であるためＣＰＵ２ｂのモニター遷移可能信号はアクティブとならない。従ってＡＮＤ回路２２の出力はアクティブとならない。命令１をステップ実行する場合この命令２のタイミングでハードウェアブレーク信号がアクティブとなる。次の命令３をそれぞれのＣＰＵのデコーダ２１でデコードすると、ＣＰＵ２ａ、ＣＰＵ２ｂともに遅延ロードでも遅延分岐でもないため、それぞれのモニター遷移可能信号がアクティブとなってＡＮＤ回路２２がアクティブとなり、ハードウェアブレーク信号がアクティブであるためＡＮＤ回路２３がアクティブとなって命令４のタイミングでＣＰＵ２ａ、ＣＰＵ２ｂともにブレーク（停止）する。
【００３５】
こうするとＣＰＵ２ａもＣＰＵ２ｂも命令１〜３を実行した後にモニター状態に遷移するため、プログラム通りにステップ実行を行うことができる。
【００３６】
本実施形態のように、ＣＰＵをブレークさせるための信号がハードウェアとして装備されており、その信号をプロセッサに印加することによって実行状態からモニター状態へ移行することをハードウェアブレークといい、ハードウェアブレーク信号が特許請求の範囲のブレーク命令に相当する。
【００３７】
本実施形態によれば、ＣＰＵ２ａ、ＣＰＵ２ｂ、ＣＰＵ２ｃを内蔵したマルチプロセッサ１において、ステップ動作時にモニター状態に遷移させるために、ＣＰＵ２ａ、ＣＰＵ２ｂ、ＣＰＵ２ｃそれぞれの命令をデコーダ２１でデコードして、モニター状態に遷移可能な命令の場合はモニター遷移可能信号を出力し、全てのＣＰＵがモニター遷移可能信号を出力した場合に、各ＣＰＵをモニター状態に遷移させているので、プログラム通りの動きを再現できるステップ実行をすることができる。
【００３８】
また、マルチプロセッサ１内部でモニター状態への遷移をハード的に制御しているので、ステップ実行時のデバッグ用ホストコンピュータの処理の負荷を軽減することができる。さらに、ハードウェアブレークを用いているので、各ＣＰＵのプログラムメモリからのデータを読み出して各ＣＰＵのプログラムメモリの書き換えといった作業が不要となるためステップ実行が高速化できる。
【００３９】
なお、ＡＮＤ回路２２およびＡＮＤ回路２３は、ＣＰＵ２ａ、２ｂ、２ｃがそれぞれ内蔵せずに、図２に示すようにブレーク生成装置３で一括して論理積をとってモニター遷移信号を生成してＣＰＵ２ａ、２ｂ、２ｃに出力する構成としてもよい。
【００４０】
このように構成することで、ブレーク生成装置３で一括して論理積をとってモニター遷移信号を生成してＣＰＵ２ａ、２ｂ、２ｃに出力しているので、ＣＰＵ２ａ、２ｂ、２ｃに対する回路変更が最小限で済む。
【００４１】
ただし、図２よりも図１の構成のほうが、各ＣＰＵとＡＮＤ回路との間の配線が短くなるために高速に動作させる際に有利である。一般的にＬＳＩのチップレイアウトの際には図３に示すようにＣＰＵ２ａ、２ｂ、２ｃは並べて配置されることが多い。一方、ブレーク生成装置３のようなデバッグ回路は、通常動作に関わらないことや外部との通信を行うことからＣＰＵ２ａ、２ｂ、２ｃとは離れた外周に配置される可能性が大きい。この場合、各ＣＰＵとブレーク生成装置３との間の配線が長くなり、図２のように各ＣＰＵから信号を取り出してからまた各ＣＰＵに信号を出力する構成では、図１と比較して回路の高速化が困難である。従って、ハードウェアで各ＣＰＵをブレークさせる際には図１の構成の方が好ましい。
【００４２】
［第２実施形態］
次に、本発明の第２の実施形態を図４を参照して説明する。なお、前述した第１の実施形態と同一部分には、同一符号を付して説明を省略する。図４は、本発明の第２の実施形態にかかるマルチプロセッサのブロック図である。
【００４３】
本実施形態では、選択手段としてのブレーク生成装置３が、ハードウェアブレーク信号に加えて、ＣＰＵ２ａマスク信号、ＣＰＵ２ｂマスク信号、ＣＰＵ２ｃマスク信号を出力している。
【００４４】
さらに、ＣＰＵ２ａでは、ＣＰＵ２ｂマスク信号とＣＰＵ２ｂが出力したモニター遷移可能信号とがＯＲ回路２４によって論理和をとってＡＮＤ回路２２に入力され、ＣＰＵ２ｃマスク信号とＣＰＵ２ｃが出力したモニター遷移可能信号とがＯＲ回路２５によって論理和をとってＡＮＤ回路２２に入力されている。ＣＰＵ２ｂでは、ＣＰＵ２ａマスク信号とＣＰＵ２ａが出力したモニター遷移可能信号とがＯＲ回路２４によって論理和をとってＡＮＤ回路２２に入力され、ＣＰＵ２ｃマスク信号とＣＰＵ２ｃが出力したモニター遷移可能信号とがＯＲ回路２５によって論理和をとってＡＮＤ回路２２に入力されている。ＣＰＵ２ｃでは、ＣＰＵ２ａマスク信号とＣＰＵ２ａが出力したモニター遷移可能信号とがＯＲ回路２４によって論理和をとってＡＮＤ回路２２に入力され、ＣＰＵ２ｂマスク信号とＣＰＵ２ｂが出力したモニター遷移可能信号とがＯＲ回路２５によって論理和をとってＡＮＤ回路２２に入力されている。
【００４５】
このような構成にすることで同期して動かなくても構わないＣＰＵを除外してステップ実行が可能となる。例えば、ＣＰＵ２ａを除外する場合、ＣＰＵ２ａマスク信号をアクティブ（ハイレベル）にする。そうすると、ＣＰＵ２ｂとＣＰＵ２ｃではＯＲ回路２４によってＡＮＤ回路２２の入力が常にアクティブ（ハイレベル）となるので、ＣＰＵ２ａの状態に関わらずＣＰＵ２ｂと２ｃとでステップ実行を行うことができる。すなわち、ブレーク生成装置３が出力するＣＰＵ２ａマスク信号、ＣＰＵ２ｂマスク信号、ＣＰＵ２ｃマスク信号によってモニター状態に遷移するＣＰＵを選択している。
【００４６】
本実施形態によれば、ブレーク生成装置３が各ＣＰＵに対してマスク信号（ＣＰＵ２ａマスク信号、ＣＰＵ２ｂマスク信号、ＣＰＵ２ｃマスク信号）を出力して、各ＣＰＵでは他のＣＰＵからのモニター遷移可能信号とマスク信号の論理和を取った上で、自身の信号と論理積を取るように構成しているので、他のＣＰＵとの依存関係の無い物を除外することができ、それによって除外したＣＰＵがモニター状態に遷移できない命令を実行中であってもモニター状態にさせることができ、全てのＣＰＵを同期してステップ実行する場合と比較してステップ実行を行う際の１ステップの命令数を少なくすることができる。
【００４７】
［第３の実施形態］
次に、本発明の第３の実施形態を図５および図６を参照して説明する。なお、前述した第１、第２の実施形態と同一部分には、同一符号を付して説明を省略する。図５は、本発明の第３の実施形態にかかるデバッグ装置のブロック図である。図６は、図５に示したデバッグ装置のステップ実行動作を示すフローチャートである。
【００４８】
図５に示したデバッグ装置１０は、マルチプロセッサ１´と、ブレーク生成装置３´と、を備えている。
【００４９】
マルチプロセッサ１´は、ＣＰＵ２ａ´、２ｂ´、２ｃ´を備えている。ＣＰＵ２ａ´、２ｂ´、２ｃ´は、デコーダ２１や、図示しないプログラム格納用のプログラムＲＡＭ、演算データ格納用のデータＲＡＭ、プログラムのアドレスを保持するプログラムカウンタ、プログラムＲＡＭから読み出した命令を格納する命令レジスタ、演算回路および各種レジスタを備えている点は第１、第２の実施形態のＣＰＵ２ａ、２ｂ、２ｃと同様であるが、ＡＮＤ回路２２および２３が削除されている点が異なる。
【００５０】
さらに、マルチプロセッサ１´は第１、第２の実施形態において、内蔵されていたブレーク生成装置３が削除され、マルチプロセッサ１´外部にブレーク生成装置３´として設けられている。この監視手段、遷移手段としてのブレーク生成装置は、例えばデバッグ用のコンピュータやワークステーションなどで構成してもよい。
【００５１】
次に、上述した構成のデバッグ装置１０において、ステップ実行を行う際の動作を図６のフローチャートを参照して説明する。図６に示したフローチャートはブレーク実行装置３´にて実行される。
【００５２】
まず、ステップＳ１において、検査対象となる命令を各ＣＰＵのプログラムカウンタ位置の命令に設定しステップＳ２に進む。本ステップでは、各ＣＰＵのプログラムをプログラムメモリからブレーク生成装置３´に読み出して、ステップ実行する命令をプログラムカウンタに設定された状態としている。
【００５３】
次に、ステップＳ２において、全ＣＰＵにおいて対象命令をチェックしてステップＳ３に進む。本ステップにおいては、モニター状態に遷移できる命令であるか否かをチェックしている。
【００５４】
次に、ステップＳ３において、全てのＣＰＵがモニター状態に遷移可能か否かを判断して遷移可能である場合（ＹＥＳの場合）はステップＳ５に進み、遷移可能でない場合（ＮＯの場合）はステップＳ４に進む。つまり、ステップＳ２でチェックした命令がモニター状態に遷移可能か否かを判断している。
【００５５】
次に、ステップＳ４において、全てのＣＰＵがモニター状態に遷移可能な命令でなかったため、対象命令を１つ次の命令に進めてステップＳ２に戻る。
【００５６】
次に、ステップＳ５において、全てのＣＰＵがモニター状態に遷移可能な命令であったため、対象命令の１つ次の命令を退避してステップＳ６に進む。
【００５７】
次に、ステップＳ６において、対象命令の１つ次の命令をソフトウェアブレーク命令（ＥＢＲＫ命令）に修正しステップＳ７に進む。本ステップにおいて、ステップＳ５で退避した命令に代えてソフトウェアブレーク命令に差し替える。
【００５８】
次に、ステップＳ７において、全てのＣＰＵをプログラム実行状態にする。本ステップにおいて、修正したプログラムを各ＣＰＵのプログラムメモリに書き込んでプログラムを実行させている。そして、実行されたプログラムはＥＢＲＫ命令をデコーダ２１がデコードすることでモニター遷移可能信号を出力してＣＰＵを停止させ、以後モニター状態に遷移してステップ実行を行うことができる。
【００５９】
上述したフローチャートの動作例を第１の実施形態で例示したプログラムでそれぞれ命令１をステップ実行する場合で説明する。まず命令１をそれぞれ検査すると、ＣＰＵ２ａ´、ＣＰＵ２ｂ´ともに遅延ロード命令であるためスキップする。次に命令２をそれぞれ検査するとＣＰＵ２ａ´は遅延ロードでも遅延分岐でもないが、ＣＰＵ２ｂ´が遅延ロード命令であるためスキップする。次の命令３をそれぞれ検査すると、ＣＰＵ２ａ´、ＣＰＵ２ｂ´ともに遅延ロードでも遅延分岐でもないため、それぞれ次の命令４をソフトウェアブレーク命令（ＥＢＲＫ命令）に差し替える。
【００６０】
本実施形態のように、ブレークしたい箇所の命令を、ＥＢＲＫ命令に置き換えて、モニター状態への移行をプロセッサの命令デコーダに委ねて、モニターモードへ移行することをソフトウェアブレークといい、このＥＢＲＫ命令が特許請求の範囲のブレーク命令に相当する。
【００６１】
本実施例によれば、デバッグ装置１０において、ステップ動作時にモニター状態に遷移させるために、ブレーク生成装置３´でマルチプロセッサ１´内のＣＰＵ２ａ´、２ｂ´、２ｃ´のプログラムをそれぞれ読み込んで、実行するべき命令を検査し、全てのＣＰＵでその命令が遅延ロード、遅延分岐命令ではなければ次の命令を退避し、ソフトウェアブレーク命令に差し替えた後、全てのＣＰＵを同時にプログラム実行状態にする。もしも１つでも遅延ロードや遅延分岐命令がある場合には全てのＣＰＵでその命令をスキップして次の命令を検査するということを遅延ロード、遅延分岐命令が出なくなるまで繰り返しているので、プログラム通りの動きを再現できるステップ実行をすることができる。
【００６２】
また、ブレーク生成装置３´でソフトウェアブレーク命令に差し替えることでステップ実行を行わせているので、マルチプロセッサ１´に追加回路等が不要となる。
【００６３】
また、上述した第３の実施形態では、遅延ロードである場合には直後の命令をＥＢＲＫ命令に差し替えることが出来ないとして説明を行ったが、遅延ロードであってもデスティネーションが直後の命令のソースと異なる場合には、直後の命令をＥＢＲＫ命令に差し替えても問題がないため、検査対象の命令だけではなく、直後の命令も考慮して判断を行うようにすればステップ実行の際の命令実行数を少なくすることが出来る。
【００６４】
なお、本発明は上記実施形態に限定されるものではない。即ち、本発明の骨子を逸脱しない範囲で種々変形して実施することができる。
【図面の簡単な説明】
【００６５】
【図１】本発明の第１の実施形態にかかるマルチプロセッサのブロック図である。
【図２】図１に示したマルチプロセッサの変形例を示したブロック図である。
【図３】図１に示したマルチプロセッサのチップレイアウトの例を示した説明図である。
【図４】本発明の第２の実施形態にかかるマルチプロセッサのブロック図である。
【図５】本発明の第３の実施形態にかかるデバッグ装置のブロック図である。
【図６】図５に示したデバッグ装置のステップ実行動作を示すフローチャートである。
【図７】遅延ロード命令のパイプラインの例を示す説明図である。
【図８】遅延ロード命令をステップ実行させた場合のパイプラインの例を示す説明図である。
【図９】遅延ロード命令時の問題点を除いたステップ実行のパイプラインの例を示す説明図である。
【符号の説明】
【００６６】
１                        マルチプロセッサ
２ａ、２ｂ、２ｃ          ＣＰＵ
２１                      デコーダ（監視手段）
２２、２３                ＡＮＤ回路（遷移手段）
２４、２５                ＯＲ回路（選択手段）
３                        ブレーク生成装置（選択手段）
１０                      デバッグ装置（選択手段）
１´                      マルチプロセッサ
２ａ´、２ｂ´、２ｃ´    ＣＰＵ
３´                      ブレーク生成装置（監視手段、遷移手段）
【図１】
2010033323.tif 000003
【図２】
2010033323.tif 000004
【図３】
2010033323.tif 000005
【図４】
2010033323.tif 000006
【図５】
2010033323.tif 000007
【図６】
2010033323.tif 000008
【図７】
2010033323.tif 000009
【図８】
2010033323.tif 000010
【図９】
2010033323.tif 000011