JP2003167732A - サブ命令の共用、命令のストアならびに圧縮のための方法、およびコンピュータシステム - Google Patents

Abstract

(57)【要約】 【課題】 サブ命令を共用する条件を識別する制御ビッ
トの組を有するＶＬＩＷ命令形式を導入する。 【解決手段】 ＶＬＩＷのコンパイル時に、命令が分析
されてサブ命令を共用する機会を識別する。そのような
機会は、命令の制御ビット内に符号化される。命令が命
令キャッシュ内に移動される前に、命令は新しい形式に
圧縮されて、選択されたサブ命令の冗長な発生を削除す
る。特定的には、サブ命令がそれぞれのクラスタ（２
６）の対応の機能処理単位（２８）によって共用される
べきである場合、サブ命令は命令内に１度だけ現れれば
よい。冗長な発生は削除される。制御ビットは命令のパ
ーズ時に復号化されて、共用サブ命令を関連の機能処理
単位に経路制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の背景】この発明は、プロセッサ命令を圧縮する
ための超長命令語（ＶＬＩＷ）計算アーキテクチャ、方
法および装置に関し、より特定的にはＶＬＩＷ命令の記
憶要件を減じるための方法および装置、ならびに命令の
オプコード部分を圧縮するための方法および装置に関す
る。

【０００２】処理効率を最適化するための従来の努力に
おいて、命令帯域幅よりもデータ帯域幅に多く対処がな
されてきた。この偏重は、たとえば典型的にはデータキ
ャッシュミス率よりも少ない命令キャッシュ率を示すベ
ンチマークプログラムに基づくと、正しいように思われ
る。そのような結果は、オフチップ命令帯域幅要件はデ
ータ帯域幅要件よりも小さいことを示す。しかしなが
ら、画像処理のようないくつかの商業的作業負荷に対し
ては、典型的にはデータキャッシュミス率は命令キャッ
シュミス率よりも低い。したがって、命令帯域幅を最適
化する必要性が増大している。

【０００３】最近の２つの傾向が命令帯域幅を増大さ
せ、したがって、大きなサイズの命令キャッシュに対す
る必要性を増大させている。第１の傾向は、超長命令語
（ＶＬＩＷ）アーキテクチャが多くの高性能プロセッサ
アーキテクチャにおいて一般的になってきていることで
ある。ＶＬＩＷアーキテクチャは、その広い命令ビット
を活用してサイクルごとに多数の動作を実行する。これ
が直接反映して、スーパースカラアーキテクチャと比較
して顕著に増大した命令帯域幅をもたらす。たとえば、
２５６ビットのＶＬＩＷ命令幅（典型的な縮小命令セッ
トコンピュータ（ＲＩＳＣ）命令よりも４倍から８倍広
い）は珍しくはない。

【０００４】画像処理などのマルチメディア計算アプリ
ケーションは、多数のデータストリームを扱うための並
列構造を用いてより効率的に実現される。テキサス州ダ
ラスのテキサス・インスツルメント（Texas Instrument
s）によって製造されるＴＭＳ３２０Ｃ６ｘおよび、日
本国東京の株式会社日立製作所とカリフォルニア州キャ
ンベルのイクエータ・テクノロジー（Equator Technolo
gies）とによって製造されるＭＡＰ１０００などのＶＬ
ＩＷプロセッサは、データストリームと命令ストリーム
との両方の大量の並列性をサポートし、プログラム命令
の並列またはパイプライン化された実行を実現する。

【０００５】ＶＬＩＷプロセッサは、クラスタと呼ばれ
る１つ以上の多数の均一な処理ブロックを有する。クラ
スタの各々は、共通の数の機能処理単位を含む。ＶＬＩ
Ｗ命令は多数のサブ命令フィールドを含む。ＶＬＩＷ命
令のサイズは線形に増大し、並列命令の数はサブ命令フ
ィールドにおいて並行に規定される。命令に現われるサ
ブ命令は並列実行のために機能処理単位の間で分散され
る。

【０００６】従来のＶＬＩＷプロセッサは、典型的には
命令ごとに１０未満の動作を実行する。同時実行の数は
将来のメディアプロセッサにおいて実質的に増大する見
込みであり、命令は２５６または５１２ビット幅になる
見込みである。しかしながら、命令のサイズが増大する
につれ、対応してデータフローおよびメモリ構造に対す
る負荷が増大する。十分な命令フェッチ帯域幅を提供す
るために、ＶＬＩＷ命令は典型的には最初に外部メモリ
からフェッチされ、実行される前にオンチップ命令キャ
ッシュにストアされる。たとえばタイト処理ループの間
の、キャッシュのスラッシング（すなわち、サイクルミ
ス）は、非常に望ましくなく、性能の劣化につながる。
したがって、命令キャッシュを効率的に管理して所望の
高い処理スループットを維持することが強く望まれてき
ている。

【０００７】同時に、プロセッサのクロック周波数が増
大し、より広いＶＬＩＷアーキテクチャが適用され、か
つより複雑なアルゴリズムが開発されるにつれ、より大
きな命令キャッシュに対する必要性は増大する。したが
って、ＶＬＩＷ命令を効率的に扱いかつキャッシュする
ための方法に対する必要性がある。

【０００８】第２の傾向は、プロセッサクロック周波数
を増大するにあたって深い実行パイプラインの使用がク
リティカルになってきていることである。深い実行パイ
プラインはリードアフターライト依存においてコンフリ
クトの可能性を増大させる。コンフリクトはＮＯＰ命令
の挿入か、または実行パイプラインをストールさせるハ
ードウェア検出技術によって解決される。いずれの場合
においても、貴重な実行サイクルが失われ、これはプロ
セッサの最大限の活用を阻む。ソフトウェアパイプライ
ン化はこれらの深い実行パイプラインにおけるリードア
フターライトコンフリクトをなくすことにおいて重要な
ツールとなった。ソフトウェアパイプライン化は、タイ
トループを何度かアンロールし、かつタイトループの多
数の反復をオーバーラップさせて、付加的なＮＯＰまた
はプロセッサストールサイクルなしにリードアフターラ
イト依存を解決させるための余地を作ることを可能にす
る。これはタイトループサイズを増大させ、よって命令
キャッシュミス率をも増大させるという弊害がある。し
たがって、命令帯域幅を減じるか、より効率的に扱う技
術に対する必要性が存在する。

【０００９】複合命令セットコンピュータ（ＣＩＳＣ）
アーキテクチャおよび縮小命令セットコンピュータ（Ｒ
ＩＳＣ）アーキテクチャにおいては、命令キャッシュの
効率性により命令圧縮をほとんど必要としなかった。し
かしながら、ビルコウスキ（Bealkowski）他による１９
９７年７月３日発行の米国特許第５，６３６，３５２号
の「圧縮命令を用いるための方法および装置」において
は、命令圧縮技術が導入されている。命令はオプコード
（すなわち命令オペランド）および１つ以上のデータオ
ペランド（たとえばソースオペランドフィールドおよび
デスティネーションオペランドフィールド）からなる。
１つ以上の制御ビットもまた命令内に含まれる。ビルコ
ウスキ他は、頻繁に用いられる命令に対するエントリを
含む、シノニムテーブルと呼ばれるテーブルを実現す
る。命令のシーケンスは以前に定義されていない特別オ
プコードおよびそれぞれのシノニムテーブルへのインデ
ックスを有する単一の命令に圧縮される（たとえば、命
令内で許可されるビットの数に基づく限度まで、シーケ
ンスの命令ごとに１つが圧縮される）。

【００１０】ビルコウスキ他の圧縮技術の制限とは、典
型的なプログラムにおける唯一の（unique）命令の数が
非常に大きいことである。したがって、ビルコウスキ他
は１２ビットの最大インデックス幅と、エントリの各々
が３２ビットの命令を保持する４０９６エントリのシノ
ニムテーブルとを提案する。そのようなテーブルは１６
キロバイトのオンチップメモリを必要とする。そのよう
なテーブルのサイズは高性能プロセッサなどにおいて用
いられるレベル１命令キャッシュに匹敵するので、これ
は費用のかかる解決策である。ビルコウスキ他は、シノ
ニムテーブルが読出専用メモリ内にストアされ、かつマ
イクロプロセッサ設計の時点で予め規定される１つの実
施例を提案する。別の実施例においてはビルコウスキ他
は、シノニムテーブルがプロセッサ初期化の間にロード
可能であることを提案する。しかしながら企図される場
合、テーブルは静的で変化しない構成である。したがっ
て、命令帯域幅を減じるためのより効率的な解決策に対
する必要性がある。

【００１１】

【発明の要約】この発明に従うと、ＶＬＩＷ命令のサブ
命令は機能処理単位の間で共用されて、命令キャッシュ
に、ある実施例においてはメインメモリにストアされる
ＶＬＩＷ命令のサイズを減じる。特定的には、ＶＬＩＷ
命令はサブ命令共用の場合に圧縮される。ある実施例に
おいては命令はコンパイル時に圧縮され、圧縮された形
式でメインメモリにストアされる。他の実施例において
は命令は圧縮されない形式でメインメモリにストアさ
れ、キャッシュメモリにストアされる前に圧縮される。

【００１２】この発明の一局面によると、命令圧縮制御
ビットの組がＶＬＩＷ命令の各々に関連付けられる。一
実施例においてはＶＬＩＷ命令は命令内の制御ビット組
を含むよう形式化される。ＶＬＩＷ命令は、複数のサブ
命令フィールド、命令圧縮制御ビット組、およびＮＯＰ
命令の位置を示す（すなわち、空である）ものなどのよ
うな他の雑制御ビットを含む。

【００１３】完全に拡張された形式においては、ＶＬＩ
Ｗ命令は予め規定された数のサブ命令フィールドを含
み、フィールドの数はＶＬＩＷ命令を実行するプロセッ
サのアーキテクチャによって決定される。サブ命令フィ
ールドのいくつかはＮＯＰ命令であり得る。さらにサブ
命令フィールドのいくつかは他のサブ命令フィールドに
あるものと同じサブ命令を含み得る。ＮＯＰ命令のため
に割当てられるスペースを除去するために命令を圧縮す
ることが公知である。この発明に従うと、選択された場
合のサブ命令の冗長性を減じるための方策が提供され
る。

【００１４】１つの命令が４つのサブ命令フィールドを
含むアーキテクチャを考察する。そのような命令に対し
て関連する１５の状況が存在する。１つの状況において
は、冗長なサブ命令は存在しない（たとえば、ＡＢＣ
Ｄ）。残りの状況においては、サブ命令の間にある程度
の冗長性が存在する（たとえば、ＡＡＡＡ、ＡＡＡＢ、
ＡＡＢＡ、ＡＢＡＡ、ＢＡＡＡ、ＡＡＢＢ、ＡＢＡＢ、
ＡＢＢＡ、ＡＡＢＣ、ＡＢＡＣ、ＡＢＣＡ、ＢＡＡＣ、
ＢＡＣＡ、ＢＣＡＡ）。Ａ、Ｂ、ＣおよびＤはサブ命令
が別のフィールド内のサブ命令と同一であるか異なって
いるかを識別するために用いられていることに留意され
たい。当業者においては、多数の異なったサブ命令Ａが
存在することが認識されるであろう。同様に、多くの異
なったサブ命令Ｂ、ＣおよびＤが存在する。

【００１５】より多くのサブ命令フィールドが存在する
アーキテクチャに対しては、さらなる冗長なサブ命令の
状況が存在する。いかなる所与のアーキテクチャに対し
ても、２^zより多い起こり得る状況は存在せず、ここで
「ｚ」はサブ命令フィールドの数である。すべての冗長
状況をカバーするために、「ｚ」までの制御ビットが存
在するであろうが、ここでｚはプロセッサアーキテクチ
ャにおいて許容されるサブ命令フィールドの最大数であ
る。

【００１６】ある実施例においては、すべてのそのよう
な状況は命令の各々に「ｚ」の制御ビットを含むことに
よりカバーされる。しかしながら、命令幅が増大するに
つれ、サブ命令共用のためにそのように多数の付加的な
制御ビットを加えることは望ましくないおそれがある。
特定的には、実務上何度も出現し繰返すサブ命令冗長性
の間にあるパターンが見られる傾向がある場合には、そ
のような多くのビットのコストは過剰に思われる。結果
として、好ましい実施例においては制御ビットの数を
「ｚ」未満に減じて、約２^zの予め規定された数のサブ
命令共用状況を扱うことを可能にする。

【００１７】サブ命令冗長性のパターンが変化する異な
ったアプリケーションに対して異なったプロセッサを設
計し得る。さらに、どの場合にサブ命令共用のためにサ
ブ命令冗長性をカバーするかは、プロセッサが対象とす
るアプリケーション（たとえば、画像処理アプリケーシ
ョン）に対して最も大きな影響を与えるよう、所与のプ
ロセッサに対して戦略的に選択される。

【００１８】いかなるサブ命令冗長性状況も潜在的にカ
バーされてプロセッサアーキテクチャ内に設計される
が、１つの方策においてはすべてまたはそれ以下のサブ
命令共用可能性がカバーされる。一実施例においてはサ
ブ命令共用は対応の機能処理単位に対して向けられる冗
長なサブ命令に対して提供される。機能処理単位はプロ
セッサの一部である。プロセッサは「ｚ」の機能処理単
位を含むが、ここで「ｚ」は１つの命令内のサブ命令の
最大数である。しかしながら、より特定的には、プロセ
ッサは複数のクラスタを含み、クラスタの各々は共通の
数の機能処理単位（ＦＰＵ）を含む。１つのクラスタ内
のＦＰＵの各々に対して、互いのクラスタ内に対応のＦ
ＰＵが存在する。対応のＦＰＵの各々は同じ機能を有す
る。たとえば、４つのＦＰＵの３つのクラスタがある
と、４組の対応するＦＰＵが存在する。１つの方策にお
いては、いずれか２つ以上の対応のＦＰＵの間のサブ命
令冗長性の並べ替えの各々がカバーされる。そのような
例においてはｚ＝７であり、命令ごとに７つの命令圧縮
制御ビットが存在する。これは１２の機能処理単位間
の、すべての可能性のあるサブ命令共用状況をカバーす
るための制御ビットの最大数（たとえば、１２）よりも
少ない。

【００１９】この発明の別の局面に従うと、クラスタの
各々における対応の機能処理単位に向けられる冗長なサ
ブ命令が圧縮される。特定的には、少なくとも２つのク
ラスタにおける対応の機能処理単位に対する１つの命令
内に同じサブ命令が存在すると、この発明にしたがっ
て、サブ命令の１つのコピーのみがストアされればよ
い。対応の機能処理単位に対する冗長なサブ命令は省か
れ、圧縮された命令をもたらす。そのような圧縮に対し
ては、特定のサブ命令を共用する冗長なサブ命令フィー
ルドを識別する命令圧縮制御ビットの対応する条件が存
在する。

【００２０】この発明の別の局面によると、ＶＬＩＷプ
ロセッサに対するコンピュータプログラムのコンパイル
の間に（たとえば、より高レベルの言語ソースコードま
たはアセンブラソースコードのアセンブリ）、命令圧縮
制御ビットは所与の命令に対して圧縮の各々を規定する
条件を特定するよう設定される。命令圧縮制御ビットを
含む命令は、圧縮されたまたは圧縮されない形式でメモ
リ内にストアされる。圧縮されない形式でストアされる
場合、命令はプロセッサのオンチップ命令キャッシュに
ストアされる前に圧縮される。したがって、命令は命令
のメインメモリへの記憶と命令のオンチップ命令キャッ
シュへの記憶との間のいずれかのステップで圧縮される
（たとえば、これは圧縮されてメインメモリで復元され
る；これは圧縮されて一次のキャッシュまたは二次のキ
ャッシュにストアされる；これはオンチップ命令キャッ
シュに移動するときに圧縮される）。

【００２１】この発明の別の局面によると、命令圧縮制
御ビットの条件は、どのように圧縮命令が実行のために
圧縮解除されるべきかを規定する。特に制御ビットは、
圧縮命令内の１つ以上のサブ命令が、ＶＬＩＷプロセッ
サの機能処理単位の間で同時実行のためにどのように共
用されるべきかを判断する。命令圧縮制御ビットの組
は、冗長的にではなくすぐに冗長な対応のサブ命令がス
トアされる１つ以上の圧縮条件を識別する。識別される
条件の各々は、少なくとも２つの対応の機能処理単位に
よって共用されるべきサブ命令に対応する。

【００２２】異なったクラスタの機能処理単位を、対応
する機能処理単位であると関連付け、かつそのような対
応の機能処理単位に向けられる冗長なサブ命令を圧縮す
ることの利点は、画像計算アルゴリズムの通常のプログ
ラム構造によるものである。出願人らは、同じサブ命令
が多数のクラスタにおいて用いられる画像計算ライブラ
リ関数のためのプログラムコードにおいて多くのタイト
ループを認識した。たとえば２つのクラスタを有するＶ
ＬＩＷプロセッサで実現される２Ｄ畳み込み関数に対し
ては、最も頻繁に用いられるサブ命令は、内積および、
内積の解の区分短縮（partitioned compaction）であ
る。これらのサブ命令のいずれかを実行するほとんどの
命令に対して、多くのクラスタが同じサブ命令を割当て
られていることが認識された。特定的にはそのような関
数のためのＭＡＰ１０００プロセッサに対するアセンブ
リコードにおいては、出願人らはタイトループプログラ
ムが１３３の命令のうち、両方のクラスタに対して全く
同じサブ命令（オペランドを含む）からなる６７の命令
を有することを認識した。したがって、対応の機能処理
単位に向けられるサブ命令の冗長性は重要な画像処理ア
ルゴリズムにおいて顕著に発生する。ＶＬＩＷ命令にお
ける冗長性をなくして、多数のクラスタにおいて同じサ
ブ命令が実行されるべきである場合に必要となる命令ビ
ットを少なくすることにより、プログラムサイズが減じ
られる。さらに、命令キャッシュ利用の効率性が向上
し、効率的な命令フェッチ帯域幅が増大する。

【００２３】オプコード圧縮実施例においては、命令帯
域幅は、命令の全体を圧縮する命令圧縮技術とは異なる
技術で減じられる。共通して用いられるオプコードの１
つ以上のテーブルをストアするために、オンチップラン
ダムアクセスメモリのある領域が割当てられる。命令内
の通常のオプコードは、テーブルとテーブルへのインデ
ックスとを識別するコードに置き換えられる。コードは
圧縮されないオプコードよりも少ないビットを含む。そ
の結果、命令が圧縮される。

【００２４】この技術はさまざまなプロセッサアーキテ
クチャに対して実現されるが、この技術は多数のオプコ
ード（すなわち、サブ命令の各々に対するもの）を含む
ＶＬＩＷ命令に対して特に有利である。一実施例におい
ては、命令の特別なコードビットの間の１つのビット
が、ＶＬＩＷ命令が圧縮されているかまたは圧縮されて
いないかを明示するために割当てられる。たとえば、あ
る実施例においてはＶＬＩＷ命令に対するオプコード圧
縮は全か無かである。すなわち、すべてのサブ命令オプ
コードが圧縮されるかいずれもされないかである。ＮＯ
Ｐ命令オプコードを圧縮するための十分な方法が存在す
るので、代替的な従来の方法を用いてこの発明の実施例
の圧縮命令形式の中のＮＯＰサブ命令を識別してもよ
い。

【００２５】この発明の１つの局面によると、共通して
用いられるオプコードのテーブルはリアルタイム処理の
間に動的に更新され、上書きされ、かつ置き換えられ
る。テーブルはアプリケーションプログラムの実行の間
にストアすることができる。動的更新の利点は、より小
さなテーブルサイズが効率的に命令帯域幅を減じること
である。ある実施例においては、テーブルは動的である
必要はなく、固定されていてもよい。広い範囲のアプリ
ケーションプログラムに対して最も頻繁に用いられるす
べてのオプコードをストアするために、そのようなテー
ブルは動的に更新されるテーブルよりも大きくなる。好
ましい動的な実施例に対しては、テーブルはアプリケー
ションにカスタマイズされ、プログラム設計の一部とな
る。たとえば、オプコードテーブルにストアされるべき
オプコードのそれぞれのテーブルを備えて異なったタス
クがプログラムされる。それぞれのテーブルは次いでタ
スクが切替わるときにロードされる。より小さな動的オ
プコードテーブルは、オプコードのより効率的な選択、
およびタスク切替えの間のテーブルローディングに対す
る低いオーバーヘッドの利点をもたらす。さらに、多数
のテーブルをストアするためにプロセッサチップにスペ
ースが割当てられる場合、１つのテーブルがアクティブ
にされ別のものはインアクティブにされるために、テー
ブルローディングオーバーヘッドはさらに減じられる。

【００２６】ある実施例においては、所与のオプコード
テーブルにおける１つ以上の特定のエントリが更新され
る。テーブルインデックスを用いてオプコードテーブル
内のどこで更新された値を書込むべきかを識別する特定
の命令が含まれる。さらにある実施例にＣＩＳＣ様の命
令が含まれ、データをメモリからより早くオプコードテ
ーブルに転送し、テーブルをよりコンパクトにストアす
る。

【００２７】ある実施例においては、オプコードテーブ
ルは不揮発性メモリから関数コール内の初期にプレロー
ディングされる。さらに、以前のテーブルに対するポイ
ントが維持されて、それにより関数が完了し処理がコー
リングルーチンに戻った後で、コーリングルーチンに対
するオプコードテーブルが復元される。

【００２８】この発明のこれらおよび他の局面ならびに
利点は、添付の図面と併せて以下の詳細な説明を参照す
ることにより、よりよく理解されるであろう。

【００２９】

【特定の実施例の説明】概要 図１は、超長命令語（ＶＬＩＷ）プロセッサのためのプ
ログラムコンパイルおよび記憶のブロック図を示す。
「超長命令語」ＶＬＩＷという用語は、コンピュータシ
ステムおよびプログラムアーキテクチャ、並列処理およ
び画像処理の分野における用語であり、これは一般的に
プロセッサが典型的には、６４ビット以上であり多数の
サブ命令からなる命令を扱うことができるアーキテクチ
ャを指す。

【００３０】プログラムエンジニアはソースコード１２
を準備し、テストし、かつデバッグする。ソースコード
１２はアセンブラ言語または高階プログラミング言語で
書かれる。ソースコードは次いでコンパイラ／アセンブ
ラ１４によってコンパイル／アセンブルされ、マシンコ
ード１６をもたらす。マシンコード１６は、マシンコー
ド１６を実行すべきプロセッサを有するコンピュータの
メモリ１８にストアされる。

【００３１】図２を参照すると、ホストコンピュータ１
０は、超長命令語（ＶＬＩＷ）プロセッサ２０、命令キ
ャッシュ２２、およびメインメモリ２４を含む。好まし
い実施例においては命令キャッシュ２２はプロセッサ２
０の一部である（オンチップに位置する）。メインメモ
リは、メモリ１８であるか、またはメモリ１８からコン
ピュータプログラムマシンコード１６を受取る。図３を
参照すると、典型的なＶＬＩＷプロセッサ２０アーキテ
クチャは、機能処理単位（ＦＰＵ）２８の複数のクラス
タ２６を含む。クラスタ２６の各々は、共通の数の機能
処理単位２８を含む。その結果、異なったクラスタ２６
の機能処理単位２８に１対１対応が存在する。図３は、
クラスタごとに「ｍ」個の機能処理単位の「ｎ」個のク
ラスタを有する汎用アーキテクチャを示す。第１のクラ
スタは、（１，１）から（１，ｍ）までの機能処理単位
を有する。第２のクラスタは、（２，１）から（２，
ｍ）までの機能処理単位を有する。ｎ番目のクラスタ
は、（ｎ，１）から（ｎ，ｍ）までの機能処理単位を有
する。したがって、ｎ＊ｍ個の機能処理単位が存在す
る。クラスタ２６ごとに、専用レジスタファイル２７が
存在する。ｎ、ｍ、およびｎ＊ｍの値は、プロセッサ２
０アーキテクチャによって決定された予め規定された数
である。そのような値は異なった実施例に対して変化し
得る。ｎ＊ｍの値は、ｎ＊ｍ機能処理単位を有するプロ
セッサに対するＶＬＩＷ命令内に含まれ得るサブ命令の
最大数に相当する予め規定された数である。

【００３２】図４を参照すると、プロセッサ２０に対す
る命令形式３０は最大ｎ＊ｍ個のサブ命令フィールド３
２を含む。サブ命令フィールド３２の各々の内容は処理
のために対応の機能処理単位２８に経路制御される。す
べてのｎ＊ｍ個のサブ命令フィールドが埋められた命令
に対しては、サブ命令はｎ＊ｍ個の機能処理単位２８の
各々に経路制御される。典型的には、すべてのｎ個のク
ラスタ２６に対して１つのみのプログラムカウンタが存
在する。その結果、機能処理単位は典型的にはシンクロ
ナスに動作して所与の命令のサブ命令を同時実行する。

【００３３】サブ命令フィールド３２ｉが空である場
合、命令３０は従来の技術を用いて圧縮される。その結
果、命令によって占有されていたメモリスペースが減じ
られる。この発明は、多数のクラスタ２６の対応の機能
処理単位２８に対して冗長なサブ命令が存在する場合命
令サイズを圧縮するさらなる技術に関する。特に、画像
計算アルゴリズムのタイトループにおいては、同じサブ
命令が多数のクラスタにおいて実行されるのが認識され
ている。従来的には、サブ命令はサブ命令フィールド３
２の各々で繰返され、命令キャッシュ２０のメモリスペ
ースの非効率的な使用およびメモリ転送帯域幅の非効率
的な適用をもたらした。この発明の局面による圧縮され
た命令形式においては、サブ命令が多数の機能処理単位
２８の間で共用される。

【００３４】ＶＬＩＷ圧縮命令形式 図５を参照すると、それぞれのサブ命令３６をストアす
る「ｎ×ｍ」個のサブ命令フィールド３２を含む、圧縮
されない命令３４の例が示される。あるサブ命令フィー
ルド３２は空白であり得る（たとえば、フィールド３２
（２，１））。あるサブ命令フィールドは別のサブ命令
フィールドど同じサブ命令を含み得る。サブ命令フィー
ルド３２の各々は、特定のクラスタ２６の特定の機能処
理単位２８に関連付けられる。示される例においては、
サブ命令フィールド（１，１）から（１，ｍ）までは、
クラスタ１のそれぞれの機能処理単位（１，１）から
（１，ｍ）までにに関連付けられる。サブ命令フィール
ド（２，１）から（２，ｍ）まではクラスタ２のそれぞ
れの機能処理単位（２，１）から（２，ｍ）までに関連
付けられる。サブ命令フィールドの各々は同様に、サブ
命令フィールド（ｎ，１）から（ｎ，ｍ）までがクラス
タｎのそれぞれの機能処理単位（ｎ，１）から（ｎ，
ｍ）までに関連付けられる。

【００３５】クラスタ１からｎの各々に対する機能処理
単位（＿，１）はここで対応の機能処理単位と呼ばれる
ことに留意されたい。特に、それらは多数のクラスタの
各々の、対応の第１の機能処理単位と呼ばれる。対応の
機能処理単位（＿，ｉ）によって処理するための所与の
命令内に同じサブ命令が含まれている場合、命令形式は
圧縮されて冗長性をなくす。同じサブ命令が含まれてい
るが、対応しない機能処理単位（＿，ｉ）および（＿，
ｊ）へのものである場合、冗長性は対処されないことに
留意されたい（すなわち、命令形式は必ずしも圧縮され
なくてもよい）。ある実施例においてはこれらの冗長性
もまた対処されるが、好ましい実施例においてはこれら
は無視される。そのような冗長性が無視されるのは、こ
れらが対応の機能処理単位に向けられるサブ命令の間の
冗長性の対処における利得に匹敵するほどの、効率性に
おける利得をもたらさないためである。

【００３６】図６を参照すると、空白フィールドが省か
れた従来の圧縮された形式３４′で例示的な命令３４が
示される。圧縮されない形式において空白フィールドが
生じるであろう位置はアスタリスク（「＊」）で示す。

【００３７】図７を参照すると、この発明の局面に従っ
た圧縮された形式３４″における例示的な命令３４が示
される。圧縮された形式において、命令圧縮制御ビット
の組３７のための領域と、１つ以上の、好ましくは空で
はないサブ命令フィールドとが存在する。同じサブ命令
をストアする対応のＦＰＵ（＿，ｉ）に対するサブ命令
フィールドは、対応の機能処理単位のうちの１つのみに
対するサブ命令を含むよう減じられる。そのような対応
の機能処理単位はサブ命令を共用する。

【００３８】示される例示的な命令に関しては、第１の
クラスタおよびｎ番目のクラスタの両方の第２の機能処
理単位に向けられるサブ命令は、共通のサブ命令を有す
ることに留意されたい。これらのＦＰＵ（１，２）およ
び（ｎ，２）は対応の機能処理単位である。したがっ
て、冗長なサブ命令は省かれる。さまざまな実施例にお
いて冗長なサブ命令は第１の発生、第２の発生または他
の発生において省かれる。示される実施例においては第
１の発生以外のすべてが省かれる。圧縮されない形式に
おいて、省かれた冗長フィールドが発生するであろう位
置はダブルアスタリスク（「＊＊」）で示す。また、空
のサブ命令フィールドもまた圧縮されていることに留意
されたい。さまざまな実施例において、従来の圧縮技術
もまた実現されるか否かに応じて空のフィールドは圧縮
されても圧縮されなくてもよい。

【００３９】また、サブ命令フィールド３２（１，ｍ）
および３２（２，２）の各々は共通のサブ命令「Ｃ」を
有することに留意されたい。ある実施例においては圧縮
動作が行なわれてこの冗長を避ける。しかしながら、こ
のような冗長は頻繁には発生しないことが見出されたの
で、好ましい実施例においてはこの冗長は「そのまま」
残される。同様に、サブ命令フィールド３２（ｎ，１）
および３２（ｎ，３）もまた共通のサブ命令「Ｅ」を有
する。これらは共通のクラスタ内でＦＰＵに対して向け
られる。ある実施例においては、圧縮動作が行なわれて
この冗長性を避ける。しかしながら、このような冗長は
頻繁には発生しないことが見出されたので、好ましい実
施例においてはこの冗長は「そのまま」残される。

【００４０】命令圧縮制御ビットの組３７は、対応の機
能処理単位がサブ命令を共用するべき起こり得る条件の
各々を識別するために十分なビットを含む。たとえば、
クラスタごとに「ｍ」個のＦＰＵの２つのクラスタがあ
る場合、組３７は「ｍ」個の制御ビットを含む。クラス
タごとに２つのＦＰＵの「ｎ」個のクラスタがある場
合、組３７は「ｎ」個の制御ビットを含む。クラスタご
とに「ｍ」個のＦＰＵの「ｎ」個のクラスタを有するア
ーキテクチャにおいては、ベストモードの実施例におけ
る組３７はｎ＋ｍ個のの制御ビットを含むが、ここでｎ
＞２であり、ｍ＞２である。他の実施例においては制御
ビットの数は変化し得る。以下のテーブル１は、クラス
タごとに２つの機能処理単位の２つのクラスタが存在す
るアーキテクチャに対するビット符号化を示す。そのよ
うなアーキテクチャに関しては、組３７内に２つの制御
ビットが存在する。

【００４１】テーブル１：制御ビット符号化 ００ サブ命令共用なし ０１ 圧縮された形式における第１のサブ命令がＦＰＵ
（＿，１）によって共用される １０ 圧縮された形式における第２のサブ命令がＦＰＵ
（＿，２）によって共用される １１ 圧縮された形式における第１のサブ命令がＦＰＵ
（＿，１）によって共用され、かつ圧縮された形式にお
ける第２のサブ命令がＦＰＵ（＿，２）によって共用さ
れる

【００４２】以下のテーブル２は、クラスタごとに３つ
の機能処理単位の２つのクラスタが存在するアーキテク
チャのためのビット符号化を示す。そのようなアーキテ
クチャに対しては、組３７内に３つの制御ビットが存在
する。

【００４３】テーブル２：制御ビット符号化 ０００ サブ命令共用なし ００１ 圧縮された形式における第１のサブ命令はＦＰ
Ｕ（＿，１）によって共用される ０１０ 圧縮された形式における第２のサブ命令はＦＰ
Ｕ（＿，２）によって共用される ０１１ 圧縮された形式における第１のサブ命令はＦＰ
Ｕ（＿，１）によって共用され、圧縮された形式におけ
る第２のサブ命令はＦＰＵ（＿，２）によって共用され
る １００ 圧縮された形式における第３のサブ命令はＦＰ
Ｕ（＿，３）によって共用される １０１ 圧縮された形式における第１のサブ命令はＦＰ
Ｕ（＿，１）によって共用され、圧縮された形式におけ
る第３のサブ命令はＦＰＵ（＿，３）によって共用され
る １１０ 圧縮された形式における第２のサブ命令はＦＰ
Ｕ（＿，２）によって共用され、圧縮された形式におけ
る第３のサブ命令はＦＰＵ（＿，３）によって共用され
る １１１ 圧縮された形式における第１のサブ命令はＦＰ
Ｕ（＿，１）によって共用され、圧縮された形式におけ
る第２のサブ命令はＦＰＵ（＿，２）によって共用さ
れ、圧縮された形式における第３のサブ命令はＦＰＵ
（＿，３）によって共用される

【００４４】さまざまな実施例において、２つ以上の対
応のＦＰＵ（＿，ｉ）の間で共用されるべきサブ命令が
存在する潜在的な圧縮条件の各々を識別するために実現
し得るさまざまな符号化方策が存在する。

【００４５】命令ごとに大量の制御ビットを加えること
は望ましくないおそれがあるので、圧縮条件のサブセッ
トは減じられた数の制御ビットによって識別され得る。
たとえば、クラスタごとに２つのＦＰＵを備えた４つの
クラスタアーキテクチャにおいては、４つの制御ビット
を上に明記されるものと同じ方法で用いるか、または３
つの制御ビットを以下のテーブル３に説明されるように
用いることができる。

【００４６】テーブル３：制御ビット符号化 ０００ サブ命令共用なし ００１ 圧縮された形式における第１のサブ命令がすべ
てのＦＰＵ（ｉ，１）によって共用される、ｉ＝１，４ ０１０ 圧縮された形式における第２のサブ命令がＦＰ
Ｕ（ｉ，２）によって共用される、ｉ＝１，４ ０１１ 圧縮された形式における第１のサブ命令がＦＰ
Ｕ（ｉ，１）によって共用され、圧縮された形式におけ
る第２のサブ命令がＦＰＵ（ｉ，２）によって共用され
る、ｉ＝１，４ １００ 圧縮された形式における第１のサブ命令がＦＰ
Ｕ（１，１）、（３，１）によって共用され、圧縮され
た形式における第２のサブ命令がＦＰＵ（１，２）、
（３，２）によって共用され、圧縮された形式における
第３のサブ命令がＦＰＵ（２，１）、（４，１）によっ
て共用され、圧縮された形式における第４のサブ命令が
ＦＰＵ（２，２）、（４，２）によって共用される １０１ 圧縮された形式における第１のサブ命令はＦＰ
Ｕ（１，１）、（２，１）によって共用され、圧縮され
た形式における第２のサブ命令がＦＰＵ（１，２）、
（２，２）によって共用され、圧縮された形式における
第３のサブ命令がＦＰＵ（３，１）、（４，１）によっ
て共用され、圧縮された形式における第４のサブ命令が
ＦＰＵ（３，２）、（４，２）によって共用される １１０ 圧縮された形式における第１のサブ命令がＦＰ
Ｕ（１，１）、（２，１）によって共用され、圧縮され
た形式における第２のサブ命令がＦＰＵ（１，２）、
（２，２）によって共用され、第３から第６までのもの
は共用されない １１１ 第１から第４のものは共用されず、圧縮された
形式における第５のサブ命令がＦＰＵ（３，１）、
（４，１）によって共用され、圧縮された形式における
第６のサブ命令はＦＰＵ（３，２）、（４，２）によっ
て共用される

【００４７】当業者においては、異なった符号化方策を
実現して、さまざまなサブ命令共用条件を識別し得るこ
とを理解するであろう。異なった復号化アーキテクチャ
が異なった符号化方策に付随し、所望のサブ命令共用方
策を実現するであろう。

【００４８】サブ命令共用 図９を参照すると、制御ビットの組を復号化し、かつも
しサブ命令が存在すればそれらのうちいずれがＶＬＩＷ
プロセッサの対応のＦＰＵの間で共用されるべきかを判
断するための例示的な多重化方策が示される。一実施例
においては、プロセッサ２０はそのような符号化および
サブ命令共用を行なうための論理を含む。示される実施
例においては、クラスタごとに２つの機能単位２８の２
つのクラスタ２６が存在する。ＶＬＩＷ命令４２は、命
令キャッシュ２２から検索され、制御ビットの組３７の
条件に基づいてパーズされる。そのような実施例に対す
るＶＬＩＷ４２命令は、２つ、３つまたは４つのサブ命
令フィールド３２を含む。

【００４９】マルチプレクサ４４は、第２のクラスタの
第１の機能単位を命令４２の第１のサブ命令フィールド
および第３のサブ命令フィールドに結合する。マルチプ
レクサ４６は、第２のクラスタの第２の機能単位を命令
４２の第２のサブ命令フィールドおよび第４のサブ命令
フィールドに結合する。上述のテーブル１における復号
化方策に従うと、命令４２は組３７が００の符号化条件
を有している場合に４つのサブ命令を含む。サブ命令の
各々は別々のＦＰＵに経路制御される。命令４２は、組
３７が０１または１０の符号化条件を有する場合に３つ
のサブ命令を含む。０１に符号化された場合、マルチプ
レクサ４４は第１のサブ命令を選択する。こうして、ク
ラスタ１および２の第１の機能単位は第１のサブ命令を
共用する。第２のサブ命令は第１のクラスタの第２のＦ
ＰＵに向かう。第３のサブ命令はシフトされてマルチプ
レクサ４６に入り、これはそのような第３のサブ命令を
第２のクラスタの第２のＦＰＵによって処理するために
選択する。

【００５０】組４６が１０に符号化される場合、第１の
サブ命令は第１のクラスタの第１のＦＰＵに向かい、第
２のサブ命令は第１のクラスタの第２のＦＰＵに向か
う。マルチプレクサ４４は第３のサブ命令を選択し、そ
れにより第３のサブ命令は第２のクラスタ内の第１のＦ
ＰＵに向かう。マルチプレクサ４６は第２のサブ命令を
選択し、それにより第２のサブ命令は第１のクラスタの
第２のＦＰＵと第２のクラスタの第２のＦＰＵとによっ
て共用される。

【００５１】命令４２は、組３７が１１の符号化条件を
有する場合に２つのサブ命令を含む。そのような場合に
おいてはマルチプレクサは第１のサブ命令をパスし、そ
れにより第１のサブ命令は第１のクラスタの第１のＦＰ
Ｕと第２のクラスタの第１のＦＰＵとによって共用され
る。同様に、マルチプレクサ４６は第２のサブ命令をパ
スし、それにより第２のサブ命令は第１のクラスタの第
２のＦＰＵと第２のクラスタの第２のＦＰＵとによって
共用される。

【００５２】図１０（Ａ）から（Ｅ）を参照すると、サ
ブ命令共用は、クラスタごとにｎ＝２クラスタおよびｍ
＝２ＦＰＵを有するプロセッサ上でさまざまな命令４２
Ａから４２Ｅに対して比較される。命令の各々は４つま
でのサブ命令３６を含む。４つのサブ命令はサブ命令が
視覚的にそのデスティネーションＦＰＵと相関するよう
に、２つの行に構成される。特定的には、一番上の行の
サブ命令は第１のクラスタの第１および第２のＦＰＵ
（１，１）、（１，２）のそれぞれに向けられるのに対
し、一番下の行のサブ命令は第２のクラスタの第１およ
び第２のＦＰＵ（２，１）、（２，２）のそれぞれに向
けられる。さらに、命令ビットサイズはサブ命令サイズ
に対して等しい３２ビットであると示される。命令４２
ごとに示されるのは、意図された動作４８（左側）、Ｎ
ＯＰ圧縮のみを備えた命令５０（中央）およびサブ命令
共用のために圧縮された命令４２（右側）である。

【００５３】以下のテーブル４は、サブ命令共用を備え
るかまたはサブ命令共用を備えない、異なった命令の場
合を指定するために用いられるいくつかの命令ビットを
要約する。Ｎは命令内での空ではないサブ命令の数であ
り、もとの圧縮された命令は命令圧縮の後で３２×Ｎビ
ット長さになるであろう。しかしながら、サブ命令共用
があると、命令内に冗長度に応じて異なった長さが生じ
得る。たとえば、制御ビット３７が００（すなわち、サ
ブ命令共用なし）であれば、その命令に対しては３２×
Ｎ＋２ビットであり、もとの命令と比較すると２ビット
のオーバーヘッドを含む。しかしながら、制御ビット３
７が０１または１０であれば、サブ命令共用によって１
つのサブ命令フィールドが省かれる。結果は３２×（Ｎ
−１）＋２ビットであり、これはこの命令に対して３０
ビットを節約する。この場合に関しては、制御ビットは
１１であり、２つのサブ命令フィールドが省かれ、ビッ
トの数は３２×（Ｎ−２）＋２であり、この命令に対し
て６２ビットを節約する。

【００５４】

【表１】

【００５５】いくつかのタイトループルーチン（２Ｄ畳
み込み、２Ｄ復号ＦＦＴおよびアフィンワーピング（af
fine warping））がＭＡＰ１０００プロセッサのために
アセンブリ言語で書かれた、画像計算プログラムにおけ
るサブ命令共用の実際の効果が研究された。ＭＡＰ１０
００はクラスタごとに２つのＦＰＵの２つのクラスタを
有する。サブ命令の各々が３２ビット幅であると想定し
て、タイトループ内の命令の数およびそれらの冗長特性
は以下のテーブル５にリストされる。２Ｄ畳み込みに関
しては、サブ命令共用によって節約することのできる命
令ビットの数は−２×４８＋３０×４０＋６２×４５＝
３８９４ビットであると計算された。１３３の命令内
で、畳み込みタイトループにおける空ではないサブ命令
の総数は３３７であった。よって、もとのプログラムサ
イズは３３７×３２＝１０７８４ビットである。こうし
て、サブ命令共用結果はテーブル６に示すようにタイト
ループプログラムサイズにおいて３６．１％の減少をも
たらした。同様に、２Ｄ復号ＦＦＴおよびアフィンワー
ピングタイトループは、それぞれプログラムサイズにお
いて２３．９％および４１．９％の減少を示した。

【００５６】

【表２】

【００５７】上述のプログラムサイズ減少はタイトルー
プに対してのみであることに留意されたい。コール機能
を併せて考察する場合、サブ命令共用の結果はより長い
ものになるであろう。しかしながら、結果はそれでも非
常に顕著である。たとえば、５１２×５１２の８ビット
画像を読込み、２Ｄ畳み込みタイトループをコールし、
メモリに出力画像を書込むアプリケーションプログラム
を考察すると、約１００キロバイトを占有する。サブ命
令共用によって達成されるプログラムサイズ減少の合計
は０．５％未満である。しかしながら、タイトループ外
のプログラムのほとんどが一度のみ実行されるのに対
し、タイトループは何度も反復されるので、ほとんどの
プログラム実行時間は実際、タイトループ内で使用され
る。マップ１０００での１５×１５核を備える２Ｄ畳み
込みの場合においては、タイトループ実行時間は実行時
間の合計の８９％以上を占める。したがって、タイトル
ープを利用可能な命令キャッシュに適合させることは、
全体のプログラムサイズを減少させることよりも重要で
ある。さらに、より洗練されたタイトループ（こうして
命令のためにより多くのビットを必要とする）が開発さ
れ、および／または多数のタイトループが組合されて新
しい高レベルタイトループを生成する場合、個々のタイ
トループのサイズができるだけ小さくされ、それにより
新しいタイトループが命令キャッシュスラッシングを引
起さない、すなわちタイトループを反復する間に過剰な
命令キャッシュミスを起こさないことが望ましい。

【００５８】冗長なサブ命令を識別し共用するための方
法 図１１を参照すると、サブ命令共用機会を識別するため
のフローチャート６０は、所与の命令のサブ命令が、サ
ブ命令共用条件が存在するか否かを判断するために比較
されるステップ６２を含む。一実施例においては、多数
のクラスタの１つ以上の対応の機能処理単位（＿，ｉ）
に対して現われるいずれのサブ命令も共用されるべきで
ある。別の実施例においてはより限定された条件の組が
特定の設計に従って指定される。たとえば上述のテーブ
ル３は、限定された条件の組の例を挙げる。ステップ６
４において、命令圧縮制御ビットの組３７はサブ命令共
用条件の各々を識別するために設定される。その後に命
令はステップ６８においてメモリにストアされる。ある
実施例においては命令は圧縮されない形式でストアされ
る（または、サブ命令共用圧縮なしにＮＯＰ圧縮などの
従来の圧縮技術のみを用いた形式でストアされる）。別
の実施例においては、命令はステップ６６でサブ命令が
共用されるべき冗長なサブ命令を省く。

【００５９】サブ命令共用のために冗長性を除去するこ
となく命令がメモリ内にストアされる実施例の場合は、
命令を圧縮する、またはさらに圧縮するための命令が別
の時点で実行される。図１２を参照すると、フローチャ
ート６９のステップ７０において、命令圧縮制御ビット
の組３７がサブ命令共用条件を識別するためにテストさ
れる。組３７の符号化条件に従って、ステップ７２にお
いて１つ以上のサブ命令が命令形式から削除される。削
除されたサブ命令は冗長なサブ命令である。ＦＰＵによ
って共用されるべきである同一のサブ命令が残留する。
その結果、圧縮された命令または、さらに圧縮された命
令がもたらされる。そのような結果として生じる圧縮さ
れた命令は命令キャッシュ２２、一次キャッシュまたは
メインメモリ２４に経路制御される。命令のサイズを減
じることにより、命令キャッシュにおいて要求されるス
ペースおよびデータをキャッシュに移動させるために必
要となる時間が減じられる。フローチャート６９の方法
はさまざまな実施例において、命令がメインメモリ２４
から命令キャッシュ２２（図２を参照）に移動される場
合に、または別の時点で行われる。

【００６０】図１３を参照すると、命令圧縮制御ビット
の組３７を復号化するための方法のフローチャート７４
は、さまざまなサブ命令共用条件に対して制御ビットを
テストするためのステップ７６を含む。ステップ７８に
おいて、圧縮命令４２はパーズされてサブ命令をデステ
ィネーションであるＦＰＵ２８に経路制御する。サブ命
令共用条件が存在する場合、サブ命令は複数の対応の機
能処理単位に経路制御される。

【００６１】代替的な実施例 対応のＦＰＵの間での冗長なサブ命令について、サブ命
令を共用するケースを説明してきたが、ある実施例にお
いては同様に包含され得る冗長なサブ命令のさらなる状
況が存在する。命令が「ｐ」個のサブ命令フィールドを
含む汎用アーキテクチャに関しては、冗長なサブ命令が
ない状況と、ある程度の冗長がサブ命令の間に存在す
る、２^p-1よりも少ない状況とが存在する。ｐ＝８のサ
ブ命令フィールドが存在するアーキテクチャに関して
は、２⁸＝２５６より少ない状況が存在する。いくつか
の状況は同じ結果を表わすので、状況の数はやや２５６
よりも少なくなる。しかしながらすべてのそのような状
況をカバーするために、命令圧縮制御ビットの組３７内
には「ｐ」個の制御ビットが存在する。こうして、一実
施例においては命令ごとに「ｐ」個の制御ビットが含ま
れる。

【００６２】しかしながら、命令幅が増大する場合、サ
ブ命令共用のために非常に多くの付加的な制御ビットを
加えることは望ましくないおそれがある。特に、実務上
何度も繰返し出現する、サブ命令の間の冗長性のパター
ンが存在する傾向がある場合、非常に多くのビットのコ
ストは過剰であると思われるであろう。結果として、好
ましい実施例においては、予め定められた数の起こり得
る２^pのサブ命令共用状況を処理するための制御ビット
の数がｐ以下に減じられる。異なったアプリケーション
に対しては異なったプロセッサが設計され、サブ命令冗
長のパターンも変化する。さらに、サブ命令共用の対象
となるサブ命令冗長のケースもまた、所与のプロセッサ
に対して戦略的に選択され、プロセッサが標的とするこ
れらのアプリケーション（たとえば、画像処理アプリケ
ーション）に対して最大の効果をもたらすようにされ
る。上のセクションで説明された好ましい実施例は、一
般的な画像処理関数の戦略的に重要なタイトループにお
いて発生することが見出されたサブ命令共用シナリオ状
況に関連する。

【００６３】オプコード圧縮−概要 図１４を参照すると、この発明の実施例に従った１つ以
上のオプコード圧縮テーブルを組入れたアプリケーショ
ンプログラムを処理するためのホストシステム１１１
は、プロセッサ２０２、キャッシュメモリ２２、不揮発
性メインメモリ２４、およびユーザインターフェイス１
２０を含み、これらは１つ以上のバス構造１２２によっ
て相互接続される。ユーザインターフェイス１２０はデ
ィスプレイ装置１２４、キーボード１２６およびポイン
ト／クリック装置１２８を含む。

【００６４】この発明のオプコード圧縮技術は、超長命
令語（「ＶＬＩＷ」）プロセッサおよびスーパースカラ
プロセッサを含むさまざまなホストプロセッサ２０上で
実現され得る。例示的なＶＬＩＷプロセッサは、テキサ
ス州ダラスのテキサス・インスツルメント（Texas Inst
ruments）によって製造されるＴＭＳ３２０Ｃ６ｘおよ
び、日本国東京の株式会社日立製作所とカリフォルニア
州キャンベルのイクエータ・テクノロジー（Equator Te
chnologies）とによって製造されるＭＡＰ１０００を含
む。各々はデータストリームと命令ストリームとの両方
の大量の並列性をサポートし、並列またはパイプライン
化されたプログラム命令の実行を実現する。例示的なス
ーパースカラプロセッサは、ニューヨーク州のインター
ナショナル・ビジネス・マシーンズ（International Bu
siness Machines）およびイリノイ州シカゴのモトロー
ラ・コーポレーション（Motorola Corporation）によっ
て製造されるPowerPC６０４、カリフォルニア州パロア
ルトのインテル・コーポレーション（Intel Corporatio
n）によるペンティアム（Ｒ）ＩＩプロセッサ、ＭＩＰ
Ｓ Ｒ１０００００、マサチューセッツ州メイナードの
デジタル・イクイップメント・コーポレーション（Digi
tal Equipment Corporation）によるDEC Alpha２１２６
４、カリフォルニア州パロアルトのヒューレット・パッ
カード（Hewlett-Packard）によって製造されるＰＡ−
ＲＩＳＣ ８０００ファミリーのプロセッサ、およびカ
リフォルニア州サニーベイルのサン・マイクロシステム
ズ（Sun Microsystems）によって製造されるUltraＳＰ
ＡＲＣ−ＩＩを含む。

【００６５】図１５は、単一チップ上に実現された例示
的なプロセッサ２０を示す。示されるのはメディア加速
プロセッサ（media accelerated processor）１０００
（ＭＡＰ１０００）のプロセッサアーキテクチャであ
る。ＭＡＰ１０００プロセッサは、直接メモリアクセス
（ＤＭＡ）コントローラ１２９、データキャッシュ１３
０、命令キャッシュ１３２およびクラスタ２６と呼ばれ
る並列実行単位を含む。そのような構成要素の各々は共
通のチップ上に存在する。クラスタ２６の各々は１つ以
上の機能単位２８、たとえば整数演算ならびに論理単位
および整数浮動小数点グラフィック演算ならびに論理単
位を有する。また、クラスタ２６の各々はいくつかの汎
用レジスタ、いくつかの汎用レジスタ、いくつかの１ビ
ットプレディケートレジスタおよび多数の専用レジスタ
を含む。

【００６６】命令形式 図１６を参照すると、従来のｋビットの、圧縮されない
ＶＬＩＷ命令形式は、オプコード１４２、１つ以上のソ
ースオペランドフィールド１４４およびデスティネーシ
ョンオペランドフィールド１４６を含む。オプコード１
４２の各々は、いくつかのサブ命令１４８に区分けされ
る。クラスタ２６の各々の機能単位２８ごとに１つのサ
ブ命令が存在する。たとえばクラスタごとに２つの機能
ユニットの２つのクラスタを有するＶＬＩＷプロセッサ
２０に関しては、命令は４つのサブ命令１４８を含む。
ソースオペランドフィールド１４４およびデスティネー
ションオペランドフィールド１４６は同様にサブワード
１５０に区分けされる。

【００６７】図１７を参照すると、ＶＬＩＷ命令のオプ
コードが、圧縮されない形式１５２およびＮＯＰサブ命
令オペランドが圧縮される形式１５４で示される。ＮＯ
Ｐサブ命令を圧縮するための１つの従来の方法による
と、残りのサブ命令の配置を識別する（よって、ＮＯＰ
サブ命令の位置をも識別する）マスクワード１５６が生
成される。

【００６８】図１８Ａおよび図１８Ｂを参照すると、Ｖ
ＬＩＷ命令のオプコードが２つのオプコード１５８、１
６０に対して圧縮されない形式および圧縮された形式で
示される。オプコード１５８においては、ＮＯＰサブ命
令は存在しない。圧縮されたオプコード形式１６２にお
いては、サブ命令オペランドは減じられたビット長さに
圧縮される。特定的には、サブ命令１４８の各々はオプ
コードがコード１６３と置換えられるが、これはオプコ
ードルックアップテーブル１６６（図１９を参照）へ索
引付けするか、そうでなければオプコードルックアップ
テーブル１６６に対して、および／またはこの中でポイ
ントする。オプコード１６０においてはＮＯＰサブ命令
が存在する。好ましい実施例においてはＮＯＰサブ命令
は、従来の圧縮方法のいずれかを用いて圧縮される。次
いで残りのサブ命令１４８オペランドが圧縮されて圧縮
されたオペランド形式１６４を達成する。再び、残りの
特定のサブ命令オペランドはコード１６３と置換えら
れ、これはオプコードルックアップテーブル１６６（図
１９を参照）へ索引付けするか、そうでなければオプコ
ードルックアップテーブル１６６に対して、および／ま
たはこの中でポイントする。

【００６９】通常の動作の間に、ＶＬＩＷ命令のすべて
がオプコード圧縮された形式１６２／１６４を示すわけ
ではない。いくつかのオプコードは圧縮されず、または
ＮＯＰサブ命令だけが圧縮される。しかしながら、ＶＬ
ＩＷ命令のために好ましい実施例においては、オプコー
ド圧縮方策を示すべきであるいかなるオプコード１４２
も、すべてのサブ命令オプコードを圧縮される。しかし
ながら、ＮＯＰオプコードは好ましくは異なった態様で
圧縮されることに留意されたい。また、ある実施例にお
いては、サブ命令の共用はさらに、圧縮されるべきサブ
命令オプコードの数を減らすことに留意されたい。

【００７０】上のセクションにおいて、サブ命令共用と
呼ばれる圧縮技術について説明した。その技術による
と、オプコードが冗長なサブ命令を含む特定の場合が、
サブ命令共用の対象となる。特定的には、圧縮されたサ
ブ命令共用形式において冗長なサブ命令オペランドがよ
り少ない回数で発生する（たとえば、１回発生する）よ
う、冗長性が除去される。そのような技術に対する命令
形式は、サブ命令オペランドに加えて１組の制御ビット
を含む。制御ビットは、サブ命令共用の特別な場合を識
別する（たとえば、クラスタごとの機能単位１が、圧縮
サブ命令共用オプコードの特定のサブワードにストアさ
れるものと同じサブ命令のコピーを受取る）。サブ命令
共用のいくつかの場合をここで説明する。

【００７１】オプコード１４２が圧縮された形式である
か圧縮されない形式であるかを識別するために、制御ビ
ット６５がすべてのオプコード形式に対して用いられ
る。制御ビットは、サブ命令オペランドの圧縮が実行さ
れていることを示す１つの値を有し、実行されていない
（しかしながらＮＯＰ圧縮およびサブ命令共用はやはり
実行されているかも知れない）ことを示す別の値を有す
る。

【００７２】図２０を参照すると、オプコード形式は圧
縮されない形式１４２およびさまざまな圧縮タイプの形
式において示される。形式１５４はＮＯＰ圧縮された形
式１５４におけるオプコードに対応する。形式１７０
は、ＮＯＰ圧縮およびサブ命令共用を示すオプコードに
対応する。形式１７２は、ＮＯＰ圧縮、サブ命令共用お
よびオプコード圧縮の各々を示すオプコードに対応す
る。動作の間に、プロセッサ２０はこれらの形式のいず
れかまたはすべてを、別々にまたは累積して実行し得
る。

【００７３】図２１（Ａ）を参照すると、たとえばＲＩ
ＳＣおよび／またはスーパースカラアーキテクチャを有
するプロセッサ２０に対して実現される単一命令形式８
０が示される。命令は、オプコード８２、１つ以上のソ
ースオペランドフィールド８４およびデスティネーショ
ンオペランドフィールド８６を含む。この発明は、デー
タオペランドに対して圧縮方策が実施されているか否か
に拘らずオプコード圧縮に関連するので、オプコードの
圧縮についてのみここで説明する。図２１（Ｂ）の圧縮
オプコード形式９２においては、オプコードは減じられ
たビット長さ形式に圧縮される。特定的には、オプコー
ド８２はコード９４と置換えられ、これはオプコードル
ックアップテーブル１６６（図１９を参照）へ索引付け
するか、そうでなければオプコードルックアップテーブ
ル１６６に対して、および／またはこの中でポイントす
る。オプコード８２が圧縮された形式であるか、または
圧縮されない形式であるかを識別するために、制御ビッ
ト６５がオプコード形式８２、９２に対して用いられ
る。制御ビットは、サブ命令オペランドの圧縮が実行さ
れていることを示す１つの値と、実行されていない（し
かしながら、ＮＯＰ圧縮およびサブ命令共用はやはり実
行されているかも知れない）ことを示す別の値とを有す
る。

【００７４】オプコードテーブル 図１９は、複数のエントリ１６８を有するオプコードル
ックアップテーブル１６６を示す。ホストプロセッサ２
０に対する一部のオプコードは、オプコードテーブル１
６８にエントリを有する。好ましい実施例においては、
小さな、選択されたオプコードのサブセットがテーブル
１６８にストアされる。ベストモードの実施例において
は、オプコードテーブル１６６の内容はコンパイルの間
に規定され、それにより所与のアプリケーションに対し
てカスタマイズされる。いくつかの実施例においては、
オンチップメモリ上で代替的にアクティブになり現在の
オプコードテーブルとしての役割を果たし得る複数のオ
プコードが存在する。オプコードテーブルは、タスク切
替の間にタスクに対してロードされる。したがって、テ
ーブルサイズを小さく保つと、ローディングオーバーヘ
ッドが最小化される。さらにテーブルへのエントリを戦
略的に選択することにより、テーブルはタスクに対して
効率的になる。

【００７５】特定的な実施例においては、オプコードテ
ーブルが関数コールまたはタスクコールごとのコンパイ
ルの間に生成される。関数がアクティブになると、対応
のオプコードテーブルがシステムメモリから（たとえ
ば、不揮発性メモリ２４またはキャッシュメモリ２２か
ら）オンチップメモリ１３２（たとえば、オンチップ命
令キャッシュメモリまたはオンチップデータメモリ）に
ロードされる。そのような場合に、以前のバージョンの
オプコードテーブルは退避されるかまたは上書きされ
る。退避される場合の実施例においては、アドレスも退
避される。関数が完了すると、以前のオプコードテーブ
ルのアドレスは検索されて、それにより以前のオプコー
ドテーブルがプロセッサ２０によって用いられる現在の
オプコードテーブルとなる。そのような技術を用いる
と、コード１６３／９４はテーブルアドレスを含む必要
がなく、テーブルへのインデックスのみを含んでいれば
よい。他の実施例、たとえば多数のオプコードテーブル
が同時にアクティブになることを許すものにおいては、
コードは特定のテーブルをもポイントする。

【００７６】いくつかの実施例においては、さまざまな
オプコードテーブルがプロセッサチップ上にキャッシュ
される。所与の時間に１つのテーブルが現在のオプコー
ドテーブルとしてアクティブである。そのような現在の
ステータスはプログラムのさまざまな部分の実行、また
はプログラムの変更の間に動的に変化する。

【００７７】最も頻繁に発生する特定のオプコードは、
実行される関数、タスクおよびアプリケーションプログ
ラムに依存するが、殆どの画像処理アプリケーションに
対して、オプコードテーブルにストアするためのオプコ
ードの有効数は、１０−２０のオーダであることが経験
的に見出された。これは、典型的なスーパースカラまた
はＶＬＩＷプロセッサのオペランド命令セットの全体よ
りも実質的に少ない。特定的には、この発明者らによる
１つの研究においては、殆どの画像処理関数によって用
いられるオプコードの約９０％またはそれ以上を保持す
るのに１６エントリのルックアップテーブルが十分に大
きいことが見出された。特に、発明者らはすべての命令
圧縮および命令ルックアップテーブルを実現するのでは
なく、オプコード圧縮およびオプコードテーブルを生成
すると、有効な性能に対するエントリの数は実質的によ
り少ないことを見出した。

【００７８】１６エントリテーブルに対しては、４ビッ
トのみがテーブル１６６へのインデックスを規定すれば
よい。しかしながら別の実施例においては、テーブルサ
イズは変化することがあり、したがってコード１６３／
９４を規定するビットの数も変動するであろう。エント
リの各々（すなわち圧縮されないオプコード）が１２ビ
ットを占有する１６エントリテーブルにおいては、合計
１９２ビットが単一のオプコードテーブルに対して用い
られる。したがって、テーブルサイズは小さく、オプコ
ードテーブルローディングおよびタスク切替の間に殆ど
オーバーヘッドを伴わない。これは特に、テーブルが頻
繁に更新されるマルチスレッド処理のために有利であ
る。

【００７９】オプコード圧縮動作 いくつかの実施例においては、オプコードテーブルは所
与のプロセッサに対して専用である。しかしながら好ま
しい実施例に従うと、オプコードテーブルは所与のアプ
リケーションプログラムのためにソフトウェア内で規定
される。図２２を参照して、コンパイラ１００はステッ
プ１０２を実行してソースコードのリストをマシン言語
にコンパイルし、コンピュータシステムにインストール
する。そのようなコンパイルの間に、コンパイルはオプ
コードケーブル内にストアするための１組のオプコード
を選択するステップ１０４を実行する。そのような選択
および記憶は、プログラム全体またはプログラムの一部
のいずれかに対して行なわれる。たとえば、オプコード
の組は関数、タスクまたはプログラムの他のモジュラー
編成単位ごとに選択される。実施例の変形においては、
生成されるテーブルの数は編成の方法（たとえば、プロ
グラム全体、関数、他の単位）によって変化し得る。好
ましくは、すべてのオプコードテーブルは同じサイズで
ある。

【００８０】実施例の変形においては、どのオプコード
をオプコードテーブルにストアするかを選択するために
用いられる方策は変化し得る。好ましい実施例において
は、最も頻繁に発生するオプコードが選択される。他の
選択方策も実現し得る。

【００８１】図２３を参照すると、ステップ１０８にお
いてアプリケーションプログラムがコンピュータシステ
ム１１１のシステムメモリ１９（図２５を参照）に実行
のためにインストールされる。他の実施例においてはア
プリケーションは計算システム上の組込コンピュータプ
ログラムとしてストアされる。ステップ１１０において
アプリケーションプログラムが実行される。

【００８２】図２４を参照すると、アプリケーションプ
ログラム１１４のフローチャート１１２の動作は、１つ
以上のオプコードテーブル２４０、２４２（図２５を参
照）の使用に関するいくつかのステップを含む。ステッ
プ１１６においては、アプリケーションプログラムが実
行のためにロードされる。そのようなステップは典型的
には、アプリケーションプログラムの全部または一部
を、不揮発性メモリ２４からキャッシュメモリ２２など
のランダムアクセスメモリにロードするステップを含
む。プログラム命令のいくつかの部分は、プロセッサの
オンチップメモリ１３２にロードされる。

【００８３】プログラムの実行の間に、コンパイルの間
に規定された１つ以上のオプコードテーブル２４０、２
４２がオンチップメモリ１３２にロードされる。ある実
施例においては、多数のオプコードテーブルが同時にオ
ンチップメモリに存在する。他の実施例においては、所
与の時間に１つのオプコードテーブルだけがオンチップ
メモリに存在する。いずれの場合においても、ポインタ
２４６によって示される、所与の時間現在にアクティブ
であるオプコードテーブルが存在する。プロセッサが命
令をパーズし、コード６５／９４がオプコード圧縮がそ
の命令に対してアクティブであることを示すと、プロセ
ッサはアクティブなオプコードテーブルを参照して圧縮
命令形式１６２／１６４／１７２／９２において示され
るオプコードを検索する。

【００８４】たとえば、ステップ１１８において、関数
Ａの実行のための準備が開始する。そのような準備に含
まれるのは、ステップ１２０において関数Ａによって用
いられるオプコードテーブルのアクティブ化である。そ
のようなアクティブ化は、現在のオプコードテーブルポ
インタ２４６における対応のオプコードテーブルのオン
チップアドレスをストアするステップを含む。もしテー
ブルが既にオンチップにロードされていなければ、ステ
ップはまたテーブルをオンチップメモリにロードするス
テップをも含む。ステップ１２２において、関数Ａがさ
らに実行される。オプコード圧縮が用いられていること
を示すコード６５を有する如何なる命令も、プロセッサ
によってパーズされ、オプコードテーブルへのインデッ
クスを識別する。ＶＬＩＷ命令に対しては、多数のイン
デックスが存在し得る。ＲＩＳＣまたはスーパースカラ
命令に対しては、１つのオプコードのみが存在し得る。
存在するインデックスの各々は、オプコードを検索する
ために用いられる。次いでオプコードが実行される。関
連する命令内のソースオペランドおよびデスティネーシ
ョンオペランドフィールドは、実行されるオプコードに
対応するマイクロコードに基づいて処理される。

【００８５】アプリケーションプログラムに対して１つ
以上のオプコードテーブルが規定される実施例において
は、別のオプコードテーブルが先行のオプコードテーブ
ルに現在アクティブなオプコードテーブルとして置換わ
る状況がある。たとえば、ステップ１２４において、関
数Ｂが実行のためにコールされる。関数Ｂの実行に備え
て、関数Ｂの処理のために用いられるべきオプコードテ
ーブルはステップ１２６において現在のオプコードテー
ブルとなるようアクティブ化される。そのようなアクテ
ィブ化は、対応のオプコードテーブルを現在のオプコー
ドテーブルポインタ２４６のオンチップアドレスにスト
アすることを含む。もしテーブルが既にオンチップにロ
ードされていなければ、ステップはまたテーブルをオン
チップメモリにロードすることをも含む。ステップ１２
８において、関数Ｂが実行される。関数Ｂの完了の際
に、先行のオプコードテーブルが現在のオプコードテー
ブルとして復元される。そのような復元は、制御が戻さ
れるプログラムの一部に対するオプコードテーブルのア
クティブ化と同様である。したがって、関数Ａに対する
オプコードテーブルは、アクティブなオプコードテーブ
ルとして復元される。

【００８６】一実施例においては、関数Ａに対するオプ
コードテーブルのアドレスが、関数Ｂがコールされたと
きにスタック２４８にプッシュされる。関数Ｂが完了す
ると、アドレスはスタック２４８から検索されて、関数
Ａに対するオプコードテーブルアドレスを識別する。ス
テップ１３２において関数Ａの処理が再開する。

【００８７】共通して用いられるオプコードのテーブル
はリアルタイムの処理の間に動的に更新され、上書きさ
れかつ置換えられる。たとえば、テーブルは、アプリケ
ーションプログラムまたはタスクの実行の間にストアさ
れ、アプリケーションプログラムまたはタスクごとに変
更される。動的な更新の利点とは、より小さなテーブル
サイズが効率的に命令帯域幅を減じることである。

【００８８】いくつかの実施例においては、テーブルは
動的である必要はなく、固定されていてもよい。たとえ
ば、広い範囲のアプリケーションプログラムに対して最
も頻繁に用いられるすべてのオプコードをストアするた
めには、そのようなテーブルは動的に更新されるテーブ
ルよりも大きくなるであろう。好ましい動的実現化のた
めにテーブルはアプリケーションに対してカスタマイズ
され、プログラム設計の一部となる。たとえば、オプコ
ードテーブルにストアされるべきオプコードのそれぞれ
のテーブルを備えて、異なったタスクがプログラムされ
る。次いでそれぞれのテーブルはタスク切替の際にロー
ドされる。より小さな動的なオプコードテーブルは、オ
プコードの効率的な選択の利点と、タスク切替の間のテ
ーブルローディングに対する低いオーバーヘッドとをも
たらす。さらに、多数のテーブルをストアするためにプ
ロセッサチップ上にスペースが割当てられている場合、
１つのテーブルがアクティブにされ別のものがインアク
ティブにされるので、テーブルローディングオーバーヘ
ッドはさらに減じられる。

【００８９】ある実施例においては、所与のオプコード
テーブル内の１つ以上の特定のエントリが更新される。
オプコードテーブル内のどこで更新された値を上書きす
るべきかを識別するためにテーブルインデックスを用い
る特別な命令が含まれる。さらに、ある実施例において
は、データをメモリからオプコードテーブルにより早く
転送し、かつテーブルによりコンパクトにストアするた
めのＣＩＳＣ様の命令が含まれる。

【００９０】ある実施例においては、、オプコードテー
ブルは関数コールの早期に不揮発性メモリからプレロー
ドされる。さらに、先行のテーブルに対するポインタは
維持され、それにより、関数が完了し処理がコーリング
ルーチンに戻った後で、オプコードテーブルはコーリン
グルーチンに対して復元される。

【００９１】価値のある有利な効果 この発明の利点は、命令キャッシュにおいて必要となる
命令スペースが、ＶＬＩＷ命令に対して効率的に減じら
れることである。特に、画像処理アルゴリズムの間に実
行され、占有タイトループを有するいくつかの関数に対
しては、スラッシングが発生するであろう場合にも、ス
ラッシングなしにタイトループを維持することが可能で
ある。

【００９２】別の利点とは、ＶＬＩＷサブ命令において
いくらかの冗長性をなくすことにより、より少ないビッ
トのみが必要となり、よってプログラムサイズが減じら
れることである。さらに、命令キャッシュ利用の効率性
が向上し、かつ命令フェッチ帯域幅が増大する。

【００９３】この発明の好ましい実施例を例示し説明し
てきたが、さまざまな代替例、変形および等価物を用い
得る。したがって、上述の説明は前掲の特許請求の範囲
によって規定されるこの発明の範囲を限定するものと解
してはならない。

【図面の簡単な説明】

【図１】 ＶＬＩＷ命令を有するコンピュータプログラ
ムの開発および記憶のブロック図である。

【図２】 ＶＬＩＷプロセッサを有するコンピュータシ
ステムの部分的なブロック図である。

【図３】 ＶＬＩＷプロセッサアーキテクチャのブロッ
ク図である。

【図４】 図３のプロセッサに対するさまざまなサブ命
令フィールド内容のデスティネーションを識別する、Ｖ
ＬＩＷ命令形式の図である。

【図５】 例示的な圧縮されないＶＬＩＷ命令の図であ
る。

【図６】 ＮＯＰサブ命令を除去するためのＶＬＩＷ命
令の図である。

【図７】 サブ命令共用を実現するためのこの発明の実
施例に従って圧縮されたＶＬＩＷ命令の図である。

【図８】 図７の命令に含まれる制御ビットの組の図で
ある。

【図９】 さまざまなサブ命令共用条件を判断するため
の命令の制御ビットを復号化するための多重化アーキテ
クチャの図である。

【図１０】 （Ａ）から（Ｅ）は、命令の意図された分
散、ＮＯＰ圧縮を備えた命令、およびサブ命令共用のた
めの形式における命令を示す例示的な命令の図である。

【図１１】 命令圧縮制御ビットを設定するための方法
のフローチャートである。

【図１２】 サブ命令共用のための命令を圧縮するため
の方法のフローチャートである。

【図１３】 さまざまなサブ命令共用条件を識別するた
めの命令圧縮制御ビットを復号化するための方法のフロ
ーチャートである。

【図１４】 例示的なホスト処理システムのブロック図
である。

【図１５】 この発明の実施例に従ってオプコード圧縮
が実施される例示的なプロセッサのブロック図である。

【図１６】 従来の圧縮されないＶＬＩＷ命令形式の図
である。

【図１７】 従来のＮＯＰ圧縮を有するＶＬＩＷ命令の
図である。

【図１８】 （Ａ）および（Ｂ）は、この発明の実施例
に従った、オプコード圧縮と、オプコード圧縮およびＮ
ＯＰ圧縮の両方とを示すＶＬＩＷ命令の図である。

【図１９】 この発明の実施例に従ったオプコードテー
ブルの図である。

【図２０】 圧縮されない形式、ＮＯＰ圧縮された形
式、サブ命令共用形式およびオプコード圧縮された形式
を含む、進行形式（progressive format）におけるＶＬ
ＩＷ命令の図である。

【図２１】 （Ａ）および（Ｂ）は、ＲＩＳＣまたはス
ーパースカラプロセッサアーキテクチャに対する圧縮さ
れない形式およびオプコード圧縮された形式における命
令の図である。

【図２２】 この発明の実施例に従った１つ以上のオプ
コードテーブルを規定するコンパイル動作のフローチャ
ートである。

【図２３】 アプリケーションプログラムをインストー
ルし実行するためのフローチャートである。

【図２４】 この発明の実施例に従った、オプコード圧
縮実現化を例示する図２３のアプリケーションプログラ
ムの関連部分の実行のフローチャートである。

【図２５】 この発明の実施例に従った、オプコードテ
ーブルをロードするためのメモリ編成の図である。

【符号の説明】

２６ クラスタ、２７ クラスタのためのレジスタファ
イル、２８ 機能処理単位。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 9/45 Ｇ０６Ｆ 12/08 ５１１Ｂ 12/08 ５０１ ５５９Ｚ ５１１ ５６３ ５５９ 9/30 ３２０Ａ ５６３ 9/44 ３２２Ｆ (72)発明者 ステファン・ジー・バーグ アメリカ合衆国、98105−3582 ワシント ン州、シアトル、ユニバーシティ・ウェ イ・エヌ・イー、5212、アパートメント・ 203 (72)発明者 ウェイユン・スン アメリカ合衆国、98125 ワシントン州、 シアトル、エヌ・イー・ワンハンドレッド アンドシックスス・ストリート、818 (72)発明者 ヨンミン・キム アメリカ合衆国、98155 ワシントン州、 シアトル、エヌ・イー・ワンハンドレッド アンドエイティナインス・プレイス、4431 Ｆターム(参考） 5B005 JJ13 KK03 KK14 KK22 LL01 MM02 MM03 NN12 5B013 DD00 DD04 5B033 AA05 AA06 AA10 AA14 BA01 BB02 BE05 BE07 5B081 CC21 CC22 CC32

Claims (21)

【特許請求の範囲】
1. 【請求項１】 超長命令語アーキテクチャを有するプロ
   セッサ２０上の複数のクラスタ２６の機能処理単位２８
   の間の所与の命令３０／３４／４２のサブ命令３２を共
   用するための方法であって、前記所与の命令は制御ビッ
   トの組３７および少なくとも１つのサブ命令を含み、前
   記プロセッサは複数のクラスタ２６を含み、前記複数の
   クラスタのクラスタの各々は複数の機能処理単位２８を
   含み、前記方法は、 予め規定された条件を識別するための制御ビットの組３
   ７をテストするステップと、 予め規定された条件が識別された場合、所与の命令３０
   ／３４／４２の前記サブ命令３２を、予め規定された条
   件によって定められる複数の機能処理単位２８に経路制
   御するステップと、 前記多数の機能処理単位においてサブ命令を同時実行す
   るステップとを含む、方法。
2. 【請求項２】 前記経路制御するステップは、所与の命
   令３０／３４／４２の前記サブ命令３２を、前記複数の
   クラスタの第１のクラスタの第１の機能処理単位２８
   （１，１）および、前記複数のクラスタの第２のクラス
   タの第１の機能処理単位２８（２，１）に経路制御する
   ステップを含み、前記実行するステップは、前記複数の
   クラスタの前記第１のクラスタの前記第１の機能処理単
   位および、前記複数のクラスタの前記第２のクラスタの
   前記第１の機能処理単位で、サブ命令を同時実行するス
   テップを含む、請求項１に記載の方法。
3. 【請求項３】 前記所与の命令は第１のサブ命令および
   第２のサブ命令を含み、前記テストするステップは、制
   御ビットの組をテストして第１の予め規定された条件を
   識別するステップを含み、前記経路制御するステップ
   は、第１のサブ命令を経路制御するステップを含み、前
   記方法はさらに、 前記制御ビットの組をテストして第２の予め規定された
   条件を識別するステップと、 第２の予め規定された条件が識別された場合、前記所与
   の命令の前記第２のサブ命令を、前記複数のクラスタの
   前記第１のクラスタの第２の機能処理単位２８（１，
   ２）および前記複数のクラスタの前記第２のクラスタの
   第２の機能処理単位２８（２，２）に経路制御するステ
   ップと、 サブ命令を、前記第１の機能処理単位および前記第２の
   機能処理単位で同時実行するステップとを含み、 前記実行するステップは、前記第１のサブ命令を前記第
   １のクラスタの前記第１の機能処理単位で、前記第１の
   サブ命令を前記第２のクラスタの前記第１の機能処理単
   位で、前記第２のサブ命令を前記第１のクラスタの前記
   第２の機能処理単位で、および前記第２のサブ命令を前
   記第２のクラスタの前記第２の機能処理単位で同時実行
   するステップを含む、請求項２に記載の方法。
4. 【請求項４】 超長命令語アーキテクチャを有するプロ
   セッサ２０で実行するべきコンピュータプログラムの命
   令３０／３４／４２をストアするための方法であって、 命令の各々は、少なくとも１つのサブ命令３２から第１
   の規定された数のサブ命令３２までの間のサブ命令を含
   み、前記第１の予め規定された数は少なくとも２であ
   り、 プロセッサ２０は、第２の予め規定された数ｎに等しい
   複数のクラスタ２６に編成され、前記複数のクラスタの
   クラスタの各々は、共通の数ｍの機能処理単位２８から
   なり、前記機能処理単位の共通の数は、前記第２の予め
   規定された数と積算すると前記第１の予め規定された数
   と等しく（ｎ＊ｍ）、 前記第１の予め規定された数のサブ命令を有する所与の
   命令に対しては、前記複数のクラスタの機能処理単位の
   各々が、前記所与の命令のそれぞれのサブ命令を実行す
   るためのものであり、前記方法は、 前記所与の命令内でサブ命令が１度以上発生するパター
   ンを識別するステップ６２を含み、前記サブ命令は冗長
   なサブ命令であり、前記方法はさらにパターンは予め規
   定されたパターンの組の中のものであるか否かを判断す
   るステップと、 パターンが予め規定されたパターンの組の中のものであ
   る場合、前記命令に対する制御ビットの組を設定して前
   記パターンが存在することを示すステップ６４とを含
   む、方法。
5. 【請求項５】 パターンが予め規定されたパターンの組
   の中のものである場合、圧縮された命令を得るために所
   与の命令内の冗長なサブ命令の１つの発生を削除するこ
   とにより、所与の命令を圧縮するステップ６６をさらに
   含む、請求項３に記載の方法。
6. 【請求項６】 圧縮された命令を命令キャッシュ内に移
   動するステップ６８と、 圧縮された命令の制御ビットの組をテストして、圧縮さ
   れた命令に対してサブ命令共用が発生することを識別す
   る条件を判断するステップ７６と、 サブ命令共用が発生すると判断された場合、圧縮された
   命令をパーズして、冗長なサブ命令を識別された条件に
   よって判断された複数の機能処理単位に経路制御するス
   テップ７８と、 サブ命令を、前記複数の機能処理単位で同時実行するス
   テップとをさらに含む、請求項５に記載の方法。
7. 【請求項７】 超長命令語アーキテクチャを有するプロ
   セッサ２０上で実行するためのコンピュータプログラム
   の命令３０／３４／４２／４８をストアするための方法
   であって、 命令の各々は、少なくとも１つのサブ命令３２から第１
   の予め規定された数までのサブ命令を含み、前記第１の
   予め規定された数は少なくとも４であり、 プロセッサは第２の予め規定された数ｎに等しい複数の
   クラスタ２６に編成され、前記複数のクラスタのクラス
   タの各々は共通の数ｍの機能処理単位２８を含み、前記
   機能処理単位の共通の数と前記第２の予め定められた数
   とを積算すると、前記第１の予め規定された数と等しく
   （ｎ＊ｍ）、前記方法は、 所与の命令４８に対して、前記複数のクラスタの第１の
   クラスタの第１の機能単位２８（１，１）によって処理
   されるべき第１のサブ命令と、前記複数のクラスタの第
   ２のクラスタの第１の機能単位２８（２，１）によって
   処理されるべき第２のサブ命令とを比較するステップ
   と、 前記第１のサブ命令が前記第２のサブ命令と同じである
   場合、前記所与の命令に関連の制御ビットの組の第１の
   制御ビットを、前記第２のサブ命令が前記第１のサブ命
   令と等しいことを示す第１の論理状態に設定するステッ
   プと、 前記所与の命令に対して、前記複数のクラスタの前記第
   １のクラスタの第２の機能単位によって処理されるべき
   第３のサブ命令と、前記複数のクラスタの前記第２のク
   ラスタの第２の機能単位によって処理されるべき第４の
   サブ命令とを比較するステップと、 第３のサブ命令が第４のサブ命令と同じである場合、前
   記所与の命令に関連の制御ビットの組の第２の制御ビッ
   トを第４のサブ命令が第３のサブ命令と等しいことを示
   す第２の論理状態に設定するステップと、 第１の制御ビットおよび第２の制御ビットを備えた前記
   所与の命令をストアするステップとを含む、方法。
8. 【請求項８】 前記ストアするステップは、所与の命令
   を圧縮されない形式にストアするステップを含み、所与
   の命令を圧縮された形式に圧縮するステップと、所与の
   命令を圧縮された形式でキャッシュにストアするステッ
   プとをさらに含み、前記圧縮するステップは、 所与の命令に関連する第１の制御ビットをテストするス
   テップ７０と、 前記第１の制御ビットが前記第１の論理状態と等しい場
   合に、所与の命令を圧縮してサイズを減じて、等しい前
   記第１のサブ命令と前記第２のサブ命令とのうちの１つ
   のコピーを省いて、前記第１のサブ命令および前記第２
   のサブ命令の冗長な記憶を避けるステップ７２と、 所与の命令に関連する前記第２の制御ビットをテストす
   るステップ７０と、 前記第２の制御ビットが前記第２の論理状態と等しい場
   合に、所与の命令を圧縮してサイズを減じて、等しい前
   記第３のサブ命令と前記第４のサブ命令とのうちの１つ
   のコピーを省いて、前記第３のサブ命令および前記第４
   のサブ命令の冗長な記憶を省くステップ７２とを含む、
   請求項７に記載の方法。
9. 【請求項９】 前記ストアするステップは、所与の命令
   を圧縮された形式でストアするステップを含み、前記ス
   トアするステップの前に、所与の命令を圧縮された形式
   に圧縮するステップをさらに含み、前記圧縮するステッ
   プは、 前記第１の制御ビットが前記第１の論理状態と等しい場
   合に、所与の命令を圧縮してサイズを減じて、等しい前
   記第１のサブ命令と前記第２のサブ命令とのうちの１つ
   のコピーを省いて、前記第１のサブ命令および前記第２
   のサブ命令の冗長な記憶を避けるステップと、 前記第２の制御ビットが前記第２の論理状態に等しい場
   合に、所与の命令を圧縮してサイズを減じて、等しい前
   記第３のサブ命令と前記第４のサブ命令とのうちの１つ
   のコピーを省いて、前記第３のサブ命令および前記第４
   のサブ命令の冗長な記憶を省くステップとを含む、請求
   項７に記載の方法。
10. 【請求項１０】 所与の命令を圧縮された形式でキャッ
    シュ２２にストアするステップをさらに含む、請求項９
    に記載の方法。
11. 【請求項１１】 所与の命令を前記第１の制御ビットお
    よび前記第２の制御ビットを備えて圧縮された形式４２
    Ａ−Ｄでキャッシュにストアするステップを含み、前記
    圧縮された形式４２Ａは、前記第１の制御ビットが前記
    第１の論理状態に設定されている場合に、前記第１のサ
    ブ命令の記憶と前記第２のサブ命令の記憶とを組合せて
    第１の組合された記憶にさせ、前記圧縮された形式は、
    前記第２の制御ビットが前記第２の論理状態に設定され
    ている場合に、前記第３のサブ命令の記憶と前記第４の
    サブ命令の記憶とを組合せて第２の組合された記憶にさ
    せ、さらに前記第１の制御ビットをテストするステップ
    と、 前記第１の制御ビットが前記第１の論理状態に設定され
    ている場合、前記第１の組合された記憶の内容を、前記
    第１のクラスタの前記第１の機能処理単位および前記第
    ２のクラスタの前記第１の機能処理単位に経路制御し
    て、前記第１のクラスタの前記第１の機能処理単位およ
    び前記第２のクラスタの前記第１の機能処理単位による
    同時実行を行なわせるステップと、 前記第２の制御ビットをテストするステップと、 前記第２の制御ビットが前記第２の論理状態に設定され
    ている場合、前記第２の組合された記憶の内容を、前記
    第１のクラスタの前記第２の機能処理単位および前記第
    ２のクラスタの前記第２の機能処理単位に経路制御し
    て、前記第１のクラスタの前記第２の機能処理単位およ
    び前記第２のクラスタの前記第２の機能処理単位による
    同時実行を行なわせるステップとを含む、請求項７に記
    載の方法。
12. 【請求項１２】 超長命令語アーキテクチャを有するプ
    ロセッサ２０上で実行するためのコンピュータプログラ
    ムの命令３０／３４を圧縮された形式４２に圧縮するた
    めの方法であって、 前記命令の各々は、少なくとも１つのサブ命令３２と、
    第１の予め規定された数までのサブ命令を含み、前記第
    １の予め規定された数は少なくとも４であり、 前記プロセッサは、第２の予め規定された数ｎに等しい
    複数のクラスタ２６に編成され、前記複数のクラスタの
    クラスタの各々は、共通の数ｍの機能処理単位２８を含
    み、機能処理単位の共通の数と前記第２の予め規定され
    た数とを積算すると、前記第１の予め規定された数に等
    しく（ｎ＊ｍ）、 前記方法は、 所与の命令に対して、前記複数のクラスタの第１のクラ
    スタの第１の機能単位２８（１，１）によって処理され
    るべき第１のサブ命令３２（１，１）と、前記複数のク
    ラスタの第２のクラスタの第１の機能単位２８（２，
    １）によって処理されるべき第２のサブ命令３２（２，
    １）とを比較するステップと、前記第１のサブ命令が前
    記第２のサブ命令と同じである場合４８Ａ、所与の命令
    を前記第１のサブ命令を備えるが前記第２のサブ命令を
    備えずにストアされるよう圧縮し、かつ所与の命令４２
    に関連の第１の制御ビット３７を、前記第２のサブ命令
    が前記第１のサブ命令に等しいことを示す論理状態に設
    定するステップと、 所与の命令に対して、前記複数のクラスタの前記第１の
    クラスタの第２の機能単位２８（１，２）によって処理
    されるべき第３のサブ命令３２（１，２）と、前記複数
    のクラスタの前記第２のクラスタの第２の機能単位２８
    （２，２）によって処理されるべき第４のサブ命令３２
    （２，２）とを比較するステップと、 前記第３のサブ命令が前記第４のサブ命令と同じであっ
    た場合４８Ｂ、Ｃ、Ｄ、所与の命令を前記第３のサブ命
    令を備えるが前記第４のサブ命令を備えずにストアされ
    るよう圧縮し、かつ所与の命令に関連の第２の制御ビッ
    ト３７を、前記第４のサブ命令が前記第３のサブ命令に
    等しいことを示す論理状態に設定するステップとを含
    む、方法。
13. 【請求項１３】 コンピュータシステム１０であって、 超長命令語アーキテクチャを有しかつ機能処理単位２８
    の複数のクラスタ２６を含むプロセッサ２０を含み、前
    記複数のクラスタのクラスタの各々は、共通の数ｍの機
    能処理単位を含み、前記プロセッサは、第１の予め規定
    された数ｎのクラスタを含み、前記超長命令語アーキテ
    クチャは、命令が第２の予め規定された数までのサブ命
    令を有することを可能にし、前記第２の予め規定された
    数は、前記第１の予め規定された数と前記共通の数とを
    積算したものに等しく、前記プロセッサによって実行さ
    れるべき命令３０／３４の各々は、制御ビットの組３７
    を備えて、１つのサブ命令から前記第２の予め規定され
    た数のサブ命令までを含み、前記コンピュータシステム
    １０はさらに制御ビットの組の条件によって決定される
    圧縮された形式４２に第１のサブ命令をストアする命令
    キャッシュメモリ２２を含み、前記圧縮された形式は、
    複数の機能処理単位によって共用されるべき第１の命令
    の所与のフィールド内にストアされる共用サブ命令３６
    を含み、前記複数の機能処理単位は、前記制御ビットの
    組の条件によって判断される、コンピュータシステム。
14. 【請求項１４】 前記共用サブ命令は、前記制御ビット
    の組が第１の予め規定された条件を識別した場合、第１
    のクラスタの第１の機能処理単位２８（１，１）および
    第２のクラスタの第１の機能処理単位２８（２，１）に
    対するものである、請求項１３に記載のシステム。
15. 【請求項１５】 前記共用サブ命令は第１の共用サブ命
    令であり、圧縮された形式４２Ｄは、制御ビット３７の
    組が同時に（either concurrently）第２の予め規定さ
    れた条件を識別した場合、前記第１のクラスタの第２の
    機能処理単位２８（１，２）および前記第２のクラスタ
    の第２の機能処理単位２８（２，２）に対する第２の共
    用サブ命令をさらに含む、請求項１４に記載のシステ
    ム。
16. 【請求項１６】 所与の命令に対して制御ビットの組を
    テストするための手段７６と、 前記テストする手段が第１の予め規定された条件を識別
    した場合、前記第１の共通のサブ命令を、前記複数のク
    ラスタの前記第１のクラスタの前記第１の機能処理単位
    と前記第２のクラスタの前記第１の機能処理単位とに経
    路制御するための手段７８とをさらに含む、請求項１４
    に記載のシステム。
17. 【請求項１７】 前記第１の共通のサブ命令は、前記第
    １のクラスタの前記第１の機能処理単位および前記第２
    のクラスタの前記第１の機能処理単位で同時実行され
    る、請求項１６に記載のシステム。
18. 【請求項１８】 前記圧縮されない形式の第１の命令３
    ０は、前記第２の予め規定された数のサブ命令を含み、
    前記第１の命令は、第１のクラスタの第１の機能処理単
    位２８（１，１）によって実行される第１のサブ命令３
    ２（１，１）と、第２のクラスタの第１の機能処理単位
    ２８（２，１）によって実行される第２のサブ命令３２
    （２，１）とを含み、前記システムはさらに、前記第１
    の命令をコンパイルするための手段１４を含み、前記コ
    ンパイルする手段は、 前記第１のサブ命令と前記第２のサブ命令とを比較する
    ための手段６２と、 前記第１のサブ命令が前記第２のサブ命令に等しい場合
    に、第１の予め規定された条件を識別するするために制
    御ビットの組の状態を設定するための手段６４とを含
    む、請求項１４に記載のシステム。
19. 【請求項１９】 前記圧縮されない形式の前記第１の命
    令は、前記第２の予め規定された数のサブ命令を含み、
    前記第１の命令は、第１のクラスタの第１の機能処理単
    位によって実行される第１のサブ命令と、第２のクラス
    タの第１の機能処理単位によって実行される第２のサブ
    命令とを含み、前記システムはさらに、前記第１の命令
    を圧縮された形式に圧縮するための手段を含み、前記圧
    縮手段は、 前記第１の命令に関連の制御ビットの組をテストするた
    めの手段７０と、 前記制御ビットの組が、前記第１のサブ命令と前記第２
    のサブ命令とが等しいことを識別した場合、前記第２の
    サブ命令を省くことにより第１の命令のサイズを減じる
    ための手段７２とを含む、請求項１４に記載のシステ
    ム。
20. 【請求項２０】 圧縮されない形式の第１の命令は、前
    記第２の予め規定された数のサブ命令を含み、前記第１
    の命令は、第１のクラスタの第１の機能処理単位によっ
    て実行される第１のサブ命令と、第２のクラスタの第１
    の機能処理単位によって実行される第２のサブ命令とを
    含み、前記システムはさらに、前記第１の命令をキャッ
    シュするための手段を含み、前記キャッシュ手段は、 第１の命令に関連の制御ビットの組をテストするための
    手段７０と、 制御ビットの組が、前記第１のサブ命令と前記第２のサ
    ブ命令とが等しいことを識別した場合、前記第２のサブ
    命令を省くことによりサイズを減じて第１の命令を圧縮
    された形式にするための手段と、 第１の命令を圧縮された形式で命令キャッシュ２２にロ
    ードするための手段とを含む、請求項１４に記載のシス
    テム。
21. 【請求項２１】 圧縮されない形式の第１の命令は、前
    記第２の予め規定された数のサブ命令を含み、前記第１
    の命令は、第１のクラスタの第１の機能処理単位によっ
    て実行される第１のサブ命令と、第２のクラスタの第１
    の機能処理単位によって実行される第２のサブ命令とを
    含み、前記システムはさらに、前記第１の命令をキャッ
    シュするための手段を含み、前記キャッシュ手段は、 前記第１のサブ命令と前記第２のサブ命令とを比較する
    ための手段６２と、 前記第１のサブ命令が前記第２のサブ命令に等しい場合
    に、第１の予め定められた条件を識別するよう前記第１
    の命令に関連の制御ビットの組の状態を設定するための
    手段６４と、 前記制御ビットの組が、前記第１のサブ命令と前記第２
    のサブ命令とが等しいことを識別した場合、前記第２の
    サブ命令を省くことにより第１の命令のサイズを減じて
    圧縮された形式を得るための手段６６と、 圧縮された形式で前記第１の命令を命令キャッシュにロ
    ードするための手段６８とを含む、請求項１４に記載の
    システム。