JP2005216177A - コンフィグラブル・プロセッサの設計装置、設計方法、ライブラリの最適化方法、プロセッサ、及びプロセッサを備えた半導体装置の製造方法 - Google Patents

Abstract

【課題】 構成変更可能なプロセッサの設計において、拡張命令の定義処理、拡張命令及びハードウェア拡張の選択といった処理を自動的に行うこと。
【解決手段】 目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、プロセッサで実行するプログラムの内容を解析する解析部(122,132)と、解析部による解析結果に基づいて、プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成するハードウェア拡張部(142)と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部(141)と、ハードウェア拡張部が生成したハードウェア拡張情報と拡張命令定義部が生成した拡張命令定義のいずれか一方もしくは両方によって、プロセッサの性能が目標性能を満足するか否かを見積もる性能見積部(143)とを備える。
【選択図】 図１

Description

本発明は、目的に応じて構成変更可能なプロセッサの設計装置、設計方法、ライブラリの最適化方法に係り、特に、コンフィグラブル・プロセッサの設計におけるハードウェア拡張や拡張命令定義を自動化するための技術に関する。

目的に応じて命令を追加したり、構成を変更したりできるプロセッサを搭載したＳｏＣ（System on Chip）などのシステムＬＳＩ設計では、設計者は、開発対象のシステムに求められるアルゴリズムをＣ言語などの高級言語でソースプログラムを記述し、上位レベルでのシステムシミュレーションを行って所望する性能を達成したか否かを検証を行っている。検証の結果、所望の性能を達成していない場合は）、ボトルネックとなっている箇所を特定し、拡張命令（ユーザ定義命令）を新たに定義したり、拡張命令に置き換える部分やハードウェアに置き換える部分を選び出したりして、ソースプログラムを書き換え、システムシミュレーションを再度実行して、所望の性能が達成されたか否かを検証する。

このような一連の作業を軽減するために、例えば、検証環境や開発ツールを作成する装置（例えば、特許文献１参照）や、ハードウェアとソフトウェアの切り分け作業の初期段階における性能評価作業を支援する装置（例えば、特許文献２参照）が開示されている。
特開２００２−２３００６５号公報 特開２０００−５７１８８号公報

しかしながら、従来は、拡張命令の定義や命令セットの仕様を策定する作業や、解析結果に基づいてソースプログラムから拡張命令に置き換える部分やハードウェアに置き換える部分を選び出す作業などを、専ら人手によって試行錯誤をしながら行っていたため、非常に時間と手間のかかる作業となっていた。

また、拡張命令の定義方法や、拡張命令化及びハードウェア化の拡張方法には、様々な選択肢があるため、最適な定義方法や拡張方法を選択するためには、逐一検証する必要があり、非常に時間と手間のかかる作業となっていた。

また、システムシミュレーションを行って所望する性能を達成したか否かを検証する場合、従来は、ソースプログラムの関数毎の実行回数や命令毎の実行回数等を基にプログラムの動作状況を解析していたが、関数単位での解析では大まかな動作状況しか解析できず、命令単位の解析では命令の前後の関係が失われるため、大局的な判断ができないという問題があった。

また、従来は、ソースプログラムを動作させるにあたって、ユーザが新たに定義した拡張命令の命令セットを自動的に生成するような仕組みがなかった。

さらにまた、新たに定義された拡張命令よってソースプログラムを最適化することはできても、ソースプログラムの翻訳時等に用いられるライブラリを最適化することはできなかった。

本発明は、このような問題に鑑みてなされたものであって、構成変更可能なプロセッサの設計において、拡張命令の定義処理、拡張命令及びハードウェア拡張の選択といった処理を自動的に行うことができ、最適な拡張方法を選択できるコンフィグラブル・プロセッサの設計装置、設計方法、及びライブラリの最適化方法を提供することを目的とする。

上記課題を解決するため、本発明に係る設計装置の特徴は、目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、プロセッサで実行するプログラムの内容を解析する解析部と、解析部による解析結果に基づいて、プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成するハードウェア拡張部と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部と、ハードウェア拡張部が生成したハードウェア拡張情報と拡張命令定義部が生成した拡張命令定義のいずれか一方もしくは両方によって、プロセッサの性能が目標性能を満足するか否かを見積もる性能見積部とを備えることにある。

また、本発明に係る設計装置の別の特徴は、目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、プロセッサで実行するプログラムを実行し、その実行結果から得られるプロファイル情報を用いて動的解析情報を解析する解析部と、解析部による解析結果に基づいて、プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成するハードウェア拡張部と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備える。そして、動的解析部は、プログラムの命令列をブロックに分割する命令列分割部と、分割されたブロック単位で命令の実行回数をカウントする命令実行部とを備え、ブロック単位でカウントした実行回数を動的解析結果として出力することにある。

また、本発明に係る設計装置の別の特徴は、目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、プロセッサで実行するプログラムの内容を解析する解析部と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分、あるいはユーザにより与えられた拡張命令化部分に対して、の拡張命令定義を生成する拡張命令定義部とを備える。そして、拡張命令定義部は、プログラムのうち拡張命令化候補のブロックに対し、当該ブロックの処理動作と等価な処理動作を行う拡張命令の生成の可否を判定する命令化判定部と、命令化判定部の判定結果に従って、ブロックの処理動作と等価な処理動作を行う拡張命令記述を生成する命令記述生成部とを備えることにある。

また、本発明に係る設計装置の別の特徴は、目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、プロセッサで実行するプログラムのための拡張命令を組み合わせて部分命令集合群を生成する部分命令集合生成部と、各部分命令集合を用いて行ったプログラムの翻訳結果から得られる構文解析情報と、翻訳結果を用いて実行したプログラムの実行結果から得られるプロファイル情報とから、各部分命令集合を用いることによる効果を解析する解析部と、解析部による解析結果に基づいて、所定の制約条件に最適な部分命令集合を選択し、選択した部分命令集合を拡張命令セットとして生成する命令セット生成部とを備えることにある。

また、本発明に係る設計装置の別の特徴は、目的に応じて構成変更可能なプロセッサで実行するプログラムの内容を解析する解析部と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備えるコンフィグラブル・プロセッサの設計装置であって、プログラムの翻訳に用いるライブラリを最適化するライブラリ・オプティマイザを備える。そして、ライブラリ・オプティマイザは、拡張命令定義内に定義された拡張命令に適合するプロセッサの命令列を解析する解析部と、解析部の解析結果に基づいて、ライブラリのバイナリコードに、該当する命令列が存在するか否かを検出する検出部と、検出部の検出結果に基づいて、ライブラリのバイナリコードを最適化するバイナリ変換部とを含むことにある。

また、本発明に係る設計方法の特徴は、目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、解析部が、プロセッサで実行するプログラムの内容を解析する段階と、ハードウェア拡張部が、解析部による解析結果に基づいて、プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する段階と、拡張命令定義部が、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する段階と、性能見積部が、ハードウェア拡張部が生成したハードウェア拡張情報と拡張命令定義部が生成した拡張命令定義のいずれか一方もしくは両方によって、プロセッサの性能が目標性能を満足するか否かを見積もる段階とを含み、プロセッサの性能が目標性能を満足するまで各段階の処理をコンピュータの各部に実行させることにある。

また、本発明に係る設計方法の別の特徴は、目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、命令列分割部が、プロセッサで実行するプログラムの命令列をブロックに分割する段階と、命令実行部が、プログラムを実行し、分割されたブロック単位で命令の実行回数をカウントし、カウントした実行回数を動的解析結果として出力する段階と、ハードウェア拡張部が、命令実行部による解析結果に基づいて、プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する段階と、拡張命令定義部が、命令実行部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する段階とを含み、各段階の処理をコンピュータの各部に実行させることにある。

また、本発明に係る設計方法の別の特徴は、目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、解析部が、プロセッサで実行するプログラムの内容を解析する段階と、命令化判定部が、解析部による解析結果に基づいて、プログラムのうち拡張命令化候補のブロックに対し、当該ブロックの処理動作と等価な処理動作を行う拡張命令の生成の可否を判定する段階と、命令記述生成部が、命令化判定部の判定結果に従って、ブロックの処理動作と等価な処理動作を行う拡張命令記述を生成する段階とを含み、各段階の処理をコンピュータの各部に実行させることにある。

また、本発明に係る設計方法の別の特徴は、目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、部分命令集合生成部が、プロセッサで実行するプログラムのための拡張命令を組み合わせて部分命令集合群を生成する段階と、解析部が、各部分命令集合を用いて行ったプログラムの翻訳結果から得られる構文解析情報と、翻訳結果を用いて実行したプログラムの実行結果から得られるプロファイル情報とから、各部分命令集合を用いることによる効果を解析する段階と、命令セット生成部が、解析部による解析結果に基づいて、所定の制約条件に最適な部分命令集合を選択し、選択した部分命令集合を拡張命令セットとして生成する段階とを含み、各段階の処理をコンピュータの各部に実行させることにある。

また、本発明に係るライブラリ最適化方法の特徴は、目的に応じて構成変更可能なプロセッサで実行するプログラムの翻訳結果から得られる構文解析情報と、翻訳結果を用いて実行したプログラムの実行結果から得られるプロファイル情報とからプログラムを解析する解析部と、解析部による解析結果に基づいて、プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備えるコンフィグラブル・プロセッサの設計装置において、プログラムの翻訳に用いられるライブラリをコンピュータにより最適化する最適化方法であって、解析部が、拡張命令定義内に定義された拡張命令に適合するプロセッサの命令列を解析する段階と、検出部が、解析部の解析結果に基づいて、ライブラリのバイナリコードに、該当する命令列が存在するか否かを検出する段階と、バイナリ変換部が、検出部の検出結果に基づいて、ライブラリのバイナリコードを最適化する段階とを含み、各段階の処理をコンピュータの各部に実行させることにある。

本発明によれば、構成変更可能なプロセッサの設計において、拡張命令の定義処理、拡張命令及びハードウェア拡張の選択といった処理を自動的に行うことができ、最適な拡張方法を選択できるコンフィグラブル・プロセッサの設計装置、設計方法、及びライブラリの最適化方法を提供することができる。

以下、本発明の実施形態を図面に基づいて説明する。尚、各図面を通じて同一もしくは同等の部位や構成要素には、同一もしくは同等の参照符号を付し、その説明を省略もしくは簡略化する。

以下に示すそれぞれの実施形態における、コンフィグラブル・プロセッサの設計装置は、ターゲットシステムに応じて、命令を追加したり、構成を変更したりすることができるコンフィグラブル・プロセッサ等を設計するための設計装置であり、例えば、中央処理装置、記憶装置、入力装置、出力装置などを備えたコンピュータシステムにより実現される。また、各実施形態に示す設計処理手順をコンピュータプログラムにして、コンピュータ読み取り可能な記憶媒体に格納し、上記コンピュータシステムにより実現される設計装置に読み取らせ、読み取らせたコンピュータプログラムに記述されている各処理を設計装置に実行させることができる。

［実施形態１］
図１に示すように、実施形態１における設計装置は、ツール生成部１０３、言語ツール１０４、シミュレータ１０５、拡張処理部１０９、入力／表示部１１４などを備えている。

ツール生成部１０３は、リターゲッタブルまたはコンフィギュラブルなプロセッサの開発環境生成ツールであり、プロセッサ構成情報１０２を入力し、入力したプロセッサ構成情報１０２に基づいて、言語ツール１０４、ライブラリ１１２、シミュレータ１０５等を生成する。プロセッサ構成情報１０２には、拡張命令定義やハードウェア拡張情報が含まれる。

言語ツール１０４は、翻訳部１２１と静的解析部１２２を備えている。翻訳部１２１は、例えばＣ言語により記述されたプログラム１０１を入力して、シミュレータ１０５で実行可能な実行形式１０６（アセンブリ記述）に変換するコンパイル機能を有する。プログラム１０１には、設計対象のプロセッサで実行したいアルゴリズムの全部または一部が記述されている。静的解析部１２２は、Ｃ言語記述をパース（構文解析）する機能が含まれており、構文木、データフロー解析結果、ループ解析結果、変数のライフタイム解析結果等を静的解析情報１０７として出力する。

シミュレータ１０５は、シミュレータ部１３１と動的解析部１３２とを備えている。シミュレータ部１３１は、言語ツール１０４が生成した実行形式１０６を用いてシミュレーションを実行する。また、動的解析部１３２は、プロファイル機能を有し、関数単位，文単位，命令単位の実行情報を解析し、動的解析情報１０８として出力する。

拡張処理部１０９は、拡張命令定義部１４１、ハードウェア拡張部１４２、性能見積部１４３を備えている。拡張命令定義部１４１は、静的解析情報１０７及び動的解析情報１０８を基に、プログラム１０１の中で拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する。ハードウェア拡張部１４２は、静的解析情報１０７及び動的解析情報１０８を基に、プログラム１０１の中でハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する。拡張命令定義部１４１により生成された拡張命令定義や、ハードウェア拡張部１４２により生成されたハードウェア拡張情報は、プロセッサ構成情報１０２に反映される。更に、ハードウェア拡張を行った場合には、プログラム１０１（Ｃ言語記述）にも反映される。性能見積部１４３は、拡張命令定義部１４１が生成した拡張命令定義とハードウェア拡張部１４２が生成したハードウェア拡張情報のいずれか一方もしくは両方によって、設定対象のプロセッサの性能が目標性能を満足するか否かを見積もる。つまり、性能見積部１４３は、制約条件１１０により目標性能（目的関数及び目標値）が与えられ、空間を探索しその目標値を満たす点（ハードウェア拡張方法および拡張命令定義の組み合わせが空間の点に対応する）を求める。目的関数としては、例えば、プログラム１０１の実行速度が挙げられる。

また、拡張命令定義部１４１及びハードウェア拡張部１４２は、外部より与えられる制約条件１１０を用いるようにすることもできる。制約条件１１０は、性能見積部１４３が探索する探索空間を限定する働きがある。制約条件１１０としては、例えば、ゲート数，コードサイズ，消費電力などがある。

図２は、コンフィグラブル・プロセッサを含むハードウェアおよびプロセッサ上で実行するソフトウェアの設計処理手順を例示している。

ここで説明する設計処理例では、設計対象のプロセッサがプログラム１０１を実行する速度を、所定の基準値以下に収めることを目的とする。

ステップＳ２０１において、プロセッサに実行させるアルゴリズムを、Ｃ言語を用いてプログラム１０１に記述し、入力／表示部１１４から入力する。また、プロセッサ構成情報１０２を入力／表示部１１４から作成する。更に、拡張（ハードウェア拡張化及び拡張命令化）を制約するための制約条件１１０とプロセッサの目標性能を、入力／表示部１１４から作成する。本情報は、エディタ等を使用して作成してもよいし、ＧＵＩを用いて必要項目を表示し、項目毎に値を入力することによって作成しても良い。

次に、ステップＳ２０２において、ツール生成部１０３は、プロセッサ構成情報１０２に従って、言語ツール１０４やシミュレータ１０５を生成（カスタマイズ）する。生成された言語ツール１０４の翻訳部１２１は、プログラム１０１をコンパイルして実行形式１０６に変換する。言語ツール１０４の静的解析部１２２は、プログラム１０１のコンパイル結果から得られる構文解析情報を用いて静的解析情報１０７を出力する。動的解析部１３２は、静的解析情報１０７として翻訳部１２１（コンパイラ）から生成されるアセンブリ記述やプログラム解析情報を使用する。プログラム解析情報には、Ｃ言語のプログラムを構成する各文に対するループのネスト数を表すループ情報、各関数を構成する命令数、各関数で使用する外部データのサイズ、コードサイズなどが含まれるものとする。

また、シミュレータ部１３１は、言語ツール１０４が生成した実行形式１０６を用いてシミュレーションを実行し、動的解析部１３２は、シミュレーションによる実行状態を解析し、動的解析情報１０８として出力する。動的解析部１３２は、動的解析情報１０８としてシミュレータ部１３１から生成されるプロファイル情報を使用する。プロファイル情報としては、各関数の呼び出し回数、各文および各命令の実行回数、プログラム１０１全体の実行命令数に対する関数毎の実行命令数の割合などが出力される。

次に、ステップＳ２０３において、拡張処理部１０９の性能見積部１４３は、静的解析情報１０７または動的解析情報１０８を基に評価を行う。動的解析情報１０８には、実行命令数、実行サイクル数などが含まれる。これらの情報からプロセッサによるプログラム１０１の実行速度を見積もり、ステップＳ２０４において、プロセッサによるプログラム１０１の実行速度が、制約条件１１０として与えられている目標性能に達しているか否かを判定する。また、制約条件１１０としてコードサイズが与えられている場合には、静的解析情報１０７に含まれるコードサイズと比較することにより、制約条件１１０を満たしているか否かを調べることができる。

見積もった実行速度が目標性能を満たし、且つ制約条件１１０も満足している場合、ステップＳ２１１以降の半導体装置の製造工程に移行する。

見積もった実行速度が目標性能を満たさない、または見積もった実行速度が制約条件１１０を満たさない場合、ステップＳ２０５において、拡張命令定義部１４１あるいはハードウェア拡張部１４２は、拡張命令化あるいはハードウェア拡張化を行って、制約条件１１０及び目標性能を満たすようにプロセッサのアーキテクチャを変更する。例えば、プログラム１０１内の複数の命令を集約して新たな単一の命令に定義し、定義した単一の命令をプログラム１０１で使用するようにする（拡張命令化）、あるいは、プログラム１０１でソフトウェア的に実行している処理を専用ハードウェアで代替する（ハードウェア拡張化）ことにより、プロセッサ全体の処理速度を向上することができる。ハードウェア拡張化は、あるまとまった処理（例えば関数）に対して行うため、拡張命令化よりも高い性能向上が期待できる。

拡張処理部１０９が行う拡張処理は、拡張命令化あるいはハードウェア拡張化の様々な方法の中から最適な拡張方法を探索する問題とみなすことができる。ここでは、静的解析情報１０７を使用して探索する場合と、動的解析情報１０８を使用して探索する場合について、説明する。探索問題を解くアルゴリズムには様々なものが提案されているが、ここでは、貪欲法を採用する。

まず、静的解析情報１０７を使用する場合について具体的に説明する。図３は拡張処理の手順を擬似コードで表現したものである。図３の0303行から0313行の処理では、静的解析情報１０７に基づいて、プログラム１０１の中のボトルネックとなっている関数（命令数が最も多い関数）を特定し、特定した関数に対して、制約条件１１０と目標性能を満たす拡張方法が選択される。同様に、0314行から0323行の処理では、静的解析情報１０７に基づいて、プログラム１０１の中のボトルネックとなっている文（命令数が最も多い文）を特定し、特定した文に対して、制約条件１１０と目標性能を満たす拡張方法が選択される。

プログラム１０１でソフトウェア的に実行している処理を専用ハードウェアで代替する場合、ゲート数の増加につながるが、どの程度ゲート数が増加するかは、高位合成ツールを使用することにより評価することができる。制約条件１１０としてゲート数が与えられた場合、この情報を用いることで制約条件１１０を満たすか否かを調べることができる。関数が外部データを参照している場合、処理の前でそのデータを専用ハードウェアに転送し、終了後にプロセッサ側に転送することが必要となる。関数を選択する場合に、この情報を考慮することにより処理能力をより正確に評価することもできる。

動的解析情報１０８を使用して最適な拡張方法を探索する場合は、シミュレータ１０５が実行形式１０６を用いてシミュレーションすることにより得られるプロファイル結果を参照する。これにより、プログラム１０１の中の各関数に対して、プログラム１０１全体の実行命令数に対する各関数の実行命令数の割合を取得できる。この割合の多い関数が、ハードウェア拡張化あるいは拡張命令化の候補となる。尚、静的解析情報１０７と動的解析情報１０８の両方を使用して最適な拡張方法を探索することも可能である。尚、ハードウェア拡張化あるいは拡張命令化の対象となる箇所を特定するのを自動化する以外に、ユーザが対象となる箇所を入力／表示部１１４から指定することもできる。

ステップＳ２０４の判定処理で、制約条件１１０を満たし、且つ目標性能も満足していると判定された場合、以下に示すステップＳ２１１以降の半導体装置の製造工程に移行する。

ステップＳ２１１において、ステップＳ２０１〜ステップＳ２０５で設計された結果を基に、設計されたプロセッサを含む半導体回路のマスクデータを作成する。

ステップＳ２１２において、ステップＳ２１１で作成されたマスクデータを基にマスクを作成する。

ステップＳ２１３において、ステップＳ２１２で作成されたマスクを用いて、上記プロセッサを含む半導体回路パターンを、半導体基板内及び半導体基板上に形成する。

図４は、ハードウェア拡張化あるいは拡張命令化の対象となる箇所を、入力／表示部１１４から指定するための表示画面の例である。

画面の向かって左側には、プログラム１０１を構成する関数を、各関数の呼び出し関係がわかるようにツリー状に表示する関数表示ウインド４０１が配置されている。画面の向かって右側には、関数のコードを表示するコード表示ウインド４０２が配置されている。

関数表示ウインド４０１に対して行うことができる操作は、次の５種類の操作である。

第１の操作は、ハードウェア拡張化対象の関数を選択する操作である。複数の関数を選択することも可能である。図４に示した例では、関数“foo200()”が選択されている。この操作によって選択された関数は、優先的にハードウェア拡張の対象となる。

第２の操作は、ハードウェア拡張化非対象の関数を選択する操作である。複数の関数を選択することも可能である。この操作によって選択された関数は、ハードウェア拡張の対象外となる。

第３の操作は、拡張命令化対象の関数を選択する操作である。複数の関数を選択することも可能である。この操作によって選択された関数は、優先的に拡張命令化の対象となる。

第４の操作は、拡張命令化非対象の関数を選択する操作である。複数の関数を選択することも可能である。この操作によって選択された関数は、拡張命令化の対象外となる。

第５の操作は、コード表示ウインド４０２にコードを表示する関数を選択する機能である。図４に示した例では、関数表示ウインド４０１で選択された関数“foo200()”のコードがコード表示ウインド４０２に表示されている。

コード表示ウインド４０２に対する操作は、次の２種類の操作である。

第１の操作は、拡張命令化対象のコード領域を指定する操作である。複数の領域を指定することも可能である。この操作によって指定された領域は、優先的に拡張命令化の対象となる。

第２の操作は、拡張命令化非対象のコード領域を指定する操作である。複数の領域を指定することも可能である。この操作によって指定された領域は、拡張命令化の対象外となる。

図５は、本実施形態における設計装置及び設計方法によって設計されるコンフィグラブル・プロセッサ５００の構成を例示している。コンフィグラブル・プロセッサ５００は、タイマ・カウンタ５０１、割込みコントローラ５０２、デバック機能５０３、オプション命令５０４、コンフィグラブル・プロセッサコア５０５、バス・インタフェース・ユニット（ＢＩＵ）５０６、命令キャッシュ／ＲＡＭ５０８及びデータキャッシュ／ＲＡＭ５０９を含むローカルメモリ５０７、グローバルバス・インタフェース・ユニット５１０、ＤＳＰユニット５１１、ユーザカスタム命令（ＵＣＩ）ユニット５１２、コプロセッサ５１３、ハードウェアエンジン５１４、ローカルバス５１６及びＤＭＡコントローラ５１７を含むデータストリーマ５１５などを備えている。本実施形態における設計装置及び設計方法によって、オプション命令５０４、ＤＳＰユニット５１１、ＵＣＩユニット５１２、コプロセッサ５１３、ハードウェアエンジン５１４等が拡張の対象となり、コンフィグラブル・プロセッサコア５０５の処理能力を補いつつ、コンフィグラブル・プロセッサ５００全体の高速化を図るように拡張される。

以上、説明したように、実施形態１における設計装置及び設計方法によれば、拡張命令の定義や、ハードウェア拡張および拡張命令の選択を自動的に行うことができるため、様々な拡張方法を短時間に評価することが可能となり、最適な拡張方法を選択することが可能となる。

［実施形態２］
実施形態２では、図１に示した設計装置の拡張処理部１０９、特に拡張命令定義部１４１において、プログラム１０１のうちの拡張命令化対象ブロックについて拡張命令化が可能か否かを判定し、可能であればそれと等価な拡張命令を定義した命令記述を生成する仕組みについて、詳細に説明する。

コンフィギュラブル・プロセッサでは、あらかじめ用意されている命令セットに加えて、アプリケーション向けの拡張命令をユーザが定義することができる。特に、プログラム１０１中でボトルネックとなっている部分を、より少ない命令列の拡張命令に置き換えることで、パフォーマンス、コードサイズとも改善され、非常に効果的である。しかし実際には、オペランドとして使えるレジスタの個数や使用できる演算器などの制約から、プログラムの一部をそのまま拡張命令に置き換えることができるのは稀である。従って、ユーザはプログラムの構成を変更するなどの試行錯誤をして、置き換え可能な拡張命令を見つけなければならず、非常に手間のかかる作業となっていた。

そこで、図６に示すように、実施形態２における拡張命令定義部１４１は、プログラム１０１のうち拡張命令化対象のブロック（ブロック情報６０１により対象ブロックが指定される）に対し、そのブロックの処理動作と等価な処理動作を行う拡張命令の生成の可否を判定する命令化判定部６０２と、命令化判定部６０２の判定結果に従って、拡張命令化対象のブロックの処理動作と等価な処理動作を行う拡張命令記述６０５を生成する命令記述生成部６０４を備えている。更に拡張命令定義部１４１は、拡張命令化対象のブロックを更に分割するブロック分割部６０３を備え、命令記述生成部６０４は、ブロック分割部６０３によって更に分割された各ブロックの一部または全部に対し、拡張命令記述６０５の生成を実行する。

尚、ブロック分割部６０３は、プログラム１０１に記述されている単一の文を複数のブロックに分割することもできる。命令記述生成部６０４は、分割して生成された各ブロックの中から、所定の変数を使用している文、あるいは所定のレジスタを使用している命令列を含むブロックに対し、拡張命令記述６０５の生成を実行することもできる。また、命令記述生成部６０４は、ブロック内で使用されている変数をプロセッサ外部のレジスタに割り当て、割り当てられたプロセッサ外部のレジスタとプロセッサ間の転送命令を定義した拡張命令記述６０５を生成することもできる。

図７は、拡張命令定義部１４１が行う拡張命令記述６０５を生成する処理の動作例を示している。

尚、以下に示す例では、拡張命令化の対象ブロックとして、図８に例示するプログラムの0811行から0814行までの文からなるブロックが指定され、複数種類用意されている命令拡張方法の中からコプロセッサ拡張が指定（命令拡張方法の方法は制約条件１１０で指定される）された場合について説明する。選択された命令化拡張方法により命令化判定の条件が変わってくるが、コプロセッサ拡張における命令化可能条件については、命令化判定処理の部分で説明する。また、既に図９に例示する命令をもつコプロセッサ５１３が付加されているものとする。

図８の0803行の“__cop”は、それをつけて宣言された変数をコプロセッサ５１３のレジスタに割り当てるよう、コンパイラ（翻訳部１２１）に指示をするための指示子である。図８のソースプログラムをコンパイルした結果のアセンブリコードを図１０に示す。

ステップＳ７０１において、命令化判定部６０２は、拡張命令化対象のブロックについて拡張命令の生成の可否を判定する。判定の結果（ステップＳ７０２）、拡張命令の生成が可能であれば、ステップＳ７０３において、命令記述生成部６０４は、拡張命令化対象のブロックの処理動作と等価な処理動作を行う拡張命令記述６０５を生成する。

ここで、コプロセッサ拡張における制約条件１１０として、拡張命令のオペランドは最大３個までとし、そのうちプロセッサコア５０５の汎用レジスタのオペランドは、最大２個まで定義可能であるとする。対象としているブロックは少なくとも４個のコアの汎用レジスタをオペランドとして必要になるため、命令化判定部６０２は、このブロックは命令化不可能と判定する。

次に、ステップＳ７０４において、ブロック分割部６０３は、現状のブロックをさらに分割して拡張命令化を試みる。ブロック分割部６０３は、ブロック内の0811〜0814行の各文が、一つ一つのブロックになるよう分割し、ステップＳ７０５〜ステップＳ７０９のループ処理で、分割した各ブロックに対して命令化を試みる。

図８の0811〜0813行の文は、図１０の1001〜1003行目の単一命令へそれぞれ変換されるため、ステップＳ７０６において、命令化判定部６０２は、命令化不要と判断し、0811〜0813行の文からなるブロックに対しては拡張命令化を行わない。それに対して、図８の0814行目の文は、図１０の1004〜1006行目までの３つの命令列へ変換されるため、命令化判定部６０２は、更にコプロセッサ拡張の制約条件１１０を満たすか否かを調べる。図８の0814行目の命令文は、プロセッサコア５０５のレジスタ２個の値、コプロセッサ５１３のレジスタの値、定数値を入力とし、結果をプロセッサコア５０５のレジスタへと返却している。定数値を即値オペランドではなく命令動作内に組み込めば、プロセッサコア５０５のレジスタオペランド２個、コプロセッサ５１３のレジスタオペランド１個で命令として定義できることになり、コプロセッサ拡張の制約条件１１０を満たす。従って、命令化判定部６０２は、0814行目の命令文については命令化可能と判定する。

ステップＳ７０８において、命令記述生成部６０４は、図１１に例示するように、(0814)行目の命令文から拡張命令の命令定義記述６０５を生成する。拡張命令の名前は、既存の命令と重複しないように、“cinst_”の後に拡張命令の通し番号（図１１に示した例では“0001”を付加したものとする。1101行目の引数には、図８の0814行目に出現する変数を書き出す。1103行目の動作定義部分には、図８の0814行目の文をそのまま書き出す。尚、命令の名前やオペコードは、ユーザが入力／表示部１１４から指定するようにしてもよい。

ここで、後述する『コンパイラによる最適化処理方法』を用いると、図１１に示す命令記述定義をコンパイラ（翻訳部１２１）に与えることで、図１１に定義したコプロセッサ命令も生成できるよう、コンパイラをカスタマイズできる。図８の0814行目の文は、拡張命令追加後のコンパイラを使ってコンパイルすると、図１２の1204行目のようなコンパイル結果になる。図１２に示すコードは、図１０に示すコードに比べて、命令が２つ減り、コードサイズ、実行命令数、実行サイクル数の削減に対して効果がある。このような処理をソースプログラムの多くの部分に適用すれば、さらに効果が大きくなる。また、従来はこのような命令追加を人手で行っていたが、本システムでは自動で行うため、開発期間の短縮化に大きく寄与する。尚、ここで説明した例では、ブロックの分割を文単位で行ったが、構文木解析を行い、複数の文を含む分割単位や、文の一部だけからなる分割単位を作ってもよい。また、Ｃ言語で記述されたプログラムを例に説明したが、他のプログラミング言語でもよく、アセンブリ言語やバイナリ形式でもよい。アセンブリ言語やバイナリ形式を処理する場合、ブロックの分割は命令列を分割すればよい。アセンブリ言語やバイナリ形式から生成した命令記述の動作部分は、命令化した命令列と等価なＣ言語等の記述として生成すればよい。

また、命令化判定部６０２は、オペランドの個数と等価な命令の存在を命令化判定条件としたが、演算の種類、ブロックに表れる文の種類などを、命令化判定条件に加えてもよい。例えば、１サイクルで終了する命令だけ定義可能な命令拡張方法では、ブロック内に乗算がある場合不可としてもよい。またメモリアクセスをする文や、関数呼び出しなどの制御文がブロック内にあれば、命令化不可としてもよい。

また、図７に例示したフローチャートでは、命令化対象ブロックが１つだけ指定された場合を例示しているが、複数の命令化対象ブロックに対して、図７の処理を繰り返し実行するようにして、複数の命令対象ブロックに対して拡張命令記述６０５を生成するようにしてもよい。また、図７のフローチャートでは、分割後のどのブロックも命令化ができなければ、次のステップＳ７１０へ進んでいるが、分割のパターンを数通り試みてそれでも命令化できなければ、次のステップＳ７１０へ進むようにしてもよい。更に、追加命令が増えすぎるのを抑えるため、命令化の採用／不採用を、ユーザが入力／表示部１１４から指定するようにしてもよい。

次に、プロセッサ外のレジスタに変数を割り当てる場合を例にして説明する。

命令化の対象となるブロックとして、図１３の1306行目の文が与えられたとする。尚、図１３に示すプログラムを、拡張命令なしの命令セットでコンパイルした結果のアセンブリコードを、図１４に示す。図１３の1306行目の文に対応するアセンブリコードは、1404〜1405行目のコードである。

図７のフローチャートに示すように、ステップＳ７０１において、命令化判定部６０２は、図１３の1306行目の文について拡張命令化の判定を行う。拡張命令の制限条件として、プロセッサコア５０５の汎用レジスタのオペランドは２個まで使用可能であるとすると、1306行目の文は、変数“tmp”，“a[i]”，“x[i]”に相当する３個のレジスタを使用するため、命令化判定部６０２は、ステップＳ７０２において、拡張命令化不可と判定する。

次に、ステップＳ７０３において、ブロック分割部６０３は、1306行目の文の分解を試みる。ブロック分割部６０３は、構文木解析を行って、1306行目の文を“Z=(a[i] + x[i]) / 2;”と“tmp=tmp+Z;”の２つのブロックに分解する。尚、変数“Z”は、文の分解により出現した中間変数である。

ステップＳ７０６において、命令化判定部６０２は、この２つのブロックに対して、拡張命令化が可能か否かを調べる。“Z=(a[i] + x[i]) / 2”のブロックは、中間変数“Z”が“a[i]”または“x[i]”に割り当てられたレジスタと共有できるか判断できないため、３個のレジスタオペランドが必要となる。従って、命令化判定部６０２は、“Z=(a[i] + x[i]) / 2”のブロックについては命令化不可と判定する。一方、“tmp=tmp+Z;”のブロックは１つの命令に変換されるため、命令化判定部６０２は、“tmp=tmp+Z;”のブロックについても拡張命令化不可と判定する。また、“Z=(a[i] + x[i]) / 2”の文を更に分割しても、１つの命令に変換されるブロックにしか分割されないため、プロセッサ外のレジスタ（外部レジスタ）への変数の割り付けを考慮した命令化判定のステップＳ７１０へ進む。

ここで、図１３に示す各文に出現する変数のデータ型や他の属性は、予めわかっているものとする。これらは公知のプログラム解析技術により容易に実現可能であり、プログラムを解析した結果を外部から与えてもよいし、プログラム解析機能を含めてもよい。

ここでは、ブロック内の変数の中から外部レジスタに割り付けるのに適当な変数を選び出す。本実施形態では、基本データ型のローカル変数ということから、変数“tmp”を外部レジスタに割り付けることとする。そうすると、1306行目の文におけるコアのレジスタは、変数“a[i]”及び変数“x[i]”に相当する２個だけとなり、ステップＳ７１１において、命令化判定部６０２は拡張命令化が可能と判定する。

ステップＳ７１２において、命令記述生成部６０４は、1306行目のブロックに相当する命令に加え、変数を外部レジスタに割り当てたため、拡張モジュール内のレジスタとプロセッサの汎用レジスタ間でデータ転送を行う命令も自動的に追加生成する。この結果、命令記述生成部６０４は、図１５に例示するような３個の命令を定義した命令定義記述６０５を生成する。図１５に例示する命令定義記述６０５の動作記述内に現れる変数“dspreg”が、拡張モジュール内のレジスタを表す変数であり、1501行目の“reg : 32 : dspreg;”で定義されている。また、命令“dspst”は、プロセッサのレジスタから拡張モジュールのレジスタへの転送命令であり、命令“dspld”が拡張モジュールのレジスタからプロセッサのレジスタへの転送命令である。また、1306行目の文から生成した命令“dinst_0001”の動作記述では、外部レジスタに割り当てられた変数“tmp”の代わりに“dspreg”を用いる。

ここで、後述する『コンパイラによる最適化処理方法』を用いると、図１５に示す命令記述定義をコンパイラ（翻訳部１２１）に与えることで、コンパイラがカスタマイズされ、図１３の1306行目の文のコンパイル結果は図１６のようになる。また、変数“tmp”が拡張モジュール内のレジスタに割り付けられるため、コンパイラは変数“tmp”への代入および参照をしている部分に対し、拡張モジュール内のレジスタへの転送命令を生成する。拡張モジュール内のレジスタとの転送命令がループの前後に挿入されることになるが、ループ内部の命令数が減ったため、実行命令数、実行サイクル数とも減少し、パフォーマンスは改善される。

［コンパイラによる最適化処理方法］
ここで、前述の『コンパイラによる最適化処理方法』について説明する。

ユーザが定義した拡張命令とその動作内容の定義をコンパイラ（翻訳部１２１）に与えると、コンパイラは、プログラム１０１内に記述された命令文のうち、ユーザが定義した拡張命令を用いた処理動作と同等の動作を行う命令文を、ユーザが定義した拡張命令に応じた機械語に最適化する。具体的には、コンパイラは、プログラム１０１の構文解析を行う際に、プログラム１０１内に記述された命令について文法規則への適合性を解析し、命令の組み合わせが拡張命令及び該拡張命令の動作内容を定義しているか否かを解析し、構文解析された拡張命令及び該拡張命令の動作内容の定義を記憶しておく。そして、コンパイラは、ソースプログラムから生成した機械語と、記憶しておいた拡張命令の動作内容とが一致するか否かを判定し、一致する場合、当該機械語を拡張命令の動作内容に応じた機械語に最適化する。

以上のようにして、コンパイラ（翻訳部１２１）は、ユーザが定義した拡張命令を用いたプログラム１０１のコンパイル処理を最適化することができる。

以上、実施形態２について詳細に説明したように、実施形態２によれば、従来は非常に手間がかかり困難であった、追加命令の定義を効率よく容易に行うことができる。また、コンパイラも自動的に命令追加に対応できるため、コードサイズの削減やパフォーマンスの改善効果を即座に得ることができる。

また、ブロック分割や外部レジスタ割り当てなどの機能を有しているため、ブロック内のさまざまなパターンの追加命令を生成することが可能であり、従来はユーザが試行錯誤をして求めていた拡張命令を、効率よく求めることができる。

［実施形態３］
シミュレーション結果に基づいて動的解析部１３２がプログラム１０１の動作を動的に解析する際に、例えば関数毎に実行回数等を解析すると、大まかな動作状況しか解析できなく、ある命令列が動作条件によって動作するかどうかを判別するのは難しい。また、命令毎に実行回数等を解析すると、命令の前後の関係が失われてしまい、大極的な判断ができなくなる。そこで実施形態３では、動的解析部１３２は、命令列を分岐や収斂のない基本ブロック単位に分割し、その基本ブロック単位での実行回数を解析する例を説明する。

図１７は、実施形態３における動的解析部１３２の構成例を示している。命令列分割部１７０３は、翻訳部１２１（コンパイラやアセンブラ）で生成された実行形式１０６の命令列１７０１と、ユーザが動作解析を行いたい（実行回数を取得したい）命令ブロックの情報であるユーザ指定分割情報１７０２を入力し、命令列１７０１をユーザ指定分割情報１７０２の範囲でブロック分割し、命令ブロック情報１７０４として出力する。命令列１７０１は、一般にオブジェクトコード、実行コードと呼ばれるものである。ユーザ指定分割情報１７０２は、動作解析を行おうとする命令列１７０１の範囲を、ユーザが入力／表示部１１４から指定した情報で、コードの開始アドレスと終了アドレスの組からなっている。尚、ユーザ指定分割情報１７０２は必須の情報ではなく、ユーザ指定分割情報１７０２が指定されなければ、命令列分割部１７０３は所定の範囲でブロック分割を実行する。

命令実行部１７０５は、命令列分割部１７０３が出力した命令ブロック情報１７０４を用いて、各命令ブロックについて命令ブロック毎の実行回数を解析し、解析結果を命令ブロック実行回数１７０６として出力し、動的解析情報１０８となる。

図１８は、命令列分割部１７０３の詳細な構成を例示している。分岐命令探索部１８０１は、ユーザ指定分割情報１７０２を入力し、ユーザにより指定されている分割範囲を探索範囲とする。分岐命令探索部１８０１は、命令列１７０１の開始アドレスを、分岐先のアドレスとして分岐収斂情報１８０２の初期値として記憶する。

次に、分岐命令探索部１８０１は、探索範囲中の命令列の中で、分岐を発生させる可能性のある命令を全て探索し、探索した分岐命令のアドレス及び分岐先のアドレスと、そのアドレスが分岐命令のものであるか分岐先のものであるかの情報を、分岐収斂情報１８０２として記憶する。分岐先のアドレスは、分岐命令が分岐条件を持っている場合は２カ所以上あるので、分岐命令探索部１８０１は、この全てのアドレスを分岐収斂情報１８０２に記憶する。

次に、分岐ブロック生成部１８０３は、ユーザ指定分割情報１７０２を命令ブロック情報１７０４として出力し、分岐収斂情報１８０２をアドレス順にソートし、ソートされた分岐収斂情報１８０２の前後の組み合わせを命令ブロックとして、命令ブロック情報１７０４に追加する。尚、分岐収斂情報１８０２から命令ブロック情報１７０４に変換する際に、終了アドレスが分岐先のアドレスである場合には、そのアドレスから１を減算する。また、その際に、開始アドレスが分岐アドレスならば、命令ブロックとしては分岐収斂情報１８０２に追加しない。

図１９は、命令実行部１７０５の詳細な構成を例示している。命令シミュレータ１９０６の内部で持つ、現命令と現命令アドレスを用いて命令ブロックの実行回数が計算される。命令シミュレータ１９０６が１つの命令を実行する度に以下の動作を行う。

まず、命令実行部１７０５は、シミュレーションを開始する前に先行命令情報１９０１を空にしておく。シミュレーション時には、ブロック情報計算部１９０２は、現命令アドレスと命令ブロック情報１７０４とから、現命令がどの命令ブロックに属しているかを計算し、結果をブロック情報１９０３として記憶する。

次に、情報比較部１９０４は、先行命令情報１９０１とブロック情報１９０３とを入力し、命令ブロック実行回数１７０６をカウントするか否かの判定を行う。情報比較部１９０４の出力は、ブロック情報１９０３が先行命令情報１９０１の命令ブロックと異なるか、または先行命令情報１９０１内の命令が分岐命令である場合には、真になり、その他の場合には偽となる。

次に、命令ブロック実行回数計算部１９０５は、情報比較部１９０４の出力が真の場合にのみ、ブロック情報１９０３に該当するブロックの実行回数を１増加させる。最後に、命令ブロック実行回数計算部１９０５は、情報比較部１９０４の出力値に関わらず、現命令とブロック情報１９０３とを、先行命令情報１９０１として登録する。

ここで、具体的な例を用いて、本実施形態３における動的解析部１３２の処理動作を説明する。尚、以下に説明する例では、ユーザ指定分割情報１７０２は、指定されていないものとする。

図２０は、動的解析部１３２が入力する命令列１７０１の一例である。命令列１７０１は、アドレス情報と命令との組み合わせで構成される。命令は、実際には２進表記のコードとなっているが、ここでは説明をわかりやすくするために、ニーモニックで表記している。本実施形態３では、“LD”，“ADD”，“SUB”，“JNZ”，“JMP”の５種類の命令が出現する命令列１７０１を用意した。ニーモニック中の“R”で始まる変数は、レジスタを表しており、()付きの数値は、メモリアクセスを表している。“LD”はロードストア、“ADD”は加算、“SUB”は減算、“JNZ”はゼロ以外で分岐、“JMP”が無条件分岐を行う命令を表している。

まず、命令列分割部１７０３に、図２０に示された命令列１７０１が入力されると、分岐命令探索部１８０１は、命令列１７０１の先頭アドレスである“0001”番地を、“分岐先”という属性で分岐収斂情報１８０２に記憶する。次に、分岐命令探索部１８０１は、この命令列１７０１内から分岐命令を探索する。命令列１７０１において、分岐命令は“0006”番地，“0009”番地，“000d”番地に存在し、そのうち“0006”番地の分岐命令は、条件分岐命令であり、条件が成立した場合には“000a”番地に分岐し、不成立の場合には“0007”番地の命令を実行する。そこで、分岐命令探索部１８０１は、“0006”番地を“分岐”という属性で、“000a”番地，“0007”番地を“分岐先”の属性で分岐収斂情報１８０２に登録する。同様にして処理を繰り返すと、図２１に示すような分岐収斂情報１８０２が得られる。最後に、分岐命令探索部１８０１は、図２１に示した分岐収斂情報１８０２をアドレス順にソートし、図２２に示すような分岐収斂情報１８０２が生成される。

次に、分岐ブロック生成部１８０３は、図２２に示したように生成された分岐収斂情報１８０２を入力し、命令ブロック情報１７０４を生成する。分岐ブロック生成部１８０３は、まず、分岐収斂情報１８０２の先頭から連続する２つの情報を読み出す。最初に読み出されるのは、“0001”番地（分岐先）と“0002”番地（分岐先）の情報で、これを命令ブロック情報１７０４の開始アドレスと終了アドレスとする。ここで、終了アドレスに属性が“分岐先”である情報を使う場合には、アドレスから１を減算することになっているので、開始アドレスが“0001”番地で、終了アドレスが“0001”番地という情報が得られ、分岐ブロック生成部１８０３は、これを命令ブロック情報１７０４に登録する。

次に分岐収斂情報１８０２から読み出される情報は、“0002”番地（分岐先）と“0006”番地（分岐）の組であるので、分岐ブロック生成部１８０３は、開始アドレスが“0002”番地で、終了アドレスが“0006”番地という情報を、命令ブロック情報１７０４に登録する。

次に分岐収斂情報１８０２から読み出される情報は、“0006”番地（分岐）と“0007”番地（分岐先）の組であるが、属性が“分岐”であるアドレスは、開始アドレスとして使用しないので、この組では何もしない。

次に分岐収斂情報１８０２から読み出される情報は、“0007”番地（分岐先）と“0009”（分岐）の組、というように処理を進めていくと、図２３に示すような命令ブロック情報１７０４が得られる。尚、この命令ブロック情報１７０４には、区別のため各ブロックに命令ブロック番号を振ってある。

最後に、命令実行部１７０５において命令のシミュレーションが行われ、命令ブロック実行回数１７０６が計算される。以下、最初の１０命令分について、具体的に説明する。尚、“0006”番地の条件分岐は成立し、“000a”番地にジャンプしたものとする。

（１）“0001”番地について…ブロック情報計算部１９０２は、“0001”番地の命令が命令ブロック番号“0”のブロックに属していると算出する。情報比較部１９０４の判定結果は、先行命令情報１９０１が空であるため不一致となり、命令ブロック実行回数計算部１９０５は、命令ブロック番号“0”の実行回数に１を加算する。そして、現命令“LD”と命令ブロック番号“0”を、先行命令情報１９０１に登録する。

（２）“0002”番地について…ブロック情報計算部１９０２は、“0002”番地の命令が命令ブロック番号“1”のブロックに属していると算出する。情報比較部１９０４の判定結果は、先行命令情報１９０１の内容が命令“LD”と命令ブロック番号“0”であるため、不一致となり、命令ブロック実行回数計算部１９０５は、命令ブロック番号“1”の実行回数に１を加算する。そして、現命令“LD”と命令ブロック番号“1”を、先行命令情報１９０１に登録する。

（３）“0003”番地について…ブロック情報計算部１９０２は、“0003”番地の命令が命令ブロック番号“1”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“LD”と命令ブロック番号“1”であるため、情報比較部１９０４の判定結果は一致となり、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“LD”と命令ブロック番号“1”を、先行命令情報１９０１に登録する。

（４）“0004”番地について…ブロック情報計算部１９０２は、“0004”番地の命令が命令ブロック番号“1”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“LD”と命令ブロック番号“1”であるため、情報比較部１９０４の判定結果は一致となり、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“ADD”と命令ブロック番号“1”を、先行命令情報１９０１に登録する。

（５）“0005”番地について…ブロック情報計算部１９０２は、“0005”番地の命令が命令ブロック番号“1”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“ADD”と命令ブロック番号“1”であるため、情報比較部１９０４は一致と判定し、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“LD”と命令ブロック番号“1”を、先行命令情報１９０１に登録する。

（６）“0006”番地について…ブロック情報計算部１９０２は、“0006”番地の命令が命令ブロック番号“1”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“LD”と命令ブロック番号“1”であるため、情報比較部１９０４は一致と判定し、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“JNZ”と命令ブロック番号“1”を、先行命令情報１９０１に登録する。

（７）“000a”番地について…ブロック情報計算部１９０２は、“000a”番地の命令が命令ブロック番号“3”のブロックに属していると算出する。先行命令情報１９０１の内容が命令“JNZ”と命令ブロック番号“1”であるため、情報比較部１９０４の判定結果は不一致となり、命令ブロック実行回数計算部１９０５は、命令ブロック番号“3”の実行回数に１を加算する。そして、現命令“SUB”と命令ブロック番号“3”を、先行命令情報１９０１に登録する。

（８）“000b”番地について…ブロック情報計算部１９０２は、“000b”番地の命令が命令ブロック番号“4”のブロックに属していると算出する。先行命令情報１９０１の内容が命令“SUB”と命令ブロック番号“3”であるため、情報比較部１９０４の判定結果は不一致となり、命令ブロック実行回数計算部１９０５は、命令ブロック番号“4”の実行回数に１を加算する。そして、現命令“LD”と命令ブロック番号“4”を、先行命令情報１９０１に登録する。

（９）“000c”番地について…ブロック情報計算部１９０２は、“000c”番地の命令が命令ブロック番号“4”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“LD”と命令ブロック番号“4”であるため、情報比較部１９０４は一致と判定し、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“SUB”と命令ブロック番号“4”を、先行命令情報１９０１に登録する。

（１０）“000d”番地について…ブロック情報計算部１９０２は、“000d”番地の命令が命令ブロック番号“4”のブロックに属していると算出する。先行命令情報１９０１の内容は、命令“SUB”と命令ブロック番号“4”であるため、情報比較部１９０４は一致と判定し、命令ブロック実行回数計算部１９０５は実行回数をカウントしない。そして、現命令“JNZ”と命令ブロック番号“4”を、先行命令情報１９０１に登録する。

同様の処理を繰り返すことにより、図２４に示す命令ブロック実行回数１７０６を得ることができる。尚、図２４に示した例は、“0006”番地の条件分岐が常に成立したものとした結果である。

以上説明したように、実施形態３によれば、従来はプログラムの動的解析時に関数毎や命令毎にしか実行回数等を解析できなかったものを、指定されたブロック毎の実行回数や、分岐や収斂の無い命令列毎の実行回数を解析することができる。

実行命令列の頻度解析に於いては、従来は全実行命令列を検索して調べることが必要であったし、割り込みが入った場合等は割り込みの処理の命令列も解析データに含まれてしまっていた。それに対して、実施形態３に示したような解析データを作成し、実行プログラムを検索して、該当するブロックの実行回数を加算していくことで、全実行命令列を検索したのと同等の解析結果を容易に得ることができる。このように、実行プログラムのサイズは、一般的に全実行命令列に比べると非常に小さなものとなるので、検索にかかる時間を大幅に短縮することが可能である。対話的な処理の場合には待ち時間の短縮につながるので、特に効果がある。

［実施形態４］
実施形態４では、コンフィグラブル・プロセッサの設計装置において、プログラム１０１を動作させるにあたってユーザの与えた制約条件１１０を満たすユーザ定義命令（拡張命令）を、命令セットとして生成する例について、以下に示す第１〜２実施例で説明する。更に、命令セットの一部を実行時に切り替えて使うための部分命令セットと、それに対応したプロセッサについて、以下に示す第３実施例で説明する。

［第１実施例］
図２５は、実施形態４（第１実施例）における設計装置の構成例を示している。この設計装置は、部分命令集合生成部２５０２、プログラム解析部２５０３、命令セット生成部２５０４などを備えている。部分命令集合生成部２５０２は、プロセッサで実行するプログラム１０１のためのユーザ定義命令（拡張命令）を組み合わせて部分命令集合群｛U_0，U_1，…，U_n｝を生成する。プログラム解析部２５０３は、各部分命令集合を用いて行ったプログラム１０１の翻訳結果から得られる構文解析情報と、翻訳結果を用いて実行したプログラム１０１の実行結果から得られるプロファイル情報とから、各部分命令集合を用いることによる効果を解析する。命令セット生成部２５０４は、プログラム解析部２５０３による解析結果に基づいて、制約条件１１０に最適な部分命令集合を選択し、選択した部分命令集合を拡張命令セット定義２５０５として生成する。

まず、ユーザは、設計装置の入力として、プロセッサ上で動作させるプログラム１０１と、ユーザ定義命令群Uを与える。

ステップＳ２５０２において、部分命令集合生成部２５０２は、入力として与えられたユーザ定義命令群Uの命令を組み合わせて、部分命令集合U_x｛x=0，1，…，n｝を生成する。全ての命令の組み合わせについて生成したものを、集合U_all = ｛U_0，U_1，…，U_n｝とする。

プログラム解析部２５０３は、集合U_allの個々の部分命令集合U_x｛x=0，1，…，n｝について、以下の手順でプログラムのコンパイルと解析を行う。

ステップＳ２５１２において、プログラム解析部２５０３は、部分命令集合U_xをユーザ定義命令の命令セットとして用い、プログラム１０１をコンパイルし、アセンブリコード及びオブジェクトコードを生成する。この時、コンパイラは、実施形態２で説明した『コンパイラによる最適化処理方法』の技術を用いることで、ユーザ定義命令を使って、コードサイズが最小に最適化されるアセンブリコードを生成する。

ステップＳ２５１３において、プログラム解析部２５０３は、ステップＳ２５１２で生成したオブジェクトコードをシミュレータ上で実行し、プロファイル結果から基本ブロックごとの実行回数を記録する（動的解析）。また、プログラム解析部２５０３は、コンパイルしたプログラムのアセンブリコードから、基本ブロック毎に命令数を記録する（静的解析）。

ステップＳ２５１４において、プログラム解析部２５０３は、ステップＳ２５１３で記録した基本ブロックごとの実行回数と基本ブロック毎の命令数との乗算で、基本ブロック毎の実行命令数を求める。同様の手順で、基本ブロックごとの実行命令数を全てのブロックについて求め、合計した値がプログラム全体の実行命令数となる
ステップＳ２５１５において、命令セット生成部２５０４は、プログラム解析部２５０３で求めた実行命令数が、ユーザの与えた制約条件１１０を満たすような部分命令集合U_xが、１つ以上存在するか否かを判定する。判定の結果、制約条件１１０を満たす部分命令集合U_xが存在する場合、ステップＳ２５１６において、命令セット生成部２５０４は、それらのうち命令定義数が最小である部分命令集合U_xを、拡張命令セット定義２５０５として出力する。

次に、具体例について詳細に説明する。

図２６に示すような、Ｃ言語で記述されたプログラム１０１を、設計装置の入力として与える。このプログラムは、３つの基本ブロックから構成されている。また、図２７に示すようなユーザ定義命令群Uを、設計装置の入力として与える。

プログラム解析部２５０３において、図２６の入力のプログラム１０１をコンパイルすると、コンパイル結果としてアセンブリコードが得られる。

図２８は、図２７のユーザ定義命令群Uを使わずに、図２６のプログラム１０１をコンパイルした結果を示している。図２８のアセンブルリストを、アセンブルリストA<empty>と呼ぶことにする。アセンブルリストA<empty>のアセンブリコードに使われている命令は、プロセッサにおいて標準的に利用可能なコア命令のみである。

それに対して、図２７のユーザ定義命令群Uを使ってアセンブルした結果を、図２９に示す。図２９のアセンブルリストを、アセンブルリストA<muldivi, muldiv2>と呼ぶことにする。アセンブルリストA<empty>とアセンブルリストA<muldivi, muldiv2>を比較すると、アセンブルリストA<empty>の３〜５行目が“muldivi”命令に、また１１〜１２行目が“muldiv2”命令に置き換えられており、コード中の命令数が減少していることがわかる。命令数が減少していることから、実行時の実行命令数も減少することがわかる。

次に、命令セット生成部２５０４において、制約条件１１０を満たし、且つユーザ定義命令数が最小になるような部分命令集合U_xを求める。ここでは、制約条件１１０として「実行命令数が６６命令以下」という制約条件１１０を入力として与えるものとする。

図２８より、基本ブロック毎の実行回数と命令数の積和として実行命令数を求めると、アセンブルリストA<empty>の実行命令数は７１命令であり、制約条件１１０を満たしていない。また、図２９より、基本ブロック毎の実行回数と命令数の積和として実行命令数を求めると、アセンブルリストA<muldivi, muldiv2>の実行命令数は６２命令であり、このことから“muldiv2”命令及び“muldivi”命令を使うことで制約条件１１０を満たすということがわかる。

次に、命令セット生成部２５０４において、ユーザ定義命令数が最小になるような集合を求める。手順としては、入力で与えた最大の集合U_allから、ユーザ定義命令数を１つづつ減らした部分命令集合を求め、対応するアセンブリコードを生成するという処理を、制約条件１１０を満たす間繰り返す。

ここでは集合の候補として、
U={muldiv2, muldivi}
U_I={muldivi}
U_2={muldiv2}
の3つが考えられる。

具体的な手順としては、命令セット生成部２５０４は、部分命令集合U_Iに対応するアセンブリコードA<muldivi>と、ユーザ命令定義群U_2に対応するアセンブリコードA<muldiv2>を、命令変換によって導き出し、それぞれの集合が制約条件１１０を満たすかどうかをチェックする。

図３０に、アセンブリコードA<muldivi>を導き出した結果を示す。図３０から、アセンブリコードA<muldivi>の実行命令数は、６９命令であり、制約条件１１０を満たしていないことがわかる。

次に、アセンブリコードA<muldiv2>を導き出した結果を、図３１に示す。図３１から、アセンブリコードA<muldiv2>の実行命令数は、６４命令であり、ユーザ命令定義群U_2が制約条件１１０を満たしていることがわかる。

最終的に、命令セット生成部２５０４は、図３２に例示するように“muldiv2”命令を唯一の命令として持つユーザ命令定義群U_2を、拡張命令セット定義２５０５として出力する。

上記の例では、ユーザ命令定義群U_2が制約条件１１０を満たし、且つユーザ定義命令数が最小となる唯一の命令セット定義となったが、制約条件１１０の与え方によっては、複数のユーザ命令定義群が命令セット定義の条件を満たすこともある。例えば、上記の例において制約条件１１０が「実行命令数が７０命令以下」であった場合、ユーザ命令定義群U_Iとユーザ命令定義群U_2の両方が、条件を満たすことになる。このような場合は、条件を満たす命令セット定義を複数出力してもよい。また、ユーザが指定した以外の条件を考慮して順序を決定し、それに従って出力することも可能である。上記の例で、ユーザが指定していない「プログラム１０１中の命令数」を考慮することにした場合、ユーザ命令定義群U_Iに対応するアセンブリコードA<muldivi>が１５命令であるのに対して、ユーザ命令定義群U_2に対応するアセンブリコードA<muldiv2>は１６命令であるため、ユーザ命令定義群U_2よりユーザ命令定義群U_Iを優先して出力する。

［第２実施例］
第１実施例では、制約条件１１０として「プログラムの実行命令数」及び「プログラムの命令数」を用いる例を説明したが、第２実施例ではそれ以外の制約条件１１０を用いる場合を考える。

まず、制約条件１１０としての「コードサイズ」については、プログラム１０１を命令セット定義を用いてアセンブルし、出力されるオブジェクトの大きさ（サイズ）によって求めることができる。

また、制約条件１１０としての「チップサイズ」については、求めるための幾つかの方法が考えられる。まずは、ユーザ定義命令毎に概算のチップサイズの値をユーザが制約条件１１０として与え、それらの値を合計して命令セット定義のチップサイズとする方法である。この応用として、複数のユーザ定義命令の組み合わせに対してチップサイズの値を与え、同様にして合計で命令セット定義のチップサイズを求める方法も考えられる。この方法は、複数のユーザ定義命令で演算器を共用可能な場合に有効である。例えば、図２７に示した“muldivi”命令と“muldiv2”命令は、どちらも乗算器と除算器を必要とするので、これらを両命令で共用することが考えられる。また、それぞれの命令セット定義毎に高位合成ツール等の外部ツールを用いて回路を生成し、チップサイズを見積もる方法も考えられる。

［第３実施例］
図３３は、実施形態４の第３実施例における設計装置の構成例を示している。この設計装置は、以下のような手順で処理を行う。第１実施例の手順と異なる部分は、命令セット生成部２５０４が、プログラム分割部３３０２と部分命令セット定義部３３０３に置き換わっていることと、入力であるユーザ定義命令群Uの命令オペコードに、未確定のオペコードが含まれていて良いということである。

まず、ユーザは、設計装置の入力として、プロセッサ上で動作させるプログラム１０１と、ユーザ定義命令群Uを与える。ユーザ定義命令群U中のユーザ定義命令には、オペコードに確定していない部分があってよい。

ステップＳ３３１１において、プログラム解析部３３０１は、入力として与えられたユーザ定義命令群Uを用いて、プログラム１０１をコンパイルし、アセンブリコード及びオブジェクトコードを生成する。また、プログラム解析部３３０１は、基本ブロック毎に各ユーザ定義命令の出現頻度を記録する。更に、プログラム解析部３３０１は、シミュレータのプロファイル結果から基本ブロックごとの実行回数を記録する。

ステップＳ３３１２において、プログラム分割部３３０２は、基本ブロックを単位として、同じユーザ定義命令群を使う基本ブロックの集合にまとめる。同じユーザ定義命令群を使う基本ブロックの集合を、命令ブロック集合と呼ぶことにする。

ステップＳ３３１３において、部分命令セット生成部３３０３は、ステップＳ３３１２で生成された命令ブロック集合のそれぞれについて、使用されているユーザ定義命令群を、部分命令セット定義として出力する。このとき、入力として制約条件１１０が与えられていれば、部分命令セット定義を出力する前に、第１実施例のステップＳ２５１６の手順と同様の手順で命令変換を行い、使用するユーザ定義命令を削減する。

ステップＳ３３１４において、部分命令セット生成部３３０３は、ユーザ定義命令群Uの命令のオペコードに未確定な部分があるか否かを判定し、未確定な部分がある場合、ステップＳ３３１５において、利用可能な範囲からオペコードを割り当てる。そして、部分命令セット生成部３３０３は、ステップＳ３３１６において、各々の命令ブロックの集合を、部分命令セット定義３３０５として出力する。

具体例を以下に示す。入力として、図３４に示すような、Ｃ言語で記述されたプログラム１０１と、図３５に示すようなユーザ定義命令群Umaxを与える場合を考える。図３５に示すように、ユーザ定義命令群Umaxには、“muldivi”命令，“max3”命令，“min3”命令の３つのユーザ定義命令が定義されている。図２７に示したユーザ定義命令群と異なる点は、オペコードに“*”が指定されている点である。オペコードは、その命令のビットパターンを１文字１ビットで表記したものであり、“0”，“1”は、対応するビットの値を示す。また“n”，“m”，“k”は、それぞれ対応するレジスタオペランドRn，Rm，Rkのレジスタ番号が、それぞれの位置に設定されることを示す。この部分は、アセンブリコードでのオペランド指定におけるレジスタ番号の値が、そのままエンコードされる。“_”は区切り文字で、データとしては無視される。“*”は、命令のオペコードのうちその部分が未確定であることを示す。

プログラム解析部３３０１が、ユーザ定義命令群Umaxを使って、図３４のプログラム１０１をアセンブルした結果、アセンブルリストA<muldiv2, muldivi, max3, min3>は、図３６に示すようになる。

次に、プログラム分割部３３０２は、アセンブルリストA< muldiv2, max3, min3>を基に、基本ブロック１〜４を命令ブロック集合に分割する。分割の手法はいろいろ考えられるが、ここでは単純に同じユーザ定義命令を使っているブロックをまとめることにする。その結果は、図３７に示すようになる。

次に、部分命令セット生成部３３０３は、各命令ブロック集合に対応する部分命令セット定義を生成する。この場合、命令ブロック集合IB1に対応する部分命令セット定義は、部分命令セット定義U_IB1={muldiv2}となり、命令ブロック集合IB2に対応する部分命令セット定義は、部分命令セット定義U_IB2={min3, max3}となる。命令ブロック集合IB3では、ユーザ定義命令が使われていないので、部分命令セット定義は出力されない。

更に、ユーザ定義命令群Umaxでは、オペコードの一部が未確定だったので、部分命令セット生成部３３０３は、割り当てるオペコードを決定する。ここでは制約条件１１０として、利用可能なオペコードの範囲を入力として与えることにする。仮に、利用可能なオペコードの範囲として「下位５ビットを自由に使える」という指定をしたとする。

図３８に示すように、各命令はオペコード上で下位から数えて５〜８ビット目が未確定（“*”）であるが、利用可能な範囲は１〜５ビット目のみであるため、割り当てを変更可能なのは５ビット目だけとなる。１ビットの変更で指定できるオペコードは２つだけであるため、“muldiv2”命令、“max3”命令、“min3”命令の３つの命令を同時に割り当てることはできない。そこで、部分命令セット定義U_IB1と部分命令セット定義U_IB2に、同じオペコードの範囲を割り当てることにする。各部分命令セット毎のユーザ定義命令は、それぞれ２命令以下であるから、このようにすることで、全ての命令にオペコードを割り当てることができる。

オペコードの割り当てを行った結果を、図３９に示す。オペコードの命令への割り当ては、ユーザが直接指定してもよいし、利用可能なオペコード集合から、部分命令セット生成部３３０３が自動的に割り当ててもよい。

図３９に示した例の場合、“muldiv2”命令と“max3”命令は同じオペコードになる可能性があるため、両方を同時に使うことはできず、何らかの手段で部分命令セット定義の切り替えを行う必要がある。切り替えの方法は、専用命令を使う方法や、特定の制御レジスタに値を設定して切り替える方法などが考えられる。

図４０は、基本ブロック毎の先頭に、専用命令である“switchiss”命令を挿入し、切り替えて使う方法を用いた例である。複数の部分命令セット定義を同じハードウェアに実装し、切り替えて実行することにより、このような命令セット定義を扱うことが可能になる。これらの部分命令セット定義は、例えばダイナミックリコンフィギュラブル回路上に実装することが考えられる。

以上説明したように、実施形態４によれば、ユーザの要求を制約条件１１０として与えることで、要求を満たす命令セットを自動的に求めることが可能になる。また、未確定のオペコードの割り当ても自動的に行うことができる。また、複数の部分命令セット定義を同一のハードウェアに割り当てることで、必要なユーザ定義命令の実行を可能にしながら、チップサイズの削減を行うことができる。

［実施形態５］
実施形態５では、プログラム１０１の翻訳等に用いられるライブラリを、コンフィギュラブル・プロセッサの拡張命令定義に応じて最適化するライブラリ・オプティマイザについて説明する。

図４１に例示するように、ライブラリ・オプティマイザは、解析部４１０１、検出部４１０４、変換部４１０７などを備えている。解析部４１０１は、拡張命令定義ファイル１１３内に定義された拡張命令に適合するプロセッサの命令列を解析する。検出部４１０４は、解析部４１０１の解析結果（対応表４１０２）に基づいて、ライブラリ１１２ａのバイナリコードに、該当する前記命令列が存在するか否かを検出する。バイナリ変換部４１０７は、検出部４１０４の検出結果４１０５に基づいて、ライブラリ１１２ａのバイナリコードを最適化する。

以下、上記の各部の処理動作例を詳細に説明する。

図４２は解析部４１０１の処理動作例を示している。

図４２に示すように、解析部４１０１は、まず拡張命令定義ファイル１１３を入力し、定義されている拡張命令を解析する（ステップＳ４２０１）。拡張命令定義ファイル１１３は、上記各実施形態の設計装置により生成されたファイルでもよいし、手動で生成されたファイルでもよい。拡張命令定義ファイル１１３は、ターゲットプロセッサの命令定義もすべて含んでいるものとする。

また、解析部４１０１は、入力した拡張命令定義ファイル１１３を、内部的にアセンブラ定義ファイル４１０３と、Ｃ言語ヘッダファイル４２１１あるいはＣ言語ヘッダファイル４２１１と同等の内部情報に変換するが、手動または自動で生成されたアセンブラ定義ファイル４１０３とＣ言語ヘッダファイル４２１１を、解析部４１０１が外部から入力できるようにしてもよい。

ステップＳ４２０１の解析の結果、拡張命令である場合、次に、解析部４１０１は、Ｃ言語ヘッダファイル４２１１から、拡張された命令について、これと等価なターゲットプロセッサの命令列の解析を行う（ステップＳ４２０３）。この処理については、実施形態２で説明した『コンパイラによる最適化処理方法』の技術を用いる。ただし、解析部４１０１は、中間コードではなく、アセンブラコードレベルの解析を行う。

拡張命令定義ファイル１１３内に定義されている命令が残っている場合は、ステップＳ４２０１に戻り、拡張命令定義ファイル１１３内に定義されている命令が終わるまで、以上の処理を繰り返す（ステップＳ４２０４）。

この結果、解析結果として、拡張された命令と、それに変換可能なターゲットプロセッサの命令列の対応表４１０２を生成することができる。

このとき、コードサイズが削減されるような解析結果のみを有効とする。これは、コードサイズが不変または増加する場合は、最適化する意味がないためであり、また、後述する変換部４１０７の局所的バイナリ変換のために必要であるためである。コードサイズについては、アセンブラ定義ファイル４１０３より情報が得られる。

図４３は検出部４１０４の処理動作例を示している。

図４３に示すように、検出部４１０４は、各ライブラリ１１２ａに対して、拡張命令への変換が可能な命令列を検出する。ライブラリ１１２ａは、すべてのライブラリを対象にしてもよいし、別途プロファイル情報を外部から入力し、最適化の対象とするライブラリ１１２ａ、さらには、ライブラリ１１２ａ内部の対象範囲を限定してもよい。検出対象を限定する場合、検出処理と変換処理を高速に行うことができる。いずれにしても、ライブラリ１１２ａを個々に走査しておくので、以下、単独のライブラリ１１２ａに対して検出と変換を行うことを前提に説明する。検出と変換の対象となるライブラリを、当該ライブラリと呼ぶ。当該ライブラリは、C言語から作成されたライブラリ１１２ａを前提とするが、条件を満たせば、それ以外でも可能である。詳細は後述する。

逆アセンブル結果生成部４３１１は、まずアセンブラ定義ファイル４１０３を使用して、当該ライブラリの逆アセンブル結果４１０６を生成する（ステップＳ４３０１）。そして、逆アセンブル結果生成部４３１１は、逆アセンブル結果４１０６から、解析部４１０１で生成した対応表４１０２を使用して、拡張命令に等価な命令列の検出を行い、検出結果４１０５として出力する（ステップＳ４３０３）。拡張命令に等価な命令列の検出方法は、実施形態２で説明した『コンパイラによる最適化処理方法』の技術を用いる。

ステップＳ４３０３の拡張命令に等価な命令列の検出において、収斂のある命令を含むことはできない。これを考慮するため、逆アセンブル結果生成部４３１１は、逆アセンブル時に、収斂のある命令に対して、ラベルを付加する（ステップＳ４３０２）。これにより、途中にラベルを含んだような命令列を、拡張命令に変換可能な命令列として検出されることを回避する。

逆アセンブル結果生成部４３１１は、ラベルの付加を、以下の手順で行う。

（１）逆アセンブル時に、無条件分岐命令の次の命令には、ラベルを付加しておく。

（２）ＰＣ相対の分岐命令に対しては、当該ライブラリ全体にわたって、オフセットを計算し、すべてのラベルを付加しておく。

（３）絶対アドレスへの分岐命令に対しては、当該ライブラリのリロケーション情報を検索して、すべてのラベルを付加しておく。

この結果、当該ライブラリがＣ言語から作成されたライブラリである場合は、当該ライブラリ中で収斂のある命令すべてにラベルを付加できたことになる。大域シンボルが、他のライブラリあるいはモジュールから参照される場合、それは必ず関数の先頭であり、その直前は、必ず無条件分岐命令になっている。Ｃ言語から当該ライブラリを作成するコンパイラで、関数の先頭の命令の直前命令が無条件分岐にならない場合は、コンパイラオプションの対応やコンパイラの実装で、必ず無条件分岐にするように修正することは、技術的に可能である。ポインタ参照により、収斂してくる場合は、Ｃ言語から作成されたライブラリである限り、関数の先頭に限定されるはずであり、上述のように検出可能である。

図４４は、変換部４１０７の処理動作例を示している。

図４４に示すように、変換部４１０７は、検出部４１０４の検出結果４１０５に基づいて、ライブラリ１１２ａのバイナリを最適化し変換する。

まず、変換部４１０７は、該当する命令列をすべて削除し、その一番小さいアドレスに変換する拡張命令のバイナリに変換する（ステップＳ４４０１）。変換した結果、余った領域は、隙間となる。

次に、変換部４１０７は、隙間を、該当した命令列の、次の命令以降の命令を、前に移動して詰めていく（ステップＳ４４０２）。このとき、変換部４１０７は、以下の処理を実行する。

（１）移動する命令がラベルの場合、当該ライブラリ全体にわたって、そのラベルへのＰＣ相対の分岐命令に対しては、その命令が移動しないのであれば、移動量によりオフセットを修正し、そのラベルへの絶対アドレスへの分岐命令に対しては、リロケーション情報を適切に修正する。

（２）移動する命令がＰＣ相対の分岐命令の場合、その分岐先が移動しない命令であれば、移動量によりオフセットを修正する。

（３）移動する命令が絶対アドレスへの分岐命令の場合、リロケーション情報を適切に修正する。

（４）移動する命令が無条件分岐命令（リターン命令を含む）の場合、上記（２）（３）の修正を行い、移動後に、移動を終了。移動する命令が無条件分岐命令でない場合は、さらに次の命令を前に移動してつめていく（ステップＳ４４０３）。

上述のように、無条件分岐命令を移動した後に処理を終了するため、変換処理を高速化できる。また、移動が終了した後、新たに生じた隙間は、そのまま放置してもよいし、“nop”命令で埋めることにより、デバッグ時の逆アセンブル結果を整形して見せるようにしてもよい。

最後に、変換部４１０７は、当該ライブラリを再アセンブルし、最適化されたライブラリ１１２ｂとして出力する。

次に、標準ライブラリの“atoi”関数を用いた実施例を説明する。ここで使用する“atoi”関数は、完全な関数ではないが、実施例としては十分である。図４５に例示するようなＣ言語でプログラミングされ、図４６に示すようにバイナリとして、ライブラリ化されているものとする。尚、図４６の(4501)行目の“rrrrrr”は、リロケーション情報を意味する。

ここで、命令拡張の定義として、図４７に示すような拡張命令定義が与えられたとする。この拡張命令定義は、拡張命令自動生成により生成されてもよいし、手動で生成されてもよい。ライブラリ・オプティマイザは、上記ファイルを直接入力してもよいし、図４８に示すような、別途生成されたアセンブラ定義ファイルとＣ言語ヘッダファイルを入力してもよい。

解析部４１０１は、Ｃ言語ヘッダヘッダファイルから、拡張定義された命令と等価なターゲットプロセッサの命令列の解析を行う。この解析には、実施形態２で説明した『コンパイラによる最適化処理方法』の技術を用いる。

すなわち、
“slad3 $t,$n,$n”
“mov $u,$t”
“add3 $t,$m,-48”
“sll $u,1”
“add3 $n,$t,$u”
の命令列は、拡張した命令
“digit $n,$u”
に変換可能であるという解析結果（対応表４１０４）を生成する。

検出部４１０４は、上記のバイナリに対して、逆アセンブル結果４１０６を生成する。上述した逆アセンブル結果の、
“_atoi”
“L50000”
“L5”
は、詳細説明の条件に従って検出できるラベルであり、検出部４１０４内部でラベルとして認識している。

検出部４１０４は、この逆アセンブル結果４１０６に対して、解析結果をもとに、“digit”命令に変換可能な命令列を検出する。この解析には、実施形態２で説明した『コンパイラによる最適化処理方法』の技術を用いる。

この結果、ラベルを含まない命令列
“slad3 $0,$0,$0”
“mov $12,$0”
“add3 $0,$11,-48”
“sll $12,1”
“add3 $0,$0,$12”
を、拡張した命令
“digit $0,$11”
に変換可能であるという検出結果４１０５を出力する。

変換部４１０７は、検出したコード列を隙間とし、隙間の先頭を拡張命令に変換する。この時点で、当該ライブラリは、図４９に示すようになる。余った隙間（4811行目〜4813行目）は “xxxx”で表示する。

次に、変換部４１０７は、隙間をうめるための移動を開始する。隙間となる“xxxx”を削除するように、それ以降の命令列を移動する。ラベル“L5”（4815行目）が移動されるので、それへのオフセットを使用している命令（“beqz”命令（4809行目））のバイナリも変換する。また、ＰＣ相対の分岐命令（“bra”命令（4814行目））も移動されるので、そのバイナリも変換する。“ret”命令（4816行目）は無条件分岐なので、それを移動した時点で、移動は終了する。移動の結果を図５０に示す。

新たに生じた隙間（4914〜4917行目）は、放置してもよいが、ここではデバッグ時の逆アセンブル結果の見栄えをよくするために、図５１に示すように、“nop”命令に変換しておく。

以上説明したように、実施形態５によれば、アプリケーションプログラムにリンクされるライブラリを拡張命令に応じて最適化することができ、より高速に実行可能なオブジェクトファイルを生成することができる。

以上、本発明の実施の形態について詳細に説明したが、本発明は、その精神または主要な特徴から逸脱することなく、他の色々な形で実施することができる。

従って、前述の各実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には何ら拘束されない。更に、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内のものである。

実施形態１における、構成変更可能なプロセッサの設計装置の構成例を示す概略ブロック図である。 図１に示した設計装置による設計処理手順を例示するフローチャートである。 拡張命令化及びハードウェア拡張化の処理手順を擬似コードで表現した一例を示す図である。 ハードウェア拡張化や拡張命令化の対象となる箇所を指定するための表示画面のレイアウト例である。 実施形態１における設計装置及び設計方法によって設計されるコンフィグラブル・プロセッサの構成を例示した図である。 実施形態２における拡張命令定義部の構成例を示す図である。 図６に示した拡張命令定義部が行う拡張命令記述を生成する処理の動作例を示すフローチャートである。 図６に示した拡張命令定義部が入力するソースプログラムの一例を示す図である。 拡張命令化前のコプロセッサの命令定義例を示す図である。 図６に示したソースプログラムをコンパイルした結果のアセンブリコードを例示する図である。 命令記述生成部が生成する拡張命令の命令定義記述の一例を示す図である。 拡張命令追加後のコンパイラを用いて、図８に示したソースプログラムをコンパイルした結果を例示する図である。 図６に示した拡張命令定義部が入力するソースプログラムの別の例を示す図である。 図１３に示すプログラムを、拡張命令なしの命令セットでコンパイルした結果のアセンブリコードを例示する図である。 命令記述生成部が生成する拡張命令の命令定義記述の一例を示す図である。 図１３に示すプログラムを、拡張命令を用いてコンパイルした結果のアセンブリコードを例示する図である。 実施形態３における動的解析部の構成例を示す図である。 図１７に示した動的解析部のうち、命令列分割部の構成例を示す図である。 図１７に示した動的解析部のうち、命令実行部の構成例を示す図である。 図１７に示した動的解析部が入力する命令列の一例を示す図である。 図１８に示した命令列分割部のうち、分岐命令探索部が出力する分岐収斂情報の一例を示す図である。 図２１に示した分岐収斂情報を、アドレス順にソートした結果を例示する図である。 図１８に示した命令列分割部のうち、分岐ブロック生成部が出力する命令ブロック情報の一例を示す図である。 図１８に示した命令ブロック実行回数計算部が出力する命令ブロック実行回数の一例を示す図である。 実施形態４（第１実施例）における設計装置の構成例を示す図である。 図２５に示した設計装置が入力するソースプログラムの一例を示す図である。 図２５に示した設計装置が入力するユーザ定義命令群の一例を示す図である。 図２７に示したユーザ定義命令群を使わずに、図２６のプログラムをコンパイルした結果を例示する図である。 図２７に示したユーザ定義命令群を使って、図２６のプログラムをコンパイルした結果を例示する図である。 ユーザ定義命令群U_Iによって導き出されたアセンブリコードA<muldivi>を例示する図である。 ユーザ定義命令群U_2によって導き出されたアセンブリコードA<muldiv2>を例示する図である。 命令セット生成部によって出力される命令セット定義の一例を示す図である。 実施形態４（第３実施例）における設計装置の構成例を示す図である。 図３３に示した設計装置が入力するソースプログラムの一例を示す図である。 図３３に示した設計装置が入力するユーザ定義命令群の一例を示す図である。 図３５に示したユーザ定義命令群を使って、図３４のプログラムをコンパイルした結果を例示する図である。 プログラム分割部によって分割された命令ブロックの集合を例示する図である。 ユーザ定義命令とそのオペコード（未確定コードを含む）の一例を示す図である。 ユーザ定義命令とそのオペコード（コード割り当て済み）の一例を示す図である。 部分命令セット定義の切り替えを使ったアセンブリコードの一例を示す図である。 実施形態５におけるライブラリ・オプティマイザの構成例を示す図である。 図４１に示したライブラリ・オプティマイザのうち、解析部の詳細な構成を例示する図である。 図４１に示したライブラリ・オプティマイザのうち、検出部の詳細な構成を例示する図である。 図４１に示したライブラリ・オプティマイザのうち、変換部の詳細な構成を例示する図である。 図４１に示したライブラリ・オプティマイザが最適化するライブラリに登録されている関数の一例を例示する図である。 図４５に示した関数のバイナリ例を例示する図である。 図４１に示したライブラリ・オプティマイザが入力する拡張命令定義ファイルの一例を示す図である。 図４１に示したライブラリ・オプティマイザが外部から入力するアセンブラ定義ファイルとＣ言語ヘッダファイルの一例を示す図である。 ライブラリ・オプティマイザが変換したライブラリデータの一例を示す図である。 図４９に示したライブラリデータの隙間を埋めるためにコードを移動した様子を例示する図である。 図５０に示した移動処理の結果、新たにできた隙間に“nop”命令を埋めた例を示す図である。

符号の説明

１０１…プログラム
１０２…プロセッサ構成情報
１０３…ツール生成部
１０４…言語ツール
１０５…シミュレータ
１０６…実行形式
１０７…静的解析情報
１０８…動的解析情報
１０９…拡張処理部
１１０…制約条件
１１２…ライブラリ
１１２ａ…ライブラリ（最適化前）
１１２ｂ…ライブラリ（最適化後）
１１３…拡張命令定義ファイル
１１４…入力／表示部
１２１…翻訳部
１２２…静的解析部
１３１…シミュレータ部
１３２…動的解析部
１４１…拡張命令定義部
１４２…ハードウェア拡張部
１４３…性能見積部
４０１…関数表示ウインド
４０２…コード表示ウインド
５００…プロセッサ
５０１…タイマ・カウンタ
５０２…割込みコントローラ
５０３…デバック機能
５０４…オプション命令
５０５…プロセッサコア
５０６…ＢＩＵ
５０７…ローカルメモリ
５０８…命令キャッシュ／ＲＡＭ
５０９…データキャッシュ／ＲＡＭ
５１０…グローバルバスＩ／Ｆユニット
５１１…ＤＳＰユニット
５１２…ＵＣＩユニット
５１３…コプロセッサ
５１４…ハードウェアエンジン
５１５…データストリーマ
５１６…ローカルバス
５１７…ＤＭＡコントローラ
６０１…ブロック情報
６０２…命令化判定部
６０３…ブロック分割部
６０４…命令記述生成部
６０５…拡張命令記述
１７０１…命令列
１７０２…ユーザ指定分割情報
１７０３…命令列分割部
１７０４…命令ブロック情報
１７０５…命令実行部
１７０６…命令ブロック実行回数
１８０１…分岐命令探索部
１８０２…分岐収斂情報
１８０３…分岐ブロック生成部
１７０４…命令ブロック情報
１９０１…先行命令情報
１９０２…ブロック情報計算部
１９０３…ブロック情報
１９０４…情報比較部
１９０５…命令ブロック実行回数計算部
１９０６…命令シミュレータ
２５０２…部分命令集合生成部
２５０３…プログラム解析部
２５０４…命令セット生成部
２５０５…拡張命令セット定義
３３０１…プログラム解析部
３３０２…プログラム分割部
３３０３…部分命令セット生成部
３３０５…部分命令セット定義
４１０１…解析部
４１０２…対応表
４１０３…アセンブラ定義ファイル
４１０４…検出部
４１０５…検出結果
４１０６…逆アセンブル結果
４１０７…変換部
４２１１…Ｃ言語ヘッダファイル
４３１１…逆アセンブル結果生成部

Claims (29)

1. 目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、
   前記プロセッサで実行するプログラムの内容を解析する解析部と、
   前記解析部による解析結果に基づいて、前記プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成するハードウェア拡張部と、
   前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部と、
   前記ハードウェア拡張部が生成した前記ハードウェア拡張情報と前記拡張命令定義部が生成した前記拡張命令定義のいずれか一方もしくは両方によって、前記プロセッサの性能が目標性能を満足するか否かを見積もる性能見積部と
   を備えることを特徴とするコンフィグラブル・プロセッサの設計装置。
2. 前記解析部は、前記プログラムの翻訳結果から得られる構文解析情報を用いて静的解析情報を解析する静的解析部と、前記プログラムの実行結果から得られるプロファイル情報を用いて動的解析情報を解析する動的解析部の少なくとも一方を含むこと
   を特徴とする請求項１記載のコンフィグラブル・プロセッサの設計装置。
3. 前記ハードウェア拡張化及び前記拡張命令化を制約するための制約条件を入力する入力部を備え、
   前記ハードウェア拡張部は、前記制約条件を満たすように前記ハードウェア拡張化を実行し、前記拡張命令定義部は、前記制約条件を満たすように前記拡張命令化を実行すること
   を特徴とする請求項１または請求項２のいずれか１項に記載のコンフィグラブル・プロセッサの設計装置。
4. 前記ハードウェア拡張化あるいは前記拡張命令化を実行する部分、または、前記ハードウェア拡張化あるいは前記拡張命令化の実行を禁止する部分を指定するための指示情報を入力する入力部を備えること
   を特徴とする請求項１ないし請求項３のいずれか１項に記載のコンフィグラブル・プロセッサの設計装置。
5. 目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、
   前記プロセッサで実行するプログラムを実行し、その実行結果から得られるプロファイル情報を用いて動的解析情報を解析する解析部と、
   前記解析部による解析結果に基づいて、前記プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成するハードウェア拡張部と、
   前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備え、
   前記動的解析部は、
   前記プログラムの命令列をブロックに分割する命令列分割部と、
   分割された前記ブロック単位で命令の実行回数をカウントする命令実行部とを備え、
   前記ブロック単位でカウントした前記実行回数を動的解析結果として出力すること
   を特徴とするコンフィグラブル・プロセッサの設計装置。
6. 前記命令列分割部は、前記プログラムの命令列のうち、分岐及び収斂を含まない命令列群を１ブロックとして分割すること
   を特徴とする請求項５記載のコンフィグラブル・プロセッサの設計装置。
7. 前記命令実行部は、前記分岐及び収斂を含まない命令列群からなるブロックの先頭命令の実行回数のみをカウントして、当該ブロックの実行回数とすること
   を特徴とする請求項６記載のコンフィグラブル・プロセッサの設計装置。
8. 目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、
   前記プロセッサで実行するプログラムの内容を解析する解析部と、
   前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分、あるいはユーザにより与えられた拡張命令化部分に対して、の拡張命令定義を生成する拡張命令定義部とを備え、
   前記拡張命令定義部は、
   前記プログラムのうち拡張命令化候補のブロックに対し、当該ブロックの処理動作と等価な処理動作を行う拡張命令の生成の可否を判定する命令化判定部と、
   前記命令化判定部の判定結果に従って、前記ブロックの処理動作と等価な処理動作を行う拡張命令記述を生成する命令記述生成部とを備えること
   を特徴とするコンフィグラブル・プロセッサの設計装置。
9. 前記拡張命令定義部は、前記ブロックを更に分割するブロック分割部を備え、
   前記命令記述生成部は、前記更に分割された各ブロックの一部または全部に対し、前記拡張命令記述の生成を実行すること
   を特徴とする請求項８に記載のコンフィグラブル・プロセッサの設計装置。
10. 前記ブロック分割部は、前記プログラムに記述されている単一の文を複数のブロックに分割すること
    を特徴とする請求項９に記載のコンフィグラブル・プロセッサの設計装置。
11. 前記命令記述生成部は、分割して生成された各ブロックの中から、所定の変数を使用している文、あるいは所定のレジスタを使用している命令列を含むブロックに対し、前記拡張命令記述の生成を実行すること
    を特徴とする請求項８に記載のコンフィグラブル・プロセッサの設計装置。
12. 前記命令記述生成部は、前記ブロック内で使用されている変数を前記プロセッサ外部のレジスタに割り当て、割り当てられた前記プロセッサ外部のレジスタと前記プロセッサ間の転送命令を定義した拡張命令記述を生成すること
    を特徴とする請求項８に記載のコンフィグラブル・プロセッサの設計装置。
13. 目的に応じて構成変更可能なプロセッサを設計するための設計装置であって、
    前記プロセッサで実行するプログラムのための拡張命令を組み合わせて部分命令集合群を生成する部分命令集合生成部と、
    各部分命令集合を用いて行った前記プログラムの翻訳結果から得られる構文解析情報と、前記翻訳結果を用いて実行した前記プログラムの実行結果から得られるプロファイル情報とから、前記各部分命令集合を用いることによる効果を解析する解析部と、
    前記解析部による解析結果に基づいて、所定の制約条件に最適な部分命令集合を選択し、選択した部分命令集合を拡張命令セットとして生成する命令セット生成部と
    を備えることを特徴とするコンフィグラブル・プロセッサの設計装置。
14. 前記制約条件は、プログラムの実行命令数、プログラムのコードサイズ、プロセッサのチップサイズのうち、少なくとも１つを含むこと
    を備えることを特徴とする請求項１３記載のコンフィグラブル・プロセッサの設計装置。
15. 前記命令セット生成部は、
    前記解析部による解析結果に基づいて、前記プログラムを部分プログラムに分割するプログラム分割部と、
    各部分プログラムで実行される命令の集合である部分命令セット定義を生成する部分命令セット定義生成部を備えること
    を特徴とする請求項１３記載のコンフィグラブル・プロセッサの設計装置。
16. 前記部分命令セット定義生成部は、各部分プログラムにオペコードが未定義の命令が含まれている場合、利用可能なオペコードを割り当てること
    を特徴とする請求項１５記載のコンフィグラブル・プロセッサの設計装置。
17. 前記部分命令セット定義生成部は、複数の前記部分命令セット定義に対して、同じオペコードの集合を割り当てること
    を特徴とする請求項１５記載のコンフィグラブル・プロセッサの設計装置。
18. 目的に応じて構成変更可能なプロセッサで実行するプログラムの内容を解析する解析部と、前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備えるコンフィグラブル・プロセッサの設計装置であって、
    前記プログラムの翻訳に用いるライブラリを最適化するライブラリ・オプティマイザを備え、前記ライブラリ・オプティマイザは、
    前記拡張命令定義内に定義された拡張命令に適合する前記プロセッサの命令列を解析する解析部と、
    前記解析部の解析結果に基づいて、前記ライブラリのバイナリコードに、該当する前記命令列が存在するか否かを検出する検出部と、
    前記検出部の検出結果に基づいて、前記ライブラリのバイナリコードを最適化するバイナリ変換部とを含むこと
    を特徴とするコンフィグラブル・プロセッサの設計装置。
19. 前記拡張命令定義は、アセンブラ定義ファイルとＣ言語によるヘッダファイルにより構成されることを特徴とする請求項１８に記載のコンフィグラブル・プロセッサの設計装置。
20. 前記検出部は、外部よりプロファイル情報を入力し、ライブラリのクリティカルな部分の最適化のみ行うこと
    を特徴とする請求項１８または請求項１９のいずれかに記載のコンフィグラブル・プロセッサの設計装置。
21. 前記変換部は、ライブラリ内の局所的なバイナリ変換を行うこと
    を特徴とする請求項１８ないし請求項２０のいずれか１項に記載のコンフィグラブル・プロセッサの設計装置。
22. 目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、
    解析部が、前記プロセッサで実行するプログラムの内容を解析する段階と、
    ハードウェア拡張部が、前記解析部による解析結果に基づいて、前記プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する段階と、
    拡張命令定義部が、前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する段階と、
    性能見積部が、前記ハードウェア拡張部が生成した前記ハードウェア拡張情報と前記拡張命令定義部が生成した前記拡張命令定義のいずれか一方もしくは両方によって、前記プロセッサの性能が目標性能を満足するか否かを見積もる段階とを含み、
    前記プロセッサの性能が前記目標性能を満足するまで前記各段階の処理を前記コンピュータの前記各部に実行させることを特徴とするコンフィグラブル・プロセッサの設計方法。
23. 目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、
    命令列分割部が、前記プロセッサで実行するプログラムの命令列をブロックに分割する段階と、
    命令実行部が、前記プログラムを実行し、分割された前記ブロック単位で命令の実行回数をカウントし、カウントした前記実行回数を動的解析結果として出力する段階と、
    ハードウェア拡張部が、前記命令実行部による解析結果に基づいて、前記プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する段階と、
    拡張命令定義部が、前記命令実行部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する段階とを含み、
    前記各段階の処理を前記コンピュータの前記各部に実行させることを特徴とするコンフィグラブル・プロセッサの設計方法。
24. 目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、
    解析部が、前記プロセッサで実行するプログラムの内容を解析する段階と、
    命令化判定部が、前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化候補のブロックに対し、当該ブロックの処理動作と等価な処理動作を行う拡張命令の生成の可否を判定する段階と、
    命令記述生成部が、前記命令化判定部の判定結果に従って、前記ブロックの処理動作と等価な処理動作を行う拡張命令記述を生成する段階とを含み、
    前記各段階の処理を前記コンピュータの前記各部に実行させることを特徴とするコンフィグラブル・プロセッサの設計方法。
25. 目的に応じて構成変更可能なプロセッサをコンピュータにより設計するための設計方法であって、
    部分命令集合生成部が、前記プロセッサで実行するプログラムのための拡張命令を組み合わせて部分命令集合群を生成する段階と、
    解析部が、各部分命令集合を用いて行った前記プログラムの翻訳結果から得られる構文解析情報と、前記翻訳結果を用いて実行した前記プログラムの実行結果から得られるプロファイル情報とから、前記各部分命令集合を用いることによる効果を解析する段階と、
    命令セット生成部が、前記解析部による解析結果に基づいて、所定の制約条件に最適な部分命令集合を選択し、選択した部分命令集合を拡張命令セットとして生成する段階とを含み、
    前記各段階の処理を前記コンピュータの前記各部に実行させることを特徴とするコンフィグラブル・プロセッサの設計方法。
26. 目的に応じて構成変更可能なプロセッサで実行するプログラムの翻訳結果から得られる構文解析情報と、前記翻訳結果を用いて実行した前記プログラムの実行結果から得られるプロファイル情報とから前記プログラムを解析する解析部と、前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する拡張命令定義部とを備えるコンフィグラブル・プロセッサの設計装置において、前記プログラムの翻訳に用いられるライブラリをコンピュータにより最適化する最適化方法であって、
    解析部が、前記拡張命令定義内に定義された拡張命令に適合する前記プロセッサの命令列を解析する段階と、
    検出部が、前記解析部の解析結果に基づいて、前記ライブラリのバイナリコードに、該当する前記命令列が存在するか否かを検出する段階と、
    バイナリ変換部が、前記検出部の検出結果に基づいて、前記ライブラリのバイナリコードを最適化する段階とを含み、
    前記各段階の処理を前記コンピュータの前記各部に実行させることを特徴とするライブラリの最適化方法。
27. 目的に応じて構成変更可能なプロセッサであって、
    解析部が、前記プロセッサで実行するプログラムを入力し、入力した前記プログラムの内容を解析する段階と、
    ハードウェア拡張部が、前記解析部による解析結果に基づいて、前記プログラムのうちハードウェア拡張化する部分を求め、求めたハードウェア拡張化部分のハードウェア拡張情報を生成する段階と、拡張命令定義部が、前記解析部による解析結果に基づいて、前記プログラムのうち拡張命令化する部分を求め、求めた拡張命令化部分の拡張命令定義を生成する段階と、性能見積部が、前記ハードウェア拡張部が生成した前記ハードウェア拡張情報と前記拡張命令定義部が生成した前記拡張命令定義のいずれか一方もしくは両方によって、前記プロセッサの性能が目標性能を満足するか否かを見積もる段階とを含み、前記プロセッサの性能が前記目標性能を満足するまで前記各段階の処理を前記コンピュータの前記各部に実行させる設計方法によって設計されることを特徴とするプロセッサ。
28. 請求項２２に記載の設計方法により設計されたプロセッサであって、
    前記複数の部分命令セット定義を同一のハードウェアに実装し、実装した前記複数の部分命令セット定義を、プロセッサを実行中に切り替えて実行すること
    を特徴とするプロセッサ。
29. 請求項２２に記載の設計方法において前記コンピュータの前記各部で実行された前記各段階の処理で得られた結果を基に、マスクデータを作成する段階と、
    作成された前記マスクデータを基にマスクを作成する段階と、
    作成された前記マスクを用いて、前記プロセッサを含む半導体回路の回路パターンを、半導体基板内及び半導体基板上に形成する段階とを有すること
    を特徴とするプロセッサを備えた半導体装置の製造方法。
    
    

Images