データプロセッサ
【課題】命令コード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コード空間を縮小する。
【解決手段】フラグ生成命令数が多い場合に１命令が生成するフラグ数を増やすことによって、フラグ生成命令数の減少がフラグ使用命令数の増加を上回るようにすることにより命令数の削減を実現するという観点を基に、オペランドのデータサイズに応じた複数フラグを生成する命令を定義する。例えば、縮小命令セットコンピュータ型のデータプロセッサにおいて、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグ（ｎｅｗＵ，ｎｅｗＴ）を生成する命令を命令セットに加える。
【解決手段】フラグ生成命令数が多い場合に１命令が生成するフラグ数を増やすことによって、フラグ生成命令数の減少がフラグ使用命令数の増加を上回るようにすることにより命令数の削減を実現するという観点を基に、オペランドのデータサイズに応じた複数フラグを生成する命令を定義する。例えば、縮小命令セットコンピュータ型のデータプロセッサにおいて、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグ（ｎｅｗＵ，ｎｅｗＴ）を生成する命令を命令セットに加える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マイクロプロセッサやマイクロコンピュータ等のデータプロセッサに係り、命令に対する効率的なコード割当を可能にする技術に関する。
【背景技術】
【０００２】
マイクロプロセッサは、１９８４年にモトローラ社が開発した６８０２０以来長らく３２ビットプロセッサが主流であった。３２ビットで指定できる２３２B=４GBは約２０年間にわたり十分大きなアドレス空間であったためである。しかしながら、システム性能向上に伴う必要メモリ容量の増大とメモリ単価の下落によって、近年、PC／サーバ分野で４ＧＢを越える空間を扱える６４ビットプロセッサが普及しつつある。そして、組込プロセッサにおいても、PC／サーバ分野に追随する形で数年から十年遅れで６４ビット化が進行すると予測される。
【０００３】
組込プロセッサは、性能最優先のPC／サーバ用プロセッサとは異なり、高効率と高性能の両立が求められる。この結果、高コード効率の実現可能な１６ビット固定長命令セットのRISC（Reduced Instruction Set Computer）型の組込プロセッサが普及している。高コード効率は、オフチップメモリの大容量化が進んだ現在においても、オンチップのキャッシュ、ＲＡＭやＲＯＭの有効活用には欠かせないものである。しかしながら、こうしたプロセッサを６４ビット化するには１６ビット固定長命令コード空間の効率的な活用が不可欠である。
【０００４】
また、３２ビットプロセッサの時代が長らく続いた結果、演算の基本が３２ビットとなり、８ビットや１６ビットのデータはプロセッサのレジスタ上で３２ビットに拡張して扱うか、４個の８ビットデータや２個の１６ビットデータとして３２ビット単位で扱うことが一般的となった。そして、６４ビットプロセッサにおいても、６４ビットの演算体系に加えて、こうした３２ビットを基本とした演算体系をサポートする必要がある。このため、既存の６４ビットプロセッサでは、必要に応じて同一演算に対して３２ビットと６４ビットの双方の演算命令を定義している。この結果、６４ビットプロセッサでは演算命令数が増大し、それらを定義するために必要なコード空間も増大している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平０６−３３７７８３号公報
【非特許文献】
【０００６】
【非特許文献１】PowerPC User Instruction Set Architecture Book I Version 2.02、Internet URL<http://www.ibm.com/developerworks/power/library/pa-archguidev2>、平成20年1月23日検索
【非特許文献２】SH-4A拡張機能ソフトウェアマニュアル、Internet URL<http://documentation.renesas.com/jpn/products/mpumcu/rjj09b0235_sh4asm.pdf>、平成20年1月23日検索
【非特許文献３】AMD64 Architecture Programmer’s Manual Volume１: Application Programming, Revision 3.11 、Internet URL<http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf>、平成20年1月23日検索
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述のように、１６ビット固定長命令コードのRISC型の組込プロセッサを６４ビット化するには命令のコード空間（単に命令コード空間とも証する）の効率的な活用が不可欠である。中でも、３２ビットプロセッサが３２ビット演算体系のみのサポートで済んだのに対して、６４ビットプロセッサにおいては３２ビットと６４ビットの双方の演算体系をサポートする必要がある。そして、このために既存の６４ビットプロセッサのように同一演算に対して３２ビットと６４ビットの双方の演算命令を定義すると、１６ビット固定長命令セットでは命令コード空間を圧迫し、既存の３２ビット演算体系並みの６４ビット演算体系を構築することが難しい。例えば３２ビットの演算体系を有する命令セットの命令のオペレーションコードが、８ビットで表すことが出来る２５６種類あるとき、複数の６４ビット演算命令を単に追加しようとすると、オペレーションコードのビット数を少なくとも1ビット増やすことが必要になり、命令コード空間が大きくなり、既存の３２ビットの演算の命令体系を維持することが出来なくなり。
【０００８】
特に、６４ビット演算の演算結果の下位３２ビットが３２ビット演算のそれと同一な場合でも、演算結果から生成するフラグが３２ビットと６４ビットの演算で異なる場合は異なる命令を定義する必要がある。生成するフラグのみが異なる場合、１命令で生成するフラグ数を増やすことによってフラグを生成する命令数を削減することが出来る。例えば、文献１のPowerPCでは１命令で正・負・ゼロ・オーバーフロー・キャリーといった複数種類のフラグを生成している。更に、文献２では複数種類の複数サイズ用のフラグを生成している。即ち「種類数」×「サイズ数」のフラグを生成している。文献２では「４種類」×「２サイズ」＝「８フラグ」である。
【０００９】
しかしながら、１命令で生成するフラグ数を増加させるとフラグを使用する命令数を増加させる必要がある。例えば、条件分岐命令の分岐条件は「どのフラグを使用するか」と「使用するフラグがセットされているかクリアされているか」の組合せで決定する方式が一般的である。文献２の条件分岐命令では、フラグの使い方を指定するフィールドに５ビット取っていて、３２通りの指定が可能となっている。したがって、条件分岐命令数は３２×「フラグ以外のバリエーション数」となる。フラグ以外のバリエーションとしてはディレイスロットの有無、分岐先アドレス指定方法等が考えられる。
【００１０】
このように「フラグ数の増加」は「フラグを生成する命令（フラグ生成命令）数の削減」に貢献する反面「フラグを使用する命令（フラグ使用命令）数の増大」を招く。したがって、文献２のようにフラグ数を増やせば命令数が削減できるとは限らない。文献２はCISC（Complicated Instruction Set Computer）を前提としており、主要なフラグ生成命令である演算命令はメモリオペランドも指定できるため数が多い。そして、フラグ数を増やして数の多い「フラグ生成命令数の削減」を行えば命令数を削減できた。一方、一般的なRISCは３２ビット固定長命令セットであり、命令コード空間に余裕があるため、命令数削減ニーズが小さい。このためRISCにおいてフラグ数を調整して命令数の最小化を図った例はない。しかし、１６ビット固定長命令セットのRISCの６４ビットプロセッサ化においては命令コード空間に余裕がない。また、RISCはCISCよりフラグ生成命令数が少ない。このため、フラグ数を増やすだけでは最適化ポイントを見出せない。そして、フラグ生成命令数とフラグ使用命令数のバランスが良くなる方式にすることが重要である。
【００１１】
本発明が解決しようとする第１の課題は、フラグ生成命令数の少ない命令セットにおいてフラグ数を調整して命令数を削減し、それらを定義するために必要なコード空間の最小化を図り、１６ビット固定長命令セットのRISCのように命令コード空間に余裕がないプロセッサの６４ビット化を可能にすることである。
【００１２】
また、一般に、フラグ数を増やしても、１命令で生成した複数のフラグを使用する例は少なく、１つだけを使用する場合が多い。一方、複数命令で生成したフラグを組み合わせて使用すると、プログラムを効率的に出来る場合がある。しかし、命令を実行する度に複数のフラグを更新すると、先行命令が生成したフラグを後続の命令が上書きしてしまうため、フラグを組み合わせて使用することは困難である。このため、生成したフラグを逐次レジスタに転送して、レジスタ上で論理演算してからフラグに戻したり、レジスタ上で論理演算した結果を数値として判定してフラグを生成したり、フラグを生成する度に条件分岐や条件実行をする必要がある。これらの方式は実行命令数が多くなったり、分岐頻度が増加したりするため効率が悪く性能が低下する。
【００１３】
特に、あるデータを演算対象としてみた場合、そのサイズが２種類であることはないため、複数種類のサイズに対するフラグを生成しても一方は不要である。適切な符号拡張またはゼロ拡張により、複数種類のサイズに対するフラグが同じ値になって、どちらでも使えるということはありうるが、一方が不要であることに変わりはない。したがって、複数のフラグを定義した場合、同時に更新するよりは、必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にすることも効果的である。しかしながら、これを実現するには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定する必要があり、最も大きな命令コード空間を必要とする。
【００１４】
本発明が解決しようとする第２の課題は、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することを可能にすることである。
【課題を解決するための手段】
【００１５】
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
【００１６】
本発明では、フラグ生成命令数が多い場合に１命令が生成するフラグ数を増やすことによって、フラグ生成命令数の減少がフラグ使用命令数の増加を上回るようにすることにより命令数の削減を実現するという観点を基に、オペランドのデータサイズに応じた複数フラグを生成する命令を定義すると言う手段を採用するものである。要するに、縮小命令セットコンピュータ型のデータプロセッサにおいて、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグを生成する命令を命令セットに加える。
【００１７】
第２の観点として、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にするには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定するという手段を採用する。すなわち、前記命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を命令セットに加える。
【発明の効果】
【００１８】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記のとおりである。
【００１９】
すなわち、第１の観点の発明により、命令セットを構成する命令の種類（命令数）が全体として少なくなる。したがって、命令コード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コードのコード空間縮小に寄与することができる。例えば、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００２０】
第２の観点の発明により、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明に係るデータプロセッサにおけるプロセッサコアの構成を概略的に例示するブロック図である。
【図２】本発明の実施形態１に係るプロセッサコアの実行ユニットを概略的に例示するブロック図である。
【図３】本発明の実施形態２に係るフラグ更新プレフィックス命令を概略的に例示する説明図である。
【図４】本発明の実施形態２に係るプロセッサコアの命令デコードユニットを概略的に例示するブロック図である。
【図５】本発明の実施形態２に係るプロセッサコアの実行ユニットを概略的に例示するブロック図である。
【図６】本発明の実施形態２に係るプロセッサコアの動作を概略的に例示する説明図である。
【図７】本発明に係るデータプロセッサの概略的な構成を例示するブロック図である。
【発明を実施するための形態】
【００２２】
１．実施の形態の概要
先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。
【００２３】
最初に上記夫々の観点について具体的に説明する。先ず、第１の観点に関し、１６ビット固定長命令セットのRISC型３２ビットプロセッサのフラグ生成命令数は、例えば文献３のSH-４Aプロセッサコアではオペランドフィールドが８ビットの命令が１７、４ビットの命令が１２である。尚、フラグを使用して更新する命令はフラグ生成命令としてカウントしている。また、６４ビットプロセッサ化に関係のない浮動小数点命令は除いている。一方、フラグ使用命令数は、オペランドフィールドが８ビットの命令が４、４ビットの命令が１である。そして、フラグ数は１である。フラグ数が少ないほどフラグ生成命令数が増え、フラグ使用命令数が減るため、SH-４Aプロセッサコアでは２９命令対５命令とフラグ生成命令数の方が約６倍多い。そして、２９のフラグ生成命令のうち２６命令はオペランドサイズによって動作が異なるため、単純に６４ビット命令を追加すると２６命令増加する。この結果、フラグ生成命令数とフラグ使用命令数の比は５５対５となり１１倍となる。
【００２４】
このようにフラグ生成命令数が多い場合、1命令が生成するフラグ数を増やすことによって比率を変えて命令数を削減することができる。増やし方としては、（１）フラグの種類、（２）オペランドサイズ、又は（３）その両方に応じたフラグを定義する方式が考えられる。
【００２５】
まず、（１）のフラグの種類に応じたフラグを定義する方式について考える。SH-４Aプロセッサコアのフラグの種類には、符号付大小、符号なし大小、ゼロ、オーバーフロー、キャリー、シフトアウトビット等がある。そして、フラグは１ビットなので、どの命令が立てたフラグかで意味が変わる。異なる演算が異なる種類のフラグを立てる場合、フラグの種類を増やしても命令数は減らないため、同一演算で生成するフラグのみ異なる場合に着目すると、比較命令が候補となる。比較命令は、符号付大小、符号なし大小、ゼロの３フラグを別フラグにすれば、１８命令を８命令にできる。他の命令はゼロ、オーバーフロー、キャリー、シフトアウトビット等を生成するが、演算が異なるためフラグを種類で分けても命令数削減効果はない。一方、フラグ使用命令数はフラグ種類数に応じて３倍になり、５命令から１５命令になる。この結果、フラグの関係する命令数は６０命令から１０命令減って１０命令増えるため６０命令のままである。
【００２６】
次に、（２）のオペランドサイズに応じたフラグを定義する方式について考える。３２ビットと６４ビットのオペランドサイズ毎にフラグを設けると、オペランドサイズによって動作が異なる２９命令のうち、下位３２ビットの動作が同一な１５命令を３２ビットと６４ビットで共通の命令とすることができる。一方、フラグは２倍となるため、フラグ使用命令数は５命令から１０命令になる。この結果、フラグの関係する命令数は６０命令から１５命令減って５命令増えるため５０命令に減少する。
【００２７】
更に、（３）の両方に応じたフラグを定義する方式を考える。まず、フラグを３種類にすることによって、比較命令を１８命令から８命令にできる。更にサイズ毎にフラグを定義することによって８命令を４命令にすることができる。また、比較命令以外のフラグ生成命令のうち下位３２ビットの動作が同一な命令を６命令削減できる。一方、フラグ使用命令数はフラグ種類数に応じて６倍になり、５命令から３０命令になる。この結果、フラグの関係する命令数は６０命令から２０命令減って２５命令増えるため６５命令に増加する。
【００２８】
以上のように、命令数最小化という観点からフラグ数を最適化すると、（２）オペランドサイズに応じてフラグを定義する方式が最善であることが明らかになった。
【００２９】
命令が消費する命令コード空間は命令がオペランドフィールドに使用するビット数によって大きく変化する。Nビットでは命令コード空間全体の２の(１６-N）乗分の一の空間を消費する。例えば８ビットならば１/２５６、４ビットならば１/４０９６の空間を消費する。このため、重要なのは８ビットオペランドフィールドの命令数の削減である。
【００３０】
そこで、上記考察を８ビットオペランドフィールドを有する命令（単に８ビットオペランドフィールド命令とも称する）に限定して行うと、３２ビットプロセッサのフラグ関連の８ビットオペランドフィールド命令は生成命令が１７、使用命令が条件分岐命令４の計２１命令であり、このうちオペランドサイズによって動作が異なる命令は生成命令の１５命令なので、単純に６４ビット命令を追加すると生成命令が１５命令増加して３２命令になり、計３６命令となる。
【００３１】
まず、（１）のフラグの種類に応じたフラグを定義する方式では、フラグを３種類にすることによって、比較命令を１７命令から６命令にできる反面、条件分岐命令が４命令から１２命令に増加するので、フラグの関係する命令数は３６命令から８命令減って８命令増えるため３６命令のままである。
【００３２】
次に、（２）のオペランドサイズに応じたフラグを定義する方式では、オペランドサイズによって動作が異なる１５命令のうち、下位３２ビットの動作が同一な１０命令を３２ビットと６４ビットで共通の命令とすることができる。一方、フラグは２倍となるため、条件分岐命令数は４命令から８命令になる。この結果、フラグの関係する命令数は３６命令から１０命令減って４命令増えるため３０命令に減少する。
【００３３】
更に、（３）の両方に応じたフラグを定義する方式を考える。まず、フラグを３種類にすることによって、比較命令を１４命令から６命令にできる。更にサイズ毎にフラグを定義することによって６命令を３命令にすることができる。また、比較命令以外のフラグ生成命令のうち下位３２ビットの動作が同一な命令を３命令削減できる。一方、フラグ使用命令数はフラグ種類数に応じて６倍になり、４命令から２４命令になる。この結果、フラグの関係する命令数は３６命令から１４命令減って２０命令増えるため４２命令に増加する。
【００３４】
以上のように命令コード空間消費に影響の大きい８ビットオペランドフィールド命令に限定しても（２）のオペランドサイズに応じてフラグを定義する方式が最善であることが解る。一方、文献２でCISCに適用した際は、命令のコードサイズ最小化に最善であった（３）の方式がRISCでは最悪の方式となっている。
【００３５】
本発明の第１の課題であるフラグ生成命令数の少ない命令セットにおいてフラグ数を調整して命令数を削減し、それらを定義するために必要なコード空間の最小化を図り、１６ビット固定長命令セットのRISCのように命令コード空間に余裕がないプロセッサの６４ビット化を可能にすることは、オペランドサイズに応じたフラグを定義することによって達成する。具体的には、３２ビットと６４ビットのオペランドサイズ毎にフラグを設け、３２ビットと６４ビットオペランドの命令で下位３２ビットの動作が同一な命令を統合し、フラグ数増加に応じた条件分岐等のフラグ使用命令数を増加させることにより達成する。これにより、命令セットを構成する命令の種類（命令数）が全体として少なくなる。
【００３６】
第２の観点に関しては、課題のところで述べたように、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にするには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定する必要があり、最も大きな命令コード空間を必要とする。
【００３７】
この問題を解決するには、後続命令を修飾する命令であるプレフィックス命令を定義すればよい。プレフィックス命令の実装は可変長命令セットの実装に類似しており、文献４の８７頁からの記載のようにプレフィックス命令を使うプロセッサは従来から存在する。そして、本分野の通常のスキルの技術者であればその実装は可能である。そして、どのようなプレフィックス命令を定義するかが重要となる。本発明ではフラグ更新プレフィックス命令として、更新するフラグの指定、後続命令が生成したフラグのうち使用するフラグの指定、指定した２つのフラグ間の論理演算の指定を行う。フラグを２種類、演算を８種類とすると、５ビットのオペランドフィールドで指定することができ、大きな命令コード空間を必要としない。論理演算も指定できるため、残したいフラグの更新抑止が可能な命令セットで論理演算を別命令で行う場合と同一の命令数でフラグ間の論理演算を実行することができる。これにより、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能となる。
【００３８】
上記観点を踏まえて代表的な実施の形態を説明する。
【００３９】
〔１〕縮小命令セットコンピュータ型のデータプロセッサは、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグ（ｎｅｗＵ，ｎｅｗＴ）を生成する第１命令を命令セットに有する。これにより、命令セットを構成する命令の種類（命令数）が全体として少なくなる。したがって、命令のコード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コード空間の縮小に寄与することができる。例えば、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００４０】
〔２〕項１のデータプロセッサは、例えば前記第１命令によって生成されたフラグを選択して使用する第２命令を更に前記命令セットに有する。
【００４１】
〔３〕項１のデータプロセッサは、例えば前記第１命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を更に前記命令セットに有する。これにより、複数のフラグを定義して必要なものだけを更新することができる。
【００４２】
〔４〕項１のデータプロセッサは、例えば前記第１命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を更に前記命令セットに有する。これにより、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にすることができる。したがって、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能になる。
【００４３】
〔５〕項１のデータプロセッサにおいて、例えば前記複数データサイズは、３２ビットと６４ビットである。
【００４４】
〔６〕項２のデータプロセッサにおいて、例えば前記フラグは、複数データサイズ毎の、符号付き大小、符号無し大小、ゼロ、オーバーフロー、キャリー、又はシフトアウトビットである。
【００４５】
〔７〕命令実行部（ＥＸＵ）を有する縮小命令セットコンピュータ型の別のデータプロセッサは、フラグの生成を伴う処理を実行するための第１命令及びフラグの使用を伴う処理を実行するための第２命令を命令セットに有する。前記命令実行部は命令デコード結果に従った処理を行なう演算回路（ＡＬＵ，ＳＦＴ）、フラグラッチ回路（Ｕ，Ｔ）及びフラグ選択回路（ＦＭＵＸ）を有する。前記演算回路は、前記第１命令のデコード結果に従って、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグを生成する。前記フラグラッチ回路は、前記第１命令のデコード結果に従って、前記演算回路で生成されたフラグをラッチする。前記フラグ選択回路は、前記第２命令のデコード結果に従って、前記フラグラッチ回路にラッチされたフラグを選択する。
【００４６】
〔８〕項７のデータプロセッサにおいて、例えば前記演算回路はデータサイズ毎に符号付き大小、符号無し大小、ゼロ、オーバーフロー、キャリー、及びシフトアウトビットのフラグを生成し、生成したフラグから一種類のフラグが第１命令で選択されてオペランドサイズ毎に前記フラグラッチ回路にラッチされる。
【００４７】
〔９〕項８のデータプロセッサにおいて、例えば前記複数データサイズは、３２ビットと６４ビットである。
【００４８】
〔１０〕更に別のデータプロセッサは、演算処理を行なって複数のフラグを生成可能な演算命令と共に、前記演算命令が生成した複数のフラグのうち後続命令が生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を命令セットに有する。
【００４９】
〔１１〕更に別のデータプロセッサは、演算処理を行なって複数のフラグを生成可能な演算命令と共に、前記演算命令が生成した複数のフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を命令セットに有する。
【００５０】
２．実施の形態の詳細
実施の形態について更に詳述する。以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。なお、発明を実施するための最良の形態を説明するための全図において、同一の機能を有する部材には同一の符号を付し、その繰り返しの説明は省略する。
【００５１】
《実施形態１》
図７には本発明に係るデータプロセッサＤＰＵが例示される。データプロセッサＤＰＵは中央処理装置のようなプロセッサコアＣＰＵを中心に、これに内部バスで接続された不揮発性メモリＲＯＭ、揮発性メモリＲＡＭ、入出力インタフェース回路ＩＯＣ、及び外部バスインタフェース回路ＥＢＩＦ等を備え、例えば相補型ＭＯＳ修正回路製造技術により単結晶シリコン等の１個の半導体基板に形成される。不揮発性メモリＲＯＭはプロセッサコアＣＰＵが実行するプログラム等の格納領域に利用され、揮発性メモリＲＡＭはプロセッサコアＣＰＵのワーク領域等に利用される。
【００５２】
図１にはプロセッサコアＣＰＵのブロック構成が概略的に例示される。例えばプロセッサコアＣＰＵは、命令キャッシュＩＣ、命令フェッチユニットＩＦＵ、命令デコードユニットＩＤＵ、実行ユニットＥＸＵ、ロードストアユニットＬＳＵ、データキャッシュＤＣ、及びバスインタフェースユニットユニットＢＩＵから成る。
【００５３】
命令フェッチユニットＩＦＵは命令アドレスＩＡを命令キャッシュＩＣに出力し、命令キャッシュＩＣは命令アドレスＩＡで指定されたアドレスからフェッチした命令ＦＩを命令フェッチユニットＩＦＵに返す。キャッシュミスした場合は、ミスしたアドレスを外部命令アドレスＥＩＡとしてバスインタフェースユニットユニットＢＩＵに出力し、外部フェッチ命令ＥＩを受け取ってから、命令ＦＩを命令フェッチユニットＩＦＵに返す。
【００５４】
命令デコードユニットＩＤＵは、命令フェッチユニットＩＦＵから命令ＯＰを受け取り、分岐制御信号ＢＲＣを出力する。また、命令ＯＰをデコードし、実行ユニットＥＸＵ及びロードストアユニットＬＳＵにそれぞれ実行制御情報ＥＸＣ及びロードストア制御情報ＬＳＣを出力すると共に、レジスタファイルＲＦにアクセスし、実行用オペランドＥＸＡ及びＥＸＢを実行ユニットＥＸＵに、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤをロードストアユニットＬＳＵに供給する。更に、実行結果ＥＸＯを実行ユニットＥＸＵから、ロードデータＬＤをロードストアユニットＬＳＵから受け取り、レジスタファイルＲＦに格納する。
【００５５】
実行ユニットＥＸＵは命令デコードユニットＩＤＵから実行制御情報ＥＸＣ、実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って演算実行した後、実行結果ＥＸＯを命令デコードユニットＩＤＵに返す。
【００５６】
ロードストアユニットＬＳＵは命令デコードユニットＩＤＵからロードストア制御情報ＬＳＣ、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤを受け取り、ロードストア制御情報ＬＳＣに従ってロードストア実行した後、ロードデータＬＤを命令デコードユニットＩＤＵに返す。また、ロードストアの際には、データキャッシュＤＣにデータアドレスＤＡを出力し、更にストアの際には、データキャッシュストアデータＤＣＳＤも出力する。そして、データキャッシュＤＣはロードの際にはデータキャッシュロードデータＤＣＬＤをロードストアユニットＬＳＵ返し、ストアの際はデータキャッシュストアデータＤＣＳＤをストアする。キャッシュミスした場合は、ミスしたアドレスを外部データアドレスＥＤＡとしてバスインタフェースユニットユニットＢＩＵに出力し、外部ロードデータＥＬＤを受け取ってから、データキャッシュロードデータＤＣＬＤをロードストアユニットＬＳＵに返す。また、キャッシュミスに伴うデータのコピーバックや、キャッシュしないデータの外部ストア時には、それらのデータを外部ストアデータＥＳＤとして出力すると共に、それらのデータのアドレスを外部データアドレスＥＤＡとして出力する。
【００５７】
バスインタフェースユニットＢＩＵは、命令キャッシュＩＣ又はデータキャッシュＤＣから、それぞれ外部命令アドレスＥＩＡ又は外部データアドレスＥＤＡを受け取り、プロセッサコアＣＰＵ外に外部アドレスＥＡを出力してデータを要求し、外部データＥＤとして受け取り、それぞれ外部フェッチ命令ＥＩ又は外部ロードデータＥＬＤとして出力する。また、データキャッシュＤＣから、外部データアドレスＥＤＡ及び外部ストアデータＥＳＤを受け取り、プロセッサコアＣＰＵ外に外部アドレスＥＡ及び外部データＥＤとして出力し、ストアリクエストを出す。
【００５８】
図２には、本発明の実施形態１に係るプロセッサの実行ユニットＥＸＵが概略的に例示される。実行ユニットＥＸＵは算術論理演算器ＡＬＵ、シフタＳＦＴ、３２ビットフラグマルチプレクサＦＭ３２、６４ビットフラグマルチプレクサＦＭ６４、３２ビットシフトアウトマルチプレクサＭ３２、６４ビットシフトアウトビットマルチプレクサＭ６４、出力マルチプレクサＯＭＵＸ、３２ビット演算用フラグＴ、６４ビット演算用フラグＵ、フラグマルチプレクサＦＭＵＸから成る。また、図示していないが命令デコードユニットＩＤＵからの実行制御情報ＥＸＣは各構成要素に入力されてそれらを制御する。
【００５９】
算術論理演算器ＡＬＵは命令デコードユニットＩＤＵから実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って各種算術論理演算を実行した後、実行結果ＡＬＯ、３２ビットフラグ群（符号付大ＧＴ３２，符号なし大ＧＵ３２、ゼロＺ３２、オーバーフローＶ３２、キャリーＣ３２）及び６４ビットフラグ群（符号付大ＧＴ６４，符号なし大ＧＵ６４、ゼロＺ６４、オーバーフローＶ６４、キャリーＣ６４）を出力する。
【００６０】
シフタＳＦＴは命令デコードユニットＩＤＵから実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って各種シフト演算を実行した後、実行結果ＳＦＯ、３２ビット左シフトアウトビットＳＬ３２、６４ビット左シフトアウトビットＳＬ６４、及び右シフトアウトビットＳＲを出力する。そして、３２ビットシフトアウトビットマルチプレクサＭ３２で、シフト演算の方向に応じて３２ビット左シフトアウトビットＳＬ３２又は右シフトアウトビットＳＲを選択して３２ビットフラグ群の１つである３２ビットシフトアウトフラグＳＦ３２として出力する。また、６４ビットシフトアウトビットマルチプレクサＭ６４で、シフト演算の方向に応じて６４ビット左シフトアウトビットＳＬ６４又は右シフトアウトビットＳＲを選択して６４ビットフラグ群の１つである６４ビットシフトアウトフラグＳＦ６４として出力する。
【００６１】
出力マルチプレクサＯＭＵＸは実行結果ＡＬＯ及び実行結果ＳＦＯの一方を実行制御情報ＥＸＣに従って選択し、実行結果EXOとして出力する。
【００６２】
３２ビットフラグマルチプレクサＦＭ３２は３２ビットフラグ群から命令の種類に応じてフラグを選択して、新たな３２ビットフラグｎｅｗＴを生成し、３２ビットフラグＴの入力とする。同様に、６４ビットフラグマルチプレクサＦＭ６４は６４ビットフラグ群から命令の種類に応じてフラグを選択し、新たな６４ビットフラグｎｅｗＵを生成し、６４ビットフラグＵの入力とする。３２ビットフラグＴ及び６４ビットフラグＵはこれらの入力をラッチし、フラグマルチプレクサＦＭＵＸに出力する。フラグマルチプレクサＦＭＵＸは使用する命令に応じて３２ビットフラグＴ及び６４ビットフラグＵの一方を選択し、フラグ出力ＦＯとして出力する。フラグマルチプレクサＦＭＵＸはラッチ後の値を使用して、次命令で使用するフラグを選択しており、図示していないが命令デコードユニットＩＤＵからの実行制御情報ＥＸＣとして、ラッチ前の値を使用することにより次命令の制御情報を受け取ることが出来る。
【００６３】
上記実施形態1により、命令セットを構成する命令の種類（命令数）を全体として少なくすることができる。したがって、命令コード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コードのコード空間縮小に寄与することができ、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００６４】
《実施形態２》
図３には、本発明の実施形態２に係るフラグ更新プレフィックス命令が概略的に例示される。フラグ更新プレフィックス命令は、更新するフラグの指定、後続命令が生成したフラグのうち使用するフラグの指定、指定した２つのフラグ間の論理演算の指定を行う。フラグを３２ビットフラグＴ及び６４ビットフラグＵの２種類とすると、更新するフラグの指定に１ビット、後続命令が生成したフラグのうち使用するフラグの指定に１ビット使用する。また、演算を６種類とすると、指定した２つのフラグ間の論理演算の指定には３ビット使用する。したがって、フラグ更新プレフィックス命令は５ビットのオペランドフィールドで指定することができ、大きな命令コード空間を必要としない。
【００６５】
１６ビット固定長命令セットで定義すると、図３のように１１ビットのオペレーションタイプ指定フィールドＯＰＴでフラグ更新プレフィックス命令であることを指定し、２ビットのソースデスティネーション指定フィールドＳＤで、更新するフラグの指定及び後続命令が生成したフラグのうち使用するフラグの指定を行い、３ビットの論理演算指定フィールドＴＹＰで指定した２つのフラグ間の論理演算の指定を行う。論理演算の種類は論理積ＡＮＤ、論理和ＯＲ、否定論理積ＡＮＤＮ、否定論理和ＯＲＮ、排他的論理和ＸＯＲ、新フラグＮＥＷの６種類であり、それぞれＴＹＰフィールドの０００から１０１を割り当てている。この演算の種類にソースとソースデスティネーションフラグを加えてニモニックとしている。ＳＤフィールドは上位がソース、下位がデスティネーションで、０が３２ビットフラグＴ、１が６４ビットフラグＵを指定することを表す。動作欄のｎｅｗＴは後続命令が生成した３２ビットフラグ、ｎｅｗＵは後続命令が生成した６４ビットフラグ、＆＝、｜＝、＾＝、＝、〜はＣ言語と同じ意味の演算子であり、＆＝は右辺の値と左辺の値との論理積を取って左辺の変数に代入、｜＝は右辺の値と左辺の値との論理和を取って左辺の変数に代入、＾＝は右辺の値と左辺の値との排他的論理和を取って左辺の変数に代入、＝は右辺の値を左辺の変数に代入、〜は右側の値を論理反転することを表す。
【００６６】
例えばＳＤ＝００、ＴＹＰ＝０００の場合は、論理演算の種類は論理積ＡＮＤ、更新するフラグ（デスティネーションフラグ）は３２ビットフラグＴ，後続命令が生成したフラグのうち使用するフラグ（ソースフラグ）も３２ビットフラグＴであり、ニモニックはＡＮＤＴＴ、動作はＴ＆＝ｎｅｗＴ；Ｕ：不変なので、３２ビットフラグＴと後続命令が生成したフラグのうち３２ビットフラグＴとの論理積を取って３２ビットフラグＴに格納し、６４ビットフラグＵは更新しないというフラグ更新プレフィックス命令となる。そして、後続命令の動作は、プレフィックス命令がなければ生成したフラグで３２ビットフラグＴ及び６４ビットフラグＵを更新するところを、上記フラグ更新プレフィックス指定の動作に置き換えられる。
【００６７】
本実施形態２と前述の実施形態１との構成上の違いは命令デコードユニットＩＤＵ及び実行ユニットＥＸＵに現れるため、プロセッサコアの代表的ブロック構成は実施形態１と同様に図１に示される。
【００６８】
図４には、本発明の実施形態２に係るプロセッサの命令デコードユニットＩＤＵが概略的に例示される。１サイクルに１命令発行するスカラプロセッサを例示するが、文献４のようにプレフィックス命令を使うプロセッサは従来から存在し、本分野の通常のスキルの技術者であればプレフィックスデコード及び発行方式のスーパースカラ、アウトオブオーダ等の他の発行形態への適用は可能である。また、本実施例ではフラグ更新プレフィックス命令のみがプレフィックス命令であることを前提としているが、他のプレフィックス命令も扱えるように拡張することも本分野の通常のスキルの技術者であれば可能である。
【００６９】
命令デコードユニットＩＤＵは、メインデコーダＤＥＣ及びプレフィックスデコーダＰＦ−ＤＥＣから成る。メインデコーダＤＥＣは命令フェッチユニットＩＦＵから供給される命令ＯＰをデコードし、実行制御情報ｏｐ−ｅｘｃを実効制御情報ＥＸＣの一部として実行ユニットＥＸＵへ、３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグＵの更新制御ｏｐ−ｗｒｕをプレフィックスデコーダＰＦ−ＤＥＣへ、ロードストア制御情報ＬＳＣをロードストアユニットＬＳＵへ、そして、レジスタファイル制御情報ＲＦＣをレジスタファイルＲＦへ出力する。尚、レジスタファイル制御情報ＲＦＣのうち、書込み情報は発行された命令がレジスタ書込みステージに達するタイミングで供給する。
【００７０】
ファイルＲＦはレジスタファイル制御情報ＲＦＣに基づいて、実行用オペランドＥＸＡ及びＥＸＢを実行ユニットＥＸＵに、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤをロードストアユニットＬＳＵに供給する。更に、実行結果ＥＸＯを実行ユニットＥＸＵから、ロードデータＬＤをロードストアユニットＬＳＵから受け取り、レジスタファイルＲＦに格納する。
【００７１】
プレフィックスデコーダＰＦ−ＤＥＣは、命令ＯＰのオペレーションタイプ指定フィールドＯＰＴをデコードし、命令ＯＰがフラグ更新プレフィックスであれば有効フラグｖを立て、そうでなければクリアする。また、２ビットのソースデスティネーション指定フィールドＳＤをそれぞれプレフィックスソースフラグ指定情報ｐｆｓｒｃとプレフィックスデスティネーションフラグ情報ｐｆｄｓｔとしてラッチする。更に、論理演算指定フィールドＴＹＰをプレフィックス論理演算指定情報ｐｆｔｙｐとしてラッチする。命令ＯＰがフラグ更新プレフィックス命令である場合、メインデコーダＤＥＣにもそれが供給される。この時、メインデコーダＤＥＣはフラグ更新プレフィックスをノーオペレーションコードとみなし、実行ユニットＥＸＵ及びロードストアユニットＬＳＵが何もしないような制御情報を出力する。
【００７２】
命令ＯＰがフラグ更新プレフィックス命令であった次のサイクルでは、メインデコーダＤＥＣは後続命令をデコードし、前述のように各種制御情報を出力する。一方、プレフィックスデコーダＰＦ−ＤＥＣでは、前サイクルでラッチした情報を使って処理を進める。命令ＯＰがフラグ更新プレフィックス命令であったため、有効フラグｖが立っており、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕとしては、それぞれプレフィックス論理演算指定情報ｐｆｔｙｐ、プレフィックスフラグソース指定情報ｐｆｓｒｃ、同じくプレフィックスフラグソース指定情報ｐｆｓｒｃ、プレフィックスデスティネーションフラグ情報ｐｆｄｓｔが０、及びプレフィックスデスティネーションフラグ情報ｐｆｄｓｔが１という情報を出力する。この結果、フラグ生成のための制御情報としては、メインでコーダからの３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグ更新制御ｏｐ−ｗｒｕがオーバーライドされ、フラグ更新プレフィックス命令の情報が出力される。
【００７３】
一方、命令ＯＰがフラグ更新プレフィックス命令でなかった次のサイクルでは、有効フラグｖが立っていないため、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕとしては、それぞれ１０１、０、１、３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグ更新制御ｏｐ−ｗｒｕを出力する。この結果、メインデコーダＤＥＣの出力が命令デコードユニットＩＤＵとして出力される。尚、メインデコーダＤＥＣ出力のない、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、及び６４ビットフラグソース情報ｓｒｕとして、それぞれ１０１、０、１出力することが命令本来の動作を指定している。
【００７４】
上記論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕはメインデコーダＤＥＣで生成される実行制御情報ｏｐ−ｅｘｃと共に実効制御情報ＥＸＣとして実行ユニットＥＸＵに出力される。
【００７５】
図５には、本発明の実施形態２に係るプロセッサの実行ユニットＥＸＵが概略的に例示される。図２に例示した実施形態１に係るプロセッサの実行ユニットＥＸＵと共通部分は同一の機能を有している。追加部分は、３２ビットフラグソースマルチプレクサＳ３２、６４ビットフラグソースマルチプレクサＳ６４、３２ビットフラグ論理演算器ＦＬ３２、及び６４ビットフラグ論理演算器ＦＬ６４である。
【００７６】
３２ビットフラグソースマルチプレクサＳ３２は、命令デコードユニットＩＤＵからの３２ビットフラグソース情報ｓｒｔに従って、新たな３２ビットフラグｎｅｗＴ又は新たな６４ビットフラグｎｅｗＵを選択し、３２ビットフラグ論理演算器ＦＬ３２に供給し、３２ビットフラグ論理演算器ＦＬ３２は、これと３２ビットフラグＴとから、論理演算指定情報ｔｙｐに従って、論理演算を行い、結果を３２ビットフラグＴにラッチする新たな値とする。同様に、６４ビットフラグソースマルチプレクサＳ６４は、命令デコードユニットＩＤＵからの６４ビットフラグソース情報ｓｒｔに従って、新たな３２ビットフラグｎｅｗＴ又は新たな６４ビットフラグｎｅｗＵを選択し、６４ビットフラグ論理演算器ＦＬ６４に供給し、６４ビットフラグ論理演算器ＦＬ６４は、これと６４ビットフラグＵとから、論理演算指定情報ｔｙｐに従って、論理演算を行い、結果を６４ビットフラグＵにラッチする新たな値とする。
【００７７】
上記のように本発明の実施形態２に係る命令デコードユニットＩＤＵ及び実行ユニットＥＸＵにより、大きな命令コード空間を必要としないフラグ更新プレフィックス命令による、残したいフラグの更新抑止、複数命令で生成したフラグ間の論理演算が可能となる。
【００７８】
次に、具体例によってフラグ更新プレフィックス命令の効果を説明する。図６には本発明の実施形態２に係るプロセッサの動作例が概略的に例示される。図６のＣプログラムは６４ビットポインタｐがＮＵＬＬポインタでなく、３２ビット変数ｉが１０より大きかったら｛｝内を実行せよというプログラムである。ＮＵＬＬポインタは何も指していない状態であり値が０となっている。
【００７９】
フラグ更新プレフィックス命令を含むアセンブラで、このＣプログラムを記述すると図６のように４命令で記述される。まず第１ステップで、ＣＭＰ／ＥＱ ｐ，０で６４ビットポインタｐとＮＵＬＬポインタ値０とを６４ビットサイズで比較し、比較結果を６４ビットフラグＵに格納する。６４ビットポインタｐがＮＵＬＬポインタの場合に６４ビットフラグＵがセットされる。即ち、Ｕ＝（ｐ＝＝ＮＵＬＬ）となる。このとき、３２ビットフラグＴには６４ビットポインタｐとＮＵＬＬポインタ値０の下位３２ビットを比較した結果が格納されるが本プログラムでは使用しない。第２ステップでは、フラグ更新プレフィックス命令ＯＲＮＴＵをデコードする。第３ステップでは、ＣＭＰ／ＧＴ ｉ，１０で３２ビット変数ｉが１０より大きかったら新たな３２ビットフラグｎｅｗＴが立つ。そして、フラグ更新プレフィックス命令ＯＲＮＴＵによって、Ｕ｜＝〜ｎｅｗＴとなるので、Ｕ＝（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）となる。このとき、３２ビットフラグＴは不変である。この結果、６４ビットフラグＵにはＣプログラムのｉｆ文の条件式の反転値が入っている。第４ステップでは、ＢＴ．Ｄ ＿ａｆｔｅｒ＿ｉｆ＿ｃｌｏｓｅによってＵが１、即ち条件式が不成立ならばｉｆ文の後ろに飛ぶのでｉｆ文は実行されない。
【００８０】
以上のようにフラグ更新プレフィックス命令を使うと複数の比較結果をまとめることが出来るため、１回の条件分岐で条件判定が完了する。フラグ更新プレフィックス命令を使わないと条件判定のたびに条件分岐を行う必要があり、これを高速化することは困難である。あるいは生成したフラグを汎用レジスタに転送して論理演算を行う場合、第２ステップのフラグ更新プレフィックス命令の代わりにフラグ転送命令ＭＯＶＵ Ｒ０を実行して生成したＵフラグを汎用レジスタＲ１に転送し、第４ステップの条件分岐の前に、フラグ転送命令ＭＯＶＴ Ｒ０を実行して生成したＴフラグを汎用レジスタＲ１に転送し、ＮＯＴ Ｒ０で論理反転し、ＡＮＤ ＃１，Ｒ０で上位をクリアし、ＯＲ Ｒ０，Ｒ１で（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）を生成する。更に、ＳＨＬＲ Ｒ１で（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）を３２ビットフラグＴに格納する。したがって、命令数が４命令増えて２倍になり性能が低下する。このように、フラグ更新プレフィックス命令は複雑な条件判定を高速化することが出来る。
【００８１】
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。例えばフラグ更新プレフィックス命令はＯＲＮＴＵに代表されるように、後続命令が生成するフラグによって更新するフラグの指定に加えて、後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行う機能を有するものとした。本発明はそれに限定されず、先に生成された夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグを指定する機能だけを持つ命令であってもよい。
【符号の説明】
【００８２】
ＩＣ 命令キャッシュ
ＩＦＵ 命令フェッチユニット
ＩＤＵ 命令デコードユニット
ＥＸＵ 実行ユニット
ＬＳＵ ロードストアユニット
ＤＣ データキャッシュ
ＢＩＵ バスインタフェースユニットユニット
ＩＡ 命令アドレス
ＥＩＡ 外部命令アドレス
ＯＰ 命令
ＢＲＣ 分岐制御信号
ＥＸＣ 実行制御情報
ＬＳＣ ロードストア制御情報
ＲＦ レジスタファイル
ＥＸＡ，ＥＸＢ 実行用オペランド
ＬＳＡ，ＬＳＢ ロードストア用アドレスオペランド
ＳＤ ストアデータ
ＥＸＯ 実行結果
ＤＡ データアドレス
ＤＣＳＤ データキャッシュストアデータ
ＤＣＬＤ データキャッシュロードデータ
ＥＬＤ 外部ロードデータ
ＥＩＡ 外部命令アドレス
ＥＡ 外部アドレス
ＥＤ 外部データ
ＥＩ 外部フェッチ命令
ＥＳＤ 外部ストアデータ
ＡＬＵ 算術論理演算器
ＳＦＴ シフタ
ＦＭ３２ ３２ビットフラグマルチプレクサ
ＦＭ６４ ６４ビットフラグマルチプレクサ
Ｍ３２ ３２ビットシフトアウトマルチプレクサ
Ｍ６４ ６４ビットシフトアウトビットマルチプレクサ
ＯＭＵＸ 出力マルチプレクサ
Ｔ ３２ビット演算用フラグ
Ｕ ６４ビット演算用フラグ
ｎｅｗＴ 新たな３２ビットフラグ
ｎｅｗＵ 新たな６４ビットフラグ
ＦＭＵＸ フラグマルチプレクサ
ＡＬＯ，ＳＦＯ 実行結果
ＧＴ３２ ３２ビットデータサイズの符号付大フラグ
ＧＵ３２ ３２ビットデータサイズの符号なし大フラグ
Ｚ３２ ３２ビットデータサイズのゼロフラグ
Ｖ３２ ３２ビットデータサイズのオーバーフローフラグ
Ｃ３２ ３２ビットデータサイズのキャリーフラグ
ＧＴ６４ ６４ビットデータサイズの符号付大フラグ
ＧＵ６４ ６４ビットデータサイズの符号なし大フラグ
Ｚ６４ ６４ビットデータサイズのゼロフラグ
Ｖ６４ ６４ビットデータサイズのオーバーフローフラグ
Ｃ６４ ６４ビットデータサイズのキャリーフラグ
ＳＬ３２ ３２ビット左シフトアウトビット
ＳＬ６４ ６４ビット左シフトアウトビット
ＳＲ 右シフトアウトビット
ＳＦ３２ ３２ビットシフトアウトフラグ
ＳＦ６４ ６４ビットシフトアウトフラグ
Ｓ３２ ３２ビットフラグソースマルチプレクサ
Ｓ６４ ６４ビットフラグソースマルチプレクサ
ＦＬ３２ ３２ビットフラグ論理演算器
ＦＬ６４ ６４ビットフラグ論理演算器
【技術分野】
【０００１】
本発明は、マイクロプロセッサやマイクロコンピュータ等のデータプロセッサに係り、命令に対する効率的なコード割当を可能にする技術に関する。
【背景技術】
【０００２】
マイクロプロセッサは、１９８４年にモトローラ社が開発した６８０２０以来長らく３２ビットプロセッサが主流であった。３２ビットで指定できる２３２B=４GBは約２０年間にわたり十分大きなアドレス空間であったためである。しかしながら、システム性能向上に伴う必要メモリ容量の増大とメモリ単価の下落によって、近年、PC／サーバ分野で４ＧＢを越える空間を扱える６４ビットプロセッサが普及しつつある。そして、組込プロセッサにおいても、PC／サーバ分野に追随する形で数年から十年遅れで６４ビット化が進行すると予測される。
【０００３】
組込プロセッサは、性能最優先のPC／サーバ用プロセッサとは異なり、高効率と高性能の両立が求められる。この結果、高コード効率の実現可能な１６ビット固定長命令セットのRISC（Reduced Instruction Set Computer）型の組込プロセッサが普及している。高コード効率は、オフチップメモリの大容量化が進んだ現在においても、オンチップのキャッシュ、ＲＡＭやＲＯＭの有効活用には欠かせないものである。しかしながら、こうしたプロセッサを６４ビット化するには１６ビット固定長命令コード空間の効率的な活用が不可欠である。
【０００４】
また、３２ビットプロセッサの時代が長らく続いた結果、演算の基本が３２ビットとなり、８ビットや１６ビットのデータはプロセッサのレジスタ上で３２ビットに拡張して扱うか、４個の８ビットデータや２個の１６ビットデータとして３２ビット単位で扱うことが一般的となった。そして、６４ビットプロセッサにおいても、６４ビットの演算体系に加えて、こうした３２ビットを基本とした演算体系をサポートする必要がある。このため、既存の６４ビットプロセッサでは、必要に応じて同一演算に対して３２ビットと６４ビットの双方の演算命令を定義している。この結果、６４ビットプロセッサでは演算命令数が増大し、それらを定義するために必要なコード空間も増大している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平０６−３３７７８３号公報
【非特許文献】
【０００６】
【非特許文献１】PowerPC User Instruction Set Architecture Book I Version 2.02、Internet URL<http://www.ibm.com/developerworks/power/library/pa-archguidev2>、平成20年1月23日検索
【非特許文献２】SH-4A拡張機能ソフトウェアマニュアル、Internet URL<http://documentation.renesas.com/jpn/products/mpumcu/rjj09b0235_sh4asm.pdf>、平成20年1月23日検索
【非特許文献３】AMD64 Architecture Programmer’s Manual Volume１: Application Programming, Revision 3.11 、Internet URL<http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf>、平成20年1月23日検索
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述のように、１６ビット固定長命令コードのRISC型の組込プロセッサを６４ビット化するには命令のコード空間（単に命令コード空間とも証する）の効率的な活用が不可欠である。中でも、３２ビットプロセッサが３２ビット演算体系のみのサポートで済んだのに対して、６４ビットプロセッサにおいては３２ビットと６４ビットの双方の演算体系をサポートする必要がある。そして、このために既存の６４ビットプロセッサのように同一演算に対して３２ビットと６４ビットの双方の演算命令を定義すると、１６ビット固定長命令セットでは命令コード空間を圧迫し、既存の３２ビット演算体系並みの６４ビット演算体系を構築することが難しい。例えば３２ビットの演算体系を有する命令セットの命令のオペレーションコードが、８ビットで表すことが出来る２５６種類あるとき、複数の６４ビット演算命令を単に追加しようとすると、オペレーションコードのビット数を少なくとも1ビット増やすことが必要になり、命令コード空間が大きくなり、既存の３２ビットの演算の命令体系を維持することが出来なくなり。
【０００８】
特に、６４ビット演算の演算結果の下位３２ビットが３２ビット演算のそれと同一な場合でも、演算結果から生成するフラグが３２ビットと６４ビットの演算で異なる場合は異なる命令を定義する必要がある。生成するフラグのみが異なる場合、１命令で生成するフラグ数を増やすことによってフラグを生成する命令数を削減することが出来る。例えば、文献１のPowerPCでは１命令で正・負・ゼロ・オーバーフロー・キャリーといった複数種類のフラグを生成している。更に、文献２では複数種類の複数サイズ用のフラグを生成している。即ち「種類数」×「サイズ数」のフラグを生成している。文献２では「４種類」×「２サイズ」＝「８フラグ」である。
【０００９】
しかしながら、１命令で生成するフラグ数を増加させるとフラグを使用する命令数を増加させる必要がある。例えば、条件分岐命令の分岐条件は「どのフラグを使用するか」と「使用するフラグがセットされているかクリアされているか」の組合せで決定する方式が一般的である。文献２の条件分岐命令では、フラグの使い方を指定するフィールドに５ビット取っていて、３２通りの指定が可能となっている。したがって、条件分岐命令数は３２×「フラグ以外のバリエーション数」となる。フラグ以外のバリエーションとしてはディレイスロットの有無、分岐先アドレス指定方法等が考えられる。
【００１０】
このように「フラグ数の増加」は「フラグを生成する命令（フラグ生成命令）数の削減」に貢献する反面「フラグを使用する命令（フラグ使用命令）数の増大」を招く。したがって、文献２のようにフラグ数を増やせば命令数が削減できるとは限らない。文献２はCISC（Complicated Instruction Set Computer）を前提としており、主要なフラグ生成命令である演算命令はメモリオペランドも指定できるため数が多い。そして、フラグ数を増やして数の多い「フラグ生成命令数の削減」を行えば命令数を削減できた。一方、一般的なRISCは３２ビット固定長命令セットであり、命令コード空間に余裕があるため、命令数削減ニーズが小さい。このためRISCにおいてフラグ数を調整して命令数の最小化を図った例はない。しかし、１６ビット固定長命令セットのRISCの６４ビットプロセッサ化においては命令コード空間に余裕がない。また、RISCはCISCよりフラグ生成命令数が少ない。このため、フラグ数を増やすだけでは最適化ポイントを見出せない。そして、フラグ生成命令数とフラグ使用命令数のバランスが良くなる方式にすることが重要である。
【００１１】
本発明が解決しようとする第１の課題は、フラグ生成命令数の少ない命令セットにおいてフラグ数を調整して命令数を削減し、それらを定義するために必要なコード空間の最小化を図り、１６ビット固定長命令セットのRISCのように命令コード空間に余裕がないプロセッサの６４ビット化を可能にすることである。
【００１２】
また、一般に、フラグ数を増やしても、１命令で生成した複数のフラグを使用する例は少なく、１つだけを使用する場合が多い。一方、複数命令で生成したフラグを組み合わせて使用すると、プログラムを効率的に出来る場合がある。しかし、命令を実行する度に複数のフラグを更新すると、先行命令が生成したフラグを後続の命令が上書きしてしまうため、フラグを組み合わせて使用することは困難である。このため、生成したフラグを逐次レジスタに転送して、レジスタ上で論理演算してからフラグに戻したり、レジスタ上で論理演算した結果を数値として判定してフラグを生成したり、フラグを生成する度に条件分岐や条件実行をする必要がある。これらの方式は実行命令数が多くなったり、分岐頻度が増加したりするため効率が悪く性能が低下する。
【００１３】
特に、あるデータを演算対象としてみた場合、そのサイズが２種類であることはないため、複数種類のサイズに対するフラグを生成しても一方は不要である。適切な符号拡張またはゼロ拡張により、複数種類のサイズに対するフラグが同じ値になって、どちらでも使えるということはありうるが、一方が不要であることに変わりはない。したがって、複数のフラグを定義した場合、同時に更新するよりは、必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にすることも効果的である。しかしながら、これを実現するには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定する必要があり、最も大きな命令コード空間を必要とする。
【００１４】
本発明が解決しようとする第２の課題は、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することを可能にすることである。
【課題を解決するための手段】
【００１５】
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
【００１６】
本発明では、フラグ生成命令数が多い場合に１命令が生成するフラグ数を増やすことによって、フラグ生成命令数の減少がフラグ使用命令数の増加を上回るようにすることにより命令数の削減を実現するという観点を基に、オペランドのデータサイズに応じた複数フラグを生成する命令を定義すると言う手段を採用するものである。要するに、縮小命令セットコンピュータ型のデータプロセッサにおいて、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグを生成する命令を命令セットに加える。
【００１７】
第２の観点として、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にするには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定するという手段を採用する。すなわち、前記命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を命令セットに加える。
【発明の効果】
【００１８】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記のとおりである。
【００１９】
すなわち、第１の観点の発明により、命令セットを構成する命令の種類（命令数）が全体として少なくなる。したがって、命令コード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コードのコード空間縮小に寄与することができる。例えば、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００２０】
第２の観点の発明により、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明に係るデータプロセッサにおけるプロセッサコアの構成を概略的に例示するブロック図である。
【図２】本発明の実施形態１に係るプロセッサコアの実行ユニットを概略的に例示するブロック図である。
【図３】本発明の実施形態２に係るフラグ更新プレフィックス命令を概略的に例示する説明図である。
【図４】本発明の実施形態２に係るプロセッサコアの命令デコードユニットを概略的に例示するブロック図である。
【図５】本発明の実施形態２に係るプロセッサコアの実行ユニットを概略的に例示するブロック図である。
【図６】本発明の実施形態２に係るプロセッサコアの動作を概略的に例示する説明図である。
【図７】本発明に係るデータプロセッサの概略的な構成を例示するブロック図である。
【発明を実施するための形態】
【００２２】
１．実施の形態の概要
先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。
【００２３】
最初に上記夫々の観点について具体的に説明する。先ず、第１の観点に関し、１６ビット固定長命令セットのRISC型３２ビットプロセッサのフラグ生成命令数は、例えば文献３のSH-４Aプロセッサコアではオペランドフィールドが８ビットの命令が１７、４ビットの命令が１２である。尚、フラグを使用して更新する命令はフラグ生成命令としてカウントしている。また、６４ビットプロセッサ化に関係のない浮動小数点命令は除いている。一方、フラグ使用命令数は、オペランドフィールドが８ビットの命令が４、４ビットの命令が１である。そして、フラグ数は１である。フラグ数が少ないほどフラグ生成命令数が増え、フラグ使用命令数が減るため、SH-４Aプロセッサコアでは２９命令対５命令とフラグ生成命令数の方が約６倍多い。そして、２９のフラグ生成命令のうち２６命令はオペランドサイズによって動作が異なるため、単純に６４ビット命令を追加すると２６命令増加する。この結果、フラグ生成命令数とフラグ使用命令数の比は５５対５となり１１倍となる。
【００２４】
このようにフラグ生成命令数が多い場合、1命令が生成するフラグ数を増やすことによって比率を変えて命令数を削減することができる。増やし方としては、（１）フラグの種類、（２）オペランドサイズ、又は（３）その両方に応じたフラグを定義する方式が考えられる。
【００２５】
まず、（１）のフラグの種類に応じたフラグを定義する方式について考える。SH-４Aプロセッサコアのフラグの種類には、符号付大小、符号なし大小、ゼロ、オーバーフロー、キャリー、シフトアウトビット等がある。そして、フラグは１ビットなので、どの命令が立てたフラグかで意味が変わる。異なる演算が異なる種類のフラグを立てる場合、フラグの種類を増やしても命令数は減らないため、同一演算で生成するフラグのみ異なる場合に着目すると、比較命令が候補となる。比較命令は、符号付大小、符号なし大小、ゼロの３フラグを別フラグにすれば、１８命令を８命令にできる。他の命令はゼロ、オーバーフロー、キャリー、シフトアウトビット等を生成するが、演算が異なるためフラグを種類で分けても命令数削減効果はない。一方、フラグ使用命令数はフラグ種類数に応じて３倍になり、５命令から１５命令になる。この結果、フラグの関係する命令数は６０命令から１０命令減って１０命令増えるため６０命令のままである。
【００２６】
次に、（２）のオペランドサイズに応じたフラグを定義する方式について考える。３２ビットと６４ビットのオペランドサイズ毎にフラグを設けると、オペランドサイズによって動作が異なる２９命令のうち、下位３２ビットの動作が同一な１５命令を３２ビットと６４ビットで共通の命令とすることができる。一方、フラグは２倍となるため、フラグ使用命令数は５命令から１０命令になる。この結果、フラグの関係する命令数は６０命令から１５命令減って５命令増えるため５０命令に減少する。
【００２７】
更に、（３）の両方に応じたフラグを定義する方式を考える。まず、フラグを３種類にすることによって、比較命令を１８命令から８命令にできる。更にサイズ毎にフラグを定義することによって８命令を４命令にすることができる。また、比較命令以外のフラグ生成命令のうち下位３２ビットの動作が同一な命令を６命令削減できる。一方、フラグ使用命令数はフラグ種類数に応じて６倍になり、５命令から３０命令になる。この結果、フラグの関係する命令数は６０命令から２０命令減って２５命令増えるため６５命令に増加する。
【００２８】
以上のように、命令数最小化という観点からフラグ数を最適化すると、（２）オペランドサイズに応じてフラグを定義する方式が最善であることが明らかになった。
【００２９】
命令が消費する命令コード空間は命令がオペランドフィールドに使用するビット数によって大きく変化する。Nビットでは命令コード空間全体の２の(１６-N）乗分の一の空間を消費する。例えば８ビットならば１/２５６、４ビットならば１/４０９６の空間を消費する。このため、重要なのは８ビットオペランドフィールドの命令数の削減である。
【００３０】
そこで、上記考察を８ビットオペランドフィールドを有する命令（単に８ビットオペランドフィールド命令とも称する）に限定して行うと、３２ビットプロセッサのフラグ関連の８ビットオペランドフィールド命令は生成命令が１７、使用命令が条件分岐命令４の計２１命令であり、このうちオペランドサイズによって動作が異なる命令は生成命令の１５命令なので、単純に６４ビット命令を追加すると生成命令が１５命令増加して３２命令になり、計３６命令となる。
【００３１】
まず、（１）のフラグの種類に応じたフラグを定義する方式では、フラグを３種類にすることによって、比較命令を１７命令から６命令にできる反面、条件分岐命令が４命令から１２命令に増加するので、フラグの関係する命令数は３６命令から８命令減って８命令増えるため３６命令のままである。
【００３２】
次に、（２）のオペランドサイズに応じたフラグを定義する方式では、オペランドサイズによって動作が異なる１５命令のうち、下位３２ビットの動作が同一な１０命令を３２ビットと６４ビットで共通の命令とすることができる。一方、フラグは２倍となるため、条件分岐命令数は４命令から８命令になる。この結果、フラグの関係する命令数は３６命令から１０命令減って４命令増えるため３０命令に減少する。
【００３３】
更に、（３）の両方に応じたフラグを定義する方式を考える。まず、フラグを３種類にすることによって、比較命令を１４命令から６命令にできる。更にサイズ毎にフラグを定義することによって６命令を３命令にすることができる。また、比較命令以外のフラグ生成命令のうち下位３２ビットの動作が同一な命令を３命令削減できる。一方、フラグ使用命令数はフラグ種類数に応じて６倍になり、４命令から２４命令になる。この結果、フラグの関係する命令数は３６命令から１４命令減って２０命令増えるため４２命令に増加する。
【００３４】
以上のように命令コード空間消費に影響の大きい８ビットオペランドフィールド命令に限定しても（２）のオペランドサイズに応じてフラグを定義する方式が最善であることが解る。一方、文献２でCISCに適用した際は、命令のコードサイズ最小化に最善であった（３）の方式がRISCでは最悪の方式となっている。
【００３５】
本発明の第１の課題であるフラグ生成命令数の少ない命令セットにおいてフラグ数を調整して命令数を削減し、それらを定義するために必要なコード空間の最小化を図り、１６ビット固定長命令セットのRISCのように命令コード空間に余裕がないプロセッサの６４ビット化を可能にすることは、オペランドサイズに応じたフラグを定義することによって達成する。具体的には、３２ビットと６４ビットのオペランドサイズ毎にフラグを設け、３２ビットと６４ビットオペランドの命令で下位３２ビットの動作が同一な命令を統合し、フラグ数増加に応じた条件分岐等のフラグ使用命令数を増加させることにより達成する。これにより、命令セットを構成する命令の種類（命令数）が全体として少なくなる。
【００３６】
第２の観点に関しては、課題のところで述べたように、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にするには、フラグ生成命令が更新するフラグと、フラグ使用命令が使用するフラグの双方の種類及び場所を指定する必要があり、最も大きな命令コード空間を必要とする。
【００３７】
この問題を解決するには、後続命令を修飾する命令であるプレフィックス命令を定義すればよい。プレフィックス命令の実装は可変長命令セットの実装に類似しており、文献４の８７頁からの記載のようにプレフィックス命令を使うプロセッサは従来から存在する。そして、本分野の通常のスキルの技術者であればその実装は可能である。そして、どのようなプレフィックス命令を定義するかが重要となる。本発明ではフラグ更新プレフィックス命令として、更新するフラグの指定、後続命令が生成したフラグのうち使用するフラグの指定、指定した２つのフラグ間の論理演算の指定を行う。フラグを２種類、演算を８種類とすると、５ビットのオペランドフィールドで指定することができ、大きな命令コード空間を必要としない。論理演算も指定できるため、残したいフラグの更新抑止が可能な命令セットで論理演算を別命令で行う場合と同一の命令数でフラグ間の論理演算を実行することができる。これにより、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能となる。
【００３８】
上記観点を踏まえて代表的な実施の形態を説明する。
【００３９】
〔１〕縮小命令セットコンピュータ型のデータプロセッサは、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグ（ｎｅｗＵ，ｎｅｗＴ）を生成する第１命令を命令セットに有する。これにより、命令セットを構成する命令の種類（命令数）が全体として少なくなる。したがって、命令のコード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コード空間の縮小に寄与することができる。例えば、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００４０】
〔２〕項１のデータプロセッサは、例えば前記第１命令によって生成されたフラグを選択して使用する第２命令を更に前記命令セットに有する。
【００４１】
〔３〕項１のデータプロセッサは、例えば前記第１命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を更に前記命令セットに有する。これにより、複数のフラグを定義して必要なものだけを更新することができる。
【００４２】
〔４〕項１のデータプロセッサは、例えば前記第１命令が生成した夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を更に前記命令セットに有する。これにより、複数のフラグを定義して必要なものだけを更新して、残したいフラグは残し、フラグ間の演算を可能にすることができる。したがって、命令コード空間の最小化を主目的として定義した複数フラグを、大きな命令コード空間を使わずに活用し、複数命令で生成したフラグを組み合わせて使用することが可能になる。
【００４３】
〔５〕項１のデータプロセッサにおいて、例えば前記複数データサイズは、３２ビットと６４ビットである。
【００４４】
〔６〕項２のデータプロセッサにおいて、例えば前記フラグは、複数データサイズ毎の、符号付き大小、符号無し大小、ゼロ、オーバーフロー、キャリー、又はシフトアウトビットである。
【００４５】
〔７〕命令実行部（ＥＸＵ）を有する縮小命令セットコンピュータ型の別のデータプロセッサは、フラグの生成を伴う処理を実行するための第１命令及びフラグの使用を伴う処理を実行するための第２命令を命令セットに有する。前記命令実行部は命令デコード結果に従った処理を行なう演算回路（ＡＬＵ，ＳＦＴ）、フラグラッチ回路（Ｕ，Ｔ）及びフラグ選択回路（ＦＭＵＸ）を有する。前記演算回路は、前記第１命令のデコード結果に従って、複数データサイズのオペランドに対して演算処理が可能であって小さいデータサイズのオペランドに対する演算処理と等しい処理を大きいデータサイズのオペランドの下位側に対して行い演算処理されるオペランドのデータサイズに拘わらず夫々のデータサイズに対応するフラグを生成する。前記フラグラッチ回路は、前記第１命令のデコード結果に従って、前記演算回路で生成されたフラグをラッチする。前記フラグ選択回路は、前記第２命令のデコード結果に従って、前記フラグラッチ回路にラッチされたフラグを選択する。
【００４６】
〔８〕項７のデータプロセッサにおいて、例えば前記演算回路はデータサイズ毎に符号付き大小、符号無し大小、ゼロ、オーバーフロー、キャリー、及びシフトアウトビットのフラグを生成し、生成したフラグから一種類のフラグが第１命令で選択されてオペランドサイズ毎に前記フラグラッチ回路にラッチされる。
【００４７】
〔９〕項８のデータプロセッサにおいて、例えば前記複数データサイズは、３２ビットと６４ビットである。
【００４８】
〔１０〕更に別のデータプロセッサは、演算処理を行なって複数のフラグを生成可能な演算命令と共に、前記演算命令が生成した複数のフラグのうち後続命令が生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を命令セットに有する。
【００４９】
〔１１〕更に別のデータプロセッサは、演算処理を行なって複数のフラグを生成可能な演算命令と共に、前記演算命令が生成した複数のフラグのうち後続命令が生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を命令セットに有する。
【００５０】
２．実施の形態の詳細
実施の形態について更に詳述する。以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。なお、発明を実施するための最良の形態を説明するための全図において、同一の機能を有する部材には同一の符号を付し、その繰り返しの説明は省略する。
【００５１】
《実施形態１》
図７には本発明に係るデータプロセッサＤＰＵが例示される。データプロセッサＤＰＵは中央処理装置のようなプロセッサコアＣＰＵを中心に、これに内部バスで接続された不揮発性メモリＲＯＭ、揮発性メモリＲＡＭ、入出力インタフェース回路ＩＯＣ、及び外部バスインタフェース回路ＥＢＩＦ等を備え、例えば相補型ＭＯＳ修正回路製造技術により単結晶シリコン等の１個の半導体基板に形成される。不揮発性メモリＲＯＭはプロセッサコアＣＰＵが実行するプログラム等の格納領域に利用され、揮発性メモリＲＡＭはプロセッサコアＣＰＵのワーク領域等に利用される。
【００５２】
図１にはプロセッサコアＣＰＵのブロック構成が概略的に例示される。例えばプロセッサコアＣＰＵは、命令キャッシュＩＣ、命令フェッチユニットＩＦＵ、命令デコードユニットＩＤＵ、実行ユニットＥＸＵ、ロードストアユニットＬＳＵ、データキャッシュＤＣ、及びバスインタフェースユニットユニットＢＩＵから成る。
【００５３】
命令フェッチユニットＩＦＵは命令アドレスＩＡを命令キャッシュＩＣに出力し、命令キャッシュＩＣは命令アドレスＩＡで指定されたアドレスからフェッチした命令ＦＩを命令フェッチユニットＩＦＵに返す。キャッシュミスした場合は、ミスしたアドレスを外部命令アドレスＥＩＡとしてバスインタフェースユニットユニットＢＩＵに出力し、外部フェッチ命令ＥＩを受け取ってから、命令ＦＩを命令フェッチユニットＩＦＵに返す。
【００５４】
命令デコードユニットＩＤＵは、命令フェッチユニットＩＦＵから命令ＯＰを受け取り、分岐制御信号ＢＲＣを出力する。また、命令ＯＰをデコードし、実行ユニットＥＸＵ及びロードストアユニットＬＳＵにそれぞれ実行制御情報ＥＸＣ及びロードストア制御情報ＬＳＣを出力すると共に、レジスタファイルＲＦにアクセスし、実行用オペランドＥＸＡ及びＥＸＢを実行ユニットＥＸＵに、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤをロードストアユニットＬＳＵに供給する。更に、実行結果ＥＸＯを実行ユニットＥＸＵから、ロードデータＬＤをロードストアユニットＬＳＵから受け取り、レジスタファイルＲＦに格納する。
【００５５】
実行ユニットＥＸＵは命令デコードユニットＩＤＵから実行制御情報ＥＸＣ、実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って演算実行した後、実行結果ＥＸＯを命令デコードユニットＩＤＵに返す。
【００５６】
ロードストアユニットＬＳＵは命令デコードユニットＩＤＵからロードストア制御情報ＬＳＣ、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤを受け取り、ロードストア制御情報ＬＳＣに従ってロードストア実行した後、ロードデータＬＤを命令デコードユニットＩＤＵに返す。また、ロードストアの際には、データキャッシュＤＣにデータアドレスＤＡを出力し、更にストアの際には、データキャッシュストアデータＤＣＳＤも出力する。そして、データキャッシュＤＣはロードの際にはデータキャッシュロードデータＤＣＬＤをロードストアユニットＬＳＵ返し、ストアの際はデータキャッシュストアデータＤＣＳＤをストアする。キャッシュミスした場合は、ミスしたアドレスを外部データアドレスＥＤＡとしてバスインタフェースユニットユニットＢＩＵに出力し、外部ロードデータＥＬＤを受け取ってから、データキャッシュロードデータＤＣＬＤをロードストアユニットＬＳＵに返す。また、キャッシュミスに伴うデータのコピーバックや、キャッシュしないデータの外部ストア時には、それらのデータを外部ストアデータＥＳＤとして出力すると共に、それらのデータのアドレスを外部データアドレスＥＤＡとして出力する。
【００５７】
バスインタフェースユニットＢＩＵは、命令キャッシュＩＣ又はデータキャッシュＤＣから、それぞれ外部命令アドレスＥＩＡ又は外部データアドレスＥＤＡを受け取り、プロセッサコアＣＰＵ外に外部アドレスＥＡを出力してデータを要求し、外部データＥＤとして受け取り、それぞれ外部フェッチ命令ＥＩ又は外部ロードデータＥＬＤとして出力する。また、データキャッシュＤＣから、外部データアドレスＥＤＡ及び外部ストアデータＥＳＤを受け取り、プロセッサコアＣＰＵ外に外部アドレスＥＡ及び外部データＥＤとして出力し、ストアリクエストを出す。
【００５８】
図２には、本発明の実施形態１に係るプロセッサの実行ユニットＥＸＵが概略的に例示される。実行ユニットＥＸＵは算術論理演算器ＡＬＵ、シフタＳＦＴ、３２ビットフラグマルチプレクサＦＭ３２、６４ビットフラグマルチプレクサＦＭ６４、３２ビットシフトアウトマルチプレクサＭ３２、６４ビットシフトアウトビットマルチプレクサＭ６４、出力マルチプレクサＯＭＵＸ、３２ビット演算用フラグＴ、６４ビット演算用フラグＵ、フラグマルチプレクサＦＭＵＸから成る。また、図示していないが命令デコードユニットＩＤＵからの実行制御情報ＥＸＣは各構成要素に入力されてそれらを制御する。
【００５９】
算術論理演算器ＡＬＵは命令デコードユニットＩＤＵから実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って各種算術論理演算を実行した後、実行結果ＡＬＯ、３２ビットフラグ群（符号付大ＧＴ３２，符号なし大ＧＵ３２、ゼロＺ３２、オーバーフローＶ３２、キャリーＣ３２）及び６４ビットフラグ群（符号付大ＧＴ６４，符号なし大ＧＵ６４、ゼロＺ６４、オーバーフローＶ６４、キャリーＣ６４）を出力する。
【００６０】
シフタＳＦＴは命令デコードユニットＩＤＵから実行用オペランドＥＸＡ及びＥＸＢを受け取り、実行制御情報ＥＸＣに従って各種シフト演算を実行した後、実行結果ＳＦＯ、３２ビット左シフトアウトビットＳＬ３２、６４ビット左シフトアウトビットＳＬ６４、及び右シフトアウトビットＳＲを出力する。そして、３２ビットシフトアウトビットマルチプレクサＭ３２で、シフト演算の方向に応じて３２ビット左シフトアウトビットＳＬ３２又は右シフトアウトビットＳＲを選択して３２ビットフラグ群の１つである３２ビットシフトアウトフラグＳＦ３２として出力する。また、６４ビットシフトアウトビットマルチプレクサＭ６４で、シフト演算の方向に応じて６４ビット左シフトアウトビットＳＬ６４又は右シフトアウトビットＳＲを選択して６４ビットフラグ群の１つである６４ビットシフトアウトフラグＳＦ６４として出力する。
【００６１】
出力マルチプレクサＯＭＵＸは実行結果ＡＬＯ及び実行結果ＳＦＯの一方を実行制御情報ＥＸＣに従って選択し、実行結果EXOとして出力する。
【００６２】
３２ビットフラグマルチプレクサＦＭ３２は３２ビットフラグ群から命令の種類に応じてフラグを選択して、新たな３２ビットフラグｎｅｗＴを生成し、３２ビットフラグＴの入力とする。同様に、６４ビットフラグマルチプレクサＦＭ６４は６４ビットフラグ群から命令の種類に応じてフラグを選択し、新たな６４ビットフラグｎｅｗＵを生成し、６４ビットフラグＵの入力とする。３２ビットフラグＴ及び６４ビットフラグＵはこれらの入力をラッチし、フラグマルチプレクサＦＭＵＸに出力する。フラグマルチプレクサＦＭＵＸは使用する命令に応じて３２ビットフラグＴ及び６４ビットフラグＵの一方を選択し、フラグ出力ＦＯとして出力する。フラグマルチプレクサＦＭＵＸはラッチ後の値を使用して、次命令で使用するフラグを選択しており、図示していないが命令デコードユニットＩＤＵからの実行制御情報ＥＸＣとして、ラッチ前の値を使用することにより次命令の制御情報を受け取ることが出来る。
【００６３】
上記実施形態1により、命令セットを構成する命令の種類（命令数）を全体として少なくすることができる。したがって、命令コード空間に余裕のないＲＩＳＣ型のデータプロセッサにおける命令コードのコード空間縮小に寄与することができ、１６ビット固定長命令セットのＲＩＳＣのように命令コード空間に余裕がないプロセッサの６４ビット化が可能になる。
【００６４】
《実施形態２》
図３には、本発明の実施形態２に係るフラグ更新プレフィックス命令が概略的に例示される。フラグ更新プレフィックス命令は、更新するフラグの指定、後続命令が生成したフラグのうち使用するフラグの指定、指定した２つのフラグ間の論理演算の指定を行う。フラグを３２ビットフラグＴ及び６４ビットフラグＵの２種類とすると、更新するフラグの指定に１ビット、後続命令が生成したフラグのうち使用するフラグの指定に１ビット使用する。また、演算を６種類とすると、指定した２つのフラグ間の論理演算の指定には３ビット使用する。したがって、フラグ更新プレフィックス命令は５ビットのオペランドフィールドで指定することができ、大きな命令コード空間を必要としない。
【００６５】
１６ビット固定長命令セットで定義すると、図３のように１１ビットのオペレーションタイプ指定フィールドＯＰＴでフラグ更新プレフィックス命令であることを指定し、２ビットのソースデスティネーション指定フィールドＳＤで、更新するフラグの指定及び後続命令が生成したフラグのうち使用するフラグの指定を行い、３ビットの論理演算指定フィールドＴＹＰで指定した２つのフラグ間の論理演算の指定を行う。論理演算の種類は論理積ＡＮＤ、論理和ＯＲ、否定論理積ＡＮＤＮ、否定論理和ＯＲＮ、排他的論理和ＸＯＲ、新フラグＮＥＷの６種類であり、それぞれＴＹＰフィールドの０００から１０１を割り当てている。この演算の種類にソースとソースデスティネーションフラグを加えてニモニックとしている。ＳＤフィールドは上位がソース、下位がデスティネーションで、０が３２ビットフラグＴ、１が６４ビットフラグＵを指定することを表す。動作欄のｎｅｗＴは後続命令が生成した３２ビットフラグ、ｎｅｗＵは後続命令が生成した６４ビットフラグ、＆＝、｜＝、＾＝、＝、〜はＣ言語と同じ意味の演算子であり、＆＝は右辺の値と左辺の値との論理積を取って左辺の変数に代入、｜＝は右辺の値と左辺の値との論理和を取って左辺の変数に代入、＾＝は右辺の値と左辺の値との排他的論理和を取って左辺の変数に代入、＝は右辺の値を左辺の変数に代入、〜は右側の値を論理反転することを表す。
【００６６】
例えばＳＤ＝００、ＴＹＰ＝０００の場合は、論理演算の種類は論理積ＡＮＤ、更新するフラグ（デスティネーションフラグ）は３２ビットフラグＴ，後続命令が生成したフラグのうち使用するフラグ（ソースフラグ）も３２ビットフラグＴであり、ニモニックはＡＮＤＴＴ、動作はＴ＆＝ｎｅｗＴ；Ｕ：不変なので、３２ビットフラグＴと後続命令が生成したフラグのうち３２ビットフラグＴとの論理積を取って３２ビットフラグＴに格納し、６４ビットフラグＵは更新しないというフラグ更新プレフィックス命令となる。そして、後続命令の動作は、プレフィックス命令がなければ生成したフラグで３２ビットフラグＴ及び６４ビットフラグＵを更新するところを、上記フラグ更新プレフィックス指定の動作に置き換えられる。
【００６７】
本実施形態２と前述の実施形態１との構成上の違いは命令デコードユニットＩＤＵ及び実行ユニットＥＸＵに現れるため、プロセッサコアの代表的ブロック構成は実施形態１と同様に図１に示される。
【００６８】
図４には、本発明の実施形態２に係るプロセッサの命令デコードユニットＩＤＵが概略的に例示される。１サイクルに１命令発行するスカラプロセッサを例示するが、文献４のようにプレフィックス命令を使うプロセッサは従来から存在し、本分野の通常のスキルの技術者であればプレフィックスデコード及び発行方式のスーパースカラ、アウトオブオーダ等の他の発行形態への適用は可能である。また、本実施例ではフラグ更新プレフィックス命令のみがプレフィックス命令であることを前提としているが、他のプレフィックス命令も扱えるように拡張することも本分野の通常のスキルの技術者であれば可能である。
【００６９】
命令デコードユニットＩＤＵは、メインデコーダＤＥＣ及びプレフィックスデコーダＰＦ−ＤＥＣから成る。メインデコーダＤＥＣは命令フェッチユニットＩＦＵから供給される命令ＯＰをデコードし、実行制御情報ｏｐ−ｅｘｃを実効制御情報ＥＸＣの一部として実行ユニットＥＸＵへ、３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグＵの更新制御ｏｐ−ｗｒｕをプレフィックスデコーダＰＦ−ＤＥＣへ、ロードストア制御情報ＬＳＣをロードストアユニットＬＳＵへ、そして、レジスタファイル制御情報ＲＦＣをレジスタファイルＲＦへ出力する。尚、レジスタファイル制御情報ＲＦＣのうち、書込み情報は発行された命令がレジスタ書込みステージに達するタイミングで供給する。
【００７０】
ファイルＲＦはレジスタファイル制御情報ＲＦＣに基づいて、実行用オペランドＥＸＡ及びＥＸＢを実行ユニットＥＸＵに、ロードストア用アドレスオペランドＬＳＡ及びＬＳＢ、並びにストアデータＳＤをロードストアユニットＬＳＵに供給する。更に、実行結果ＥＸＯを実行ユニットＥＸＵから、ロードデータＬＤをロードストアユニットＬＳＵから受け取り、レジスタファイルＲＦに格納する。
【００７１】
プレフィックスデコーダＰＦ−ＤＥＣは、命令ＯＰのオペレーションタイプ指定フィールドＯＰＴをデコードし、命令ＯＰがフラグ更新プレフィックスであれば有効フラグｖを立て、そうでなければクリアする。また、２ビットのソースデスティネーション指定フィールドＳＤをそれぞれプレフィックスソースフラグ指定情報ｐｆｓｒｃとプレフィックスデスティネーションフラグ情報ｐｆｄｓｔとしてラッチする。更に、論理演算指定フィールドＴＹＰをプレフィックス論理演算指定情報ｐｆｔｙｐとしてラッチする。命令ＯＰがフラグ更新プレフィックス命令である場合、メインデコーダＤＥＣにもそれが供給される。この時、メインデコーダＤＥＣはフラグ更新プレフィックスをノーオペレーションコードとみなし、実行ユニットＥＸＵ及びロードストアユニットＬＳＵが何もしないような制御情報を出力する。
【００７２】
命令ＯＰがフラグ更新プレフィックス命令であった次のサイクルでは、メインデコーダＤＥＣは後続命令をデコードし、前述のように各種制御情報を出力する。一方、プレフィックスデコーダＰＦ−ＤＥＣでは、前サイクルでラッチした情報を使って処理を進める。命令ＯＰがフラグ更新プレフィックス命令であったため、有効フラグｖが立っており、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕとしては、それぞれプレフィックス論理演算指定情報ｐｆｔｙｐ、プレフィックスフラグソース指定情報ｐｆｓｒｃ、同じくプレフィックスフラグソース指定情報ｐｆｓｒｃ、プレフィックスデスティネーションフラグ情報ｐｆｄｓｔが０、及びプレフィックスデスティネーションフラグ情報ｐｆｄｓｔが１という情報を出力する。この結果、フラグ生成のための制御情報としては、メインでコーダからの３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグ更新制御ｏｐ−ｗｒｕがオーバーライドされ、フラグ更新プレフィックス命令の情報が出力される。
【００７３】
一方、命令ＯＰがフラグ更新プレフィックス命令でなかった次のサイクルでは、有効フラグｖが立っていないため、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕとしては、それぞれ１０１、０、１、３２ビットフラグ更新制御ｏｐ−ｗｒｔ及び６４ビットフラグ更新制御ｏｐ−ｗｒｕを出力する。この結果、メインデコーダＤＥＣの出力が命令デコードユニットＩＤＵとして出力される。尚、メインデコーダＤＥＣ出力のない、論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、及び６４ビットフラグソース情報ｓｒｕとして、それぞれ１０１、０、１出力することが命令本来の動作を指定している。
【００７４】
上記論理演算指定情報ｔｙｐ、３２ビットフラグソース情報ｓｒｔ、６４ビットフラグソース情報ｓｒｕ、３２ビットフラグ更新制御ｗｒｔ及び６４ビットフラグ更新制御ｗｒｕはメインデコーダＤＥＣで生成される実行制御情報ｏｐ−ｅｘｃと共に実効制御情報ＥＸＣとして実行ユニットＥＸＵに出力される。
【００７５】
図５には、本発明の実施形態２に係るプロセッサの実行ユニットＥＸＵが概略的に例示される。図２に例示した実施形態１に係るプロセッサの実行ユニットＥＸＵと共通部分は同一の機能を有している。追加部分は、３２ビットフラグソースマルチプレクサＳ３２、６４ビットフラグソースマルチプレクサＳ６４、３２ビットフラグ論理演算器ＦＬ３２、及び６４ビットフラグ論理演算器ＦＬ６４である。
【００７６】
３２ビットフラグソースマルチプレクサＳ３２は、命令デコードユニットＩＤＵからの３２ビットフラグソース情報ｓｒｔに従って、新たな３２ビットフラグｎｅｗＴ又は新たな６４ビットフラグｎｅｗＵを選択し、３２ビットフラグ論理演算器ＦＬ３２に供給し、３２ビットフラグ論理演算器ＦＬ３２は、これと３２ビットフラグＴとから、論理演算指定情報ｔｙｐに従って、論理演算を行い、結果を３２ビットフラグＴにラッチする新たな値とする。同様に、６４ビットフラグソースマルチプレクサＳ６４は、命令デコードユニットＩＤＵからの６４ビットフラグソース情報ｓｒｔに従って、新たな３２ビットフラグｎｅｗＴ又は新たな６４ビットフラグｎｅｗＵを選択し、６４ビットフラグ論理演算器ＦＬ６４に供給し、６４ビットフラグ論理演算器ＦＬ６４は、これと６４ビットフラグＵとから、論理演算指定情報ｔｙｐに従って、論理演算を行い、結果を６４ビットフラグＵにラッチする新たな値とする。
【００７７】
上記のように本発明の実施形態２に係る命令デコードユニットＩＤＵ及び実行ユニットＥＸＵにより、大きな命令コード空間を必要としないフラグ更新プレフィックス命令による、残したいフラグの更新抑止、複数命令で生成したフラグ間の論理演算が可能となる。
【００７８】
次に、具体例によってフラグ更新プレフィックス命令の効果を説明する。図６には本発明の実施形態２に係るプロセッサの動作例が概略的に例示される。図６のＣプログラムは６４ビットポインタｐがＮＵＬＬポインタでなく、３２ビット変数ｉが１０より大きかったら｛｝内を実行せよというプログラムである。ＮＵＬＬポインタは何も指していない状態であり値が０となっている。
【００７９】
フラグ更新プレフィックス命令を含むアセンブラで、このＣプログラムを記述すると図６のように４命令で記述される。まず第１ステップで、ＣＭＰ／ＥＱ ｐ，０で６４ビットポインタｐとＮＵＬＬポインタ値０とを６４ビットサイズで比較し、比較結果を６４ビットフラグＵに格納する。６４ビットポインタｐがＮＵＬＬポインタの場合に６４ビットフラグＵがセットされる。即ち、Ｕ＝（ｐ＝＝ＮＵＬＬ）となる。このとき、３２ビットフラグＴには６４ビットポインタｐとＮＵＬＬポインタ値０の下位３２ビットを比較した結果が格納されるが本プログラムでは使用しない。第２ステップでは、フラグ更新プレフィックス命令ＯＲＮＴＵをデコードする。第３ステップでは、ＣＭＰ／ＧＴ ｉ，１０で３２ビット変数ｉが１０より大きかったら新たな３２ビットフラグｎｅｗＴが立つ。そして、フラグ更新プレフィックス命令ＯＲＮＴＵによって、Ｕ｜＝〜ｎｅｗＴとなるので、Ｕ＝（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）となる。このとき、３２ビットフラグＴは不変である。この結果、６４ビットフラグＵにはＣプログラムのｉｆ文の条件式の反転値が入っている。第４ステップでは、ＢＴ．Ｄ ＿ａｆｔｅｒ＿ｉｆ＿ｃｌｏｓｅによってＵが１、即ち条件式が不成立ならばｉｆ文の後ろに飛ぶのでｉｆ文は実行されない。
【００８０】
以上のようにフラグ更新プレフィックス命令を使うと複数の比較結果をまとめることが出来るため、１回の条件分岐で条件判定が完了する。フラグ更新プレフィックス命令を使わないと条件判定のたびに条件分岐を行う必要があり、これを高速化することは困難である。あるいは生成したフラグを汎用レジスタに転送して論理演算を行う場合、第２ステップのフラグ更新プレフィックス命令の代わりにフラグ転送命令ＭＯＶＵ Ｒ０を実行して生成したＵフラグを汎用レジスタＲ１に転送し、第４ステップの条件分岐の前に、フラグ転送命令ＭＯＶＴ Ｒ０を実行して生成したＴフラグを汎用レジスタＲ１に転送し、ＮＯＴ Ｒ０で論理反転し、ＡＮＤ ＃１，Ｒ０で上位をクリアし、ＯＲ Ｒ０，Ｒ１で（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）を生成する。更に、ＳＨＬＲ Ｒ１で（ｐ＝＝ＮＵＬＬ）｜〜（ｉ＞１０）を３２ビットフラグＴに格納する。したがって、命令数が４命令増えて２倍になり性能が低下する。このように、フラグ更新プレフィックス命令は複雑な条件判定を高速化することが出来る。
【００８１】
以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。例えばフラグ更新プレフィックス命令はＯＲＮＴＵに代表されるように、後続命令が生成するフラグによって更新するフラグの指定に加えて、後続命令が生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行う機能を有するものとした。本発明はそれに限定されず、先に生成された夫々のデータサイズに対応するフラグのうち後続命令が生成するフラグによって更新するフラグを指定する機能だけを持つ命令であってもよい。
【符号の説明】
【００８２】
ＩＣ 命令キャッシュ
ＩＦＵ 命令フェッチユニット
ＩＤＵ 命令デコードユニット
ＥＸＵ 実行ユニット
ＬＳＵ ロードストアユニット
ＤＣ データキャッシュ
ＢＩＵ バスインタフェースユニットユニット
ＩＡ 命令アドレス
ＥＩＡ 外部命令アドレス
ＯＰ 命令
ＢＲＣ 分岐制御信号
ＥＸＣ 実行制御情報
ＬＳＣ ロードストア制御情報
ＲＦ レジスタファイル
ＥＸＡ，ＥＸＢ 実行用オペランド
ＬＳＡ，ＬＳＢ ロードストア用アドレスオペランド
ＳＤ ストアデータ
ＥＸＯ 実行結果
ＤＡ データアドレス
ＤＣＳＤ データキャッシュストアデータ
ＤＣＬＤ データキャッシュロードデータ
ＥＬＤ 外部ロードデータ
ＥＩＡ 外部命令アドレス
ＥＡ 外部アドレス
ＥＤ 外部データ
ＥＩ 外部フェッチ命令
ＥＳＤ 外部ストアデータ
ＡＬＵ 算術論理演算器
ＳＦＴ シフタ
ＦＭ３２ ３２ビットフラグマルチプレクサ
ＦＭ６４ ６４ビットフラグマルチプレクサ
Ｍ３２ ３２ビットシフトアウトマルチプレクサ
Ｍ６４ ６４ビットシフトアウトビットマルチプレクサ
ＯＭＵＸ 出力マルチプレクサ
Ｔ ３２ビット演算用フラグ
Ｕ ６４ビット演算用フラグ
ｎｅｗＴ 新たな３２ビットフラグ
ｎｅｗＵ 新たな６４ビットフラグ
ＦＭＵＸ フラグマルチプレクサ
ＡＬＯ，ＳＦＯ 実行結果
ＧＴ３２ ３２ビットデータサイズの符号付大フラグ
ＧＵ３２ ３２ビットデータサイズの符号なし大フラグ
Ｚ３２ ３２ビットデータサイズのゼロフラグ
Ｖ３２ ３２ビットデータサイズのオーバーフローフラグ
Ｃ３２ ３２ビットデータサイズのキャリーフラグ
ＧＴ６４ ６４ビットデータサイズの符号付大フラグ
ＧＵ６４ ６４ビットデータサイズの符号なし大フラグ
Ｚ６４ ６４ビットデータサイズのゼロフラグ
Ｖ６４ ６４ビットデータサイズのオーバーフローフラグ
Ｃ６４ ６４ビットデータサイズのキャリーフラグ
ＳＬ３２ ３２ビット左シフトアウトビット
ＳＬ６４ ６４ビット左シフトアウトビット
ＳＲ 右シフトアウトビット
ＳＦ３２ ３２ビットシフトアウトフラグ
ＳＦ６４ ６４ビットシフトアウトフラグ
Ｓ３２ ３２ビットフラグソースマルチプレクサ
Ｓ６４ ６４ビットフラグソースマルチプレクサ
ＦＬ３２ ３２ビットフラグ論理演算器
ＦＬ６４ ６４ビットフラグ論理演算器
【特許請求の範囲】
【請求項１】
演算処理を行なって複数のフラグを生成可能な演算命令を命令セットに有するデータプロセッサであって、
前記演算命令によって生成した複数のフラグのうち後続命令によって生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を前記命令セットに有する、データプロセッサ。
【請求項２】
演算処理を行なって複数のフラグを生成可能な演算命令を命令セットに有するデータプロセッサであって、
前記演算命令によって生成した複数のフラグのうち後続命令によって生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令によって生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を前記命令セットに有する、データプロセッサ。
【請求項１】
演算処理を行なって複数のフラグを生成可能な演算命令を命令セットに有するデータプロセッサであって、
前記演算命令によって生成した複数のフラグのうち後続命令によって生成するフラグによって更新するフラグを指定する当該後続命令を修飾するプレフィックス命令を前記命令セットに有する、データプロセッサ。
【請求項２】
演算処理を行なって複数のフラグを生成可能な演算命令を命令セットに有するデータプロセッサであって、
前記演算命令によって生成した複数のフラグのうち後続命令によって生成するフラグによって更新するフラグの指定に加えて、修飾する後続命令によって生成するフラグのうち使用するフラグの指定、及び指定した２つのフラグ間の論理演算の指定を夫々行うプレフィックス命令を前記命令セットに有する、データプロセッサ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−９３０５１（Ｐ２０１３−９３０５１Ａ）
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願番号】特願２０１３−１９２００（Ｐ２０１３−１９２００）
【出願日】平成２５年２月４日（２０１３．２．４）
【分割の表示】特願２００８−３７０６９（Ｐ２００８−３７０６９）の分割
【原出願日】平成２０年２月１９日（２００８．２．１９）
【出願人】（３０２０６２９３１）ルネサスエレクトロニクス株式会社 (8,021)
【Ｆターム（参考）】
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願日】平成２５年２月４日（２０１３．２．４）
【分割の表示】特願２００８−３７０６９（Ｐ２００８−３７０６９）の分割
【原出願日】平成２０年２月１９日（２００８．２．１９）
【出願人】（３０２０６２９３１）ルネサスエレクトロニクス株式会社 (8,021)
【Ｆターム（参考）】
[ Back to top ]