JP3806341B2 - サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム - Google Patents
サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム Download PDFInfo
- Publication number
- JP3806341B2 JP3806341B2 JP2001357626A JP2001357626A JP3806341B2 JP 3806341 B2 JP3806341 B2 JP 3806341B2 JP 2001357626 A JP2001357626 A JP 2001357626A JP 2001357626 A JP2001357626 A JP 2001357626A JP 3806341 B2 JP3806341 B2 JP 3806341B2
- Authority
- JP
- Japan
- Prior art keywords
- instruction
- sub
- functional processing
- cluster
- instructions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Advance Control (AREA)
- Executing Machine-Instructions (AREA)
- Devices For Executing Special Programs (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
【０００１】
【発明の背景】
この発明は、プロセッサ命令を圧縮するための超長命令語（ＶＬＩＷ）計算アーキテクチャ、方法および装置に関し、より特定的にはＶＬＩＷ命令の記憶要件を減じるための方法および装置、ならびに命令のオプコード部分を圧縮するための方法および装置に関する。
【０００２】
処理効率を最適化するための従来の努力において、命令帯域幅よりもデータ帯域幅に多く対処がなされてきた。この偏重は、たとえば典型的にはデータキャッシュミス率よりも少ない命令キャッシュ率を示すベンチマークプログラムに基づくと、正しいように思われる。そのような結果は、オフチップ命令帯域幅要件はデータ帯域幅要件よりも小さいことを示す。しかしながら、画像処理のようないくつかの商業的作業負荷に対しては、典型的にはデータキャッシュミス率は命令キャッシュミス率よりも低い。したがって、命令帯域幅を最適化する必要性が増大している。
【０００３】
最近の２つの傾向が命令帯域幅を増大させ、したがって、大きなサイズの命令キャッシュに対する必要性を増大させている。第１の傾向は、超長命令語（ＶＬＩＷ）アーキテクチャが多くの高性能プロセッサアーキテクチャにおいて一般的になってきていることである。ＶＬＩＷアーキテクチャは、その広い命令ビットを活用してサイクルごとに多数の動作を実行する。これが直接反映して、スーパースカラアーキテクチャと比較して顕著に増大した命令帯域幅をもたらす。たとえば、２５６ビットのＶＬＩＷ命令幅（典型的な縮小命令セットコンピュータ（ＲＩＳＣ）命令よりも４倍から８倍広い）は珍しくはない。
【０００４】
画像処理などのマルチメディア計算アプリケーションは、多数のデータストリームを扱うための並列構造を用いてより効率的に実現される。テキサス州ダラスのテキサス・インスツルメント（Texas Instruments）によって製造されるＴＭＳ３２０Ｃ６ｘおよび、日本国東京の株式会社日立製作所とカリフォルニア州キャンベルのイクエータ・テクノロジー（Equator Technologies）とによって製造されるＭＡＰ１０００などのＶＬＩＷプロセッサは、データストリームと命令ストリームとの両方の大量の並列性をサポートし、プログラム命令の並列またはパイプライン化された実行を実現する。
【０００５】
ＶＬＩＷプロセッサは、クラスタと呼ばれる１つ以上の多数の均一な処理ブロックを有する。クラスタの各々は、共通の数の機能処理単位を含む。ＶＬＩＷ命令は多数のサブ命令フィールドを含む。ＶＬＩＷ命令のサイズは線形に増大し、並列命令の数はサブ命令フィールドにおいて並行に規定される。命令に現われるサブ命令は並列実行のために機能処理単位の間で分散される。
【０００６】
従来のＶＬＩＷプロセッサは、典型的には命令ごとに１０未満の動作を実行する。同時実行の数は将来のメディアプロセッサにおいて実質的に増大する見込みであり、命令は２５６または５１２ビット幅になる見込みである。しかしながら、命令のサイズが増大するにつれ、対応してデータフローおよびメモリ構造に対する負荷が増大する。十分な命令フェッチ帯域幅を提供するために、ＶＬＩＷ命令は典型的には最初に外部メモリからフェッチされ、実行される前にオンチップ命令キャッシュにストアされる。たとえばタイト処理ループの間の、キャッシュのスラッシング（すなわち、サイクルミス）は、非常に望ましくなく、性能の劣化につながる。したがって、命令キャッシュを効率的に管理して所望の高い処理スループットを維持することが強く望まれてきている。
【０００７】
同時に、プロセッサのクロック周波数が増大し、より広いＶＬＩＷアーキテクチャが適用され、かつより複雑なアルゴリズムが開発されるにつれ、より大きな命令キャッシュに対する必要性は増大する。したがって、ＶＬＩＷ命令を効率的に扱いかつキャッシュするための方法に対する必要性がある。
【０００８】
第２の傾向は、プロセッサクロック周波数を増大するにあたって深い実行パイプラインの使用がクリティカルになってきていることである。深い実行パイプラインはリードアフターライト依存においてコンフリクトの可能性を増大させる。コンフリクトはＮＯＰ命令の挿入か、または実行パイプラインをストールさせるハードウェア検出技術によって解決される。いずれの場合においても、貴重な実行サイクルが失われ、これはプロセッサの最大限の活用を阻む。ソフトウェアパイプライン化はこれらの深い実行パイプラインにおけるリードアフターライトコンフリクトをなくすことにおいて重要なツールとなった。ソフトウェアパイプライン化は、タイトループを何度かアンロールし、かつタイトループの多数の反復をオーバーラップさせて、付加的なＮＯＰまたはプロセッサストールサイクルなしにリードアフターライト依存を解決させるための余地を作ることを可能にする。これはタイトループサイズを増大させ、よって命令キャッシュミス率をも増大させるという弊害がある。したがって、命令帯域幅を減じるか、より効率的に扱う技術に対する必要性が存在する。
【０００９】
複合命令セットコンピュータ（ＣＩＳＣ）アーキテクチャおよび縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャにおいては、命令キャッシュの効率性により命令圧縮をほとんど必要としなかった。しかしながら、ビルコウスキ（Bealkowski）他による１９９７年７月３日発行の米国特許第５，６３６，３５２号の「圧縮命令を用いるための方法および装置」においては、命令圧縮技術が導入されている。命令はオプコード（すなわち命令オペランド）および１つ以上のデータオペランド（たとえばソースオペランドフィールドおよびデスティネーションオペランドフィールド）からなる。１つ以上の制御ビットもまた命令内に含まれる。ビルコウスキ他は、頻繁に用いられる命令に対するエントリを含む、シノニムテーブルと呼ばれるテーブルを実現する。命令のシーケンスは以前に定義されていない特別オプコードおよびそれぞれのシノニムテーブルへのインデックスを有する単一の命令に圧縮される（たとえば、命令内で許可されるビットの数に基づく限度まで、シーケンスの命令ごとに１つが圧縮される）。
【００１０】
ビルコウスキ他の圧縮技術の制限とは、典型的なプログラムにおける唯一の（unique）命令の数が非常に大きいことである。したがって、ビルコウスキ他は１２ビットの最大インデックス幅と、エントリの各々が３２ビットの命令を保持する４０９６エントリのシノニムテーブルとを提案する。そのようなテーブルは１６キロバイトのオンチップメモリを必要とする。そのようなテーブルのサイズは高性能プロセッサなどにおいて用いられるレベル１命令キャッシュに匹敵するので、これは費用のかかる解決策である。ビルコウスキ他は、シノニムテーブルが読出専用メモリ内にストアされ、かつマイクロプロセッサ設計の時点で予め規定される１つの実施例を提案する。別の実施例においてはビルコウスキ他は、シノニムテーブルがプロセッサ初期化の間にロード可能であることを提案する。しかしながら企図される場合、テーブルは静的で変化しない構成である。したがって、命令帯域幅を減じるためのより効率的な解決策に対する必要性がある。
【００１１】
【発明の要約】
この発明に従うと、ＶＬＩＷ命令のサブ命令は機能処理単位の間で共用されて、命令キャッシュに、ある実施例においてはメインメモリにストアされるＶＬＩＷ命令のサイズを減じる。特定的には、ＶＬＩＷ命令はサブ命令共用の場合に圧縮される。ある実施例においては命令はコンパイル時に圧縮され、圧縮された形式でメインメモリにストアされる。他の実施例においては命令は圧縮されない形式でメインメモリにストアされ、キャッシュメモリにストアされる前に圧縮される。
【００１２】
この発明の一局面によると、命令圧縮制御ビットの組がＶＬＩＷ命令の各々に関連付けられる。一実施例においてはＶＬＩＷ命令は命令内の制御ビット組を含むよう形式化される。ＶＬＩＷ命令は、複数のサブ命令フィールド、命令圧縮制御ビット組、およびＮＯＰ命令の位置を示す（すなわち、空である）ものなどのような他の雑制御ビットを含む。
【００１３】
完全に拡張された形式においては、ＶＬＩＷ命令は予め規定された数のサブ命令フィールドを含み、フィールドの数はＶＬＩＷ命令を実行するプロセッサのアーキテクチャによって決定される。サブ命令フィールドのいくつかはＮＯＰ命令であり得る。さらにサブ命令フィールドのいくつかは他のサブ命令フィールドにあるものと同じサブ命令を含み得る。ＮＯＰ命令のために割当てられるスペースを除去するために命令を圧縮することが公知である。この発明に従うと、選択された場合のサブ命令の冗長性を減じるための方策が提供される。
【００１４】
１つの命令が４つのサブ命令フィールドを含むアーキテクチャを考察する。そのような命令に対して関連する１５の状況が存在する。１つの状況においては、冗長なサブ命令は存在しない（たとえば、ＡＢＣＤ）。残りの状況においては、サブ命令の間にある程度の冗長性が存在する（たとえば、ＡＡＡＡ、ＡＡＡＢ、ＡＡＢＡ、ＡＢＡＡ、ＢＡＡＡ、ＡＡＢＢ、ＡＢＡＢ、ＡＢＢＡ、ＡＡＢＣ、ＡＢＡＣ、ＡＢＣＡ、ＢＡＡＣ、ＢＡＣＡ、ＢＣＡＡ）。Ａ、Ｂ、ＣおよびＤはサブ命令が別のフィールド内のサブ命令と同一であるか異なっているかを識別するために用いられていることに留意されたい。当業者においては、多数の異なったサブ命令Ａが存在することが認識されるであろう。同様に、多くの異なったサブ命令Ｂ、ＣおよびＤが存在する。
【００１５】
より多くのサブ命令フィールドが存在するアーキテクチャに対しては、さらなる冗長なサブ命令の状況が存在する。いかなる所与のアーキテクチャに対しても、２zより多い起こり得る状況は存在せず、ここで「ｚ」はサブ命令フィールドの数である。すべての冗長状況をカバーするために、「ｚ」までの制御ビットが存在するであろうが、ここでｚはプロセッサアーキテクチャにおいて許容されるサブ命令フィールドの最大数である。
【００１６】
ある実施例においては、すべてのそのような状況は命令の各々に「ｚ」の制御ビットを含むことによりカバーされる。しかしながら、命令幅が増大するにつれ、サブ命令共用のためにそのように多数の付加的な制御ビットを加えることは望ましくないおそれがある。特定的には、実務上何度も出現し繰返すサブ命令冗長性の間にあるパターンが見られる傾向がある場合には、そのような多くのビットのコストは過剰に思われる。結果として、好ましい実施例においては制御ビットの数を「ｚ」未満に減じて、約２zの予め規定された数のサブ命令共用状況を扱うことを可能にする。
【００１７】
サブ命令冗長性のパターンが変化する異なったアプリケーションに対して異なったプロセッサを設計し得る。さらに、どの場合にサブ命令共用のためにサブ命令冗長性をカバーするかは、プロセッサが対象とするアプリケーション（たとえば、画像処理アプリケーション）に対して最も大きな影響を与えるよう、所与のプロセッサに対して戦略的に選択される。
【００１８】
いかなるサブ命令冗長性状況も潜在的にカバーされてプロセッサアーキテクチャ内に設計されるが、１つの方策においてはすべてまたはそれ以下のサブ命令共用可能性がカバーされる。一実施例においてはサブ命令共用は対応の機能処理単位に対して向けられる冗長なサブ命令に対して提供される。機能処理単位はプロセッサの一部である。プロセッサは「ｚ」の機能処理単位を含むが、ここで「ｚ」は１つの命令内のサブ命令の最大数である。しかしながら、より特定的には、プロセッサは複数のクラスタを含み、クラスタの各々は共通の数の機能処理単位（ＦＰＵ）を含む。１つのクラスタ内のＦＰＵの各々に対して、互いのクラスタ内に対応のＦＰＵが存在する。対応のＦＰＵの各々は同じ機能を有する。たとえば、４つのＦＰＵの３つのクラスタがあると、４組の対応するＦＰＵが存在する。１つの方策においては、いずれか２つ以上の対応のＦＰＵの間のサブ命令冗長性の並べ替えの各々がカバーされる。そのような例においてはｚ＝７であり、命令ごとに７つの命令圧縮制御ビットが存在する。これは１２の機能処理単位間の、すべての可能性のあるサブ命令共用状況をカバーするための制御ビットの最大数（たとえば、１２）よりも少ない。
【００１９】
この発明の別の局面に従うと、クラスタの各々における対応の機能処理単位に向けられる冗長なサブ命令が圧縮される。特定的には、少なくとも２つのクラスタにおける対応の機能処理単位に対する１つの命令内に同じサブ命令が存在すると、この発明にしたがって、サブ命令の１つのコピーのみがストアされればよい。対応の機能処理単位に対する冗長なサブ命令は省かれ、圧縮された命令をもたらす。そのような圧縮に対しては、特定のサブ命令を共用する冗長なサブ命令フィールドを識別する命令圧縮制御ビットの対応する条件が存在する。
【００２０】
この発明の別の局面によると、ＶＬＩＷプロセッサに対するコンピュータプログラムのコンパイルの間に（たとえば、より高レベルの言語ソースコードまたはアセンブラソースコードのアセンブリ）、命令圧縮制御ビットは所与の命令に対して圧縮の各々を規定する条件を特定するよう設定される。命令圧縮制御ビットを含む命令は、圧縮されたまたは圧縮されない形式でメモリ内にストアされる。圧縮されない形式でストアされる場合、命令はプロセッサのオンチップ命令キャッシュにストアされる前に圧縮される。したがって、命令は命令のメインメモリへの記憶と命令のオンチップ命令キャッシュへの記憶との間のいずれかのステップで圧縮される（たとえば、これは圧縮されてメインメモリで復元される；これは圧縮されて一次のキャッシュまたは二次のキャッシュにストアされる；これはオンチップ命令キャッシュに移動するときに圧縮される）。
【００２１】
この発明の別の局面によると、命令圧縮制御ビットの条件は、どのように圧縮命令が実行のために圧縮解除されるべきかを規定する。特に制御ビットは、圧縮命令内の１つ以上のサブ命令が、ＶＬＩＷプロセッサの機能処理単位の間で同時実行のためにどのように共用されるべきかを判断する。命令圧縮制御ビットの組は、冗長的にではなくすぐに冗長な対応のサブ命令がストアされる１つ以上の圧縮条件を識別する。識別される条件の各々は、少なくとも２つの対応の機能処理単位によって共用されるべきサブ命令に対応する。
【００２２】
異なったクラスタの機能処理単位を、対応する機能処理単位であると関連付け、かつそのような対応の機能処理単位に向けられる冗長なサブ命令を圧縮することの利点は、画像計算アルゴリズムの通常のプログラム構造によるものである。出願人らは、同じサブ命令が多数のクラスタにおいて用いられる画像計算ライブラリ関数のためのプログラムコードにおいて多くのタイトループを認識した。たとえば２つのクラスタを有するＶＬＩＷプロセッサで実現される２Ｄ畳み込み関数に対しては、最も頻繁に用いられるサブ命令は、内積および、内積の解の区分短縮（partitioned compaction）である。これらのサブ命令のいずれかを実行するほとんどの命令に対して、多くのクラスタが同じサブ命令を割当てられていることが認識された。特定的にはそのような関数のためのＭＡＰ１０００プロセッサに対するアセンブリコードにおいては、出願人らはタイトループプログラムが１３３の命令のうち、両方のクラスタに対して全く同じサブ命令（オペランドを含む）からなる６７の命令を有することを認識した。したがって、対応の機能処理単位に向けられるサブ命令の冗長性は重要な画像処理アルゴリズムにおいて顕著に発生する。ＶＬＩＷ命令における冗長性をなくして、多数のクラスタにおいて同じサブ命令が実行されるべきである場合に必要となる命令ビットを少なくすることにより、プログラムサイズが減じられる。さらに、命令キャッシュ利用の効率性が向上し、効率的な命令フェッチ帯域幅が増大する。
【００２３】
オプコード圧縮実施例においては、命令帯域幅は、命令の全体を圧縮する命令圧縮技術とは異なる技術で減じられる。共通して用いられるオプコードの１つ以上のテーブルをストアするために、オンチップランダムアクセスメモリのある領域が割当てられる。命令内の通常のオプコードは、テーブルとテーブルへのインデックスとを識別するコードに置き換えられる。コードは圧縮されないオプコードよりも少ないビットを含む。その結果、命令が圧縮される。
【００２４】
この技術はさまざまなプロセッサアーキテクチャに対して実現されるが、この技術は多数のオプコード（すなわち、サブ命令の各々に対するもの）を含むＶＬＩＷ命令に対して特に有利である。一実施例においては、命令の特別なコードビットの間の１つのビットが、ＶＬＩＷ命令が圧縮されているかまたは圧縮されていないかを明示するために割当てられる。たとえば、ある実施例においてはＶＬＩＷ命令に対するオプコード圧縮は全か無かである。すなわち、すべてのサブ命令オプコードが圧縮されるかいずれもされないかである。ＮＯＰ命令オプコードを圧縮するための十分な方法が存在するので、代替的な従来の方法を用いてこの発明の実施例の圧縮命令形式の中のＮＯＰサブ命令を識別してもよい。
【００２５】
この発明の１つの局面によると、共通して用いられるオプコードのテーブルはリアルタイム処理の間に動的に更新され、上書きされ、かつ置き換えられる。テーブルはアプリケーションプログラムの実行の間にストアすることができる。動的更新の利点は、より小さなテーブルサイズが効率的に命令帯域幅を減じることである。ある実施例においては、テーブルは動的である必要はなく、固定されていてもよい。広い範囲のアプリケーションプログラムに対して最も頻繁に用いられるすべてのオプコードをストアするために、そのようなテーブルは動的に更新されるテーブルよりも大きくなる。好ましい動的な実施例に対しては、テーブルはアプリケーションにカスタマイズされ、プログラム設計の一部となる。たとえば、オプコードテーブルにストアされるべきオプコードのそれぞれのテーブルを備えて異なったタスクがプログラムされる。それぞれのテーブルは次いでタスクが切替わるときにロードされる。より小さな動的オプコードテーブルは、オプコードのより効率的な選択、およびタスク切替えの間のテーブルローディングに対する低いオーバーヘッドの利点をもたらす。さらに、多数のテーブルをストアするためにプロセッサチップにスペースが割当てられる場合、１つのテーブルがアクティブにされ別のものはインアクティブにされるために、テーブルローディングオーバーヘッドはさらに減じられる。
【００２６】
ある実施例においては、所与のオプコードテーブルにおける１つ以上の特定のエントリが更新される。テーブルインデックスを用いてオプコードテーブル内のどこで更新された値を書込むべきかを識別する特定の命令が含まれる。さらにある実施例にＣＩＳＣ様の命令が含まれ、データをメモリからより早くオプコードテーブルに転送し、テーブルをよりコンパクトにストアする。
【００２７】
ある実施例においては、オプコードテーブルは不揮発性メモリから関数コール内の初期にプレローディングされる。さらに、以前のテーブルに対するポイントが維持されて、それにより関数が完了し処理がコーリングルーチンに戻った後で、コーリングルーチンに対するオプコードテーブルが復元される。
【００２８】
この発明のこれらおよび他の局面ならびに利点は、添付の図面と併せて以下の詳細な説明を参照することにより、よりよく理解されるであろう。
【００２９】
【特定の実施例の説明】
概要
図１は、超長命令語（ＶＬＩＷ）プロセッサのためのプログラムコンパイルおよび記憶のブロック図を示す。「超長命令語」ＶＬＩＷという用語は、コンピュータシステムおよびプログラムアーキテクチャ、並列処理および画像処理の分野における用語であり、これは一般的にプロセッサが典型的には、６４ビット以上であり多数のサブ命令からなる命令を扱うことができるアーキテクチャを指す。
【００３０】
プログラムエンジニアはソースコード１２を準備し、テストし、かつデバッグする。ソースコード１２はアセンブラ言語または高階プログラミング言語で書かれる。ソースコードは次いでコンパイラ／アセンブラ１４によってコンパイル／アセンブルされ、マシンコード１６をもたらす。マシンコード１６は、マシンコード１６を実行すべきプロセッサを有するコンピュータのメモリ１８にストアされる。
【００３１】
図２を参照すると、ホストコンピュータ１０は、超長命令語（ＶＬＩＷ）プロセッサ２０、命令キャッシュ２２、およびメインメモリ２４を含む。好ましい実施例においては命令キャッシュ２２はプロセッサ２０の一部である（オンチップに位置する）。メインメモリは、メモリ１８であるか、またはメモリ１８からコンピュータプログラムマシンコード１６を受取る。図３を参照すると、典型的なＶＬＩＷプロセッサ２０アーキテクチャは、機能処理単位（ＦＰＵ）２８の複数のクラスタ２６を含む。クラスタ２６の各々は、共通の数の機能処理単位２８を含む。その結果、異なったクラスタ２６の機能処理単位２８に１対１対応が存在する。図３は、クラスタごとに「ｍ」個の機能処理単位の「ｎ」個のクラスタを有する汎用アーキテクチャを示す。第１のクラスタは、（１，１）から（１，ｍ）までの機能処理単位を有する。第２のクラスタは、（２，１）から（２，ｍ）までの機能処理単位を有する。ｎ番目のクラスタは、（ｎ，１）から（ｎ，ｍ）までの機能処理単位を有する。したがって、ｎ＊ｍ個の機能処理単位が存在する。クラスタ２６ごとに、専用レジスタファイル２７が存在する。ｎ、ｍ、およびｎ＊ｍの値は、プロセッサ２０アーキテクチャによって決定された予め規定された数である。そのような値は異なった実施例に対して変化し得る。ｎ＊ｍの値は、ｎ＊ｍ機能処理単位を有するプロセッサに対するＶＬＩＷ命令内に含まれ得るサブ命令の最大数に相当する予め規定された数である。
【００３２】
図４を参照すると、プロセッサ２０に対する命令形式３０は最大ｎ＊ｍ個のサブ命令フィールド３２を含む。サブ命令フィールド３２の各々の内容は処理のために対応の機能処理単位２８に経路制御される。すべてのｎ＊ｍ個のサブ命令フィールドが埋められた命令に対しては、サブ命令はｎ＊ｍ個の機能処理単位２８の各々に経路制御される。典型的には、すべてのｎ個のクラスタ２６に対して１つのみのプログラムカウンタが存在する。その結果、機能処理単位は典型的にはシンクロナスに動作して所与の命令のサブ命令を同時実行する。
【００３３】
サブ命令フィールド３２ｉが空である場合、命令３０は従来の技術を用いて圧縮される。その結果、命令によって占有されていたメモリスペースが減じられる。この発明は、多数のクラスタ２６の対応の機能処理単位２８に対して冗長なサブ命令が存在する場合命令サイズを圧縮するさらなる技術に関する。特に、画像計算アルゴリズムのタイトループにおいては、同じサブ命令が多数のクラスタにおいて実行されるのが認識されている。従来的には、サブ命令はサブ命令フィールド３２の各々で繰返され、命令キャッシュ２０のメモリスペースの非効率的な使用およびメモリ転送帯域幅の非効率的な適用をもたらした。この発明の局面による圧縮された命令形式においては、サブ命令が多数の機能処理単位２８の間で共用される。
【００３４】
ＶＬＩＷ圧縮命令形式
図５を参照すると、それぞれのサブ命令３６をストアする「ｎ×ｍ」個のサブ命令フィールド３２を含む、圧縮されない命令３４の例が示される。あるサブ命令フィールド３２は空白であり得る（たとえば、フィールド３２（２，１））。あるサブ命令フィールドは別のサブ命令フィールドど同じサブ命令を含み得る。サブ命令フィールド３２の各々は、特定のクラスタ２６の特定の機能処理単位２８に関連付けられる。示される例においては、サブ命令フィールド（１，１）から（１，ｍ）までは、クラスタ１のそれぞれの機能処理単位（１，１）から（１，ｍ）までにに関連付けられる。サブ命令フィールド（２，１）から（２，ｍ）まではクラスタ２のそれぞれの機能処理単位（２，１）から（２，ｍ）までに関連付けられる。サブ命令フィールドの各々は同様に、サブ命令フィールド（ｎ，１）から（ｎ，ｍ）までがクラスタｎのそれぞれの機能処理単位（ｎ，１）から（ｎ，ｍ）までに関連付けられる。
【００３５】
クラスタ１からｎの各々に対する機能処理単位（＿，１）はここで対応の機能処理単位と呼ばれることに留意されたい。特に、それらは多数のクラスタの各々の、対応の第１の機能処理単位と呼ばれる。対応の機能処理単位（＿，ｉ）によって処理するための所与の命令内に同じサブ命令が含まれている場合、命令形式は圧縮されて冗長性をなくす。同じサブ命令が含まれているが、対応しない機能処理単位（＿，ｉ）および（＿，ｊ）へのものである場合、冗長性は対処されないことに留意されたい（すなわち、命令形式は必ずしも圧縮されなくてもよい）。ある実施例においてはこれらの冗長性もまた対処されるが、好ましい実施例においてはこれらは無視される。そのような冗長性が無視されるのは、これらが対応の機能処理単位に向けられるサブ命令の間の冗長性の対処における利得に匹敵するほどの、効率性における利得をもたらさないためである。
【００３６】
図６を参照すると、空白フィールドが省かれた従来の圧縮された形式３４′で例示的な命令３４が示される。圧縮されない形式において空白フィールドが生じるであろう位置はアスタリスク（「＊」）で示す。
【００３７】
図７を参照すると、この発明の局面に従った圧縮された形式３４″における例示的な命令３４が示される。圧縮された形式において、命令圧縮制御ビットの組３７のための領域と、１つ以上の、好ましくは空ではないサブ命令フィールドとが存在する。同じサブ命令をストアする対応のＦＰＵ（＿，ｉ）に対するサブ命令フィールドは、対応の機能処理単位のうちの１つのみに対するサブ命令を含むよう減じられる。そのような対応の機能処理単位はサブ命令を共用する。
【００３８】
示される例示的な命令に関しては、第１のクラスタおよびｎ番目のクラスタの両方の第２の機能処理単位に向けられるサブ命令は、共通のサブ命令を有することに留意されたい。これらのＦＰＵ（１，２）および（ｎ，２）は対応の機能処理単位である。したがって、冗長なサブ命令は省かれる。さまざまな実施例において冗長なサブ命令は第１の発生、第２の発生または他の発生において省かれる。示される実施例においては第１の発生以外のすべてが省かれる。圧縮されない形式において、省かれた冗長フィールドが発生するであろう位置はダブルアスタリスク（「＊＊」）で示す。また、空のサブ命令フィールドもまた圧縮されていることに留意されたい。さまざまな実施例において、従来の圧縮技術もまた実現されるか否かに応じて空のフィールドは圧縮されても圧縮されなくてもよい。
【００３９】
また、サブ命令フィールド３２（１，ｍ）および３２（２，２）の各々は共通のサブ命令「Ｃ」を有することに留意されたい。ある実施例においては圧縮動作が行なわれてこの冗長を避ける。しかしながら、このような冗長は頻繁には発生しないことが見出されたので、好ましい実施例においてはこの冗長は「そのまま」残される。同様に、サブ命令フィールド３２（ｎ，１）および３２（ｎ，３）もまた共通のサブ命令「Ｅ」を有する。これらは共通のクラスタ内でＦＰＵに対して向けられる。ある実施例においては、圧縮動作が行なわれてこの冗長性を避ける。しかしながら、このような冗長は頻繁には発生しないことが見出されたので、好ましい実施例においてはこの冗長は「そのまま」残される。
【００４０】
命令圧縮制御ビットの組３７は、対応の機能処理単位がサブ命令を共用するべき起こり得る条件の各々を識別するために十分なビットを含む。たとえば、クラスタごとに「ｍ」個のＦＰＵの２つのクラスタがある場合、組３７は「ｍ」個の制御ビットを含む。クラスタごとに２つのＦＰＵの「ｎ」個のクラスタがある場合、組３７は「ｎ」個の制御ビットを含む。クラスタごとに「ｍ」個のＦＰＵの「ｎ」個のクラスタを有するアーキテクチャにおいては、ベストモードの実施例における組３７はｎ＋ｍ個のの制御ビットを含むが、ここでｎ＞２であり、ｍ＞２である。他の実施例においては制御ビットの数は変化し得る。以下のテーブル１は、クラスタごとに２つの機能処理単位の２つのクラスタが存在するアーキテクチャに対するビット符号化を示す。そのようなアーキテクチャに関しては、組３７内に２つの制御ビットが存在する。
【００４１】
テーブル１：制御ビット符号化
００ サブ命令共用なし
０１ 圧縮された形式における第１のサブ命令がＦＰＵ（＿，１）によって共用される
１０ 圧縮された形式における第２のサブ命令がＦＰＵ（＿，２）によって共用される
１１ 圧縮された形式における第１のサブ命令がＦＰＵ（＿，１）によって共用され、かつ圧縮された形式における第２のサブ命令がＦＰＵ（＿，２）によって共用される
【００４２】
以下のテーブル２は、クラスタごとに３つの機能処理単位の２つのクラスタが存在するアーキテクチャのためのビット符号化を示す。そのようなアーキテクチャに対しては、組３７内に３つの制御ビットが存在する。
【００４３】
テーブル２：制御ビット符号化
０００ サブ命令共用なし
００１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用される
０１０ 圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用される
０１１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用される
１００ 圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１０１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１１０ 圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１１１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
【００４４】
さまざまな実施例において、２つ以上の対応のＦＰＵ（＿，ｉ）の間で共用されるべきサブ命令が存在する潜在的な圧縮条件の各々を識別するために実現し得るさまざまな符号化方策が存在する。
【００４５】
命令ごとに大量の制御ビットを加えることは望ましくないおそれがあるので、圧縮条件のサブセットは減じられた数の制御ビットによって識別され得る。たとえば、クラスタごとに２つのＦＰＵを備えた４つのクラスタアーキテクチャにおいては、４つの制御ビットを上に明記されるものと同じ方法で用いるか、または３つの制御ビットを以下のテーブル３に説明されるように用いることができる。
【００４６】
テーブル３：制御ビット符号化
０００ サブ命令共用なし
００１ 圧縮された形式における第１のサブ命令がすべてのＦＰＵ（ｉ，１）によって共用される、ｉ＝１，４
０１０ 圧縮された形式における第２のサブ命令がＦＰＵ（ｉ，２）によって共用される、ｉ＝１，４
０１１ 圧縮された形式における第１のサブ命令がＦＰＵ（ｉ，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（ｉ，２）によって共用される、ｉ＝１，４
１００ 圧縮された形式における第１のサブ命令がＦＰＵ（１，１）、（３，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（３，２）によって共用され、圧縮された形式における第３のサブ命令がＦＰＵ（２，１）、（４，１）によって共用され、圧縮された形式における第４のサブ命令がＦＰＵ（２，２）、（４，２）によって共用される
１０１ 圧縮された形式における第１のサブ命令はＦＰＵ（１，１）、（２，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（２，２）によって共用され、圧縮された形式における第３のサブ命令がＦＰＵ（３，１）、（４，１）によって共用され、圧縮された形式における第４のサブ命令がＦＰＵ（３，２）、（４，２）によって共用される
１１０ 圧縮された形式における第１のサブ命令がＦＰＵ（１，１）、（２，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（２，２）によって共用され、第３から第６までのものは共用されない
１１１ 第１から第４のものは共用されず、圧縮された形式における第５のサブ命令がＦＰＵ（３，１）、（４，１）によって共用され、圧縮された形式における第６のサブ命令はＦＰＵ（３，２）、（４，２）によって共用される
【００４７】
当業者においては、異なった符号化方策を実現して、さまざまなサブ命令共用条件を識別し得ることを理解するであろう。異なった復号化アーキテクチャが異なった符号化方策に付随し、所望のサブ命令共用方策を実現するであろう。
【００４８】
サブ命令共用
図９を参照すると、制御ビットの組を復号化し、かつもしサブ命令が存在すればそれらのうちいずれがＶＬＩＷプロセッサの対応のＦＰＵの間で共用されるべきかを判断するための例示的な多重化方策が示される。一実施例においては、プロセッサ２０はそのような符号化およびサブ命令共用を行なうための論理を含む。示される実施例においては、クラスタごとに２つの機能単位２８の２つのクラスタ２６が存在する。ＶＬＩＷ命令４２は、命令キャッシュ２２から検索され、制御ビットの組３７の条件に基づいてパーズされる。そのような実施例に対するＶＬＩＷ４２命令は、２つ、３つまたは４つのサブ命令フィールド３２を含む。
【００４９】
マルチプレクサ４４は、第２のクラスタの第１の機能単位を命令４２の第１のサブ命令フィールドおよび第３のサブ命令フィールドに結合する。マルチプレクサ４６は、第２のクラスタの第２の機能単位を命令４２の第２のサブ命令フィールドおよび第４のサブ命令フィールドに結合する。上述のテーブル１における復号化方策に従うと、命令４２は組３７が００の符号化条件を有している場合に４つのサブ命令を含む。サブ命令の各々は別々のＦＰＵに経路制御される。命令４２は、組３７が０１または１０の符号化条件を有する場合に３つのサブ命令を含む。０１に符号化された場合、マルチプレクサ４４は第１のサブ命令を選択する。こうして、クラスタ１および２の第１の機能単位は第１のサブ命令を共用する。第２のサブ命令は第１のクラスタの第２のＦＰＵに向かう。第３のサブ命令はシフトされてマルチプレクサ４６に入り、これはそのような第３のサブ命令を第２のクラスタの第２のＦＰＵによって処理するために選択する。
【００５０】
組４６が１０に符号化される場合、第１のサブ命令は第１のクラスタの第１のＦＰＵに向かい、第２のサブ命令は第１のクラスタの第２のＦＰＵに向かう。マルチプレクサ４４は第３のサブ命令を選択し、それにより第３のサブ命令は第２のクラスタ内の第１のＦＰＵに向かう。マルチプレクサ４６は第２のサブ命令を選択し、それにより第２のサブ命令は第１のクラスタの第２のＦＰＵと第２のクラスタの第２のＦＰＵとによって共用される。
【００５１】
命令４２は、組３７が１１の符号化条件を有する場合に２つのサブ命令を含む。そのような場合においてはマルチプレクサは第１のサブ命令をパスし、それにより第１のサブ命令は第１のクラスタの第１のＦＰＵと第２のクラスタの第１のＦＰＵとによって共用される。同様に、マルチプレクサ４６は第２のサブ命令をパスし、それにより第２のサブ命令は第１のクラスタの第２のＦＰＵと第２のクラスタの第２のＦＰＵとによって共用される。
【００５２】
図１０（Ａ）から（Ｅ）を参照すると、サブ命令共用は、クラスタごとにｎ＝２クラスタおよびｍ＝２ＦＰＵを有するプロセッサ上でさまざまな命令４２Ａから４２Ｅに対して比較される。命令の各々は４つまでのサブ命令３６を含む。４つのサブ命令はサブ命令が視覚的にそのデスティネーションＦＰＵと相関するように、２つの行に構成される。特定的には、一番上の行のサブ命令は第１のクラスタの第１および第２のＦＰＵ（１，１）、（１，２）のそれぞれに向けられるのに対し、一番下の行のサブ命令は第２のクラスタの第１および第２のＦＰＵ（２，１）、（２，２）のそれぞれに向けられる。さらに、命令ビットサイズはサブ命令サイズに対して等しい３２ビットであると示される。命令４２ごとに示されるのは、意図された動作４８（左側）、ＮＯＰ圧縮のみを備えた命令５０（中央）およびサブ命令共用のために圧縮された命令４２（右側）である。
【００５３】
以下のテーブル４は、サブ命令共用を備えるかまたはサブ命令共用を備えない、異なった命令の場合を指定するために用いられるいくつかの命令ビットを要約する。Ｎは命令内での空ではないサブ命令の数であり、もとの圧縮された命令は命令圧縮の後で３２×Ｎビット長さになるであろう。しかしながら、サブ命令共用があると、命令内に冗長度に応じて異なった長さが生じ得る。たとえば、制御ビット３７が００（すなわち、サブ命令共用なし）であれば、その命令に対しては３２×Ｎ＋２ビットであり、もとの命令と比較すると２ビットのオーバーヘッドを含む。しかしながら、制御ビット３７が０１または１０であれば、サブ命令共用によって１つのサブ命令フィールドが省かれる。結果は３２×（Ｎ−１）＋２ビットであり、これはこの命令に対して３０ビットを節約する。この場合に関しては、制御ビットは１１であり、２つのサブ命令フィールドが省かれ、ビットの数は３２×（Ｎ−２）＋２であり、この命令に対して６２ビットを節約する。
【００５４】
【表１】
【００５５】
いくつかのタイトループルーチン（２Ｄ畳み込み、２Ｄ復号ＦＦＴおよびアフィンワーピング（affine warping））がＭＡＰ１０００プロセッサのためにアセンブリ言語で書かれた、画像計算プログラムにおけるサブ命令共用の実際の効果が研究された。ＭＡＰ１０００はクラスタごとに２つのＦＰＵの２つのクラスタを有する。サブ命令の各々が３２ビット幅であると想定して、タイトループ内の命令の数およびそれらの冗長特性は以下のテーブル５にリストされる。２Ｄ畳み込みに関しては、サブ命令共用によって節約することのできる命令ビットの数は−２×４８＋３０×４０＋６２×４５＝３８９４ビットであると計算された。１３３の命令内で、畳み込みタイトループにおける空ではないサブ命令の総数は３３７であった。よって、もとのプログラムサイズは３３７×３２＝１０７８４ビットである。こうして、サブ命令共用結果はテーブル６に示すようにタイトループプログラムサイズにおいて３６．１％の減少をもたらした。同様に、２Ｄ復号ＦＦＴおよびアフィンワーピングタイトループは、それぞれプログラムサイズにおいて２３．９％および４１．９％の減少を示した。
【００５６】
【表２】
【００５７】
上述のプログラムサイズ減少はタイトループに対してのみであることに留意されたい。コール機能を併せて考察する場合、サブ命令共用の結果はより長いものになるであろう。しかしながら、結果はそれでも非常に顕著である。たとえば、５１２×５１２の８ビット画像を読込み、２Ｄ畳み込みタイトループをコールし、メモリに出力画像を書込むアプリケーションプログラムを考察すると、約１００キロバイトを占有する。サブ命令共用によって達成されるプログラムサイズ減少の合計は０．５％未満である。しかしながら、タイトループ外のプログラムのほとんどが一度のみ実行されるのに対し、タイトループは何度も反復されるので、ほとんどのプログラム実行時間は実際、タイトループ内で使用される。マップ１０００での１５×１５核を備える２Ｄ畳み込みの場合においては、タイトループ実行時間は実行時間の合計の８９％以上を占める。したがって、タイトループを利用可能な命令キャッシュに適合させることは、全体のプログラムサイズを減少させることよりも重要である。さらに、より洗練されたタイトループ（こうして命令のためにより多くのビットを必要とする）が開発され、および／または多数のタイトループが組合されて新しい高レベルタイトループを生成する場合、個々のタイトループのサイズができるだけ小さくされ、それにより新しいタイトループが命令キャッシュスラッシングを引起さない、すなわちタイトループを反復する間に過剰な命令キャッシュミスを起こさないことが望ましい。
【００５８】
冗長なサブ命令を識別し共用するための方法
図１１を参照すると、サブ命令共用機会を識別するためのフローチャート６０は、所与の命令のサブ命令が、サブ命令共用条件が存在するか否かを判断するために比較されるステップ６２を含む。一実施例においては、多数のクラスタの１つ以上の対応の機能処理単位（＿，ｉ）に対して現われるいずれのサブ命令も共用されるべきである。別の実施例においてはより限定された条件の組が特定の設計に従って指定される。たとえば上述のテーブル３は、限定された条件の組の例を挙げる。ステップ６４において、命令圧縮制御ビットの組３７はサブ命令共用条件の各々を識別するために設定される。その後に命令はステップ６８においてメモリにストアされる。ある実施例においては命令は圧縮されない形式でストアされる（または、サブ命令共用圧縮なしにＮＯＰ圧縮などの従来の圧縮技術のみを用いた形式でストアされる）。別の実施例においては、命令はステップ６６でサブ命令が共用されるべき冗長なサブ命令を省く。
【００５９】
サブ命令共用のために冗長性を除去することなく命令がメモリ内にストアされる実施例の場合は、命令を圧縮する、またはさらに圧縮するための命令が別の時点で実行される。図１２を参照すると、フローチャート６９のステップ７０において、命令圧縮制御ビットの組３７がサブ命令共用条件を識別するためにテストされる。組３７の符号化条件に従って、ステップ７２において１つ以上のサブ命令が命令形式から削除される。削除されたサブ命令は冗長なサブ命令である。ＦＰＵによって共用されるべきである同一のサブ命令が残留する。その結果、圧縮された命令または、さらに圧縮された命令がもたらされる。そのような結果として生じる圧縮された命令は命令キャッシュ２２、一次キャッシュまたはメインメモリ２４に経路制御される。命令のサイズを減じることにより、命令キャッシュにおいて要求されるスペースおよびデータをキャッシュに移動させるために必要となる時間が減じられる。フローチャート６９の方法はさまざまな実施例において、命令がメインメモリ２４から命令キャッシュ２２（図２を参照）に移動される場合に、または別の時点で行われる。
【００６０】
図１３を参照すると、命令圧縮制御ビットの組３７を復号化するための方法のフローチャート７４は、さまざまなサブ命令共用条件に対して制御ビットをテストするためのステップ７６を含む。ステップ７８において、圧縮命令４２はパーズされてサブ命令をデスティネーションであるＦＰＵ２８に経路制御する。サブ命令共用条件が存在する場合、サブ命令は複数の対応の機能処理単位に経路制御される。
【００６１】
代替的な実施例
対応のＦＰＵの間での冗長なサブ命令について、サブ命令を共用するケースを説明してきたが、ある実施例においては同様に包含され得る冗長なサブ命令のさらなる状況が存在する。命令が「ｐ」個のサブ命令フィールドを含む汎用アーキテクチャに関しては、冗長なサブ命令がない状況と、ある程度の冗長がサブ命令の間に存在する、２p-1よりも少ない状況とが存在する。ｐ＝８のサブ命令フィールドが存在するアーキテクチャに関しては、２8＝２５６より少ない状況が存在する。いくつかの状況は同じ結果を表わすので、状況の数はやや２５６よりも少なくなる。しかしながらすべてのそのような状況をカバーするために、命令圧縮制御ビットの組３７内には「ｐ」個の制御ビットが存在する。こうして、一実施例においては命令ごとに「ｐ」個の制御ビットが含まれる。
【００６２】
しかしながら、命令幅が増大する場合、サブ命令共用のために非常に多くの付加的な制御ビットを加えることは望ましくないおそれがある。特に、実務上何度も繰返し出現する、サブ命令の間の冗長性のパターンが存在する傾向がある場合、非常に多くのビットのコストは過剰であると思われるであろう。結果として、好ましい実施例においては、予め定められた数の起こり得る２pのサブ命令共用状況を処理するための制御ビットの数がｐ以下に減じられる。異なったアプリケーションに対しては異なったプロセッサが設計され、サブ命令冗長のパターンも変化する。さらに、サブ命令共用の対象となるサブ命令冗長のケースもまた、所与のプロセッサに対して戦略的に選択され、プロセッサが標的とするこれらのアプリケーション（たとえば、画像処理アプリケーション）に対して最大の効果をもたらすようにされる。上のセクションで説明された好ましい実施例は、一般的な画像処理関数の戦略的に重要なタイトループにおいて発生することが見出されたサブ命令共用シナリオ状況に関連する。
【００６３】
オプコード圧縮−概要
図１４を参照すると、この発明の実施例に従った１つ以上のオプコード圧縮テーブルを組入れたアプリケーションプログラムを処理するためのホストシステム１１１は、プロセッサ２０２、キャッシュメモリ２２、不揮発性メインメモリ２４、およびユーザインターフェイス１２０を含み、これらは１つ以上のバス構造１２２によって相互接続される。ユーザインターフェイス１２０はディスプレイ装置１２４、キーボード１２６およびポイント／クリック装置１２８を含む。
【００６４】
この発明のオプコード圧縮技術は、超長命令語（「ＶＬＩＷ」）プロセッサおよびスーパースカラプロセッサを含むさまざまなホストプロセッサ２０上で実現され得る。例示的なＶＬＩＷプロセッサは、テキサス州ダラスのテキサス・インスツルメント（Texas Instruments）によって製造されるＴＭＳ３２０Ｃ６ｘおよび、日本国東京の株式会社日立製作所とカリフォルニア州キャンベルのイクエータ・テクノロジー（Equator Technologies）とによって製造されるＭＡＰ１０００を含む。各々はデータストリームと命令ストリームとの両方の大量の並列性をサポートし、並列またはパイプライン化されたプログラム命令の実行を実現する。例示的なスーパースカラプロセッサは、ニューヨーク州のインターナショナル・ビジネス・マシーンズ（International Business Machines）およびイリノイ州シカゴのモトローラ・コーポレーション（Motorola Corporation）によって製造されるPowerPC６０４、カリフォルニア州パロアルトのインテル・コーポレーション（Intel Corporation）によるペンティアム（Ｒ）ＩＩプロセッサ、ＭＩＰＳ Ｒ１０００００、マサチューセッツ州メイナードのデジタル・イクイップメント・コーポレーション（Digital Equipment Corporation）によるDEC Alpha２１２６４、カリフォルニア州パロアルトのヒューレット・パッカード（Hewlett-Packard）によって製造されるＰＡ−ＲＩＳＣ ８０００ファミリーのプロセッサ、およびカリフォルニア州サニーベイルのサン・マイクロシステムズ（Sun Microsystems）によって製造されるUltraＳＰＡＲＣ−ＩＩを含む。
【００６５】
図１５は、単一チップ上に実現された例示的なプロセッサ２０を示す。示されるのはメディア加速プロセッサ（media accelerated processor）１０００（ＭＡＰ１０００）のプロセッサアーキテクチャである。ＭＡＰ１０００プロセッサは、直接メモリアクセス（ＤＭＡ）コントローラ１２９、データキャッシュ１３０、命令キャッシュ１３２およびクラスタ２６と呼ばれる並列実行単位を含む。そのような構成要素の各々は共通のチップ上に存在する。クラスタ２６の各々は１つ以上の機能単位２８、たとえば整数演算ならびに論理単位および整数浮動小数点グラフィック演算ならびに論理単位を有する。また、クラスタ２６の各々はいくつかの汎用レジスタ、いくつかの汎用レジスタ、いくつかの１ビットプレディケートレジスタおよび多数の専用レジスタを含む。
【００６６】
命令形式
図１６を参照すると、従来のｋビットの、圧縮されないＶＬＩＷ命令形式は、オプコード１４２、１つ以上のソースオペランドフィールド１４４およびデスティネーションオペランドフィールド１４６を含む。オプコード１４２の各々は、いくつかのサブ命令１４８に区分けされる。クラスタ２６の各々の機能単位２８ごとに１つのサブ命令が存在する。たとえばクラスタごとに２つの機能ユニットの２つのクラスタを有するＶＬＩＷプロセッサ２０に関しては、命令は４つのサブ命令１４８を含む。ソースオペランドフィールド１４４およびデスティネーションオペランドフィールド１４６は同様にサブワード１５０に区分けされる。
【００６７】
図１７を参照すると、ＶＬＩＷ命令のオプコードが、圧縮されない形式１５２およびＮＯＰサブ命令オペランドが圧縮される形式１５４で示される。ＮＯＰサブ命令を圧縮するための１つの従来の方法によると、残りのサブ命令の配置を識別する（よって、ＮＯＰサブ命令の位置をも識別する）マスクワード１５６が生成される。
【００６８】
図１８Ａおよび図１８Ｂを参照すると、ＶＬＩＷ命令のオプコードが２つのオプコード１５８、１６０に対して圧縮されない形式および圧縮された形式で示される。オプコード１５８においては、ＮＯＰサブ命令は存在しない。圧縮されたオプコード形式１６２においては、サブ命令オペランドは減じられたビット長さに圧縮される。特定的には、サブ命令１４８の各々はオプコードがコード１６３と置換えられるが、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。オプコード１６０においてはＮＯＰサブ命令が存在する。好ましい実施例においてはＮＯＰサブ命令は、従来の圧縮方法のいずれかを用いて圧縮される。次いで残りのサブ命令１４８オペランドが圧縮されて圧縮されたオペランド形式１６４を達成する。再び、残りの特定のサブ命令オペランドはコード１６３と置換えられ、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。
【００６９】
通常の動作の間に、ＶＬＩＷ命令のすべてがオプコード圧縮された形式１６２／１６４を示すわけではない。いくつかのオプコードは圧縮されず、またはＮＯＰサブ命令だけが圧縮される。しかしながら、ＶＬＩＷ命令のために好ましい実施例においては、オプコード圧縮方策を示すべきであるいかなるオプコード１４２も、すべてのサブ命令オプコードを圧縮される。しかしながら、ＮＯＰオプコードは好ましくは異なった態様で圧縮されることに留意されたい。また、ある実施例においては、サブ命令の共用はさらに、圧縮されるべきサブ命令オプコードの数を減らすことに留意されたい。
【００７０】
上のセクションにおいて、サブ命令共用と呼ばれる圧縮技術について説明した。その技術によると、オプコードが冗長なサブ命令を含む特定の場合が、サブ命令共用の対象となる。特定的には、圧縮されたサブ命令共用形式において冗長なサブ命令オペランドがより少ない回数で発生する（たとえば、１回発生する）よう、冗長性が除去される。そのような技術に対する命令形式は、サブ命令オペランドに加えて１組の制御ビットを含む。制御ビットは、サブ命令共用の特別な場合を識別する（たとえば、クラスタごとの機能単位１が、圧縮サブ命令共用オプコードの特定のサブワードにストアされるものと同じサブ命令のコピーを受取る）。サブ命令共用のいくつかの場合をここで説明する。
【００７１】
オプコード１４２が圧縮された形式であるか圧縮されない形式であるかを識別するために、制御ビット６５がすべてのオプコード形式に対して用いられる。制御ビットは、サブ命令オペランドの圧縮が実行されていることを示す１つの値を有し、実行されていない（しかしながらＮＯＰ圧縮およびサブ命令共用はやはり実行されているかも知れない）ことを示す別の値を有する。
【００７２】
図２０を参照すると、オプコード形式は圧縮されない形式１４２およびさまざまな圧縮タイプの形式において示される。形式１５４はＮＯＰ圧縮された形式１５４におけるオプコードに対応する。形式１７０は、ＮＯＰ圧縮およびサブ命令共用を示すオプコードに対応する。形式１７２は、ＮＯＰ圧縮、サブ命令共用およびオプコード圧縮の各々を示すオプコードに対応する。動作の間に、プロセッサ２０はこれらの形式のいずれかまたはすべてを、別々にまたは累積して実行し得る。
【００７３】
図２１（Ａ）を参照すると、たとえばＲＩＳＣおよび／またはスーパースカラアーキテクチャを有するプロセッサ２０に対して実現される単一命令形式８０が示される。命令は、オプコード８２、１つ以上のソースオペランドフィールド８４およびデスティネーションオペランドフィールド８６を含む。この発明は、データオペランドに対して圧縮方策が実施されているか否かに拘らずオプコード圧縮に関連するので、オプコードの圧縮についてのみここで説明する。図２１（Ｂ）の圧縮オプコード形式９２においては、オプコードは減じられたビット長さ形式に圧縮される。特定的には、オプコード８２はコード９４と置換えられ、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。オプコード８２が圧縮された形式であるか、または圧縮されない形式であるかを識別するために、制御ビット６５がオプコード形式８２、９２に対して用いられる。制御ビットは、サブ命令オペランドの圧縮が実行されていることを示す１つの値と、実行されていない（しかしながら、ＮＯＰ圧縮およびサブ命令共用はやはり実行されているかも知れない）ことを示す別の値とを有する。
【００７４】
オプコードテーブル
図１９は、複数のエントリ１６８を有するオプコードルックアップテーブル１６６を示す。ホストプロセッサ２０に対する一部のオプコードは、オプコードテーブル１６８にエントリを有する。好ましい実施例においては、小さな、選択されたオプコードのサブセットがテーブル１６８にストアされる。ベストモードの実施例においては、オプコードテーブル１６６の内容はコンパイルの間に規定され、それにより所与のアプリケーションに対してカスタマイズされる。いくつかの実施例においては、オンチップメモリ上で代替的にアクティブになり現在のオプコードテーブルとしての役割を果たし得る複数のオプコードが存在する。オプコードテーブルは、タスク切替の間にタスクに対してロードされる。したがって、テーブルサイズを小さく保つと、ローディングオーバーヘッドが最小化される。さらにテーブルへのエントリを戦略的に選択することにより、テーブルはタスクに対して効率的になる。
【００７５】
特定的な実施例においては、オプコードテーブルが関数コールまたはタスクコールごとのコンパイルの間に生成される。関数がアクティブになると、対応のオプコードテーブルがシステムメモリから（たとえば、不揮発性メモリ２４またはキャッシュメモリ２２から）オンチップメモリ１３２（たとえば、オンチップ命令キャッシュメモリまたはオンチップデータメモリ）にロードされる。そのような場合に、以前のバージョンのオプコードテーブルは退避されるかまたは上書きされる。退避される場合の実施例においては、アドレスも退避される。関数が完了すると、以前のオプコードテーブルのアドレスは検索されて、それにより以前のオプコードテーブルがプロセッサ２０によって用いられる現在のオプコードテーブルとなる。そのような技術を用いると、コード１６３／９４はテーブルアドレスを含む必要がなく、テーブルへのインデックスのみを含んでいればよい。他の実施例、たとえば多数のオプコードテーブルが同時にアクティブになることを許すものにおいては、コードは特定のテーブルをもポイントする。
【００７６】
いくつかの実施例においては、さまざまなオプコードテーブルがプロセッサチップ上にキャッシュされる。所与の時間に１つのテーブルが現在のオプコードテーブルとしてアクティブである。そのような現在のステータスはプログラムのさまざまな部分の実行、またはプログラムの変更の間に動的に変化する。
【００７７】
最も頻繁に発生する特定のオプコードは、実行される関数、タスクおよびアプリケーションプログラムに依存するが、殆どの画像処理アプリケーションに対して、オプコードテーブルにストアするためのオプコードの有効数は、１０−２０のオーダであることが経験的に見出された。これは、典型的なスーパースカラまたはＶＬＩＷプロセッサのオペランド命令セットの全体よりも実質的に少ない。特定的には、この発明者らによる１つの研究においては、殆どの画像処理関数によって用いられるオプコードの約９０％またはそれ以上を保持するのに１６エントリのルックアップテーブルが十分に大きいことが見出された。特に、発明者らはすべての命令圧縮および命令ルックアップテーブルを実現するのではなく、オプコード圧縮およびオプコードテーブルを生成すると、有効な性能に対するエントリの数は実質的により少ないことを見出した。
【００７８】
１６エントリテーブルに対しては、４ビットのみがテーブル１６６へのインデックスを規定すればよい。しかしながら別の実施例においては、テーブルサイズは変化することがあり、したがってコード１６３／９４を規定するビットの数も変動するであろう。エントリの各々（すなわち圧縮されないオプコード）が１２ビットを占有する１６エントリテーブルにおいては、合計１９２ビットが単一のオプコードテーブルに対して用いられる。したがって、テーブルサイズは小さく、オプコードテーブルローディングおよびタスク切替の間に殆どオーバーヘッドを伴わない。これは特に、テーブルが頻繁に更新されるマルチスレッド処理のために有利である。
【００７９】
オプコード圧縮動作
いくつかの実施例においては、オプコードテーブルは所与のプロセッサに対して専用である。しかしながら好ましい実施例に従うと、オプコードテーブルは所与のアプリケーションプログラムのためにソフトウェア内で規定される。図２２を参照して、コンパイラ１００はステップ１０２を実行してソースコードのリストをマシン言語にコンパイルし、コンピュータシステムにインストールする。そのようなコンパイルの間に、コンパイルはオプコードケーブル内にストアするための１組のオプコードを選択するステップ１０４を実行する。そのような選択および記憶は、プログラム全体またはプログラムの一部のいずれかに対して行なわれる。たとえば、オプコードの組は関数、タスクまたはプログラムの他のモジュラー編成単位ごとに選択される。実施例の変形においては、生成されるテーブルの数は編成の方法（たとえば、プログラム全体、関数、他の単位）によって変化し得る。好ましくは、すべてのオプコードテーブルは同じサイズである。
【００８０】
実施例の変形においては、どのオプコードをオプコードテーブルにストアするかを選択するために用いられる方策は変化し得る。好ましい実施例においては、最も頻繁に発生するオプコードが選択される。他の選択方策も実現し得る。
【００８１】
図２３を参照すると、ステップ１０８においてアプリケーションプログラムがコンピュータシステム１１１のシステムメモリ１９（図２５を参照）に実行のためにインストールされる。他の実施例においてはアプリケーションは計算システム上の組込コンピュータプログラムとしてストアされる。ステップ１１０においてアプリケーションプログラムが実行される。
【００８２】
図２４を参照すると、アプリケーションプログラム１１４のフローチャート１１２の動作は、１つ以上のオプコードテーブル２４０、２４２（図２５を参照）の使用に関するいくつかのステップを含む。ステップ１１６においては、アプリケーションプログラムが実行のためにロードされる。そのようなステップは典型的には、アプリケーションプログラムの全部または一部を、不揮発性メモリ２４からキャッシュメモリ２２などのランダムアクセスメモリにロードするステップを含む。プログラム命令のいくつかの部分は、プロセッサのオンチップメモリ１３２にロードされる。
【００８３】
プログラムの実行の間に、コンパイルの間に規定された１つ以上のオプコードテーブル２４０、２４２がオンチップメモリ１３２にロードされる。ある実施例においては、多数のオプコードテーブルが同時にオンチップメモリに存在する。他の実施例においては、所与の時間に１つのオプコードテーブルだけがオンチップメモリに存在する。いずれの場合においても、ポインタ２４６によって示される、所与の時間現在にアクティブであるオプコードテーブルが存在する。プロセッサが命令をパーズし、コード６５／９４がオプコード圧縮がその命令に対してアクティブであることを示すと、プロセッサはアクティブなオプコードテーブルを参照して圧縮命令形式１６２／１６４／１７２／９２において示されるオプコードを検索する。
【００８４】
たとえば、ステップ１１８において、関数Ａの実行のための準備が開始する。そのような準備に含まれるのは、ステップ１２０において関数Ａによって用いられるオプコードテーブルのアクティブ化である。そのようなアクティブ化は、現在のオプコードテーブルポインタ２４６における対応のオプコードテーブルのオンチップアドレスをストアするステップを含む。もしテーブルが既にオンチップにロードされていなければ、ステップはまたテーブルをオンチップメモリにロードするステップをも含む。ステップ１２２において、関数Ａがさらに実行される。オプコード圧縮が用いられていることを示すコード６５を有する如何なる命令も、プロセッサによってパーズされ、オプコードテーブルへのインデックスを識別する。ＶＬＩＷ命令に対しては、多数のインデックスが存在し得る。ＲＩＳＣまたはスーパースカラ命令に対しては、１つのオプコードのみが存在し得る。存在するインデックスの各々は、オプコードを検索するために用いられる。次いでオプコードが実行される。関連する命令内のソースオペランドおよびデスティネーションオペランドフィールドは、実行されるオプコードに対応するマイクロコードに基づいて処理される。
【００８５】
アプリケーションプログラムに対して１つ以上のオプコードテーブルが規定される実施例においては、別のオプコードテーブルが先行のオプコードテーブルに現在アクティブなオプコードテーブルとして置換わる状況がある。たとえば、ステップ１２４において、関数Ｂが実行のためにコールされる。関数Ｂの実行に備えて、関数Ｂの処理のために用いられるべきオプコードテーブルはステップ１２６において現在のオプコードテーブルとなるようアクティブ化される。そのようなアクティブ化は、対応のオプコードテーブルを現在のオプコードテーブルポインタ２４６のオンチップアドレスにストアすることを含む。もしテーブルが既にオンチップにロードされていなければ、ステップはまたテーブルをオンチップメモリにロードすることをも含む。ステップ１２８において、関数Ｂが実行される。関数Ｂの完了の際に、先行のオプコードテーブルが現在のオプコードテーブルとして復元される。そのような復元は、制御が戻されるプログラムの一部に対するオプコードテーブルのアクティブ化と同様である。したがって、関数Ａに対するオプコードテーブルは、アクティブなオプコードテーブルとして復元される。
【００８６】
一実施例においては、関数Ａに対するオプコードテーブルのアドレスが、関数Ｂがコールされたときにスタック２４８にプッシュされる。関数Ｂが完了すると、アドレスはスタック２４８から検索されて、関数Ａに対するオプコードテーブルアドレスを識別する。ステップ１３２において関数Ａの処理が再開する。
【００８７】
共通して用いられるオプコードのテーブルはリアルタイムの処理の間に動的に更新され、上書きされかつ置換えられる。たとえば、テーブルは、アプリケーションプログラムまたはタスクの実行の間にストアされ、アプリケーションプログラムまたはタスクごとに変更される。動的な更新の利点とは、より小さなテーブルサイズが効率的に命令帯域幅を減じることである。
【００８８】
いくつかの実施例においては、テーブルは動的である必要はなく、固定されていてもよい。たとえば、広い範囲のアプリケーションプログラムに対して最も頻繁に用いられるすべてのオプコードをストアするためには、そのようなテーブルは動的に更新されるテーブルよりも大きくなるであろう。好ましい動的実現化のためにテーブルはアプリケーションに対してカスタマイズされ、プログラム設計の一部となる。たとえば、オプコードテーブルにストアされるべきオプコードのそれぞれのテーブルを備えて、異なったタスクがプログラムされる。次いでそれぞれのテーブルはタスク切替の際にロードされる。より小さな動的なオプコードテーブルは、オプコードの効率的な選択の利点と、タスク切替の間のテーブルローディングに対する低いオーバーヘッドとをもたらす。さらに、多数のテーブルをストアするためにプロセッサチップ上にスペースが割当てられている場合、１つのテーブルがアクティブにされ別のものがインアクティブにされるので、テーブルローディングオーバーヘッドはさらに減じられる。
【００８９】
ある実施例においては、所与のオプコードテーブル内の１つ以上の特定のエントリが更新される。オプコードテーブル内のどこで更新された値を上書きするべきかを識別するためにテーブルインデックスを用いる特別な命令が含まれる。さらに、ある実施例においては、データをメモリからオプコードテーブルにより早く転送し、かつテーブルによりコンパクトにストアするためのＣＩＳＣ様の命令が含まれる。
【００９０】
ある実施例においては、、オプコードテーブルは関数コールの早期に不揮発性メモリからプレロードされる。さらに、先行のテーブルに対するポインタは維持され、それにより、関数が完了し処理がコーリングルーチンに戻った後で、オプコードテーブルはコーリングルーチンに対して復元される。
【００９１】
価値のある有利な効果
この発明の利点は、命令キャッシュにおいて必要となる命令スペースが、ＶＬＩＷ命令に対して効率的に減じられることである。特に、画像処理アルゴリズムの間に実行され、占有タイトループを有するいくつかの関数に対しては、スラッシングが発生するであろう場合にも、スラッシングなしにタイトループを維持することが可能である。
【００９２】
別の利点とは、ＶＬＩＷサブ命令においていくらかの冗長性をなくすことにより、より少ないビットのみが必要となり、よってプログラムサイズが減じられることである。さらに、命令キャッシュ利用の効率性が向上し、かつ命令フェッチ帯域幅が増大する。
【００９３】
この発明の好ましい実施例を例示し説明してきたが、さまざまな代替例、変形および等価物を用い得る。したがって、上述の説明は前掲の特許請求の範囲によって規定されるこの発明の範囲を限定するものと解してはならない。
【図面の簡単な説明】
【図１】 ＶＬＩＷ命令を有するコンピュータプログラムの開発および記憶のブロック図である。
【図２】 ＶＬＩＷプロセッサを有するコンピュータシステムの部分的なブロック図である。
【図３】 ＶＬＩＷプロセッサアーキテクチャのブロック図である。
【図４】 図３のプロセッサに対するさまざまなサブ命令フィールド内容のデスティネーションを識別する、ＶＬＩＷ命令形式の図である。
【図５】 例示的な圧縮されないＶＬＩＷ命令の図である。
【図６】 ＮＯＰサブ命令を除去するためのＶＬＩＷ命令の図である。
【図７】 サブ命令共用を実現するためのこの発明の実施例に従って圧縮されたＶＬＩＷ命令の図である。
【図８】 図７の命令に含まれる制御ビットの組の図である。
【図９】 さまざまなサブ命令共用条件を判断するための命令の制御ビットを復号化するための多重化アーキテクチャの図である。
【図１０】 （Ａ）から（Ｅ）は、命令の意図された分散、ＮＯＰ圧縮を備えた命令、およびサブ命令共用のための形式における命令を示す例示的な命令の図である。
【図１１】 命令圧縮制御ビットを設定するための方法のフローチャートである。
【図１２】 サブ命令共用のための命令を圧縮するための方法のフローチャートである。
【図１３】 さまざまなサブ命令共用条件を識別するための命令圧縮制御ビットを復号化するための方法のフローチャートである。
【図１４】 例示的なホスト処理システムのブロック図である。
【図１５】 この発明の実施例に従ってオプコード圧縮が実施される例示的なプロセッサのブロック図である。
【図１６】 従来の圧縮されないＶＬＩＷ命令形式の図である。
【図１７】 従来のＮＯＰ圧縮を有するＶＬＩＷ命令の図である。
【図１８】 （Ａ）および（Ｂ）は、この発明の実施例に従った、オプコード圧縮と、オプコード圧縮およびＮＯＰ圧縮の両方とを示すＶＬＩＷ命令の図である。
【図１９】 この発明の実施例に従ったオプコードテーブルの図である。
【図２０】 圧縮されない形式、ＮＯＰ圧縮された形式、サブ命令共用形式およびオプコード圧縮された形式を含む、進行形式（progressive format）におけるＶＬＩＷ命令の図である。
【図２１】 （Ａ）および（Ｂ）は、ＲＩＳＣまたはスーパースカラプロセッサアーキテクチャに対する圧縮されない形式およびオプコード圧縮された形式における命令の図である。
【図２２】 この発明の実施例に従った１つ以上のオプコードテーブルを規定するコンパイル動作のフローチャートである。
【図２３】 アプリケーションプログラムをインストールし実行するためのフローチャートである。
【図２４】 この発明の実施例に従った、オプコード圧縮実現化を例示する図２３のアプリケーションプログラムの関連部分の実行のフローチャートである。
【図２５】 この発明の実施例に従った、オプコードテーブルをロードするためのメモリ編成の図である。
【符号の説明】
２６ クラスタ、２７ クラスタのためのレジスタファイル、２８ 機能処理単位。
【発明の背景】
この発明は、プロセッサ命令を圧縮するための超長命令語（ＶＬＩＷ）計算アーキテクチャ、方法および装置に関し、より特定的にはＶＬＩＷ命令の記憶要件を減じるための方法および装置、ならびに命令のオプコード部分を圧縮するための方法および装置に関する。
【０００２】
処理効率を最適化するための従来の努力において、命令帯域幅よりもデータ帯域幅に多く対処がなされてきた。この偏重は、たとえば典型的にはデータキャッシュミス率よりも少ない命令キャッシュ率を示すベンチマークプログラムに基づくと、正しいように思われる。そのような結果は、オフチップ命令帯域幅要件はデータ帯域幅要件よりも小さいことを示す。しかしながら、画像処理のようないくつかの商業的作業負荷に対しては、典型的にはデータキャッシュミス率は命令キャッシュミス率よりも低い。したがって、命令帯域幅を最適化する必要性が増大している。
【０００３】
最近の２つの傾向が命令帯域幅を増大させ、したがって、大きなサイズの命令キャッシュに対する必要性を増大させている。第１の傾向は、超長命令語（ＶＬＩＷ）アーキテクチャが多くの高性能プロセッサアーキテクチャにおいて一般的になってきていることである。ＶＬＩＷアーキテクチャは、その広い命令ビットを活用してサイクルごとに多数の動作を実行する。これが直接反映して、スーパースカラアーキテクチャと比較して顕著に増大した命令帯域幅をもたらす。たとえば、２５６ビットのＶＬＩＷ命令幅（典型的な縮小命令セットコンピュータ（ＲＩＳＣ）命令よりも４倍から８倍広い）は珍しくはない。
【０００４】
画像処理などのマルチメディア計算アプリケーションは、多数のデータストリームを扱うための並列構造を用いてより効率的に実現される。テキサス州ダラスのテキサス・インスツルメント（Texas Instruments）によって製造されるＴＭＳ３２０Ｃ６ｘおよび、日本国東京の株式会社日立製作所とカリフォルニア州キャンベルのイクエータ・テクノロジー（Equator Technologies）とによって製造されるＭＡＰ１０００などのＶＬＩＷプロセッサは、データストリームと命令ストリームとの両方の大量の並列性をサポートし、プログラム命令の並列またはパイプライン化された実行を実現する。
【０００５】
ＶＬＩＷプロセッサは、クラスタと呼ばれる１つ以上の多数の均一な処理ブロックを有する。クラスタの各々は、共通の数の機能処理単位を含む。ＶＬＩＷ命令は多数のサブ命令フィールドを含む。ＶＬＩＷ命令のサイズは線形に増大し、並列命令の数はサブ命令フィールドにおいて並行に規定される。命令に現われるサブ命令は並列実行のために機能処理単位の間で分散される。
【０００６】
従来のＶＬＩＷプロセッサは、典型的には命令ごとに１０未満の動作を実行する。同時実行の数は将来のメディアプロセッサにおいて実質的に増大する見込みであり、命令は２５６または５１２ビット幅になる見込みである。しかしながら、命令のサイズが増大するにつれ、対応してデータフローおよびメモリ構造に対する負荷が増大する。十分な命令フェッチ帯域幅を提供するために、ＶＬＩＷ命令は典型的には最初に外部メモリからフェッチされ、実行される前にオンチップ命令キャッシュにストアされる。たとえばタイト処理ループの間の、キャッシュのスラッシング（すなわち、サイクルミス）は、非常に望ましくなく、性能の劣化につながる。したがって、命令キャッシュを効率的に管理して所望の高い処理スループットを維持することが強く望まれてきている。
【０００７】
同時に、プロセッサのクロック周波数が増大し、より広いＶＬＩＷアーキテクチャが適用され、かつより複雑なアルゴリズムが開発されるにつれ、より大きな命令キャッシュに対する必要性は増大する。したがって、ＶＬＩＷ命令を効率的に扱いかつキャッシュするための方法に対する必要性がある。
【０００８】
第２の傾向は、プロセッサクロック周波数を増大するにあたって深い実行パイプラインの使用がクリティカルになってきていることである。深い実行パイプラインはリードアフターライト依存においてコンフリクトの可能性を増大させる。コンフリクトはＮＯＰ命令の挿入か、または実行パイプラインをストールさせるハードウェア検出技術によって解決される。いずれの場合においても、貴重な実行サイクルが失われ、これはプロセッサの最大限の活用を阻む。ソフトウェアパイプライン化はこれらの深い実行パイプラインにおけるリードアフターライトコンフリクトをなくすことにおいて重要なツールとなった。ソフトウェアパイプライン化は、タイトループを何度かアンロールし、かつタイトループの多数の反復をオーバーラップさせて、付加的なＮＯＰまたはプロセッサストールサイクルなしにリードアフターライト依存を解決させるための余地を作ることを可能にする。これはタイトループサイズを増大させ、よって命令キャッシュミス率をも増大させるという弊害がある。したがって、命令帯域幅を減じるか、より効率的に扱う技術に対する必要性が存在する。
【０００９】
複合命令セットコンピュータ（ＣＩＳＣ）アーキテクチャおよび縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャにおいては、命令キャッシュの効率性により命令圧縮をほとんど必要としなかった。しかしながら、ビルコウスキ（Bealkowski）他による１９９７年７月３日発行の米国特許第５，６３６，３５２号の「圧縮命令を用いるための方法および装置」においては、命令圧縮技術が導入されている。命令はオプコード（すなわち命令オペランド）および１つ以上のデータオペランド（たとえばソースオペランドフィールドおよびデスティネーションオペランドフィールド）からなる。１つ以上の制御ビットもまた命令内に含まれる。ビルコウスキ他は、頻繁に用いられる命令に対するエントリを含む、シノニムテーブルと呼ばれるテーブルを実現する。命令のシーケンスは以前に定義されていない特別オプコードおよびそれぞれのシノニムテーブルへのインデックスを有する単一の命令に圧縮される（たとえば、命令内で許可されるビットの数に基づく限度まで、シーケンスの命令ごとに１つが圧縮される）。
【００１０】
ビルコウスキ他の圧縮技術の制限とは、典型的なプログラムにおける唯一の（unique）命令の数が非常に大きいことである。したがって、ビルコウスキ他は１２ビットの最大インデックス幅と、エントリの各々が３２ビットの命令を保持する４０９６エントリのシノニムテーブルとを提案する。そのようなテーブルは１６キロバイトのオンチップメモリを必要とする。そのようなテーブルのサイズは高性能プロセッサなどにおいて用いられるレベル１命令キャッシュに匹敵するので、これは費用のかかる解決策である。ビルコウスキ他は、シノニムテーブルが読出専用メモリ内にストアされ、かつマイクロプロセッサ設計の時点で予め規定される１つの実施例を提案する。別の実施例においてはビルコウスキ他は、シノニムテーブルがプロセッサ初期化の間にロード可能であることを提案する。しかしながら企図される場合、テーブルは静的で変化しない構成である。したがって、命令帯域幅を減じるためのより効率的な解決策に対する必要性がある。
【００１１】
【発明の要約】
この発明に従うと、ＶＬＩＷ命令のサブ命令は機能処理単位の間で共用されて、命令キャッシュに、ある実施例においてはメインメモリにストアされるＶＬＩＷ命令のサイズを減じる。特定的には、ＶＬＩＷ命令はサブ命令共用の場合に圧縮される。ある実施例においては命令はコンパイル時に圧縮され、圧縮された形式でメインメモリにストアされる。他の実施例においては命令は圧縮されない形式でメインメモリにストアされ、キャッシュメモリにストアされる前に圧縮される。
【００１２】
この発明の一局面によると、命令圧縮制御ビットの組がＶＬＩＷ命令の各々に関連付けられる。一実施例においてはＶＬＩＷ命令は命令内の制御ビット組を含むよう形式化される。ＶＬＩＷ命令は、複数のサブ命令フィールド、命令圧縮制御ビット組、およびＮＯＰ命令の位置を示す（すなわち、空である）ものなどのような他の雑制御ビットを含む。
【００１３】
完全に拡張された形式においては、ＶＬＩＷ命令は予め規定された数のサブ命令フィールドを含み、フィールドの数はＶＬＩＷ命令を実行するプロセッサのアーキテクチャによって決定される。サブ命令フィールドのいくつかはＮＯＰ命令であり得る。さらにサブ命令フィールドのいくつかは他のサブ命令フィールドにあるものと同じサブ命令を含み得る。ＮＯＰ命令のために割当てられるスペースを除去するために命令を圧縮することが公知である。この発明に従うと、選択された場合のサブ命令の冗長性を減じるための方策が提供される。
【００１４】
１つの命令が４つのサブ命令フィールドを含むアーキテクチャを考察する。そのような命令に対して関連する１５の状況が存在する。１つの状況においては、冗長なサブ命令は存在しない（たとえば、ＡＢＣＤ）。残りの状況においては、サブ命令の間にある程度の冗長性が存在する（たとえば、ＡＡＡＡ、ＡＡＡＢ、ＡＡＢＡ、ＡＢＡＡ、ＢＡＡＡ、ＡＡＢＢ、ＡＢＡＢ、ＡＢＢＡ、ＡＡＢＣ、ＡＢＡＣ、ＡＢＣＡ、ＢＡＡＣ、ＢＡＣＡ、ＢＣＡＡ）。Ａ、Ｂ、ＣおよびＤはサブ命令が別のフィールド内のサブ命令と同一であるか異なっているかを識別するために用いられていることに留意されたい。当業者においては、多数の異なったサブ命令Ａが存在することが認識されるであろう。同様に、多くの異なったサブ命令Ｂ、ＣおよびＤが存在する。
【００１５】
より多くのサブ命令フィールドが存在するアーキテクチャに対しては、さらなる冗長なサブ命令の状況が存在する。いかなる所与のアーキテクチャに対しても、２zより多い起こり得る状況は存在せず、ここで「ｚ」はサブ命令フィールドの数である。すべての冗長状況をカバーするために、「ｚ」までの制御ビットが存在するであろうが、ここでｚはプロセッサアーキテクチャにおいて許容されるサブ命令フィールドの最大数である。
【００１６】
ある実施例においては、すべてのそのような状況は命令の各々に「ｚ」の制御ビットを含むことによりカバーされる。しかしながら、命令幅が増大するにつれ、サブ命令共用のためにそのように多数の付加的な制御ビットを加えることは望ましくないおそれがある。特定的には、実務上何度も出現し繰返すサブ命令冗長性の間にあるパターンが見られる傾向がある場合には、そのような多くのビットのコストは過剰に思われる。結果として、好ましい実施例においては制御ビットの数を「ｚ」未満に減じて、約２zの予め規定された数のサブ命令共用状況を扱うことを可能にする。
【００１７】
サブ命令冗長性のパターンが変化する異なったアプリケーションに対して異なったプロセッサを設計し得る。さらに、どの場合にサブ命令共用のためにサブ命令冗長性をカバーするかは、プロセッサが対象とするアプリケーション（たとえば、画像処理アプリケーション）に対して最も大きな影響を与えるよう、所与のプロセッサに対して戦略的に選択される。
【００１８】
いかなるサブ命令冗長性状況も潜在的にカバーされてプロセッサアーキテクチャ内に設計されるが、１つの方策においてはすべてまたはそれ以下のサブ命令共用可能性がカバーされる。一実施例においてはサブ命令共用は対応の機能処理単位に対して向けられる冗長なサブ命令に対して提供される。機能処理単位はプロセッサの一部である。プロセッサは「ｚ」の機能処理単位を含むが、ここで「ｚ」は１つの命令内のサブ命令の最大数である。しかしながら、より特定的には、プロセッサは複数のクラスタを含み、クラスタの各々は共通の数の機能処理単位（ＦＰＵ）を含む。１つのクラスタ内のＦＰＵの各々に対して、互いのクラスタ内に対応のＦＰＵが存在する。対応のＦＰＵの各々は同じ機能を有する。たとえば、４つのＦＰＵの３つのクラスタがあると、４組の対応するＦＰＵが存在する。１つの方策においては、いずれか２つ以上の対応のＦＰＵの間のサブ命令冗長性の並べ替えの各々がカバーされる。そのような例においてはｚ＝７であり、命令ごとに７つの命令圧縮制御ビットが存在する。これは１２の機能処理単位間の、すべての可能性のあるサブ命令共用状況をカバーするための制御ビットの最大数（たとえば、１２）よりも少ない。
【００１９】
この発明の別の局面に従うと、クラスタの各々における対応の機能処理単位に向けられる冗長なサブ命令が圧縮される。特定的には、少なくとも２つのクラスタにおける対応の機能処理単位に対する１つの命令内に同じサブ命令が存在すると、この発明にしたがって、サブ命令の１つのコピーのみがストアされればよい。対応の機能処理単位に対する冗長なサブ命令は省かれ、圧縮された命令をもたらす。そのような圧縮に対しては、特定のサブ命令を共用する冗長なサブ命令フィールドを識別する命令圧縮制御ビットの対応する条件が存在する。
【００２０】
この発明の別の局面によると、ＶＬＩＷプロセッサに対するコンピュータプログラムのコンパイルの間に（たとえば、より高レベルの言語ソースコードまたはアセンブラソースコードのアセンブリ）、命令圧縮制御ビットは所与の命令に対して圧縮の各々を規定する条件を特定するよう設定される。命令圧縮制御ビットを含む命令は、圧縮されたまたは圧縮されない形式でメモリ内にストアされる。圧縮されない形式でストアされる場合、命令はプロセッサのオンチップ命令キャッシュにストアされる前に圧縮される。したがって、命令は命令のメインメモリへの記憶と命令のオンチップ命令キャッシュへの記憶との間のいずれかのステップで圧縮される（たとえば、これは圧縮されてメインメモリで復元される；これは圧縮されて一次のキャッシュまたは二次のキャッシュにストアされる；これはオンチップ命令キャッシュに移動するときに圧縮される）。
【００２１】
この発明の別の局面によると、命令圧縮制御ビットの条件は、どのように圧縮命令が実行のために圧縮解除されるべきかを規定する。特に制御ビットは、圧縮命令内の１つ以上のサブ命令が、ＶＬＩＷプロセッサの機能処理単位の間で同時実行のためにどのように共用されるべきかを判断する。命令圧縮制御ビットの組は、冗長的にではなくすぐに冗長な対応のサブ命令がストアされる１つ以上の圧縮条件を識別する。識別される条件の各々は、少なくとも２つの対応の機能処理単位によって共用されるべきサブ命令に対応する。
【００２２】
異なったクラスタの機能処理単位を、対応する機能処理単位であると関連付け、かつそのような対応の機能処理単位に向けられる冗長なサブ命令を圧縮することの利点は、画像計算アルゴリズムの通常のプログラム構造によるものである。出願人らは、同じサブ命令が多数のクラスタにおいて用いられる画像計算ライブラリ関数のためのプログラムコードにおいて多くのタイトループを認識した。たとえば２つのクラスタを有するＶＬＩＷプロセッサで実現される２Ｄ畳み込み関数に対しては、最も頻繁に用いられるサブ命令は、内積および、内積の解の区分短縮（partitioned compaction）である。これらのサブ命令のいずれかを実行するほとんどの命令に対して、多くのクラスタが同じサブ命令を割当てられていることが認識された。特定的にはそのような関数のためのＭＡＰ１０００プロセッサに対するアセンブリコードにおいては、出願人らはタイトループプログラムが１３３の命令のうち、両方のクラスタに対して全く同じサブ命令（オペランドを含む）からなる６７の命令を有することを認識した。したがって、対応の機能処理単位に向けられるサブ命令の冗長性は重要な画像処理アルゴリズムにおいて顕著に発生する。ＶＬＩＷ命令における冗長性をなくして、多数のクラスタにおいて同じサブ命令が実行されるべきである場合に必要となる命令ビットを少なくすることにより、プログラムサイズが減じられる。さらに、命令キャッシュ利用の効率性が向上し、効率的な命令フェッチ帯域幅が増大する。
【００２３】
オプコード圧縮実施例においては、命令帯域幅は、命令の全体を圧縮する命令圧縮技術とは異なる技術で減じられる。共通して用いられるオプコードの１つ以上のテーブルをストアするために、オンチップランダムアクセスメモリのある領域が割当てられる。命令内の通常のオプコードは、テーブルとテーブルへのインデックスとを識別するコードに置き換えられる。コードは圧縮されないオプコードよりも少ないビットを含む。その結果、命令が圧縮される。
【００２４】
この技術はさまざまなプロセッサアーキテクチャに対して実現されるが、この技術は多数のオプコード（すなわち、サブ命令の各々に対するもの）を含むＶＬＩＷ命令に対して特に有利である。一実施例においては、命令の特別なコードビットの間の１つのビットが、ＶＬＩＷ命令が圧縮されているかまたは圧縮されていないかを明示するために割当てられる。たとえば、ある実施例においてはＶＬＩＷ命令に対するオプコード圧縮は全か無かである。すなわち、すべてのサブ命令オプコードが圧縮されるかいずれもされないかである。ＮＯＰ命令オプコードを圧縮するための十分な方法が存在するので、代替的な従来の方法を用いてこの発明の実施例の圧縮命令形式の中のＮＯＰサブ命令を識別してもよい。
【００２５】
この発明の１つの局面によると、共通して用いられるオプコードのテーブルはリアルタイム処理の間に動的に更新され、上書きされ、かつ置き換えられる。テーブルはアプリケーションプログラムの実行の間にストアすることができる。動的更新の利点は、より小さなテーブルサイズが効率的に命令帯域幅を減じることである。ある実施例においては、テーブルは動的である必要はなく、固定されていてもよい。広い範囲のアプリケーションプログラムに対して最も頻繁に用いられるすべてのオプコードをストアするために、そのようなテーブルは動的に更新されるテーブルよりも大きくなる。好ましい動的な実施例に対しては、テーブルはアプリケーションにカスタマイズされ、プログラム設計の一部となる。たとえば、オプコードテーブルにストアされるべきオプコードのそれぞれのテーブルを備えて異なったタスクがプログラムされる。それぞれのテーブルは次いでタスクが切替わるときにロードされる。より小さな動的オプコードテーブルは、オプコードのより効率的な選択、およびタスク切替えの間のテーブルローディングに対する低いオーバーヘッドの利点をもたらす。さらに、多数のテーブルをストアするためにプロセッサチップにスペースが割当てられる場合、１つのテーブルがアクティブにされ別のものはインアクティブにされるために、テーブルローディングオーバーヘッドはさらに減じられる。
【００２６】
ある実施例においては、所与のオプコードテーブルにおける１つ以上の特定のエントリが更新される。テーブルインデックスを用いてオプコードテーブル内のどこで更新された値を書込むべきかを識別する特定の命令が含まれる。さらにある実施例にＣＩＳＣ様の命令が含まれ、データをメモリからより早くオプコードテーブルに転送し、テーブルをよりコンパクトにストアする。
【００２７】
ある実施例においては、オプコードテーブルは不揮発性メモリから関数コール内の初期にプレローディングされる。さらに、以前のテーブルに対するポイントが維持されて、それにより関数が完了し処理がコーリングルーチンに戻った後で、コーリングルーチンに対するオプコードテーブルが復元される。
【００２８】
この発明のこれらおよび他の局面ならびに利点は、添付の図面と併せて以下の詳細な説明を参照することにより、よりよく理解されるであろう。
【００２９】
【特定の実施例の説明】
概要
図１は、超長命令語（ＶＬＩＷ）プロセッサのためのプログラムコンパイルおよび記憶のブロック図を示す。「超長命令語」ＶＬＩＷという用語は、コンピュータシステムおよびプログラムアーキテクチャ、並列処理および画像処理の分野における用語であり、これは一般的にプロセッサが典型的には、６４ビット以上であり多数のサブ命令からなる命令を扱うことができるアーキテクチャを指す。
【００３０】
プログラムエンジニアはソースコード１２を準備し、テストし、かつデバッグする。ソースコード１２はアセンブラ言語または高階プログラミング言語で書かれる。ソースコードは次いでコンパイラ／アセンブラ１４によってコンパイル／アセンブルされ、マシンコード１６をもたらす。マシンコード１６は、マシンコード１６を実行すべきプロセッサを有するコンピュータのメモリ１８にストアされる。
【００３１】
図２を参照すると、ホストコンピュータ１０は、超長命令語（ＶＬＩＷ）プロセッサ２０、命令キャッシュ２２、およびメインメモリ２４を含む。好ましい実施例においては命令キャッシュ２２はプロセッサ２０の一部である（オンチップに位置する）。メインメモリは、メモリ１８であるか、またはメモリ１８からコンピュータプログラムマシンコード１６を受取る。図３を参照すると、典型的なＶＬＩＷプロセッサ２０アーキテクチャは、機能処理単位（ＦＰＵ）２８の複数のクラスタ２６を含む。クラスタ２６の各々は、共通の数の機能処理単位２８を含む。その結果、異なったクラスタ２６の機能処理単位２８に１対１対応が存在する。図３は、クラスタごとに「ｍ」個の機能処理単位の「ｎ」個のクラスタを有する汎用アーキテクチャを示す。第１のクラスタは、（１，１）から（１，ｍ）までの機能処理単位を有する。第２のクラスタは、（２，１）から（２，ｍ）までの機能処理単位を有する。ｎ番目のクラスタは、（ｎ，１）から（ｎ，ｍ）までの機能処理単位を有する。したがって、ｎ＊ｍ個の機能処理単位が存在する。クラスタ２６ごとに、専用レジスタファイル２７が存在する。ｎ、ｍ、およびｎ＊ｍの値は、プロセッサ２０アーキテクチャによって決定された予め規定された数である。そのような値は異なった実施例に対して変化し得る。ｎ＊ｍの値は、ｎ＊ｍ機能処理単位を有するプロセッサに対するＶＬＩＷ命令内に含まれ得るサブ命令の最大数に相当する予め規定された数である。
【００３２】
図４を参照すると、プロセッサ２０に対する命令形式３０は最大ｎ＊ｍ個のサブ命令フィールド３２を含む。サブ命令フィールド３２の各々の内容は処理のために対応の機能処理単位２８に経路制御される。すべてのｎ＊ｍ個のサブ命令フィールドが埋められた命令に対しては、サブ命令はｎ＊ｍ個の機能処理単位２８の各々に経路制御される。典型的には、すべてのｎ個のクラスタ２６に対して１つのみのプログラムカウンタが存在する。その結果、機能処理単位は典型的にはシンクロナスに動作して所与の命令のサブ命令を同時実行する。
【００３３】
サブ命令フィールド３２ｉが空である場合、命令３０は従来の技術を用いて圧縮される。その結果、命令によって占有されていたメモリスペースが減じられる。この発明は、多数のクラスタ２６の対応の機能処理単位２８に対して冗長なサブ命令が存在する場合命令サイズを圧縮するさらなる技術に関する。特に、画像計算アルゴリズムのタイトループにおいては、同じサブ命令が多数のクラスタにおいて実行されるのが認識されている。従来的には、サブ命令はサブ命令フィールド３２の各々で繰返され、命令キャッシュ２０のメモリスペースの非効率的な使用およびメモリ転送帯域幅の非効率的な適用をもたらした。この発明の局面による圧縮された命令形式においては、サブ命令が多数の機能処理単位２８の間で共用される。
【００３４】
ＶＬＩＷ圧縮命令形式
図５を参照すると、それぞれのサブ命令３６をストアする「ｎ×ｍ」個のサブ命令フィールド３２を含む、圧縮されない命令３４の例が示される。あるサブ命令フィールド３２は空白であり得る（たとえば、フィールド３２（２，１））。あるサブ命令フィールドは別のサブ命令フィールドど同じサブ命令を含み得る。サブ命令フィールド３２の各々は、特定のクラスタ２６の特定の機能処理単位２８に関連付けられる。示される例においては、サブ命令フィールド（１，１）から（１，ｍ）までは、クラスタ１のそれぞれの機能処理単位（１，１）から（１，ｍ）までにに関連付けられる。サブ命令フィールド（２，１）から（２，ｍ）まではクラスタ２のそれぞれの機能処理単位（２，１）から（２，ｍ）までに関連付けられる。サブ命令フィールドの各々は同様に、サブ命令フィールド（ｎ，１）から（ｎ，ｍ）までがクラスタｎのそれぞれの機能処理単位（ｎ，１）から（ｎ，ｍ）までに関連付けられる。
【００３５】
クラスタ１からｎの各々に対する機能処理単位（＿，１）はここで対応の機能処理単位と呼ばれることに留意されたい。特に、それらは多数のクラスタの各々の、対応の第１の機能処理単位と呼ばれる。対応の機能処理単位（＿，ｉ）によって処理するための所与の命令内に同じサブ命令が含まれている場合、命令形式は圧縮されて冗長性をなくす。同じサブ命令が含まれているが、対応しない機能処理単位（＿，ｉ）および（＿，ｊ）へのものである場合、冗長性は対処されないことに留意されたい（すなわち、命令形式は必ずしも圧縮されなくてもよい）。ある実施例においてはこれらの冗長性もまた対処されるが、好ましい実施例においてはこれらは無視される。そのような冗長性が無視されるのは、これらが対応の機能処理単位に向けられるサブ命令の間の冗長性の対処における利得に匹敵するほどの、効率性における利得をもたらさないためである。
【００３６】
図６を参照すると、空白フィールドが省かれた従来の圧縮された形式３４′で例示的な命令３４が示される。圧縮されない形式において空白フィールドが生じるであろう位置はアスタリスク（「＊」）で示す。
【００３７】
図７を参照すると、この発明の局面に従った圧縮された形式３４″における例示的な命令３４が示される。圧縮された形式において、命令圧縮制御ビットの組３７のための領域と、１つ以上の、好ましくは空ではないサブ命令フィールドとが存在する。同じサブ命令をストアする対応のＦＰＵ（＿，ｉ）に対するサブ命令フィールドは、対応の機能処理単位のうちの１つのみに対するサブ命令を含むよう減じられる。そのような対応の機能処理単位はサブ命令を共用する。
【００３８】
示される例示的な命令に関しては、第１のクラスタおよびｎ番目のクラスタの両方の第２の機能処理単位に向けられるサブ命令は、共通のサブ命令を有することに留意されたい。これらのＦＰＵ（１，２）および（ｎ，２）は対応の機能処理単位である。したがって、冗長なサブ命令は省かれる。さまざまな実施例において冗長なサブ命令は第１の発生、第２の発生または他の発生において省かれる。示される実施例においては第１の発生以外のすべてが省かれる。圧縮されない形式において、省かれた冗長フィールドが発生するであろう位置はダブルアスタリスク（「＊＊」）で示す。また、空のサブ命令フィールドもまた圧縮されていることに留意されたい。さまざまな実施例において、従来の圧縮技術もまた実現されるか否かに応じて空のフィールドは圧縮されても圧縮されなくてもよい。
【００３９】
また、サブ命令フィールド３２（１，ｍ）および３２（２，２）の各々は共通のサブ命令「Ｃ」を有することに留意されたい。ある実施例においては圧縮動作が行なわれてこの冗長を避ける。しかしながら、このような冗長は頻繁には発生しないことが見出されたので、好ましい実施例においてはこの冗長は「そのまま」残される。同様に、サブ命令フィールド３２（ｎ，１）および３２（ｎ，３）もまた共通のサブ命令「Ｅ」を有する。これらは共通のクラスタ内でＦＰＵに対して向けられる。ある実施例においては、圧縮動作が行なわれてこの冗長性を避ける。しかしながら、このような冗長は頻繁には発生しないことが見出されたので、好ましい実施例においてはこの冗長は「そのまま」残される。
【００４０】
命令圧縮制御ビットの組３７は、対応の機能処理単位がサブ命令を共用するべき起こり得る条件の各々を識別するために十分なビットを含む。たとえば、クラスタごとに「ｍ」個のＦＰＵの２つのクラスタがある場合、組３７は「ｍ」個の制御ビットを含む。クラスタごとに２つのＦＰＵの「ｎ」個のクラスタがある場合、組３７は「ｎ」個の制御ビットを含む。クラスタごとに「ｍ」個のＦＰＵの「ｎ」個のクラスタを有するアーキテクチャにおいては、ベストモードの実施例における組３７はｎ＋ｍ個のの制御ビットを含むが、ここでｎ＞２であり、ｍ＞２である。他の実施例においては制御ビットの数は変化し得る。以下のテーブル１は、クラスタごとに２つの機能処理単位の２つのクラスタが存在するアーキテクチャに対するビット符号化を示す。そのようなアーキテクチャに関しては、組３７内に２つの制御ビットが存在する。
【００４１】
テーブル１：制御ビット符号化
００ サブ命令共用なし
０１ 圧縮された形式における第１のサブ命令がＦＰＵ（＿，１）によって共用される
１０ 圧縮された形式における第２のサブ命令がＦＰＵ（＿，２）によって共用される
１１ 圧縮された形式における第１のサブ命令がＦＰＵ（＿，１）によって共用され、かつ圧縮された形式における第２のサブ命令がＦＰＵ（＿，２）によって共用される
【００４２】
以下のテーブル２は、クラスタごとに３つの機能処理単位の２つのクラスタが存在するアーキテクチャのためのビット符号化を示す。そのようなアーキテクチャに対しては、組３７内に３つの制御ビットが存在する。
【００４３】
テーブル２：制御ビット符号化
０００ サブ命令共用なし
００１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用される
０１０ 圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用される
０１１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用される
１００ 圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１０１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１１０ 圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
１１１ 圧縮された形式における第１のサブ命令はＦＰＵ（＿，１）によって共用され、圧縮された形式における第２のサブ命令はＦＰＵ（＿，２）によって共用され、圧縮された形式における第３のサブ命令はＦＰＵ（＿，３）によって共用される
【００４４】
さまざまな実施例において、２つ以上の対応のＦＰＵ（＿，ｉ）の間で共用されるべきサブ命令が存在する潜在的な圧縮条件の各々を識別するために実現し得るさまざまな符号化方策が存在する。
【００４５】
命令ごとに大量の制御ビットを加えることは望ましくないおそれがあるので、圧縮条件のサブセットは減じられた数の制御ビットによって識別され得る。たとえば、クラスタごとに２つのＦＰＵを備えた４つのクラスタアーキテクチャにおいては、４つの制御ビットを上に明記されるものと同じ方法で用いるか、または３つの制御ビットを以下のテーブル３に説明されるように用いることができる。
【００４６】
テーブル３：制御ビット符号化
０００ サブ命令共用なし
００１ 圧縮された形式における第１のサブ命令がすべてのＦＰＵ（ｉ，１）によって共用される、ｉ＝１，４
０１０ 圧縮された形式における第２のサブ命令がＦＰＵ（ｉ，２）によって共用される、ｉ＝１，４
０１１ 圧縮された形式における第１のサブ命令がＦＰＵ（ｉ，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（ｉ，２）によって共用される、ｉ＝１，４
１００ 圧縮された形式における第１のサブ命令がＦＰＵ（１，１）、（３，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（３，２）によって共用され、圧縮された形式における第３のサブ命令がＦＰＵ（２，１）、（４，１）によって共用され、圧縮された形式における第４のサブ命令がＦＰＵ（２，２）、（４，２）によって共用される
１０１ 圧縮された形式における第１のサブ命令はＦＰＵ（１，１）、（２，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（２，２）によって共用され、圧縮された形式における第３のサブ命令がＦＰＵ（３，１）、（４，１）によって共用され、圧縮された形式における第４のサブ命令がＦＰＵ（３，２）、（４，２）によって共用される
１１０ 圧縮された形式における第１のサブ命令がＦＰＵ（１，１）、（２，１）によって共用され、圧縮された形式における第２のサブ命令がＦＰＵ（１，２）、（２，２）によって共用され、第３から第６までのものは共用されない
１１１ 第１から第４のものは共用されず、圧縮された形式における第５のサブ命令がＦＰＵ（３，１）、（４，１）によって共用され、圧縮された形式における第６のサブ命令はＦＰＵ（３，２）、（４，２）によって共用される
【００４７】
当業者においては、異なった符号化方策を実現して、さまざまなサブ命令共用条件を識別し得ることを理解するであろう。異なった復号化アーキテクチャが異なった符号化方策に付随し、所望のサブ命令共用方策を実現するであろう。
【００４８】
サブ命令共用
図９を参照すると、制御ビットの組を復号化し、かつもしサブ命令が存在すればそれらのうちいずれがＶＬＩＷプロセッサの対応のＦＰＵの間で共用されるべきかを判断するための例示的な多重化方策が示される。一実施例においては、プロセッサ２０はそのような符号化およびサブ命令共用を行なうための論理を含む。示される実施例においては、クラスタごとに２つの機能単位２８の２つのクラスタ２６が存在する。ＶＬＩＷ命令４２は、命令キャッシュ２２から検索され、制御ビットの組３７の条件に基づいてパーズされる。そのような実施例に対するＶＬＩＷ４２命令は、２つ、３つまたは４つのサブ命令フィールド３２を含む。
【００４９】
マルチプレクサ４４は、第２のクラスタの第１の機能単位を命令４２の第１のサブ命令フィールドおよび第３のサブ命令フィールドに結合する。マルチプレクサ４６は、第２のクラスタの第２の機能単位を命令４２の第２のサブ命令フィールドおよび第４のサブ命令フィールドに結合する。上述のテーブル１における復号化方策に従うと、命令４２は組３７が００の符号化条件を有している場合に４つのサブ命令を含む。サブ命令の各々は別々のＦＰＵに経路制御される。命令４２は、組３７が０１または１０の符号化条件を有する場合に３つのサブ命令を含む。０１に符号化された場合、マルチプレクサ４４は第１のサブ命令を選択する。こうして、クラスタ１および２の第１の機能単位は第１のサブ命令を共用する。第２のサブ命令は第１のクラスタの第２のＦＰＵに向かう。第３のサブ命令はシフトされてマルチプレクサ４６に入り、これはそのような第３のサブ命令を第２のクラスタの第２のＦＰＵによって処理するために選択する。
【００５０】
組４６が１０に符号化される場合、第１のサブ命令は第１のクラスタの第１のＦＰＵに向かい、第２のサブ命令は第１のクラスタの第２のＦＰＵに向かう。マルチプレクサ４４は第３のサブ命令を選択し、それにより第３のサブ命令は第２のクラスタ内の第１のＦＰＵに向かう。マルチプレクサ４６は第２のサブ命令を選択し、それにより第２のサブ命令は第１のクラスタの第２のＦＰＵと第２のクラスタの第２のＦＰＵとによって共用される。
【００５１】
命令４２は、組３７が１１の符号化条件を有する場合に２つのサブ命令を含む。そのような場合においてはマルチプレクサは第１のサブ命令をパスし、それにより第１のサブ命令は第１のクラスタの第１のＦＰＵと第２のクラスタの第１のＦＰＵとによって共用される。同様に、マルチプレクサ４６は第２のサブ命令をパスし、それにより第２のサブ命令は第１のクラスタの第２のＦＰＵと第２のクラスタの第２のＦＰＵとによって共用される。
【００５２】
図１０（Ａ）から（Ｅ）を参照すると、サブ命令共用は、クラスタごとにｎ＝２クラスタおよびｍ＝２ＦＰＵを有するプロセッサ上でさまざまな命令４２Ａから４２Ｅに対して比較される。命令の各々は４つまでのサブ命令３６を含む。４つのサブ命令はサブ命令が視覚的にそのデスティネーションＦＰＵと相関するように、２つの行に構成される。特定的には、一番上の行のサブ命令は第１のクラスタの第１および第２のＦＰＵ（１，１）、（１，２）のそれぞれに向けられるのに対し、一番下の行のサブ命令は第２のクラスタの第１および第２のＦＰＵ（２，１）、（２，２）のそれぞれに向けられる。さらに、命令ビットサイズはサブ命令サイズに対して等しい３２ビットであると示される。命令４２ごとに示されるのは、意図された動作４８（左側）、ＮＯＰ圧縮のみを備えた命令５０（中央）およびサブ命令共用のために圧縮された命令４２（右側）である。
【００５３】
以下のテーブル４は、サブ命令共用を備えるかまたはサブ命令共用を備えない、異なった命令の場合を指定するために用いられるいくつかの命令ビットを要約する。Ｎは命令内での空ではないサブ命令の数であり、もとの圧縮された命令は命令圧縮の後で３２×Ｎビット長さになるであろう。しかしながら、サブ命令共用があると、命令内に冗長度に応じて異なった長さが生じ得る。たとえば、制御ビット３７が００（すなわち、サブ命令共用なし）であれば、その命令に対しては３２×Ｎ＋２ビットであり、もとの命令と比較すると２ビットのオーバーヘッドを含む。しかしながら、制御ビット３７が０１または１０であれば、サブ命令共用によって１つのサブ命令フィールドが省かれる。結果は３２×（Ｎ−１）＋２ビットであり、これはこの命令に対して３０ビットを節約する。この場合に関しては、制御ビットは１１であり、２つのサブ命令フィールドが省かれ、ビットの数は３２×（Ｎ−２）＋２であり、この命令に対して６２ビットを節約する。
【００５４】
【表１】
いくつかのタイトループルーチン（２Ｄ畳み込み、２Ｄ復号ＦＦＴおよびアフィンワーピング（affine warping））がＭＡＰ１０００プロセッサのためにアセンブリ言語で書かれた、画像計算プログラムにおけるサブ命令共用の実際の効果が研究された。ＭＡＰ１０００はクラスタごとに２つのＦＰＵの２つのクラスタを有する。サブ命令の各々が３２ビット幅であると想定して、タイトループ内の命令の数およびそれらの冗長特性は以下のテーブル５にリストされる。２Ｄ畳み込みに関しては、サブ命令共用によって節約することのできる命令ビットの数は−２×４８＋３０×４０＋６２×４５＝３８９４ビットであると計算された。１３３の命令内で、畳み込みタイトループにおける空ではないサブ命令の総数は３３７であった。よって、もとのプログラムサイズは３３７×３２＝１０７８４ビットである。こうして、サブ命令共用結果はテーブル６に示すようにタイトループプログラムサイズにおいて３６．１％の減少をもたらした。同様に、２Ｄ復号ＦＦＴおよびアフィンワーピングタイトループは、それぞれプログラムサイズにおいて２３．９％および４１．９％の減少を示した。
【００５６】
【表２】
上述のプログラムサイズ減少はタイトループに対してのみであることに留意されたい。コール機能を併せて考察する場合、サブ命令共用の結果はより長いものになるであろう。しかしながら、結果はそれでも非常に顕著である。たとえば、５１２×５１２の８ビット画像を読込み、２Ｄ畳み込みタイトループをコールし、メモリに出力画像を書込むアプリケーションプログラムを考察すると、約１００キロバイトを占有する。サブ命令共用によって達成されるプログラムサイズ減少の合計は０．５％未満である。しかしながら、タイトループ外のプログラムのほとんどが一度のみ実行されるのに対し、タイトループは何度も反復されるので、ほとんどのプログラム実行時間は実際、タイトループ内で使用される。マップ１０００での１５×１５核を備える２Ｄ畳み込みの場合においては、タイトループ実行時間は実行時間の合計の８９％以上を占める。したがって、タイトループを利用可能な命令キャッシュに適合させることは、全体のプログラムサイズを減少させることよりも重要である。さらに、より洗練されたタイトループ（こうして命令のためにより多くのビットを必要とする）が開発され、および／または多数のタイトループが組合されて新しい高レベルタイトループを生成する場合、個々のタイトループのサイズができるだけ小さくされ、それにより新しいタイトループが命令キャッシュスラッシングを引起さない、すなわちタイトループを反復する間に過剰な命令キャッシュミスを起こさないことが望ましい。
【００５８】
冗長なサブ命令を識別し共用するための方法
図１１を参照すると、サブ命令共用機会を識別するためのフローチャート６０は、所与の命令のサブ命令が、サブ命令共用条件が存在するか否かを判断するために比較されるステップ６２を含む。一実施例においては、多数のクラスタの１つ以上の対応の機能処理単位（＿，ｉ）に対して現われるいずれのサブ命令も共用されるべきである。別の実施例においてはより限定された条件の組が特定の設計に従って指定される。たとえば上述のテーブル３は、限定された条件の組の例を挙げる。ステップ６４において、命令圧縮制御ビットの組３７はサブ命令共用条件の各々を識別するために設定される。その後に命令はステップ６８においてメモリにストアされる。ある実施例においては命令は圧縮されない形式でストアされる（または、サブ命令共用圧縮なしにＮＯＰ圧縮などの従来の圧縮技術のみを用いた形式でストアされる）。別の実施例においては、命令はステップ６６でサブ命令が共用されるべき冗長なサブ命令を省く。
【００５９】
サブ命令共用のために冗長性を除去することなく命令がメモリ内にストアされる実施例の場合は、命令を圧縮する、またはさらに圧縮するための命令が別の時点で実行される。図１２を参照すると、フローチャート６９のステップ７０において、命令圧縮制御ビットの組３７がサブ命令共用条件を識別するためにテストされる。組３７の符号化条件に従って、ステップ７２において１つ以上のサブ命令が命令形式から削除される。削除されたサブ命令は冗長なサブ命令である。ＦＰＵによって共用されるべきである同一のサブ命令が残留する。その結果、圧縮された命令または、さらに圧縮された命令がもたらされる。そのような結果として生じる圧縮された命令は命令キャッシュ２２、一次キャッシュまたはメインメモリ２４に経路制御される。命令のサイズを減じることにより、命令キャッシュにおいて要求されるスペースおよびデータをキャッシュに移動させるために必要となる時間が減じられる。フローチャート６９の方法はさまざまな実施例において、命令がメインメモリ２４から命令キャッシュ２２（図２を参照）に移動される場合に、または別の時点で行われる。
【００６０】
図１３を参照すると、命令圧縮制御ビットの組３７を復号化するための方法のフローチャート７４は、さまざまなサブ命令共用条件に対して制御ビットをテストするためのステップ７６を含む。ステップ７８において、圧縮命令４２はパーズされてサブ命令をデスティネーションであるＦＰＵ２８に経路制御する。サブ命令共用条件が存在する場合、サブ命令は複数の対応の機能処理単位に経路制御される。
【００６１】
代替的な実施例
対応のＦＰＵの間での冗長なサブ命令について、サブ命令を共用するケースを説明してきたが、ある実施例においては同様に包含され得る冗長なサブ命令のさらなる状況が存在する。命令が「ｐ」個のサブ命令フィールドを含む汎用アーキテクチャに関しては、冗長なサブ命令がない状況と、ある程度の冗長がサブ命令の間に存在する、２p-1よりも少ない状況とが存在する。ｐ＝８のサブ命令フィールドが存在するアーキテクチャに関しては、２8＝２５６より少ない状況が存在する。いくつかの状況は同じ結果を表わすので、状況の数はやや２５６よりも少なくなる。しかしながらすべてのそのような状況をカバーするために、命令圧縮制御ビットの組３７内には「ｐ」個の制御ビットが存在する。こうして、一実施例においては命令ごとに「ｐ」個の制御ビットが含まれる。
【００６２】
しかしながら、命令幅が増大する場合、サブ命令共用のために非常に多くの付加的な制御ビットを加えることは望ましくないおそれがある。特に、実務上何度も繰返し出現する、サブ命令の間の冗長性のパターンが存在する傾向がある場合、非常に多くのビットのコストは過剰であると思われるであろう。結果として、好ましい実施例においては、予め定められた数の起こり得る２pのサブ命令共用状況を処理するための制御ビットの数がｐ以下に減じられる。異なったアプリケーションに対しては異なったプロセッサが設計され、サブ命令冗長のパターンも変化する。さらに、サブ命令共用の対象となるサブ命令冗長のケースもまた、所与のプロセッサに対して戦略的に選択され、プロセッサが標的とするこれらのアプリケーション（たとえば、画像処理アプリケーション）に対して最大の効果をもたらすようにされる。上のセクションで説明された好ましい実施例は、一般的な画像処理関数の戦略的に重要なタイトループにおいて発生することが見出されたサブ命令共用シナリオ状況に関連する。
【００６３】
オプコード圧縮−概要
図１４を参照すると、この発明の実施例に従った１つ以上のオプコード圧縮テーブルを組入れたアプリケーションプログラムを処理するためのホストシステム１１１は、プロセッサ２０２、キャッシュメモリ２２、不揮発性メインメモリ２４、およびユーザインターフェイス１２０を含み、これらは１つ以上のバス構造１２２によって相互接続される。ユーザインターフェイス１２０はディスプレイ装置１２４、キーボード１２６およびポイント／クリック装置１２８を含む。
【００６４】
この発明のオプコード圧縮技術は、超長命令語（「ＶＬＩＷ」）プロセッサおよびスーパースカラプロセッサを含むさまざまなホストプロセッサ２０上で実現され得る。例示的なＶＬＩＷプロセッサは、テキサス州ダラスのテキサス・インスツルメント（Texas Instruments）によって製造されるＴＭＳ３２０Ｃ６ｘおよび、日本国東京の株式会社日立製作所とカリフォルニア州キャンベルのイクエータ・テクノロジー（Equator Technologies）とによって製造されるＭＡＰ１０００を含む。各々はデータストリームと命令ストリームとの両方の大量の並列性をサポートし、並列またはパイプライン化されたプログラム命令の実行を実現する。例示的なスーパースカラプロセッサは、ニューヨーク州のインターナショナル・ビジネス・マシーンズ（International Business Machines）およびイリノイ州シカゴのモトローラ・コーポレーション（Motorola Corporation）によって製造されるPowerPC６０４、カリフォルニア州パロアルトのインテル・コーポレーション（Intel Corporation）によるペンティアム（Ｒ）ＩＩプロセッサ、ＭＩＰＳ Ｒ１０００００、マサチューセッツ州メイナードのデジタル・イクイップメント・コーポレーション（Digital Equipment Corporation）によるDEC Alpha２１２６４、カリフォルニア州パロアルトのヒューレット・パッカード（Hewlett-Packard）によって製造されるＰＡ−ＲＩＳＣ ８０００ファミリーのプロセッサ、およびカリフォルニア州サニーベイルのサン・マイクロシステムズ（Sun Microsystems）によって製造されるUltraＳＰＡＲＣ−ＩＩを含む。
【００６５】
図１５は、単一チップ上に実現された例示的なプロセッサ２０を示す。示されるのはメディア加速プロセッサ（media accelerated processor）１０００（ＭＡＰ１０００）のプロセッサアーキテクチャである。ＭＡＰ１０００プロセッサは、直接メモリアクセス（ＤＭＡ）コントローラ１２９、データキャッシュ１３０、命令キャッシュ１３２およびクラスタ２６と呼ばれる並列実行単位を含む。そのような構成要素の各々は共通のチップ上に存在する。クラスタ２６の各々は１つ以上の機能単位２８、たとえば整数演算ならびに論理単位および整数浮動小数点グラフィック演算ならびに論理単位を有する。また、クラスタ２６の各々はいくつかの汎用レジスタ、いくつかの汎用レジスタ、いくつかの１ビットプレディケートレジスタおよび多数の専用レジスタを含む。
【００６６】
命令形式
図１６を参照すると、従来のｋビットの、圧縮されないＶＬＩＷ命令形式は、オプコード１４２、１つ以上のソースオペランドフィールド１４４およびデスティネーションオペランドフィールド１４６を含む。オプコード１４２の各々は、いくつかのサブ命令１４８に区分けされる。クラスタ２６の各々の機能単位２８ごとに１つのサブ命令が存在する。たとえばクラスタごとに２つの機能ユニットの２つのクラスタを有するＶＬＩＷプロセッサ２０に関しては、命令は４つのサブ命令１４８を含む。ソースオペランドフィールド１４４およびデスティネーションオペランドフィールド１４６は同様にサブワード１５０に区分けされる。
【００６７】
図１７を参照すると、ＶＬＩＷ命令のオプコードが、圧縮されない形式１５２およびＮＯＰサブ命令オペランドが圧縮される形式１５４で示される。ＮＯＰサブ命令を圧縮するための１つの従来の方法によると、残りのサブ命令の配置を識別する（よって、ＮＯＰサブ命令の位置をも識別する）マスクワード１５６が生成される。
【００６８】
図１８Ａおよび図１８Ｂを参照すると、ＶＬＩＷ命令のオプコードが２つのオプコード１５８、１６０に対して圧縮されない形式および圧縮された形式で示される。オプコード１５８においては、ＮＯＰサブ命令は存在しない。圧縮されたオプコード形式１６２においては、サブ命令オペランドは減じられたビット長さに圧縮される。特定的には、サブ命令１４８の各々はオプコードがコード１６３と置換えられるが、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。オプコード１６０においてはＮＯＰサブ命令が存在する。好ましい実施例においてはＮＯＰサブ命令は、従来の圧縮方法のいずれかを用いて圧縮される。次いで残りのサブ命令１４８オペランドが圧縮されて圧縮されたオペランド形式１６４を達成する。再び、残りの特定のサブ命令オペランドはコード１６３と置換えられ、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。
【００６９】
通常の動作の間に、ＶＬＩＷ命令のすべてがオプコード圧縮された形式１６２／１６４を示すわけではない。いくつかのオプコードは圧縮されず、またはＮＯＰサブ命令だけが圧縮される。しかしながら、ＶＬＩＷ命令のために好ましい実施例においては、オプコード圧縮方策を示すべきであるいかなるオプコード１４２も、すべてのサブ命令オプコードを圧縮される。しかしながら、ＮＯＰオプコードは好ましくは異なった態様で圧縮されることに留意されたい。また、ある実施例においては、サブ命令の共用はさらに、圧縮されるべきサブ命令オプコードの数を減らすことに留意されたい。
【００７０】
上のセクションにおいて、サブ命令共用と呼ばれる圧縮技術について説明した。その技術によると、オプコードが冗長なサブ命令を含む特定の場合が、サブ命令共用の対象となる。特定的には、圧縮されたサブ命令共用形式において冗長なサブ命令オペランドがより少ない回数で発生する（たとえば、１回発生する）よう、冗長性が除去される。そのような技術に対する命令形式は、サブ命令オペランドに加えて１組の制御ビットを含む。制御ビットは、サブ命令共用の特別な場合を識別する（たとえば、クラスタごとの機能単位１が、圧縮サブ命令共用オプコードの特定のサブワードにストアされるものと同じサブ命令のコピーを受取る）。サブ命令共用のいくつかの場合をここで説明する。
【００７１】
オプコード１４２が圧縮された形式であるか圧縮されない形式であるかを識別するために、制御ビット６５がすべてのオプコード形式に対して用いられる。制御ビットは、サブ命令オペランドの圧縮が実行されていることを示す１つの値を有し、実行されていない（しかしながらＮＯＰ圧縮およびサブ命令共用はやはり実行されているかも知れない）ことを示す別の値を有する。
【００７２】
図２０を参照すると、オプコード形式は圧縮されない形式１４２およびさまざまな圧縮タイプの形式において示される。形式１５４はＮＯＰ圧縮された形式１５４におけるオプコードに対応する。形式１７０は、ＮＯＰ圧縮およびサブ命令共用を示すオプコードに対応する。形式１７２は、ＮＯＰ圧縮、サブ命令共用およびオプコード圧縮の各々を示すオプコードに対応する。動作の間に、プロセッサ２０はこれらの形式のいずれかまたはすべてを、別々にまたは累積して実行し得る。
【００７３】
図２１（Ａ）を参照すると、たとえばＲＩＳＣおよび／またはスーパースカラアーキテクチャを有するプロセッサ２０に対して実現される単一命令形式８０が示される。命令は、オプコード８２、１つ以上のソースオペランドフィールド８４およびデスティネーションオペランドフィールド８６を含む。この発明は、データオペランドに対して圧縮方策が実施されているか否かに拘らずオプコード圧縮に関連するので、オプコードの圧縮についてのみここで説明する。図２１（Ｂ）の圧縮オプコード形式９２においては、オプコードは減じられたビット長さ形式に圧縮される。特定的には、オプコード８２はコード９４と置換えられ、これはオプコードルックアップテーブル１６６（図１９を参照）へ索引付けするか、そうでなければオプコードルックアップテーブル１６６に対して、および／またはこの中でポイントする。オプコード８２が圧縮された形式であるか、または圧縮されない形式であるかを識別するために、制御ビット６５がオプコード形式８２、９２に対して用いられる。制御ビットは、サブ命令オペランドの圧縮が実行されていることを示す１つの値と、実行されていない（しかしながら、ＮＯＰ圧縮およびサブ命令共用はやはり実行されているかも知れない）ことを示す別の値とを有する。
【００７４】
オプコードテーブル
図１９は、複数のエントリ１６８を有するオプコードルックアップテーブル１６６を示す。ホストプロセッサ２０に対する一部のオプコードは、オプコードテーブル１６８にエントリを有する。好ましい実施例においては、小さな、選択されたオプコードのサブセットがテーブル１６８にストアされる。ベストモードの実施例においては、オプコードテーブル１６６の内容はコンパイルの間に規定され、それにより所与のアプリケーションに対してカスタマイズされる。いくつかの実施例においては、オンチップメモリ上で代替的にアクティブになり現在のオプコードテーブルとしての役割を果たし得る複数のオプコードが存在する。オプコードテーブルは、タスク切替の間にタスクに対してロードされる。したがって、テーブルサイズを小さく保つと、ローディングオーバーヘッドが最小化される。さらにテーブルへのエントリを戦略的に選択することにより、テーブルはタスクに対して効率的になる。
【００７５】
特定的な実施例においては、オプコードテーブルが関数コールまたはタスクコールごとのコンパイルの間に生成される。関数がアクティブになると、対応のオプコードテーブルがシステムメモリから（たとえば、不揮発性メモリ２４またはキャッシュメモリ２２から）オンチップメモリ１３２（たとえば、オンチップ命令キャッシュメモリまたはオンチップデータメモリ）にロードされる。そのような場合に、以前のバージョンのオプコードテーブルは退避されるかまたは上書きされる。退避される場合の実施例においては、アドレスも退避される。関数が完了すると、以前のオプコードテーブルのアドレスは検索されて、それにより以前のオプコードテーブルがプロセッサ２０によって用いられる現在のオプコードテーブルとなる。そのような技術を用いると、コード１６３／９４はテーブルアドレスを含む必要がなく、テーブルへのインデックスのみを含んでいればよい。他の実施例、たとえば多数のオプコードテーブルが同時にアクティブになることを許すものにおいては、コードは特定のテーブルをもポイントする。
【００７６】
いくつかの実施例においては、さまざまなオプコードテーブルがプロセッサチップ上にキャッシュされる。所与の時間に１つのテーブルが現在のオプコードテーブルとしてアクティブである。そのような現在のステータスはプログラムのさまざまな部分の実行、またはプログラムの変更の間に動的に変化する。
【００７７】
最も頻繁に発生する特定のオプコードは、実行される関数、タスクおよびアプリケーションプログラムに依存するが、殆どの画像処理アプリケーションに対して、オプコードテーブルにストアするためのオプコードの有効数は、１０−２０のオーダであることが経験的に見出された。これは、典型的なスーパースカラまたはＶＬＩＷプロセッサのオペランド命令セットの全体よりも実質的に少ない。特定的には、この発明者らによる１つの研究においては、殆どの画像処理関数によって用いられるオプコードの約９０％またはそれ以上を保持するのに１６エントリのルックアップテーブルが十分に大きいことが見出された。特に、発明者らはすべての命令圧縮および命令ルックアップテーブルを実現するのではなく、オプコード圧縮およびオプコードテーブルを生成すると、有効な性能に対するエントリの数は実質的により少ないことを見出した。
【００７８】
１６エントリテーブルに対しては、４ビットのみがテーブル１６６へのインデックスを規定すればよい。しかしながら別の実施例においては、テーブルサイズは変化することがあり、したがってコード１６３／９４を規定するビットの数も変動するであろう。エントリの各々（すなわち圧縮されないオプコード）が１２ビットを占有する１６エントリテーブルにおいては、合計１９２ビットが単一のオプコードテーブルに対して用いられる。したがって、テーブルサイズは小さく、オプコードテーブルローディングおよびタスク切替の間に殆どオーバーヘッドを伴わない。これは特に、テーブルが頻繁に更新されるマルチスレッド処理のために有利である。
【００７９】
オプコード圧縮動作
いくつかの実施例においては、オプコードテーブルは所与のプロセッサに対して専用である。しかしながら好ましい実施例に従うと、オプコードテーブルは所与のアプリケーションプログラムのためにソフトウェア内で規定される。図２２を参照して、コンパイラ１００はステップ１０２を実行してソースコードのリストをマシン言語にコンパイルし、コンピュータシステムにインストールする。そのようなコンパイルの間に、コンパイルはオプコードケーブル内にストアするための１組のオプコードを選択するステップ１０４を実行する。そのような選択および記憶は、プログラム全体またはプログラムの一部のいずれかに対して行なわれる。たとえば、オプコードの組は関数、タスクまたはプログラムの他のモジュラー編成単位ごとに選択される。実施例の変形においては、生成されるテーブルの数は編成の方法（たとえば、プログラム全体、関数、他の単位）によって変化し得る。好ましくは、すべてのオプコードテーブルは同じサイズである。
【００８０】
実施例の変形においては、どのオプコードをオプコードテーブルにストアするかを選択するために用いられる方策は変化し得る。好ましい実施例においては、最も頻繁に発生するオプコードが選択される。他の選択方策も実現し得る。
【００８１】
図２３を参照すると、ステップ１０８においてアプリケーションプログラムがコンピュータシステム１１１のシステムメモリ１９（図２５を参照）に実行のためにインストールされる。他の実施例においてはアプリケーションは計算システム上の組込コンピュータプログラムとしてストアされる。ステップ１１０においてアプリケーションプログラムが実行される。
【００８２】
図２４を参照すると、アプリケーションプログラム１１４のフローチャート１１２の動作は、１つ以上のオプコードテーブル２４０、２４２（図２５を参照）の使用に関するいくつかのステップを含む。ステップ１１６においては、アプリケーションプログラムが実行のためにロードされる。そのようなステップは典型的には、アプリケーションプログラムの全部または一部を、不揮発性メモリ２４からキャッシュメモリ２２などのランダムアクセスメモリにロードするステップを含む。プログラム命令のいくつかの部分は、プロセッサのオンチップメモリ１３２にロードされる。
【００８３】
プログラムの実行の間に、コンパイルの間に規定された１つ以上のオプコードテーブル２４０、２４２がオンチップメモリ１３２にロードされる。ある実施例においては、多数のオプコードテーブルが同時にオンチップメモリに存在する。他の実施例においては、所与の時間に１つのオプコードテーブルだけがオンチップメモリに存在する。いずれの場合においても、ポインタ２４６によって示される、所与の時間現在にアクティブであるオプコードテーブルが存在する。プロセッサが命令をパーズし、コード６５／９４がオプコード圧縮がその命令に対してアクティブであることを示すと、プロセッサはアクティブなオプコードテーブルを参照して圧縮命令形式１６２／１６４／１７２／９２において示されるオプコードを検索する。
【００８４】
たとえば、ステップ１１８において、関数Ａの実行のための準備が開始する。そのような準備に含まれるのは、ステップ１２０において関数Ａによって用いられるオプコードテーブルのアクティブ化である。そのようなアクティブ化は、現在のオプコードテーブルポインタ２４６における対応のオプコードテーブルのオンチップアドレスをストアするステップを含む。もしテーブルが既にオンチップにロードされていなければ、ステップはまたテーブルをオンチップメモリにロードするステップをも含む。ステップ１２２において、関数Ａがさらに実行される。オプコード圧縮が用いられていることを示すコード６５を有する如何なる命令も、プロセッサによってパーズされ、オプコードテーブルへのインデックスを識別する。ＶＬＩＷ命令に対しては、多数のインデックスが存在し得る。ＲＩＳＣまたはスーパースカラ命令に対しては、１つのオプコードのみが存在し得る。存在するインデックスの各々は、オプコードを検索するために用いられる。次いでオプコードが実行される。関連する命令内のソースオペランドおよびデスティネーションオペランドフィールドは、実行されるオプコードに対応するマイクロコードに基づいて処理される。
【００８５】
アプリケーションプログラムに対して１つ以上のオプコードテーブルが規定される実施例においては、別のオプコードテーブルが先行のオプコードテーブルに現在アクティブなオプコードテーブルとして置換わる状況がある。たとえば、ステップ１２４において、関数Ｂが実行のためにコールされる。関数Ｂの実行に備えて、関数Ｂの処理のために用いられるべきオプコードテーブルはステップ１２６において現在のオプコードテーブルとなるようアクティブ化される。そのようなアクティブ化は、対応のオプコードテーブルを現在のオプコードテーブルポインタ２４６のオンチップアドレスにストアすることを含む。もしテーブルが既にオンチップにロードされていなければ、ステップはまたテーブルをオンチップメモリにロードすることをも含む。ステップ１２８において、関数Ｂが実行される。関数Ｂの完了の際に、先行のオプコードテーブルが現在のオプコードテーブルとして復元される。そのような復元は、制御が戻されるプログラムの一部に対するオプコードテーブルのアクティブ化と同様である。したがって、関数Ａに対するオプコードテーブルは、アクティブなオプコードテーブルとして復元される。
【００８６】
一実施例においては、関数Ａに対するオプコードテーブルのアドレスが、関数Ｂがコールされたときにスタック２４８にプッシュされる。関数Ｂが完了すると、アドレスはスタック２４８から検索されて、関数Ａに対するオプコードテーブルアドレスを識別する。ステップ１３２において関数Ａの処理が再開する。
【００８７】
共通して用いられるオプコードのテーブルはリアルタイムの処理の間に動的に更新され、上書きされかつ置換えられる。たとえば、テーブルは、アプリケーションプログラムまたはタスクの実行の間にストアされ、アプリケーションプログラムまたはタスクごとに変更される。動的な更新の利点とは、より小さなテーブルサイズが効率的に命令帯域幅を減じることである。
【００８８】
いくつかの実施例においては、テーブルは動的である必要はなく、固定されていてもよい。たとえば、広い範囲のアプリケーションプログラムに対して最も頻繁に用いられるすべてのオプコードをストアするためには、そのようなテーブルは動的に更新されるテーブルよりも大きくなるであろう。好ましい動的実現化のためにテーブルはアプリケーションに対してカスタマイズされ、プログラム設計の一部となる。たとえば、オプコードテーブルにストアされるべきオプコードのそれぞれのテーブルを備えて、異なったタスクがプログラムされる。次いでそれぞれのテーブルはタスク切替の際にロードされる。より小さな動的なオプコードテーブルは、オプコードの効率的な選択の利点と、タスク切替の間のテーブルローディングに対する低いオーバーヘッドとをもたらす。さらに、多数のテーブルをストアするためにプロセッサチップ上にスペースが割当てられている場合、１つのテーブルがアクティブにされ別のものがインアクティブにされるので、テーブルローディングオーバーヘッドはさらに減じられる。
【００８９】
ある実施例においては、所与のオプコードテーブル内の１つ以上の特定のエントリが更新される。オプコードテーブル内のどこで更新された値を上書きするべきかを識別するためにテーブルインデックスを用いる特別な命令が含まれる。さらに、ある実施例においては、データをメモリからオプコードテーブルにより早く転送し、かつテーブルによりコンパクトにストアするためのＣＩＳＣ様の命令が含まれる。
【００９０】
ある実施例においては、、オプコードテーブルは関数コールの早期に不揮発性メモリからプレロードされる。さらに、先行のテーブルに対するポインタは維持され、それにより、関数が完了し処理がコーリングルーチンに戻った後で、オプコードテーブルはコーリングルーチンに対して復元される。
【００９１】
価値のある有利な効果
この発明の利点は、命令キャッシュにおいて必要となる命令スペースが、ＶＬＩＷ命令に対して効率的に減じられることである。特に、画像処理アルゴリズムの間に実行され、占有タイトループを有するいくつかの関数に対しては、スラッシングが発生するであろう場合にも、スラッシングなしにタイトループを維持することが可能である。
【００９２】
別の利点とは、ＶＬＩＷサブ命令においていくらかの冗長性をなくすことにより、より少ないビットのみが必要となり、よってプログラムサイズが減じられることである。さらに、命令キャッシュ利用の効率性が向上し、かつ命令フェッチ帯域幅が増大する。
【００９３】
この発明の好ましい実施例を例示し説明してきたが、さまざまな代替例、変形および等価物を用い得る。したがって、上述の説明は前掲の特許請求の範囲によって規定されるこの発明の範囲を限定するものと解してはならない。
【図面の簡単な説明】
【図１】 ＶＬＩＷ命令を有するコンピュータプログラムの開発および記憶のブロック図である。
【図２】 ＶＬＩＷプロセッサを有するコンピュータシステムの部分的なブロック図である。
【図３】 ＶＬＩＷプロセッサアーキテクチャのブロック図である。
【図４】 図３のプロセッサに対するさまざまなサブ命令フィールド内容のデスティネーションを識別する、ＶＬＩＷ命令形式の図である。
【図５】 例示的な圧縮されないＶＬＩＷ命令の図である。
【図６】 ＮＯＰサブ命令を除去するためのＶＬＩＷ命令の図である。
【図７】 サブ命令共用を実現するためのこの発明の実施例に従って圧縮されたＶＬＩＷ命令の図である。
【図８】 図７の命令に含まれる制御ビットの組の図である。
【図９】 さまざまなサブ命令共用条件を判断するための命令の制御ビットを復号化するための多重化アーキテクチャの図である。
【図１０】 （Ａ）から（Ｅ）は、命令の意図された分散、ＮＯＰ圧縮を備えた命令、およびサブ命令共用のための形式における命令を示す例示的な命令の図である。
【図１１】 命令圧縮制御ビットを設定するための方法のフローチャートである。
【図１２】 サブ命令共用のための命令を圧縮するための方法のフローチャートである。
【図１３】 さまざまなサブ命令共用条件を識別するための命令圧縮制御ビットを復号化するための方法のフローチャートである。
【図１４】 例示的なホスト処理システムのブロック図である。
【図１５】 この発明の実施例に従ってオプコード圧縮が実施される例示的なプロセッサのブロック図である。
【図１６】 従来の圧縮されないＶＬＩＷ命令形式の図である。
【図１７】 従来のＮＯＰ圧縮を有するＶＬＩＷ命令の図である。
【図１８】 （Ａ）および（Ｂ）は、この発明の実施例に従った、オプコード圧縮と、オプコード圧縮およびＮＯＰ圧縮の両方とを示すＶＬＩＷ命令の図である。
【図１９】 この発明の実施例に従ったオプコードテーブルの図である。
【図２０】 圧縮されない形式、ＮＯＰ圧縮された形式、サブ命令共用形式およびオプコード圧縮された形式を含む、進行形式（progressive format）におけるＶＬＩＷ命令の図である。
【図２１】 （Ａ）および（Ｂ）は、ＲＩＳＣまたはスーパースカラプロセッサアーキテクチャに対する圧縮されない形式およびオプコード圧縮された形式における命令の図である。
【図２２】 この発明の実施例に従った１つ以上のオプコードテーブルを規定するコンパイル動作のフローチャートである。
【図２３】 アプリケーションプログラムをインストールし実行するためのフローチャートである。
【図２４】 この発明の実施例に従った、オプコード圧縮実現化を例示する図２３のアプリケーションプログラムの関連部分の実行のフローチャートである。
【図２５】 この発明の実施例に従った、オプコードテーブルをロードするためのメモリ編成の図である。
【符号の説明】
２６ クラスタ、２７ クラスタのためのレジスタファイル、２８ 機能処理単位。
Claims (17)
- 超長命令語アーキテクチャを有するプロセッサ上の複数のクラスタの機能処理単位の間の所与の命令におけるサブ命令の共用方法であって、前記所与の命令は制御ビットの組および少なくとも第１および第２のサブ命令を含み、前記プロセッサは複数のクラスタを含み、前記複数のクラスタの各々は複数の機能処理単位を含み、前記方法は、
制御ビットの組をテストして第１の所定の条件を識別するステップと、
前記第１の所定の条件が識別された場合、前記所与の命令の前記第１のサブ命令を、前記複数のクラスタの前記第１のクラスタの第１の機能処理単位および前記第２のクラスタの第１の機能処理単位に経路制御するステップと、
前記制御ビットの組をテストして第２の所定の条件を識別するステップと、
前記第２の所定の条件が識別された場合、前記所与の命令の前記第２のサブ命令を、前記複数のクラスタの前記第１のクラスタの第２の機能処理単位および前記第２のクラスタの第２の機能処理単位に経路制御するステップと、
前記第１のサブ命令を前記第１のクラスタの前記第１の機能処理単位で、前記第１のサブ命令を前記第２のクラスタの前記第１の機能処理単位で、前記第２のサブ命令を前記第１のクラスタの前記第２の機能処理単位で、および前記第２のサブ命令を前記第２のクラスタの前記第２の機能処理単位で同時実行するステップとを備えることを特徴とするサブ命令の共用方法。 - 超長命令語アーキテクチャを有するプロセッサで実行するべきコンピュータプログラムの命令のストア方法であって、
命令の各々は、少なくとも１つのサブ命令から第１の所定数のサブ命令までの間のサブ命令を含み、前記第１の所定数は少なくとも２であり、
前記プロセッサは、第２の所定数に等しい複数のクラスタに編成され、前記複数のクラスタの各々は、共通の個数の機能処理単位からなり、前記共通の個数と前記第２の所定数との積は前記第１の所定数と等しく、
前記第１の所定数のサブ命令を有する所与の命令に対しては、前記複数のクラスタの機能処理単位の各々が、前記所与の命令のそれぞれのサブ命令を実行するためのものであり、前記方法は、
前記所与の命令内で冗長なサブ命令が１度以上発生するパターンを識別するステップと
、
前記パターンは所定のパターンの組の中のものか否かを判断するステップと、
前記パターンが前記所定のパターンの組の中のものである場合、前記命令に対する制御ビットの組を設定して前記パターンが存在することを示すステップとを備えることを特徴とする命令のストア方法。 - 前記パターンが前記所定のパターンの組の中のものである場合、圧縮された命令を得るために所与の命令内の冗長なサブ命令の１つの発生を削除することにより、所与の命令を圧縮するステップをさらに含むことを特徴とする請求項２に記載の命令のストア方法。
- 圧縮された命令を命令キャッシュ内に移動するステップと、
圧縮された命令の制御ビットの組をテストして、圧縮された命令に対してサブ命令共用が発生することを識別する条件を判断するステップと、
サブ命令共用が発生すると判断された場合、圧縮された命令をパーズして、冗長なサブ命令を識別された条件によって判断された複数の機能処理単位に経路制御するステップと、
サブ命令を、前記複数の機能処理単位で同時実行するステップとをさらに備えることを特徴とする請求項３に記載の命令のストア方法。 - 超長命令語アーキテクチャを有するプロセッサ上で実行するためのコンピュータプログラムの命令のストア方法であって、
命令の各々は、少なくとも１つのサブ命令から第１の所定数までのサブ命令を含み、前記第１の所定数は少なくとも４であり、
プロセッサは第２の所定数に等しい複数のクラスタに編成され、前記複数のクラスタの各々は共通の個数の機能処理単位を含み、前記共通の個数と前記第２の所定数との積は前記第１の所定数と等しく、前記方法は、
所与の命令に対して、前記複数のクラスタの第１のクラスタの第１の機能単位によって処理されるべき第１のサブ命令と、前記複数のクラスタの第２のクラスタの第１の機能単位によって処理されるべき第２のサブ命令とを比較するステップと、
前記第１のサブ命令が前記第２のサブ命令と同じである場合、前記所与の命令に関連の制御ビットの組の第１の制御ビットを、前記第２のサブ命令が前記第１のサブ命令と等しいことを示す第１の論理状態に設定するステップと、
前記所与の命令に対して、前記複数のクラスタの前記第１のクラスタの第２の機能単位によって処理されるべき第３のサブ命令と、前記複数のクラスタの前記第２のクラスタの第２の機能単位によって処理されるべき第４のサブ命令とを比較するステップと、
第３のサブ命令が第４のサブ命令と同じである場合、前記所与の命令に関連の制御ビットの組の第２の制御ビットを第４のサブ命令が第３のサブ命令と等しいことを示す第２の論理状態に設定するステップと、
第１の制御ビットおよび第２の制御ビットを備えた前記所与の命令をストアするステップとを備えることを特徴とする命令のストア方法。 - 前記ストアするステップは、所与の命令を圧縮されない形式にストアするステップを含み、所与の命令を圧縮された形式に圧縮するステップと、所与の命令を圧縮された形式でキャッシュにストアするステップとをさらに含み、前記圧縮するステップは、
所与の命令に関連する第１の制御ビットをテストするステップと、
前記第１の制御ビットが前記第１の論理状態と等しい場合に、所与の命令を圧縮してサイズを減じて、等しい前記第１のサブ命令と前記第２のサブ命令とのうちの１つのコピーを省いて、前記第１のサブ命令および前記第２のサブ命令の冗長な記憶を避けるステップと、
所与の命令に関連する前記第２の制御ビットをテストするステップと、
前記第２の制御ビットが前記第２の論理状態と等しい場合に、所与の命令を圧縮してサイズを減じて、等しい前記第３のサブ命令と前記第４のサブ命令とのうちの１つのコピー
を省いて、前記第３のサブ命令および前記第４のサブ命令の冗長な記憶を省くステップ７２とを備えることを特徴とする請求項５に記載の命令のストア方法。 - 前記ストアするステップは、所与の命令を圧縮された形式でストアするステップを含み、前記ストアするステップの前に、所与の命令を圧縮された形式に圧縮するステップをさらに含み、前記圧縮するステップは、
前記第１の制御ビットが前記第１の論理状態と等しい場合に、所与の命令を圧縮してサイズを減じて、等しい前記第１のサブ命令と前記第２のサブ命令とのうちの１つのコピーを省いて、前記第１のサブ命令および前記第２のサブ命令の冗長な記憶を避けるステップと、
前記第２の制御ビットが前記第２の論理状態に等しい場合に、所与の命令を圧縮してサイズを減じて、等しい前記第３のサブ命令と前記第４のサブ命令とのうちの１つのコピーを省いて、前記第３のサブ命令および前記第４のサブ命令の冗長な記憶を省くステップとを備えることを特徴とする請求項５に記載の命令のストア方法。 - 所与の命令を圧縮された形式でキャッシュにストアするステップをさらに含むことを特徴とする請求項７に記載の命令のストア方法。
- 所与の命令を前記第１の制御ビットおよび前記第２の制御ビットを備えて圧縮された形式でキャッシュにストアするステップを含み、前記圧縮された形式は、前記第１の制御ビットが前記第１の論理状態に設定されている場合に、前記第１のサブ命令の記憶と前記第２のサブ命令の記憶とを組合せて第１の組合された記憶にし、前記圧縮された形式は、前記第２の制御ビットが前記第２の論理状態に設定されている場合に、前記第３のサブ命令の記憶と前記第４のサブ命令の記憶とを組合せて第２の組合された記憶にし、
さらに前記第１の制御ビットをテストするステップと、
前記第１の制御ビットが前記第１の論理状態に設定されている場合、前記第１の組合された記憶の内容を、前記第１のクラスタの前記第１の機能処理単位および前記第２のクラスタの前記第１の機能処理単位に経路制御して、前記第１のクラスタの前記第１の機能処理単位および前記第２のクラスタの前記第１の機能処理単位による同時実行を行なわせるステップと、
前記第２の制御ビットをテストするステップと、
前記第２の制御ビットが前記第２の論理状態に設定されている場合、前記第２の組合された記憶の内容を、前記第１のクラスタの前記第２の機能処理単位および前記第２のクラスタの前記第２の機能処理単位に経路制御して、前記第１のクラスタの前記第２の機能処理単位および前記第２のクラスタの前記第２の機能処理単位による同時実行を行なわせるステップとを備えることを特徴とする請求項５に記載の命令のストア方法。 - 超長命令語アーキテクチャを有するプロセッサ上で実行するためのコンピュータプログラムの命令を圧縮された形式に圧縮する命令圧縮方法であって、
前記命令の各々は、少なくとも１つの第１の所定数までのサブ命令を含み、前記第１の所定数は少なくとも４であり、
前記プロセッサは、第２の所定数に等しい複数のクラスタに編成され、前記複数のクラスタの各々は、共通の個数の機能処理単位２８を含み、前記共通の個数と前記第２の所定数との積は前記第１の所定数に等しく、
前記方法は、
所与の命令に対して、前記複数のクラスタの第１のクラスタの第１の機能単位によって処理されるべき第１のサブ命令と、前記複数のクラスタの第２のクラスタの第１の機能単位によって処理されるべき第２のサブ命令とを比較するステップと、前記第１のサブ命令が前記第２のサブ命令と同じである場合、所与の命令を前記第１のサブ命令を備えるが前記第２のサブ命令を備えずにストアされるよう圧縮し、かつ所与の命令に関連の第１の制御ビットを、前記第２のサブ命令が前記第１のサブ命令に等しいことを示す論理状態に設定するステップと、
所与の命令に対して、前記複数のクラスタの前記第１のクラスタの第２の機能単位によ
って処理されるべき第３のサブ命令と、前記複数のクラスタの前記第２のクラスタの第２の機能単位によって処理されるべき第４のサブ命令とを比較するステップと、
前記第３のサブ命令が前記第４のサブ命令と同じであった場合、所与の命令を前記第３のサブ命令を備えるが前記第４のサブ命令を備えずにストアされるよう圧縮し、かつ所与の命令に関連の第２の制御ビットを、前記第４のサブ命令が前記第３のサブ命令に等しいことを示す論理状態に設定するステップとを備えることを特徴とする命令圧縮方法。 - 超長命令語アーキテクチャを有しかつ機能処理単位の複数のクラスタを含むプロセッサを備えたコンピュータシステムであって、
前記複数のクラスタのクラスタの各々は、共通の数ｍの機能処理単位を含み、前記プロセッサは、第１の所定数のクラスタを含み、前記超長命令語アーキテクチャは、命令が第２の所定数までのサブ命令を有することを可能にし、前記第２の所定数は、前記第１の所定数と前記共通の数との積に等しく、前記プロセッサによって実行されるべき命令の各々は、制御ビットの組を備えて、１つのサブ命令から前記第２の所定数のサブ命令までを含み、
前記コンピュータシステムはさらに制御ビットの組の条件によって決定される圧縮された形式に第１のサブ命令をストアする命令キャッシュメモリを備え、
前記圧縮された形式は、複数の機能処理単位によって共用されるべき第１の命令の所与のフィールド内にストアされる共用サブ命令を含み、前記複数の機能処理単位は、前記制御ビットの組の条件によって判断され、
前記共用サブ命令は、前記制御ビットの組が第１の所定の条件を識別した場合、第１の クラスタの第１の機能処理単位および第２のクラスタの第１の機能処理単位に対するものであり、
前記共用サブ命令は、第１の共用サブ命令であり、圧縮された形式は、制御ビットの組が同時に第２の所定の条件を識別した場合、前記第１のクラスタの第２の機能処理単位および前記第２のクラスタの第２の機能処理単位に対する第２の共用サブ命令をさらに含むことを特徴とするコンピュータシステム。 - 所与の命令に対して制御ビットの組をテストする手段と、
前記テストする手段が第１の所定の条件を識別した場合、前記第１の共通のサブ命令を、前記複数のクラスタの前記第１のクラスタの前記第１の機能処理単位と前記第２のクラスタの前記第１の機能処理単位とに経路制御する手段とをさらに備えることを特徴とする請求項１１に記載のコンピュータシステム。 - 前記第１の共通のサブ命令は、前記第１のクラスタの前記第１の機能処理単位および前記第２のクラスタの前記第１の機能処理単位で同時実行されることを特徴とする請求項１１に記載のコンピュータシステム。
- 超長命令語アーキテクチャを有しかつ機能処理単位の複数のクラスタを含むプロセッサを備えたコンピュータシステムであって、
前記複数のクラスタのクラスタの各々は、共通の数ｍの機能処理単位を含み、前記プロセッサは、第１の所定数のクラスタを含み、前記超長命令語アーキテクチャは、命令が第２の所定数までのサブ命令を有することを可能にし、前記第２の所定数は、前記第１の所定数と前記共通の数との積に等しく、前記プロセッサによって実行されるべき命令の各々は、制御ビットの組を備えて、１つのサブ命令から前記第２の所定数のサブ命令までを含み、
前記コンピュータシステムはさらに制御ビットの組の条件によって決定される圧縮された形式に第１のサブ命令をストアする命令キャッシュメモリを備え、
前記圧縮された形式は、複数の機能処理単位によって共用されるべき第１の命令の所与のフィールド内にストアされる共用サブ命令を含み、前記複数の機能処理単位は、前記制御ビットの組の条件によって判断され、
前記共用サブ命令は、前記制御ビットの組が第１の所定の条件を識別した場合、第１のクラスタの第１の機能処理単位および第２のクラスタの第１の機能処理単位に対するものであり、
前記圧縮されない形式の第１の命令は、前記第２の所定数のサブ命令を含み、前記第１の命令は、第１のクラスタの第１の機能処理単位）によって実行される第１のサブ命令と、第２のクラスタの第１の機能処理単位によって実行される第２のサブ命令とを含み、前記システムはさらに、前記第１の命令をコンパイルする手段を含み、該コンパイルする手段は、
前記第１のサブ命令と前記第２のサブ命令とを比較する手段と、
前記第１のサブ命令が前記第２のサブ命令に等しい場合に、第１の所定の条件を識別するために制御ビットの組の状態を設定する手段とを含むことを特徴とするコンピュータシステム。 - 超長命令語アーキテクチャを有しかつ機能処理単位の複数のクラスタを含むプロセッサを備えたコンピュータシステムであって、
前記複数のクラスタのクラスタの各々は、共通の数ｍの機能処理単位を含み、前記プロセッサは、第１の所定数のクラスタを含み、前記超長命令語アーキテクチャは、命令が第２の所定数までのサブ命令を有することを可能にし、前記第２の所定数は、前記第１の所定数と前記共通の数との積に等しく、前記プロセッサによって実行されるべき命令の各々は、制御ビットの組を備えて、１つのサブ命令から前記第２の所定数のサブ命令までを含み、
前記コンピュータシステムはさらに制御ビットの組の条件によって決定される圧縮された形式に第１のサブ命令をストアする命令キャッシュメモリを備え、
前記圧縮された形式は、複数の機能処理単位によって共用されるべき第１の命令の所与のフィールド内にストアされる共用サブ命令を含み、前記複数の機能処理単位は、前記制御ビットの組の条件によって判断され、
前記共用サブ命令は、前記制御ビットの組が第１の所定の条件を識別した場合、第１のクラスタの第１の機能処理単位および第２のクラスタの第１の機能処理単位に対するものであり、
前記圧縮されない形式の前記第１の命令は、前記第２の所定数のサブ命令を含み、前記第１の命令は、第１のクラスタの第１の機能処理単位によって実行される第１のサブ命令と、第２のクラスタの第１の機能処理単位によって実行される第２のサブ命令とを含み、前記システムはさらに、前記第１の命令を圧縮された形式に圧縮する手段を含み、該圧縮する手段は、
前記第１の命令に関連の制御ビットの組をテストする手段と、
前記制御ビットの組が、前記第１のサブ命令と前記第２のサブ命令とが等しいことを識別した場合、前記第２のサブ命令を省くことにより第１の命令のサイズを減じる手段とを含むことを特徴とするコンピュータシステム。 - 超長命令語アーキテクチャを有しかつ機能処理単位の複数のクラスタを含むプロセッサを備えたコンピュータシステムであって、
前記複数のクラスタのクラスタの各々は、共通の数ｍの機能処理単位を含み、前記プロセッサは、第１の所定数のクラスタを含み、前記超長命令語アーキテクチャは、命令が第２の所定数までのサブ命令を有することを可能にし、前記第２の所定数は、前記第１の所定数と前記共通の数との積に等しく、前記プロセッサによって実行されるべき命令の各々は、制御ビットの組を備えて、１つのサブ命令から前記第２の所定数のサブ命令までを含み、
前記コンピュータシステムはさらに制御ビットの組の条件によって決定される圧縮された形式に第１のサブ命令をストアする命令キャッシュメモリを備え、
前記圧縮された形式は、複数の機能処理単位によって共用されるべき第１の命令の所与のフィールド内にストアされる共用サブ命令を含み、前記複数の機能処理単位は、前記制御ビットの組の条件によって判断され、
前記共用サブ命令は、前記制御ビットの組が第１の所定の条件を識別した場合、第１のクラスタの第１の機能処理単位および第２のクラスタの第１の機能処理単位に対するものであり、
圧縮されない形式の第１の命令は、前記第２の所定数のサブ命令を含み、前記第１の命令は、第１のクラスタの第１の機能処理単位によって実行される第１のサブ命令と、第２のクラスタの第１の機能処理単位によって実行される第２のサブ命令とを含み、前記システムはさらに、前記第１の命令をキャッシュする手段を含み、該キャッシュする手段は、
第１の命令に関連の制御ビットの組をテストする手段と、
制御ビットの組が、前記第１のサブ命令と前記第２のサブ命令とが等しいことを識別した場合、前記第２のサブ命令を省くことによりサイズを減じて第１の命令を圧縮された形式にする手段と、
第１の命令を圧縮された形式で命令キャッシュにロードする手段とを含むことを特徴とするコンピュータシステム。 - 超長命令語アーキテクチャを有しかつ機能処理単位の複数のクラスタを含むプロセッサを備えたコンピュータシステムであって、
前記複数のクラスタのクラスタの各々は、共通の数ｍの機能処理単位を含み、前記プロセッサは、第１の所定数のクラスタを含み、前記超長命令語アーキテクチャは、命令が第２の所定数までのサブ命令を有することを可能にし、前記第２の所定数は、前記第１の所定数と前記共通の数との積に等しく、前記プロセッサによって実行されるべき命令の各々は、制御ビットの組を備えて、１つのサブ命令から前記第２の所定数のサブ命令までを含み、
前記コンピュータシステムはさらに制御ビットの組の条件によって決定される圧縮された形式に第１のサブ命令をストアする命令キャッシュメモリを備え、
前記圧縮された形式は、複数の機能処理単位によって共用されるべき第１の命令の所与のフィールド内にストアされる共用サブ命令を含み、前記複数の機能処理単位は、前記制御ビットの組の条件によって判断され、
前記共用サブ命令は、前記制御ビットの組が第１の所定の条件を識別した場合、第１のクラスタの第１の機能処理単位および第２のクラスタの第１の機能処理単位に対するものであり、
圧縮されない形式の第１の命令は、前記第２の所定数のサブ命令を含み、前記第１の命令は、第１のクラスタの第１の機能処理単位によって実行される第１のサブ命令と、第２のクラスタの第１の機能処理単位によって実行される第２のサブ命令とを含み、前記システムはさらに、前記第１の命令をキャッシュする手段を含み、該キャッシュする手段は、
前記第１のサブ命令と前記第２のサブ命令とを比較する手段と、
前記第１のサブ命令が前記第２のサブ命令に等しい場合に、第１の所定の条件を識別するよう前記第１の命令に関連の制御ビットの組の状態を設定する手段と、
前記制御ビットの組が、前記第１のサブ命令と前記第２のサブ命令とが等しいことを識別した場合、前記第２のサブ命令を省くことにより第１の命令のサイズを減じて圧縮された形式を得る手段と、
圧縮された形式で前記第１の命令を命令キャッシュにロードする手段とを含むことを特徴とするコンピュータシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001357626A JP3806341B2 (ja) | 2001-11-22 | 2001-11-22 | サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001357626A JP3806341B2 (ja) | 2001-11-22 | 2001-11-22 | サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003167732A JP2003167732A (ja) | 2003-06-13 |
| JP2003167732A5 JP2003167732A5 (ja) | 2005-07-14 |
| JP3806341B2 true JP3806341B2 (ja) | 2006-08-09 |
Family
ID=19168935
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001357626A Expired - Fee Related JP3806341B2 (ja) | 2001-11-22 | 2001-11-22 | サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3806341B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4864840B2 (ja) | 2007-08-31 | 2012-02-01 | 株式会社東芝 | マイクロプロセッサ |
| US9201652B2 (en) | 2011-05-03 | 2015-12-01 | Qualcomm Incorporated | Methods and apparatus for storage and translation of entropy encoded software embedded within a memory hierarchy |
| JP5770534B2 (ja) * | 2011-06-01 | 2015-08-26 | 富士通株式会社 | プロセッサ、圧縮プログラム、圧縮装置、および圧縮方法 |
| US10120692B2 (en) | 2011-07-28 | 2018-11-06 | Qualcomm Incorporated | Methods and apparatus for storage and translation of an entropy encoded instruction sequence to executable form |
-
2001
- 2001-11-22 JP JP2001357626A patent/JP3806341B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003167732A (ja) | 2003-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6859870B1 (en) | Method and apparatus for compressing VLIW instruction and sharing subinstructions | |
| US6779101B1 (en) | Method and apparatus for processing compressed VLIW subinstruction opcodes | |
| US5958048A (en) | Architectural support for software pipelining of nested loops | |
| US7953955B2 (en) | Methods and apparatus for automated generation of abbreviated instruction set and configurable processor architecture | |
| JP3795757B2 (ja) | 高データ密度のｒｉｓｃプロセッサ | |
| US6665776B2 (en) | Apparatus and method for speculative prefetching after data cache misses | |
| JP5638108B2 (ja) | 処理スケジューリング方法、コンピュータおよびコンピュータプログラム | |
| Hoogerbrugge et al. | A code compression system based on pipelined interpreters | |
| US8578351B2 (en) | Hybrid mechanism for more efficient emulation and method therefor | |
| EP1267256A2 (en) | Conditional execution of instructions with multiple destinations | |
| KR20010033147A (ko) | 다중 데이터 경로 인스턴스를 갖는 프로세서 | |
| KR20000076285A (ko) | 기계 판독가능 매체 및 초대형 인스트럭션 워드 프로세서와, 컴퓨터 프로그램의 실행 방법 및 컴파일 방법 | |
| TWI764966B (zh) | 用於控制矢量記憶體存取之資料處理裝置及方法 | |
| US6550000B1 (en) | Processor to execute in parallel plurality of instructions using plurality of functional units, and instruction allocation controller | |
| US6256725B1 (en) | Shared datapath processor utilizing stack-based and register-based storage spaces | |
| JP3806341B2 (ja) | サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム | |
| JPH1097423A (ja) | ループ処理の並列実行制御に適したレジスタ構成を有するプロセッサ | |
| CN110073332B (zh) | 数据处理装置和方法 | |
| US5964870A (en) | Method and apparatus for using function context to improve branch | |
| Hoogerbrugge et al. | Pipelined Java virtual machine interpreters | |
| Wei et al. | A near-memory processor for vector, streaming and bit manipulation workloads | |
| US20010037444A1 (en) | Instruction buffering mechanism | |
| US20040015682A1 (en) | Application registers | |
| US6886091B1 (en) | Replacing VLIW operation with equivalent operation requiring fewer issue slots | |
| KR101099828B1 (ko) | 프로세싱 시스템, 이 프로세싱 시스템에 의해서 인스트럭션의 집합을 실행하는 ｖｌｉｗ 프로세서, 방법 및 컴퓨터 판독가능한 저장 매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041110 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041110 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051220 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060317 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060411 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060510 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060515 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060512 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3806341 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110519 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120519 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130519 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |