JP6882320B2 - ベクトル命令の処理 - Google Patents

Description

本技法は、データ処理の分野に関する。より詳細には、本技法は、ベクトル命令（ｖｅｃｔｏｒ ｉｎｓｔｒｕｃｔｉｏｎ）の処理に関する。

いくつかのデータ処理システムは、命令のソース・オペランド又は結果値が、複数のデータ要素を含むベクトルである、ベクトル命令の処理をサポートする。単一の命令に応答したいくつかの別個のデータ要素の処理をサポートすることによって、コード密度が改善され、命令のフェッチング及び復号のオーバーヘッドが低減され得る。処理されるべきデータ値のアレイが、データ値をベクトル・オペランドのそれぞれの要素にロードすることと、単一のベクトル命令を使用してデータ値、いくつかの要素を一度に処理することとによって、より効率的に処理され得る。

少なくともいくつかの実例は、
ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための処理回路を備える装置であって、
所与のベクトル命令に応答して、処理回路が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理回路は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するように構成され、
イベントに応答して、処理回路が、前記所与のベクトル命令の処理を中断するように構成され、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰（ｒｅｔｕｒｎ−ｆｒｏｍ−ｅｖｅｎｔ）要求に応答して、処理回路が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成され、
ベクトル値が、処理回路にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
処理の各ビートが、前記データ要素サイズ情報によって示されたデータ要素サイズにかかわらず、ベクトル値の固定サイズ部分に対応する処理を含む、
装置を提供する。

少なくともいくつかの実例は、
ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための手段を備える装置であって、
所与のベクトル命令に応答して、処理するための手段が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理するための手段は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するように構成され、
イベントに応答して、処理するための手段が、前記所与のベクトル命令の処理を中断するように構成され、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、処理するための手段が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成され、
ベクトル値が、処理するための手段にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
処理の各ビートが、前記データ要素サイズ情報によって示されたデータ要素サイズにかかわらず、ベクトル値の固定サイズ部分に対応する処理を含む、
装置を提供する。

少なくともいくつかの実例は、ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理する方法を提供し、本方法は、
所与のベクトル命令に応答して、処理の複数のビートを実施するステップであって、各ビートが、ベクトル値の一部分に対応する処理を含む、ステップと、
前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するステップと、
イベントに応答して、前記所与のベクトル命令の処理を中断するステップと、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するステップと
を含み、
ベクトル値が、データ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
処理の各ビートが、前記データ要素サイズ情報によって示されたデータ要素サイズにかかわらず、ベクトル値の固定サイズ部分に対応する処理を含む。

少なくともいくつかの実例は、上記で説明された装置に対応する、命令実行環境を与えるようにホスト・データ処理装置を制御するためのプログラム命令を含む、仮想マシン・コンピュータ・プログラムを提供する。

仮想マシン・コンピュータ・プログラムを記憶するコンピュータ可読記憶媒体も、提供され得る。本記憶媒体は、非一時的記憶媒体であり得る。

本技法のさらなる態様、特徴及び利点は、添付の図面とともに読まれるべきである、実例の以下の説明から明らかであろう。

ベクトル命令の処理をサポートするデータ処理装置の実例を概略的に示す図である。 ベクトル命令の重複実行（ｏｖｅｒｌａｐｐｅｄ ｅｘｅｃｕｔｉｏｎ）の実例を示す図である。 連続するベクトル命令間、異なるプロセッサ実装形態間、又はランタイムにおける命令の実行の異なるインスタンス間の重複の量をスケーリングすることの３つの実例を示す図である。 スカラー命令（ｓｃａｌａｒ ｉｎｓｔｒｕｃｔｉｏｎ）の実行が、２つのベクトル命令間の重複を断つ実例を示す図である。 複数のベクトル命令のブロックのどのビートが完了したかを示すためのビート・ステータス情報のための例示的な符号化を示す図である。 デバッグ・イベント又は例外の発生に関するビート・ステータス情報を記録することの２つの実例を示す図である。 デバッグ・イベント又は例外からの復帰に続いて処理を再開するためにビート・ステータス情報を使用することの実例を示す図である。 ベクトル命令の完了に応答して、ステータス情報を更新する方法を示す図である。 例外イベントをハンドリングする方法を示す図である。 例外イベントのハンドリングから復帰する方法を示す図である。 混合スカラー・ベクトル命令（ｍｉｘｅｄ−ｓｃａｌａｒ−ｖｅｃｏｒ ｉｎｓｔｒｕｃｔｉｏｎ）のビートを重複させるときの緩和された実行（ｒｅｌａｘｅｄ ｅｘｅｃｕｔｉｏｎ）の実例を示す図である。 混合スカラー・ベクトル命令のビートを重複させるときの緩和された実行の実例を示す図である。 異なるクラスの命令を処理するための処理回路内の異なるハードウェア・ユニットの実例を示す図である。 同じクラスの２つの混合スカラー・ベクトル命令が遭遇されるとき、重複実行を防ぐことの実例を示す図である。 所定の数の介在する命令によって２つの混合スカラー・ベクトル命令を分離することが、緩和された実行を回避するのをどのように支援するかを示す実例の図である。 緩和された実行を防ぐためにバリア命令（ｂａｒｒｉｅｒ ｉｎｓｔｒｕｃｔｉｏｎ）を使用することの実例を示す図である。 混合スカラー・ベクトル命令をハンドリングする方法を示す図である。 混合スカラー・ベクトル命令の重複実行のさらなる実例を示す図である。 使用され得る仮想マシン実装形態を示す図である。

いくつかの特定の実例が、以下で説明されることになる。本技法はこれらの厳密な実例に限定されないことを諒解されたい。

所与の命令セット・アーキテクチャに従って書かれたソフトウェアが、異なるハードウェア実装形態を有する様々な異なるデータ処理装置上で実行され得る。命令の所与のセットが、実行されたとき、アーキテクチャによって予想される結果を与える限り、特定の実装形態は、このアーキテクチャ準拠を達成する任意のやり方で、それのマイクロアーキテクチャ設計を自由に変化させることができる。例えば、いくつかの適用例では、エネルギー効率が性能よりも重要であり得、したがって、命令セット・アーキテクチャからの命令を実行するために与えられる処理回路のマイクロアーキテクチャ設計は、これが性能を犠牲にする場合でも、できるだけ小さいエネルギーを消費するように設計され得る。他の適用例は、性能を、エネルギー効率よりも重要な基準と見なし得、したがって、命令のより大きいスループットを可能にするが、より多くの電力を消費し得る、より複雑なハードウェア構造を含み得る。したがって、命令セット・アーキテクチャが様々な異なるエネルギー又は性能ポイントにわたるスケーリングをサポートするように命令セット・アーキテクチャを設計することが望ましいことがある。

いくつかの命令セット・アーキテクチャは、ソース・オペランド又は結果値のいずれか（又はその両方）が、複数のデータ要素を含むベクトルである、処理を実施するように、処理回路をトリガするためのベクトル命令をサポートする。いくつかのマイクロアーキテクチャ実装形態は、ベクトルの要素のすべてを並行して処理し得るが、他の実装形態は、ベクトルを一度に一部分、処理し得る。

命令実行の所与のスレッドの処理中に、処理回路が何らかの他のタイプの処理を実施することができるように、現在のスレッドの所与のベクトル命令の中断をトリガする、あるイベントが検出されることがある。例えば、イベントは、（レジスタ状態などの内部リソースを読み出すために処理回路によって実行されるべきデバッグ命令を注入すること、又は外部デバッガから処理回路の内部リソースに直接アクセスすることのいずれかによって）外部デバッガが処理回路の動作を検査することができる、デバッグ状態に切り替えることをトリガするデバッグ・イベント、或いは、エラー、障害又は外部イベントが生じたことを示す例外イベントであり得る。いくつかのそのようなイベントは、できるだけ早くイベントに応答することが重要であり得るという点で、パフォーマンス・クリティカルであり得る。イベントのハンドリングに続いて、次いで、イベントからの復帰要求（例えば、例外復帰又はデバッグ状態からの復帰）が、イベントが生じる前に実施されていた処理への復帰をトリガし得る。

本出願で説明される処理回路は、処理のいくつかのビートを実施することによってベクトル命令を処理するように構成され、各ビートは、ベクトル値の一部分に対応する処理を含む。処理回路は、２つ又はそれ以上のベクトル命令のグループのどのビートが完了したかを示すビート・ステータス情報を設定するように構成される。所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、処理回路は、どのビートがすでに完了したかを決定するためにビート・ステータス情報を使用し、すでに完了したものとしてビート・ステータス情報によって示された２つ又はそれ以上の命令のグループのビートを抑制する。所与のベクトル命令の所与のビートは、例えば、そのビートに関連する処理演算をまったく実施しないことによって、或いは、レジスタ又は他の記憶ロケーションへのその処理演算の結果の書込みをマスキングすることによって、抑制され得る。

この配置は、ベクトル命令をサポートする処理アーキテクチャが、異なる性能及びエネルギー・ポイントに対してより効率的にスケーリングすることを可能にする。２つ又はそれ以上のベクトル命令の完了したビートを追跡するビート・ステータス情報を提供することによって、これは、特定のマイクロアーキテクチャ実装形態が、異なるベクトル命令の実行が重複される量を変化させる自由を与え、したがって、各部分的に実行された命令の進行を依然として追跡しながら、異なるベクトル命令のそれぞれのビートを互いに並行して実施することが可能である。いくつかのマイクロアーキテクチャ実装形態は、それぞれのベクトル命令の実行をまったく重複させないことを選定し得、したがって、１つのベクトル命令のすべてのビートが、次の命令が開始する前に完了される。他のマイクロアーキテクチャは、連続するベクトル命令の実行を、第２のベクトル命令のビートの第１のサブセットが第１のベクトル命令からのビートの第２のサブセットと並行して実施されるように、スタッガし得る。

所与のハードウェア実装形態がベクトル命令の実行を実装することを選定する特定のやり方にかかわらず、ビート・ステータス情報を定義することによって、ビート・ステータス情報は、部分的に完了した命令が、イベントのハンドリングの後に再開することを可能にするので、スレッドを中断する前に、所与のベクトル命令が、すべてのそれのビートを完了するのを待つ必要がないので、命令実行のスレッドを中断するイベントにより迅速に応答することが可能である。この挙動はまた、アーキテクチャ上、命令がそれの実行を完了することができない、厳密な障害である例外をハンドリングするために重要であり得る。しばしば、例外応答レイテンシは、例外に続いて処理を再開するときにレイテンシを低減することよりも重要であり得、その場合、この手法は、例外ハンドリングのための利点をも提供し得る。

対照的に、単一の命令の進行に関する情報をただ記録するか、又は、命令のグループのビートの特定の組合せが、実行のスレッドの中断のポイントにおいて完了したことを仮定する手法は、マイクロアーキテクチャ・ハードウェア設計者が、異なるベクトル命令の重複の量をスケーリングするためのフレキシビリティをあまり与えないであろう。別の代替手法は、部分的に実行された命令の完了したビートの結果を、命令全体が完了するまで、コミットされない投機的状態（ｓｐｅｃｕｌａｔｉｖｅ ｓｔａｔｅ）として記憶することであろうが、これは、低電力実装形態のために望ましくないであろう追加の記憶及び制御オーバーヘッドを必要とするであろう。複数のベクトル命令のうちのどの特定のビートが完了したかを示すビート・ステータス情報を提供することと、適切なポイントにおいて処理を再開するためにこれを使用することとによって、命令セット・アーキテクチャは、投機的状態を管理する必要なしに、様々な異なるマイクロアーキテクチャにわたって性能及びエネルギー効率を改善するのを助けるために、はるかにフレキシブルであり得る。

図１は、ベクトル命令の処理をサポートするデータ処理装置２の実例を概略的に示す。これが、説明を簡単にするための簡略図であり、実際には、装置が、簡潔のために図１に示されていない多くの要素を有し得ることが諒解されよう。装置２は、命令デコーダ６によって復号された命令に応答して、データ処理を行うための処理回路４を備える。プログラム命令が、アーキテクチャによって定義されたやり方で命令を処理するように処理回路４を制御する制御信号を生成するために、メモリ・システム８からフェッチされ、命令デコーダによって復号される。例えば、デコーダ６は、算術演算、ロード／記憶演算、又は論理演算などの演算を実施するために適切なハードウェア・ユニットを処理回路４にアクティブ化させる、制御信号を生成するために、復号された命令のオペコードと、命令の任意の追加の制御フィールドとを解釈し得る。装置は、処理回路４によって処理されるべきデータ値と、処理回路の動作を構成するための制御情報とを記憶するためのレジスタ１０のセットを有する。算術又は論理命令に応答して、処理回路４は、レジスタ１０からオペランドを読み取り、命令の結果をレジスタ１０に書き戻す。ロード／記憶命令に応答して、データ値は、処理回路を介してレジスタ１０とメモリ・システム８との間で転送される。メモリ・システム８は、１つ又は複数のレベルのキャッシュ並びにメイン・メモリを含み得る。

レジスタ１０は、単一のデータ要素を含むスカラー値を記憶するためのいくつかのスカラー・レジスタを備える、スカラー・レジスタ・ファイル１２を含む。命令デコーダ６及び処理回路４によってサポートされるいくつかの命令は、スカラー・レジスタに書き戻されるスカラー結果を生成するためにスカラー・レジスタ１２から読み取られたスカラー・オペランドを処理する、スカラー命令である。

レジスタ１０は、それぞれ、複数のデータ要素を含むベクトル値を記憶するための、いくつかのベクトル・レジスタを含む、ベクトル・レジスタ・ファイル１４をも含む。ベクトル命令に応答して、命令デコーダ６は、スカラー・レジスタ１２に書き込まれるべきスカラー結果又はベクトル・レジスタ１４に書き込まれるべきさらなるベクトル結果のいずれかを生成するために、ベクトル・レジスタ１４のうちの１つから読み取られたベクトル・オペランドのそれぞれの要素に対してベクトル処理のいくつかのレーンを実施するように、処理回路４を制御する。いくつかのベクトル命令は、１つ又は複数のスカラー・オペランドからベクトル結果を生成し得るか、或いは、スカラー・レジスタ・ファイル中のスカラー・オペランドに対する追加のスカラー演算、並びにベクトル・レジスタ・ファイル１４から読み取られたベクトル・オペランドに対するベクトル処理のレーンを実施し得る。したがって、いくつかの命令は、命令の１つ又は複数のソース・レジスタ及び宛先レジスタのうちの少なくとも１つがベクトル・レジスタ１４であり、１つ又は複数のソース・レジスタ及び宛先レジスタのうちの別のものがスカラー・レジスタ１２である、混合スカラー・ベクトル命令であり得る。ベクトル命令は、データ値がベクトル・レジスタ１４とメモリ・システム８中のロケーションの間で転送されることを引き起こすベクトル・ロード／記憶命令をも含み得る。ロード／記憶命令は、メモリ中のロケーションがアドレスの連続範囲に対応する、連続ベクトル・ロード／記憶命令、或いは、いくつかの個別のアドレスを指定し、それらのアドレスの各々からのデータをベクトル・レジスタのそれぞれの要素にロードするか、又はベクトル・レジスタのそれぞれの要素からのデータを個別のアドレスに記憶するように、処理回路４を制御する、分散／集約（ｓｃａｔｔｅｒ／ｇａｔｈｅｒ）タイプ・ベクトル・ロード／記憶命令を含み得る。

処理回路４は、様々な異なるデータ要素サイズをもつベクトルの処理をサポートし得る。例えば、１２８ビット・ベクトル・レジスタ１４は、例えば、１６個の８ビットデータ要素、８つの１６ビットデータ要素、４つの３２ビットデータ要素、又は２つの６４ビットデータ要素に区分され得る。レジスタ・バンク１０内の制御レジスタが、使用されている現在のデータ要素サイズを指定し得るか、又は代替的に、これは、実行されるべき所与のベクトル命令のパラメータであり得る。

レジスタ１０は、処理回路４の処理を制御するためのいくつかの制御レジスタをも含む。例えば、これらは、処理されている現在の実行ポイントに対応する命令のアドレスを示すプログラム・カウンタ・アドレスを記憶するためのプログラム・カウンタ・レジスタ１６と、関数呼出しのハンドリングに続いて処理がそれにダイレクトされるべきである、復帰アドレスを記憶するためのリンク・レジスタ１８と、スタック・データ構造のメモリ・システム８内のロケーションを示すスタック・ポインタ・レジスタ２０と、以下でより詳細に説明されるビート・ステータス情報を記憶するためのビート・ステータス・レジスタ２２とを含み得る。これらは、記憶され得る制御情報のタイプのうちのほんの一部であり、実際には、アーキテクチャの所与の命令セットは、アーキテクチャによって定義される多くの他の制御パラメータを記憶し得ることが諒解されよう。例えば、制御レジスタは、ベクトル・レジスタの全体幅、又はベクトル処理の所与のインスタンスのために使用されている現在のデータ要素サイズを指定し得る。

処理回路４は、命令の異なるクラスを処理するためのいくつかの別個のハードウェア・ブロックを含み得る。例えば、図１３に示されているように、メモリ・システム８と対話するロード／記憶命令が、専用ロード／記憶ユニット２００によって処理され得、算術又は論理命令が、算術論理ユニット（ＡＬＵ）２０２、２０４によって処理され得る。ＡＬＵ自体は、さらに、乗算に関与する演算において実施するための乗算累算ユニット（ＭＡＣ）２０２と、他の種類のＡＬＵ演算を処理するためのさらなるユニット２０４とに区分され得る。また、浮動小数点命令をハンドリングするために浮動小数点ユニット２０６が与えられ得る。また、ベクトル処理に関与しない純粋な（ｐｕｒｅ）スカラー命令が、ベクトル命令と比較して別個のハードウェア・ブロックによってハンドリングされるか、又は同じハードウェア・ブロックを再利用し得る。

デジタル信号処理（ＤＳＰ）などのいくつかの適用例では、ほぼ等しい数のＡＬＵ及びロード／記憶命令があり得、したがって、ＭＡＣなどのいくつかの大きいブロックが、かなりの量の時間の間、アイドルのままにされ得る。この非効率性は、実行リソースが、より高い性能を獲得するためにベクトル・レーンの数を用いてスケーリングされるとき、ベクトル・アーキテクチャ上で悪化させられ得る。より小さいプロセッサ（例えば、単一発行、インオーダー・コア）上では、十分にスケーリング・アウトされたベクトル・パイプラインの面積オーバーヘッドが、法外に高くなり得る。利用可能な実行リソースのより良好な使用を行いながら、面積影響を最小限に抑えるための１つの手法は、図２に示されているように、命令の実行を重複させることである。この実例では、３つのベクトル命令が、ロード命令ＶＬＤＲと、乗算命令ＶＭＵＬと、シフト命令ＶＳＨＲとを含み、すべてのこれらの命令は、それらの間にデータ依存性があるとしても、同時に実行していることがある。これは、ＶＭＵＬの要素１が、Ｑ１の要素１のみに依存し、Ｑ１レジスタの全体に依存せず、そのため、ＶＬＤＲの実行が終了する前に、ＶＭＵＬの実行が開始することができるからである。命令が重複することを可能にすることによって、乗算器のような費用がかかるブロックが、より多くの時間、アクティブに保たれ得る。

したがって、マイクロアーキテクチャ実装形態がベクトル命令の実行を重複させることを可能にすることが望ましいことがある。しかしながら、アーキテクチャが、一定量の命令重複があることを仮定した場合、これは、マイクロアーキテクチャ実装形態が、アーキテクチャによって仮定された命令重複の量に実際に一致する場合、高効率を与え得るが、それは、異なる重複を使用するか又はまったく重複しない異なるマイクロアーキテクチャにスケーリングされる場合、問題を生じることがある。

代わりに、アーキテクチャが、図３の実例に示されているように様々な異なる重複をサポートし得る。ベクトル命令の実行は、「ビート」と呼ばれる部分に分割され、各ビートは、所定のサイズのベクトルの一部分の処理に対応する。ビートは、完全に実行されるか又はまったく実行されないかのいずれかである、ベクトル命令のアトミック部分であり、部分的に実行され得ない。１つのビートにおいて処理されるベクトルの一部分のサイズは、アーキテクチャによって定義され、ベクトルの任意の部分であり得る。図３の実例では、ビートは、ベクトル命令ごとに４つのビートがあるように、ベクトル幅の１／４に対応する処理として定義される。明らかに、これは１つの実例にすぎず、他のアーキテクチャは、異なる数のビート、例えば、２つ又は８つを使用し得る。１つのビートに対応するベクトルの一部分は、処理されているベクトルのデータ要素サイズと同じサイズであるか、それよりも大きいか又は小さくなり得る。したがって、要素サイズが、実装形態ごとに変化するか又はランタイムにおいて異なる命令間で変化する場合でも、ビートは、ベクトル処理のある固定幅である。１つのビートにおいて処理されているベクトルの一部分が、複数のデータ要素を含む場合、桁上げ信号（ｃａｒｒｙ ｓｉｇｎａｌ）は、各要素が独立して処理されることを保証するために、それぞれの要素の間の境界において無効にされ得る。１つのビートにおいて処理されるベクトルの一部分が、要素の一部だけに対応し、ハードウェアが、いくつかのビートを並行して計算するには不十分である場合、処理の１つのビート中に生成された桁上げ出力は、２つのビートの結果が一緒にデータ要素を形成するように、処理の後続するビートに桁上げ入力として入力され得る。

図３に示されているように、処理回路４の異なるマイクロアーキテクチャ実装形態は、抽象アーキテクチャ・クロックの１つの「ティック（ｔｉｃｋ）」において異なる数のビートを実行し得る。ここで、「ティック」は、アーキテクチャ状態前進（ａｄｖａｎｃｅｍｅｎｔ）のユニットに対応する（例えば、単純なアーキテクチャ上では、各ティックは、次の命令をポイントするためにプログラム・カウンタを更新することを含む、命令を実行することに関連するすべてのアーキテクチャ状態を更新するインスタンスに対応し得る）。パイプライン化などの知られているマイクロアーキテクチャ技法は、単一のティックが、ハードウェア・レベルにおいて実施するために複数のクロック・サイクルを必要とし得ることと、実際、ハードウェア・レベルにおける単一のクロック・サイクルが、複数の命令の複数の部分を処理し得ることとを意味し得ることが、当業者によって諒解されよう。しかしながら、そのようなマイクロアーキテクチャ技法は、ティックがアーキテクチャ・レベルにおいてアトミックであるとき、ソフトウェアに対して可視でない。簡潔のために、そのようなマイクロアーキテクチャは、本開示のさらなる説明中に無視される。

図３の下部の実例に示されているように、いくつかの実装形態は、すべてのビートを１つのティック内で並行して処理するために十分なハードウェア・リソースを与えることによって、同じティック中にベクトル命令のすべての４つのビートをスケジュールし得る。これは、より高性能の実装形態に好適であり得る。この場合、命令全体が１つのティックにおいて完了され得るので、アーキテクチャ・レベルにおける命令間の重複の必要はない。

一方、より面積効率的な実装形態は、ティックごとに２つのビートのみを処理することができる、より狭い処理ユニットを与え得、図３の中間の実例に示されているように、命令実行が重複され得、第２のベクトル命令の第１及び第２のビートが、第１の命令の第３又は第４のビートと並行して行われ、ここで、それらの命令は、処理回路内の異なる実行ユニット上で実行される（例えば、図３では、第１の命令は、ロード／記憶ユニット２００を使用して実行されるロード命令であり、第２の命令は、ＭＡＣ２０２を使用して実行される乗算累算命令である）。

またよりエネルギー／面積効率的な実装形態が、より狭く、一度に単一のビートのみを処理することができるハードウェア・ユニットを与え得、この場合、ティックごとに１つのビートが処理され、命令実行は、図３の上部の実例に示されているように、１つのビートだけ重複及びスタッガされ得る（これは、上記の図２に示された実例と同じである）。

図３に示されている重複はいくつかの実例にすぎず、他の実装形態も可能であることが諒解されよう。例えば、処理回路４のいくつかの実装形態は、同じティックにおける並行した複数の命令のデュアル発行をサポートし得、したがって、命令のより大きいスループットがある。この場合、１つのサイクルにおいて一緒に開始する２つ又はそれ以上のベクトル命令は、次のサイクルにおいて開始する２つ又はそれ以上のベクトル命令と重複するいくつかのビートを有し得る。

異なる性能ポイントにスケーリングするために、実装形態ごとに重複の量を変化させることと同様に、ベクトル命令間の重複の量は、ランタイムにおけるプログラム内のベクトル命令の実行の異なるインスタンス間でも変わることができる。したがって、処理回路４は、所与の命令が前の命令に対して実行されるタイミングを制御するために、図１に示されているように、ビート制御回路３０を与えられ得る。これは、命令にとって利用可能なリソースを実装すること又はそれらに依存することがより困難であるいくつかのコーナーケースでは、命令を重複させないことを選択する自由をマイクロアーキテクチャに与える。例えば、同じリソースを必要とする所与のタイプ（例えば、乗算累算）の命令が、相次いであり、すべての利用可能なＭＡＣ又はＡＬＵリソースが、別の命令によってすでに使用されている場合、次の命令を実行することを開始するための十分な空いているリソースがないことがあり、したがって、重複することよりむしろ、第２の命令の発行は、第１の命令が完了するまで待機することがある。

図４に示されているように、介在するスカラー命令がある場合も、２つのベクトル命令間の重複が防がれ得る。これは、スカラー命令は、ベクトル命令の最後のビートの成果（ｏｕｔｃｏｍｅ）に依存し得、第２のベクトル命令は、それのビートのすべてにおいてスカラー結果に依存し、したがって、ベクトル命令をスカラー命令と重複させることを回避することが、より安全であり得るからである。

上記で説明されたように重複が許可されるとき、同時に実行する複数の命令があり得る。プログラム・カウンタ１６は、依然として完了されるべき少なくとも１つのビートを有する最も古い、完了していない命令のアドレスを追跡し得る。プログラム・カウンタは、ベクトル命令がそれの最終ビートを完了するとき、増分され得る。

実行ベクトル命令の様々な異なる重複を許可することは、様々な性能ポイントにわたってハードウェア・リソースのより効率的な使用を可能にすることができるが、それは、例外又はデバッグ・イベント又は実行の現在のスレッドの中断をトリガする他のイベントのハンドリングのためのいくらかの複雑性を生じることがある。例えば、図２に示されている実例では、例外が第４のティック上で起きた場合、レジスタ・ファイルは、いくつかの命令からの部分的更新を含んでいるであろう。これをハンドリングする１つのやり方は、例外が生じた場合に戻され得る、投機的状態として部分的更新を扱うことであろうが、これは、データをメモリ・システム８に記憶するための記憶要求を、それらがコミットされるまでバッファすることと、投機的状態を追跡するためのハードウェアにおける追加のレジスタを与えることとが必要であり得るので、必要とされるハードウェアの量を増加させることがある。別の手法は、ベクトル命令の途中で例外がとられることを少しでも無効化することと、最も古い、完了していない命令が完了するまで、例外をとることを遅延させることとであろうが、例外ハンドリング・レイテンシを増加させることは、望ましくないことがあり、例外が厳密な障害である場合、そのような挙動は、障害に関連するアーキテクチャ保証を破損し得る。

代わりに、図５に示されているように、例外、デバッグ・イベント又は現在のスレッドの中断につながる他のイベントのポイントにおいて、隣接する命令のグループのどのビートが完了したかを追跡する、ビート・ステータス値を記録するために、ビート状態レジスタ２２が使用され得る。実行の重複する性質をアーキテクチャに露出することによって、これは、マイクロアーキテクチャ複雑性を低減し、電力及び面積効率を増加するのを助け得る。

図５の実例では、ビート・ステータス情報は、３つのベクトル命令Ａ、Ｂ、Ｃのグループの完了したビートを追跡し、ここで、命令Ａは、最も古い、完了していないベクトル命令に対応し、命令Ｂは、命令Ａの後の次のベクトル命令であり、命令Ｃは、命令Ｂの後の次のベクトル命令である。表記法Ａｘは、命令Ａの第ｘのビートを指し、ここで、４ビート・ベクトル実装形態の場合、ｘは１から４の間にあり、例えば、Ａ２は、命令Ａの第２のビートである。図５は、３つの命令が、ビート・ステータス情報を使用して追跡される実例を示すが、より大きい数の命令が、所与のポイントにおいて部分的に完了することを許可する他の実例では、ビート・ステータス情報は、より大きい数の命令を追跡することができる。例えば、デュアル発行がサポートされる場合、４つ以上の命令についてのビート進行を示すことが望ましいことがある。ビート・ステータス・フィールドの各値が、完了したビートの所与の組合せに割り振られる。例えば、ビート・ステータス値００１１は、命令Ａの第１及び第２のビート並びに命令Ｂの第１のビートが完了したことを示す。命令のそれぞれのグループのビートの特定のセットに対する、ビート・ステータス情報の特定の符号化された値の特定のマッピングは、任意であり、変化され得る。この実例でのビート・ステータス値００００は、未完了の命令がないこと、したがって、未完了の命令の完了したビートがないことを示す。これは、例えば、プロセッサがスカラー命令を実行したときに生じ得る。

図６は、実行の現在のスレッドの中断があるとき、ポイントにおいて記録されたビート・ステータス情報のいくつかの実例を示す。図６の上部の実例では、ベクトル命令が、ティックごとに１つのビートを用いて実行され、第４のティック上でデバッグ・イベント又は例外が生じる。したがって、このポイントにおいて、命令Ａの最初の３つのビート、命令Ｂの最初の２つのビート、及び命令Ｃの最初のビートは、すでに完了しているが、ビートＡ４、Ｂ３、Ｃ２、Ｄ１は依然として実施されていない。したがって、ビート・ステータス情報は、図５の実例によれば、ビートＡ１、Ａ２、Ａ３、Ｂ１、Ｂ２及びＣ１がすでに完了したことを示す、値０１１１を有するであろう。

同様に、図６の実例の下部では、実行されている命令は、（例えば、命令Ｂ及びＣが同じハードウェア・ユニットの使用を必要としたので）命令Ｂと命令Ｃが重複し得ないようなものであり、したがって、このとき、命令Ｃと命令Ｄは、デバッグ・イベント又は例外のとき、まだ開始していなかった。このとき、例外がティック４上に生じることは、ビートＡ１、Ａ２、Ａ３、Ｂ１及びＢ２がすでに完了したが、Ｃ１が完了していないことを示す、ビート・ステータス情報０１１０の記録をトリガする。

同様に、図３のティックごとに２つのビート実例では、例外がティック２上で生じる場合、ビートＡ１及びＡ２のみが完了し、ビート・ステータス値は００１０になるであろう。ビート・ステータス情報の値０００１及び００１０は、１つの命令Ａのみが、例外のときにおいて部分的に完了していたことを示すが、ビート・ステータス情報は、それが、次の２つの命令Ｂ、Ｃのビートのいずれも完了していないことを識別するので、複数の命令のグループのどのビートが完了したかを依然として示すことに留意されたい。

図３のティックごとに４つのビート実例では、各命令が１つのティック内で完了するので、例外のときに、部分的に完了した命令がないことになるので、ビート・ステータス値は、例外がいつ生じるかにかかわらず、００００であろう。

デバッグ・イベント又は例外が生じるとき、復帰アドレスは、プログラム・カウンタ１６の現在値に設定され、それは、最も古い、完了していない命令のアドレスを表す。したがって、図６の両方の実例では、復帰アドレスは、命令Ａのアドレスに設定されるであろう。復帰アドレスは、スタック・ポインタ・レジスタの値に対するスタック上のロケーションにおいて、又は復帰アドレス・レジスタにおいてを含む、様々な場所に記憶され得る。

図７に示されているように、これは、プロセッサが、（例えば、デバッグ・モード又は例外ハンドラからの復帰における）イベントからの復帰要求に応答して、ビート・ステータス・レジスタ２２中の復帰アドレス及びビート・ステータス情報に基づいて決定されたポイントから、処理を再開することを可能にする。イベントからの復帰要求は、デバッグ・イベントの場合、デバッガによって行われ、又は例外イベントの場合、例外ハンドラによって行われ得る。イベントからの復帰要求に続いて、処理されるべき命令のフェッチングが、この場合には命令Ａに対応する、復帰アドレスによって示されたアドレスから再開する。命令Ｂ、Ｃ及びＤが後続する（この実例は、図６の上部の実例に対応する）。しかしながら、復帰後の最初の数個のサイクルの間、すでに完了したものとしてビート・ステータス情報によって示されたビートは、抑制される。プロセッサは、対応する処理演算が実施されることを少しでも防ぐこと（例えば、データをロード又は記憶したいという要求を抑制すること、或いはＡＬＵ又はＭＡＣの無効化）によって、これらのビートを抑制し得る。代替的に、演算は、ＡＬＵ演算の場合、依然として実施され得るが、プロセッサは、演算の結果の書込みを、それが、レジスタ状態に影響を及ぼさないように、抑制し得る（すなわち、宛先ベクトル・レジスタの一部分の更新を抑制する）。所与のビートを抑制する別のやり方は、所与のビートに対応する宛先ベクトル・レジスタの一部分を所定の値（例えば０）に設定することであろう。第４のティックに達すると、次いで、パイプラインが、デバッグ・イベント又は例外が前に生じたポイントに達し、次いで、処理が通常通り継続する。したがって、例外復帰の後の最初の数個のサイクルの間、プロセッサは、有用な作業を実施することはなく、元の例外又はデバッグ・イベントが生じたときに伝送中にあった複数の命令を本質的にただ再フェッチしている。しかしながら、例外復帰レイテンシは、しばしば、いくつかの適用例では重要でないので、これは、例外をとる時間におけるレイテンシを低減するための良好なトレード・オフであり得、またこれは、完了していない命令の結果を投機的に記憶することが必要でないので、例外において記憶される必要があるアーキテクチャ状態の量を低減するのを助ける。この手法はまた、ベクトル命令のビートによって起きた厳密な障害である、例外のハンドリングを可能にする。

いくつかの場合には、複数の命令のグループの完了したビートを示すビート・ステータス情報は、デバッグ・イベント又は例外が生じることに応答して設定され得る。しかしながら、いくつかの実装形態では、後続のティックにおいて例外が生じた場合、ビート状態レジスタ２２がすでに、命令のグループのすでに完了したビートを示しているように、例外が生じたかどうかにかかわらず、命令が完了するたびにビート状態レジスタを更新することが、より容易であり得る。したがって、図８は、ベクトル命令が完了したときに状態を更新する方法を示す流れ図である。ステップ５０において、所与のベクトル命令の最終ビートが完了する。応答して、ステップ５２において、プログラム・カウンタ１６を、次の完了していない命令を示す値に更新する。ステップ５４において、伝送中の完了していない命令のどのビートがすでに完了したかを示すために、ビート・ステータス情報を更新する。例えば、ビート制御回路３０は、それが一連のベクトル命令の実行をスケジュールするタイミングに基づいて、ビート状態レジスタ２２を設定し得る。

図５は、ビート・ステータス情報の１つの例示的な符号化を示すが、別の可能性は、命令Ａ、Ｂ、Ｃなどのグループのうちの１つの１つのビートにそれぞれ対応する、いくつかのビットを含むビット・マップとして、ビート・ステータス情報を提供することであり、各ビットは、対応するビートが完了した場合、１に設定され、対応するビートが完了していない場合、０に設定される（又は、その逆も同様である）。しかしながら、実際には、所与の命令の、前のビートがまだ完了していない場合、後のビートは完了し得ないので、あらゆるビートにビットを与えることは必要とされず、図５の実例の場合のように、より小さいビット・フィールドのいくつかの符号化を、完了したビートの特定の組合せに割り振ることが、より効率的であり得る。

図９は、例外イベントに応答することの実例を示す流れ図を示す。ステップ１００において、例外イベントが検出される。応答して、ステップ１０２において、処理回路内の例外制御回路が、スタック・ポインタ・レジスタ２０に記憶されたスタック・ポインタに対するオフセットにおけるメモリ中のロケーションへのレジスタ状態（スカラー・レジスタ１２及びベクトル・レジスタ１４、並びにビート・ステータス・レジスタ２２の現在のコンテンツを含む）の保存をトリガする。レジスタ値を記憶するメモリ・ロケーションのグループは、例外スタック・フレームと総称される。スタック・ポインタは、例外に応答して呼び出された例外ハンドラが、中断されている、実行されているスレッドの前の状態を失うことなしに、データをレジスタに上書きすることができるように、レジスタ状態を一時的に記憶するためのメモリにおいて与えられるスタック・データ構造の（実装形態選定によって異なる）上部又は下部を表す。いくつかの実例では、例外に遭遇すると、すべてのレジスタ１２、１４が、それらの状態をスタックに保存され得るとは限らない。レジスタ・ファイルを、例外ハンドリング・ハードウェアによって、又は例外が起きる前にソフトウェア・スレッドが実行されることによって、自動的に保存される、「呼出し側（ｃａｌｌｅｒ）」状態と、それらが例外ハンドラによって上書きされようとしている場合、これらのレジスタをスタックに保存することが、例外ハンドラの責任である、「被呼出し側（ｃｏｌｌｅｅ）」状態とに分割することが可能である。この手法は、それらが再利用される前にいくつかのレジスタの値を維持するための機能をしばしば必要とする、ソフトウェア呼出し規則とのより良い整合を提供し得る。したがって、これらのレジスタをハードウェア例外エントリ処理の一部として保存しないことが、レジスタの冗長ダブル保存を防ぐ。

ステップ１０４において、例外スタック・フレーム中の復帰アドレス・ロケーションが、最も古い、完了していない命令のアドレスに設定される。これは、前の処理を再開するために、処理が例外ハンドラの完了に続いてそれに分岐することができる、復帰アドレスを与える。随意に、ステップ１０６において、スカラー・レジスタ１２又はベクトル・レジスタ１４、及び／又はビート・ステータス・レジスタ２２のうちの少なくともいくつかにおけるレジスタ状態が、それらのコンテンツが例外ハンドラに対して可視でないように、クリアされ得る。これは、いくつかのセキュアな適用例では、レジスタ中のセキュアなデータを保護するために望ましく、又は、前に実行していたスレッドの進行の可視性を例外ハンドラに与えることが望ましくない場合、望ましいことがある。一方、セキュリティは問題でなく、前に実行していた状態の可視性を例外ハンドラに与えることが許容できる場合、ステップ１０６は省略され得る。

ステップ１０８において、例外ハンドリング・ハードウェアは、生じた例外が障害イベントであるかどうかを検出する。例外イベントは、障害イベント及び非障害イベントを含み得る。障害イベントは、処理回路４によって実行される特定の命令によって引き起こされたエラーによってトリガされ得る。例えば、未定義命令を実行しようとする試みがある場合、或いは、現在実行中のプロセスがターゲット・アドレスにアクセスするための許可を有しないか、又は仮想物理間アドレス変換がターゲット・アドレスについてまだ定義されていないので、ロード／記憶命令がメモリ障害をトリガする場合、障害がトリガされ得る。一方、他のタイプの非障害例外は、特定の命令に関連しないことがあるが、外部イベント（例えば、ユーザがデバイス上のボタンを押すこと、或いは信号が外部デバイス又は周辺機器から受信されること）、又はプログラムが実行されることによって引き起こされないいくつかの他のイベント（例えば、アラーム又はリマインダをトリガするためのカウント・ダウン・タイマーの満了）によって、トリガされ得る。現在の例外イベントが障害イベントである場合、ステップ１１０において、プロセッサは、どの完了していない命令が障害をトリガしたかを識別するいくらかの情報を記録し得る。上記で説明された重複する実行により、複数の命令が伝送中にあり得るので、ステップ１０４において設定された復帰アドレスは、単独で、どの特定の命令が障害をトリガしたか、したがって、障害がどのようにハンドリングされ得るかを識別するために十分でないことがあり、したがって、障害を起こしている命令の指示を記録することは、いくつかの障害状態が正確にハンドリングされるのを助けることができる（例えば、複数のロード／記憶命令が伝送中にある場合、メモリ障害は、例えば、必要とされるアドレスについての変換データにおけるページングによって、障害がアドレス指定されることを可能にするための特定の命令に起因することがある）。一方、例外が障害イベントでない場合、例外は、どの特定の命令が例外をトリガしたかを知ることなしに、ハンドリングされ得るので、ステップ１１０は省略される。例外イベントのタイプにかかわらず、ステップ１１２において、プロセッサは、検出された例外イベントのタイプに対応する例外ハンドラへの分岐をトリガする。例えば、プロセッサは、検出された例外のタイプの識別子に基づいてインデックス付けされる例外ベクトル・テーブルを参照し得、テーブルは、対応する例外ハンドラのアドレスを与え得る。

図１０は、例外のハンドリングから復帰するときに実施される動作を示す、流れ図を示す。例外ハンドラは、一般に、処理が、例外によって中断された前のスレッドに復帰すべきであることを示す、例外復帰命令で終了し得、代替として、例外ハンドラからの復帰は、プロセッサが例外復帰要求として検出する、特殊な予約済みアドレスに分岐することによって実施され得る。したがって、復帰命令は、イベントからの復帰要求をトリガし得る。そのような例外復帰が、ステップ１２０において検出されたとき、ステップ１２２において、前にスタックに保存されたレジスタ状態、及びビート・ステータス情報が、スタック・ポインタ・レジスタ２０において示されたスタック・ロケーションから復元され、レジスタ・ファイル１０に書き込まれる。ステップ１２４において、処理回路４は、例外スタック・フレームにおける復帰アドレス・ロケーションによってそれらのアドレスが指定される命令から開始する、命令のフェッチングを再開する。上記で説明されたように、これは、例外が生じたときに、最も古い、完了していない命令のアドレスである。ステップ１２６において、プロセッサは、すでに完了したものとしてビート・ステータス情報によって示された命令のビートの効果を抑制するために、ビート・ステータス情報を使用する。いくつかの命令は、すでに完了したビートが繰り返される場合、同じ結果を単に再び生成し得、他のタイプの命令は、所与のビートが２回実施される場合、異なる結果を生成し得る。例えば、所与のメモリ・ロケーションにおける値をアトミックに増分するためのアトミック・メモリ更新命令は、例外がハンドリングされる前に一度、及び例外に続いて処理を再開した後に再び、それが行われた場合、間違った結果につながり得る（１ではなく２の増分につながる）。したがって、ビート・ステータス情報に基づいて、命令のすでに完了したビートを抑制することによって、正しい処理が保証され得る。一方、実際のハードウェア実装形態が、連続するベクトル命令の処理をハンドリングする特定のやり方にかかわらず、ビート・ステータス情報が、複数の命令のグループのための完了したビートの異なるパターンを示すためのフレキシビリティを与えることによって、これは、アーキテクチャが、より効率的に、異なる性能ポイントにスケーリングすることを可能にする。

図９及び図１０は、例外をとること及び例外から再開することをハンドリングするためにビート・ステータス情報を使用する実例を示すが、ビート・ステータス情報は、実行のスレッドの中断をトリガする任意の他のイベントのためにも使用され得る。例えば、外部デバッガから注入されたデバッグ命令が実行されるデバッグ・モードへの切替えをトリガするデバッグ・イベントに関して、ビート・ステータス情報は、処理が、デバッグ・モードから出ることに続いて、複数の命令の正しいビートから再開することを可能にするために、使用され得る。同様に、ビート・ステータス情報は、実行のスレッドの中断をトリガする他の種類のイベントについても、同様のやり方で使用され得る。

上記の実例では、例外に遭遇すると例外スタック・フレームに記憶される復帰アドレスは、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令のアドレスとして設定されるが、これは必須でない。復帰アドレスは、処理が再開されるべきであるポイントが、識別されることを可能にするアドレスであり得る。いくつかの場合には、処理が再開されるべきポイントは、復帰アドレスとビート・ステータス情報の両方から導出され得る。例えば、復帰アドレスが、少なくとも１つのビートが開始した、最も若いベクトル命令を示すことが可能であり得、それは、どの先行する命令が部分的にのみ完了したかを示すビート・ステータス情報とともに、例外又は他のイベントのハンドリングに続いて、それらの命令が再フェッチされることを可能にするために十分であり得る。しかしながら、この手法は、部分的に完了した命令のグループ内に分岐があるとき、より複雑になり得る。最も古い、完了していない命令のアドレスを復帰アドレスとして使用することは、分岐にわたって前に実行された命令のアドレスを識別することを試みるためにコードを通して、ステップ・バックする必要がないので、分岐を含む命令のグループのハンドリングを簡略化する。

概して、上記で説明されたビート・ステータス情報は、複数のベクトル命令についてどのビートが完了したかを示す。複数のベクトル命令は、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令と、少なくとも１つの後続のベクトル命令とを含み得る。例えば、介在するスカラー命令があり得るので、後続のベクトル命令は、最も古いベクトル命令と連続する必要はない。いくつかの場合には、ベクトル命令がそれにおいて実行されたことがあり得るいくつかの実行スロットは、実行されるべき十分な命令がなかったので、空であり得、したがって、この場合、ビート・ステータス情報は、対応するビートを、完了しなかったものとして示すことになる。

この手法は、様々なハードウェア実装形態にわたってスケーリングを可能にする。いくつかの場合には、処理回路は、所与のベクトル命令のすべてのビートを並行して実施するために不十分であるハードウェアを備え得る。したがって、処理回路は、第１のサブセットを完了した後に、所与のベクトル命令のビートの第２のサブセットを実施し得る。第１及び第２のサブセットは、プロセッサ実装形態に応じて、単一のビートを含み得るか又は複数のビートを含み得る。

ハードウェア・ユニットの利用を増加させるために、第２のベクトル命令のためのビートの第１のサブセットを実施することと並行して、第１のベクトル命令のためのビートの第２のサブセットを実施することが可能である。これは、第１のベクトル命令と第２のベクトル命令とが、異なるハードウェア・ユニットを使用して実施されるべきであるとき、特に有用である。後続のベクトル命令の第１のビートを開始する前に、１つのベクトル命令のいくつのビートが完了されるべきかを、命令ごとに変化させるために、制御回路が与えられ得る。ランタイムにおいてスケジューリングを変化させることは、プロセッサが、最も適切なスケジューリングを選定するために、実行命令の所与のインスタンスにおいて利用可能なリソースに応答することを可能にする。

代替的に、他の実装形態は、所与のベクトル命令のすべてのビートを並行して実施するのをサポートするハードウェアを備え得る。例外がとられるか又はデバッグ・モードに入ったポイントにおいて、命令が完全に完了されることになるようなハードウェアの場合、例外ハンドリング及びデバッギングは、より単純であるが、それにもかかわらず、そのようなハードウェアをもつ処理回路は、依然として、上記で指定されたようなビート・ステータス情報を生成及び使用することができるが、ビート・ステータス情報は、通常、処理が中断されたポイントにおいて、最も古い、未完了の命令のための完了したビートがないことを示すことになる（図５における「非アクティブ」ケース）。したがって、ビート・ステータス情報を定義することによって、アーキテクチャは、様々な異なる実装形態をサポートすることができる。

いくつかのシステムでは、ビート・ステータス情報は、処理をどのように再開すべきかを決定するためにプロセッサによって使用される内部状態であり得、ユーザ又はプロセッサ上で実行しているソフトウェアにとってアクセス可能にされないことがある。

しかしながら、他の実例では、ビート・ステータス情報は、処理回路、例外ハンドラ及びデバッガによって実行されているソフトウェアのうちの少なくとも１つに完全に可視であり、公開され得る。

随意に、処理回路は、ビート・ステータス情報を、スタック・ポインタ・レジスタによって示されたデータ・ストア中のロケーションに保存し、必要な場合、例外ハンドラからビート・ステータス情報を隠すために、例外イベントに応答するとビート・ステータス情報をクリアするように構成され得る。特に、セキュア状態とあまりセキュアでない状態とを少なくとも含む複数のセキュリティ状態をサポートするシステムでは、例外イベントが、セキュア状態からあまりセキュアでない状態への遷移を生じる場合、処理回路は、例外イベントに応答してビート・ステータス情報をクリアし得る。

さらなるオプションは、処理回路が、第１の例外イベントに応答してビート・ステータス情報へのアクセスを無効化し、例外イベントに応答してアクセスを再有効化することであろう。例外ハンドラがビート・ステータス情報にアクセスしようと試みるか、又は処理の複数のビートを含むさらなるベクトル命令が実行される場合、ビート・ステータス情報は、所定のロケーションに緩慢に（ｌａｚｉｌｙ）保存され得る。この情報の緩慢な保存は、処理回路、或いは、ビート・ステータス情報にアクセスすること又はベクトル命令を実行することの第１の例外ハンドラの試みによってトリガされた、ネスト化された第２の例外ハンドラのいずれかによって自動的に実施され得る。より複雑であるにもかかわらず、この緩慢な保存手法は、例外がとられるときに保存されるべき情報の量を低減し、したがって、タイム・クリティカルな例外ハンドラに入るためにかかる時間を低減することができる。

上記で説明されたようにベクトル命令の重複実行をサポートすることは、アーキテクチャが、異なる性能ポイントにおいて様々なハードウェア実装形態上で実行されることを可能にするのを助け得る。しかしながら、それは、スカラー・レジスタ・ファイル１２とベクトル・レジスタ・ファイル１４の両方に関与する混合スカラー・ベクトル命令を実行するとき、いくつかの問題を生じることがある。ベクトル命令は、概して、それらのうちの少なくとも１つがベクトル・レジスタ１４である、１つ又は複数のソース・レジスタ及び宛先レジスタを指定するが、それらのベクトル命令のサブセットは、１つ又は複数のソース・レジスタ及び宛先レジスタのうちの別のものがそれのためのスカラー・レジスタ１２である、混合スカラー・ベクトル命令である。図２及び図３に示されているタイプの重複実行は、依存性が、相互レーン（ｃｒｏｓｓ−ｌａｎｅ）依存性なしに、ベクトル処理の同じレーン内にとどまる傾向があるので、純粋なベクトル命令に概して有効である。それは、依存性によって引き起こされるハザードをもたらすことなしに、異なる命令の異なるビートを並行して実行することが可能であることを意味する。置換命令など、相互レーン動作を必要とするいくつかのタイプのベクトル命令があり得、そのような命令の場合、重複実行が使用されないことがあるが、概して、たいていのベクトル命令は、レーン中にとどまることができ、重複技法を使用することができる。

しかしながら、混合スカラー・ベクトル命令では、しばしば、スカラー値とベクトル処理のレーンの各々との間に依存性がある。例えば、スカラー・レジスタが、混合スカラー・ベクトル命令のソース・レジスタであるとき、ベクトル処理のレーンの各々は、スカラー・レジスタ中の同じスカラー値に依存し得る。このタイプの混合スカラー・ベクトル命令の実例は、ベクトル・レーンの各々におけるロード／記憶動作のために使用されるべきターゲット・アドレスを決定するためのポインタを記憶するためにスカラー・レジスタを使用する、ロード／記憶命令であり得る。一方、スカラー・レジスタが混合スカラー・ベクトル命令の宛先レジスタであるとき、処理回路は、ベクトル処理のレーンの各々の成果に依存する、スカラー・レジスタに記憶されるべきスカラー結果を生成し得る。このタイプの命令の実例は、各レーン中の要素のペアの乗算を実施し、各レーンの乗算の結果をスカラー・アキュムレータ・レジスタに累算する、乗算累算命令であり得る。いくつかの場合には、同じスカラー・レジスタが、混合スカラー・ベクトル命令によってソース・レジスタと宛先レジスタの両方として使用され得る。例えば、ロード／記憶命令は、必要とされるアドレスに対するポインタとしてスカラー・レジスタを使用し得るが、後続のロード／記憶命令が異なるアドレスを使用することを保証するために、所与の増分に基づいてポインタを更新することもある。スカラー・レジスタがソースと宛先の両方であり得る別の実例は、乗算累算命令は、スカラー・レジスタ中の前の値を上書きするのではなく、前の値に加算する。ポインタ更新は、現在のロード命令のためのアドレスが計算される前又は後のいずれかに行われ得る。

図１１及び図１２は、２つの混合スカラー・ベクトル命令が重複を用いて実行されたときに起こることがある、緩和された実行のインスタンスの２つの実例を示す。図１１の実例では、ベクトル・ロード命令（ＶＬＤＲ）の後にベクトル乗算累算（ＶＭＬＡ）命令が続き得る。したがって、この実例では、第１の混合スカラー・ベクトル命令（ＶＬＤＲ）は、スカラー・レジスタＲ０であるソース・レジスタを有し、第２の命令は、同じくスカラー・レジスタである、宛先レジスタＲ０又はＲ３を有する。正しい処理結果のために、第２の命令の結果は、第１の命令のソース・オペランドに影響を及ぼすべきでなく、より若い命令は、より古い命令の入力に影響を及ぼすべきでない。したがって、第２の命令の宛先レジスタが第１の命令の成果に影響を及ぼすべきでないので、特定のスカラー・レジスタが使用されることが考えられる。

しかしながら、図１１に示されているように、（ティックごとに２つのビートをもつこの実例において）２つの命令の実行が重複するとき、ＶＭＬＡ命令は、ＶＬＤＲ命令の最終ビートＡ４が完了する前に、ビートＢ１においてスカラー・レジスタを更新し始める。ＶＭＬＡ命令の宛先スカラー・レジスタＲ３が、図１１の下部の実例の場合のように、ＶＬＤＲ命令のソース・レジスタＲ０とは異なる場合、ＶＭＬＡ命令は、ロードの成果に影響を及ぼさず、ビートＡ４において実施されるロード動作は、乗算累算の結果に依存しない。これは、正しい成果である。しかしながら、ＶＭＬＡ命令が、図１１の上部の実例に示されているように、ＶＬＤＲ命令と同じスカラー・レジスタＲ０を指定する場合、ロードのアドレスは、ＶＭＬＡ命令のビートＢ１において実施される乗算累算動作に依存することになり、したがって、第２の命令は第１の命令の成果に影響を及ぼす。したがって、ＶＬＤＲ命令のビートＡ４は、後続のＶＭＬＡ命令が同じスカラー・レジスタを指定するか否かに応じて、（異なるアドレスからロードする）完全に異なる結果を与えることができる。さらに、ＶＬＤＲ及びＶＭＬＡが重複する量は、処理回路の実装形態及びランタイムにおいて利用可能なリソースなど、いくつかのファクタに依存し得るので、後続のＶＭＬＡによってＶＬＤＲの結果が破損されるかどうかは、コードが書き込まれ又はコンパイルされるときに決定可能でないことがある。そのような不確実性は、望ましくない及び正しくないと見なされるであろう。

一方、図１２の実例では、ＶＭＬＡ命令は、ＶＬＤＲ命令の前に行われる。したがって、このとき、第１の混合スカラー・ベクトル命令は、スカラー・レジスタである宛先レジスタを有し、第２の混合スカラー・ベクトル命令は、スカラー・レジスタであるソース・レジスタを有する。このとき、第２の命令が第１の命令に依存すべきであることが予想されるが、重複実行は、第２の命令の成果を、第１混合スカラー・ベクトル命令と第２の混合スカラー・ベクトル命令の間にいくつの介在する命令が実行されるかに依存させることができる。例えば、図１２の上部の実例では、介在する命令の数は０であり、したがって、ＶＬＤＲの第１のビートＢ１は、ＶＭＬＡの第２のビートＡ２と並行して実施される（この実例は、ティックごとに１つのビートを使用する）。したがって、ＶＭＬＡの第１のビートＡ１のみが、ＶＬＤＲのビートＢ１の前に完了し、したがって、ＶＬＤＲのターゲット・アドレスは、ＶＭＬＡ命令のビートＡ１において乗算された要素Ｑ３［１］、Ｑ４［１］の積に依存するであろう。一方、下部の実例では、１つの介在するＶＯＲＲ命令があり、したがって、今度はＶＬＤＲは命令Ｃである。このとき、ＶＬＤＲの第１のビートＣ１は、ＶＭＬＡのビートＡ３と並行して実施され、したがって、ロードのビートＣ１において計算されたターゲット・アドレスは、ＶＭＬＡの最初の２つのビートの累算（すなわち、Ｑ３［１］＊Ｑ４［１］＋Ｑ３［２］＊Ｑ４［２］）に依存し、したがって、それは、図１２の上部の実例と比較して異なるアドレスからロードすることになる。

ロードの正しい処理結果は、Ｒ０中の値を、乗算累算のビートＡ１からＡ４までにおいて実施されるすべての累算の成果に対応させるべきであろうから、図１２の両方の実例が正しくないものと見なされる。それにもかかわらず、所与の命令の成果を、それが依存する命令からそれをいくつの介在する命令が分離するかに依存させることも、望ましくないと見なされ、正しくない処理結果をもたらすであろう。

この問題に対処するための様々な手法がある。１つの手法は、混合スカラー・ベクトル命令の実行を決して重複させないことであろう。しかしながら、いくつかの実際的適用例（例えばＤＳＰ）の場合、混合スカラー・ベクトル命令は、実行されたベクトル命令の総数のかなりの部分を表し得、したがって、混合スカラー・ベクトル命令の重複実行を防ぐことは、ベクトル命令の実行を重複させることの利点の大部分を最初に否定することになる。これは、プロセッサの効率を低減する時間の大部分の間、乗算累算ユニット又はロード／記憶ユニットなどのハードウェア・ブロックがアイドル状態のままにされることにつながることがある。多くの場合、連続する混合スカラー・ベクトル命令が、同じスカラー・レジスタを参照しないことになり、この場合、実行を重複させることは許容可能であり得る。したがって、可能な場合、この重複実行を可能にすることは望ましいことであろう。

別の手法は、命令セット・アーキテクチャにおいて与えられる混合スカラー・ベクトル命令の数を低減することであり得、したがって、それらがスカラー結果を生成するか又はスカラー・オペランドを使用する場合でも、多くのベクトル命令が、それらのスカラー値をベクトル・ファイルから／に読み取り／書き込み、単にデータをスカラー・レジスタ・ファイル１２とベクトル・レジスタ・ファイル１４との間で転送するための限られた数のタイプの混合スカラー・ベクトル命令が与えられる。しかしながら、ベクトル・レジスタ・ファイルのみを使用するためにベクトル命令を制限することは、ベクトル・レジスタ・ファイル１４の記憶容量及び読取り／書込みポートに対する圧力を増加させ、それは、プロセッサの性能、面積及び電力に影響を及ぼすことがある。したがって、妥当な数の混合スカラー・ベクトル命令をサポートし続けることが望ましいことがある。

別の手法は、それぞれの混合スカラー・ベクトル命令によってスカラー・レジスタとして指定されたレジスタを比較することと、混合スカラー・ベクトル命令のペア間で同じスカラー・レジスタに対する依存性があるとき、重複実行を防ぐこととのために、ハードウェアにおけるレジスタ依存性検査回路を与えることであり得る。しかしながら、特に、比較的低電力の実装形態の場合、比較器が、ゲート・カウントに関して比較的費用がかかり得るので、そのような依存性検査回路を与えることは、装置の全体的電力消費及び回路面積に対して顕著な影響を有することがある。

実際には、ベクトル命令を使用する通常のプログラム・コードでは、図１１及び図１２に示されているものなどのスカラー依存性を有する可能性は極めて低い。ロードのためのポインタとして使用されているレジスタに乗算の和を書き込むこと、或いは、乗算累算命令によって前に生成されたアドレスからのデータをロードすることが望まれることは、極めて可能性が低いので、図１１及び図１２は、特には現実的な実例でない。ポインタ値と累算とのこの混合は単に、コードの観点から理にかなっておらず、命令の重複実行から起こることがある不確実性の実例として説明される。

実際には、本発明者は、混合スカラー・ベクトル命令のいくつかの組合せが、潜在的に正しくないことがある未知の結果につながることが許可される場合、より効率的なマイクロアーキテクチャが構築され得ることを認識した。したがって、図１１及び図１２に示されている緩和された実行の２つインスタンスは、第１の混合スカラー・ベクトル命令及び第２の混合スカラー・ベクトル命令が、それらの間の所定の数よりも少ない介在する命令とともに行われるとき、許可される。本発明者は、実際には、コードが、命令のそのような組合せを含むことがまれであること、したがって、そのようなまれな場合から保護するために、費用がかかる依存性検査回路を与えることが、電力及び面積の浪費であることを認識した。実際には、依存性が生じる可能性がある少ない状況について、正しい結果が達成され得ることを保証するために、いくつかのより効率的な技法が使用され得る。他の依存状況において結果が「未知」であることを許可する命令セット・アーキテクチャを提供することによって、全体的なマイクロアーキテクチャ・ハードウェア実装形態が、より効率的にされ得る。その場合、未知の結果が生じることがあるコーナーケースをもつコードを書くことを回避するのは、プログラマーの責任であり、以下で説明されるように、アーキテクチャは、そのような状況を回避するようにプログラマーを誘導するためのいくつかの比較的単純なルールを定義し得、したがって、処理ハードウェア自体が、これらについて検査する必要がない。

したがって、第１のスカラー・レジスタを指定する第１の混合スカラー・ベクトル命令と、第２のスカラー・レジスタを指定する後続の混合スカラー・ベクトル命令とを、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の所定の数よりも少ない介在する命令とともに含む命令のシーケンスを実行するとき、プロセッサは、
・（図１１の実例の場合のように）第１のスカラー・レジスタはソース・レジスタであり、第２のスカラー・レジスタは宛先レジスタであり、処理回路は、第２のスカラー・レジスタが前記第１のスカラー・レジスタと同じレジスタであるかどうかに応じて異なる、前記第１の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との重複実行を許可するように構成されるやり方と、
・（図１２の実例の場合のように）第１のスカラー・レジスタは宛先レジスタであり、前記第２のスカラー・レジスタはソース・レジスタであり、前記第１のスカラー・レジスタ及び前記第２のスカラー・レジスタは、同じレジスタであり（第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間に所定の数の介在する命令又は所定の数よりも少ない介在する命令をもち）、処理回路は、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の介在する命令の数に応じて異なる、前記第２の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を許可にするように構成されるやり方と
のうちの１つで、緩和された実行をサポートし得る。

この手法は、結果は、特定のマイクロアーキテクチャ実装形態が命令の実行を重複させることを選定する特定のやり方に依存し得るので、それが、命令の所与のセットを実行することの成果における、正しくない処理結果及び不確実性につながることが予想されるので、極めて直観に反している。しかしながら、この不確実性を許可することによって、これは、マイクロアーキテクチャを変化させるより多くの自由を与え、依存性検査の費用を回避する。いずれの場合も、これらのタイプの混合スカラー・ベクトル命令の実際的な現実世界の適用例は、プログラマーが緩和された実行が生じるケースを使用することを望むことになる可能性を非常に低くする。

上記に記載した緩和された実行の２つの実例のうちの、第１のスカラー・レジスタがソース・レジスタであり、第２のスカラー・レジスタが宛先レジスタである第１の実例では、第１のスカラー・レジスタは宛先レジスタでもあり得ることに留意されたい。同様に、第２のスカラー・レジスタは、ソース・レジスタ並びに宛先レジスタであり得る。代替的に、第１のスカラー・レジスタは、純粋にソース・レジスタであり得るが、宛先レジスタでないことがあり、又は、第２のスカラー・レジスタは、純粋にソース・レジスタであり得るが、宛先レジスタでないことがある。同様に、第１のスカラー・レジスタが宛先レジスタであり、第２のスカラー・レジスタがソース・レジスタである、緩和された実行の第２の例では、第１のスカラー・レジスタはソース・レジスタであり得、第２のスカラー・レジスタは宛先レジスタでもあり得る。したがって、特定のスカラー・レジスタがソース・レジスタ又は宛先レジスタであることを指定することは、スカラー・レジスタが他のタイプのレジスタであり得ることを除外しない。

この手法は、第１混合スカラー・ベクトル命令及び後続の混合スカラー・ベクトル命令のうちの少なくとも１つが算術命令であるとき、特に有用である。

実際には、混合スカラー・ベクトル命令間の実コードにおける最も一般的な実際の依存性は、関係するグループからの複数の命令がレジスタ依存性を有するときに生じる。例えば、いくつかのメモリ命令が、同じポインタ値を使用し得るか、又は、いくつかの乗算累算命令が、図１４の実例に示されているように、同じアキュムレータ・レジスタに累算し得る。図１３に示されているように、処理回路４は、命令の異なるクラスに対応するいくつかの別個のハードウェア・ユニット２００、２０２、２０４、２０６を含み得る。例えば、ハードウェア・ユニットは、メモリ命令を実行するためのロード記憶ユニット２００と、乗算に関与する命令を実行するための乗算累算ユニット２０２と、乗算以外の他の算術又は論理命令を実行するためのＡＬＵと、浮動小数点命令を実行するための浮動小数点ユニット２０６とを含み得る。したがって、命令は、どのハードウェア・ユニットがそれらを実行するように設計されたかの観点から分類され得る。

この場合、実行されるべき同じクラス中の複数の命令があるとき、第２の命令は、同じ実行リソースに対する競合があるので、第１の命令が完了するまで開始することが可能でないことがある。したがって、この場合、自然のパイプライン構造ハザードが、各命令のレジスタ指定子を比較するための余分の依存性検査回路の必要なしに、レジスタ依存性を解決することがある。したがって、アーキテクチャは、命令の異なるクラスを定義し得、第１の混合スカラー・ベクトル命令及び第２の混合スカラー・ベクトル命令が両方とも同じクラスからのものであるとき、図１１又は図１２に示されているタイプの緩和された実行が防がれるべきであることを必要とし得る。命令のクラスを検査するためのハードウェアは、しばしば、（ハードウェア・ユニット２００、２０２、２０４、２０６のうちのどれが命令を処理するかを制御するために、命令デコーダ６においてオペコードの復号がすでに必要とされていることがあるので）異なる命令のレジスタ指定子を比較するためのハードウェアよりも、あまり追加のオーバーヘッドを必要としないことがあり、したがって、この手法は、より面積及び電力効率的であることがある。

クラスの特定の定義は、実施形態ごとに変化し得る。図１３は、メモリ・アクセス命令と、乗算命令と、非乗算算術命令と、浮動小数点命令とに対応する４つのクラスにマッピングされ得る４つの実行ユニットをもつ実例を示すが、クラスは、他の命令を包含するために拡張され得るか、或いは、これらのクラスのうちの１つ又は複数が、省略されるか又は別のクラスと組み合わせられ得る。また、いくつかのベクトル命令は、それらの実行が、それらのタイプにかかわらず他のベクトル命令と重複され得るように、特定のクラスに割り振られないことがある。

例えば、実コードで起こる可能性があるベクトル命令間のスカラー依存性の最も一般的な場合では、２つの乗算命令又は２つのロード命令は、同じスカラー・レジスタを使用し得、したがって、単に、少なくともロード命令を含む第１のクラスと、（乗算累算を含む）少なくとも乗算命令を含む第２のクラスとを定義するために十分であることがある。任意の他のベクトル命令は、それらのタイプにかかわらず、重複され得るものとして扱われ得る。いくつかの乗算命令又はいくつかのロード重複を防ぐことが、最も一般的な実際の依存性を解決するために十分であり得る。

より一般的には、処理回路は、混合スカラー・ベクトル命令の異なるクラスをサポートし得、処理回路は、第１カラー・ベクトル命令及び後続の混合スカラー・ベクトル命令が両方とも同じクラスからのものであるとき、それらの緩和された実行を防ぎ得る。緩和された実行を防ぐ１つのやり方は、命令が重複することを防ぐことであり得るが、別の手法は、それらがもはや互いに依存しないように、命令のうちの１方又は他方によってどのレジスタが指定されるかを再マッピングすることであり得る。例えば、第１の混合スカラー・ベクトル命令が、ソース・レジスタとしてスカラー・レジスタを使用し（ただし、スカラー・レジスタは、第１の混合スカラー・ベクトル命令によって宛先レジスタとして使用されず）、第２の命令がスカラー宛先レジスタを使用する、図１８に示されている場合には、緩和された実行は、第１の命令によって参照される第１のスカラー・レジスタからのスカラー値を、第２の命令によって参照されない異なる第３のスカラー・レジスタにコピーすること、したがって、命令が、今度は異なるレジスタを指すことによって防がれ得る。一方、このレジスタ再マッピングはまた、回路面積に関していくらかのオーバーヘッドを必要とし得、したがって、多くの場合、単に、これらの命令のための重複実行を回避することによって緩和された実行を防ぐことが、より効率的であり得る。

概して、クラスは、同じハードウェア回路ユニットを使用する命令のクラスに対応し得るが、２つ又はそれ以上の異なるハードウェア・ユニットに対応する、いくつかのクラスがあり得る。例えば、命令のグループは、それらが、それら自身によってクラスを正当化するのに十分に共通でなく、これらが、任意の他の数の異なるハードウェア回路ユニットを使用して実行され得る場合、「他」として分類され得る。所与の実装形態が、異なるハードウェア・ユニット上で様々な種類の命令を実行することを選定する特定のやり方は、マイクロアーキテクチャ・レベルにおける実装形態選定であり、したがって、アーキテクチャは、実際に使用される特定のハードウェア・ユニットと関係なく、単に、可能性がある実装形態に関してクラスを定義し得る。

図１５及び図１６は、２つの混合スカラー・ベクトル命令間の依存性が満たされることを保証するために、プログラム・コード・レベルにおいて使用され得る他の技法を示す。図１５に示されているように、十分な数の介在する命令によって２つの混合スカラー・ベクトル命令が分離されると、それらの混合スカラー・ベクトル命令間に重複がないことになり、したがって、依存性はすでに満たされたことになる。分離が保証される、介在する命令の所定の数は、特定のマイクロアーキテクチャ実装形態に依存することになる。例えば、ティックごとに１つのビートを処理し、連続するベクトル命令の実行を１つのビートによってスタッガする実装形態では、介在する命令の所定の数は、Ｎ−１（ここで、Ｎはベクトル命令ごとのビートの数である）であり、例えば、上記の実例の場合、４ビート・ベクトルでは、３つの介在する命令である。より一般的には、処理の２^Ｊ個のビートを使用してベクトル命令が処理され、ここで、Ｊは、１よりも大きいか又はそれに等しい整数であり、重複実行では、処理回路が、第１のベクトル命令の第（２Ｋ＋１）のビートと並行して、第２のベクトル命令の第１のビートを実施し、ここで、Ｋは、整数及び０≦Ｋ＜Ｊである、命令の単一発行を用いたシステムの場合、介在する命令の所定の数は、（２^{（Ｊ−Ｋ）}−１）になり得る。デュアル発行をサポートするシステムの場合、介在する命令の所定の数は、より大きくなり得る。

したがって、命令の所定の数は、概して、第１の混合スカラー・ベクトル命令のビートを第２の混合スカラー・ベクトル命令のビートと重複させることが可能でないことを保証する、２つの連続する混合スカラー・ベクトル命令間の介在する命令の最小数である。２つの命令が、それらの依存性を引き受けることになる、何らか確実性をプログラマー又はコンパイラに与えるために、命令セット・アーキテクチャは、介在する命令の所定の数のために、ある最小値を指定し得、そのアーキテクチャに準拠するマイクロアーキテクチャは、少なくともその数の命令によって命令が分離されたとき、成果が正しく、繰返し可能であることを保証するための回路を与えるべきである。それにもかかわらず、これは、プログラマーが、所定の数よりも少ない命令によって、異なるクラスの２つの混合スカラー・ベクトル命令を分離する場合、マイクロアーキテクチャが不確定な結果を許可する自由を与える。

したがって、プログラマー又はコンパイラは、アーキテクチャによって指定されているように、それらの間に少なくとも最小数の介在する命令を含めることによって、２つの依存する混合スカラー・ベクトル命令が、それらの依存性が満たされることになることを保証することができる。多くの場合のように、依存する混合スカラー・ベクトル命令は、十分な命令によってすでに分離されていることになり、その場合、それらが互いにより近い、時折の場合から保護するためにレジスタ依存性検査回路を与えることは、しばしば正当化されない。

一方、依存する混合スカラー・ベクトル命令に、それらの間の所定の数よりも少ない介在する命令を与えることが望まれる場合、それらが、図１３及び図１４に関して説明されたように、同じクラス中にない場合には、アーキテクチャはまた、バリアの両側、２つの混合スカラー・ベクトル命令間の依存性を引き受けることをハードウェアに強いるために、プログラム・コードに含まれ得る重複バリア命令ＣＳＢを与え得る。したがって、介入する重複バリア命令があるとき、処理回路は、重複を防ぐこと又はレジスタ指定子を再マッピングすることのいずれかによって、バリアの両側上の混合スカラー・ベクトル命令の緩和された実行を防ぎ得る。

異なる実装形態は、異なるやり方でバリア命令をハンドリングし得る。図２の上部の実例の場合のように、ティックごとに単一のビートのマイクロアーキテクチャの場合、いくつかの回路が、バリア命令を検出するため、及び、第２の命令が、第１の命令が完了した後に開始されることを可能にするために十分なバブルをパイプライン中に挿入するために与えられ得る。図２の第２の実例に示されたようにデュアルビート・マイクロアーキテクチャの場合、命令の半分が両方のティックにおいて処理されるので、単一のバブルで十分であり得、したがって、バリア命令は、無演算（ｎｏ−ｏｐ）動作を実行することによって実施され得る。１つのティックにおいて全ベクトル演算を実行するための十分な実行リソースを有するクワッド・ビート・マイクロアーキテクチャの場合、依存性は、ストーリング又はパディングなしにすでに満たされており、したがって、より高性能のマイクロアーキテクチャは、実際は、バリア命令のために何もする必要がなく、パイプラインのより早いステージにおいて（例えば、フェッチ又は復号ステージにおいて）バリア命令を単に除去することができる。したがって、アーキテクチャのために書かれたコードは、それが、ベクトル命令を重複させる実装形態上で実行されている場合、バリア命令を含むことができるが、他のマイクロアーキテクチャは、実際に無演算を挿入する必要がないことがあり、バリアを無視することができる。

したがって、共通のスカラー・レジスタに依存し、所定の数よりも少ない命令が介入することによって分離される、異なるクラスの混合スカラー・ベクトル命令を与えることを、プログラマーが実際に望む極めてまれな機会に、バリアは使用され得る。本質的に、アーキテクチャは、プログラマー又はコンパイラが、所与の数よりも少ない命令によって命令を分離することを望む場合、それらは、バリアを使用するべきであり、さもなければ、それらは不確定な結果の危険を冒すことを、指摘し得る。

図１７は、混合スカラー・ベクトル命令をハンドリングする方法を示す流れ図を示す。ステップ２５０において、命令デコーダは、処理されるべき命令が混合スカラー・ベクトル命令であるかどうかを検出する。混合スカラー・ベクトル命令でない場合、命令は、そのタイプの命令に適した処理に従ってハンドリングされる。命令が混合スカラー・ベクトル命令である場合、ステップ２５２において、ビート制御回路３０は、まだ完了しておらず、現在の混合スカラー・ベクトル命令と同じクラスからのものである、前の混合スカラー・ベクトル命令があるかどうかを検出する。命令の検出及びビートのスケジューリングが、パイプラインのより早いステージにおいて行われ得るとき、前の混合スカラー・ベクトル命令は、実行をまだ開始していないことがあることに留意されたい。代替的に、前の混合スカラー・ベクトル命令は、部分的に実行され得る。

同じクラスからの完了していない混合スカラー・ベクトル命令がある場合、ステップ２５４において、ビート制御回路３０は、図１１及び図１２の実例に示されている形式の緩和された実行を防ぐためのアクションをとる。このアクションは、命令が重複するのを防ぐために、前の混合スカラー・ベクトル命令が完了するまで、実行のための現在の混合スカラー・ベクトル命令のスケジューリングを遅延させることであり得る。代替的に、現在の混合スカラー・ベクトル命令が宛先レジスタとして第２のスカラー・レジスタを指定し、前の混合スカラー・ベクトル命令がソース・レジスタとして第１のスカラー・レジスタを指定し、前の混合スカラー・ベクトル命令が実行をまだ開始していない場合、アクションは、第２のスカラー・レジスタとは異なる第３のスカラー・レジスタに第１のスカラー・レジスタからの値を書き込むことと、第１のスカラー・レジスタの代わりに第３のスカラー・レジスタを使用して、前の混合スカラー・ベクトル命令を実行することと含む。現在の混合スカラー・ベクトル命令が、前の混合スカラー・ベクトル命令と同じクラスからのものである場合、レジスタ参照を比較するためにハードウェアにおいて与えられる依存性検査回路がないので、前の混合スカラー・ベクトル命令及び現在の混合スカラー・ベクトル命令よって指定されたスカラー・レジスタが、実際に同じレジスタであるかどうかにかかわらず、万が一それらが同一である場合に備えて、ステップ２５４における反応アクションがとられることに留意されたい。

また、ステップ２５６において、ビート制御回路は、前の混合スカラー・ベクトル命令と現在の混合スカラー・ベクトル命令との間の重複バリア命令に遭遇したかどうかを確認する。遭遇した場合、再びステップ２５４において、レジスタ参照を再マッピングすること、又は重複実行を防ぐことのいずれかによって、緩和された実行を回避するために反応アクションがとられる。図１７は、ステップ２５２及び２５６が、重複バリア命令について検査するステップの前に、クラス検査ステップ２５２と連続的に実施されることを示しているが、それらは、反対の順序で、又は互いと並行して実施され得る。

前の混合スカラー・ベクトル命令及び現在の混合スカラー・ベクトル命令が同じクラスからのものでなく（又は、重複実行に対する制限が課されない「他」のタイプの命令からのものであり）、それらの間に重複バリア命令がない場合、緩和された実行が、図１１及び図１２に示されているタイプの未知の結果を生じる場合でも、ステップ２５８において、重複実行が許可される。

要約すれば、ベクトル命令からのスカラー・レジスタ更新を中心とする依存性検査を緩和することによって、及び、代わりに、上記で説明されたいくつかのより軽量のアーキテクチャ機構に依拠することによって、より効率的な実装形態を可能にするレジスタ指定子を比較するための余分の検査ハードウェアの必要なしに、現実の依存性が満たされ得る。

図１９は、使用され得る仮想マシン実装形態を示す。前に説明された実施形態は、関係する技法をサポートする特定の処理ハードウェアを動作させるための装置及び方法に関して本発明を実装するが、ハードウェア・デバイスのいわゆる仮想マシン実装形態を与えることも可能である。これらの仮想マシン実装形態は、仮想マシン・プログラム１３０をサポートするホスト・オペレーティング・システム１４０を動作させる、ホスト・プロセッサ１５０上で動作する。一般に、妥当な速度で実行する仮想マシン実装形態を提供するために、大きい、強力なプロセッサが必要とされるが、そのような手法は、適合性又は再利用理由のために、別のプロセッサにネイティブなコードを動作させる要望があるときなど、いくつかの状況で正当化され得る。仮想マシン・プログラム１３０は、仮想マシン・プログラム１３０によってモデル化されたデバイスである実際のハードウェアによって提供されるであろう、ハードウェア・インターフェースと同様である仮想ハードウェア・インターフェースをゲスト・プログラム１２０に提供する。したがって、上記のメモリ・アクセスの制御を含むプログラム命令は、仮想マシン・ハードウェアとのそれらの対話をモデル化するために仮想マシン・プログラム１３０を使用して、ゲスト・プログラム１２０内から実行され得る。ゲスト・プログラム１２０は、ベア・メタル（ｂａｒｅ ｍｅｔａｌ）プログラムであり得、又は代替的に、それは、ホストＯＳ１４０が仮想マシン・アプリケーション１３０を動作させるやり方と同様のやり方でアプリケーションを動作させる、ゲスト・オペレーティング・システムであり得る。異なるタイプの仮想マシンがあり、いくつかのタイプでは、仮想マシンは、ホストＯＳ１４０の必要なしに、ホスト・ハードウェア１５０上で直接動作することも諒解されよう。

例示的な構成が、以下の項において以下で提示される。
（１） ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための処理回路を備える装置であって、
所与のベクトル命令に応答して、処理回路が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理回路は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するように構成され、
イベントに応答して、処理回路が、前記所与のベクトル命令の処理を中断するように構成され、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、処理回路が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成された、
装置。
（２） 処理回路が、前記複数のベクトル命令のうちの１つのアドレスを示す復帰アドレスを設定するように構成され、
イベントからの復帰要求に応答して、処理回路は、復帰アドレス及び前記ビート・ステータス情報に基づいて、処理が再開されるべきであるポイントを識別するように構成された、
項（１）に記載の装置。
（３） 復帰アドレスは、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令のアドレスを示す、項（２）に記載の装置。
（４） 複数のベクトル命令は、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令と、少なくとも１つの後続のベクトル命令とを含む、項（１）から（３）までのいずれか一項に記載の装置。
（５） 処理回路が、所与のベクトル命令の複数のビートのすべてを並行して実施するには不十分なハードウェアを備える、項（１）から（４）までのいずれか一項に記載の装置。
（６） 処理回路が、所与のベクトル命令の複数のビートの第１のサブセットを完了した後に、所与のベクトル命令の複数のビートの第２のサブセットを実施するように構成された、項（１）から（５）までのいずれか一項に記載の装置。
（７） 処理回路が、第２のベクトル命令のためのビートの第１のサブセットを実施することと並行して、第１のベクトル命令のためのビートの第２のサブセットを実施するように構成された、項（６）に記載の装置。
（８） 後続のベクトル命令の第１のビートを開始する前に、１つのベクトル命令のいくつのビートが完了されるべきかを、命令ごとに変化させるための制御回路を備える、項（１）から（７）までのいずれか一項に記載の装置。
（９） 処理回路が、所与のベクトル命令の複数のビートのすべてを並行して実施するのをサポートするように構成されたハードウェアを備える、項（１）から（４）まで、（６）及び（７）のいずれか一項に記載の装置。
（１０） ベクトル値が、処理回路にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
処理の各ビートが、前記データ要素サイズ情報によって示されたデータ要素サイズにかかわらず、ベクトル値の固定サイズ部分に対応する処理を含む、
項（１）から（９）までのいずれか一項に記載の装置。
（１１） 処理回路が、前記ビート・ステータス情報を、処理回路によって実行されるソフトウェア、例外ハンドラ及びデバッガのうちの少なくとも１つにとってアクセス可能にするように構成された、項（１）から（１０）までのいずれか一項に記載の装置。
（１２） 前記イベントがデバッグ・イベントを含み、前記イベントからの復帰要求がデバッグ状態からの復帰を含む、項（１）から（１１）までのいずれか一項に記載の装置。
（１３） 前記イベントが例外イベントを含み、前記イベントからの復帰要求が例外復帰を含む、項（１）から（１２）までのいずれか一項に記載の装置。
（１４） 前記例外イベントが障害イベントを含み、前記障害イベントに応答して、処理回路は、前記複数のベクトル命令のうちのどれが、前記障害イベントが検出された、前記所与のベクトル命令であるかを識別する情報を設定するように構成された、項（１３）に記載の装置。
（１５） 例外イベントに応答して、前記処理回路が、前記ビート・ステータス情報へのアクセスを無効化するように構成され、
前記ビート・ステータス情報にアクセスすることを試みる命令、又は処理の複数のビートを含む少なくとも１つのタイプのさらなるベクトル命令の実行に応答して、前記処理回路が、
前記ビート・ステータス情報を所定のロケーションに保存すること、又は
第２の例外イベントを起こすこと
を行うように構成された、項（１３）及び（１４）のいずれか一項に記載の装置。
（１６） 例外イベントに応答して、処理回路が、ビート・ステータス情報を、スタック・ポインタ・レジスタによって示された値に対するオフセットにおいてデータ・ストア中のロケーションに保存するように構成された、項（１３）及び（１４）のいずれか一項に記載の装置。
（１７） 前記処理回路が、少なくともセキュアな状態及びあまりセキュアでない状態を含む複数のセキュリティ状態で動作可能であり、例外イベントが、前記セキュアな状態から前記あまりセキュアでない状態への遷移を生じることに応答して、処理回路が、ビート・ステータス情報をクリアするように構成された、項（１６）に記載の装置。
（１８） 処理回路が、
処理の所与のビートに対応する宛先ベクトル・レジスタの一部分を更新することを抑制することと、
処理の前記所与のビートに関連する処理演算を抑制することと
のうちの１つによって処理の前記所与のビートを抑制するように構成された、項（１）から（１７）までのいずれか一項に記載の装置。
（１９） ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための手段を備える装置であって、
所与のベクトル命令に応答して、処理するための手段が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理するための手段は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートがすでに完了したかを示すビート・ステータス情報を設定するように構成され、
イベントに応答して、処理するための手段が、前記所与のベクトル命令の処理を中断するように構成され、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、処理するための手段が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成された、
装置。
（２０） ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理する方法であって、
所与のベクトル命令に応答して、処理の複数のビートを実施するステップであって、各ビートが、ベクトル値の一部分に対応する処理を含む、ステップと、
前記所与のベクトル命令を含む複数のベクトル命令のどのビートがすでに完了したかを示すビート・ステータス情報を設定するステップと、
イベントに応答して、前記所与のベクトル命令の処理を中断するステップと、
前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令のビートを抑制しながら、前記複数のベクトル命令の処理を再開するステップと
を含む、方法。
（２１） 項（１）から（１８）までのいずれか一項に記載の装置に対応する、命令実行環境を与えるようにホスト・データ処理装置を制御するためのプログラム命令を含む、仮想マシン・コンピュータ・プログラム。
（２２） １つ又は複数のソース・レジスタ及び宛先レジスタを指定するベクトル命令を処理するための処理回路を備える装置であって、前記宛先レジスタ及び前記１つ又は複数のソース・レジスタのうちの少なくとも１つが、複数のデータ要素を含むベクトル値を記憶するためのベクトル・レジスタであり、
ベクトル命令は、前記宛先レジスタ及び前記１つ又は複数のソース・レジスタのうちの別のものが、単一のデータ要素を含むスカラー値を記憶するためのスカラー・レジスタである、少なくとも１つのタイプの混合スカラー・ベクトル命令を含み、
所与のベクトル命令に応答して、処理回路が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理回路は、第１のベクトル命令の少なくとも１つのビートが、第２のベクトル命令の少なくとも１つのビートと並行して実施される、第１のベクトル命令と第２のベクトル命令との重複実行をサポートするように構成され、
第１のスカラー・レジスタを指定する第１の混合スカラー・ベクトル命令と第２のスカラー・レジスタを指定する後続の混合スカラー・ベクトル命令とを、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の所定の数よりも少ない介在する命令とともに含む命令のシーケンスに応答して、前記処理回路は、
前記第１のスカラー・レジスタはソース・レジスタであり、前記第２のスカラー・レジスタは宛先レジスタである場合、処理回路は、第２のスカラー・レジスタが前記第１のスカラー・レジスタと同じレジスタであるかどうかに応じて異なる、前記第１の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を許可するように構成されること、並びに、
前記第１のスカラー・レジスタは宛先レジスタであり、前記第２のスカラー・レジスタはソース・レジスタであり、前記第１のスカラー・レジスタ及び前記第２のスカラー・レジスタは、同じレジスタである場合、前記処理回路は、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の介在する命令の数に応じて異なる、前記第２の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を可能にするように構成されること、
のうちの少なくとも１つを含む緩和された実行をサポートするように構成された、
装置。
（２３） 前記第１混合スカラー・ベクトル命令及び後続の混合スカラー・ベクトル命令のうちの少なくとも１つが算術命令である、項（２２）に記載の装置。
（２４） 処理回路が、混合スカラー・ベクトル命令の複数の異なるクラスの処理をサポートするように構成され、
処理回路は、第１のカラー・ベクトル命令及び後続の混合スカラー・ベクトル命令が両方とも同じクラスからのものであるとき、処理回路は第１の後続の混合スカラー・ベクトル命令の前記緩和された実行を防ぐように構成された、
項（２２）及び（２３）のいずれか一項に記載の装置。
（２５） 処理回路は、前記第１混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を防ぐことによって、前記緩和された実行を防ぐように構成された、項（２４）に記載の装置。
（２６） 前記第１のスカラー・レジスタがソース・レジスタであり、前記第２のスカラー・レジスタが宛先レジスタである場合、処理回路は、第１のスカラー・レジスタからのスカラー値を第３のスカラー・レジスタにコピーすることと、ソース・レジスタとして前記第１のスカラー・レジスタの代わりに前記第３のスカラー・レジスタを使用して、前記第１の混合スカラー・ベクトル命令の少なくとも１つのビートを実行することとによって、前記緩和された実行を防ぐように構成された、項（２４）及び（２５）のいずれか一項に記載の装置。
（２７） 処理回路が、同じハードウェア回路ユニットを使用して、同じクラスからの混合スカラー・ベクトル命令を処理するように構成された、項（２４）から（２６）までのいずれか一項に記載の装置。
（２８） 処理回路が、異なるハードウェア回路ユニットを使用して、少なくともいくつかの異なるクラスからの混合スカラー・ベクトル命令を処理するように構成された、項（２７）に記載の装置。
（２９） 混合スカラー・ベクトル命令の複数のクラスは、少なくとも
少なくともロード命令を含む第１のクラスと、
少なくとも、乗算を実行する命令含む第第２のクラスと
を含む、項（２４）から（２８）までのいずれか一項に記載の装置。
（３０） 混合スカラー・ベクトル命令の複数のクラスが、少なくとも
少なくともメモリ・アクセス命令を含む第１のクラスと、
少なくとも、乗算を実施する命令を含む第２のクラスと
少なくとも非乗算算術命令を含む第３のクラス、および
少なくとも浮動小数点命令を含む第４のクラスのうちの少なくとも１つと
を含む、項（２４）から（２９）までのいずれか一項に記載の装置。
（３１） 処理回路は、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の介在する命令が、重複バリア命令であるとき、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記緩和された実行を防ぐように構成された、項（２２）から（３０）までのいずれか一項に記載の装置。
（３２） 前記第１のスカラー・レジスタがソース・レジスタであり、前記第２のスカラー・レジスタが宛先レジスタである場合、処理回路が、第１のスカラー・レジスタからのスカラー値を第３のスカラー・レジスタにコピーすることと、ソース・レジスタとして前記第１のスカラー・レジスタの代わりに前記第３のスカラー・レジスタを使用して、前記第１の混合スカラー・ベクトル命令の少なくとも１つのビートを実行することとによって、前記緩和された実行を防ぐように構成された、項（３１）に記載の装置。
（３３） 処理回路が、少なくとも１つの無演算動作として前記重複バリア命令を実行するように構成された、項（３１）から（３２）までのいずれか一項に記載の装置。
（３４） 前記スカラー・レジスタが前記ソース・レジスタのうちの１つである、混合スカラー・ベクトル命令に応答して、処理回路は、前記スカラー・レジスタにおけるスカラー値に依存する処理の前記複数のビートの各々を実施するように構成された、項（２２）から（３３）までのいずれか一項に記載の装置。
（３５） 前記スカラー・レジスタが宛先レジスタである、混合スカラー・ベクトル命令に応答して、前記スカラー・レジスタに書き込まれるべきスカラー結果値は、処理の前記複数のビートの各々の成果に依存する、項（２２）から（３４）までのいずれか一項に記載の装置。
（３６） 少なくとも１つのタイプの混合スカラー・ベクトル命令の場合、前記スカラー・レジスタは、ソース・レジスタと宛先レジスタの両方である、項（２２）から（３５）までのいずれか一項に記載の装置。
（３７） 処理回路が、所与のベクトル命令の複数のビートのすべてを並行して実施するには不十分なハードウェアを備える、項（２２）から（３６）までのいずれか一項に記載の装置。
（３８） 前記重複実行では、処理回路が、前記第１のベクトル命令のビートの第２のサブセットと並行して、前記第２のベクトル命令のビートの第１のサブセットを実施するように構成された、項（２２）から（３７）までのいずれか一項に記載の装置。
（３９） 処理の前記複数のビートが、処理の２^Ｊ個のビートを含み、ここで、Ｊは、１よりも大きいか又はそれに等しい整数である、
前記重複実行では、処理回路が、前記第１のベクトル命令の第（２Ｋ＋１）のビートと並行して、前記第２のベクトル命令の第１のビートを実施するように構成され、ここで、Ｋは、整数及び０≦Ｋ＜Ｊである、
介在する命令の所定の数は、（２^{（Ｊ−Ｋ）}−１）を含む、
項（２２）から（３８）までのいずれか一項に記載の装置。
（４０） ベクトル値が、処理回路にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
処理の各ビートが、前記データ要素サイズ情報によって示されたデータ要素サイズにかかわらず、ベクトル値の固定サイズ部分に対応する処理を含む、
項（２２）から（３９）までのいずれか一項に記載の装置。
（４１） １つ又は複数のソース・レジスタ及び宛先レジスタを指定するベクトル命令を処理するための手段であって、前記宛先レジスタ及び前記１つ又は複数のソース・レジスタの少なくとも１つが、複数のデータ要素を含むベクトル値を記憶するためのベクトル・レジスタである、処理するための手段を備える装置であって、
ベクトル命令は、前記宛先レジスタ及び前記１つ又は複数のソース・レジスタのうちの別のものが、単一のデータ要素を含むスカラー値を記憶するためのスカラー・レジスタである、少なくとも１つのタイプの混合スカラー・ベクトル命令を含み、
所与のベクトル命令に応答して、処理するための手段が、処理の複数のビートを実施するように構成され、各ビートが、ベクトル値の一部分に対応する処理を含み、
処理するための手段は、第１のベクトル命令と第２のベクトル命令との重複実行をサポートするように構成され、第１のベクトル命令の少なくとも１つのビートが、第２のベクトル命令の少なくとも１つのビートと並行して実施され、
第１のスカラー・レジスタを指定する第１の混合スカラー・ベクトル命令と、第２のスカラー・レジスタを指定する後続の混合スカラー・ベクトル命令とを、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の所定の数よりも少ない介在する命令とともに含む命令のシーケンスに応答して、処理するための前記手段は、以下のうちの少なくとも１つを含む緩和された実行をサポートするように構成され、
前記第１のスカラー・レジスタはソース・レジスタであり、前記第２のスカラー・レジスタは宛先レジスタであり、処理するための手段は、第２のスカラー・レジスタが前記第１のスカラー・レジスタと同じレジスタであるかどうかに応じて異なる、前記第１の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を許可にするように構成され、
前記第１のスカラー・レジスタは宛先レジスタであり、前記第２のスカラー・レジスタはソース・レジスタであり、前記第１のスカラー・レジスタ及び前記第２のスカラー・レジスタは、同じレジスタであり、処理するための前記手段は、第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との間の介在する命令の数に応じて異なる、前記第２の混合スカラー・ベクトル命令の結果を生成するために、前記第１の混合スカラー・ベクトル命令と後続の混合スカラー・ベクトル命令との前記重複実行を許可にするように構成される、
装置。
（４２） 項（２２）から（４０）までのいずれか一項に記載の装置に対応する、命令実行環境を与えるようにホスト・データ処理装置を制御するためのプログラム命令を含む、仮想マシン・コンピュータ・プログラム。

本出願では、「．．．ように構成された（ｃｏｎｆｉｇｕｒｅｄ ｔｏ．．．）」という言葉は、装置の要素が、定義された動作を行うことが可能である構成を有することを意味するために使用される。このコンテキストにおいて、「構成」は、ハードウェア又はソフトウェアの相互接続の配列又は様式を意味する。例えば、装置が、定義された動作を提供する専用ハードウェアを有し得るか、或いは、プロセッサ又は他の処理デバイスが、機能を実施するようにプログラムされ得る。「ように構成された」は、装置要素が定義された動作を提供するために、何らかのやり方で変更されることを必要とすることを暗示しない。

本発明の例示的な実施形態が、添付の図面を参照しながら本明細書では詳細に説明されたが、本発明がそれらの正確な実施形態に限定されないこと、並びに、様々な変更及び修正が、添付の特許請求の範囲及び趣旨によって規定される本発明の範囲から逸脱することなく、当業者によってその中で実施され得ることを理解されたい。

Claims (20)

1. ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための処理回路を備える装置であって、
   所与のベクトル命令に応答して、前記処理回路が、処理の複数のビートを実施するように構成され、各ビートが、前記ベクトル値の一部分に対応する処理を含み、
   前記処理回路は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するように構成され、
   イベントに応答して、前記処理回路が、前記所与のベクトル命令の処理を中断するように構成され、
   前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、前記処理回路が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令の前記ビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成され、
   前記ベクトル値が、前記処理回路にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
   処理の各ビートが、前記データ要素サイズ情報によって示された前記データ要素サイズにかかわらず、前記ベクトル値の固定サイズ部分に対応する処理を含む、
   装置。
2. 前記処理回路が、前記複数のベクトル命令のうちの１つのアドレスを示す復帰アドレスを設定するように構成され、
   前記イベントからの復帰要求に応答して、前記処理回路は、前記復帰アドレス及び前記ビート・ステータス情報に基づいて、処理が再開されるべきであるポイントを識別するように構成された、請求項１に記載の装置。
3. 前記復帰アドレスは、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令のアドレスを示す、請求項２に記載の装置。
4. 前記複数のベクトル命令は、少なくとも１つのビートが依然として完了されるべきである、最も古いベクトル命令と、少なくとも１つの後続のベクトル命令とを含む、請求項１から３のいずれか一項に記載の装置。
5. 前記処理回路が、前記所与のベクトル命令の前記複数のビートの第１のサブセットを完了した後に、前記所与のベクトル命令の前記複数のビートの第２のサブセットを実施するように構成された、請求項１から４のいずれか一項に記載の装置。
6. 前記処理回路が、第２のベクトル命令のためのビートの前記第１のサブセットを実施することと並行して、第１のベクトル命令のためのビートの前記第２のサブセットを実施するように構成された、請求項５に記載の装置。
7. 後続のベクトル命令の第１のビートを開始する前に、１つのベクトル命令のいくつのビートが完了されるべきかを、命令ごとに変化させるための制御回路を備える、請求項１から６のいずれか一項に記載の装置。
8. 前記処理回路が、前記所与のベクトル命令の前記複数のビートのすべてを並行して実施するには不十分なハードウェアを備える、請求項１から７のいずれか一項に記載の装置。
9. 前記処理回路が、前記所与のベクトル命令の前記複数のビートのすべてを並行して実施するのをサポートするように構成されたハードウェアを備える、請求項１から４、６及び７のいずれか一項に記載の装置。
10. 前記処理回路が、前記ビート・ステータス情報を、前記処理回路によって実行されるソフトウェア、例外ハンドラ及びデバッガのうちの少なくとも１つにとってアクセス可能にするように構成された、請求項１から９のいずれか一項に記載の装置。
11. 前記イベントがデバッグ・イベントを含み、前記イベントからの復帰要求がデバッグ状態からの復帰を含む、請求項１から１０のいずれか一項に記載の装置。
12. 前記イベントが例外イベントを含み、前記イベントからの復帰要求が例外復帰を含む、請求項１から１１のいずれか一項に記載の装置。
13. 前記例外イベントが障害イベントを含み、前記障害イベントに応答して、前記処理回路は、前記複数のベクトル命令のうちのどれが、前記障害イベントが検出された、前記所与のベクトル命令であるかを識別する情報を設定するように構成された、請求項１２に記載の装置。
14. 前記例外イベントに応答して、前記処理回路が、前記ビート・ステータス情報へのアクセスを無効化するように構成され、
    前記ビート・ステータス情報にアクセスすることを試みる命令、又は処理の複数のビートを含む少なくとも１つのタイプのさらなるベクトル命令の実行に応答して、前記処理回路が、
    前記ビート・ステータス情報を所定のロケーションに保存すること、又は
    第２の例外イベントを起こすこと
    を行うように構成された、請求項１２又は１３に記載の装置。
15. 前記例外イベントに応答して、前記処理回路が、前記ビート・ステータス情報を、スタック・ポインタ・レジスタによって示された値に対するオフセットにおいてデータ・ストア中のロケーションに保存するように構成された、請求項１２又は１３に記載の装置。
16. 前記処理回路が、少なくともセキュアな状態及びあまりセキュアでない状態を含む複数のセキュリティ状態で動作可能であり、前記例外イベントが、前記セキュアな状態から前記あまりセキュアでない状態への遷移を生じることに応答して、前記処理回路が、前記ビート・ステータス情報をクリアするように構成された、請求項１５に記載の装置。
17. 前記処理回路が、
    処理の所与のビートに対応する宛先ベクトル・レジスタの一部分を更新することを抑制することと、
    処理の前記所与のビートに関連する処理演算を抑制することと
    のうちの１つによって処理の前記所与のビートを抑制するように構成された、請求項１から１６のいずれか一項に記載の装置。
18. ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理するための手段を備える装置であって、
    所与のベクトル命令に応答して、処理するための前記手段が、処理の複数のビートを実施するように構成され、各ビートが、前記ベクトル値の一部分に対応する処理を含み、
    処理するための前記手段は、前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するように構成され、
    イベントに応答して、処理するための前記手段が、前記所与のベクトル命令の処理を中断するように構成され、
    前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、処理するための前記手段が、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令の前記ビートを抑制しながら、前記複数のベクトル命令の処理を再開するように構成され、
    前記ベクトル値が、処理するための前記手段にとってアクセス可能なデータ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
    処理の各ビートが、前記データ要素サイズ情報によって示された前記データ要素サイズにかかわらず、前記ベクトル値の固定サイズ部分に対応する処理を含む、装置。
19. ソース・オペランド及び結果値のうちの少なくとも１つが、複数のデータ要素を含むベクトル値である、ベクトル命令を処理する方法であって、前記方法は、
    所与のベクトル命令に応答して、処理の複数のビートを実施するステップであって、各ビートが、前記ベクトル値の一部分に対応する処理を含む、ステップと、
    前記所与のベクトル命令を含む複数のベクトル命令のどのビートが完了したかを示すビート・ステータス情報を設定するステップと、
    イベントに応答して、前記所与のベクトル命令の処理を中断するステップと、
    前記所与のベクトル命令の処理への復帰を示す、イベントからの復帰要求に応答して、完了したものとして前記ビート・ステータス情報によって示された前記複数のベクトル命令の前記ビートを抑制しながら、前記複数のベクトル命令の処理を再開するステップと
    を含み、
    前記ベクトル値が、データ要素サイズ情報によって指定された複数のデータ要素サイズのうちの１つを有するデータ要素を含み、
    処理の各ビートが、前記データ要素サイズ情報によって示された前記データ要素サイズにかかわらず、前記ベクトル値の固定サイズ部分に対応する処理を含む、方法。
20. 請求項１から１７のいずれか一項に記載の前記装置に対応する、命令実行環境を与えるようにホスト・データ処理装置を制御するためのプログラム命令を含む、仮想マシン・コンピュータ・プログラム。

Images