(57)【要約】【課題】ＣＰＵによる単位時間の命令の実行完了回数を調整できるマルチスレッド実行装置、オブジェクトプログラムの生成方法及びプログラムを提供すること。【解決手段】ソースプログラムから生成されたオブジェクトプログラムを記憶するプログラム記憶手段２６と、オブジェクトプログラムの命令を発行する命令発行手段１１と、前記命令を実行する命令実行手段１５と、を有するマルチスレッド実行装置１００であって、前記オブジェクトプログラムには、目標実行速度情報記憶手段８０から読み出された前記プログラム毎の目標実行速度情報に、命令の実行完了速度情報が略一致するよう調整する、調整用コードが挿入されている、ことを特徴とする。【選択図】図３
2011008617.tif 000002
【特許請求の範囲】
【請求項１】
ソースプログラムから生成されたオブジェクトプログラムを記憶するプログラム記憶手段と、
前記オブジェクトプログラムの命令を発行する命令発行手段と、
前記命令を実行する命令実行手段と、を有するマルチスレッド実行装置であって、
前記オブジェクトプログラムには、
目標実行速度情報記憶手段から読み出された前記プログラムの目標実行速度情報に、命令の実行完了速度情報が略一致するよう調整する、調整用コードが挿入されている、
ことを特徴とするマルチスレッド実行装置。
【請求項２】
前記調整用コードを実行した前記命令実行手段は、
該調整用コードに応じて、前記命令発行手段に、前記オブジェクトプログラムの命令の発行頻度を調整するよう要求する、
ことを特徴とする請求項１記載のマルチスレッド実行装置。
【請求項３】
前記調整用コードは、前記ソースプログラムをコンパイルするコンパイラにより挿入される、
ことを特徴とする請求項１又は２記載のマルチスレッド実行装置。
【請求項４】
命令の実行完了速度を監視する前記実行速度監視手段を有し、
前記実行完了速度情報は、前記実行速度監視手段により監視された、実際にオブジェクトプログラムが実行された際の実行状況から生成される、
ことを特徴とする請求項１〜３いずれか１項記載のマルチスレッド実行装置。
【請求項５】
前記実行完了速度情報は、オブジェクトプログラムの実行状況をシミュレートするシミュレータにより生成される、
ことを特徴とする請求項１〜３いずれか１項記載のマルチスレッド実行装置。
【請求項６】
複数のオブジェクトプログラムを時分割して実行するマルチスレッド実行環境を有し、
前記命令発行手段は、スレッドを切り替えることで、複数の前記オブジェクトプログラムの命令の発行比率を調整する、
ことを特徴とする請求項１〜５いずれか１項記載のマルチスレッド実行装置。
【請求項７】
前記命令発行手段は、複数のオブジェクトプログラムの優先順位に応じて、発行頻度を調整する前記オブジェクトプログラムを選択する、
ことを特徴とする請求項１〜６いずれか１項記載のマルチスレッド実行装置。
【請求項８】
前記目標実行完了数情報は、命令の単位時間当たりの目標実行完了数、又は、プログラムの単位処理当たりの目標実行サイクル数である、
ことを特徴とする請求項１〜７いずれか１項記載のマルチスレッド実行装置。
【請求項９】
ソースプログラムから生成されたオブジェクトプログラムの命令を発行する命令発行手段と、前記命令を実行する命令実行手段と、を有する情報処理装置が実行する、オブジェクトプログラムの生成方法であって、
実行速度監視手段又はシミュレータが、ソースプログラム毎の実行完了速度情報を生成するステップと、
コンパイラが、プログラム記憶手段からソースプログラムを読み出すステップと、
コンパイラが、目標実行速度情報記憶手段からソースプログラム毎の目標実行速度情報を読み出すステップと、
コンパイラが、実行完了速度情報記憶手段から、ソースプログラム毎の実行完了速度情報を読み出すステップと、
コンパイラが、前記ソースプログラムをオブジェクトプログラムに変換すると共に、前記目標実行速度情報に前記実行完了速度情報が略一致するよう調整する、調整用コードをオブジェクトプログラムに挿入するステップと、
を有することを特徴とするオブジェクトプログラムの生成方法。
【請求項１０】
コンピュータに、
プログラム記憶手段からソースプログラムを読み出すステップと、
目標実行速度情報記憶手段からソースプログラム毎の目標実行速度情報を読み出すステップと、
実行完了速度情報記憶手段から、ソースプログラム毎の実行完了速度情報を読み出すステップと、
前記ソースプログラムをオブジェクトプログラムに変換すると共に、前記目標実行速度情報に前記実行完了速度情報が略一致するよう調整する、調整用コードをオブジェクトプログラムに挿入するステップと、
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
一以上のスレッドを時分割して実行可能なマルチスレッド実行装置及びマルチスレッド実行方法に関し、特に、スレッド毎に命令の発行比率を調整可能なマルチスレッド実行装置、オブジェクトプログラムの生成方法及びプログラムに関する。
【背景技術】
【０００２】
プログラムを効率よく実行するための種々の方法が考えられている。従来における実行効率向上のアプローチの多くは、ＣＰＵの演算回路がプログラムを実行していない時間を少なくしようとするものである。例えば、分岐やユーザの操作による処理内容の確定待ちを低減する技術（例えば、特許文献１、３参照。）、入出力割り込みによるソフト的なオーバーヘッドを低減する技術（例えば、特許文献２参照。）、コンテキストの切り替え等、ハード的なオーバーヘッドを低減する技術（例えば、特許文献４参照。）が提案されている。
【０００３】
特許文献１では、静的に処理順序を決定可能なプログラムの部分を、コンパイル時にＰＵ（Processing  Unit）の特性に応じて配置しておくヘテロジニアスなマルチプロセッサが開示されている。また、特許文献２には、共有資源にアクセスするためのサブシステムコールをマスクすることで、ハイパバイザーによる介入を制御する入出力サブシステムコール命令制御方法が開示されている。特許文献２記載の入出力サブシステムコール命令制御方法は、ハイパバイザーによる介入を制御することで、割り込みによるオーバーヘッドを抑制することを図っている。また、特許文献３には、複数のプロセッサに投機的に命令を発行するマルチスレッド処理装置において、各プロセッサのスレッド実行開始、終了、実行状態の切り替え、及び、スレッド間のデータ転送を制御するスレッドマネージャを有するマルチスレッド処理装置が開示されている。特許文献３記載のマルチスレッド処理装置は、複数のプログラム経路を同時に実行することで、投機的実行の予測精度を向上させることを図っている。また、特許文献４には、複数のハードウェアスレッドを有するマルチスレッドコンピュータにおいて、スレッドにプログラムカウンタとレジスタセットを固定的に割り当て、待機状態のスレッドと実行状態のスレッドを切り替えるマルチスレッド実行方法が開示されている。特許文献４記載のマルチスレッド実行方法は、スレッドの準備に要する時間を削減できるので処理速度を向上することを図っている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−３２８４１６号公報
【特許文献２】特開平６−３５７３１号公報
【特許文献３】特開２０００−４７８８７号公報
【特許文献４】特開２００４−２３４１２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１〜４に代表される従来の技術のように実行効率を単に向上させるだけでは、２つのプログラム間に実行タイミングの依存性があるシステムに影響を及ぼすおそれがあるという問題がある。
【０００６】
図１（ａ）は、プログラム＃０の実行タイミングとプログラム＃１の実行タイミングの関係を説明する図の一例である。プログラム＃０はＣＰＵ＿Ａ１により実行され、プログラム＃１はＣＰＵ＿Ｂ１により実行されている。ＣＰＵ＿Ａ１とＣＰＵ＿Ｂ１は、一般的には別のマイコンに実装されている。
【０００７】
プログラム＃０は処理ａを実行し、プログラム＃１は、処理ｂ１と処理ｂ２を実行する。処理ｂ２は、処理ａの処理結果を利用して実行されるものである。図１（ａ）ではプログラム＃０とプログラム＃１の実行タイミングが同期するよう設計されているので、ＣＰＵ＿Ｂ１は処理ａの処理結果を利用して処理ｂ２を実行することができる。
【０００８】
図１（ｂ）は、ＣＰＵ＿Ｂ２がプログラム＃１を実行する際の、プログラム＃０の実行タイミングとプログラム＃１の実行タイミングの関係の一例を示す図である。ＣＰＵ＿Ｂ２はＣＰＵ＿Ｂ１よりＩＰＣ（Instructions  Per  Clock  cycle）が大きいか又は単位処理の実行サイクル数が小さいＣＰＵ、いわゆる実行速度の速いＣＰＵである。ＣＰＵ＿Ｂ２がプログラム＃１を実行することで、処理ｂ１の実行タイミングが早まる。一方、処理ｂ１が完了した時にはＣＰＵ＿Ａ１は処理ａを完了してない。このため、ＣＰＵ＿Ｂ２が処理ｂ２を実行する際に、処理ａの処理結果を利用できず、例えば、ＣＰＵ＿Ｂ２は１つ前の処理ａの処理結果を利用して処理ｂ２を実行してしまうなどの不具合が生じる。
【０００９】
ところで、ハードウェア・マルチスレッド技術を搭載したＣＰＵや、１つのＣＰＵに複数のコアを搭載したマルチコアＣＰＵ、が利用できるようになってきた。そこで、それまでは複数のＣＰＵ＿Ａ１で実行していたプログラム＃０とＣＰＵ＿Ｂ１で実行していたプログラム＃１を、１つのＣＰＵに移植して実行することが考えられている。このような技術は、例えば、車載ＬＡＮに接続された複数のＥＣＵ（Electronic  Control  Unit）をより少ない数のＥＣＵに統合する際に利用することができる。
【００１０】
しかしながら、統合後のＥＣＵに搭載されたＣＰＵは、統合前のＥＣＵに搭載されていたＣＰＵとアーキテクチャが異なるため、実行タイミングに依存関係のあるプログラム＃０とプログラム＃１を単に統合後のＥＣＵに移植しただけでは、図１（ｂ）と同様の不都合が生じてしまう。
【００１１】
このような不都合に対し、統合用ＣＰＵに異なるプログラム＃０，１を移植した場合、命令の発行比率を調整することが考えられる。
図２（ａ）は、統合前のＣＰＵ＿Ａ１とＣＰＵ＿Ｂ１、及び、統合用ＣＰＵの関係を説明する図の一例である。ＣＰＵ＿Ａ１の動作クロックは６０ＭＨｚ、ＣＰＵ＿Ｂ１の動作クロックは１８０ＭＨｚである。説明を簡単にするため両者のＩＰＣは同じ（ＩＰＣ＝１）としたが、両者のＩＰＣは異なっていてもよい。また、統合用ＣＰＵの動作クロックは１８０ＭＨｚである。したがって、ＣＰＵ＿Ｂ１の実行速度はＣＰＵ＿Ａ１の３倍である。なお、統合用ＣＰＵが有するｖＣＰＵ＿Ａ１、ｖＣＰＵ＿Ｂ１は仮想ＣＰＵを意味する。
【００１２】
ＣＰＵ＿Ａ１が実行していたプログラム＃０とＣＰＵ＿Ｂ１が実行していたプログラム＃１の実行タイミングを合わせるためには、元の実行速度に応じて、統合用ＣＰＵにおける命令発行比率を変えればよい。
図２（ｂ）は命令の発行比率と実行完了数の関係の一例を示す図である。実行速度が３倍異なるのであれば、統合用ＣＰＵは、ｖＣＰＵ＿Ｂ１に３回、命令を発行する毎に、ｖＣＰＵ＿Ａ１に１回、命令を発行する。こうすることで、統合前にＣＰＵ＿Ａ１が実行していたプログラム＃０と、ＣＰＵ＿Ｂ１が実行していたるプログラム＃１の実行タイミングを、統合用ＣＰＵにおいても、ある程度、揃えられる可能性がある。
【００１３】
しかしながら、統合用ＣＰＵとＣＰＵ＿Ａ１及びＣＰＵ＿Ｂ１は動作周波数だけでなく、命令セットやＩＰＣなど単位時間当たりの命令実行完了数が異なる。また、統合用ＣＰＵが、段数の多いパイプラインや、複数のパイプラインを備えている場合、ハザードやストールにより単位時間当たりの命令実行完了数が変わるため、ＩＰＣを考慮して命令の発行比率を決定しても、所望の命令実行比率は得られない。
【００１４】
このため、命令の発行比率を制御するだけでは、ｖＣＰＵ＿Ａ１の単位時間当たりの命令実行完了数とＣＰＵ＿Ａ１の単位時間当たりの命令実行完了数、及び、ｖＣＰＵ＿Ｂ１の単位時間当たりの命令実行完了数とＣＰＵ＿Ｂ１の単位時間当たりの命令実行完了数、を一致させることができない。例えば、命令の発行比率を制御しても、単位時間におけるプログラム＃０と＃１の命令実行完了数はそれぞれ変動を繰り返し、最終的にはプログラム＃０とプログラム＃１実行タイミングが大きく異なることになってしまう。
【００１５】
すなわち、従来のマルチスレッド技術又はマルチコアを利用して、複数のプログラム＃０，１を統合した場合、統合前の複数のプログラム＃０，１の実行タイミングを保証することができないという問題があった。
【００１６】
本発明は、上記課題に鑑み、ＣＰＵによる単位時間の命令の実行完了回数を調整できるマルチスレッド実行装置、オブジェクトプログラムの生成方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
ソースプログラムから生成されたオブジェクトプログラムを記憶するプログラム記憶手段と、ソースプログラムから生成されたオブジェクトプログラムの命令を発行する命令発行手段と、前記命令を実行する命令実行手段と、を有するマルチスレッド実行装置であって、前記オブジェクトプログラムには、目標実行速度情報記憶手段から読み出された前記プログラム毎の目標実行速度情報に、命令の実行完了速度情報が略一致するよう調整する、調整用コードが挿入されている、ことを特徴とする。
【発明の効果】
【００１８】
ＣＰＵによる単位時間の命令の実行完了回数を調整できるマルチスレッド実行装置、オブジェクトプログラムの生成方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１９】
【図１】プログラム＃０の実行タイミングとプログラム＃１の実行タイミングの関係を説明する図の一例である。
【図２】統合前のＣＰＵ＿Ａ１とＣＰＵ＿Ｂ１、及び、統合用ＣＰＵの関係を説明する図の一例である。
【図３】マルチスレッド実行装置１００の概略構成図の一例である。
【図４】スレッド＃０〜＃２とハードウェアリソースの関係の一例を模式的に示す図である。
【図５】実行状況監視装置の概略構成図の一例である。
【図６】コンパイラによる調整用コードの挿入を模式的に説明する図の一例である。
【図７】アプリ実行プロファイルを模式的に示す図の一例である。
【図８】目標ＩＰＣの算出手順の一例を示す図である。
【図９】目標ＩＰＣ（統合前の実行タイミング）とアプリ実行プロファイルの関係を模式的に示す図の一例である。
【図１０】アプリ実行プログラム＃０〜２の実行比率を、少なくすべきか、多くすべきか、又は、現状維持すべきか、を登録したスケジューリング比率テーブルの一例を示す。
【図１１】実行比率の調整を説明する図の一例である。
【図１２】マルチスレッド実行装置の効果を説明する図の一例である。
【図１３】マルチスレッド実行装置がスレッドの実行比率を調整する手順を示すフローチャート図の一例である。
【図１４】マルチスレッド実行装置の概略構成図の一例である。
【図１５】マルチスレッド実行装置の概略構成図の一例である。
【図１６】マルチスレッド実行装置の概略構成図の一例である。
【発明を実施するための形態】
【００２０】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図３は、マルチスレッド実行装置１００の概略構成図の一例を示す。マルチスレッド実行装置１００は、例えば３つの統合前のＥＣＵ（Electronic  Control  Unit）を統合したマイコン２００を有する。
【００２１】
始めにマルチスレッド実行装置１００が、単位時間における各プログラムの命令の実行回数を（以下、単に実行速度という場合がある）調整する手順の概略を説明する。各プログラムの命令の実行回数を調整することで、各プログラムの実行比率も調整される。
（１）メモリ２６に、アプリ実行プログラム＃０〜＃２を記憶しておく。アプリ実行プログラム＃０〜＃２は、例えば３つのプログラム（プログラム＃０、プログラム＃１、プログラム＃２）をコンパイルしたものである。コンパイル前のプログラム＃０〜＃２はアプリソース記憶部８０に記憶されている。  
また、アプリソース記憶部８０には、統合前のＣＰＵにおける各プログラム＃０〜＃２の統合前実行速度情報（単位時間毎の各プログラムの命令実行完了数又は単位処理毎の実行サイクル数）が記憶されている。
（２）実行状況監視装置１４は、各アプリ実行プログラム＃０〜＃２（ハードウェア・マルチスレッド）の実行状況を監視する。具体的には、単位時間毎の各アプリ実行プログラム＃０〜＃２の命令実行完了数又は単位処理毎の実行サイクル数をカウントする。
（３）プロファイラ１２は、実行状況監視装置の監視した、単位時間毎の命令実行完了数又は単位処理毎の実行サイクル数から、アプリ実行プロファイルを生成する。アプリ実行プロファイルは、各アプリ実行プログラム＃０〜＃２の実際の実行状態を時間と共に記録したファイルとなる。
（４）コンパイラ２４は、アプリ実行プロファイルと統合前の統合前実行速度情報を比較して、アプリ実行プログラム＃０〜＃２のいずれか１以上に命令発行頻度を調整するための調整用コードを挿入する。
（５）以上の処理を何回か繰り返せば、アプリ実行プログラム＃０〜＃２の実際の実行速度は、統合前の実行速度と同程度となる。
【００２２】
したがって、マルチスレッド実行装置１００に複数のＥＣＵのプログラム＃０〜２を統合して搭載しても、アプリ実行プログラム＃０〜２の実行速度を統合前のＣＰＵで実行した場合とほぼ同じにすることができる。また、結果的に、アプリ実行プログラム＃０〜２の実行比率を、統合前のＣＰＵで実行した場合とほぼ同じにすることができる。
【００２３】
また、統合の前後でプログラム＃０〜２を再コーディングする必要がないのでコスト低減が可能である。また、プログラム＃０〜２のタイミング依存検討が不要なので、ソフトウェアの流通性が飛躍的に高まる。また、単位処理の実行サイクル数をフィードバック制御に用いることで、異種マイコンへの統合が可能となる。
【００２４】
〔マルチスレッド実行装置１００のハードウェア構成〕
図３に示したように、マルチスレッド実行装置１００は、マイコン２００と開発環境３００とを有する。マイコン２００は、プロセッサ５０と、命令側メモリバス２２を介して接続されたメモリ２６、データ側メモリバス２３を介して接続されたデータ記憶部２７と、を有する。開発環境３００は、プロファイラ１２、アプリ実行プロファイル記憶部７０、アプリ実行プログラム記憶部６０、コンパイラ２４、及び、アプリソース記憶部８０を有する。当然ながら開発環境３００は、車載される段階では不要となる。アプリ実行プロファイル記憶部７０、アプリ実行プログラム記憶部６０、及び、アプリソース記憶部８０は、例えば、ＨＤＤ（Hard  Disk  Drive）やＳＳＤ（Solid  State  Drive）を実体とする。これら三者を別体に設ける必要はない。
【００２５】
プロセッサ５０は、ハードウェア・マルチスレッド型の実行環境を有する。ハードウェア・マルチスレッドとは、命令バッファ１７、レジスタファイル１６（システムレジスタ等）をそれぞれ複数備え、これらを適宜切り替えて命令を実行する構造をいう。なお、プログラムやその一部の関数等を処理の実行単位としてスレッドと呼ぶことがあるが、本実施形態のスレッドとはハード的な命令の供給・実行手段をいう。図３では、３つの命令バッファ１７と３つのレジスタファイル１６を有するので、マルチスレッド実行装置１００は３つのスレッド＃０〜＃２を有する。
【００２６】
図４はスレッド＃０〜＃２とハードウェアリソースの関係の一例を模式的に示す図である。マルチスレッド実行装置１００は、各スレッドを１クロックで切り替えて異なるプログラムを実行するので、物理的に存在する１つのプロセッサ５０により複数の仮想的なＣＰＵを有するように振る舞う。このため、命令バッファ＃０から演算回路１５までをスレッド＃０、命令バッファ＃１から演算回路１５までをスレッド＃１、命令バッファ＃２から演算回路１５までをスレッド＃２、という。スレッド＃０〜＃２とその他の周辺回路を併せてｖＣＰＵ（virtual  ＣＰＵ）＃０〜＃２と称する。このように、仮想的なｖＣＰＵ＃０〜＃２を複数有することで、統合前のＥＣＵでそれぞれ独立に実行されていた異なるアプリ実行プログラム＃０〜＃２を独立に実行することができる。
【００２７】
なお、本実施形態は、ハードウェア・マルチスレッドを対象に説明するが、マルチコアのマイコン２００に対しても、各プログラムの実行速度を調整することができる。この場合、マルチコアに共通のスレッドスケジュール装置を有すればよい。
【００２８】
命令バッファ＃０〜＃２は、それぞれ命令側メモリバス２２と接続されている。命令側メモリバス２２は、アプリ実行プログラム＃０〜＃２を記憶したＥＥＰＲＯＭ等のメモリ２６と接続されている。スレッドスケジュール装置１１は、命令バッファ＃０〜＃２毎に設けられた不図示のプログラムカウンタのアドレスを命令側メモリバス２２に出力して、命令バッファ＃０〜＃２にアプリ実行プログラム＃０〜＃２の命令を１つずつ読み出す。命令バッファ＃０〜＃２は、切り替えスイッチ１９に接続されている。切り替えスイッチ１９は、同時に１つの命令バッファ１７だけを命令デコーダ１８に接続するスイッチである。
【００２９】
スレッドスケジュール装置１１は、命令を発行する命令バッファ＃０〜＃２を選択する装置である。後述するように、スレッドスケジュール装置１１は、演算回路１５からの信号に応じて、命令を発行するスレッドを調整する。こうすることで、プログラム毎に独立にＩＰＣ（Instructions  Per  Clock  cycle）を制御でき、命令発行比率を制御できる。
【００３０】
スレッドスケジュール装置１１は２つの切り替えスイッチ１９、２１とそれぞれ接続されており、切り替えスイッチ１９の接続先を命令バッファ＃０〜＃２のいずれかに切り替えることで、命令デコーダ１８に接続する命令バッファ＃０〜＃２を切り替える。スレッドスケジュール装置１１が選択したスレッド＃０〜＃２の命令が命令バッファ＃０〜＃２から読み出され、命令デコーダ１８に送出される。また、スレッドスケジュール装置１１は、命令バッファ＃０〜＃２の全てを命令デコーダ１８と切り離すこともできる。同様に、スレッドスケジュール装置１１は、切り替えスイッチ２１の接続先をレジスタファイル＃０〜＃２のいずれかに切り替えることで、命令デコーダ１８と演算回路１５が使用するレジスタファイル＃０〜＃２を切り替える。
【００３１】
命令デコーダ１８は命令を解読し、解読結果をそのスレッドのレジスタファイル＃０〜＃２に転送すると共に、パイプライン制御回路１３に送出する。レジスタファイル＃０〜＃２は、演算回路１５の演算結果、及び、データ側メモリバス２３に接続されたデータ記憶部２７から読み出されたデータを一時的に記憶する一群のレジスタである。命令デコーダ１８による解読結果は、例えば、演算の種別、１以上のソースオペランド、結果の格納場所、等である。ソースオペランドはレジスタファイル１６に供給されるので、これにより演算回路１５が演算に使用するレジスタが指定される。
【００３２】
命令デコーダ１８が演算の種類をパイプライン制御回路１３に送出すると、パイプライン制御回路１３は演算回路１５が実行する演算を指定する。演算回路１５は、演算の種類に応じて、レジスタファイル１６に記憶されたデータに演算を施す。演算の内容は、ストア、ロード、加算、乗算、除算、分岐等、演算回路１５に応じて種々のものが用意されている。そして、ストアやロード命令の場合、演算回路１５は演算したアドレスを指定してデータ側メモリバス２３からデータをフェッチする。そして、演算回路１５は、加算等の演算結果、又は、読み出したデータを、レジスタファイル１６の、結果の格納場所により指定されるレジスタにライトバックする。
【００３３】
パイプライン制御回路１３は、以上のパイプライン制御の各ステージ（命令フェッチ、命令デコード、命令実行、オペランドフェッチ、ライトバック等）を動作クロックに基づき制御する。また、パイプライン処理ではハザード（各ステージの処理を決まった時間内に終わらせることを阻害する要因）が不可避なので、パイプライン制御回路１３は、演算の種類やソースオペランド等を参照して、パイプラインにストールを発生させたり、ＮＯＰ命令を挿入したり、分岐により不要となった各ステージの内容をフラッシュするなどの処理を行う。例えば、あるスレッド（例えばスレッド＃０）にＩ／Ｏ待ちのようなハザードが生じた場合、パイプライン制御回路１３はスレッドスケジュール装置１１にそのスレッド＃０を停止させ、別のスレッド（例えばスレッド＃１）を実行するよう要求する。
【００３４】
パイプライン制御回路１３は実行状況監視装置１４と接続されている。実行状況監視装置１４は、スレッド毎に、単位時間当たりの命令実行完了数又は単位処理の実行サイクル数をカウントする（以下、両者を区別しない場合、単に「カウント値」という。）。
【００３５】
〔実行状況監視装置１４〕
図５は、実行状況監視装置１４の概略構成図の一例を示す。実行状況監視装置１４は、実行状況監視部１４１とカウンタ部１４２を有する。単位時間当たりの命令実行完了数又は単位処理の実行サイクル数は、いずれも広い意味で命令の実行速度を表すものである。単位時間当たりの命令実行完了数は、統合前のＣＰＵとｖＣＰＵ＃０〜＃２の命令セットアーキテクチャ（ＩＳＡ）が同一の場合に、コンパイラ２４がアプリ実行プログラム＃０〜＃２のいずれか１以上に調整用コードを挿入する際に用いられる。単位処理の実行サイクル数は、ＩＳＡが異なる場合に、コンパイラ２４がアプリ実行プログラム＃０〜＃２のいずれか１以上に調整用コードを挿入する際に用いられる。
【００３６】
ＩＳＡは、ＣＰＵに実装された一式の命令形式（二進数のオペコード）を意味する。したがって、ＩＳＡが同一であればある命令を実行完了するまでの実行サイクル数は、統合前のＣＰＵとｖＣＰＵ＃０〜＃２で同じである。この場合、単位時間当たりの命令実行完了数の違いは、動作周波数にのみ起因すると考えられる。一方、ＩＳＡが異なる場合はある命令を実行完了するまでの実行サイクル数が統合前のＣＰＵとｖＣＰＵで異なるので、単位時間当たりの命令実行完了数がソースコード上の命令実行完了の進捗と一致しない。このため、統合前のＣＰＵとｖＣＰＵ＃０〜＃２のＩＳＡが異なる場合、単位処理の実行サイクル数を利用して、コンパイラ２４が、ソースコード上の実行の進捗が一致するように、調整用コードを挿入する。
【００３７】
・単位時間毎の命令実行完了数
まず、単位時間毎の命令実行完了数のカウントについて説明する。パイプライン制御回路１３は、１つの命令をパイプライン処理の各ステージに遷移させながら、回路やレジスタにデータを送出する。したがって、１つの命令が実行完了したこと（例えば、レジスタファイル１６へのライトバック時）は、パイプライン制御回路１３にとって既知である。また、どのスレッド＃０〜＃２の命令を実行完了したかは、スレッドスケジュール装置１１や切り替えスイッチ１９の状態から明らかとなる。パイプライン制御回路１３は、１つの命令が実行完了すると命令実行完了情報を実行状況監視装置１４に出力する。具体的には、パイプライン制御回路１３と実行状況監視装置１４がスレッドの数だけ信号線で接続されており、パイプライン制御回路１３は実行完了したスレッドに対応した信号線にＨｉｇｈ信号を出力する。
【００３８】
実行状況監視部１４１は命令実行完了情報を取得すると、カウンタ部１４２にカウントアップを要求する。具体的にはスレッド毎に設けられたカウント回路＃０〜＃２にＨｉｇｈ信号を出力する。これにより、カウンタ部１４２は、スレッド毎に実行完了した実行完了命令数をカウントできる。単位時間の命令実行完了数は、大きいほど実行速度が大きいことを意味する。
【００３９】
そして、カウンタ部１４２は、単位時間毎に、カウント値をプロファイラ１２に出力する。また、実行状況監視部１４１は、カウンタ部１４２がカウント値をプロファイラ１２に出力した直後に、カウンタ部１４２をリセット（ゼロに戻す）する。したがって、カウンタ部１４２は、単位時間毎の命令実行完了数をプロファイラ１２に出力することができる。なお、単位時間は、例えば、動作クロックの×１０〜１０００程度である。単位時間が余り短いとカウント値の変動が大きく、長いと実行時間比率を制御しにくいので、単位時間として極端に短くない程度の実行サイクル数が、実行状況監視装置１４に設定されている。
【００４０】
・単位処理の実行サイクル数
単位処理の実行サイクル数のカウントについて説明する。単位処理とは、例えば一連の処理をまとめた関数である。例えばＣ言語では「関数名〜｛Return；｝」が１つの単位処理である。プロセッサ５０がコンパイルされたオブジェクトコードを実行する場合、コンパイルにより、オブジェクトコードには、関数の始まり・終わりにそれぞれスタックポインタの初期化・後処理する所定のコードが記述される。パイプライン制御回路１３は、命令デコーダ１８から、これら関数の始まりを示すコードと終わり示すコードを検出するとＨｉｇｈ信号を実行状況監視装置１４に出力する。
【００４１】
実行状況監視部１４１は、関数の始まりのＨｉｇｈ信号を取得するとカウンタ部１４２に動作クロックのカウント開始を要求し、次に終わりのＨｉｇｈ信号を取得するとカウンタ部１４２にカウント値をプロファイラ１２に出力させる。また、実行状況監視部１４１は、Ｈｉｇｈ信号を取得する度にカウンタ部１４２をリセット（ゼロに戻す）する。したがって、カウンタ部１４２は、関数の実行完了に必要な実行サイクル数（単位処理毎の実行サイクル数）をカウントして出力することができる。単位処理毎の実行サイクル数は、大きいほど実行速度が遅いことを意味する。
【００４２】
単位処理の実行サイクル数をフィードバック制御に用いることで、ＩＳＡが異なる例えば異種マイコンへ複数のプログラム＃０〜＃２を移植することが可能となる。
【００４３】
後述するように、命令実行完了数をカウントした単位時間毎や単位処理の実行サイクル数毎に調整用コードが挿入されることで、実行速度の調整が容易になる。このため、単位処理の実行サイクル数毎に実行速度を調整したのでは、実行速度の調整が遅れるようにあれば、基本ブロック単位の実行サイクル数毎に、調整用コードを挿入する。基本ブロックは、割り込みなどの特殊な状況を除いて、連続して実行されるひとかたまりの命令列をいう。例えば、分岐命令による分岐先から次に分岐されるまでの一連の命令である。基本ブロックはタスクよりも小さい単位なので、適切なタイミングで実行速度を調整することが可能になる。基本ブロックの区切りは、パイプライン制御装置１３が命令から検出できる。
【００４４】
〔コンパイラ２４による調整用コードの挿入〕
図６は、コンパイラ２４による調整用コードの挿入を模式的に説明する図の一例である。まず、プロファイラ１２によるアプリ実行プロファイルの生成について説明する。
図７（ａ）は、アプリ実行プロファイルを模式的に示す図の一例である。横軸は時間、縦軸はＩＰＣであるが、単位処理毎の実行サイクル数としてもよい。実行状況監視装置１４が、アプリ実行プログラム＃０〜＃２毎に、単位時間毎の命令実行完了数をプロファイラ１２に出力すると、プロファイラ１２は図７（ａ）のようなアプリ実行プロファイルを生成し、アプリ実行プロファイル記憶部７０に記憶する。
【００４５】
図７（ｂ）は、各アプリ実行プログラム＃０〜＃２のアプリ実行プロファイルを時間に対し重畳したアプリ実行プロファイルの一例を示す。図７（ｂ）は、ある時刻における各アプリ実行プログラム＃０〜＃２の実行比率を示すもので、面積比はアプリ実行プログラム＃０〜＃２の実行時間比率に等しい。本実施形態のマルチスレッド実行装置１００は、このようなアプリ実行プログラム＃０〜＃２の実行比率を、統合前と同程度にすることが特徴である。
【００４６】
＜統合前実行速度情報＞
図７（ｃ）は統合前のＣＰＵ＃０〜＃２によるアプリ実行プログラム＃０〜＃２のＩＰＣの一例を示す。図７（ｃ）の３つのアプリ実行プログラム＃０〜＃２のこのような実行速度を、マルチスレッド実行装置１００にて維持できれば、アプリ実行プログラム＃０〜＃２の命令発行比率が適切であることになる。
【００４７】
しかしながら、プログラム＃０〜２をマイコン２００に移植する際は、統合前のＣＰＵ＃０〜＃２が実行していたアプリ実行プログラム＃０〜＃２を、処理能力の高いｖＣＰＵ＃０〜＃２に実行させることが多い。このため、ｖＣＰＵ＃０〜＃２の処理能力を最大に活用してアプリ実行プログラム＃０〜＃２を実行すると、単位時間の演算量が多くなってしまう。すなわち、ｖＣＰＵ＃０〜＃２によるアプリ実行プログラム＃０〜＃２の実行速度を保証できない。
【００４８】
そこで、統合前のＣＰＵ＃０〜＃２によるアプリ実行プログラム＃０〜＃２のＩＰＣから、ｖＣＰＵ＃０〜＃２における目標ＩＰＣを決定する方法について説明する。
【００４９】
図８（ａ）は目標ＩＰＣの算出手順の一例を示す図である。図示するように、目標ＩＰＣは、次式により算出される。
目標ＩＰＣ＝  統合前のＣＰＵのＩＰＣ  ÷  統合前のＣＰＵの動作周波数とｖＣＰＵの動作周波数の比  …  （１）
統合前のＣＰＵとｖＣＰＵ＃０〜＃２のＩＳＡが同一の場合、実行速度は動作周波数により定まるとしてよいので、統合前のＣＰＵの動作周波数とｖＣＰＵの動作周波数の比から、目標ＩＰＣを求めればよい。統合前のＣＰＵの動作周波数とｖＣＰＵの動作周波数は、例えばコンパイラ２４にとって既知である。
【００５０】
一般には統合前のＣＰＵよりもｖＣＰＵの方が動作周波数が大きくなるため、統合前のＣＰＵの動作周波数とｖＣＰＵ＃０〜＃２の動作周波数の比は１以上となることが多い。例えば、統合前のＣＰＵのＩＰＣが例えば「０．８」であり、統合前のＣＰＵの動作周波数とｖＣＰＵ＃０〜＃２の動作周波数の比が「２」の場合、目標ＩＰＣは「０．４」となる。図７（ｃ）のような、統合前のＣＰＵ＃０〜＃２によるアプリ実行プログラム＃０〜＃２のＩＰＣを、動作周波数の比「２」で割れば、目標ＩＰＣが得られる。
【００５１】
また、ＩＰＣでなく、単位処理の実行サイクル数から、統合前実行速度情報を算出してもよい。図８（ｂ）は統合前実行速度情報としての目標サイクル数の算出手順の一例を示す図である。図示するように、目標実行サイクル数は、次式により算出される。
目標実行サイクル数＝  統合前のＣＰＵにおける単位処理の実行サイクル数  ×  統合前のＣＰＵの動作周波数とｖＣＰＵの動作周波数の比  …  （２）
統合前のＣＰＵとｖＣＰＵ＃０〜＃２のＩＳＡが同一でない場合、両者で同じ単位処理の実行サイクル数が異なるので、単位処理の実行サイクル数を、動作周波数の比で調整すればよい。
【００５２】
例えば、統合前のＣＰＵの単位処理の実行サイクル数が「１００」であり、統合前のＣＰＵの動作周波数とｖＣＰＵ＃０〜＃２の動作周波数の比が「２」の場合、目標実行サイクル数は「２００」となる。すなわち、ｖＣＰＵ＃０〜＃２が統合前のＣＰＵよりも早いので、単位処理の実行サイクル数を多くする必要がある。
【００５３】
図７（ｃ）と同様に、統合前のＣＰＵ＃０〜＃２によるアプリ実行プログラム＃０〜＃２の、単位処理の実行サイクル数に、動作周波数の比「２」を乗じれば、目標実行サイクル数が得られる。
【００５４】
＜調整用コード＞
図６に戻り、調整用コードについて説明する。アプリソース記憶部８０に各プログラムの統合前実行速度情報が得られ、アプリ実行プロファイル記憶部７０にアプリ実行プロファイルが記憶されている。この状態で、コンパイラ２４は両者を単位時間毎又は単位処理毎に比較しながら、アプリ実行プログラム＃０〜＃２に命令発行比率を調整するための調整用コードを挿入する。
【００５５】
図９は、目標ＩＰＣとアプリ実行プロファイルの関係を模式的に示す図の一例である。図９では、統合前のＣＰＵの動作周波数とｖＣＰＵの動作周波数の比を「２」にした。このため、統合前のＣＰＵのＩＰＣが「０．８」なら、目標ＩＰＣは「０．４」に、統合前のＣＰＵのＩＰＣが「０．７５」なら、目標ＩＰＣは「０．３５」になっている。
【００５６】
例えば、タスク毎にＩＰＣを比較する場合、アプリ実行プロファイルにおける、タスク１（時刻Ｔ０〜Ｔ９９）の平均のＩＰＣが「０．２８」になっている。目標ＩＰＣが「０．４」なので、コンパイラ２４は、このプログラム（＃０〜＃２のいずれか）の実行速度が小さいので、実行速度を増大させる必要があると判定する。
【００５７】
また、例えば、アプリ実行プロファイルにおける、タスク２（時刻Ｔ１００〜Ｔ１９９）の平均のＩＰＣが「０．４５」になっている。目標ＩＰＣが「０．４」なので、コンパイラ２４は、このプログラム（＃０〜＃２のいずれか）の単位時間の実行速度が大きいので、実行速度を減少させる必要があると判定する。
【００５８】
コンパイラ２４は、単位処理毎（タスク毎）や基本ブロック毎に、アプリ実行プロファイルのＩＰＣと目標ＩＰＣを比較する。これを各アプリ実行プログラム＃０〜＃２について行う。こうすることで、タスク毎や基本ブロック毎に、アプリ実行プログラム＃０〜２の実行速度を、大きくすべきか、小さくすべきか、又は、現状維持すべきか、を決定できる。
【００５９】
図１０は、アプリ実行プログラム＃０〜２の実行速度を、小さくすべきか、大きくすべきか、又は、現状維持すべきか、を登録したスケジューリング比率テーブルの一例を示す。なお、時間帯は、例えば１つのタスクや基本ブロックを表す。したがって、アプリ実行プログラム＃０〜２に挿入される調整用コードが、アプリ実行プログラム＃０〜＃２の実行上において同じタイミングになるとは限らない。
【００６０】
コンパイラ２４が、アプリ実行プログラム＃０〜＃２に実行速度を調整するための調整用コードを挿入する態様には、以下の２つの態様がある。
（Ａ）タスクのコードの先頭に、スケジューリング比率テーブルに応じた調整用コードを追加する態様
（Ｂ）スケジューリング調整用のタスク（このタスク全体が調整用コードとなる）と、スケジューリング比率テーブルの全体をアプリソース記憶部８０に記憶して、アプリ実行プログラム記憶部６０にオブジェクトとして追加する態様
いずれの態様でも、調整用コードがコンパイラ２４によりコンパイルされるので、アプリ実行プログラム＃０〜２と共にプロセッサ５０により実行される。なお、コンパイラ２４は、コンパイルと共に調整用コードを挿入してもよいし、コンパイル後に調整用コードをオブジェクトコードに挿入してもよい。
【００６１】
（Ａ）の態様では、調整用コードが演算回路１５により実行されると、プロセッサ５０が、例えばＯＳのスケジューラを呼び出して、アプリ実行プログラム＃０〜２の実行速度を「大」「小」「現」のうちどのよう調整するかの速度調整情報をスレッドスケジュール装置１１に設定する。実際には速度調整情報はフラグ等により実現される。例えば、アプリ実行プログラム＃０の速度調整情報が「大」の場合、スレッドスケジュール装置１１は、アプリ実行プログラム＃０の命令の発行比率をそれまでよりも多くする。また、例えば、プログラム＃１の速度調整情報が、「小」の場合、スレッドスケジュール装置１１は、プログラム＃１の命令の発行比率をそれまでよりも少なくする。なお、複数のアプリ実行プログラム＃０〜２の２以上から「大」の速度調整情報が設定された場合、スレッドスケジュール装置１１はアプリ実行プログラム＃０〜２の優先順位の高いものから命令の発行比率を調整する。このような状況が生じても実行速度を調整できるように、プロセッサ５０の処理能力には予め余裕を持たせてあるものとする。すなわち、統合前のＣＰＵをそれぞれ合計した以上の処理能力を、プロセッサ５０が有している。
【００６２】
また、調整用コードとして「多」又は「小」の２値でなく、「多」について「＋５」〜「＋１」の多段の数値を、「小」について「−５」〜「−１」の多段の数値を、用いてもよい。このような数値は、コンパイラ２４が、目標ＩＰＣとアプリ実行プロファイルのＩＰＣの乖離に応じて決定する。そして、ＯＳが多値の速度調整情報をスレッドスケジュール装置１１に設定する。この場合、スレッドスケジュール装置１１は、多値の値に応じて、プログラム＃０〜２の各命令の発行頻度を調整する。
【００６３】
なお、（Ａ）の態様において、スレッドスケジュール装置１１に速度調整情報を設定するのは、ＯＳである必要はなく、アプリ実行プログラム＃０〜＃２が直接、設定してもよいし、ドライバプログラムを呼び出して設定してもよい。
【００６４】
（Ｂ）の態様では、スケジューリング調整用のタスクが、各アプリ実行プログラム＃０〜＃２の実行開始時に、スケジューリング比率テーブルを読み出し、アプリ実行プログラム＃０〜２の進捗に応じて、速度調整情報をスレッドスケジュール装置１１に設定する。スレッドスケジュール装置１１による、スケジューリング比率の調整は態様（Ａ）と同じである。
【００６５】
以上のようにして、アプリ実行プログラム＃０〜＃２のいずれか１以上に実行速度を調整するための調整用コードが挿入された。
【００６６】
〔実行速度の調整〕
図１１は、実行速度の調整を説明する図の一例である。演算回路１５が調整用コードを実行すると、演算回路１５がスレッドスケジュール装置１１に各プログラムの速度調整情報を設定する。
【００６７】
スレッドスケジュール装置１１は、切り替えスイッチ１９を制御して、命令バッファ＃０〜＃２と命令デコーダ１８の接続を切り替える。こうすることで、実行速度を大きくしたいアプリ実行プログラム＃０〜＃２を実行するスレッド＃０〜＃２は、命令デコーダ１８と高い頻度で接続され、実行速度を小さくしたいアプリ実行プログラム＃０〜＃２を実行するスレッド＃０〜＃２は、命令デコーダ１８と接続される頻度が減るようになる。したがって、プロセッサ５０は、アプリ実行プロファイルを統合前実行速度情報に近づけることができる。
【００６８】
図１２は、マルチスレッド実行装置１００の効果を説明する図の一例である。図１２（ａ）の実測ＩＰＣは、調整用コードが挿入されていない状態のアプリ実行プログラム＃０〜＃２が、マイコン２００で実行された際のＩＰＣである。図示するように、実測ＩＰＣが目標ＩＰＣよりも大きくなっている。
【００６９】
図１２（ｂ）は、調整用コードが挿入された状態でマイコン２００で実行された際の実測ＩＰＣと目標ＩＰＣの関係の一例を示す。アプリ実行プログラム＃０〜＃２の実行速度を調整することで、図１２（ｂ）に示すように、目標ＩＰＣとマイコン２００で実行された際のＩＰＣの差を小さくすることができる。
【００７０】
また、図１２（ｂ）に示すように、実測されたＩＰＣが目標ＩＰＣよりも大きければ、調整用コードを挿入することで実行速度をさらに調整でき、実測されたＩＰＣが目標ＩＰＣよりも小さければ、調整用コードを挿入することで実行速度をさらに調整できる。
【００７１】
〔動作手順〕
図１３は、マルチスレッド実行装置１００がスレッドの実行速度を調整する手順を示すフローチャート図の一例を示す。図１３の手順の前に、アプリ実行プログラム＃０〜＃２には、調整用コードが挿入されている。図１３のフローチャート図は、マルチスレッド実行装置１００が起動するとスタートする。
【００７２】
起動直後、スレッドスケジュール装置１１は、初期値のスレッドの命令の発行比率により（例えば、同じ発行比率により）、命令バッファ＃０〜＃２と命令デコーダ１８を接続する。
【００７３】
アプリ実行プログラム＃０〜＃２に挿入された調整用コードが演算回路１５により実行されると、例えばＯＳのスケジューラがスレッドスケジュール装置１１に、速度調整情報を設定する（Ｓ１０）。
【００７４】
スレッドスケジュール装置１１には、他のアプリ実行プログラムからも速度調整情報が設定されるので、スレッドスケジュール装置１１は、３つのアプリ実行プログラム＃０〜＃２の優先順位を参照する（Ｓ２０）。
【００７５】
スレッドスケジュール装置１１は、優先順位の高いアプリ実行プログラム＃０〜＃２から順番に、実行速度を調整するので、優先順位に基づき、アプリ実行プログラムの実行速度を調整する順番を決定する（Ｓ３０）。
【００７６】
また、優先順位が同じアプリ実行プログラム＃０〜＃２がある場合があるので、スレッドスケジュール装置１１は、同一の優先順位のアプリ実行プログラム＃０〜＃２があるか否かを判定する（Ｓ４０）。同一の優先順位のアプリ実行プログラム＃０〜＃２がない場合（Ｓ４０のＮｏ）、優先順位が最も高いアプリ実行プログラム＃０〜＃２の実行速度を調整する（Ｓ５０）。同一の優先順位のアプリ実行プログラム＃０〜＃２がある場合（Ｓ４０のＹｅｓ）、スレッドスケジュール装置１１は、例えば、命令を実行する毎に、実行速度を調整するアプリ実行プログラムを切り替える（Ｓ６０）。先に、速度調整情報が設定されたアプリ実行プログラム＃０〜＃２を優先してもよい。
【００７７】
そして、スレッドスケジュール装置１１は、優先順位の高いアプリ実行プログラム＃０〜＃２の調整が済むと、次に優先順位の低いアプリ実行プログラム＃０〜＃２が速度調整情報を設定しているか否かを判定する（Ｓ７０）。次に優先順位の低いアプリ実行プログラム＃０〜＃２が速度調整情報を設定している場合（Ｓ７０のＹｅｓ）、プロセッサ５０はステップＳ４０からの処理を繰り返す。以上のように、優先順位の高いアプリ実行プログラムから優先的に、実行速度が調整されていく。
【００７８】
以上説明したように、本実施形態のマルチスレッド実行装置１００は、コンパイラ２４が命令の実行速度を調整するための調整用コードをアプリ実行プログラムに挿入することで、各スレッド＃０〜＃２の実行速度を調整することができる。したがって、複数のＥＣＵを１つに統合した場合に、統合前の各ＥＣＵの実行速度を再コーディングなしに維持することができる。また、プログラム＃０〜＃２を別のＣＰＵに移植しても、移植先のＣＰＵが移植前と時間的に同じ振る舞いをするので、プログラム＃０〜＃２の再設計が不要になり、プログラム＃０〜＃２の流通性が向上する。特に、単位処理の実行サイクル数により調整用コードを生成すれば、異種マイコンへの統合が可能となる。
【００７９】
〔好適な変形例〕
・スレッドが１つのマルチスレッド実行装置１００
マルチスレッド実行装置１００が複数のスレッドを有することを前提に説明したが、マルチスレッド実行装置１００が１つのみのスレッドを有していてもよい。
図１４は、マルチスレッド実行装置１００の概略構成図の一例を示す。図１４において図３と同一部には同一の符号を付しその説明は省略する。スレッドが１つの場合、命令バッファ１７及びレジスタファイル１６も１つになる。また、スレッドスケジュールが不要なので、スレッドスケジュール装置１１の代わりに、命令発行制御回路２８が命令バッファ１７に接続されている。命令発行制御回路２８は、演算回路１５が調整用コードを実行することで設定された速度調整情報に応じて、命令バッファ１７に命令をフェッチするタイミングを制御する。すなわち、速度調整情報が「小」の場合、命令発行制御回路２８は、例えば、命令バッファ１７と命令デコーダ１８の接続を２クロックに１回、断接したり、パイプラインにストールを発生させたり、ＮＯＰ命令を挿入する。こうすることで、単位時間毎の命令実行完了数を低下させ、又は、単位処理の実行サイクル数を増大させ、統合前のＣＰＵによるアプリ実行プログラムの実行速度を再現できる。また、速度調整情報が「大」の場合、命令発行制御回路２８は、例えば、命令バッファ１７と命令デコーダ１８を４クロックに３回接続するなど、接続する比率を多くする。こうすることで、単位時間毎の命令実行完了数を増大させ、又は、単位処理の実行サイクル数を低下させ、統合前のＣＰＵと同程度の実行速度を再現できる。
【００８０】
・実行状況監視装置１４を有さない形態
図１５は、マルチスレッド実行装置１００の概略構成図の一例を示す。図１５において図３と同一部には同一の符号を付しその説明は省略する。図１５のマルチスレッド実行装置１００は、実行状況監視装置１４を有さず、アプリソース記憶部８０がコンパイラ２４と、コンパイラ２４がアプリ実行プログラム記憶部６０と、アプリ実行プログラム記憶部６０がシミュレータ２９と、シミュレータ２９が標準プロファイル記憶部７１と、標準プロファイル記憶部７１がコンパイラ２４と、それぞれ接続されている。
【００８１】
図１５のマルチスレッド実行装置１００は、実行状況監視装置１４ではなく、シミュレータ２９がアプリ実行プロファイルの代わりに標準プロファイルを生成する。アプリ実行プロファイルが、マイコン２００によるアプリ実行プログラム＃０〜＃２を実行した際の実行速度情報であるのに対し、標準プロファイルは人為的又は機械的に設定された実行速度情報である。標準プロファイルは、例えば設計者が、一定のＩＰＣ又は単位処理の実行サイクル数を、マルチスレッド実行装置１００のおよそのＩＰＣや単位処理の実行サイクル数として設定する。こうすることで、シミュレータ２９がアプリ実行プログラム毎に、単位時間毎のＩＰＣ又は単位処理の実行サイクル数を生成することができる。また、アプリ実行プログラムの演算の種類毎に各命令をクロック数で重み付けして、マルチスレッド実行装置１００のＣＰＵがプログラムを実行した際の各命令のＩＰＣや実行サイクル数を算出してもよい。このシミュレータ２９は、実在するマルチスレッド実行装置１００をシミュレートしたものなので、演算の種類毎に必要なクロック数は容易に特定でき、マルチスレッド実行装置１００による実行結果を正確にシミュレートできる。
【００８２】
実行状況監視装置１４を有さない形態は、スレッドが１つのマルチスレッド実行装置１００に対しても適用できる。
図１６は、マルチスレッド実行装置１００の概略構成図の一例を示す。図１６において図１５と同一部には同一の符号を付しその説明は省略する。図１６のマルチスレッド実行装置１００は、スレッドスケジュール装置の代わりに命令発行制御回路２８を有し、また、プロファイラ１２でなくシミュレータ２９を有する。シミュレータ２９がアプリ実行プログラムの、単位時間毎のＩＰＣ又は単位処理の実行サイクル数を生成するので、図１５と同様に、統合前のＣＰＵの実行状況を再現できる。
【００８３】
図１５や図１６のマルチスレッド実行装置１００のように、実行状況監視装置１４を有さない構成とすることで、シミュレータ２９が必要になるものの、コスト増を抑制しやすくなる。
【符号の説明】
【００８４】
１１        スレッドスケジュール装置
１２        プロファイラ
１３        パイプライン制御回路
１４        実行状況監視装置
１５        演算回路
１６        レジスタファイル
１７        命令バッファ
１８        命令デコーダ
１９、２１  切り替えスイッチ
５０        プロセッサ
６０        アプリ実行プロファイル記憶部
１００      マルチスレッド実行装置
【図１】
2011008617.tif 000003
【図２】
2011008617.tif 000004
【図３】
2011008617.tif 000005
【図４】
2011008617.tif 000006
【図５】
2011008617.tif 000007
【図６】
2011008617.tif 000008
【図８】
2011008617.tif 000009
【図９】
2011008617.tif 000010
【図１０】
2011008617.tif 000011
【図１１】
2011008617.tif 000012
【図１２】
2011008617.tif 000013
【図１３】
2011008617.tif 000014
【図１４】
2011008617.tif 000015
【図１５】
2011008617.tif 000016
【図１６】
2011008617.tif 000017
【図７】
2011008617.tif 000018