JP2004502990A - 構成可能なプロセッサを設計する自動化されたプロセッサ生成システムおよびその方法 - Google Patents

Abstract

プロセッサハードウェアを生成するシステムはプロセッサ命令セットに対する大きな拡張のための言語をサポートし、設計者は新しい命令のセマンチックスだけを特定し、システムは他の論理を生成する。拡張言語はレジスタファイルを含むプロセッサの状態と、その状態で動作する命令の付加を提供する。言語はまた付加される状態を表すためにコンパイラに付加される新しいデータタイプを与える。これは基準セマンチックスと命令構成との別々の仕様を可能にし、設計検査を自動化するためにこれを使用する。さらに、システムはフォーマットされた命令セットの文書化を言語仕様から生成する。
【選択図】図１４

Description

【０００１】
【発明の属する技術分野】
本発明はコンピュータプロセッサと、システムおよびそれを開発する技術に関し、特にユーザのオプションで構成可能な特徴を有するプロセッサと、関連する開発システムおよび技術に関する。
【０００２】
【従来の技術】
従来技術のプロセッサは変更または拡張が困難である非常に堅牢なオブジェクトである。レジスタからレジスタへのコンピュータ処理命令および簡単な状態（レジスタファイルではない）を付加する能力を含む、プロセッサとそれらのサポーティングソフトウェアツールに対して程度が限定された拡張性はある種の従来技術のシステムで与えられている。この限定された拡張性は現在の技術において大きく進歩しており、これらの改良を使用している多数のアプリケーションは４倍以上のスピードアップまたは効率の改良を経験している。
【０００３】
しかしながら、これらの従来技術のシステムの拡張性における制限は他のアプリケーションが適切にアドレスされないことを意味している。特に、その固定した３２ビット幅レジスタにより既存のコアレジスタファイルを使用する必要性は通常、付加的な正確性、または結合したデータオペランド幅が３２ビットを超える複製された機能装置を必要とするアプリケーションではこれらの改良を使用することが妨げられる。さらに、コアレジスタファイルは多くはある命令を実行するための十分な読取りまたは書込みポートがない。これらの理由で、読取りおよび書込みポートの幅および数において構成可能である新しいレジスタファイルの付加をサポートすることが技術で必要とされている。
【０００４】
【発明が解決しようとする課題】
レジスタファイルの付加により、これらのファイルとメモリとの間でのデータ転送をする必要が生じる。コア命令セットはコアレジスタファイルのこのようなロードおよび記憶命令を含むが、付加的なレジスタファイルは付加的なロードおよび記憶命令を必要とする。これは拡張可能なレジスタファイルの原理の１つが、拡張可能なレジスタファイルを必要とされるデータタイプおよび帯域幅の大きさにすることを可能にするためである。特にレジスタファイルデータの幅は残りの命令セットによりサポートされる幅よりも広い。それ故、コアにより与えられるレジスタへデータを転送することによりデータをロードし記憶することは合理的ではなく、新しいレジスタファイルから直接値をロードし記憶することが可能である。
【０００５】
さらに、従来技術のシステムはプロセッサ状態の付加をサポートするが、その状態の量は典型的に小さい。結果として、多数の状態ビットが容易にプロセッサアーキテクチャに付加されることが技術で必要とされている。この状態は多くはオペレーティングシステムにより切換えられるコンテキストである必要がある。一度、状態の量が大きくなると、コンテキストのスイッチ時間を最小にする新しい方法が望ましい。このような方法は従来技術のプロセッサ（例えばＭＩＰＳ　Ｒ２０００コプロセッサエネーブルビット）で実行される。しかしながら、タイムリーな方法で新しい状態について知りこれを使用する必要のある実時間オペレーティングシステム（ＲＴＯＳ）および他のソフトウェアをサポートするために、入力仕様から自動的にコードシーケンスおよび論理を生成することによってさらにこれを拡張することが技術で必要とされている。
【０００６】
さらに、従来技術のプロセッサはコアプロセッサ構造と命令の拡張との間で論理の共有を可能にしない。ロードおよび記憶命令の拡張により、データキャッシュはコアと拡張の間で共有されることが重要である。このことによって、新しく構成された命令によるストアはコアによるロードによってまたはその反対に見られ、それによって、キャッシュの結合を確実にし、別々のキャッシュはこれらを一貫させ、可能にするが不所望な解決策である特別な機構を必要とする。また、データキャッシュはコアプロセッサで大きい回路の１つであり、それを共有することはコアプロセッサのサイズの減少を容易にする。
【０００７】
レジスタファイルの付加はまたハイレベル言語変数のこれらのレジスタへの割り当てをサポートするために望ましくする。従来技術のプロセッサは従来技術のコンパイラが既にユーザ変数の割当をサポートするコアレジスタファイルを使用する。したがって、コンパイラ割当が期待され、ユーザ定義レジスタファイルに対してサポートされるべきである。レジスタへ変数を割当てるために、コンパイラがサポートするユーザ定義レジスタファイルは通常のコンパイラ機能を実行するために、このようなレジスタをスピルし、回復し、除去する方法の知識を必要とする。
【０００８】
従来技術のプロセッサシステムにおける関連するがさらに一般的な制限は、そのコンパイラサポートレベルである。しばしば命令はアプリケーションに適切な新しいデータタイプをサポートするためにプロセッサに付加される（例えば多くのＤＳＰアプリケーションはプロセッサによって通常サポートされるさらに一般的な２の補数の演算の代わりに、飽和演算を実行するプロセッサを必要とする）。従来技術のシステムは新しいデータタイプをサポートする命令が付加されることを可能にするが、拡張を使用するハイレベルな言語コードを書き込むとき、これらの新しい命令を既存の言語データタイプにマップすることが必要である。幾つかのケースでは、適切な組込みデータタイプは存在しない。
【０００９】
例えば、飽和演算の例を考慮する。前述したように、多数のＤＳＰアルゴリズムは、伝統的な２の補数システムのように、アンダーフローの最小値で飽和するかまたはラッピングの代わりに使用されるビット数のオーバーフローの最大値で飽和する演算を利用する。しかしながら、これらのセマンチックを有するＣデータタイプは存在せず、Ｃ言語は以下、即ち
ｉｎｔ　ａ；
ｉｎｔ　ｂ；
ｉｎｔ　ｃ＝ａ＋ｂ；
がラッピングセマンチックを有し、以下のように書き、
ｉｎｔ　ａ；
ｉｎｔ　ｂ；
ｉｎｔ　ｃ＝ＳＡＴＡＤＤ（ａ，ｂ）；
代わりに新しい固有の機能により組込みタイプを仕様するが、これは不適切であり、アルゴリズムを不明確にする（書込み装置はＳＡＴＡＤＤ機能を単に＋と考える）。
【００１０】
他方で、新しいデータタイプの付加は＋演算子がこれらのタイプと異なって機能することを可能にし、Ｃは既に整数加算と浮動小数点加算オペレーションに対して異なるオペレーションに適用され、それによって拡張は自然である。したがって、加算を飽和する新しいデータタイプの仕様は以下のようにコード化される。
ｄｓｐ１６　ａ；
ｄｓｐ１６　ｂ；
ｄｓｐ１６　ｃ＝ａ＋ｂ；
ここで、ｄｓｐ１６は飽和データタイプを規定する。したがってその両者のオペランドが飽和データタイプであるので、最後のラインは飽和された加算を示唆する。
【００１１】
ほとんどのコンパイラはパイプラインストールを最小にする命令をスケジュールする。しかしながら従来技術のシステムでは、命令仕様がデータ構造のコンパイラのスケジュールを拡張するために使用されることは決してない。例えばロード命令は２サイクルの待ち時間でパイプラインされる。したがって、ロードの結果がロード後の次の命令で参照されることを参照するならば、ロードは完了されていないので１サイクルストールが存在する。したがって以下のシーケンス、即ち　ｌｏａｄ　ｒ１，ａｄｄｒ１
ｓｔｏｒｅ　ｒ１，ａｄｄｒ２
ｌｏａｄ　ｒ２，ａｄｄｒ３
ｓｔｏｒｅ　ｒ２，ａｄｄｒ４
は２ストールサイクルをもつ。コンパイラがこれを以下のように並べ換えると、　ｌｏａｄ　ｒ１，ａｄｄｒ１
ｌｏａｄ　ｒ２，ａｄｄｒ３
ｓｔｏｒｅ　ｒ１，ａｄｄｒ２
ｓｔｏｒｅ　ｒ２，ａｄｄｒ４
シーケンスはストールサイクルなく実行する。これは命令スケジューリングと呼ばれる共通の最適化技術である。従来技術の命令スケジューリングはパイプ段を与えるテーブルを必要とし、その命令はそれらの入力および出力を使用するが、新しく付加された命令ではこのような情報を使用しない。
【００１２】
従来技術の別の限定は、付加された命令の計算部分がパイプラインの単一サイクルで実行されなければならないことである。大きいオペランドの乗算等の幾つかの計算は典型的なＲＩＳＣパイプライン段よりも長い論理遅延を有する。従来技術を使用したこのような演算を含むことは、プロセッサクロックレートが計算を完了するための時間をさらに与えるために減少されることを必要とする。それ故、計算が幾つかのパイプライン段にわたって拡散される命令をサポートすることが望ましい。計算が多数のサイクルにわたって実行されることを可能にすることに加えて、オペランドが異なるパイプライン段で消費され生成されることを可能にすることが有効である。
【００１３】
例えば、乗算／累算演算は典型的に２つのサイクルを必要とする。第１のサイクルでは、乗算器はキャリー保存形態の積を発生し、第２のサイクルでは、キャリー保存積と累算器はキャリー保存加算の単一レベルを使用して、３つの値から２つの値に減少され、その後、キャリー伝播（ｐｒｏｐａｇａｔｅ ）加算器で加算される。最も簡単な定義は、乗算／累算命令が任意のソースオペランドから目的地まで２つのサイクルを取ることであるが、２つのサイクルの待ち時間のために１サイクルストールが存在するので、同一の累算機のレジスタへバックツーバック乗算／累算を行うことは可能ではない。しかしながら、現実には論理は累算器の入力から累算器の出力まで１サイクルだけを必要とし、より良好な方法は以下のようなさらにパワフルな記述を与えることである。
Ｄ←Ａ＋Ｂ＊Ｃ
これは段１でＢとＣを取り、段２でＡを取り、段３でＤを発生するとして記述されている。したがって、ＢまたはＣからＤへの待ち時間は３−１＝２であり、ＡからＤへの待ち時間は３−２＝１である。
【００１４】
マルチサイクル命令の付加により、加算された命令に対するターゲットパイプラインに適切なインターロック論理を発生することも必要になる。これは、サイクルの発生毎に１つの命令により、次の命令は常に１サイクルだけ遅延されるので、待ち時間のない１つの命令は次のサイクルでインターロックを生じる結果を発生できる。通常、Ｋサイクル毎にのみ命令を発生でき、これらの命令の待ち時間はＬサイクルであり、Ｌ≧Ｋであるならば、これらの命令はそれらの目的地のオペランドにインターロックを生じることができない（それらのソースオペランドがロード等の２サイクル命令により発生されたならば、命令はそれらのソースオペランドでインターロックできる）。２サイクルの新しく構成された命令を有することが可能ならば、新しく構成された命令の結果でインターロックする以下の命令を有する必要がある。
【００１５】
ほとんどの命令セットアーキテクチャは異なるプロセッサアーキテクチャの多数の構成を有する。従来技術のシステムは命令セマンチックの仕様と命令の構成論理とを結合し、これらを分離せず、これは１セットの基準セマンチックスが多数の構成で使用されることを可能にする。基準セマンチックスは命令セット文書化の１つのコンポーネントである。伝統的には、英語とさらに正確な表記との両者で命令セマンチックを説明する。英語はしばしば不明瞭またはエラーを起こしがちであるが、読取りやすい。それ故、命令の紹介、目的、簡単な定義を与える。さらに形式的な定義は命令が行うことの正確な理解をするのに便利である。１つの基準セマンチックスの目的はこの正確な定義としての役目を行うことである。他のコンポーネントは命令ワード、アセンブラ構文、テキスト記述を含んでいる。従来技術のシステムは命令ワードとアセンブラ構文を発生するための拡張言語の十分な情報を有する。基準セマンチックスの付加により、テキスト記述だけがなくなり、通常のＩＳＡ記述ブックを生成するため、フォーマットされた文書化へ変換されることができる命令記述の仕様を含む必要がある。
【００１６】
前述の特徴を含んでいるプロセッサ開発技術は、フレキシブル性とパワーの増加のために従来技術の設計確認方法をもはや有効にしない。それ故、前述の特徴を伴って、生成されたプロセッサの以下を含む多数の特徴の正確さを確認する必要があり、即ち、
−入力基準命令セマンチックの正確さ、
−入力構成命令セマンチックの正確さ、
−命令セマンチックのコンパイラによるアプリケーションプログラミング言語への変換、
−命令セマンチックのコンパイラによるハードウェア記述言語（ＨＤＬ）への変換、
−命令セマンチックのコンパイラによる命令セットシミュレータプログラミング言語への変換、
−レジスタファイル、インターロック、バイパス、コアインターフェース、例外のための命令セマンチックのコンパイラにより発生されたＨＤＬ、
命令セマンチックのコンパイラにより発生されたハードウェア抽象層（ＨＡＬ）コードのようなプロセス中に発生された任意のシステム関数抽象層（ＨＡＬについてさらに詳細が説明されている前述のＳｏｎｇｅｒの特許明細書を参照）、
−プログラミング言語コンパイラにおける固有の、およびデータタイプのサポート。
【００１７】
基準セマンチックスはまた前述の幾つかの特徴で使用されてもよい。
【００１８】
最後に、全ての新しいハードウェア機能は命令セットによりサポートされなければならない。
【００１９】
【課題を解決するための手段】
前述の従来技術の問題を考慮して、本発明の目的は読取りおよび書込みポートの幅および数において構成可能な新しいレジスタファイルの付加を含む広い範囲のプロセッサ特徴を拡張することを可能にするプロセッサ開発システムを提供することである。
【００２０】
本発明のさらに別の目的はこのような新しいレジスタファイルとメモリとの間でデータを転送する命令の付加をサポートするプロセッサ開発システムを提供することである。
【００２１】
本発明の別の目的は、コアプロセッサ構造と命令拡張との間の論理の共有、特にコアと拡張命令との間でのデータキャッシュの共有をサポートするプロセッサ開発システムを提供することである。
【００２２】
本発明の付加的な目的は、このようなレジスタをスピル、回復および移動する能力を含む拡張レジスタファイルへのハイレベルな言語変数のコンパイラ割当をサポートするプロセッサ開発システムを提供することである。
【００２３】
本発明のさらに別の目的は計算が幾つかのパイプライン段にわたって分散される命令をサポートするプロセッサ開発システムを提供することである。
【００２４】
本発明の別の目的はオペランドが異なるパイプライン段で消費され、生成されることを可能にするプロセッサ開発システムを提供することである。
【００２５】
本発明さらに別の目的は付加されたマルチサイクル命令のためターゲットパイプラインに適切なインターロック論理の発生をサポートするプロセッサ開発システムを提供することである。
【００２６】
本発明のさらに付加的な目的はパイプラインストールを最小にするようにデータ構造のコンパイラスケジューリングを拡張するために命令仕様を使用するプロセッサ開発システムを提供することである。
【００２７】
本発明のさらに別の目的は１つのセットの基準セマンチックスが多数の命令構造で使用されることを可能にするために命令セマンチックと命令の論理の仕様をサポートすることである。
【００２８】
本発明の別の目的はフォーマットされた文書化へ変換するために命令記述の仕様を使用することができるプロセッサ開発システムを提供することである。
【００２９】
本発明のさらに別の目的はプロセッサ設計の広範囲の拡張可能な特徴を確認することができるプロセッサ開発システムを提供することである。
【００３０】
本発明のさらに別の目的は入力仕様から自動的に最小の時間コンテキストスイッチングをするためにコードシーケンスおよび論理を発生することのできるプロセッサ開発システムを提供することである。
【００３１】
本発明のさらに別の目的は前述の広範囲の拡張可能な機能をサポートできる１命令セットのシミュレータを含んでいるプロセッサ開発システムを提供することである。
【００３２】
【発明の実施の形態】
この明細書において参考とされ、その一部分を構成している添付図面には、
本発明のこれらおよび別の目的、特徴および利点は、以下の好ましい実施形態の詳細な説明および添付図面から容易に明らかになるであろう。
本発明はとくに、テンシリカ命令セット拡張（ＴＩＥ）言語およびそのコンパイラならびにその他のツールが示されているＫｉｌｌｉａｎ 氏らおよびＷｉｌｓｏｎ氏らによる特許出願明細書に記載されている技術に基づいている。本発明の好ましい実施形態は、新しい構成体、およびこれらの構成体をサポートするコンパイラ等の増補ソフトウェアツールとによりＴＩＥ言語を拡張する。
【００３３】
［拡張されたレジスタファイル］
好ましい実施形態により提供される新しい機能の１つタイプのものは、レジスタファイルをサポートする。既存のプロセッサ技術において、レジスタファイルは、それぞれＢビットのＮ個の記憶位置のセットである。命令の中のフィールドはこのセットのメンバを、その命令の結果に対するソースオペランド値または宛先オペランド値として選択する。典型的に、レジスタファイルはＮ個のメンバのＲ個のものの並列読出しと、Ｎ個のメンバのＷ個のものの並列書込みとをサポートするように指定されているので、その命令は１以上のソースオペランドおよび１以上の宛先オペランドを有しており、レジスタファイルアクセスに対して依然として１サイクルしか必要としない。
【００３４】
新しいレジスタファイルを宣言するＴＩＥ言語構成体は、
ｒｅｇｆｉｌｅ ＜ｒｆｎａｍｅ＞＜ｅｌｔｗｉｄｔｈ＞＜ｅｎｔｒｉｅｓ＞＜ｓｈｏｒｔｎａｍｅ＞
であり、ここで＜ｒｆｎａｍｅ＞は後続するＴＩＥ構成体においてレジスタファイルを示すために使用されるハンドルであり、
＜ｅｌｔｗｉｄｔｈ＞はレジスタファイル構成要素（”レジスタ”）のビットで幅であり、
＜ｅｎｔｒｉｅｓ＞ はレジスタファイル中の構成要素の番号であり、
＜ｓｈｏｒｔｎａｍｅ＞ はアセンブリ言語に対するレジスタ名を生成するために使用される短いプレフィックスである（単一文字ことが多い）。レジスタ名は、レジスタ番号が付加された＜ｓｈｏｒｔｎａｍｅ＞ である。
【００３５】
ｒｅｇｆｉｌｅ 構成体は読出しおよび書込みポートの番号を宣言せず、このような物理的構成の詳細は、以下においてさらに詳細に説明されるＴＩＥコンパイラに任せられ、それによってＴＩＥが可能な限り実施形態から独立したままに維持し、ＴＩＥを高レベルの仕様説明として維持する。
【００３６】
ｒｅｇｆｉｌｅ 宣言の結果、発生されたプロセッサはプログラマーに可視の状態の付加的な＜ｅｌｔｗｉｄｔｈ＞＊＜ｅｎｔｒｉｅｓ＞ビットを、この状態の多数の＜ｅｌｔｗｉｄｔｈ＞値の読出しおよび書込みを行うための論理と共に含むことになるであろう。以下、別の関連したＴＩＥ構成体を説明した後に、論理発生アルゴリズムを詳細に示す。
【００３７】
ＴＩＥ構成体
オペランド＜ｏｎａｍｅ＞＜ｆｉｅｌｄｎａｍｅ＞｛＜ｒｆｎａｍｅ＞［＜ｆｉｅｌｄｎａｍｅ＞］｝ はこの命令ワードのフィールド＜ｆｉｅｌｄｎａｍｅ＞ により指定されたレジスタファイル＜ｒｆｎａｍｅ＞構成要素を読出すか、あるいは書込むハンドルとして＜ｏｎａｍｅ＞ を宣言する。この構成体は、＜ｒｆｎａｍｅ＞がコアレジスタファイル（“ＡＲ”と名付けられた）に加えてｒｅｇｆｉｌｅ により宣言されたレジスタファイルを指定する可能性があることを除いて、Ｋｉｌｌｉａｎ 氏らによる特許出願明細書に記載されているものと同じである。Ｋｉｌｌｉａｎ 氏らによる特許出願明細書に記載されているように、＜ｏｎａｍｅ＞ ハンドルは命令中のレジスタファイルｉｎ、ｏｕｔ および ｉｎｏｕｔオペランドを記述するためにｉｃｌａｓｓの宣言において使用できる。
【００３８】
一例として、ＴＩＥ設計書：
【数１】

は８ビットデータ値に関する簡単化されたＧａｌｏｉｓフィールド演算ユニットを構成する（この例を実施するＴＩＥファイルの全てのセットは付録Ａにおいて認められることができる）。１６エントリ、８ビットのレジスタファイルが生成され（各レジスタがｇｆｍｏｄで記憶された多項式であるＧＦ（２）モジュロを越えた多項式を保持している）、これらのレジスタに関して動作する２つの命令が規定されている。ＧＦＡＤＤ８は、命令ワード（“ｇｓレジスタ”）のｓフィールドによって特定されたレジスタ中の多項式を、命令ワード（“ｇｔレジスタ”）のｔフィールドによって特定されたレジスタ中の多項式に追加し、命令ワード（“ｇｒレジスタ”）のｒフィールドによって特定されたレジスタにその結果を書込む。ＧＦＭＵＬＸ８はｇｓレジスタ中の多項式をｘモジュロｇｆｍｏｄと乗算し、その結果をｇｒレジスタに書込む。ＧＦＲＷＭＯＤ８はｇｆｍｏｄ多項式レジスタを読出し、および書込むためのものである。
【００３９】
この簡単なＴＩＥコードから発生された論理は、それが異なったパイプラインステージに対する種々の演算の割当てを処理するために制御論理を必要とするので、さらに複雑なものになる。ＴＩＥはユーザによく知られているレベルの命令セットで命令セットを記述した高いレベルの設計書であり、命令セットの作成者（すなわち、プロセッサ設計者）により書かれたものほど低いレベルのものではない。
【００４０】
図１にはＴＩＥコードにより発生されるレジスタパイプライン制御論理の一例が示されている。この図面の左側には、４つのパイプラインレジスタとそれらの対応した入力マルチプレクサにより形成されている読出しデータパイプを含む４ステージパイプラインレジスタが示されている。上部から説明すると、読出しポートにおけるパイプラインレジスタの各対はＣ０（Ｒ） ，Ｃ１（Ｅ） ，Ｃ２（Ｍ） ，Ｃ３（Ｗ） およびＣ４ パイプラインステージの境界を描写する。各パイプラインレジスタの出力ｒｄ０　ｄａｔａＣ１ 乃至ｒｄ０　ｄａｔａＣ４ は、読出しおよび書込みポート間に挿入されているレジスタのデータパス（簡明化のために示されていない）に供給される。これらの出力は読出しポートにおける後者のパイプラインレジスタの全ての出力と同様に、次のステージのマルチプレクサへの入力として供給される。以下、読出しポートのマルチプレクサに対する制御信号の発生を詳細に説明する。
【００４１】
その図面の右側には、４つのパイプラインレジスタおよび３つの最新のパイプラインステージに対する対応した入力マルチプレクサにより形成されている書込みポートもまた示されている。レジスタのデータパスからの４つの信号ｗ０　ｄａｔａＣ１ 乃至ｗ０　ｄａｔａＣ４ は書込みポートレジスタ入力の対応したものの入力に直接供給され、あるいは前の書込みポートパイプラインレジスタの出力ｗｒ０　ｒｅｓｕｌｔＣ２ 乃至ｗｒ０　ｒｅｓｕｌｔＣ４ で多重化することによって供給される。これらの出力信号は、レジスタファイルｘｒｅｇｆｌｅＲＦの出力と共に多重化され、読出しポートパイプラインのＣ０ ステージマルチプレクサに供給される。
【００４２】
読出しおよび書込みポート内のマルチプレクサに対する制御信号は、以下のレジスタファイルのコンパイラ発生の説明から当業者により容易に認識されるように、図２の回路を使用してｘｒｅｇｆｉｌｅＲＦに対する書込みエネーブルおよび機能停止信号ｓｔａｌｌ　Ｒと共に発生される。
【００４３】
理解を容易にするために、図１および２の回路の２ステージバージョンを組合せた２ステージレジスタファイルが図３に示されている。
【００４４】
［レジスタファイルの発生］
ｒｅｇｆｉｌｅステートメントにより宣言された各レジスタファイルに対して、コンパイラは、
−−レジスタファイル記憶セル；
−−読出しポート；
−−書込みポート；
−−ソースオペランドインターロック論理；
−−ソースオペランドバイパス論理；および
−−宛先オペランド書込み論理
を生成しなければならない。
【００４５】
［読出しおよび書込みポート］
レジスタファイルを発生する第１のステップは、読出しおよび書込みポートの数を決定し、それらポートにパイプラインステージを割当て、それらポートにオペランドを割当てることである。これらの動作をするために多くのアルゴリズムが使用されることが可能であり、それぞれにおいて結果的に種々の速度および領域トレードオフが生じる。好ましい実施形態では、以下のアルゴリズムが使用される。
【００４６】
ソースオペランドをレジスタファイルから選択するために使用される各フィールドに対して、読出しポートが発生される。いくつかの場合では、これは必要な数より多くの読出しポートを発生するが、しかしそれは、レジスタ読出しが命令デコードと並列に開始することを可能にするために、一般に高速のレジスタ読出しを生じさせる。前のＧａｌｏｉｓフィールド演算例を検討する：ここにおいて、

に変更されている。
【００４７】
上記のアルゴリズムは、３以上のＧＦレジスタファイル読出しを同時に使用する命令が存在しなくても、３つのレジスタ読出しポート（命令ワードのｒ，ｓおよびｔフィールドに対してそれぞれ１つづつ）を発生するであろう。しかしながら、読出しポートが２つしか発生されない場合、ｒおよびｓフィールド間またはｒおよびｔフィールド間を選択するために読出しポートの１つの正面に２：１の多重化（ｍｕｘ）を有している必要がある。この多重化（ｍｕｘ）は、ＧＦＲＷＭＯＤ命令とＧＦＡＤＤ命令とを区別するデコード論理により制御されなければならない。複雑な例において、論理は実在的なものであり、そのレジスタファイル読出しにはるかに長い時間がかかる可能性が高い。好ましい実施形態において使用されるアルゴリズムによって必要とされる余分な領域は一般に、各レジスタファイルを読出すために使用される種々のフィールドの数が任意の命令により使用される読出しの最大数と等しくなるように、命令セット設計者が命令のレジスタファイルアクセスフィールドを構成することにより回避可能である。上記の例においてｉｃｌａｓｓ　ｇｆｒでオペランドｇｔがｇｒの代わりに使用されるのはこのためである。
【００４８】
上記のアルゴリズムに対する可能な性能の向上は、各フィールドに対してスケジュールステートメント（以下の“ＴＩＥにおけるマルチサイクル命令”セクションでさらに詳細に説明される）において特定された最小ステージ番号を追跡することである。最小ステージ番号が命令デコードが行なわれるステージ番号より大きい場合、読出しポートの番号を減少させるためにフィールドの多重化（ｍｕｘｉｎｇ）が使用されてもよい。最小ステージ番号が命令デコードステージにある場合、レジスタファイルを読出すために使用された各フィールドに対して別個のポートが使用される。
【００４９】
以下の例を検討する：
【数２】

この場合レジスタファイルＳＲの４つの入力オペランド：ｓｘ、ｓｙ、ｓｕおよびｓｖが存在している。スケジュール情報によると、ｓｕおよびｓｖの両者は第２のパイプラインステージにおいて使用され、したがってサイクル時間に影響を与えることなく単一の読出しポートにマッピングされることができる。その結果、ＳＲレジスタファイルの４つの読出しポートを生成する必要は全くない。この場合、３つの読出しポートのアドレス信号を、ｒｅａｄ　ａｄｄｒ　０，ｒｅａｄ　ａｄｄｒ　１およびｒｅａｄ　ａｄｄｒ　２とすると、３つのアドレスに対する論理は次のようなものとなる：
ｒｅａｄ　ａｄｄｒ　０＝ｘ；
ｒｅａｄ　ａｄｄｒ　１＝ｙ；
ｒｅａｄ　ａｄｄｒ　２＝ｉｎｓｔｌ？ｕ：ｖ；
【００５０】
書込みポートはタイムクリィティカルの程度が低い。非常な短いパイプラインですらサイクル０でレジスタファイルを読出し、サイクル１で計算を行ない、サイクル２でレジスタファイルを書込む。したがって、レジスタファイルを書込むために使用される全てのフィールドをデコードし、それらの間で多重化を行うには多くの時間を要する。もっとクリティカルなタイミングパスはインターロッキングである；サイクル０でレジスタファイルを読出した後、どのレジスタファイルが書込まれているかをサイクル１の始めに知っている必要があるため、レジスタファイルを読出す後続の命令は、必要ならば、その機能が停止されることができる。しかしながら、一般に、１サイクルは、宛先レジスタファイルをデコードし、多重化するのに十分な時間なので、このアルゴリズムは速度に影響を与えずに領域を節約する。
【００５１】
プロセッサパイプラインへのレジスタファイル読出しおよび書込みポートのインターフェースは、コアプロセッサのパイプラインアーキテクチャにしたがって変化する。好ましい実施形態では、この明細書において共に参考文献とされているＤｉｘｉｔ 氏らによる米国特許出願０９／１９２，３９５号明細書およびＫｉｌｌｉａｎ 氏らによる米国特許出願０９／３２２，７３５号明細書に示されているように、コアプロセッサのパイプラインは常に、固定されたパイプラインステージにおいて読出しおよび書込みポートを使用し、この場合４ステージパイプラインレジスタファイルにおいて常に第１のステージの前に読出しポートが使用され、最後（第４）のステージの後に書込みポートが使用される。
【００５２】
各読出しポートはソースオペランドとしてそれを使用する任意の命令の最初のステージで読出され、このようなオペランドを後のステージで使用する命令は最初にレジスタファイルを読出し、そのデータを指定されたステージにステージする。このステージングには、レジスタファイルが読出された後に所望の要素を生成する命令が依然として利用できるように、バイパス多重化もまた含まれている。書込みポートに関して、書込みは、たとえばＷステージ等の命令引渡しステージが後で生じる場合に、そのステージ中の宛先オペランドとしてそれを使用する任意の命令の最後のステージで行なわれる。図１は、好ましい実施形態のレジスタファイル読出しおよび書込みポートに対する概略的な論理を示している。
【００５３】
［バイパス論理］
バイパス論理は図１に示されており、読出しポート論理装置のマルチプレクサによって行なわれる。たとえば、命令がステージ３（ｗｒ０　ｄａｔａ　Ｃ３ ）において結果を生じ、後続する命令がそのデータをステージ１で使用する必要がある場合、読出しポート論理装置の第１のマルチプレクサに対する制御信号は、左側からの第４の入力が選択されるように設定される。その結果、次のクロックサイクルにおいて、その命令に対してデータ（ｒｄ０　ｄａｔａ　Ｃ１ ）が利用可能である。
【００５４】
［インターロック論理］
図２にはインターロック論理が示されている。命令デコーディング論理はスケジュール情報に基づいて、まさに発せられようとしている命令のために、各読出しポート対してｄｅｆＮ信号を発生すると共に各書込みポートに対してｕｓｅＮ信号を発生する。ｕｓｅＮは、命令にはステージＮにおいてその入力レジスタオペランドが必要になるであろうということを示している。ｄｅｆＮは、命令がステージＮにおいてその結果を生成するであろうことを示している。さらに、ある命令に対するｄｅｆＮ信号はパイプライン中の命令と共に伝送される。機能停止信号は、全てのｄｅｆＮとｕｓｅＮ信号の信号の組合せを検査することにより発生される。以下の例は、２つの読出しポート（ｒｄ０およびｒｄ１）と１つの書込みポート（ｗｒ０）を備えた４ステージパイプラインレジスタファイルに対する機能停止論理を示した。信号名称（　Ｃｎ ）中の接尾辞は、その信号がパイプラインのステージｎ中に存在することを示している。
【００５５】
したがって、
【数３】

【００５６】
以下のパールコードは、好ましい実施形態では機能停止コードを開発するために使用される。ｗｆｉｅｌｄ（）およびｒｆｉｅｌｄ（）は、簡単な信号名称、ポート名およびステージ番号から信号名称を構成する機能である。その表記は効率的なファクタ化された形式で書かれる。
【数４】

【００５７】
［書込み論理］
書込みポートアドレスは、好ましい実施形態では、各書込みポートに関連したハードウェア費用を減少させるために多重化されるため、どのオペランドがどのポートを使用するかを決定するアルゴリズムを有することが必要になる。この多重化に対する１つの基準は、必要とされる論理を最小にすることである。ターゲットのパイプラインにおいて、主要な論理装置の費用は書込みポートステージにデータをステージングする費用である。全ての書込みが同じパイプラインステージで行なわれる場合、この論理装置の費用に差はないが、しかし書込みが多数のステージで行なわれる場合には、類似した書込みステージを有する宛先オペランドをひとまとめにすることによって論理が節約されることができる。
【００５８】
以下の例を検討する：
【数５】

ここで、ｉｎｓｔ１はＳＲに対して２つの結果を生成し、１つは３サイクルで生成され、他方は８サイクルで生成されたものである。ｉｎｓｔ２はＳＲに対して９サイクルで１つの結果を生成する。ｉｎｓｔ１には２つの書込みポートが必要であり、ｉｎｓｔ２には１つの書込みポートが必要なので、レジスタファイルＳＲは２つの書込みポートを有していればよい。そのポートをｗｒ０およびｗｒ１とする。ｉｎｓｔ１に対して、書込みポートへのオペランドのマッピングは簡単に、
ｓｘ−＞ｗｒ０
ｓｙ−＞ｗｒ１
である。
【００５９】
これは、ｗｒ０が８つのステージを有する必要があり、ｗｒ１が３つのステージを有する必要があることを意味している。ｉｎｓｔ２に対して、
ｓｚ−＞ｗｒ０
または
ｓｚ−＞ｗｒ１
のいずれかであるという選択肢がある。
【００６０】
しかしながら、２つの選択肢の論理費用は異なっている。ｗｒ０へのｓｚのマッピングは、ｗｒ０にもう１ステージ追加すること（８から９への増加）を意味し、ｗｒ１へのｓｚのマッピングは、ｗｒ１にもう６ステージ追加すること（３から９への増加）を意味する。
【００６１】
好ましい実施形態は、以下のアルゴリズムを使用する。各命令に対して、ステージ番号による降順でオペランドを分類し、それらを書込みポート０乃至書込みポートｎ−１に順次割当てる。したがって、書込みポート０が有するデータチェーンが最長となり、書込みポートｎ−１が有するデータチェーンが最短となる。ｍがｎより小さいｍ個のオペランドを有する命令に対して、それらのオペランドはステージ番号による同様の降順で最初のｍ個の書込みポートにマッピングされる。以下の例は書込みポート割当てプロセスを示すために使用される：
【数６】

【００６２】
上記の書込みポート割当て手順がデータステージング費用を最小化しても、電力消費のような別の費用基準の最適化のためにさらに向上されることができる。上記の例において、ステージング費用を全く増加させずに、ｉｎｓｔ３のｓｗがｗｒ１にマップされることができる。しかしながら、そうすることにより、データがステージ２の終りにレジスタＳＲ中に書込まれた後、パイプラインをパワーダウンする機会が与えられる。
【００６３】
ｓｗをｗｒ０に割当てるには、パイプラインが９サイクルのあいだアクティブである必要がある。以下の手順は、電力消費のような付加的な費用考慮事項に対する書込みポート割当てをさらに改善するための第２のパスとして使用されることができる。
【００６４】
ｍ＜ｎであるｍ個のオペランドを有する各命令ならびに逆の順での各オペランドに関して、オペランドの割当てを新しい書込みポートｉに移し、ここでｉはステージング費用の増加を伴わないで可能な限り大きいものである。前の例を使用してこの手順を説明するために、ｉｎｓｔ１のオペランドはすでに全ての書込みポートを使用しているため、移動することはできない。ｉｎｓｔ２に関して、ｓｚはステージング費用の増加なしにｗｒ１に再度割当てられることはできない。ｉｎｓｔ３に関して、ｓｗはステージング費用の増加なしにｗｒ０からｗｒ１に再度割当てられることができる。
【００６５】
レジスタファイル読出しおよび書込みポートの割当てのためのアルゴリズムに関して多くのバリエーションが可能である。たとえば、いくつかの状況では、データステージングを最小にして消費電力を少くするために厳密に必要とされる個数より多くのポートを設けることが適切かもしれない。読出しおよび書込みポートに関連したハードウェア費用をさらに減少するためにいくつかの命令により必要とされる個数より少いポートを設けることもまた可能である；読出しポートに関して、これはレジスタオペランドを読出すのに多くのサイクルを必要とすることを意味し、書込みポートに関しては、これはあるレジスタ書込みをバッファして、書込みポートの使用されない１サイクル待機することを意味する。別の可能なものは、ＴＩＥコードがレジスタファイル読出しおよび書込みポート割当てを特定して、自動アルゴリズムにより望ましくない結果が生じるケースに対処することを可能にすることである。
【００６６】
拡張レジスタ構成の上記の概念は、Ｎ読出し、Ｍ書込みＢビットＳエントリレジスタファイルを生成するパールプログラムである付録Ｂのコードにおいて使用される。
【００６７】
［ロード／記憶命令］
関連技術の背景において説明されたように、ＴＩＥロードおよび記憶命令は、データをＴＩＥレジスタファイルとの間で転送すると共にデータをＴＩＥレジスタファイルからメモリに直接転送する手段を提供するために必要である。したがって、それらはこの要求により、コアパイプラインのメモリ（Ｍ）ステージのローカルメモリ、すなわちデータキャッシュ、データＲＡＭ、データＲＯＭ等を共用しなければならない。ローカルメモリを共用することに加えて、コアロード／記憶に使用されるその他のハードウェアリソースを可能な限り共用することが望ましい。リソースを共用することにより、領域およびタイミングに関してさらに最適な解決方法が得られる。以下に説明されるように、アドレス計算論理およびデータ整列論理は、コアとＴＩＥロード／記憶との間で共用される２セットのリソースである。
【００６８】
好ましい実施形態において、以下のインターフェース信号がＴＩＥロード／記憶を実施することを要求される：
【数７】

【００６９】
これらの信号の大部分は図４に示されている。図６はＬＳＳｉｚｅ９２７ 、ＭｅｍＤａｔａＯｕｔ＜ｎ＞９０１ およびＭｅｍＤａｔａＩｎ＜ｎ＞９３８ を示している。ＬＳＳｉｚｅはデータ参照のサイズをバイト（好ましい実施形態においては１，２，４，８または１６）で示し、ＭｅｍＤａｔａＯｕｔ＜ｎ＞はＴＩＥセマンティクスからコアへのデータの記憶を行い、ＭｅｍＤａｔａＩｎ＜ｎ＞はコアからＴＩＥセマンティクスへのデータのロードを行う。好ましい実施形態において、＜ｎ＞は８，１６，３２，６４または１２８であってよい。
【００７０】
ＴＩＥロード／記憶のメモリアドレスの計算において、ＴＩＥロードおよび記憶命令のフォーマットがコアのそれと一致する場合、アドレス加算器を共用することが可能である。アドレス加算器の複製は無駄であり、アドレス計算路における付加的遅延を導入する。インターフェース信号は、図４に示されているコアアドレス加算器への入力を表す。このアドレス論理はアドレシングモード：
Ｉ　　ＡＲ［ｓ］＋ｉｍｍｅｄｉａｔｅ
Ｘ　　ＡＲ［ｓ］＋ＡＲ［ｔ］
のサポートを意図されている。
【００７１】
２つのモード間の選択はＬＳＩｎｄｅｘｅｄインターフェース信号によって行なわれる。Ｉ形式により使用されるｉｍｍｅｄｉａｔｅはＶＡｄｄｒＯｆｆｓｅｔ入力上に与えられ、Ｘ形式により使用されるＡＲ［ｔ］値はＶＡｄｄｒＩｎｄｅｘ入力上に与えられる。ＶＡｄｄｒＢａｓｅはＡＲ［ｓ］を与えるために使用される。ＡＲ［ｓ］およびＡＲ［ｔ］以外の他の値がＴＩＥセマンティックブロックによりＶＡｄｄｒＢａｓｅおよびＶＡｄｄｒＩｎｄｅｘ上に与えられることができるが、これらの値を与えることにより、論理最適化は結果的に得られる論理を著しく簡単化することが可能となり、それによってアドレス発生がタイミングクリティカルとなることを阻止する。これは、ＴＩＥ論理からのＶＡｄｄｒＢａｓｅ（ＡＲ［ｓ］）がコアのベースアドレスと同じであることを論理最適化が認識してそれを同じ信号に減少するためである。
【００７２】
ＴＩＥは、この論理に対してコアにより与えられるある修正においてロードおよび記憶整列による利益を得ることができる。整列は大量の論理が実施されることを必要とするため、ＴＩＥに対する複製を回避することにより著しい領域の節約が行なわれる。さらに、複製は重いローディングによるタイミング臨界路を導入することを可能にし、それがローカルメモリの出力および整列ならびにデータセンタク制御信号を強制的に駆動させる。もっとも、整列リソースの共用を実行するために、図５および６に例示されている修正が必要である。
【００７３】
これらの修正は、コアロード／記憶の３２ビットとは対照的にＴＩＥロード／記憶が多数のロード／記憶幅を必要とし／提供することに関連する。これは、整列論理装置内の全てのデータ路がＴＩＥまたはコアデータ幅の最大に整合するように幅を増加させなければならないことを意味する。第２に、ＴＩＥロードは、コアにより要求される単なる右シフトとは対照的に、もっと一般的な整列機能を必要とする可能性が高い。これは、整列論理がＴＩＥ整列機能とコア右シフトとのスーパーセットを行わなければならないことを意味する。
【００７４】
図５は、１２８ビットアクセス幅の３ウェイセット関連データキャッシュ８０３ 乃至８０５ および並列データＲＡＭ８０６ に対する従来技術のコアロード整列論理を示している。この例において、キャッシュされていないデータ入力８０８ はまたキャッシュレフィル都合上１２８ビット幅であるように選択され、データＲＡＭアクセスは、それが３２ビットの最大幅を有するコアロード／記憶によってのみ行なわれるため３２ビット幅である。記憶されたデータが後続するロードにバイパスされなければならない場合に使用される３２ビット幅の記憶データ入力もまた存在する。
【００７５】
使用される主な整列メカニズムは、符号拡張８１４ 乃至８１９ もまたそうであるように、バイトレベルの右シフトにより後続される４：１マルチプレクサ８０９ 乃至８１２ である。シフトの量はロードアドレス８１３ 、８２１ およびワンホットのデコードされたｃｏｒｅＳｉｚｅ信号８２０ により与えられる。記憶およびデータＲＡＭデータは、それらがすでに３２ビット幅なので４：１マルチプレクサを必要としない。その後、一連の後続するマルチプレクサ８２２ 乃至８３３ によって３２ビット幅の整列されたデータが選択され、最終的なコアロードデータ８３４ が得られる。
【００７６】
図６は、この実施形態におけるロード整列構成の一例を示している。主要な違いは、全てのロードデータソース９０６ 乃至９１１ がここでは１２８ビット幅のＴＩＥロード命令をサポートするために１２８ビット幅であり、ロード整列結果もまた１２８ビット幅であることである。この例において、整列自身は、符号拡張素子９２１ 乃至９２５ により後続されるバイトレベルロ−タ９１４ 乃至９１８ を使用して行なわれる。この例では、ＴＩＥセマンティクスがたまたまデータ回転（再び、コアロード整列により要求された単なる右シフトに加えて）を要求しているので、バイトレベル回転子が必要とされている。シフトまたは回転の量は、ロードアドレス９１９ およびワンホットのデコードされたＬＳＳｉｚｅ９２７ またはｃｏｒｅＳｉｚｅ９２６ によって与えられる。最終的なロード整列の出力は、１２８ビット幅全体９３８ がＬＳＳｉｚｅによって特定された多数のロード幅の全てを供給するＴＩＥコプロセッサにより、あるいは３つのコアロード幅３２／１６／８ビットをｃｏｒｅＳｉｚｅにより特定されたものとして供給するコア専用の最下位３２ビット部分９３９ により使用されることができる。
【００７７】
コアはメモリデータに加えて、バーチャルアドレスをセマンティックブロックに戻す。バーチャルアドレスはしばしば、ロードデータに関する付加的な処理のために必要とされる。さらに、これによって、バーチャルアドレスを形成するために使用されるレジスタを修正するロードおよび記憶命令が定義されることが可能になる。たとえばコアＩＳＡの“更新”モードは以下を行う：
ＩＵ　ｖＡｄｄｒ＜−ＡＲ［ｓ］＋ｏｆｆｓｅｔ
ＡＲ［ｓ］＜−ｖＡｄｄｒ
ＸＵ　ｖＡｄｄｒ＜−ＡＲ［ｓ］＋ＡＲ［ｔ］
ＡＲ［ｓ］＜−ｖＡｄｄｒ
【００７８】
ベースアドレスレジスタＡＲ［ｓ］への束にされた書込みにより、多くの内部ループにおける別々のインクリメント命令が回避される。これはＴＩＥにおいて“ｉｎ”を“ｉｎｏｕｔ”に変更して割当てを追加するのと同じくらい簡単に行なわれる。
【００７９】
ベースアドレスレジスタへの束にされた書込みから得られる利益を理解するために、最初に、この特徴を使用しないソフトウェアループを検討する：
【数８】

【００８０】
この例は、その要素が８バイト幅である２つの入力アレイ（ｐｘおよびｐｙ）にわたってループし、計算（ｉｎｓｔ１）を行い、別のアレイ（ｐｚ）中に結果を記憶する。このループにおける７つの命令のうち３つのものがロードおよび記憶命令に対するベースポインタをアドバンスするために使用された。束にされた書込みロードおよび記憶命令を使用するので、この例は以下のコード：
【数９】

で示されるようにはるかに効率的なものになる。
【００８１】
ここで、ｔｉｅ　ｌｏａｄｉｕ（ｔｉｅ　ｓｔｏｒｅｉｕ）は１つの命令で、バーチャルアドレスをｐ＋８として計算し、メモリデータをロード（記憶）してｐをｐ＋８に変更する。この最初の減算は、その最初のものがｐｘ＋８，ｐｙ＋８で始まり、最初にｐｘ＋８に記憶するために、ｐｘ，ｐｙおよびｐｚを補正するために必要とされる。
【００８２】
ここに説明されているロード／記憶インターフェースのようなコア信号のステージ番号はコアパイプラインにより固定され、スケジュール宣言で特定されない。しかしながら、上述のパイプライン挿入アルゴリズムでは適切な値が使用される。たとえば、以下によって、ロードおよび記憶命令が上記のＧａｌｏｉｓフィールド演算ＧＦユニット例に加えられる：
【数１０】

【数１１】

以下は、本発明のためにロードアライナーを生成するｔｐｐ入力である：
【数１２】

【数１３】

以下は、幅１２８に対する出力である：
【数１４】

以下は、幅６４に対する出力である：
【数１５】

以下は、幅３２に対する出力である：
【数１６】

【００８３】
［コアへのインターフェース］
ロードおよび記憶は典型的に、データキャッシュまたは小型データＲＡＭを使用してプロセッサパイプライン内で処理される。費用および正確さの両方のために、新しいロードおよび記憶命令はまた、ＴＩＥおよびコア命令の両方により処理されるキャッシュ／ＲＡＭデータの完全性を維持するためにこのデータキャッシュ／ＲＡＭを使用しなければならない。従来技術のシステムにおいて、コアに加えられた命令はそのコアと論理を共用しなかった。好ましい実施形態では、このような共用のためのメカニズムが提供される。
【００８４】
ＴＩＥ構成：ｉｎｔｅｒｆａｃｅ ＜ｓｎａｍｅ＞＜ｗｉｄｔｈ＞＜ｍｎａｍｅ＞［ｉｎ｜ｏｕｔ］は、ＴＩＥモジュール＜ｍｎａｍｅ＞ にインターフェースする信号＜ｓｎａｍｅ＞ を宣言する。この信号は＜ｗｉｄｔｈ＞ ビット幅であり、それは最後のパラメータに応じてこのＴＩＥコードへの入力または出力のいずれかである。コアへのインターフェースについて、＜ｍｎａｍｅ＞ はコアである。
【００８５】
ＴＩＥｉｃｌａｓｓ構成は、命令により使用されるインターフェース信号を列挙するために拡張される。そのシンタックス（構文）は次のとおりである。
【００８６】
ｉｃｌａｓｓ＜ｃｌａｓｓｎａｍｅ＞
｛＜ｉｎａｍｅ＞， ・・・｝
｛＜ｏｐｅｒａｎｄｓｐｅｃ＞， ・・・｝
｛＜ｓｔａｔｅｓｐｅｃ＞， ・・・｝
｛＜ｉｎｔｅｒｆａｃｅｓｐｅｃ＞， ・・・｝
ここで、＜ｉｎｔｅｒｆａｃｅｓｐｅｃ＞ は ｉｎ＜ｓｎａｍｅ＞または ｏｕｔ＜ｓｎａｍｅ＞ のいずれかであり、＜ｓｎａｍｅ＞ はインターフェース信号名または例外ステートメントで宣言された例外信号名のいずれかである。例外信号名は入力としてではなく、出力としてのみ使用されてもよい。同様にスケジュール構成が拡張され、それによってインターフェース信号名は“ｉｎ”（入力として）または“ｏｕｔ”（出力として）を使用してパイプラインステージ番号を与えられることが可能になる。
【００８７】
セマンティックブロックからの各出力インターフェース信号は、その命令のワンホット命令デコード信号の論理和演算と論理積演算をされ、その出力がそれらのｉｃｌａｓｓのインターフェースセクション中に列挙される。その後、全てのセマンティックブロックからの論理積演算をされたインターフェース信号が論理和演算をされ、コアへの出力信号を形成する。図７は、ＴＩＥコンパイラによる出力インターフェース信号ｓｎａｍｅの構成を示している。ｓｎａｍｅ　ｓｅｍＩはｉ番目のセマンティックブロックにより生成されたｓｎａｍｅの値を表している。ｉＮ１およびｉＮ２は１ビット命令デコード信号であり、ｓｎａｍｅ　ｓｅｍＩ　ｓｅｌは、ｉ番目のセマンティックがｓｎａｍｅを生成する状態を表す信号である。各入力インターフェース信号は、その信号を使用するモジュールに直接供給される。
【００８８】
［ＴＩＥにおけるコンパイラ／ＯＳサポート］
ここまではＴＩＥ構成は、状態および命令が規定されることを可能にしているが、しかしこれらの命令がソフトウェアによりどのようにして自動的に使用されるかに関する手掛かりを与えていない。従来技術のシステムでは、使用される命令は全て、アプリケーション中に書込まれたイントリンシックスによって参照された。したがって、コンパイラはイントリンシックスを命令上にマップするためだけに必要とされ、命令自身の使用方法を知るために必要とはされなかった。ユーザ定義可能なレジスタファイルの追加により、コンパイラがプログラム変数をレジスタファイルの要素に割当てることが望ましいことになる。レジスタ割当て中、コンパイラは、レジスタファイル中に含まれるレジスタにプログラム値を割当てようと試みる。プログラム中のある位置において、全ての値がレジスタに割当てられることができない。これらの位置では、１以上の値がメモリに移動されなければならない。値をレジスタからメモリに移動するには記憶装置が必要であり、値をメモリからレジスタに移動するにはロードが必要である。したがって、最低限、コンパイラは値をメモリからレジスタにロードする方法および値をレジスタからメモリに記憶する方法を知っていなければならない。
【００８９】
レジスタ割当て中、コンパイラが値を１つのレジスタから別のレジスタへ移動させることも必要である。たとえば、１つの機能により生成された値はレジスタＡに戻され、次の命令には、その値がレジスタＢから使用されることが必要かもしれない。コンパイラは、最初にレジスタＡを一時記憶位置に記憶し、その後その記憶位置からレジスタＢにロードすることにより値をレジスタＡからレジスタＢに移動させることができる。しかしながら、値をレジスタＡからレジスタＢに直接移動するほうが、おそらくもっと効率的である。したがって、１つのレジスタから別のレジスタへの値の移動方法をコンパイラが知っていることは、必須ではないが、望ましい。
【００９０】
保存および再生シーケンスは、個々のレジスタの保存および再生シーケンスの単なる連結より複雑かもしれない。全レジスタファイルをしたとき、性能および、またはスペース節約対スピル（ｓｐｉｌｌ）命令の明らかな連結の機会が生じる可能性がある。これはまた、レジスタファイル中には存在しないコプロセッサ状態を含む可能性がある。
【００９１】
各コプロセッサの状態は、種々の異なった潜在的に相互依存したコンポーネントから成る。これらのコンポーネントを保存および再生するために使用される命令シーケンスは、相互依存性に依存している可能性がある。
【００９２】
相互依存情報はグラフとして表されることができる。グラフが周期的である場合、その状態を成功的に保存することはどの時点でも不可能である。しかし、依存グラフが非周期的（ＤＡＧ）であるならば、コプロセッサの状態の全てが任意の時点で保存および再生されることができるように、コンポーネントの保存および再生を配列（ｏｒｄｅｒ）する方法が存在する。
【００９３】
ＴＩＭコンパイラは標準的なグラフ構成および解析アルゴリズムを使用して、この依存情報を生成し、解析し、所定のコプロセッサに対する保存および再生シーケンスを生成したときにこの情報を考慮する。
【００９４】
たとえば、ｒｅｇｆｉｌｅ　ａおよびｒｅｇｆｉｌｅ　ｂという２つのレジスタファイルを有するコプロセッサを考慮する。ｒｅｇｆｉｌｅ　ａは４つの３２ビットレジスタを有し、ｒｅｇｆｉｌｅ　ｂは１６の１２８ビット値を有している。付加的な状態は、ｒｅｇ　ｔｏｕｃｈｅｄと呼ばれるタッチされているレジスタのビットフィールド、ならびにｒｅｇ　ｂａｃｋと呼ばれるｒｅｇｆｉｌｅ　ａのプッシュレジスタ・ツー・バックレジスタ０である。コプロセッサは以下のロードおよび記憶命令を供給して、そのコプロセッサ状態を保存および再生する：
【数１７】

この場合、この保存状態依存性に対するＤＡＧは、次のように見える：
ｒｅｇ　ｔｏｕｃｈｅｄ＜−− ｒｅｇｆｉｌｅ　ａ，ｒｅｇｆｉｌｅ　ｂ，
ｒｅｇ　ｂａｃｋ
これは、このコプロセッサに対するＴＩＥにより、ｒｅｇｆｉｌｅ　ａ，ｒｅｇｆｉｌｅ　ｂまたはｒｅｇ　ｂａｃｋがタッチされているのでｒｅｇ　ｔｏｕｃｈｅｄは任意の時点で変化するように構成されているためである。
【００９５】
ｒｅｇｆｉｌｅ　ａ＜−− ｒｅｇ　ｂａｃｋ
これは、ｒｅｇｆｉｌｅ　ａでレジスタを保存するには、ｒｅｇｆｉｌｅ　ａ中にフリーレジスタを必要とするためである。ｒｅｇｆｉｌｅ　ａ中のフリーレジスタを獲得するには、そのレジスの値がｒｅｇ　ｂａｃｋ通って移動される必要がある。これはｒｅｇ　ｂａｃｋの現在の値を破壊する。
【００９６】
ｒｅｇｆｉｌｅ　ａ＜−−−− ｒｅｇｆｉｌｅ　ｂ
これは、ｒｅｇｆｉｌｅ　ｂに対する保存命令が、記憶すべきものへのアドレスとしてｒｅｇｆｉｌｅ　ａ中のレジスタを使用するためである。これは、ｒｅｇｆｉｌｅ　ａがすでに記憶されている場合にのみｒｅｇｆｉｌｅ　ｂが記憶されることが可能であることを意味する。これは、例示を簡単にするための説明に過ぎず、実際はｒｅｇｆｉｌｅ　ａ中のレジスタは１つだけである。
【００９７】
このようにして、保存シーケンスは、その状態が適切な順序で保存されることを確実にする。この場合、その順序は：
ｒｅｇ　ｔｏｕｃｈｅｄ，ｒｅｇ　ｂａｃｋ，ｒｅｇｆｉｌｅ　ａ，
ｒｅｇｆｉｌｅ　ｂ
【００９８】
さらに、好ましい実施形態により、組込みタイプの標準プログラミング言語（たとえば、Ｃにおける６４＋ビットまたは上述したような飽和演算）で表されることのできない構成要素を有するレジスタファイルの定義がことが可能となるため、規定されたハードウェアに一致するように新しいタイプを追加するメカニズムを有している必要がある。プログラミング言語タイプはまた、変数がどのレジスタファイルに割当てられるかを決定するのに有用である。
【００９９】
たとえば、整数計算命令は整数レジスタファイル中のそれらのオペランドだけを採用し、浮動小数点命令は浮動小数点レジスタファイル中のそれらのオペランドだけを採るので、多くのＩＳＡでは整数値を１つのレジスタファイルにマップし、浮動小数点値を別のレジスタファイルにマップすることが一般的である。新しいデータタイプを生成する能力が与えられた場合、組込みタイプと新しいタイプとの間および異なった新しいタイプ間で可能な変換を特定するメカニズムを有していることが望ましい。たとえば、Ｃプログラミング言語では、ｃｈａｒタイプ変数とｓｈｏｒｔタイプ変数との間の変換が可能である（ｃｈａｒタイプを符号またはゼロ拡張することにより）。
【０１００】
ＴＩＥ構成：ｃｔｙｐｅ＜ｔｎａｍａ＞＜ｓｉｚｅ＞＜ａｌｉｇｎｍｅｎｔ＞＜ｒｆｎａｍｅ＞は、プログラミング言語タイプ＜ｔｎａｍａ＞を生成し、それがメモリ中の＜ａｌｉｇｎｍｅｎｔ＞ビット境界に整列された＜ｓｉｚｅ＞ビットであり、これが＜ｒｆｎａｍｅ＞に割当てられることを宣言する。
【０１０１】
たとえば、Ｇａｌｏｉｓフィールド演算ＧＦユニットに関して続けると、ステートメントｃｔｙｐｅ　ｇｆ８　８　８　ｇｆは、８ビット値を８ビットメモリ境界で整列させる“ｇｆ８”と名付けられた新しいタイプ（好ましい実施形態ではＣプログラミング言語に対する）を宣言し、これらの値は必要に応じて“ｇｆ”レジスタファイルに割当てられるレジスタである。
【０１０２】
ＴＩＥ構成：ｐｒｏｔｏ＜ｐｎａｍｅ＞｛＜ｏｐｓｅｃ＞，…｝｛＜ｔｐｓｅｃ＞，…｝｛＜ｉｎｓｔ＞…｝は、コンパイラがイントリンシックスのオペランドに関するタイプ情報を知っているか、あるいはそれを提供しなければならない種々の機能を行う命令シーケンスを特定するために使用される。＜ｏｐｓｅｃ＞はオペランドタイプ仕様であり、＜ｔｓｐｅｃ＞は命令シーケンスにより必要とされる一時レジスタ仕様であり、＜ｉｎｓｔ＞はシーケンスの命令である。
【０１０３】
＜ｏｓｐｅｃ＞の構文は、
［ｉｎ｜ｏｕｔ｜ｉｎｏｕｔ］＜ｔｙｐｅｎａｍｅ＞［＊］＜ｏｎａｍｅ＞
であり、ここで＜ｏｎａｍｅ＞はシーケンスの命令（＜ｉｎｓｔ＞）に置換されてもよいオペランド名である。＜ｔｙｐｅｎａｍｅ＞はオペランドのタイプ名である（オプションのアステリスクが与えられている場合は、そのタイプに対するポインタである）。
【０１０４】
一時レジスタ仕様＜ｔｓｐｅｃ＞の構文は、
＜ｒｆｎａｍｅ＞＜ｏｎａｍｅ＞
であり、ここで＜ｏｎａｍｅ＞は、シーケンスの命令（＜ｉｎｓｔ＞）中に代入されてもよいオペランド名称である。＜ｔｙｐｅｎａｍｅ＞は、＜ｏｎｍｅ＞がこのシーケンスに一時的に割当てられなければならないレジスタファイルを識別するタイプ名称である。
【０１０５】
シーケンス中の命令＜ｉｎｓｔ＞の構文は、
＜ｉｎａｍｅ＞［＜ｏｎａｍｅ＞｜＜ｌｉｔｅｒａｌ＞］，…；
であり、ここで＜ｉｎａｍｅ＞は命令名であり、＜ｏｎａｍｅ＞は＜ｏｓｐｅｃ＞または＜ｔｓｐｅｃ＞で宣言されたオペランド名称であり、＜ｌｉｔｅｒａｌ＞は、ｐｒｏｔｏにより特定された命令シーケンスを発生したときにコンパイラにより不変のまま使用される定数またはストリングである。
【０１０６】
ｐｒｏｔｏの１つの使用法は、イントリンシックスを規定するために単にタイプを命令オペランドと関連付けることである。この場合、＜ｐｎａｍｅ＞は命令の名称である；＜ｏｓｐｅｃ＞はｉｃｌａｓｓオペランド仕様に一致する（タイプ名称が追加されることを除いて）；＜ｔｓｐｅｃ＞リストは空でなければならない。また＜ｉｎｓｔ＞シーケンスは単一の命令から構成されていなければならない。一例を以下に示す：
【数１８】

【０１０７】
ｐｒｏｔｏの別の使用法は、マルチ命令イントリンシックを規定することである。ここでは＜ｔｓｐｅｃ＞は空でなくてもよい。たとえば：
【数１９】

【０１０８】
ｐｒｏｔｏの付加的な使用法は、ｃｔｙｐｅＴＩＥ構成を使用して宣言されたプログラミング言語タイプの値のロードおよび記憶方法をコンパイラに命令することである。前に述べたように、メモリとの間でやり取りされる値をロードおよび記憶することができるには、コンパイラがレジスタ割当てを行い、レジスタファイルの内容がタスクスイッチで保存および復元されることを可能にする必要がある。
【０１０９】
各ｃｔｙｐｅ＜ｔｎａｍｅ＞宣言に対して、以下の形式のｐｒｏｔｏ宣言が存在しなければならない：
【数２０】

【０１１０】
＜ｔｎａｍｅ＞　ｌｏａｄｉ　ｐｒｏｔｏは、タイプ＜ｔｎａｍｅ＞の値をメモリからレジスタ中にロードするために使用されなければならない命令シーケンスをコンパイラに知らせる。＜ｔｎａｍｅ＞　ｓｔｏｒｅｉ　ｐｒｏｔｏは、タイプ＜ｔｎａｍｅ＞の値をレジスタからメモリ中に記憶するために使用されなければならない命令シーケンスをコンパイラに知らせる。
【０１１１】
前に述べたように、コンパイラは、値が１つのレジスタから別のレジスタにどのように移動すべきかを知っていることが望ましい。ロードおよび記憶によるように、ｐｒｏｔｏはレジスタ間において値をどのように移動すべきかをコンパイラに命令するために使用される。各ｃｔｙｐｅ＜ｔｎａｍｅ＞宣言に対して、以下の形式のｐｒｏｔｏ宣言が存在する可能性がある：
【数２１】

【０１１２】
たとえば、Ｇａｌｏｉｓフィールド演算ＧＦユニットに関して続けると、ｐｒｏｔｏ宣言：
【数２２】

は、コンパイラにｇｆ８変数のレジスタ割当てを行わせるように好ましい実施形態に入力される必要がある；それらはまた、ｇｆレジスタファイルに対するタスク状態スイッチシーケンスを生じさせるために入力される必要がある。
【０１１３】
ｐｒｏｔｏの最後の使用法は、組込みタイプと新しいタイプとの間および異なった新しいタイプ間で可能な変換を規定することである。変換プロとタイプは必要ない；たとえば、新しいタイプＡと新しいタイプＢとの間の変換が特定されていない場合、コンパイラはタイプＡの変数がタイプＢの変数に変換されることを可能にしない。新しいまたは組込みタイプ＜ｔ１ｎａｍｅ＞および＜ｔ２ｎａｍｅ＞（組込みタイプであることが可能なのは多くてその１つ；このメカニズムは２つの組込みタイプ間の変換の仕様を許さず、これは、その変換がプログラミング言語よりすでに規定されているためである）の各対に対して、以下の形式の３つまでのｐｒｏｔｏ宣言が存在することができる：
【数２３】

【０１１４】
たとえば、Ｇａｌｏｉｓフィールド演算ＧＦユニットに関して続けると、ｐｒｏｔｏ宣言：
【数２４】

は、メモリ中のタイプｃｈａｒの変数とレジスタ中のタイプｇｆ８の変数との間の変換を可能にする。これらのｐｒｏｔｏに対して、以下の例は、ｃｈａｒタイプの２つのベクトルがＧＦＡＤＤイントリンシックを使用してどのようにして付加されるかを示している：
【数２５】

【０１１５】
従来技術のシステム（たとえば、ＧＮＵ　Ｃコンパイラ）では、コンパイラは各プログラム変数およびコンパイラ発生一時変数に対するタイプ情報を維持する。これらの組込み変数タイプは、高レベル言語タイプ（たとえば、Ｃ、ｃｈａｒ、ｓｈｏｒｔ、ｉｎｔ、ｆｌｏａｔ、ｄｏｕｂｌｅ等）に対応する。各組込みタイプに対して、コンパイラは、タイプの名称、そのタイプに対するサイズおよび整列要求、ならびにそのタイプの値が割当てられなければならないレジスタファイルを知っていなければならない。新しいタイプに関して、この情報はｃｔｙｐｅ言語構成により提供される。ｃｔｙｐｅ情報を使用して、コンパイラはそのタイプを表すために内部タイプ構造を発生し、組込みタイプに対して行われたものと同じ方法でプログラム変数およびコンパイラ発生一時変数に対してそのタイプを使用する。
【０１１６】
従来技術のＧＮＵ　Ｃコンパイラは、列挙されたタイプｍａｃｈｉｎｅ　ｍｏｄｅを使用してタイプを内部的に表す。関連したタイプはクラスでまとめられ、列挙されたタイプｍｏｄｅ　ｃｌａｓｓによって記述される。新しいタイプをサポートするために、当業者は、ユーザ定義タイプを表わしているタイプのクラスを表すためにｍｏｄｅ　ｃｌａｓｓにイニューマレータを追加することができ、ｃｔｙｐｅＴＩＥ言語構成を使用して宣言された新しいタイプのそれぞれに対してｍａｃｈｉｎｅ　ｍｏｄｅに１つのイニューマレータを追加することができる。たとえば、新しいタイプを表わすクラスがＭＯＤＥ　ＵＳＥＲと呼ばれると仮定すると、ファイルｍａｃｈｍｏｄｅ．ｈでのｍｏｄｅ　ｃｌａｓｓの定義は以下のようになる：
【数２６】

【０１１７】
イニューマレータは、ファイルｍａｃｈｍｏｄｅ．ｄｅｆにラインを挿入することによってｍａｃｈｉｎｅ　ｍｏｄｅに追加される。各ラインは新しいタイプ、そのクラスおよびそのサイズ（８ビットバイトで与えられる）を規定する。ユーザ定義タイプに対するイニューマレータは、Ｕ＜ｎ＞ｍｏｄｅと名付けられ、ここで０＜ｎ＞はゼロとユーザ定義タイプの総数との間の数である。たとえば、前に説明した例からのユーザ定義タイプｇｆ８を表わすために内部タイプを追加するために、以下のラインが追加される：
ＤＥＦ　ＭＡＣＨＭＯＤＥ（Ｕ０ｍｏｄｅ，“Ｕ０”，ＭＯＤＥ　ＵＳＥＲ，１，１，ＶＯＩＤｍｏｄｅ）
その後、当業者はＧＮＵ　Ｃコンパイラにより与えられた解析および最適化を修正し、ＭＯＤＥ　ＵＳＥＲクラスのタイプに関して正しく行うことができる。
【０１１８】
従来技術のコンパイラにおいて、コードセレクタ（またはコード発生器）は、内部的に表わされた各命令を低レベル命令のシーケンス（アセンブリ言語に多かれ少かれ対応している）で置換することができる。コードセレクタは、内部命令によって行われた動作の検査および命令に対するオペランドのタイプにより置換すべき命令シーケンスを決定する。たとえば、ａｄｄを表わす内部命令はタイプｉｎｔの２つの値を入力として有し、またタイプｉｎｔの１つの値を出力として有している；あるいは、タイプｆｌｏａｔの２つの値を入力として有し、またタイプｆｌｏａｔの１つの値を出力として有していてもよい。入力および出力値のタイプに基づいて、コードセレクタは整数加算を行う命令のシーケンスまたは浮動小数点加算を行う命令のシーケンスのいずれかを選択する。ユーザ定義タイプに対して、ロード、記憶、移動および変換ｐｒｏｔｏ定義は、ユーザ定義タイプを有する１以上のオペランドを有する内部命令と置換するための命令シーケンスを記述する。Ｇａｌｏｉｓフィールド演算ＧＦユニットの例で続けると、内部命令がｇｆ８値のロードを表わす場合、コードセレクタはｇｆ８　ｌｏａｄｉ　ｐｒｏｔｏを調べて、その命令と置換されるべき命令シーケンスを決定する。
【０１１９】
従来技術のＧＮＵコンパイラにおいて、ターゲットのプロセッサにおいて利用可能な命令は、命令パターンを使用して記述される；さらに詳細な情報はたとえば文献［Ｓｔａｌｌｍａｎ， “ｕｓｉｎｇ ａｎｄ Ｐｏｒｔｉｎｇ ＧＮＵ ＣＣ”（１９９５）］に記載されている。これらの命令パターンは、オペランドの番号およびタイプを含む命令を記述している。コンパイラにおいてユーザ定義タイプをサポートするために、ロード、記憶、移動および変換ｐｒｏｔｏは、コンパイラによって期待される命令パターンに変換される。たとえばｇｆ８　ｌｏａｄ　ｐｒｏｔｏは以下のパターンにより表わされる（ｇｆ８　ｃｔｙｐｅがｍａｃｈｉｎｅ　ｍｏｄｅイニューマレータＵ０ｍｏｄｅにマップされていると仮定する）：
【数２７】

【０１２０】
一時レジスタを特定するｐｒｏｔｏは、適切なタイプのオペランドの重書きあるいは“クロッバー”を行う命令パターンに変換される。コンパイラは、クロッバーされたオペランドがその命令の位置で使用されないことを保証するため、その命令はそれを一時的なものとして使用することができる。たとえば、ユーザ定義タイプｔｔに対する以下のロードｐｒｏｔｏはクロッバーを含む命令パターンを発生する：
【数２８】

【０１２１】
［イントリンシック機能宣言］
Ｋｉｌｌｉａｎ 氏他による米国特許出願では、ＧＮＵａｓｍステートメントを使用する機能として全てのＴＩＥ命令の定義を含んでいるイントリンシック機能宣言ファイルが発生される。とくに、各命令機能は、そうしないと発生する可能性の高い最適化を抑制するＣ揮発性プロパティにより識別される。この方法は安全であるが、ＴＩＥ命令が安全に再度順序付けされることができる場合、あるコンパイラ最適化を阻止する。本発明は、従来技術のシステムを２つの方法で改善する。第１に、ロードおよび記憶命令だけが揮発性として宣言され、したがってコード最適化中に命令を再度順序付けする最大自由度をコンパイラに提供する。第２の改善では、特別なユーザ宣言されたステートメントを使用する命令が明示的な状態アーギュメントにより宣言され、したがって命令の副作用に関するさらに正確な情報をコンパイラに提供する。以下のヘッダファイルは、ＧＦ例中の全ての命令をイントリンシック機能として宣言するためにＴＩＥコンパイラから発生される：
【数２９】

【数３０】

【０１２２】
上記のサンプル出力において、ＧＦＡＤＤ８Ｉのような演算命令は揮発性として宣言されない。ＬＧＦ８　Ｉのようなロードおよび記憶命令は揮発性として宣言される。ＧＦＲＷＭＯＤ８のようなプロセッサ状態を読出すか、あるいは書込む命令は、これらの命令に副作用があることをコンパイラに信号で伝えるもう１つのアーギュメント　ｘｔ　ｓｔａｔｅを有している。
【０１２３】
［レジスタ割当て］
従来技術のシステム（たとえば、ＣＮＵ　Ｃコンパイラ）は、可搬性のために設計されたレジスタ割当てアルゴリズムを含んでいる。可搬性のために、コンパイラは種々のＩＳＡをサポートすることが必要になる。これらのＩＳＡは、それら自身は構成可能でもなく、拡張可能でもないが、それらの任意のものをターゲットにしなければならないコンパイラは、レジスタ割当てに対する一般的なアプローチをとらなければならない。したがって、従来技術のシステムは多レジスタ割当てを許すことが可能であり、あるものはプログラミング言語タイプをあるレジスタファイルに制限することが可能である。
【０１２４】
従来技術のＧＮＵ　Ｃコンパイラは、ターゲットのマシン記述を修正することにより任意の数のレジスタファイルが特定されることを可能にする。当業者は、文献“Ｕｓｉｎｇ ａｎｄ Ｐｏｒｔｉｎｇ ＧＮＵ ＣＣ”に記載されているように、ターゲットに対するマシン記述を修正することによって１以上の新しいレジスタファイルのためにＧＣＣにサポートを追加することができる。
【０１２５】
各ＴＩＥ　ｒｅｇｆｉｌｅ構成に対して、コンパイラは、そのレジスタファイル中のレジスタに値を割当てるように自動的に構成される。ｒｅｇｆｉｌｅ構成は、レジスタファイル中のレジスタの数を示している。上述のように、ＴＩＥ　ｃｔｙｐｅ構成は、そのタイプのその値が割当てられなければならないレジスタファイルを特定する。コンパイラは、ユーザ定義タイプを有する各プログラム値を割当てようと試みるときに、この情報ならびにレジスタファイル中のレジスタの数を使用する。Ｇａｌｏｉｓフィールド演算ＧＦユニット例で続けると、ｇｆレジスタに対するｒｅｇｆｉｌｅ構成は：
ｒｅｇｆｉｌｅ　ｇｆ　８　１６　ｇ
【０１２６】
これは、それぞれがサイズ８ビットの１６個のｇｆレジスタが存在していることを示す。ｇｆ８タイプに対するｃｔｙｐｅ構成は：
ｃｔｙｐｅ　ｇｆ８　８　８　ｇｆ
であり、タイプｇｆ８の値がｇｆレジスタファイルに関連付けられなければならないことを示している。このようにして、コンパイラはタイプｇｆ８の全ての値を、１６個のレジスタを有するｇｆレジスタファイルに割当てる。
【０１２７】
［命令のスケジューリング］
従来技術のシステム（例えばＧＮＵ　Ｃコンパイラ）はパイプライン機能停止（ストール）を減少することにより性能を向上するために命令を再度出す命令スケジューリングアルゴリズムを含んでいる。これらのアルゴリズムは発行幅等等のパイプラインの制限と機能装置の有効性とを満たしながら、さらにストールサイクルを最少にする命令発注を決定するためにターゲットプロセッサのパイプラインをシミュレートすることにより動作する。
【０１２８】
従来技術のＧＮＵ　Ｃコンパイラは、任意の対の命令に対して、１つの命令が直ちに次々にスケジュールされる場合に生じるストールサイクル数を決定することによりプロセッサのパイプラインをシミュレートとする。各命令対のストール情報に基づいて、コンパイラは総ストールサイクルを最小にする命令の発注を発見しようとする。新しいＴＩＥ命令では、コンパイラはＴＩＥ言語スケジュール構成により与えられる情報を使用することによりストールサイクルを決定する。命令Ｂが命令Ａのすぐ後にスケジュールされる場合に生じるストール数を決定するために、コンパイラはＡの各出力オペランドの書込みのためのパイプラインステージをＢの各対応する入力オペランドの読込みのためのパイプラインステージと比較する。各オペランドに対しては、これらの値の差プラス１（規定されたオペランドパイプラインステージ値に対するスケジュール構成のセマンチックのため）はストールを避けるためにＡをＢから分離しなければならない最小数のサイクルを示している。値１はストールせずにＢがＡの後すぐにスケジュールされることができることを示しており、値２はＡが１ストールサイクルを生じたすぐ後にＢをスケジュールすることを示しており、以下同様である。Ａにより書かれる全てのオペランドにわたる最大のストール値はＢがＡのすぐ後にスケジュールされる場合に生じるストールサイクル数である。
【０１２９】
以下の例のスケジューリング構成を考慮する。
【数３１】

【０１３０】
以下のコードシーケンスでは、ＡＬＤ命令のｘｔオペランドはＡＡＤＤ命令のｘａオペランドと同じである。したがって、ＡＡＤＤ命令はストールを避けるためＡＬＤ後に（ｄｅｆ　ｘｔ）−（ｕｓｅ　ｘａ）＋１＝２−１＋１＝２サイクルをスケジュールされなければならない。ＡＡＤＤがＡＬＤのすぐ後にスケジュールされるならば、１つのサイクルストールが存在する。
ＡＬＤ　　ｘ３，　ａ０，　０
ＡＡＤＤ　ｘ０，　ｘ３，　ｘ１
以下のコードシーケンスでは、ＡＬＤ命令のｘｔオペランドｘ３はＡＡＤＤ命令のｘｂオペランドと同一である。したがって、ＡＡＤＤ命令はストールを避けるためにＡＬＤ後に（ｄｅｆ　ｘｔ）−（ｕｓｅ　ｘｂ）＋１＝２−２＋１＝１サイクルをスケジュールされなければならない。この場合、ＡＡＤＤがＡＬＤのすぐ後にスケジュールされるならば、ストールは存在しない。
ＡＬＤ　　ｘ３，　ａ０，　０
ＡＡＤＤ　ｘ０，　ｘ１，　ｘ３
【０１３１】
［レイジー状態スイッチ］
レジスタファイルをプロセッサに付加することは、ほとんどの実時間オペレーティングシステムにより実行されるようなマルチタスク環境ではタスク切換えの一部分としてセーブされ回復されなければならない状態の量を著しく増加する。付加的な状態はしばしばタスクのサブセットで実行されるある計算に特定であるので、そうすることはタスク切換えサイクルカウントを不必要に増加する理由で、タスク切換え毎にこの付加的な状態をセーブし回復することは望ましくない。これはまた解決策が従来技術にあるので拡張可能ではないプロセッサでは問題である。例えばＭＩＰＳ　Ｒ２０００　ＣＰＥＮＡＢＬＥビットは１つのタスクから別のタスクへのコプロセッサのレジスタの“レイジー（ｌａｚｙ）”切換えを可能にする。好ましい実施形態はレイジー切換えがプロセッサ拡張により生成される状態に適用されることを可能にする（ＴＩＥ状態およびｒｅｇｆｉｌｅ 宣言）。
【０１３２】
これはセーブおよび回復動作では最も複雑なものの１つである。幾つかの理由で複雑である。即ち、文脈切換えから遅延される時間点で生じることと、実行時間が各プロセッサファイルの妥当性を管理しなければならないことと、コア自体が例外が生じたときにコプロセッサの妥当性を変更することが理由である。
【０１３３】
これがどのように対処されることができるかを示すため、２つのタスクＡ、Ｂを有するシステムが存在すると仮定する。また２つのコプロセッサレジスタｃｐ　０とｃｐ　１も存在する。システムの状態はコアにより維持されている有効なビットと、実時間により維持されているレジスタファイルオウナー記録からなる。その後、以下の表１で示されている事象のシーケンスを考慮する。この例ではコプロセッサの状態は各タスクのスタックのベースに記憶されていると仮定される。
【表１】

【表２】

　　　　　　　　　　　　　　　　　表１
【０１３４】
レイジー切換え機構はアクセスがエネーブルまたはディスエーブルされることができるセットへグループ化される状態を必要とし、ディスケーブルされた状態へのアクセスは例外を生成し、例外ハンドラは切換えられなければならない状態を決定でき、例外ハンドラはメモリにセーブされ、メモリから状態および再エネーブルされたアクセスを回復する。
【０１３５】
好ましい実施形態では、ＴＩＥは、
ｃｏｐｒｏｃｅｓｓｏｒ ＜ｃａｍｅ＞ ＜ｃｕｍｂｅｒ＞ ｛ ＜ｓｎａｍｅ＞，．．．｝
を構成し、＜ｓｎａｍｅ＞，．．． により名称を付けられた状態がレイジー切換えの目的でグループされていることを宣言する。このグループ化は名称＜ｃａｍｅ＞と、０乃至７の範囲の番号＜ｃｕｍｂｅｒ＞を与えられる。任意の＜ｓｎａｍｅ＞，．．． が１よりも多数のコプロセッサステートメントで名称を付けられるならば、これはエラーである。
【０１３６】
前述の構成では、命令のリストが生成され、これはｉｃｌａｓｓのｉｎ／ｏｕｔ／ｉｎｏｕｔリストでは＜ｓｎａｍｅ＞ を有する。信号がその後生成され、これはこれらの命令に対する命令のワンホットデコードのＯＲである。この信号はＣＰＥＮＡＢＬＥビットの補数によりＡＮＤ処理される。各プロセッサで生成されるこれらの信号はその後、以下の例外セクションで詳細に説明する例外を生成するＴＩＥソースコードと結合される。全てのコプロセッサのディスエーブルされた例外はＴＩＥソースコードからの任意の例外よりも高い優先順位を有する。コプロセッサのディスエーブルされた例外の間には最も低い番号の例外が優先順位を有する。
【０１３７】
好ましい実施形態のコアプロセッサでは、異なる例外は全て同一のベクトルを使用し、例外によりＥＸＣＣＡＵＳＥレジスタへロードされたコードによって弁別される。コアプロセッサはこれらの例外に対して８つのコーズコード（３２から３９）を予約する。コプロセッサステートメントに応答して、ＴＩＥコンパイラはビット＜ｃｕｍｂｅｒ＞をＣＰＥＮＡＢＬＥレジスタへ付加し、＜ｃｕｍｂｅｒ＞がクリアであり任意の命令アクセス＜ｓｎａｍｅ＞，．．． が実行されるならば、例外を生成させるために論理をプロセッサへ付加し、その例外がコアにより認識されるとき３２＋＜ｃｎｕｍｂｅｒ＞ をＥＸＣＣＡＵＳＥレジスタへロードするため論理をプロセッサへ付加する。
【０１３８】
［ＴＩＥ中のマルチサイクル命令］
従来のプロセッサ技術では、多数のサイクルの計算を必要とする命令は、計算の組合わせ論理をパイプライン処理し、まだ計算されていない結果に基づく命令が発行されることを防止するために付加的な論理装置を必要とする。さらに、このようなプロセッサのコンパイラはパイプラインストールを最小にするために命令を再整列するためのアルゴリズムを含むべきである。
【０１３９】
最初のアイテムは典型的に慎重に選択された位置で挿入されるパイプラインレジスタを有する論理を書込むことによりプロセッサ設計者により実行される。第２のアイテムは典型的に、発行される命令のソースオペランドをパイプラインの全てのまだ計算されていない目的地オペランドに対して比較し、一致が存在するならば命令を保持することにより実行される。
【０１４０】
これらの３つのアイテムは調節されなければならない。計算論理のパイプライン処理が変化を発行論理に一致しないならば、プロセッサは不正確な結果を生む。パイプラインストールを最小にするために再整列することが組合わせ論理のパイプライン化と一致しないならば、次善の性能が生じる（例えば、準備される前に結果の使用をスケジュールすることはパイプラインストールを生成する）。
【０１４１】
以下の例を採用する。
【数３２】

【０１４２】
ＭＵＬ論理が２サイクルにわたって実行されるが、制御論理が１つの命令をサイクル毎に発行するならば、ａ３はＡＤＤ命令がそれを必要とするときに正確な値をもたないので、ａ６は不正確な結果を有する。正確であるように、発行論理はＭＵＬが２つのステージにわたってパイプライン処理され、ＡＤＤ命令を発行する前に１サイクルストールすることを知らなければならない。ＡＡ命令を１サイクルだけストールすることが正確な論理を生んでも、最適な性能は与えない。ＡＤＤとＳＵＢ命令の順序を切換えることにより、この例ではもはや任意の命令をストールする必要はなく、それ故最適な性能を生じる。これはＭＵＬ論理の実行と、命令発行論理の実行と、命令の再整列（スケジューリング）との間での適切な調節によってのみ実現されることができる。
【０１４３】
従来技術のシステムでは、これらの３つのアイテム（パイプライン論理、パイプラインストール、命令の再スケジューリング）はしばしば別々に実行され、調整をより困難にし、設計確認要求を増加する。本発明の好ましい実施形態はこれらの特徴で必要とされる情報を一度特定し、その仕様からプロセッサ発生器で３つのアイテムを実行する方法を提供する。
【０１４４】
さらに、好ましい実施形態の命令セットシミュレータはそのタイミングモデルで情報をスケジュールする同一の仕様を使用する。これは好ましい実施形態の全ての特徴を使用するアプリケーションディベロッパが、低速度のＨＤＬシミュレータでアプリケーションを実行するのではなく、ハードウェアが組み立てられる前に性能の良好な予測を獲得することを可能にする。
【０１４５】
ここで参考文献とされているＫｉｌｌｉａｎ とＷａｒｔｈｍａｎのＸｔｅｎｓａ（商標名）命令セットアーキテクチャ（ＩＳＡ）基準マニュアルの第１０章は、プロセッサパイプラインの性能のモデル化に使用され、パイプラインストールを最小にするための従来技術で使用されているパイプラインハードウェアを説明する方法を開示している。しかしながら、好ましい実施形態では、この説明は前述した最初の２つのアイテムで付加的に使用される。
【０１４６】
特に、ＴＩＥ言語は以下の宣言を含んでいる。
【数３３】

　ここで＜ｉｎａｍｅ＞ は命令の名称であり、
＜ｏｎａｍｅ＞ はオペランドまたは状態名であり、
＜ｓｔａｇｅ＞ はパイプラインステージを示す順序である。
【０１４７】
ＴＩＥにより使用されるｄｅｆステージ番号はＫｉｌｌｉａｎ とＷａｒｔｈｍａｎのＸｔｅｎｓａ（商標名）命令セットアーキテクチャ（ＩＳＡ）基準マニュアルの第１０章で説明されている値よりも１だけ小さく、したがって命令間の分離はｍａｘ（ＳＡ−ＳＢ，０）の代わりにｍａｘ（ＳＡ−ＳＢ＋１，０）である。
【０１４８】
この仕様に基づいて、Ｋｉｌｌｉａｎ とＷｉｓｏｎ のアプリケーションで記載されたＴＩＥコンパイラは以下のようにセマンチック論理仕様にパイプラインレジスタを挿入するように拡張される。ステージ番号がセマンチックブロックへの入力毎に割当てられる。命令デコード信号と即時のオペランドには構成に特有の番号（好ましい実施形態では０）を割当てられる。レジスタソースオペランド、状態レジスタ、インターフェース信号（以下説明する）にはＴＩＥスケジュール宣言からステージ番号（構成に特有のデフォルトにより、好ましい実施形態では１）が割当てられる。次にセマンチックブロックの各ノードはポストオーダー（即ち各その先行ノードがビジットされた後）でビジットされる。ノードＮＳのステージ番号は任意のその入力の最大のステージ番号である。ステージ番号ＩＳ＜ＮＳの各入力に対して、コンパイラは入力とノードとの間にＮＳ−ＩＳパイプラインレジスタを挿入する。最後に、出力レジスタオペランド、状態レジスタ、インターフェース信号がビジットされる。セマンチックブロックＩＳからのステージ番号がスケジュールステートメントで宣言されるステージ番号ＯＳよりも大きいならば、入力ＴＩＥ仕様はエラーである。そうでなく、ＯＳ＞ＩＳならば、出力の前にＯＳ−ＩＳパイプラインレジスタを挿入する。
【０１４９】
このプロセスは以下の例により示される。
【数３４】

【０１５０】
この例は命令“ｅｘａｍｐｌｅ ”がステージ１でオペランドａｒｓ、ａｒｔ、状態ａ３を使用し、ステージ２で状態ｓ１とｓ２を使用することを特定している。これはステージ３で結果オペランドａｒｒを発生する。この説明では、前述のレジスタ挿入処理は図８の（Ａ）の回路を生成する。最大の入力ステージは２であるので、ノード“？”のＮＳは２である。ａｒｓとａｒｔのＩＳは１であるので、１つのレジスタがそれぞれのノード“？”の入力で挿入される。同様にノード“＋”で、ｓ３入力は他の入力と一致するように１ステージだけ遅延される。最後に、ノード“＋”の出力はａｒｒに割当てられる前に１ステージだけ遅延される。前述の例のスケジュール記述では、ａｒｒは“ｏｕｔ　ａｒｒ１”として宣言されるならば、パイプライン挿入処理手順は図８の（Ｂ）の回路を生成する。ノード“＋”のＮＳは２であり、ａｒｒのＯＳは１であるので、処理手順は入力スケジュールの要求が満たされないためにエラーメッセージを発生する。
【０１５１】
前述のアルゴリズムは必要な時にパイプラインレジスタを正確に挿入するが、これらのレジスタの配置は最適からほど遠い。合成のため許容可能な論理を生成するために初期挿入後、Ｓｙｎｏｐｓｙｓ’ ＤｅｓｉｇｎＣｏｍｐｉｌｅｒで見られるようなパイプラインレジスタ最適化アルゴリズムを使用する必要がある。これは典型的にレジスタの両側の論理遅延をバランスするため組合わせ論理装置を横切ってレジスタを移動することにより行われる・前述の例を使用して、レジスタ最適化は図８の（Ｃ）のような回路を生成し、ここではノード“＋”の出力におけるレジスタは遅延をバランスし、サイクル時間を減少するため入力に移動される。
【０１５２】
幾つかのケースでは、２つの命令は幾つかの共通の論理装置を共有してもよいので、１つの命令に対する１つのパイプラインステージのレジスタ、および異なる命令の別のステージのオペランドを使用または規定するセマンチックブロックを有することが望ましい。２つの別々のセマンチックブロックで命令を特定することは不必要な論理の重複を必要とする。
【０１５３】
これは好ましい実施形態の変形で可能な拡張である。この能力は２つのオペランド、例えば単なる＜ｏｐｅｒａｎｄ＞ の代わりに ＜ｏｐｅｒａｎｄ＞＠＜ｓｔａｇｅ＞ のセマンチックブロックで別々の信号名を使用することによりサポートされる。この変形が一度行われると、前述のアルゴリズムはマルチシステム環境でさえも正確に動作する。
【０１５４】
例えば、以下の２つの命令、即ち
ｉｎｓｔ１：ａｒｒ＝ａｒｓ＋ａｒｔ
ｉｎｓｔ２：ａｒｒ＝ａｒｓ＋ａｒｔ＋ｓ１
を有することを望むならば、幾つかの理由でｓ１はステージ１の入力でなければならず。サイクル時間の要求は、１サイクルで１付加を行う時間だけが存在することである。前述の拡張を使用して、セマンチックの記述を以下示す。
【数３５】

【０１５５】
拡張された信号名ａｒｓ＠２とａｒｔ＠２により単一のセマンチックブロックで２つの命令を記述することにより、２つの命令は、２つの別々のセマンチックブロックで２つの命令を記述する３つの加算器の代わりに２つの加算器だけにより実行されることができる。
【０１５６】
［例外］
ほとんどのプロセッサは完了のかわりに例外を条件的に生成する命令の幾つかのメカニズムを有する。例えば、分割命令は除数がゼロのときに生じさせる。本発明の好ましい実施形態は最初に以下の新しい例外を宣言することによりＴＩＥからこの能力をサポートする。
ｅｘｃｅｐｔｉｏｎ ＜ｅｎａｍｅ＞ ＜ｅｘｃｅｐｔｉｏｎｃｏｄｅ＞ ｛＜ｅｘｃｌ＞，．．．｝ ＜ｓｔｒｉｎｇ＞
ここで＜ｅｎａｍｅ＞ はそれを挙げるセマンチックブロックで使用される命令および信号の名称であり、＜ｅｘｃｅｐｔｉｏｎｃｏｄｅ＞ はこの例外を他から弁別するためにソフトウェア例外ハンドラに通過される値であり、＜ｅｘｃｌ＞等は低い優先順位の例外であり、＜ｓｔｒｉｎｇ＞は文書化で使用される記述ストリングである。
【０１５７】
一度宣言されると、例外信号は前述のｉｃｌａｓｓ宣言にリストされる。この宣言により、例外の名称を有する単一ビット信号が規定された命令を含んでいるセマンチックのＴＩＥブロック内に生成され、この信号は割当てられなければならない。図９は多数のＴＩＥブロックから例外信号を結合し、１よりも多くのものが単一命令により通報されるときに例外間で優先順位を付けるためにＴＩＥコンパイラにより生成される論理処理を示している。
【０１５８】
例外信号はスケジュール宣言の所定のステージ番号でもある。しかしながら、好ましい実施形態では、コアプロセッサはそのＭ個のパイプラインステージの全ての例外を処理する。この構造では、スケジュール宣言により特定されるステージ番号はＭステージのステージ番号以下であることを確実にするためにチェックされ、そうでなければエラーがコンパイル時間に通報される。特定のステージ番号がＭステージのステージ番号以下であるならば、Ｍステージのステージ番号が代わりに使用される。したがって図９の論理はＭステージで評価される。
【０１５９】
図９で示されているように、各セマンチックブロックにより生成される例外信号はそれらのインターフェースセクションで例外信号を宣言するワンホット命令デコード信号のＯＲによりＡＮＤ処理される（これはその例外を挙げた命令が実行されるときにＴＩＥコードが有効な例外信号だけを発生することを可能にする）。次に、全ての例外信号は幾つかの例外が生じていることを示す単一信号を発生するようにＯＲ処理される。この信号は従来技術のようにコアにより処理される。
【０１６０】
最後に、優先度エンコーダは例外コードがコアプロセッサのＥＸＣＣＡＵＳＥレジスタへ書込まれるか否かを決定するために使用される。低い優先順位の例外のリストは指令されたグラフを形成するために使用される（１サイクルが検出されたならば、これはコンパイルタイムエラーと考えられる）。このグラフのトポロジの分類（例えばＵｎｉｘ ｔｓｏｒｔプログラム）が生成され、結果的な順番は種々の例外信号の優先度エンコードを行うために使用される。プリオリティエンコードの結果はその後、ｍｕｘの対応する例外コードを選択するために使用される。この信号はその後従来技術のようにコアにより処理される。
【０１６１】
１例として、図９は以下の３つの優先順位を付けられた例外信号のＴＩＥ記述の論理を示しており、全てはサイクルＮで起こる。
【数３６】

【０１６２】
この場合、例外ｅｘ１はＣ１のｉｎｓｔ１と、Ｃ３のｉｎｓｔ４により挙げられ、ｅｘ２はＣ３のｉｎｓｔ２により挙げられ、ｅｘ３はＣ２のｉｎｓｔ３により挙げられる。この実施形態では、全ての例外信号はそれらの宣言されたステージで生成され、コミットステージにパイプラインで転送され、その点で例外原因値は前述のＴＩＥ記述で特定したように例外信号の優先順位により例外コードを選択することによって計算される。例外信号Ｅｘｃｅｐｔｉｏｎと原因信号ＥｘＣａｕｓｅはコアに与えられる。例外が一度処理されると、パイプラインの全ての命令を消去して実効的に残りの未処理の例外をクリアするためにコアは信号をＴＩＥ論理へ返送する。
【０１６３】
別の例として、図１０はコードにより記述される回路を示しており、回路の下では一方は例外を発生し、一方は両者を発生する２つの例外および幾つかの命令を有する。この例では、オーバーフローはゼロによる除算よりも低い優先順位である（実際に両者は除算では同時に生じず、したがって相対的な優先順位は無関係である）。
【０１６４】
図面では、それぞれ図示されたセマンチックブロックはＴＩＥ例外の全体のセットの幾つかのサブセットを生成し、したがって正確なワイヤリングは入力依存性であることに注意する。さらに、セマンチックブロックでは、例外出力はＴＩＥスケジュールメカニズムにより分解ステージにパイプラインされる。
【数３７】

【０１６５】
図１０は全てのＴＩＥ例外が全てのコア例外に関する単一の固定した優先順位を有する配置を示している。直通拡張によりＴＩＥ例外ステートメントが種々のコア例外を明示的に意味することができる。ＴＩＥコンパイラはその後、ＴＩＥとコア例外を結合する優先度エンコーダを生成することができる。
【０１６６】
［基準セマンチックス］
Ｋｉｌｌｉａｎ とＷｉｌｓｏｎのアプリケーションで記載されたようなシステムは各命令の単一のセマンチック定義を有する。このセマンチック定義は命令を表すハードウェアとソフトウェアとの両者を生成するために使用された。このようなシステムは多数の命令が共に規定され、ワンホット命令デコード入力信号により微分されることを可能にする（例えば加算および減算命令は加算器を共有できる）。この特性の使用は実効的なハードウェアを生成するため必要である。好ましい実施形態で規定されることができる命令の複雑性を増加することにより、構成セマンチックの実効的なセットは読取り、書込み、検査、理解が困難になる。これらもまたパイプライン化のためにさらに同調され、抽象が少なくされる。これは記述がパイプラインの効果を考慮しなければならず、パイプラインレジスタが移動されることができる信号を発生するためである。
【０１６７】
例えば、ＴＩＥの浮動小数点構造では、３または４サイクルの浮動小数点加算演算と反対に２サイクルの浮動小数点加算演算をターゲットとするために恐らく異なるコードを書込む。これはプログラマーがしばしば明瞭にする目的で少数のゲートを生成するためにコードを最適化するために抽象が少ない。例えば以下のように書かれる。
基準セマンチックス（かなりクリア）では、
ｘ＝ｙ＊３を割当てるが、
ソフトウェア開発ツールはマニュアル等で実行されるように定数のケースによる乗算を処理しないので、
ｘ＝ｙ＋｛ｙ［３０：０］，１’ ｂ０｝を割当てる。
【０１６８】
別の例として、乗算−累算命令を参照で説明するため、以下のように簡単にする。
ａｃｃ＝ａ＊ｂ＋ａｃｃ
しかしセマンチック記述では、この命令は２つのパイプラインステージにわたって実行されなければならないことを考慮しなければならない。熟練したハードウェア設計者は、ａ＊ｂの部分的な結果は第１のステージでキャリー保存加算器ツリーを使用して計算される必要があり、ａｃｃによる２つの部分的な結果を加算する最終結果は第２のステージで計算されることを知っている。
【０１６９】
したがって、ネイティブ機械命令に対する対応が失われるので、構成セマンチックはシミュレーションソフトウェアに変換されるとき低速度になる。先の命令を使用して、参照記述は２つの命令を使用してシミュレートされることができる。この場合、セマンチック記述のシミュレートは数百の命令を取る。
【０１７０】
前述の理由では、好ましい実施形態はセマンチックの２つのセットの仕様を可能にする。１つのセットは基準セマンチックスと呼ばれる。単位命令当り１つの基準セマンチックスが存在し、命令間にはセマンチックの共有はない。このセマンチックの定義は通常、命令の予測されたオペレーションを規定するために明瞭にするために書かれる。第２のセットのセマンチック、即ち構成セマンチックはハードウェア構成のためのものである。これらのセマンチックはハードウェアが多数の命令により共有されることを可能にするために従来技術のシステムの特性を維持し、通常、ゲートレベルの合成により低いレベルで書かれる。
【０１７１】
これは以下のように、２つの命令ＡＤＤとＳＵＢを規定する簡単なＴＩＥ例で示されることができる。
【数３８】

【０１７２】
参照記述は簡単で直接的である。しかしながら、セマンチックの記述は構成の効率に関与しなければならず、特に、この場合では３つの命令により必要とされる加算器を共有しなければならない。これを行うため、数の減算はビットに関する補数と定数１との加算と同様である数学的アイデンティティに依存する。
【０１７３】
基準セマンチックスはまた基準セマンチックスにより命令セットが一度規定され、その後、構成セマンチックの異なるセットにより多数回、実行されることを可能にする。基準セマンチックスは通常形式的ではなくＩＳＡ文書化でのみ規定されるが、多数の構成による単一のＩＳＡ規定が産業で共通して実行される。好ましい実施形態はこの典型的な処理手順を逆にし、基準セマンチックスを形式的に規定し、ＴＩＥ仕様から文書化を獲得する。
【０１７４】
別々の基準セマンチックスと構成セマンチックはそれらの等価性を検査する必要を生じる。従来のシステムでは、文書化の基準セマンチックスにより、等価性はそれを検査するため人間による文書読取りと、書込み試験によりチェックされる。この処理手順には時間がかかり、正確な言語で特定される基準セマンチックスでは、基準セマンチックスを構成セマンチックと比較するために論理等価ツールを使用できる。好ましい実施形態は２つの異なる方法、即ち、その一方は特定の命令に対して基準セマンチックスと構成セマンチックの等価性をチェックし、その他方は基準セマンチックスを使用して構成される回路全体が構成セマンチックを使用して構成されたものに等しいかをチェックする方法で、均等性チェックツールへ必要な入力を行うことによりこのプロセスを自動化する。第１の方法は構成セマンチック記述のデバッグを容易にする。第２の方法はセマンチックにより特定された論理だけでなく、全てのセマンチックを結合するためのグルー論理を含んでいる全体的な設計を確認する。
【０１７５】
基準セマンチックスと構成セマンチックから生成される回路は通常等しくない。所定の命令に対して、出力信号のサブセットだけが設定される。残りの出力信号に対しては、基準セマンチックスと構成セマンチックはこれらが論理的に“ｄｏｎ’ｔ ｃａｒｅｓ ”、即ち未使用であるので、コスト基準または記述の容易度に基づいて異なる値を割当てるように選択されることができる。好ましい実施形態は付加的な論理を生成することによりこの問題を解決し、したがって特に別の命令によって発生される出力信号は変更されず、残りの出力信号は図１１で示されているように強制的に０のような特定の論理値にされる。この図面は、基準記述（ｘ　ｒｅｆ）により発生される各出力信号ｘと、セマンチック記述（ｘ　ｉｍｐ１）により発生される各出力信号ｘは別の信号ｉｇｎｏｒｅ　ｘでアンド処理され、それによってｘが命令出力の一部ではないとき０にされ、それ故等価チェックツールからの誤った否定的な結果を防止する。ＩＣＬＡＳＳステートメントから、ｘを設定する命令のセットを知り、それ故、ｉｇｎｏｒｅ　ｘは単にｘを設定しない命令の論理ＯＲである。
【０１７６】
［組込みモジュール］
ある普通に使用される計算は言語定義演算子をもたない。しかしながら、他の言語構成の使用は記述するのに非常に面倒であるか、効率的に構成するのが非常に困難である。タイはこれらの幾つかの計算において以下の表ＩＩで示されている組込み演算を行う。
【表３】

【０１７７】
例として、以下の記述はＡＤＤとＳＵＢ命令間で加算器を共有する。
ａｓｓｉｇｎ ａｒｒ＝ＴＩＥａｄｄ（ａｒｓ， ＳＵＢ？〜ａｒｔ ： ａｒｔ， ＳＵＢ）
以下のセマンチック記述はキャリー保存加算器（ＣＳＡ）アレイを使用して４つの数を加算し、全加算器が後続する。
ｗｉｒｅ ［３１：０］ ｓ１， ｃ１，ｓ２，ｃ２ ；
ａｓｓｉｇｎ｛ｓ１， ｃ１｝＝ＴＩＥｃｓａ（ｄ１， ｄ２， ｄ３）；
ａｓｓｉｇｎ｛ｓ２， ｃ２｝＝ＴＩＥｃｓａ（ｃ１ ＜＜ １， ｃ１， ｄ４） ；
ａｓｓｉｇｎ ｓｕｍ＝（ｃ１ ＜＜ １） ＋ｓ２
組込みモジュールを使用する利点は、ＴＩＥコンパイラが組込みモジュールを認識し、それらのためのさらに効率的な構成を得るためにモジュール発生器を使用することである。
【０１７８】
［文書化］
基準セマンチックスは命令セット文書化の１つの重要なエレメントでもある。典型的な命令セット基準マニュアルは、その例示的なページが図１２に示されており、各命令に対して、そのマシンコードフォーマット、そのパッケージ、アセンブラ構文、概要（命令の１ラインテキストの記述）、命令のフルテキスト記述、命令のより正確な動作定義、ならびにアセンブラノートおよび命令に関連する例外を含むことができる。マシンコードフォーマットを生成するのに必要な全ての情報は、オプコードビットおよびオペランドフィールドを含んでいるので、既にＴＩＥ仕様中に認められている。同様に、アセンブラ構文はニモニックおよびオペランド名称から得られる。ＴＩＥ基準セマンチックスは正確な定義になる。概要およびテキスト記述だけがない。それ故、好ましい実施形態は命令セットの設計者が概要とテキスト記述を特定することを可能にするようにＴＩＥへ構造を付加する。
【０１７９】
ＴＩＥパッケージ仕様は以下のフォーマットを有する。
ｐａｃｋａｇｅ ＜ｐｎａｍｅ＞ ＜ｓｔｒｉｎｇ＞
・
・
・
ｅｎｄｐａｃｋａｇｅ ＜ｐｎａｍｅ＞
パッケージ名＜ｐｎａｍｅ＞ はパッケージとエンドパッケージとの間で規定された全ての命令に関連する。以下説明するように、パッケージは文書化以外の他の使用法を有する。＜ｓｔｒｉｎｇ＞パラメータは文書化の目的のためのパッケージの名称を与える（スペースを有してもよい）。
【０１８０】
ＴＩＥ概要仕様は以下のフォーマットを有する。
ｓｙｎｏｐｓｉｓ ＜ｉｎａｍｅ＞ ＜ｓｔｒｉｎｇ＞
ここで、＜ｓｔｒｉｎｇ＞は命令の短い記述（ほぼ１ラインの半分）である。このテキストではフォーマット制御は必要ない。このテキストは典型的に本の見出しと命令リストの付加的なマテリアルのために使用される。
【０１８１】
ＴＩＥ記述仕様は以下のフォーマットを有する。
ｄｅｓｃｒｉｐｔｉｏｎ ＜ｉｎａｍｅ＞ ＜ｓｔｒｉｎｇ＞
ここで、＜ｓｔｒｉｎｇ＞は英語または別の自然言語で命令のオペレーションを記述したテキストを含んでいるストリングである。このテキストではテキストフォーマットコマンドが必要とされている。好ましい実施形態は、ＨＴＭＬのような言語を実行する（ＨＴＭＬの仕様は例えばｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＲＥＣ−ｈｔｍｌ４０ で見られる）。さらに２つの随意選択的な文書化ストリングが以下のようにサポートされる。
ａｓｓｅｍｂｌｙ　ｎｏｔｅ ＜ｉｎａｍｅ＞ ＜ｓｔｒｉｎｇ＞
ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｎｏｔｅ ＜ｉｎａｍｅ＞ ＜ｓｔｒｉｎｇ＞
これらの随意選択的な仕様は付加的な命令当りのテキストを与える。
【０１８２】
ＨＴＭＬのように、２つの種類、即ちエレメントと文字エンティティのフォーマット制御がサポートされる。目的は正確な外観ではなくデータの属性を特定することである。データはその属性に基づいて出力媒体に適切であるようにレンダリングされる。文字エンティティ＆＜ｎａｍｅ＞はＡＳＣＩＬＬで有効ではない文字を特定するか、または特別なレンダリングを使用する。エレメントはパラグラフ、リスト、コード例等のようなＨＴＭＬ定義エンティティを表している。ＨＴＭＬ４．０仕様から引用して“［ｅ］各エレメントタイプの宣言は３つの部分、即ちスタートタグ、内容、エンドタグを記述する。エレメントの名称は（＜ＥＬＥＭＥＮＴ−ＮＡＭＥ＞と書かれた）スタートタグと、（＜／ＥＬＥＭＥＮＴ−ＮＡＭＥ＞ と書かれた）エンドタグ”で現れ、エンドタグ中のエレメントの名称の前のスラッシュ符号に注意する。
【０１８３】
換言すると、＜ＥＬＥＭＥＮＴ−ＮＡＭＥ＞ＤＯＣＵＭＥＮＴＡＴＩＯＮ＜／ＥＬＥＭＥＮＴ−ＮＡＭＥ＞はＤＯＣＵＭＥＮＴＡＴＩＯＮ に与えられたフォーマットを特定する。ＨＴＭＬとは異なって、エンドタグ＜／ＥＬＥＭＥＮＴ−ＮＡＭＥ＞ は随意選択的ではない。２つの種類のタグ、即ちブロックおよびインラインが存在する。ブロックタグはパラグラフ状の構造を特定し、インラインタグはこれらのパラグラフ内のテキストのフォーマットの特定に使用される。インラインタグはネストされてもよい。ブロックタグはＵＬ内のＬＩを除いてネストされない。
【０１８４】
これらの構造は各命令および命令のインデックスに対するＨＴＭＬページをアセンブルする付属資料Ｃの１つのようなプログラムの一部としてＨＴＭＬ文書化を作成するためにＨＴＭＬに容易に変換される。このようなＨＴＭＬ文書化はプロセッサのユーザのオンライン基準マニュアルを設定するために使用されることができる。好ましい実施形態でこれを実行するプログラムはＰｅｒｌプログラミング言語で書かれ、２つの列、即ち一方はニモニック用でもう一方は概要テキストストリングのＨＴＭＬ表によりｉｎｄｅｘ．ｈｔｍｌファイルを作成することにより動作する。表の行はソートされた順序で命令を処理することにより充填されている。命令ニモニックは各命令に対して作成されるページにＨＴＭＬリンクされている。
【０１８５】
命令当たりのページはＨＴＭＬレベル−１の見出し（“Ｈ１”）で開始し、ニモニックおよび概要を与える。次に、種々のセクションはＨＴＭＬレベル−２の見出し（“Ｈ２”）中の固定された名称により紹介される。“Ｉｎｓｔｒｕｃｔｉｏｎ Ｗｏｒｄ”とラベルを付けられた第１のセクションは単位ビット当り１列を有するＨＴＭＬ表により表されるマシンコードフォーマットを与える。オプコードビット（ ’０’ または ’１’ ）は対応する表のセルに挿入される。オペランドフィールドはフィールド名称で充填されている。多数の隣接ビットに拡がるフィールドは反復を避けるためにＨＴＭＬ表のＣＯＬＳＰＡＮ 特性を使用する。マシンコードボックスのビットは表の上の行を使用して番号を付けられ、フィールド幅は下の行で与えられる。
【０１８６】
“Ｐａｃｋａｇｅ ”とラベルを付けられた第２のセクションは命令を規定するＴＩＥパッケージ名称を与える。簡単はハッシュは識別子から文書化ストリングへパッケージ名称を変換するために使用される。パッケージ名称自体はＨＴＭＬパラグラフのブロック−エレメント（“Ｐ”）の内部の出力である。
【０１８７】
“Ａｓｓｅｍｂｌｅｒ Ｓｙｎｔａｘ”とラベルを付けられた第３のセクションはこの命令をコード化するために使用されるアセンブリ言語フォーマットを与える。これはコンマで分離されている命令ニモニック、スペース、およびオペランド名称からなる。レジスタオペランド名称はレジスタファイルの短い名称をフィールド名称に連結することにより形成される。即時のオペランド名称は丁度ＴＩＥからの即時名称である。アセンブラ構文はＨＴＭＬコードのインラインエレメント（“ＣＯＤＥ”）を使用したＨＴＭＬパラグラフのブロックレベルエレメント（“Ｐ”）の内部の出力である。コードのインラインエレメントはプログラミング言語のコードが通常レンダリングされる方法と類似した固定幅のフォントでテキストをレンダリングする。
【０１８８】
“Ｄｅｓｃｒｉｐｔｉｏｎ ”とラベルを付けられた第４のセクションはＴＩＥからＨＴＭＬへ変換されたテキスト記述を含んでいる。ＴＩＥのフォーマットコードはＨＴＭＬのものと類似しているので、この変換は非常に簡単である。主な必要性はＩＮＳＴＲＥＦエレメントをＨＴＭＬリンクから名称を有する命令へ変換することである。
【０１８９】
“Ａｓｓｅｍｂｌｅｒ Ｎｏｔｅ”とラベルを付けられた随意選択的な第５のセクションはＴＩＥからＨＴＭＬへ変換されるテキストを含んでいる。
【０１９０】
“Ｅｘｃｅｐｔｉｏｎ ”とラベルを付けられた第６のセクションは、この命令が挙げることができる例外のリストを含んでいる。ロードおよび記憶命令はＴＩＥコンパイラによるリストに付加されるロード記憶エラー例外を自動的に有する。対応する例外信号が命令のｉｃｌａｓｓの信号リストセクションにリストされるならば、他の例外がリストされる。例外は優先順にリストされる（前述のトポロジ分類の結果）。
【０１９１】
“Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ｎｏｔｅｓ”とラベルを付けられた随意選択的な第７のセクションは、ＴＩＥからＨＴＭＬへ変換されるテキストを含んでいる。
【０１９２】
これは時には読者に便利であるので、以下説明するＴＩＥ仕様から文書化へ試験ケースリストをコピーすることも可能である。
【０１９３】
プロセッサ命令の文書化の例を以下示す。
【数３９】

【０１９４】
【数４０】

【０１９５】
【数４１】

【０１９６】
【数４２】

【０１９７】
ＨＴＭＬは好ましい実施形態では文書化フォーマット言語として使用されるが、当業者はＡｄｏｂｅ Ｆｒａｍｅ Ｍａｋｅｒ ＭＩＦ フォーマット等の他の等価仕様言語が使用されてもよいことを認識するであろう。
【０１９８】
［サブフィールド］
プログラム実行特性を変化するプロセッサ構造オプションに対する感受性を少なくする技術の開発は、フィールドを別のフィールドのサブフィールドとして規定する能力である。これはフィールドの定義を命令ワードの特別な部分に限定し、これらが他のフィールド部分として規定されることを許容しない従来の構成可能なプロセッサシステムと対照的である。フィールドを他のフィールドの部分として規定する能力は構成されたプロセッサのエンディアンとソフトウェアが部分的に独立することを可能にする。
【０１９９】
例えば、従来のシステムでは、ｔフィールドの最初の２ビットに対応する新しいフィールドｔ１０は以下のＴＩＥステートメントの一方でのみ規定されることができる。
ｆｉｅｌｄ ｔ１０ ｉｎｓｔ［５：４］　　 ／＊ｆｏｒ ｆｉｅｌｄ ｍｅｍｏｒｙ ｏｒｄｅｒ＊／
または、
ｆｉｅｌｄ ｔ１０ ｉｎｓｔ［１５：１４］　　 ／＊ｆｏｒ ｂｉｇ ｅｎｄｉａｎ ｍｅｍｏｒｙ ｏｒｄｅｒ＊／
この配置では、メモリ順と独立してｔ１０を規定することはできない。サブフィールドの使用を許容することにより、本発明はｔ１０が以下のように規定されることを可能にする。
ｆｉｅｌｄ ｔ１０ ｔ［１：０］
ｔはプロセッサコアによりリトルエンディアンではｉｎｓｔ［７：４］ であり、ビッグエンディアンに対してはｉｎｓｔ［１７：１４］ であるように規定されるので、ｔ１０はメモリ順と独立する。
【０２００】
［テストケース］
ユーザ特定されたＴＩＥの検査の２つの特徴が存在する。第１の特徴はコアとＴＩＥブロックとユーザ定義された状態とレジスタファイルとの間のインターフェースの正確さを確実にすることである。第２の特徴はユーザセマンチックスのハードウェアへの変換、換言するとＴＩＥコンパイラの正確さを確認することである。第１の特徴はＴＩＥ命令セマンチックスに依存せず、ＴＩＥ仕様の特性から得られることができる。
【０２０１】
ユーザ特定されたＴＩＥの任意の命令された予め定められた試験または診断を書き込むことはできない。この問題はユーザＴＩＥ仕様から試験を導出し、同時にＴＩＥのハードウェアおよびソフトウェアが生成されることにより対処される。ＴＩＥコンパイラはユーザ命令のためのＩＳＡ記述を生成する。ＴＩＥに対する診断発生器はＴＩＥ命令のＩＳＡ記述を読取る。これもユーザ特定された状態およびレジスタファイルについての知識を含んでいる。この情報はユーザＴＩＥの幾つかの意味のある診断セットを作成するために発生器により使用される。
【０２０２】
基準セマンチックスは基準セマンチックスの検査方法を与える。基準セマンチックスはこれらをターゲットアプリケーションで使用することにより確認される。Ｋｉｌｌｉａｎ とＷｉｌｓｏｎの明細書に記載されたように、アプリケーションは設計者によってイントリンシックにより新しい命令を使用するように変更されることができる。変更されたアプリケーションおよび命令定義は共にシミュレータまたはネイティブのいずれかにおいて試験される。ネイティブ実行は（従来技術のように）機能としてイントリンシックの通常のプログラミング言語（例えばＣ）定義を生成するＴＩＥコンパイラの能力により容易にされる。ターゲットアプリケーションの使用は通常、命令定義の最良の試験である。
【０２０３】
Ｃコードを生成するＴＩＥコンパイラの正確さはこのプロセスによりチェックされるが、アプリケーションがＨＤＬシミュレータでも実行されていない限り、ＴＩＥコードからＨＤＬへの変換はチェックされない。しかしながらＨＤＬシミュレータは通常非常に遅いために多くのアプリケーションでこれを行うことができない。それ故、入力セマンチックからＨＤＬへのＴＩＥコンパイラの変換の正確さを試験するための幾つかの他の方法を有することが望ましい。
【０２０４】
また、設計者はアプリケーションが命令により処理されなければならない全てのケースをカバーするかについて確信をもたない可能性がある。これはプロセッサが生成された後にアプリケーションが変更するか、または新しいアプリケーションがこのプロセッサを使用するならば重要である。この場合、他の方法に命令を試験させることが望ましい。従来技術のシステムでは、プロセッサの命令は、通常、選択されたソースオペランド値のセットで命令を実行し、予測値に対する結果のオペランドをチェックする手書き診断を実行することにより試験される。好ましい実施形態はＴＩＥ仕様から有効である付加的な情報を使用することによってこのプロセスを自動化する。
【０２０５】
ＴＩＥのｉｃｌａｓｓ仕様は各命令の全ての入力および出力と、レジスタファイルオペランド、即値、またはプロセッサ状態レジスタであるかをリストする。ＴＩＥ構造、即ち、

これはソースオペランド値と、命令＜ｉｎａｍｅ＞ に対する予期された結果のリストを与える。ここで、＜ｏｎａｍｅ＞ はオペランドまたは状態レジスタの名称であり、＜ｖａｌｕｅ＞ は（リスト中の試験しているｉｎまたはｉｎｏｕｔ オペランドまたはレジスタの）対応する入力値または（リスト中の試験しているｉｎまたはｉｎｏｕｔ オペランド、レジスタまたは例外信号の）予測値である。
【０２０６】
ＴＩＥコンパイラは、ｉｎおよびｉｎｏｕｔ プロセッサがＷＵＲイントリンシックおよび、Ｗｉｌｓｏｎの明細書に記載されているＴＩＥ　ｕｓｅｒ　ｒｅｇｉｓｔｅｒ構成で宣言されている数とを使用してリスト中の試験の値に登録する通常のプログラミング言語（例えばＣ）でテストプログラムを生成する。その後、これはローディングレジスタのｐｒｏｔｏ 宣言により特定されるイントリンシックを使用して、ｉｎおよびｉｎｏｕｔ レジスタファイルオペランドを設定する。コアレジスタファイル中のオペランド（例えば好ましい実施形態ではＡＲ）は組込み言語タイプを使用する。次にＴＩＥコンパイラはｉｃｌａｓｓにより特定される順序でリストされたオペランドによりイントリンシックを呼出す。次に、テストのｏｕｔ リストで特定されているｉｎまたはｉｎｏｕｔ オペランドが読出され、所定の予測値と比較される。最後に、テストのｏｕｔ リストのプロセッサレジスタＲＵＲイントリンシックと、ｕｓｅｒ　ｒｅｇｉｓｔｅｒ構成のためのレジスタ数とを使用して読出され、所定の値と比較される。
【０２０７】
この自動的に発生されたプログラミング言語診断は命令セットシミュレータまたはハードウェアＲＴＬモデルで、或いはターゲットプログラミング言語への変換によりＴＩＥコンパイラによって生成されたイントリンシックエミュレート機能をネイティブに使用することにより実行されてもよい。
【０２０８】
１例として、仕様、即ち、
【数４３】

これは以下のＣ診断を生成する。
【０２０９】
【数４４】

【０２１０】
［テストケースを生成するためのテストベクトルの自動サンプリング］
アプリケーションの実行が入力命令セマンチックの正確さを試験するのに十分である場合、入力セマンチックのＴＩＥ変換を試験するためにＨＤＬシミュレータを動作するためのテストケースを有することが望ましい。ＨＤＬシミュレータは多くの場合に非常に遅いのでアプリケーションを動作できない。それ故、ネイティブにまたは命令セットシミュレータで実行するアプリケーションからテストを抽出する方法を有することが望ましい。
【０２１１】
ＴＩＥコンパイラはそれ故、入力を書込み、命令のオペランドをファイルに出力するコードによってアプリケーションプログラミング言語への入力セマンチックの変換を増補するオプションを有する。このファイルはその後、重複を除去し統計的なサンプリングを使用することにより後処理されることができ、それによってＨＤＬシミュレータでシミュレートするのために合理的な複数のテストケースを抽出する。これらの記録はその後、前述したＴＩＥテスト構成に変換されることができ、それによってその構成は残りのプロセスで影響を与える（ｌｅｖｅｒａｇｅ）ことができる。
【０２１２】
このアーキテクチャとマイクロアーキテクチャテストを生成する方法論を使用する動機はユーザＴＩＥの構成の体系的な確認プロセスを与えることである。ユーザのアプリケーションはＴＩＥ構成のマイクロアーキテクチャを試験するのに十分ではないのでこれは非常に重要である。このような診断をＴＩＥ記述から生成するために、ＩＳＡ記述からの必要な情報と、ＴＩＥコンパイラにより生成されるパイプライン情報とを獲得する装置を使用する。この方式を以下説明する。
【０２１３】
［ＴＩＥ命令のＩＳＡ記述］
ユーザの要求にしたがってプロセッサコアを構成することができるように、１つの構造が使用される。構造は基本的にパーツのリストと、ウェブベースインターフェースを通ってユーザによりカスタマイズされることができるプロセッサコアの属性である。これらのプロセッサ属性は構成パラメータと呼ばれる。構成パラメータの完全なリストはそれらのデフォルト値および、値が想定することができる範囲と共に、プロセッサコアの構成スペースを規定する。プロセッサコアの具体的な例示、即ち全ての構成パラメータが具体値を割当てられているコアの例はコア構成である。
【０２１４】
現在、構成スペースと具体的なコア構成との両者は構成パラメータおよびそれらの値をリストするテキストファイルとして表される。全ての構成パラメータのフラットリストとテキストファイルで数えられるそれらの値は人が容易に読むことができる利点を有するが、これはハードウェアおよびソフトウェアの個々のピースを構成するプロセスを複雑にする。その理由で、構造情報を読取り、プロセッサの種々の部分のオブジェクト指向表示と構成パラメータ値を作成する１セットのツールが開発されている。このツールおよび構成の表示は総称して構成環境または構成データベースとして知られている。
【０２１５】
ソフトウェアおよびハードウェアの構成中、ｔｐｐはディベロッパが構成情報をプログラムでアクセスし、ソースコードの部分を容易に計算することを可能にする構成環境へのハンドルを与える。さらに、計算は構成環境で実行され、したがって全ての構成されたソースを横切って共有されるので、構成ソースコードの開発は簡単にされる。
【０２１６】
ＩＳＡを記述するＰＥＲＬライブラリが開発されている。ＴＩＥでは、ＴＩＥコンパイラはユーザ定義命令のためのＰＥＲＬオブジェクトを生成するように動作し、これはコアＩＳＡに付加される。そこから、全ての確認ツールはＩＳＡと、ユーザ定義ＴＩＥのパイプライン情報を獲得するためにこれらのＰＥＲＬオブジェクトに問合わせる。
【０２１７】
以下の例はこれが行われる態様を示している。簡単なＴＩＥ記述で開始する。
【数４５】

【０２１８】
ＴＩＥコンパイラはＴＩＥユーザ状態と、それを使用する命令のセマンチックについての以下の情報を生成する。
【数４６】

【０２１９】
前述の情報から、ＴＩＥ命令ａｃｃに対するアセンブリコードを生成することが可能である。命令は、共にタイプＡＲである２つのレジスタオペランドを有することが知られており、それに基づいて幾つかのランダムなレジスタ割当が行われることが可能であり、さらに良好には出力および入力フィールドが知られているので、幾つかのインテリジェントレジスタ割当を行うことが可能である。それ故、以下のようなこの命令に対するアセンブリコードを自動的に生成することができる。
ａｃｃ　＄ａ７，＄ａ１３
ここでａ７ａとａ１３はＡＲのｒｅｇｆｉｌｅ 定義を見るレジスタ割当アルゴリズムにより生成されるｓおよびｔフィールドである。ＴＩＥ命令のＩＳＡ記述の幾つかのさらに別の例を以下示す。
【数４７】

【０２２０】
命令の予測された結果についての十分な情報を獲得することができないので、ＴＩＥセマンチックの正確性をチェックすることができない。例えばａｃｃ命令の結果がテストで正しいか否かをチェックすることができない。しかしながら、ハードウェアが状態累算器で誤った結果を生成した場合には、これは別のセクションでさらに詳細に説明するように全ての命令の境界でＲＴＬとＩＳＳとの間の全てのユーザ状態およびレジスタファイルを比較するコシミュレーション機構によって検出される。以下のセクションは疑似コードのようなアルゴリズムを表現するために幾つかのＰＥＲＬを使用する。診断発生器はほとんどＰＥＲＬベースのプログラムである。
【０２２１】
正しいＴＩＥ命令を発生するために診断発生器により使用されるアルゴリズムを以下示す。
【数４８】

【０２２２】
また、ＴＩＥ命令を実行し始めることができる前に、ＴＩＥ状態およびレジスタファイルを初期化する必要がある。これは以下の方法で行われる。
【０２２３】
【数４９】

【０２２４】
［ＴＩＥに対するパイプライン情報］
ＴＩＥのバイパスおよびインターロック論理装置を試験するマイクロアーキテクチャの診断を生成するために、ＴＩＥ命令のパイプライン情報が必要とされる。これはレジスタおよび状態のようなリソースがＴＩＥ命令により読取られ書込まれるステージの知識を与える。ＴＩＥコンパイラはこの情報を提供し、これはＰＥＲＬオブジェクトで表され、検査ツールにより使用される。ユーザ定義レジスタファイルと、単にパイプラインの異なるステージでデータを移動する１組の命令に付いての以下の例を取り、コンベンション１：Ｅステージ、２：Ｍステージ、３：Ｗステージに注意する。
【数５０】

【０２２５】
これはＰＥＲＬデータベースで以下のように変換する。
【数５１】

【０２２６】
この情報がどのようにして次のセクションで診断を生成するために使用されるかを見ることができる。
【０２２７】
［ＴＩＥに対するマイクロアーキテクチャ試験］
このセクションの目的は、ＴＩＥとコアとの間のインターフェースの構成と、ならびにもしも存在すればＴＩＥ状態とレジスタファイルとの間のインターフェースの構成についての知識に基づいてＴＩＥ論理装置のマイクロアーキテクチャ診断を生成することである。ＴＩＥ自体のＩＳＡとパイプライン記述が使用されるが、前述したようにＴＩＥ命令の構成の“正確性”は直接テストでは確認されていない。
【０２２８】
ＭＶＰ診断のセットは以下の構成の特徴をテストするために生成される。　−コア／タイインターフェースの制御論理、
−ロード／記憶およびバイパスとインターロック論理を含むユーザ状態とレジスタファイルとの構成。
【０２２９】
［コアとＴＩＥとの間の制御信号］
例外、中断、リプレイ信号はテストの生成により試験され、ここではそれぞれのユーザ命令はコア（例えばブランチ）、例外およびリプレイ信号の制御フロー変化により削除される。命令はその実行の全てのステージで、丁度完了ステージまで削除されるべきである。
【０２３０】
これらのテストを生成するアルゴリズムは、ＴＩＥコンパイラにより生成されるＩＳＡ記述中の全てのＴＩＥ命令コードにわたって単に反復し、以下の各ケースを構成する。
ケースａ）フローの変化により削除されるＴＩＥ命令
【数５２】

【０２３１】
ケースｂ）例外により削除されるＴＩＥ命令
【数５３】

【０２３２】
認められるように、例外を発生する命令と、ＴＩＥ命令との間のノーオペレーション数はＴＩＥ命令実行のステージを制御し、それによって削除される。
【０２３３】
ケースｃ）パイプラインによりリプレイされるＴＩＥ命令
【０２３４】
【数５４】

【０２３５】
［ユーザ状態とレジスタファイルのバイパス論理］
これらの試験はそれらを書込み／読取る“ペアリング”命令によりＴＩＥ状態とレジスタファイルに対してバイパス論理を実行する。テストは命令に関してストールが存在しないことを確実にし、データを取出し、（構造が許容するならば）不必要なストールとエラーとしてのフラグを探すために命令シーケンスの前および後にサイクルカウントレジスタをチェックする。そのアルゴリズムを以下に示す。
【０２３６】
特定のレジスタファイルまたは状態に対して全ての読取り／書込みステージのリスト［ｉｎｓｔｒ， ｆｉｅｌｄ］を生成する。この状態／レグファイル（ｒｅｇｆｉｌｅ ）の最大の完了ステージをチェックする。書込みおよび読取り命令を対として組合わせ、最大の完了ステージまでの間のノーオペレーション数を変化する。
【数５５】

【０２３７】
命令シーケンスを二度実行することによりＩ＄とＤ＄が存在しないことを保証する必要がある。第２回の反復では、サイクルカウントチェックが行われる。予測された数のサイクルは読取り／書込みステージとノーオペレーションに基づいている。前述の例の幾つかの例のケースが以下のものである。
【０２３８】
【数５６】

【０２３９】
［インターロックおよびハザード］
このテストは、リードアフタライトのケース、ライトアフタライトのケースおよび（恐らく）ライトアフタリードハザードケースでストールを補正するものである。
【０２４０】
ハザードケースのアルゴリズムは前述のバイパスケースのアルゴリズムと類似して得られる。ステージ２および３で同一のレグファイルを書込む２つの命令が存在し、それに続いてステージ１でそれを読取る命令が続く。第３の命令は第２の書込み結果をストール（機能停止）する。
【０２４１】
【数５７】

【０２４２】
［ロード／記憶］
全てのレジスタファイルへのロードおよび記憶は以下のアルゴリズムを使用して、全ての整列および誤整列されたアドレスに対して包括的に試験される。
【数５８】

【０２４３】
ロードの予測された結果はロードのセマンチックに基づき、ほとんどのケースで決定されることができるが、全ての可能なセマンチックでそうすることは可能ではなく、その場合、チェックをその状態のままにしメモリを比較することが必要である。
【０２４４】
ＴＩＥロード／記憶命令のデータのブレークポイントはまた構成がデータのブレークポイントをサポートする場合にＴＩＥロード／記憶命令について試験される。データのブレークポイントがＴＩＥ命令で作用する態様の詳細はロード／記憶アーキテクチャセクションで見られる。生成された診断はデータブレークアドレスレジスタ、制御マスクレジスタ、ロード／記録のバーチャルアドレスの全ての可能な組合わせに対してデータのブレークポイントを試験する。
【数５９】

【０２４５】
整合するデータのブレークポイントはデバッグ例外を生じる。前述の試験のデバッグ例外ハンドラは例外が本当に生じたことを確認するためにチェックされるカウンタを更新する。これに加えて、さらに複雑なケースも構成され、ここではデータのブレークポイントを有するロード／記憶はこのような例外の正確な優先順位を確認するために（レジスタウィンドウイング作用について）オーバーフロー／アンダーフロー例外と一致する。
【０２４６】
［ＴＩＥ命令のランダム診断発生器］
ランダム診断はコアＩＳＡと、その構造のマイクロアーキテクチャの確認において主要な役目を行う。命令のランダムシーケンスは指令された試験によりカバーされる可能性の少ない境界のケースおよび他のシナリオに衝突する可能性がある。これらは設計確認のカバー計量にも付加される。付加的なインテリジェンスは幾つかの特徴を付加することによりこれらのランダム発生器に付加されている。例えば、命令シーケンスのテンプレートはターゲット特定の興味のあるシナリオに対して作成されることができる。これの例は書込みバッファ、またはゼロオーバーラップループを単一命令で充填するバックツーバック記憶装置である。各命令タイプまたは命令シーケンスに添付された相対的な確率は特定の種類の命令を生成しようとする頻度を決定することができ、例えばブランチ命令が高い相対的な確率（または加重）を有するならば、生成される試験はさらに多くのブランチを有する。ユーザ制御されたパラメータは生成される試験特性を調節できる。例えばコマンドラインアーギュメントはある命令の相対的な加重、テストの長さ、ネストされた機能呼の数等を制御できる。ランダム診断発生器は、同様にユーザ定義されたＴＩＥ命令を生成することができる。
【０２４７】
基礎的なメカニズムはマイクロアーテキテクチャ試験のメカニズムに類似している。ランダム発生器はコアＩＳＡと同様にＴＩＥ命令を含んでいるＩＳＡ記述を読取る。有効なＴＩＥ命令は特定のＴＩＥ命令のＩＳＡ記述を見て、幾つかのレジスタ割り当て機構を使用することにより構成される。
【数６０】

【０２４８】
ランダム発生器は、構成システムのエンドユーザによりアクセス可能ではないが、内部確認と、前述したようなＴＩＥ記述の範囲全体で使用されることが好ましく、８、１６、３２、６４、１２８ ビットのような可変幅、および状態のＴＩＥレジスタファイルの完全なケースをさらに含んでいる。さらに、エンドユーザはさらに別の確認で使用するためにランダム発生器へのアクセスを与えられてもよい。
【０２４９】
［ＴＩＥ検査のカバー区域測定］
前述したように、この確認の目標はコアとＴＩＥインターフェースの正確性と、ユーザ定義状態、レジスタファイル、関連する論理、ＴＩＥ命令のハードウェアへの正確な変換の構成を確実にする。これらの領域の幾つかのカバー区域計量が必要である。
【０２５０】
これはＴＩＥコンパイラにより生成されるＲＴＬの基本的な設計のカバー区域を指すことを意味するのではなく、前述の領域の機能的なカバー区域を指す。ＴＩＥに対するこのようなカバー区域評価を行うことは非常に困難であるが、ＲＴＬと共に作動する幾つかの機能的なカバー区域モジュールを生成し、幾つかのカバー区域の測定を報告するための方法が開発されている。例えば１つの重要な領域は、ＴＩＥレジスタファイルと状態との間の全てのバイパス路である。バイパスを試験するために生成された診断は全ての可能なバイパス路をカバーするが、目標はＲＴＬの確認と独立した確認を有することである。そうするために、幾つかのＶｅｒｉｌｏｇ ／ＶＥＲＡモジュールはＴＩＥ記述とパイプライン情報から自動的に生成される。これらのモジュールはカバーされたバイパス路を報告するためにＲＴＬシミュレーション時間中に動作する。
【０２５１】
既に先のセクションで見られた１２８ビットレジスタファイルｉ１２８の例を取ると、図１３はハードウェアにおけるこのような汎用目的のレジスタファイルと、その構造を示している。図面は１つの読取りポートＲｄ０と１つの書込みポートＷｄを示している。典型的にレジスタファイルには２つの読取りポートと１つの書込みポートが存在する。信号のネーミングコンベンションは、
＜ｐｏｒｔ 　ｎａｍｅ＞ 　＜ｓｉｇｎａｌ 　ｎａｍｅ＞ 　＜ｓｔａｇｅ　ｎａｍｅ＞
ここで、
ｐｏｒｔ　ｎａｍｅ：レジスタファイルの名称（Ｒｄ０、Ｒｄ１、Ｗｄ）
ｓｉｇｎａｌ　ｎａｍｅ：信号名称は、
ｒｅａｄ ｐｏｒｔ ：ｍｕｘ：ｍｕｘの出力
ｄａｔａ：ＴＩＥのデータパス装置へ行くフリップフロップ　　　　　　　　　　　　　 の出力
ｗｒｉｔｅ ｐｏｒｔ：ｍｕｘ：ｍｕｘの出力
ｄａｔａ：データパス装置の出力
ｒｅｓｕｌｔ：フリップフロップの出力
ｓｔａｇｅ 　ｎａｍｅ：これはパイプラインのステージを示す。
先のセクションで説明したように、ここでのコンベンションは、
Ｃ０：Ｒステージ、Ｃ１：Ｅステージ、Ｃ２：Ｍステージ、Ｃ３：Ｗステージ　簡単にする目的で、以下の説明は全てのＴＩＥ命令をＭステージの終了した後ではなくレジスタファイルを書き込むことに限定する。
【０２５２】
ブロック図はこれらのステージの異なるバイパス路を示している。（前に述べたセクションではレジスタファイルの使用として表された）ステージ１および２のデータパスにより読取られる読取りポートＲＤ０において、以下はブロック図を示しまたは説明している。【数６１】

ステージ２および３で書き込まれた書込みポートＷｄは類似のバイパス路を有する。
【０２５３】
【数６２】

【０２５４】
［バイパス路のカバー区域］
好ましい実施形態の目標は、前述のブロック図の全てのバイパス路が検査されているか否かをチェックするモニタを生成することである。１例のバイパス路は図１３では破線のパスで示されている。モニタは基本的にパスを通るデータを追跡し、したがって非常に重要な仮定を行うことが必要であり、これはデータがＴＩＥのデータパス装置で変化されていないことである。これは以下のチェックが行われることができることを意味している。
Ｗｄ　ｄａｔａ　Ｃ１＝＝Ｒｄ０　ｄａｔａ　Ｃ１
ＴＩＥ命令がＥステージ（Ｃ１）でデータを読取り、Ｅステージで出力データを発生する仮定により、データは変更されない。これは勿論、任意の真のＴＩＥ命令では当てはまらない。しかしながら、試験するため、（本物のハードウェアでは除去される）ユーザＴＩＥにおける幾つかの“アイデンティティ”が紹介される。これらの命令は特にコピーデータを単に試験するものである。この例では、２つのアイデンティティ命令が得られる。
Ｉｄｅｎｔｉｔｙ １：ｕｓｅ Ｃ１， ｄｅｆ Ｃ１：これはＥステージでレジスタファイルを読み、Ｅステージで同一のデータを生成する。
Ｉｄｅｎｔｉｔｙ ２：ｕｓｅ Ｃ１， ｄｅｆ Ｃ２：これは１サイクル遅延後にデータを発生する。
【０２５５】
モニタ生成の冒頭で説明したが、全てのバイパス路が検査されたか否かを試験するＶｅｒａモジュールを生成するアルゴリズムを説明する。ＴＩＥコンパイラにより生成される情報が使用され、前述の信号名称コンベンションを以下示す。
【数６３】

【０２５６】
信号リストを作成するサブルーチンの動作は簡単にするために省略されているが、当業者には明白であろう。１つの重要な注意は、データパスが信号のリストでどのように表されるかである。データパスが書込みステージ＞読取りステージ（例えば前述のＩｄｅｎｔｉｔｙ ２命令）を有するならば、データパス装置で費やされるサイクル数（この説明では２サイクルのＴＩＥ命令の限定にしたがって１まで）が単に付加される。
【０２５７】
図１３で破線で示されているパスは以下のように信号リストとしてまたは前述のアルゴリズムからのトレースから生成される。
ｉ１２８　ｗｄ　ｄａｔａ　ｃ２−＞
ｉ１２８　ｒｄ０ 　ｍｕｘ 　ｃ０−＞
ｉ１２８　ｒｄ０ 　ｄａｔａ　ｃ１−＞
ｗａｉｔｃｙｃｌｅｓ１−＞
ｉ１２８　ｗｄ　ｄａｔａ　ｃ２−＞
ｉ１２８　ｗｄ　ｍｕｘ 　ｃ２−＞
ｉ１２８　ｗｄ　ｒｅｓｕｌｔ　ｃ３
ここで、ｉ１２８はレジスタファイル名称である。ＸｔｅｎｓａのトップレベルからＴＩＥレジスタファイルｉ１１２８へのパスはこれにプリペンドされている。図１３からのデータパスのｒｄ０ 　ｄａｔａ　ｃ１−＞ｗｄ　ｄａｔａ　ｃ２は信号トレースにおいて待ちサイクル１として表されていることに注意する。
【０２５８】
このような信号トレースのリストは、全てのバイパス路で生成される。信号トレースに基づいて、小さいモニタモジュールはこの通路がトレースされているか否かをチェックするためにＶｅｒｉｌｏｇ ／Ｖｅｒａで生成される。トレースされているならば、シミュレートの終了時にこのパスで１を報告する。各モニタは基本的に以下のアルゴリズムにより生成される小さい状態マシーンである。
ａ）状態マシーンの状態数を決定し、
状態数＝信号トレース＋の（Ｅからの）ステージ数
状態におけるデータパスのｍ／ｃサイクル数
ｂ）状態にしたがって信号をグループ化し、
ｃ）以下のコードを生成する。
【数６４】

【０２５９】
例えばバイパス路を生成する状態マシーンを以下に示す。
【０２６０】
【数６５】

【０２６１】
［確認の要約］
入力基準命令セマンチックの正確性を試験するために、ＴＩＥコーダはイントリンシックスを使用して新しい命令を使用するためにアプリケーションを変更し、その後（１）これをマシーンコードにコンパイルし、命令セットシミュレータによりアプリケーションを作動するか、または（２）ネイティブコードにコンパイルし、イントリンシックの互換性を与えるためにＴＩＥコンパイラにより出力されたマクロおよび機能を使用する。アプリケーションの正確性はこれらの２つのオプションのいずれか一方により命令基準セマンチックスの正確性を確認する。基準セマンチックスの変換はオプション２により確認され、拡張されたコンパイラおよびシミュレータの正確性はオプション１により確認される。アプリケーションにより与えられたものを超える付加的なカバー区域は、特別なケース（例えば普通でないまたは“コーナー”の場合）の試験を生成するためにテストケースＴＩＥ構造の使用によるものである。
【０２６２】
構成セマンチックは前述の方法と同一方法を使用する基準セマンチックスの代わりにこれらを変換するためにＴＩＥコンパイラオプションを使用することによって確認されてもよい。構成セマンチックとそれらのＨＤＬへの変換もまた、それぞれＨＤＬへの変換において動作する市場で等価のチェックツールにより基準セマンチックスに類似して形式的に確認されてもよい。構成セマンチックとそれらの変換もまたＨＤＬシミュレータで動作するＴＩＥ規定のテストのケースの使用によりチェックされる。
【０２６３】
レジスタファイルのＴＩＥコンパイラ、インターロック、バイパス、コアインターフェース、および例外によって生成されるＨＤＬはＴＩＥ入力に基づいて自動的に生成された試験を動作し結果を確認するためのコシミュレーションを使用することにより確認される。これらの試験はインターロック、バイパスおよび例外の全ての組合わせを徹底的に試験するためパイプライン仕様を使用する。
【０２６４】
ＴＩＥコンパイラにより生成されるＨＡＬコードは命令セットシミュレータでそれを実行することにより検査される。新しい命令のアセンブラおよびコンパイラサポートはほとんど前述のようにして検査される。
【０２６５】
［プロセッサのコシミュレーション］
コシミュレーションはＲＴＬと参照モデルを並列に動作し、特定された境界においてＩＳＡで規定された構造的な可視状態を比較するプロセスである。
【０２６６】
コシミュレータ（以後“ｃｏｓｉｍ”とする）は、ＲＴＬシミュレータ、ＩＳＳ、および多数の他のモニタ／チェッカタスクとの間のシンクロナイザおよびゲートウェイとして作用する。診断はＲＴＬとＩＳＳとの間にミスマッチが生じるとすぐに、またはアサーションチェッカが破局的事象を通報するときに失敗する。
【０２６７】
コシミュレーションの使用には幾つかの利点がある。第１に、失敗した診断を容易にデバッグすることである。これは問題が生じたサイクル（またはその近く）でシミュレーションを停止させ、デバッグ時間と労力を著しく減少させる。
【０２６８】
第２に、さらに状態チェックを行う。これはプログラム実行を通じてプロセッサ状態の観察を可能にし、それによって正確な最終結果を生成しながら、エラーのある中間結果を生成するケースを通報する。
【０２６９】
最後に、コシミュレーションにより、自己チェックの必要はない。ランダム診断が実行され、チェックされることができる。
【０２７０】
好ましい実施形態では、ＩＳＳは参照モデルであり、境界は命令の退去と外部イベントが生じるときにはいつでも規定される。比較される構造的な可視の状態のセットは構成可能である。構成可能なプロセッサによりｃｏｓｉｍを使用する１つの挑戦はＲＴＬとＩＳＳを比較するプロセスに関する完全な知識がないことである。ＲＴＬとＩＳＳとの比較について知られていることは、比較は命令退去境界と外部イベントの発生で生じることを必要とすることである。しかしながら、ＲＴＬとＩＳＳで比較されるべきプロセッサ状態はユーザがその構成に含まれるように選択するプロセッサオプションに依存する。プロセッサオプションがプロセッサコアの特別な構成に含まれないとき、状態はＲＴＬまたはＩＳＳのいずれにも存在しないので、ｃｏｓｉｍ環境はオプションにより導入される状態を比較しようと試みてはならない。したがって、好ましい実施形態は、構成可能で、プロセッサ構成中にソフトウェアおよびハードウェアと共にカスタマイズされるｃｏｓｉｍ環境を使用する。
【０２７１】
［ＴＩＥによりｃｏｓｉｍを動作させる態様］
ユーザがＴＩＥを使用してプロセッサ状態と命令セットを拡張する能力は、ｃｏｓｉｍ環境がプロセッサ状態および命令セットについての事前に完全な知識なしに開発される必要があるので、ｃｏｓｉｍプロセスを複雑にする。ＴＩＥの存在する場合、ｃｏｓｉｍ環境は新しいプロセッサ状態を決定できる必要があり、その新しいプロセッサ状態は比較され／確認にされ、新しい状態がＲＴＬとＩＳＳの間で比較される境界を決定する。ｃｏｓｉｍがこれらの２つの要求／目標を実現できるようにするために、ＴＩＥで定義されている新しいプロセッサ状態に関する情報を必要とする。ｃｏｓｉｍにより必要とされる情報は新しい状態の名称と、状態エレメントの幅と、状態を定義する完全なＲＴＬ階級（パス）と、状態がリセットで定義されるか否かと、これが個々の状態またはレジスタファイルであるか否かと、状態がレジスタファイルであるときのエントリ数とを含んでいる。
【０２７２】
ｃｏｓｉｍにより必要とされる情報は３つのステップでユーザのＴＩＥ記述から生成される。最初に、図１４で示されているように、ＴＩＥコンパイラはＴＩＥ記述をパーズし、入力ファイルに定義されている状態の中間表示を生成する。この中間表示はその後、ｃｏｓｉｍプリプロセッサにより新しいＴＩＥ状態の確認に必要なｃｏｓｉｍソースコードを生成するために使用される。最後に、生成されたｃｏｓｉｍコードは所定の構成に特定のｃｏｓｉｍ環境を生成するために残りのｃｏｓｉｍフレームワークと一体化される。これは好ましくは例えばカリフォルニア州マウンテンビューのＳｙｎｏｐｓｙｓ社によるＶｅｒａ（商標名）Ｓｙｓｔｅｍ Ｖｅｒｉｆｉｅｒ で構成されるようなＶｅｒａ（商標名）コシミュレーション言語でコードを生成するためｔｐｐを使用して行われる。
【０２７３】
以下のセクションはｃｏｓｉｍプリプロセッサと、前述のガロアフィールドのＴＩＥ例と連結して得られた発生されたｃｏｓｉｍソースコードの例を含んでいる。
【数６６】

ｃｏｓｉｍソースコード（レジスタファイルの比較）：
【数６７】

ｃｏｓｉｍ出力プログラム（レジスタファイルの比較）：
【数６８】

ｃｏｓｉｍソースコード（ＴＩＥ状態の比較）：
【数６９】

ｃｏｓｉｍ出力プログラム（ＴＩＥ状態の比較）：
【数７０】

【０２７４】
したがって、要約すると、Ｋｉｌｌｉａｎ の明細書に記載されているシミュレータを好ましい実施形態で動作するように適合するため、主に状態への一般化に対処するための多数の変化を行わなければならない。ＴＩＥ状態は任意の幅であるので、インターフェースは任意の大きさのレジスタ値を必要とされるが、インターフェースは性能の理由でいつでも使用されるわけではないことが好ましい。このため、レジスタはクラスに区分され、ｇｄｂとｃｏｓｉｍインターフェースはこれらが１つのクラスと、単一の整数コードから１つのクラス内のインデックスを発見することができるように変更される。ソケットインターフェースは任意の幅値が送信および受信されることができるように変更される。新しいメモリインターフェースは広いロードと記憶域をサポートするために付加される。ＴＩＥ状態の初期化はレジスタファイルと、レジスタのコプロセッサへの割当てをサポートするために一般化される。ＴＩＥ状態のアクセスに関連するシミュレートパイプライン遅延のサポートも付加される。ＴＩＥ状態へのインターフェースはＣＰＥＮＡＢＬＥ例外をシミュレートするために変更される。
【０２７５】
［要約］
前述した主要な新しいＴＩＥ構造を要約すると、これらが影響する生成されたファイルおよびそれらの通常目的が以下の表ＩＩＩ に与えられている。
【表４】

本発明を好ましい実施形態を伴って前述したが、これは単に例示の目的で行われたものであり、本発明はそれに限定されない。本発明の変形は当業者に容易に明白であり、それらは本発明の技術的範囲内に含まれる。
［付属資料］
【数７１】

【０２７６】
【図面の簡単な説明】
【図１】
好ましい実施形態にしたがった４ステージのパイプライン化された拡張可能なレジスタに関する制御論理の構成図。
【図２】
好ましい実施形態にしたがった４ステージのパイプライン化された拡張可能なレジスタに関する制御論理の構成図。
【図３】
図１および２のレジスタの２ステージバージョンの構成図。
【図４】
第１の実施形態にしたがったコア加算器への信号インターフェースの説明図。
【図５】
従来のロード整列装置の構成図。
【図６】
好ましい実施形態にしたがったロード整列装置の構成図。
【図７】
好ましい実施形態にしたがったセマンチックブロック信号出力インターフェースの構成図。
【図８】
好ましい実施形態にしたがったパイプラインレジスタ最適化の説明図。
【図９】
好ましい実施形態の例外処理の説明図。
【図１０】
好ましい実施形態のさらに別の例外処理の説明図。
【図１１】
好ましい実施形態の基準セマンチックス情報処理の構成図。
【図１２】
好ましい実施形態にしたがった自動的に生成された命令文書化の構成図。
【図１３】
好ましい実施形態にしたがったＴＩＥ検査プロセスの説明図。
【図１４】
好ましい実施形態のコシミュレーションプロセスの説明図。

Claims (49)

1. 構成可能なプロセッサを設計するシステムにおいて、
   予め定められた部分とユーザ定義部分とを含んでいる構成可能な仕様に基づいてプロセッサのハードウェア構成の記述を生成するハードウェア生成手段と、
   構成仕様に基づいてハードウェア構成に特別なソフトウェア開発ツールを生成するソフトウェア生成手段とを具備し、
   ハードウェア生成手段は、構成仕様のユーザ定義部分に基づいてプロセッサのハードウェア構成の記述のユーザ定義レジスタファイルを含むものであり、
   ソフトウェア生成手段は、ソフトウェア開発ツールのユーザ定義プロセッサレジスタファイルに関連するソフトウェアを含むものであるシステム。
2. ユーザ定義プロセッサレジスタファイルに関連するソフトウェアは命令のフィールドにしたがってレジスタファイルの素子をアクセスする命令を含んでいる請求項１記載のシステム。
3. ハードウェア生成手段は、レジスタ転送レベルのハードウェア記述言語に少なくとも一部分のハードウェア構成記述を生成する請求項２記載のシステム。
4. 構成仕様はレジスタファイル中の素子幅を特定するステートメントを使用してレジスタファイルを規定する請求項１記載のシステム。
5. 構成仕様はレジスタファイルの素子数を特定するステートメントを使用してレジスタファイルを規定する請求項１記載のシステム。
6. ハードウェア生成手段は、構成仕様と独立してレジスタファイルの少なくとも１つの読取りポートと書込みポートの数を決定する請求項１記載のシステム。
7. ハードウェア生成手段は、構成仕様中のスケジューリング情報に基づいて読取りポートの数を決定する請求項６記載のシステム。
8. ハードウェア生成手段は、プロセッサのハードウェア構成記述の一部分として、データのステージング価格を最小にするために命令オペランドへユーザ定義レジスタファイルの書込みポートを割当てるための論理記述を生成する請求項１記載のシステム。
9. ハードウェア生成手段はレジスタファイルにアクセスするパイプライン論理を生成する請求項１記載のシステム。
10. ユーザ定義レジスタファイルの読取りポートは、それらをソースオペランドとして使用する任意の命令の最も早期の段で読取られる請求項９記載のシステム。
11. ユーザ定義レジスタファイルの書込みポートはそれを目的地オペランドとして使用する任意の命令の最終段、またはその後であるならば命令コミット段で読み取られる請求項９記載のシステム。
12. ハードウェア生成手段は、プロセッサのハードウェア構成の部分として、レジスタファイルをアクセスする命令内で、レジスタファイルからソースオペランドを選択するために使用される各フィールドのレジスタファイルの読取りポートを与える論理を発生する請求項１記載のシステム。
13. ハードウェア生成手段は、プロセッサのハードウェア構成の一部分としてレジスタファイルにアクセスするためのバイパス論理を生成する請求項１記載のシステム。
14. ハードウェア生成手段は、命令オペランドに基づいた構成仕様と、構成仕様の状態使用記述により説明されたプロセッサの所定のパイプラインのインターロック論理を生成する請求項１３記載のシステム。
15. ハードウェア生成手段は、プロセッサのハードウェア構成の一部分として、レジスタファイルをアクセスするインターロック論理を生成する請求項１記載のシステム。
16. ハードウェア生成手段は、構成仕様のスケジューリング情報に基づいてインターロック論理を生成する請求項１５記載のシステム。
17. ハードウェア生成手段は、命令オペランドに基づいた構成仕様と、構成仕様の状態使用記述により説明されたプロセッサの所定のパイプラインのインターロック論理を生成する請求項１５記載のシステム。
18. ハードウェア生成手段は、ユーザ定義レジスタファイルのアクセスをサポートするために構成仕様の予め定められた部分により記述されるプロセッサ論理装置の少なくとも１部分を使用するようにプロセッサハードウェア構成記述を生成する請求項１記載のシステム。
19. プロセッサ論理装置の少なくとも一部分はアドレス計算論理装置を含んでいる請求項１８記載のシステム。
20. アドレス計算論理装置はアドレス加算器論理装置を含んでいる請求項１９記載のシステム。
21. プロセッサ論理装置の少なくとも一部分は予め定められた部分とユーザ定義部分との間で共有されるデータ整列論理装置を含んでいる請求項１９記載のシステム。
22. プロセッサ論理の少なくとも一部分はデータメモリである請求項１９記載のシステム。
23. 構成仕様のユーザ定義部分は条件的にユーザ定義レジスタファイルに書込みをする命令の記述を含んでいる請求項１記載のシステム。
24. ソフトウェア生成手段は、ユーザ定義レジスタファイルに関するソフトウェアの部分として、構成仕様に基づいて設計確認とプロセッサの製造の診断試験を行う請求項１記載のシステム。
25. 構成仕様は、プロセッサの命令に対する基準および構成セマンチックスの両者を含んでおり、
    基準セマンチックスは構成セマンチックの設計の正確さを確認するために使用されることができる請求項１記載のシステム。
26. プロセッサ命令セット記述言語は命令試験のケースを含んでおり、
    ソフトウェア生成手段は試験のケースの診断を行う請求項１記載のシステム。
27. ソフトウェア生成手段は、アプリケーションを実行しながらオペランドをプロセッサ命令セット記述言語の命令にサンプリングすることによって試験ベクトルを自動的に生成する請求項１記載のシステム。
28. ソフトウェア生成手段はユーザ定義状態とレジスタファイルに関するソフトウェアの一部分としてオペレーティングシステムの少なくとも一部を生成する請求項１記載のシステム。
29. 発生されたオペレーティングシステム部分はプロセッサ状態の保存および回復シーケンスを含んでいる請求項２８記載のシステム。
30. 保存および回復シーケンスはコンポーネント状態の相互依存性に関して生成され、相互依存性に対して確認される請求項２９記載のシステム。
31. オペレーティングシステムはタスク交換中にプロセッサ状態全体より少なくしか記憶できない請求項２８記載のシステム。
32. 構成仕様のユーザ定義部分は構成仕様の予め定められた部分でみられないソフトウェアデータタイプを規定し、
    コンパイラはソフトウェアデータタイプをサポートする請求項２８記載のシステム。
33. ソフトウェア生成手段はユーザ定義レジスタファイルに関するソフトウェアの一部分としてコンパイラ、リンカ、シミュレータ、デバッガの少なくとも１つを生成する請求項１記載のシステム。
34. ソフトウェア生成手段はユーザ定義レジスタファイルに関するソフトウェアの一部分としてコンパイラを生成し、
    コンパイラはユーザ特定レジスタファイル中のレジスタへプログラム変数を割当てることができる請求項１記載のシステム。
35. コンパイラはさらに、メモリからユーザ定義レジスタファイルのレジスタへ値をロードし、ユーザ定義レジスタファイルのレジスタ中の値をメモリに記憶することができる請求項３４記載のシステム。
36. コンパイラはさらに、ユーザ定義レジスタファイルの１つのレジスタからユーザ定義レジスタファイルの別のレジスタへ値を移動できる請求項３４記載のシステム。
37. コンパイラはユーザ定義レジスタファイルをアクセスするソフトウェア生成手段により生成されるソフトウェアの命令のストールサイクルを決定するために構成仕様でスケジューリング情報を使用する請求項３４記載のシステム。
38. ソフトウェア生成手段はバイパス通路のカバー範囲をチェックするためにモニタを自動的に生成する請求項１記載のシステム。
39. 構成可能なプロセッサを設計するシステムにおいて、
    予め定められた部分とユーザ定義部分を含んでいる構成仕様に基づいて、プロセッサのハードウェア構成の記述を生成するハードウェア生成手段と、
    構成仕様に基づいて、ハードウェア構成に特定のソフトウェア開発ツールを生成するソフトウェア生成手段とを具備し、
    構成仕様はソフトウェア開発ツールで使用される命令のスケジューリング情報を特定するステートメントを含んでおり、
    ハードウェア生成手段は、構成仕様に基づいて、少なくとも１つのパイプライン論理と、パイプラインストーリング論理と、命令再スケジューリング論理との少なくとも１つの記述を生成するシステム。
40. スケジューリング情報は命令のオペランドが所定の段でプロセッサのパイプラインに入るステートメントを含んでいる請求項３９記載のシステム。
41. スケジューリング情報は命令の演算が所定の段でプロセッサのパイプラインを出るステートメントを含んでいる請求項３９記載のシステム。
42. ソフトウェア生成手段により生成されたソフトウェアは構成仕様のユーザ定義部分に記述されている命令を使用するコンパイラを含んでおり、
    コンパイラは構成仕様のユーザ定義部分に説明されている命令をスケジュールするために命令スケジュール中にスケジューリング情報を使用する請求項３９記載のシステム。
43. 構成仕様は複数のプロセッササイクルが処理されることを必要とする命令の記述を含んでいる請求項３９記載のシステム。
44. 構成仕様は、プロセッサのターゲットパイプラインと独立している命令のセマンチックの記述を含んでおり、
    ハードウェア生成手段は命令セマンチックから分離したパイプライン記述に基づいてパイプラインのプロセッサハードウェア構成の一部分としてパイプラインを生成する請求項４３記載のシステム。
45. 構成可能なプロセッサを設計するシステムにおいて、
    予め定められた部分とユーザ規定部分とを含んでいる構成仕様に基づいて、プロセッサのハードウェア構成の記述を生成するハードウェア生成手段と、
    構成仕様に基づいて、ハードウェア構成に特有のソフトウェア開発ツールを生成するソフトウェア生成手段と、
    構成仕様に基づいて構成仕様により記述されたプロセッサ命令セットの文書を生成する文書生成手段とを具備しているシステム。
46. 文書生成手段はプロセッサ命令セットの文書を生成するために構成仕様中に規定されている命令の基準セマンチックスを使用する請求項４５記載のシステム。
47. 構成仕様のユーザ定義部分は、ここで規定されている命令の基準セマンチックと、ユーザ定義命令の概要とユーザ定義命令のテキスト記述の少なくとも一方のユーザ規定仕様を含んでおり、
    文書生成手段は、プロセッサ命令セットの文書を生成するために概要とテキスト記述の少なくとも一方を使用する請求項４５記載のシステム。
48. 構成可能なプロセッサを設計するシステムにおいて、
    予め定められた部分とユーザ定義部分とを含んでいる構成仕様に基づいて、プロセッサのハードウェア構成の記述を生成するハードウェア生成手段と、
    構成仕様に基づいて、ハードウェア構成に特有のソフトウェア開発ツールを生成するソフトウェア生成手段とを具備し、
    構成仕様はプロセッサ命令が例外を挙げたときプロセッサ例外の仕様を含んでおり、
    ハードウェア生成はプロセッサハードウェア構成の一部分としてその例外をサポートするハードウェアを生成するシステム。
49. 拡張可能なプロセッサのハードウェア記述を実行するハードウェアシミュレーション手段と、
    拡張可能なプロセッサのソフトウェア基準モデルを実行するソフトウェアシミュレーション手段と、
    ハードウェアシミュレーション手段とソフトウェアシミュレーション手段とを動作し、そこからのシミュレーション結果を比較して拡張可能なプロセッサのハードウェア記述と拡張可能なプロセッサのソフトウェア参照モデルとの対応を設定するコシミュレーション手段とを具備しているプロセッサシミュレーションシステム。

Images