(57)【特許請求の範囲】
【請求項１】
複数のヘテロジニアス処理要素と、
前記複数のヘテロジニアス処理要素のうちの１又は複数での実行のために命令のディスパッチを行うハードウェアヘテロジニアススケジューラであって、前記命令は、前記複数のヘテロジニアス処理要素のうちの前記１又は複数により処理されるコードフラグメントに対応し、前記命令は、前記複数のヘテロジニアス処理要素の前記１又は複数のうちの少なくとも１つに対するネイティブ命令である、ハードウェアヘテロジニアススケジューラと
を備え、
前記ハードウェアヘテロジニアススケジューラは、コンパイル、組み込み関数、アセンブリ、ライブラリ、中間、オフロード及びデバイスのうちの３つ以上を含む複数のコードタイプをサポートし、
前記ハードウェアヘテロジニアススケジューラは、受信したコードフラグメントを、前記複数のヘテロジニアス処理要素のうちの１又は複数に対してネイティブな他のコードフラグメントにコンバートするコンバータを有するシステム。
【請求項２】
前記複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、請求項１に記載のシステム。
【請求項３】
前記複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、請求項２に記載のシステム。
【請求項４】
前記ハードウェアヘテロジニアススケジューラは、
前記コードフラグメントのプログラムフェーズを検出するプログラムフェーズ検出器をさらに有し、
前記複数のヘテロジニアス処理要素は、第１のマイクロアーキテクチャを有する第１の処理要素、及び、前記第１のマイクロアーキテクチャとは異なる第２のマイクロアーキテクチャを有する第２の処理要素を含み、
前記プログラムフェーズは、第１のフェーズ及び第２のフェーズを含む複数のプログラムフェーズのうちの１つであり、前記命令のディスパッチは、前記検出されたプログラムフェーズに部分的に基づいており、
前記第１の処理要素による前記コードフラグメントの処理は、前記第２の処理要素による前記コードフラグメントの処理と比較してワット性能特性を改善する、請求項１から３のいずれか一項に記載のシステム。
【請求項５】
前記ハードウェアヘテロジニアススケジューラは、
受信した前記コードフラグメントを実行するために、前記複数のヘテロジニアス処理要素についての処理要素のタイプを選択し、ディスパッチを用いて、前記複数のヘテロジニアス処理要素のうち前記選択されたタイプの処理要素に前記コードフラグメントをスケジューリングするセレクタをさらに備える、請求項１から４のいずれか一項に記載のシステム。
【請求項６】
前記コードフラグメントは、ソフトウェアスレッドと関連付けられた１又は複数の命令である、請求項１に記載のシステム。
【請求項７】
データ並列プログラムフェーズの場合、前記選択されたタイプの処理要素は、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、請求項５に記載のシステム。
【請求項８】
データ並列プログラムフェーズの場合、前記選択されたタイプの処理要素は、密な算術のプリミティブをサポートする回路である、請求項５又は７に記載のシステム。
【請求項９】
データ並列プログラムフェーズの場合、前記選択されたタイプの処理要素は、アクセラレータである、請求項５又は７に記載のシステム。
【請求項１０】
データ並列プログラムフェーズは、同じ制御フローを用いて同時に処理される複数のデータ要素を有する、請求項５から９のいずれか一項に記載のシステム。
【請求項１１】
スレッド並列プログラムフェーズの場合、前記選択されたタイプの処理要素は、スカラ処理コアである、請求項５、７、８及び９のいずれか一項に記載のシステム。
【請求項１２】
スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐を有する、請求項５から１１のいずれか一項に記載のシステム。
【請求項１３】
直列プログラムフェーズの場合、前記選択されたタイプの処理要素は、アウトオブオーダコアである、請求項５、７、８、９及び１１のいずれか一項に記載のシステム。
【請求項１４】
データ並列プログラムフェーズの場合、前記選択されたタイプの処理要素は、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、請求項５、７、８、９、１１及び１３のいずれか一項に記載のシステム。
【請求項１５】
前記ハードウェアヘテロジニアススケジューラは、前記選択されたタイプの処理要素が前記コードフラグメントをネイティブに処理できない場合、機能をエミュレートする、請求項５、７、８、９、１１、１３及び１４のいずれか一項に記載のシステム。
【請求項１６】
前記ハードウェアヘテロジニアススケジューラは、利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする、請求項１から１４のいずれか一項に記載のシステム。
【請求項１７】
前記ハードウェアヘテロジニアススケジューラは、前記選択されたタイプの処理要素が前記コードフラグメントをネイティブに処理できない場合、機能をエミュレートする、請求項５、７、８、９、１１、１３、１４及び１５のいずれか一項に記載のシステム。
【請求項１８】
前記複数のヘテロジニアス処理要素についての処理要素のタイプの前記選択は、ユーザに対して透過的である、請求項５、７、８、９、１１、１３、１４、１５及び１７のいずれか一項に記載のシステム。
【請求項１９】
前記複数のヘテロジニアス処理要素についての処理要素のタイプの前記選択は、オペレーティングシステムに対して透過的である、請求項５、７、８、９、１１、１３、１４、１５、１７及び１８のいずれか一項に記載のシステム。
【請求項２０】
前記ハードウェアヘテロジニアススケジューラは、各スレッドがスカラコア上で実行中であるかのようにプログラマに見えるようにするべく、ホモジニアスマルチプロセッサプログラミングモデルを提示する、請求項１から１９のいずれか一項に記載のシステム。
【請求項２１】
前記提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、請求項２０に記載のシステム。
【請求項２２】
前記複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、請求項１から２１のいずれか一項に記載のシステム。
【請求項２３】
前記ハードウェアヘテロジニアススケジューラは、前記複数のヘテロジニアス処理要素のうちの１つで実行されるバイナリトランスレータを含む、請求項１から２２のいずれか一項に記載のシステム。
【請求項２４】
前記複数のヘテロジニアス処理要素の処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、請求項５、７、８、９、１１、１３、１４、１５、１７、１８及び１９のいずれか一項に記載のシステム。
【請求項２５】
前記ハードウェアヘテロジニアススケジューラは、前記ディスパッチされた命令に対してマルチプロトコルバスインタフェースで用いるプロトコルを選択する、請求項１から２４のいずれか一項に記載のシステム。
【請求項２６】
前記マルチプロトコルバスインタフェースによりサポートされる第１のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、請求項２５に記載のシステム。
【請求項２７】
前記マルチプロトコルバスインタフェースによりサポートされる第２のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、請求項２５又は２６に記載のシステム。
【請求項２８】
前記マルチプロトコルバスインタフェースによりサポートされる第３のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、請求項２５から２７のいずれか一項に記載のシステム。
【請求項２９】
前記第３のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス（ＰＣＩｅ）プロトコルを有する、請求項２８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概してコンピューティングデバイスの分野、より具体的には、ヘテロジニアスコンピューティング方法、デバイス及びシステムに関する。
【背景技術】
【０００２】
現在のコンピュータでは、ＣＰＵは、アプリケーションソフトウェア及びオペレーティングシステムを実行するなどの汎用計算タスクを実行する。ある専門分野に特化した計算タスク、例えば、グラフィックス及び画像処理は、グラフィックスプロセッサ、画像プロセッサ、デジタル信号プロセッサ及び固定機能アクセラレータにより処理される。現在のヘテロジニアスマシンでは、各タイプのプロセッサは、様々な態様でプログラミングされる。
【０００３】
ビッグデータ処理の時代では、今日の汎用プロセッサと比較して、より低いエネルギーでより高い性能が求められている。アクセラレータ（例えば、カスタム固定機能ユニット又はオーダーメイドプログラマブルユニットのいずれか一方）は、これらの要求を満足させることに役立っている。この分野は、アルゴリズム及びワークロードの両方において急速な進化を遂げており、利用可能なアクセラレータのセットは、事前に予測することが難しく、製品型内のストックユニットにわたって枝分かれして、製品型と共に進化する可能性が極めて高い。
【図面の簡単な説明】
【０００４】
添付の図面と併せて以下の詳細な説明により、実施形態が容易に理解されるであろう。この説明を容易にするために、同様の参照番号は、同様の構造的要素を指定する。実施形態は、例として示され、添付の図面の図に制限することを目的としたものではない。
【０００５】
【図１】ヘテロジニアスマルチプロセッシングの実行環境を表現したものである。
【０００６】
【図２】ヘテロジニアスマルチプロセッシングの実行環境を表現したものである。
【０００７】
【図３】ヘテロジニアススケジューラの例示的な実装を示す。
【０００８】
【図４】コンピュータシステムのシステムブート及びデバイス発見についての実施形態を示す。
【０００９】
【図５】処理要素の３つのタイプに対するプログラムフェーズのマッピングに基づいたスレッド移行の例を示す。
【００１０】
【図６】ヘテロジニアススケジューラにより実行される例示的な実施フローである。
【００１１】
【図７】ヘテロジニアススケジューラによるスレッド宛先選択のための方法についての例を示す。
【００１２】
【図８】論理ＩＤに対する縞模様マッピングの使用についての概念を示す。
【００１３】
【図９】論理ＩＤに対する縞模様マッピングの使用についての例を示す。
【００１４】
【図１０】コアグループの例を示す。
【００１５】
【図１１】バイナリトランスレータ切替メカニズムを利用するシステムにおけるスレッド実行の方法についての例を示す。
【００１６】
【図１２】アクセラレータに対するホットコードのコア割り当てについての例示的な方法を示す。
【００１７】
【図１３】ページディレクトリベースレジスタイベントに対するウェイクアップ又は書き込みのための可能性があるコア割り当てについての例示的な方法を示す。
【００１８】
【図１４】直列フェーズスレッドの例を示す。
【００１９】
【図１５】スリープコマンドイベントに対するスレッド応答のための潜在的なコア割り当てについての例示的な方法を示す。
【００２０】
【図１６】フェーズ変更イベントに応じたスレッドのための潜在的なコア割り当てについての例示的な方法を示す。
【００２１】
【図１７】加速領域を記述するコードの例を示す。
【００２２】
【図１８】ハードウェアプロセッサコアにおけるＡＢＥＧＩＮを用いた実行についての方法の実施形態を示す。
【００２３】
【図１９】ハードウェアプロセッサコアにおいてＡＥＮＤを用いた実行についての方法の実施形態を示す。
【００２４】
【図２０】パターンマッチングを用いてＡＢＥＧＩＮ／ＡＥＮＤ等価を提供するシステムを示す。
【００２５】
【図２１】パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。
【００２６】
【図２２】パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。
【００２７】
【図２３】メモリ依存性の様々なタイプ、これらのセマンティクス、オーダリング要求及び使用事例を示す。
【００２８】
【図２４】ＡＢＥＧＩＮ命令により指し示されるメモリデータブロックの例を示す。
【００２９】
【図２５】ＡＢＥＧＩＮ／ＡＥＮＤセマンティクスを用いるように構成されるメモリ２５０３の例を示す。
【００３０】
【図２６】ＡＢＥＧＩＮ／ＡＥＮＤを用いた実行についての異なるモードでの動作の方法の例を示す。
【００３１】
【図２７】ＡＢＥＧＩＮ／ＡＥＮＤを用いた実行についての異なるモードでの動作の方法の例を示す。
【００３２】
【図２８】一実施例に関する追加の詳細を示す。
【００３３】
【図２９】アクセラレータの実施形態を示す。
【００３４】
【図３０】マルチプロトコルリンクを介してプロセッサに結合されるアクセラレータ及び１又は複数のコンピュータプロセッサチップを含むコンピュータシステムを示す。
【００３５】
【図３１】実施形態に係るデバイスバイアスフローを示す。
【００３６】
【図３２】一実施例に従う例示的な処理を示す。
【００３７】
【図３３】オペランドが１又は複数のＩ／Ｏデバイスから解放される場合の処理を示す。
【００３８】
【図３４】２つの異なるタイプのワークキューを用いた実施例を示す。
【００３９】
【図３５】Ｉ／Ｏファブリックインタフェースを介してサブミットされた記述子をＲＥＣＥＩＶＥする複数のワークキューを有するデータストリーミングアクセラレータ（ＤＳＡ）デバイスの実施例を示す。
【００４０】
【図３６】２つのワークキューを示す。
【００４１】
【図３７】エンジン及びグループ化を用いた別の構成を示す。
【００４２】
【図３８】記述子の実施例を示す。
【００４３】
【図３９】完了記録の実施例を示す。
【００４４】
【図４０】例示的な非ｏｐ記述子及びｎｏ−ｏｐ完了記録を示す。
【００４５】
【図４１】例示的なバッチ記述子及びｎｏ−ｏｐ完了記録を示す。
【００４６】
【図４２】例示的なドレイン記述子及びドレイン完了記録を示す。
【００４７】
【図４３】例示的なメモリ移動記述子及びメモリ移動完了記録を示す。
【００４８】
【図４４】例示的なフィル記述子を示す。
【００４９】
【図４５】例示的な比較記述子及び比較完了記録を示す。
【００５０】
【図４６】例示的な比較中間記述子を示す。
【００５１】
【図４７】例示的な作成データ記録記述子及び作成差分記録完了記録を示す。
【００５２】
【図４８】差分記録のフォーマットを示す。
【００５３】
【図４９】例示的な適合差分記録記述子を示す。
【００５４】
【図５０】作成差分記録及び適合差分記録オペレーションの利用についての一実施例を示す。
【００５５】
【図５１】例示的なデュアルキャストを用いたメモリコピー記述子及びデュアルキャストを用いたメモリコピー完了記録を示す。
【００５６】
【図５２】例示的なＣＲＣ生成記述子及びＣＲＣ生成を示す。
【００５７】
【図５３】ＣＲＣ生成記述子を用いた例示的なコピーを示す。
【００５８】
【図５４】例示的なＤＩＦ挿入記述子及びＤＩＦ挿入完了記録を示す。
【００５９】
【図５５】例示的なＤＩＦストリップ記述子及びＤＩＦストリップ完了記録を示す。
【００６０】
【図５６】例示的なＤＩＦ更新記述子及びＤＩＦ更新完了記録を示す。
【００６１】
【図５７】例示的なキャッシュフラッシュ記述子を示す。
【００６２】
【図５８】ＥＮＱＣＭＤにより生成された６４バイトのエンキュー格納データを示す。
【００６３】
【図５９】ＭＯＶＤＩＲＩ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００６４】
【図６０】ＭＯＶＤＩＲＩ６４Ｂ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００６５】
【図６１】ＥＮＣＱＭＤ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００６６】
【図６２】ＥＮＱＣＭＤＳ命令に関するフォーマットを示す。
【００６７】
【図６３】ＥＮＣＱＭＤ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００６８】
【図６４】ＵＭＯＮＩＴＯＲ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００６９】
【図６５】ＵＭＷＡＩＴ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００７０】
【図６６】ＴＰＡＵＳＥ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【００７１】
【図６７】ＵＭＷＡＩＴ及びＵＭＯＮＩＴＯＲ命令を用いた実行の例を示す。
【００７２】
【図６８】ＴＰＡＵＳＥ及びＵＭＯＮＩＴＯＲ命令を用いた実行の例を示す。
【００７３】
【図６９】アクセラレータがキャッシュコヒーレントインタフェースを通じて複数のコアに通信可能に結合される例示的な実装を示す。
【００７４】
【図７０】データ管理ユニット、複数の処理要素及び高速オンチップストレージを含むアクセラレータ及び前述の他のコンポーネントの別の図を示す。
【００７５】
【図７１】処理要素により実行された処理の例示的なセットを示す。
【００７６】
【図７２ａ】ベクトルｙを生成するために、ベクトルｘに対する疎行列間の乗算の例を図示する。
【００７７】
【図７２ｂ】各値が（値、行インデックス）ペアとして格納される行列ＡのＣＳＲ表現を示す。
【００７８】
【図７２ｃ】（値、列インデックス）ペアを用いる行列ＡのＣＳＣ表現を示す。
【００７９】
【図７３ａ】計算パターンの擬似コードを示す。
【図７３ｂ】計算パターンの擬似コードを示す。
【図７３ｃ】計算パターンの擬似コードを示す。
【００８０】
【図７４】データ管理ユニット及び処理要素の一実施例に関する処理フローを示す。
【００８１】
【図７５ａ】ｓｐＭｓｐＶ＿ｃｓｃ及びｓｃａｌｅ＿ｕｐｄａｔｅ演算に関するパスを（点線を用いて）強調表示する。
【００８２】
【図７５ｂ】ｓｐＭｄＶ＿ｃｓｒ演算に関するパスを示す。
【００８３】
【図７６ａ】隣接行列としてのグラフを表す例を示す。
【図７６ｂ】隣接行列としてのグラフを表す例を示す。
【００８４】
【図７６ｃ】頂点プログラムを示す。
【００８５】
【図７６ｄ】頂点プログラムを実行するための例示的なプログラムコードを示す。
【００８６】
【図７６ｅ】ＧＳＰＭＶの定式化を示す。
【００８７】
【図７７】フレームワークを示す。
【００８８】
【図７８】カスタマイズ可能な論理ブロックが各ＰＥ内に提供されることを示す。
【００８９】
【図７９】各アクセラレータタイルの処理を示す。
【００９０】
【図８０ａ】テンプレートの一実施例についてのカスタマイズ可能なパラメータを要約したものである。
【００９１】
【図８０ｂ】チューニング検討事項を示す。
【００９２】
【図８１】最も一般的な疎行列フォーマットの１つを示す。
【００９３】
【図８２】ＣＲＳデータフォーマットを用いた疎行列−密ベクトル乗算についての実施例に関する段階を示す。
【００９４】
【図８３】アクセラレータ論理ダイと、ＤＲＡＭの１又は複数のスタックとを含むアクセラレータについての実施例を示す。
【００９５】
【図８４ａ】上部視点からＤＲＡＭダイのスタックの方を向いたアクセラレータ論理チップの一実施例を示す。
【図８４ｂ】上部視点からＤＲＡＭダイのスタックの方を向いたアクセラレータ論理チップの一実施例を示す。
【００９６】
【図８５】ＤＰＥの大まかな概観図を提供する。
【００９７】
【図８６】ブロッキングスキームの実施例を示す。
【００９８】
【図８７】ブロック記述子を示す。
【００９９】
【図８８】単一のドット積エンジンのバッファ内に合致する２行行列を示す。
【０１００】
【図８９】このフォーマットを用いるドット積エンジン内のハードウェアの一実施例を示す。
【０１０１】
【図９０】キャプチャを行うマッチ論理ユニットの内容を示す。
【０１０２】
【図９１】実施例に係る疎行列−疎ベクトル乗算をサポートするドット積エンジン設計の詳細を示す。
【０１０３】
【図９２】特定の値を用いる例を示す。
【０１０４】
【図９３】計算の両方のタイプを処理できるドット積エンジンを生じさせるように、疎−密及び疎−疎ドット積エンジンがどのように組み合わられるかを示す。
【０１０５】
【図９４ａ】１２個のアクセラレータスタックを用いたソケット交換の実施を示す。
【０１０６】
【図９４ｂ】プロセッサ／コアのセット及び８つのスタックを用いたマルチチップパッケージ（ＭＣＰ）実装を示す。
【０１０７】
【図９５】アクセラレータスタックを示す。
【０１０８】
【図９６】６４個のドット積エンジン、８つのベクトルキャッシュ及び統合メモリコントローラを含むＷＩＯ３  ＤＲＡＭスタックの下に位置することが意図されるアクセラレータの潜在的なレイアウトを示す。
【０１０９】
【図９７】７つのＤＲＡＭ技術を比較したものである。
【０１１０】
【図９８ａ】スタック型ＤＲＡＭを示す。
【図９８ｂ】スタック型ＤＲＡＭを示す。
【０１１１】
【図９９】幅優先探索（ＢＦＳ）のリストを示す。
【０１１２】
【図１００】一実施例に従うラムダ関数を規定するために用いられる記述子のフォーマットを示す。
【０１１３】
【図１０１】実施形態におけるヘッダワードの下位６バイトを示す。
【０１１４】
【図１０２】行列値バッファ、行列インデックスバッファ及びベクトル値バッファを示す。
【０１１５】
【図１０３】ラムダデータパスの一実施例の詳細を示す。
【０１１６】
【図１０４】命令エンコーディングの実施例を示す。
【０１１７】
【図１０５】ある特定の命令のセットに対するエンコーディングを示す。
【０１１８】
【図１０６】例示的な比較述語のエンコーディングを示す。
【０１１９】
【図１０７】バイアスを用いた実施形態を示す。
【０１２０】
【図１０８ａ】ワークキューベースの実装と共に用いられるメモリマッピングされたＩ／Ｏ（ＭＭＩＯ）空間レジスタを示す。
【図１０８ｂ】ワークキューベースの実装と共に用いられるメモリマッピングされたＩ／Ｏ（ＭＭＩＯ）空間レジスタを示す。
【０１２１】
【図１０９】行列の乗算の例を示す。
【０１２２】
【図１１０】２分木低減ネットワークを用いたｏｃｔｏＭＡＤＤ命令処理を示す。
【０１２３】
【図１１１】積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【０１２４】
【図１１２】積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【０１２５】
【図１１３（Ａ）】ＭＡＤＤ命令を実行するための例示的なハードウェアを示す。
【図１１３（Ｂ）】ＭＡＤＤ命令を実行するための例示的なハードウェアを示す。
【図１１３（Ｃ）】ＭＡＤＤ命令を実行するための例示的なハードウェアを示す。
【０１２６】
【図１１４】ハードウェアヘテロジニアススケジューラ回路及びメモリとのそのインタラクションの例を示す。
【０１２７】
【図１１５】ソフトウェアヘテロジニアススケジューラの例を示す。
【０１２８】
【図１１６】ポストシステムブートデバイス発見のための方法の実施形態を示す。
【０１２９】
【図１１７】共有メモリ内のスレッドに対する移動の例を示す。
【０１３０】
【図１１８】ヘテロジニアススケジューラにより実行され得るスレッド移動のための例示的な方法を示す。
【０１３１】
【図１１９】詳細に上述されたように、抽象実行環境を提示するプロセッサのブロック図である。
【０１３２】
【図１２０】例示的なマルチチップ構成を示す簡易ブロック図である。
【０１３３】
【図１２１】マルチチップリンク（ＭＣＬ）の例示的な実装を含むシステムの少なくとも一部を表すブロック図を示す。
【０１３４】
【図１２２】例示的なＭＣＬの例示的な論理ＰＨＹのブロック図を示す。
【０１３５】
【図１２３】ＭＣＬを実装するために用いられる論理の別の表現を示すことを簡易ブロック図が示されることを図示する。
【０１３６】
【図１２４】ＡＢＥＧＩＮ／ＡＥＮＤがサポートされていない場合の実行の例を示す。
【０１３７】
【図１２５】本発明の一実施形態に係るレジスタアーキテクチャのブロック図である。
【０１３８】
【図１２６Ａ】本発明の実施形態に係る、例示的なインオーダパイプライン及び例示的なレジスタリネーミング・アウトオブオーダ発行／実行パイプラインの両方を示すブロック図である。
【０１３９】
【図１２６Ｂ】本発明の実施形態に係るプロセッサに含まれるインオーダアーキテクチャコアの例示的な実施形態及び例示的なレジスタリネーミング・アウトオブオーダ発行／実行アーキテクチャコアの両方を示すブロック図である。
【０１４０】
【図１２７Ａ】より具体的な例示的インオーダコアアーキテクチャのブロック図を示し、コアは、チップ内の（同じタイプ及び／又は異なるタイプの他のコアを含む）いくつかの論理ブロックのうちの１つであろう。
【図１２７Ｂ】より具体的な例示的インオーダコアアーキテクチャのブロック図を示し、コアは、チップ内の（同じタイプ及び／又は異なるタイプの他のコアを含む）いくつかの論理ブロックのうちの１つであろう。
【０１４１】
【図１２８】本発明の実施形態に係る、１つより多くのコアを有してよく、統合メモリコントローラを有してよく、かつ、統合グラフィックスを有してよいプロセッサのブロック図である。
【０１４２】
【図１２９】本発明の実施形態に係るシステムのブロック図を示す。
【０１４３】
【図１３０】本発明の実施形態に係る第１のより具体的な例示的システムのブロック図である。
【０１４４】
【図１３１】本発明の実施形態に係る第２のより具体的な例示的システムのブロック図である。
【０１４５】
【図１３２】本発明の実施形態に従うＳｏＣのブロック図である。
【０１４６】
【図１３３】本発明の実施形態に係る、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令変換器の使用を対比するブロック図である。
【発明を実施するための形態】
【０１４７】
以下の詳細な説明では、本明細書の一部を形成する添付の図面への参照が行われ、同様の符号が全体を通じて同様の部品を指し、実践され得る例示的な実施形態を用いて示される。他の実施形態が利用されてよく、構造的又は論理的な変更が本開示の範囲から逸脱することなく行われてよいことが理解されるべきである。したがって、以下の詳細な説明は、限定的な意味にとられるべきでなく、実施形態の範囲は、添付の特許請求の範囲及びこれらの同等物により規定される。
【０１４８】
様々なオペレーションが、特許請求の範囲に記載の主題を理解する際に最も役立つ態様で、複数の別個の動作又は処理として順番に説明され得る。しかしながら、説明の順序は、これらの処理が必然的に順序に依存することを示唆するものとして解釈されるべきではない。特に、これらの処理は、提示の順序で実行されないくてもよい。説明される処理は、説明される実施形態とは異なる順序で実行されてよい。追加の実施形態では、様々な追加の処理が実行されてよく、及び／又は、説明される処理が省略されてもよい。
【０１４９】
本開示の目的のために、「Ａ及び／又はＢ」という用語は、（Ａ）、（Ｂ）又は（Ａ及びＢ）を意味する。本開示の目的のために、「Ａ、Ｂ及び／又はＣ」という用語は、（Ａ）、（Ｂ）、（Ｃ）、（Ａ及びＢ）、（Ａ及びＣ）、（Ｂ及びＣ）又は（Ａ、Ｂ及びＣ）を意味する。
【０１５０】
説明では、「一実施形態において」又は「複数の実施形態において」という用語を用いてよく、同じ又は異なる実施形態のうちの１又は複数をそれぞれ指し得る。さらに、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」及び「有する（ｈａｖｉｎｇ）」などの用語は、本開示の実施形態に関して用いられる場合、同義である。
【０１５１】
背景技術に記載したように、アクセラレータの様々な混合を実装する幅広いストックユニット及びプラットフォームがあるので、アクセラレータの解決手段を展開し、ポータブルに利用するアクセラレータの複雑性を管理することは困難であり得る。さらに、非常に多数のオペレーティングシステム（及びバージョン、パッチなど）を考慮すると、デバイスドライバモデルを用いてアクセラレータを配置するには、ビッグデータ処理についての開発者の取り組み、非移植性及び厳密な性能要件に起因する採用に対するハードルを含む制限がある。アクセラレータは、典型的には、汎用プロセッサ上で実行するソフトウェアよりも効率的に機能を実行するハードウェアデバイス（回路）である。例えば、ハードウェアアクセラレータは、特定のアルゴリズム／タスク（例えば、ビデオエンコーディング又はデコーディング、特定のハッシュ関数など）、又は、アルゴリズム／タスクのクラス（例えば、機械学習、疎データ操作、暗号化、グラフィックス、物理学、正規表現、パケット処理、人工知能、デジタル信号プロセッシングなど）の実行を改善するために用いられ得る。アクセラレータの例は、限定されることはないが、グラフィックス処理ユニット（「ＧＰＵ」）、固定機能フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）アクセラレータ、及び、固定機能特定用途向け集積回路（「ＡＳＩＣ」）を含む。アクセラレータは、いくつかの実施例において、ＣＰＵがシステム内の他のプロセッサよりも効率的である場合、汎用の中央処理装置（「ＣＰＵ」）であってよいことに留意する。
【０１５２】
所与のシステム（例えば、システムオンチップ（「ＳｏＣ」）、プロセッサストックユニット、ラックなど）の電力量は、利用可能なシリコンエリアの一部上のみで処理要素により消費され得る。これは、たとえ、ハードウェアブロックのすべてが同時にアクティブになり得ることはないとしても、特定の処理に対するエネルギー消費を低減する様々な特化型のハードウェアブロックを構築することを有利にする。
【０１５３】
スレッドを処理する処理要素（例えば、コア又はアクセラレータ）を選択し、処理要素とインタフェース接続し、及び／又は、ヘテロジニアマルチプロセッサ環境内の電力消費を管理するためのシステム、方法及び装置の実施形態が詳細に説明される。例えば、様々な実施形態において、ヘテロジニアマルチプロセッサは、スレッド及び／又は処理要素の対応するワークロードの特性に基づいて、ヘテロジニアマルチプロセッサの異なるタイプの処理要素間でスレッドを動的に移行し、処理要素の１又は複数にプログラムインタフェースを提供し、特定の処理要素上での実行のためのコードを変換し、ワークロード及び選択された処理要素又はこれらの組み合わせについての特性に基づいて、選択された処理要素と共に用いる通信プロトコルを選択するように、（例えば、設計により、又は、ソフトウェアにより）構成される。
【０１５４】
第１態様において、ワークロードディスパッチインタフェース、すなわち、ヘテロジニアススケジューラは、ホモジニアスマルチプロセッサプログラミングモデルをシステムプログラマに提示する。特に、この態様では、プログラマが特定のアーキテクチャをターゲットとするソフトウェア又は同等の抽象化を開発することを可能にし得る一方、開発されるソフトウェアへの対応する変更を要求することなく、基礎となるハードウェアに対する連続的な改善を容易する。
【０１５５】
第２態様において、マルチプロトコルリンクは、第１のエンティティ（ヘテロジニアススケジューラなど）が、通信と関連付けられたプロトコルを用いて、多数のデバイスと通信することを可能にする。これは、デバイス通信用に別々のリンクを有する必要性に取って代わるものである。特に、このリンクは、リンク上で動的に多重化される３又はそれより多いプロトコルを有する。例えば、共通のリンクは、１）１又は複数の独自又は業界標準（例えば、ＰＣＩエクスプレス仕様又は同等の代替手段など）において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、ＤＭＡスタイルのデータ転送及び様々なサービスを可能にする生産者／消費者、発見、構成、割込み（ＰＤＣＩ）プロトコル、２）デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス（ＣＡＣ）プロトコル、及び、３）処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス（ＭＡ）プロトコルからなるプロトコルをサポートする。
【０１５６】
第３態様において、スレッドのスケジューリング、移行若しくはエミュレーション、又は、これらの一部が、スレッドのフェーズに基づいて行われる。例えば、スレッドのデータ並列フェーズは、典型的には、スケジューリングされ、又は、ＳＩＭＤコアに移行され、スレッドのスレッド並列フェーズは、典型的には、スケジューリングされ、又は、１又は複数のスカラコアに移行され、直列フェーズは、典型的には、スケジューリングされ、又は、アウトオブオーダコアに移行される。コアタイプのそれぞれは、両方ともスレッドのスケジューリング、移行又はエミュレーションについて考慮されるエネルギー又はレイテンシのいずれか一方を最小化する。エミュレーションは、スケジューリング又は移行が可能でない又は有利でない場合に用いられてよい。
【０１５７】
第４態様において、スレッド又はこれらの一部は、オポチュニスティックに（ｏｐｐｏｒｔｕｎｉｓｔｉｃａｌｌｙ）、アクセラレータへオフロードされる。特に、スレッドのアクセラレータ開始（ＡＢＥＧＩＮ）命令及びアクセラレータ終了（ＡＥＮＤ）命令又はこれらの一部、ブックエンド命令が、アクセラレータ上で実行可能であり得る。アクセラレータが利用可能でない場合、次に、ＡＢＥＧＩＮとＡＥＮＤとの間の命令が通常通り実行される。しかしながら、アクセラレータが利用可能である場合、アクセラレータを用いる（例えば、少ない電力を用いる）ことが好ましく、次に、ＡＢＥＧＩＮとＡＥＮＤ命令との間の命令は、そのアクセラレータ上で実行するために変換され、そのアクセラレータの実行のためにスケジューリングされる。その結果、アクセラレータの使用はオポチュニスティックである。
【０１５８】
第５態様において、スレッド又はその一部は、ＡＢＥＧＩＮ又はＡＥＮＤを用いることなく、アクセラレータに（オポチュニスティックな）オフロードのために解析される。ソフトウェア又はハードウェアパターンマッチは、アクセラレータ上で実行可能であり得るコード用に、スレッド又はその一部に対して実行される。アクセラレータが利用可能でない場合、又は、スレッド又はその一部それ自体がアクセラレータの実行に役立たない場合、スレッドの命令は、通常通りに実行される。しかしながら、アクセラレータが利用可能である場合、アクセラレータを用いる（例えば、少ない電力を用いる）ことが好ましく、次に、命令は、そのアクセラレータで実行するために変換され、そのアクセラレータ上での実行のためにスケジューリングされる。その結果、アクセラレータの使用はオポチュニスティックである。
【０１５９】
第６態様において、選択された宛先処理要素をより良く適合させるコードフラグメント（スレッドの一部）の変換が実行される。例えば、コードフラグメントは、１）異なる命令セットを利用するために変換され、２）より多く並列化され、３）あまり並列化されず（直列化され）、４）データを並列化し（例えば、ベクトル化され）、及び／又は、５）データをあまり並列化しない（例えば、非ベクトル化される）。
【０１６０】
第７態様において、（共有又は専用のいずれか一方の）ワークキューは、デバイスにより行われるワークの範囲を定義する記述子を受信する。専用のワークキューは、単一のアプリケーション用の記述子を格納する一方、共有のワークキューは、複数のアプリケーションによりサブミットされる記述子を格納する。ハードウェアインタフェース／アービタは、特定のアービトレーションポリシに従って（例えば、各アプリケーション及びＱｏＳ／公平性ポリシの処理要件に基づいて）、記述子をワークキューからアクセラレータ処理エンジンにディスパッチする。
【０１６１】
第８態様において、密行列乗算に対する改善は、単一の命令の実行と共に２次元行列の乗算を考慮する。複数のパックドデータ（ＳＩＭＤ、ベクトル）ソースは、単一のパックドデータソースに対して乗算される。いくつかの例において、２分木が乗算に用いられる。
【０１６２】
図１は、ヘテロジニアスマルチプロセッシングの実行環境を表現したものである。この例において、第１のタイプのコードフラグメント（例えば、ソフトウェアスレッドと関連付けられた１又は複数の命令）がヘテロジニアススケジューラ１０１により受信される。コードフラグメントは、任意の数のソースコード表現の形式であってよく、例えば、マシンコード、中間表現、バイトコード、テキストベースのコード（高水準言語、例えばＣ＋＋などのアセンブリコード、ソースコード）などを含む。ヘテロジニアススケジューラ１０１は、（例えば、すべてのスレッドがスカラコア上で実行中であるかのように、それらがユーザ及び／又はオペレーティングシステムに見えるように）ホモジニアスマルチプロセッサプログラミングモデルを提示し、受信したコードフラグメントに関するワークロードタイプ（プログラムフェーズ）を判断し、判断したワークロードタイプに対応する処理要素のタイプ（スカラ、アウトオブオーダ（ＯＯＯ）、単一命令複数データ（ＳＩＭＤ）又はアクセラレータを選択して、ワークロード（例えば、スレッド並列コード用のスカラ、直列コード用のＯＯＯ、データ並列用のＳＩＭＤ、及び、データ並列用のアクセラレータ）を処理し、対応する処理要素による処理のためにコードフラグメントをスケジューリングする。図１に示される特定の実施例において、処理要素タイプは、スカラコア１０３（例えば、インオーダコア）、連続的に格納された複数のデータ要素をレジスタが有するパックドデータオペランドに対して演算を行う単一命令複数データ（ＳＩＭＤ）コア１０５、低レイテンシのアウトオブオーダコア１０７及びアクセラレータ１０９を含む。いくつかの実施形態において、スカラコア１０３、単一命令複数データ（ＳＩＭＤ）コア１０５、低レイテンシのアウトオブオーダコア１０７は、ヘテロジニアプロセッサ内にあり、アクセラレータ１０９は、このヘテロジニアプロセッサの外部にある。しかしながら、処理要素の様々な異なる構成が利用されてよいことに留意されたい。いくつかの実施例において、ヘテロジニアススケジューラ１０１は、受信したコードフラグメント又はその一部を、処理要素の選択されたタイプに対応するフォーマットに変換又は解釈する。
【０１６３】
処理要素１０３〜１０９は、異なる命令セットアーキテクチャ（ＩＳＡ）をサポートしてよい。例えば、アウトオブオーダコアは、第１のＩＳＡをサポートしてよく、インオーダコアは、第２のＩＳＡをサポートしてよい。この第２のＩＳＡは、第１のＩＳＡの（サブ又はスーパー）セットであってよく、又は、異なっていてもよい。さらに、処理要素は、異なるマイクロアーキテクチャを有してよい。例えば、第１のアウトオブオーダコアは、第１のマイクロアーキテクチャをサポートし、インオーダコアは、異なる第２のマイクロアーキテクチャをサポートする。たとえ処理要素の特定のタイプ内であったとしても、ＩＳＡ及びマイクロアーキテクチャは、異なっていてもよいことに留意する。例えば、第１のアウトオブオーダコアは、第１のマイクロアーキテクチャをサポートしてよく、第２のアウトオブオーダコアは、異なるマイクロアーキテクチャをサポートしてよい。命令は、それらがＩＳＡの一部であるという点で、特定のＩＳＡに対して「ネイティブ」である。ネイティブ命令は、外部の変更（例えば、変換）を必要とすることなく、特定のマイクロアーキテクチャで実行する。
【０１６４】
いくつかの実施例では、処理要素の１又は複数は、例えば、システムオンチップ（ＳｏＣ）として、単一のダイに統合される。そのような実施例では、例えば、改善された通信レイテンシ、製造／コスト、低減されたピンカウント、プラットフォームの小型化などからの利益を得る場合がある。他の実施例では、処理要素は、まとめてパッケージ化され、それにより、単一のダイにある必要はなく、上記で参照したＳｏＣの利益の１又は複数を実現する。これらの実施例は、例えば、処理要素タイプ毎に最適化される異なる処理技術、歩留まり向上のためのより小さいダイサイズ、所有の知的財産ブロックの統合などからさらなる利益を得てよい。いくつかの従来のマルチパッケージ制限では、異なるデバイスが追加されるときに、それらと通信することが困難であるかもしれない。本明細書で説明されるマルチプロトコルリンクは、異なるタイプのデバイスに共通のインタフェースをユーザ、オペレーティングシステム（「ＯＳ」）などに提示することにより、この課題を最小化又は緩和する。
【０１６５】
いくつかの実施例において、ヘテロジニアススケジューラ１０１は、プロセッサコア（例えば、ＯＯＯコア１０７）での実行のために、コンピュータ可読媒体（例えば、メモリ）に格納されたソフトウェアにおいて実装される。これらの実施例において、ヘテロジニアススケジューラ１０１は、ソフトウェアヘテロジニアススケジューラと称される。このソフトウェアは、バイナリトランスレータ、実行時（「ＪＩＴ」）コンパイラ、コードフラグメントを含むスレッドの実行をスケジューリングするＯＳ１１７、パターンマッチャ、内部モジュールコンポーネント又はこれらの組み合わせを実装してよい。
【０１６６】
いくつかの実施例では、ヘテロジニアススケジューラ１０１は、回路及び／又は回路により実行される有限ステートマシンとして、ハードウェア内に実装される。これらの実施例では、ヘテロジニアススケジューラ１０１は、ハードウェアヘテロジニアススケジューラと称される。
【０１６７】
プログラム（例えば、ＯＳ１１７、エミュレーション層、ハイパーバイザ、セキュアモニタなど）の観点から、各タイプの処理要素１０３−１０９は、共有メモリアドレス空間１１５を利用する。いくつかの実施例において、共有メモリアドレス空間１１５は、図２に示されるように、２つのタイプのメモリ、メモリ２１１及びメモリ２１３を選択的に有する。そのような実施例において、メモリのタイプは、限定されることはないが、メモリ位置における差（例えば、異なるソケット上に配置される、など）、対応するインタフェース標準における差（例えば、ＤＤＲ４、ＤＤＲ５など）、所要電力における差、及び／又は、使用される基礎となるメモリ技術における差（例えば、高帯域幅メモリ（ＨＢＭ）、シンクロナスＤＲＡＭなど）を含む様々な方式で区別されてよい。
【０１６８】
共有メモリアドレス空間１１５は、各タイプの処理要素によりアクセス可能である。しかしながら、いくつかの実施形態において、例えば、ワークロードの必要性に基づいて、異なるタイプのメモリが異なる処理要素に対して優先的に割り当てられてよい。例えば、いくつかの実施例では、プラットフォームのファームウェアインタフェース（例えば、ＢＩＯＳ又はＵＥＦＩ）又はメモリストレージは、プラットフォームにおいて利用可能なメモリリソースのタイプ、及び／又は、特定のアドレス範囲又はメモリタイプに関する処理要素の共通性を示すフィールドを含む。
【０１６９】
ヘテロジニアススケジューラ１０１は、スレッドが所与の時点のどこで実行されるかを判断するためにスレッドを解析する場合、この情報を利用する。典型的には、スレッド管理メカニズムは、既存のスレッドを管理する方法に応じて、情報に基づいた決定を通知するために、それに利用可能な情報の全体を調べる。これは、多数の方式でそれ自体を明らかにし得る。例えば、処理要素に対して物理的に近いアドレス範囲の共通性を有する特定の処理要素上で実行するスレッドは、処理要素上で実行されるであろう通常状況の下、スレッドにわたる優先処理を与え得る。
【０１７０】
別の例は、特定のメモリタイプ（例えば、ＤＲＡＭのより高速なバージョン）から利益を得るであろうスレッドは、そのデータをメモリタイプに物理的に移動させ、コード内のメモリ参照を共有アドレス空間の一部を指し示すように調整させ得るということである。例えば、ＳＩＭＤコア１０５上のスレッドが第２のメモリタイプ２１３を利用し得る一方、それは、アクセラレータ１０９がアクティブであり、そのメモリタイプ２１３を必要とする（又は、ＳＩＭＤコア１０５のスレッドに割り当てられた部分を少なくとも必要とする）場合、この利用から移動させてもよい。
【０１７１】
例示的なシナリオは、メモリが一方よりも他方の処理要素に物理的に近い場合である。よくある例は、アクセラレータがコアとは異なるメモリタイプに直接接続されている場合である。
【０１７２】
これらの例では、典型的には、データ移動を開始するＯＳである。しかしながら、下位レベル（例えば、ヘテロジニアススケジューラ）が、独自で又は別のコンポーネント（例えば、ＯＳ）からの支援を伴ってこの機能を実行することを拒むものは何もない。前の処理要素のデータががフラッシュされ、ページテーブルエントリが無効にされるか否かは、データ移動を行うための実装及び不利益に依存する。データが、すぐ用いられる可能性が高くはない場合、一方のメモリタイプから他方にデータを移動するよりも、むしろストレージから単にコピーした方がより実現可能であるかもしれない。
【０１７３】
図１１７の（Ａ）〜（Ｂ）は、共有メモリ内のスレッドに対する移動の例を示す。この例では、２つのタイプのメモリは、それぞれがその空間内のアドレスの独自の範囲を有するアドレス空間を共有する。１１７の（Ａ）において、共有メモリ１１７１５は、第１のタイプのメモリ１１７０１及び第２のタイプのメモリ１１７０７を含む。第１のタイプのメモリ１１７０１は、第１のアドレス範囲１１７０３を有し、スレッド１  １１７０５に専用のアドレスである範囲内にある。第２のタイプのメモリ１１７０７は、第２のアドレス範囲１１７０９を有する。
【０１７４】
スレッド１  １１７０５の実行中のいくつかの時点で、ヘテロジニアススケジューラは、第２のスレッド１１７１１が、スレッド１  １１７０５に割り当てられる前に、第１のタイプのメモリ１１７０１内のアドレスを用いるように、スレッド１  １１７０５を移動することの決定を行う。これは、図１１７の（Ｂ）に示されている。この例では、スレッド１  １１７０５は、第２のタイプのメモリ１１７０７に再割り当てされ、用いるためのアドレスの新たなセットが与えられる。しかしながら、これは、該当のケースである必要はない。メモリのタイプの差が、（例えば、ＰＥへの距離に基づいて）物理的又は空間的であってよいことに留意する。
【０１７５】
図１１８は、ヘテロジニアススケジューラにより実行され得るスレッド移動のための例示的な方法を示す。１１８０１において、第１のスレッドは、共有メモリ空間内の第１のタイプのメモリを用いて、コア又はアクセラレータなどの第１の処理要素（「ＰＥ」）上で実行されるよう指示される。例えば、図１１７の（Ａ）において、これは、スレッド１である。
【０１７６】
後のいくつかの時点で、第２のスレッドを実行する要求が１１８０３において受信される。例えば、アプリケーション、ＯＳなどは、実行されるハードウェアスレッドを要求する。
【０１７７】
１１８０５において、共有アドレス空間内の第１のタイプのメモリを用いる第２のＰＥで第２のスレッドが実行されるべきとの判断が行われる。例えば、第２のスレッドは、第１のタイプのメモリに直接結合されるアクセラレータ上で実行され、当該実行（第１のスレッドが使用しているメモリを解放することを含む）は、第２のスレッドに第２のタイプのメモリを使用させるよりも効率的である。
【０１７８】
いくつかの実施形態では、１１８０７において、第１のスレッドのデータが第１のタイプのメモリから第２のタイプのメモリに移動される。これは、第１のスレッド実行の実行を単に停止して、その配置において別のスレッドを開始することがより効率的である場合に、必ずしも発生するわけではない。
【０１７９】
１１８０９において、第１のスレッドと関連付けられたトランスレーションルックアサイドバッファ（ＴＬＢ）エントリが無効にされる。さらに、最も多くの実施形態では、データのフラッシュが実行される。
【０１８０】
１１８１１において、第２のスレッドは、第２のＰＥに向けられ、第１のスレッドに対して前に割り当てられていた第１のタイプのメモリ内のアドレスの範囲に割り当てられる。
【０１８１】
図３は、ヘテロジニアススケジューラ３０１の例示的な実施例を示す。いくつかの例において、スケジューラ３０１は、ランタイムシステムの一部である。図示されるように、プログラムフェーズ検出器３１３は、コードフラグメントを受信し、対応するプログラムフェーズの実行が、直列、データ並列又はスレッド並列として最良の特徴であるか否かを判断するために、コードフラグメントの１又は複数の特性を識別する。これが判断される方法の例が以下に詳細に説明される。図１に関して詳細に説明したように、コードフラグメントは、任意の数のソースコード表現の形式であってよい。
【０１８２】
反復的コードフラグメントについて、パターンマッチャ３１１は、この「ホット」コードを識別し、さらに、いくつかの例においては、コードフラグメントと関連付けられたワークロードが、異なる処理要素で処理するためにより適し得ることを示す対応する特性も識別する。パターンマッチャ３１１及びその動作に関するさらなる詳細は、例えば、図２０の文脈において以下で説明される。
【０１８３】
セレクタ３０９は、処理要素の特性と、電源マネージャ３０７により提供された熱及び／又は電力情報とに少なくとも部分的に基づいて、受信したコードフラグメントのネイティブ表現を実行するターゲット処理要素を選択する。当該ターゲット処理要素の選択は、コードフラグメントに対して最も適合するもの（すなわち、ワークロード特性と処理要素機能との間のマッチ）をできるだけ簡単に選択し得るが、システムの現在の電力消費レベル（例えば、電源マネージャ３０７により提供され得る場合）、処理要素の可用性、一方のタイプのメモリから他方へ移動するデータ量（及び、そのように行うことに対して関連付けられた不利益）などを考慮してもよい。いくつかの実施形態において、セレクタ３０９は、ハードウェア回路内に実装される、又は、ハードウェア回路により実行される有限ステートマシンである。
【０１８４】
いくつかの実施形態において、セレクタ３０９は、ターゲット処理要素と通信するために、対応するリンクプロトコルも選択する。例えば、いくつかの実施例において、処理要素は、システムファブリック又はポイントツーポイント相互接続に関する複数のプロトコルを動的に多重化又はカプセル化することが可能な対応する共通のリンクインタフェースを利用する。例えば、特定の実施例において、サポートされるプロトコルは、１）１又は複数の独自又は業界標準（例えば、ＰＣＩエクスプレス仕様又は同等の代替手段など）において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、ＤＭＡスタイルのデータ転送及び様々なサービスを可能にする生産者／消費者、発見、構成、割込み（ＰＤＣＩ）プロトコル、２）デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス（ＣＡＣ）プロトコル、及び、３）処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス（ＭＡ）プロトコルを含む。セレクタ３０９は、処理要素に通信される要求のタイプに基づいて、これらのプロトコル間の選択を行う。例えば、生産者／消費者、発見、構成又は割込み要求は、ＰＤＣＩプロトコルを用い、キャッシュコヒーレンス要求は、ＣＡＣプロトコルを用い、ローカルメモリアクセス要求は、ＭＡプロトコルを用いる。
【０１８５】
いくつかの実施例において、スレッドは、フェーズタイプを示すマーカを含み、したがって、フェーズ検出器は利用されない。いくつかの実施例において、スレッドは、処理要素タイプ、リンクプロトコル及び／又はメモリタイプに関する暗示又は明示的な要求を含む。これらの実施例において、セレクタ３０９は、その選択処理においてこの情報を利用する。例えば、セレクタ３０９による選択は、スレッド及び／又はユーザによりオーバーライドされてよい。
【０１８６】
実装に応じて、ヘテロジニアススケジューラは、受信したコードフラグメントを処理し、ターゲット処理要素に対して対応するネイティブエンコーディングを生成する１又は複数のコンバータを含んでよい。例えば、ヘテロジニアススケジューラは、第１のタイプのマシンコードを第２のタイプのマシンコードに変換する変換器、及び／又は、中間表現をターゲット処理要素にネイティブなフォーマットに変換するＪＩＴコンパイラを含んでよい。代替的に又はさらに、ヘテロジニアススケジューラは、反復的コードフラグメント（すなわち、「ホット」コード）を識別し、コードフラグメント又は対応するマイクロオペレーションの１又は複数のネイティブエンコーディングをキャッシュするパターンマッチャを含んでよい。これらの選択的なコンポーネントのそれぞれは、図３に示されている。特に、ヘテロジニアススケジューラ３０１は、変換器３０３及びＪＩＴコンパイラ３０５を含む。ヘテロジニアススケジューラ３０１がオブジェクトコード又は中間表現に対して演算を行う場合、受信したコードフラグメントをターゲット処理要素１０３、１０５、１０７、１０９のうちの１又は複数にネイティブなフォーマットに変換するために、ＪＩＴコンパイラ３０５が呼び出される。ヘテロジニアススケジューラ３０１がマシンコード（バイナリ）に対して演算を行う場合（例えば、ある命令セットから他の命令セットに変換する場合など）、バイナリトランスレータ３０３は、受信したコードフラグメントを、ターゲット処理要素のうちの１又は複数にネイティブなマシンコードに変換する。代替的な実施形態において、ヘテロジニアススケジューラ３０１は、これらのコンポーネントのうちの１又は複数を除外してよい。
【０１８７】
例えば、いくつかの実施形態では、バイナリトランスレータは含まれていない。これは、スケジューラにこれを対処させる代わりに、潜在的に利用可能なアクセラレータ、コアなどをプログラムが考慮する必要があるので、プログラミングの複雑性が増すという結果をもたらし得る。例えば、プログラムは、異なるフォーマットにおけるルーチンのためのコードを含む必要があるかもしれない。しかしながら、いくつかの実施形態において、バイナリトランスレータがない場合、より高いレベルでコードを受け入れるＪＩＴコンパイラがあり、当該ＪＩＴコンパイラが必要な変換を実行する。パターンマッチャが存在する場合、特定の処理要素で実行されるべきコードを発見するためにホットコードがさらに検出されてよい。
【０１８８】
例えば、いくつかの実施形態では、ＪＩＴコンパイラは含まれていない。これはまた、スケジューラにこれを対処させる代わりに、プログラムがまず特定のＩＳＡ用のマシンコードにコンパイルする必要があるので、プログラミングの複雑性が増すという結果をもたらし得る。しかしながら、いくつかの実施形態において、バイナリトランスレータがあり、かつ、ＪＩＴコンパイラがない場合、スケジューラは、以下で詳細に説明するように、ＩＳＡ間で変換してよい。パターンマッチャが存在する場合、特定の処理要素で実行されるべきコードを発見するためにホットコードがさらに検出されてよい。
【０１８９】
例えば、いくつかの実施形態では、パターンマッチャは含まれていない。これはまた、移動された可能性があるコードが、実行中の特定のタスクにとって効率的とはいえないコアのままである可能性が高いので、効率性が下がるという結果をもたらし得る。
【０１９０】
いくつかの実施形態では、バイナリトランスレータ、ＪＩＴコンパイラ又はパターンマッチャがない。これらの実施形態では、スレッドを移動させるフェーズ検出又は明示的な要求のみが、スレッド／処理要素割り当て／移行に利用される。
【０１９１】
図１〜図３を再び参照すると、ヘテロジニアススケジューラ１０１は、ハードウェア（例えば、回路）、ソフトウェア（例えば、実行可能なプログラムコード）又はこれらの任意の組み合わせで実装されてよい。図１１４は、ハードウェアヘテロジニアススケジューラ回路及びメモリとのそのインタラクションの例を示す。ヘテロジニアススケジューラは、限定されることはないが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）ベース又は特定用途向け集積回路（ＡＳＩＣ）ベースのステートマシンとして、本明細書で詳細に説明される機能を提供するソフトウェアを内部に格納するメモリに結合される埋め込み型マイクロコントローラ、他のサブコンポーネントを有する論理回路（例えば、データハザード検出回路など）として、及び／又は、アウトオブオーダコアにより実行されるソフトウェア（例えば、ステートマシン）として、スカラコアにより実行されるソフトウェア（例えば、ステートマシン）として、ＳＩＭＤコアにより実行されるソフトウェア（例えば、ステートマシン）又はこれらの組み合わせとして含む多くの異なる様式で作成されてよい。図示された例では、ヘテロジニアススケジューラは、様々な機能を実行する１又は複数のコンポーネントを含む回路１１４０１である。いくつかの実施形態において、この回路１１４０１は、プロセッサコア１１４１９の一部であるが、チップセットの一部であってもよい。
【０１９２】
スレッド／処理要素（ＰＥ）トラッカー１１４０３は、システム及び各ＰＥで実行するスレッドごとにステータス（例えば、ＰＥの可用性、その現在の電力消費など）を維持する。例えば、トラッカー１１４０３は、テーブルなどのデータ構造において、アクティブ、アイドル又はインアクティブのステータスを維持する。
【０１９３】
いくつかの実施形態において、パターンマッチャ１１４０５は、「ホット」コード、アクセラレータコード、及び／又は、ＰＥ割り当てを要求するコードを識別する。このマッチングに関するさらなる詳細が後で提供される。
【０１９４】
ＰＥ情報１１４１１は、どのようなＰＥ（及びこれらのタイプ）がシステムにあり、何がＯＳなどによりスケジューリングされ得るかに関する情報を格納する。
【０１９５】
上記では、ヘテロジニアススケジューラ回路１１４０１内の別々のコンポーネントとして詳細に説明されているが、一方、コンポーネントは、組み合わせられてよい、及び／又は、ヘテロジニアススケジューラ回路１１４０１の外部に移動されてもよい。
【０１９６】
ヘテロジニアススケジューラ回路１１４０１に結合されるメモリ１１４１３は、追加の機能を提供する（コア及び／又はヘテロジニアススケジューラ回路１１４０１により）実行されるソフトウェアを含んでよい。例えば、ソフトウェアパターンマッチャ１１４１７は、「ホット」コード、アクセラレータコード、及び／又は、ＰＥ割り当てを要求するコードを識別するために用いられてよい。例えば、ソフトウェアパターンマッチャ１１４１７は、コードシーケンスを、メモリに格納されたパターンの予め決定されたセットと比較する。メモリは、ある命令セットから他の命令セットに（例えば、１つの命令設定からアクセラレータベースの命令又はプリミティブに）コードを変換する変換器を格納してもよい。
【０１９７】
これらのコンポーネントは、どのようなリンクプロトコルが使用され、ＰＥなどで既に実行中のスレッドがある場合にどのような移行が発生するべきかなどを、スレッドを実行するためにそのＰＥの選択を行うセレクタ１１４１１に供給する。いくつかの実施形態において、セレクタ１１４１１は、ハードウェア回路内に実装される、又は、ハードウェア回路により実行される有限ステートマシンである。
【０１９８】
メモリ１１４１３は、例えば、いくつかの実施例において、１又は複数の変換器１１４１５（例えば、バイナリ、ＪＩＴコンパイラなど）が、選択されたＰＥのために異なるフォーマットにスレッドコードを変換すべく、メモリに格納されることを含んでもよい。
【０１９９】
図１１５は、ソフトウェアヘテロジニアススケジューラの例を示す。ソフトウェアヘテロジニアススケジューラは、限定されることはないが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）ベース又は特定用途向け集積回路（ＡＳＩＣ）ベースのステートマシンとして、本明細書で詳細に説明される機能を提供するソフトウェアを内部に格納するメモリに結合される埋め込み型マイクロコントローラ、他のサブコンポーネントを有する論理回路（例えば、データハザード検出回路など）として、及び／又は、アウトオブオーダコアにより実行されるソフトウェア（例えば、ステートマシン）として、スカラコアにより実行されるソフトウェア（例えば、ステートマシン）として、ＳＩＭＤコアにより実行されるソフトウェア（例えば、ステートマシン）又はこれらの組み合わせとして含む多くの異なる様式で作成されてよい。図示された例では、ソフトウェアヘテロジニアススケジューラは、メモリ１１４１３に格納される。その結果、プロセッサコア１１４１９に結合されるメモリ１１４１３は、スレッドをスケジューリングするために（コアにより）実行されるソフトウェアを含む。いくつかの実施形態において、ソフトウェアヘテロジニアススケジューラはＯＳの一部である。
【０２００】
実装に応じて、コア内のスレッド／処理要素（ＰＥ）トラッカー１１４０３は、システム及び各ＰＥにおいて実行するスレッドごとにステータス（例えば、ＰＥの可用性、その現在の電力消費など）を維持する、又は、スレッド／ＰＥトラッカー１１５２１を用いてソフトウェアでこれが実行される。例えば、トラッカーは、テーブルなどのデータ構造において、アクティブ、アイドル又はインアクティブのステータスを維持する。
【０２０１】
いくつかの実施形態において、パターンマッチャ１１４１７は、「ホット」コード、及び／又は、ＰＥ割り当てを要求するコードを識別する。このマッチングに関するさらなる詳細が後で提供される。
【０２０２】
ＰＥ情報１１４０９及び／又は１１５０９は、どのようなＰＥがシステムにあり、何がＯＳなどによりスケジューリングされ得るかに関する情報を格納する。
【０２０３】
ソフトウェアパターンマッチャ１１４１７は、「ホット」コード、アクセラレータコード、及び／又は、ＰＥ割り当てを要求するコードを識別するために用いられてよい。
【０２０４】
スレッド／ＰＥトラッカー、処理要素情報、及び／又は、パターンマッチは、ＰＥなどで既に実行中のスレッドがある場合、どのようなリンクプロトコルを用いるか、どのような移行が発生するべきかが、スレッドを実行するＰＥの選択を行うセレクタ１１４１１に供給される。いくつかの実施形態において、セレクタ１１４１１は、プロセッサコア１１４１９より実装されて実行される有限ステートマシンである。
【０２０５】
メモリ１１４１３は、例えば、いくつかの実施例において、１又は複数の変換器１１４１５（例えば、バイナリ、ＪＩＴコンパイラなど）が選択されたＰＥのために異なるフォーマットにスレッドコードを変換すべく、メモリに格納されることを含んでもよい。
【０２０６】
動作中、ＯＳは、実行環境の抽象化を提示する（例えば、ヘテロジニアススケジューラ１０１、３０１など）ヘテロジニアススケジューラを利用して、処理対象のスレッドをスケジューリングし、このスレッドを実行する。
【０２０７】
以下の表は、潜在的な抽象化特徴（すなわち、プログラムが何を参照するか）、潜在的な設計自由度及びアーキテクチャの最適化（すなわち、何がプログラマから隠れているか）、及び、抽象化における特定の特徴を提供するための潜在的な利益又は理由を要約したものである。
【表１】
0006988040.tif 000002
【０２０８】
いくつかの例示的な実装において、ヘテロジニアススケジューラは、他のハードウェア及びソフトウェアリソースとの組み合わせにおいて、すべてを実行し、すべてのプログラミング技術（例えば、コンパイラ、組み込み関数、アセンブリ、ライブラリ、ＪＩＴ、オフロード、デバイス）をサポートする完全なプログラミングモデルを提示する。他の例示的な実装は、他のプロセッサ開発企業、例えば、ＡＲＭホールディングス社、ＭＩＰＳ、ＩＢＭ又はこれらのラインセンシ若しくは採用者により提供されるものに適合する代替的な実行環境を提示する。
【０２０９】
図１１９は、詳細に上述されたように、抽象実行環境を提示するプロセッサのブロック図である。この例では、プロセッサ１１９０１は、いくつかの異なるコアタイプ、例えば、図１に詳細に説明されているものを含む。各（ワイド）ＳＩＭＤコア１１９０３は、密な算術のプリミティブをサポートする融合積和演算（ＦＭＡ）回路、独自のキャッシュ（例えば、Ｌ１及びＬ２）、特定用途実行回路及びスレッド状態用のストレージを含む。
【０２１０】
各レイテンシ最適化（ＯＯＯ）コア１１９１３は、融合積和演算（ＦＭＡ）回路、独自のキャッシュ（例えば、Ｌ１及びＬ２）及びアウトオブオーダ実行回路を含む。
【０２１１】
各スカラコア１１９０５は、融合積和演算（ＦＭＡ）回路、独自のキャッシュ（例えば、Ｌ１及びＬ２）、特定用途実行及びスレッド状態の格納を含む。典型的には、スカラコア１１９０５は、メモリレイテンシをカバーするのに十分なスレッドをサポートする。いくつかの実施例において、ＳＩＭＤコア１１９０３及びレイテンシ最適化コア１１９１３の数は、スカラコア１１９０５の数と比較して少ない。
【０２１２】
いくつかの実施形態において、１又は複数のアクセラレータ１１９１７が含まれる。これらのアクセラレータ１１９１７は、固定機能又はＦＰＧＡベースであってよい。これらのアクセラレータ１１９１７とは代替的に又はこれらに加えて、いくつかの実施形態では、アクセラレータ１１９１７は、プロセッサの外部にある。
【０２１３】
プロセッサ１１９０１はまた、プロセッサ内にあるコア及び潜在的に任意のアクセラレータにより共有されるラストレベルキャッシュ（ＬＬＣ）１１９０７を含む。いくつかの実施形態において、ＬＬＣ１１９０７は、高速アトミック用の回路を含む。
【０２１４】
１又は複数の相互接続１１９１５は、コア及びアクセラレータを互いに、及び、外部インタフェースに結合する。例えば、いくつかの実施形態では、メッシュ型の相互接続が様々なコアを結合する。
【０２１５】
メモリコントローラ１１９０９は、コア及び／又はアクセラレータをメモリに結合する。
【０２１６】
複数の入力／出力インタフェース（例えば、以下で詳細に説明されるＰＣＩｅ、共通のリンク）１１９１１は、プロセッサ１１９０１を外部デバイス、例えば、他のプロセッサ及びアクセラレータに接続する。
【０２１７】
図４は、コンピュータシステムのシステムブート及びデバイス発見についての実施形態を示す。システムについての知識は、例えば、どのようなコアが利用可能であるか、どれくらいのメモリが利用可能であるか、コアに関連するメモリ位置などがヘテロジニアススケジューラにより利用されるかといった知識を含む。いくつかの実施形態において、この知識は、アドバンスド・コンフィグレーション・アンド・パワー・インタフェース（ＡＣＰＩ）を用いて構築される。
【０２１８】
４０１において、コンピュータシステムがブートされる。
【０２１９】
４０３において、構成設定のクエリが行われる。例えば、いくつかのＢＩＯＳベースのシステムでは、ブートされたときに、ＢＩＯＳは、システムの動作確認を行い、ドライブ及び他の構成設定を独自のメモリバンクにクエリすることにより、オペレーション用のコンピュータを準備する。
【０２２０】
４０５において、プラグインコンポーネントの探索が行われる。例えば、ＢＩＯＳは、コンピュータ内の任意のプラグインコンポーネントを探索し、メモリ内のポインタ（割込みベクトル）をセットアップしてそれらのルーチンにアクセスする。ＢＩＯＳは、デバイスドライバ並びにアプリケーションプログラムから、ハードウェア及び他の周辺デバイスとのインタフェース接続に関する要求を受け入れる。
【０２２１】
４０７において、システムコンポーネント（例えば、コア、メモリなど）のデータ構造が生成される。例えば、ＢＩＯＳは、典型的には、ＯＳが付属デバイスとインタフェースするハードウェアデバイス及び周辺デバイス構成情報を生成する。さらに、ＡＣＰＩは、システムボードに対する柔軟でスケーラブルなハードウェアインタフェースを定義し、コンピュータが、特に、ノートブックコンピュータなどのポータブルデバイスにおいて、電源管理を改善するために、その周辺機器をオン及びオフすることを可能にする。ＡＣＰＩ仕様は、ハードウェアインタフェースと、ソフトウェアインタフェース（ＡＰＩ）と、実装される場合、ＯＳ指向構成及び電源管理をサポートするデータ構造とを含む。ソフトウェアの設計者は、ＡＣＰＩを用いて、ハードウェア、オペレーティングシステム及びアプリケーションソフトウェアを含むコンピュータシステム全体の電源管理機能を統合できる。この統合は、どのデバイスがアクティブであり、コンピュータサブシステム及び周辺機器に対する電源管理リソースのすべてを処理するかをＯＳが判断することを可能にする。
【０２２２】
４０９において、オペレーティングシステム（ＯＳ）がロードされて、制御を獲得する。例えば、ＢＩＯＳがその起動ルーチンを完了した時点で、ＢＩＯＳは制御をＯＳに渡す。ＡＣＰＩである場合、ＢＩＯＳは、コンピュータの制御をＯＳに渡し、ＢＩＯＳは、ＡＣＰＩ名前空間を含むデータ構造をＯＳにエクスポートし、それは、ツリーとしてグラフィカルに表され得る。名前空間は、コンピュータに接続されたＡＣＰＩデバイスのディレクトリとして動作し、各ＡＣＰＩデバイスに対してステータス情報をさらに定義及び提供するオブジェクトを含む。ツリー内の各ノードは、デバイスと関連付けられており、一方、ＯＳにより評価される場合、デバイスを制御し、ＡＣＰＩ仕様で規定されるような特定の情報をＯＳに返すノード、サブノード及びリーフがオブジェクトを表す。ＯＳ又はＯＳによりアクセスされるドライバは、名前空間オブジェクトを列挙及び評価する機能のセットを含んでよい。ＯＳが機能をコールして、ＡＣＰＩ名前空間内のオブジェクトの値を返す場合、ＯＳは、そのオブジェクトを評価したといえる。
【０２２３】
いくつかの例において、利用可能なデバイスが変わる。例えば、アクセラレータ、メモリなどが加えられる。ポストシステムブートデバイス発見のための方法の実施形態が図１１６に示される。例えば、この方法の実施形態は、ブート後のシステムに追加されたアクセラレータを発見するために用いられてよい。１１６０１において、電源オン又はリセットされる接続されたデバイスのインジケーションが受信される。例えば、エンドポイントデバイスは、例えば、ＯＳにより、ＰＣＩｅスロットにプラグ接続される、又は、リセットされる。
【０２２４】
１１６０３において、リンクトレーニングが接続されたデバイスを用いて実行され、接続されたデバイスが初期化される。例えば、ＰＣＩｅのリンクトレーニングは、リンク幅、レーン極性、及び／又は、サポートされる最大データレートなどのリンク構成パラメータを確立するために実行される。いくつかの実施形態において、接続されたデバイスの性能は、（例えば、ＡＣＰＩテーブルに）格納される。
【０２２５】
１１６０５において、接続されたデバイスの初期化が完了した場合、準備完了メッセージ（ｒｅａｄｙ  ｍｅｓｓａｇｅ）が接続されたデバイスからシステムに送信される。
【０２２６】
１１６０７において、デバイスが構成を準備できたことを示すために、接続されたデバイスの準備完了ステータスビットが設定される。
【０２２７】
１１６０９において、初期化された、接続されたデバイスが構成される。いくつかの実施形態において、デバイス及びＯＳは、デバイス用のアドレス（例えば、メモリマッピングされたＩ／Ｏ（ＭＭＩＯ）アドレス）について合意する。デバイスは、ベンダ識別番号（ＩＤ）、デバイスＩＤ、モデル番号、シリアル番号、特性、リソース要件などのうちの１又は複数を含むデバイス記述子を提供する。ＯＳは、記述子データ及びシステムリソースに基づいて、デバイスに対する追加の動作及び構成パラメータを判断してよい。ＯＳは、構成クエリを生成してよい。デバイスは、デバイス記述子に応答してよい。次に、ＯＳは、構成データを生成して、このデータを（例えば、ＰＣＩハードウェアを通じて）デバイスに送信する。これは、デバイスと関連付けられるアドレス空間を定義するベースアドレスレジスタの設定を含んでよい。
【０２２８】
システムの知識が構築された後に、ＯＳは、ヘテロジニアススケジューラ（例えば、ヘテロジニアススケジューラ１０１、３０１など）を利用して、処理対象のスレッドをスケジューリングして、このスレッドを実行する。次に、ヘテロジニアススケジューラは、各スレッドのコードフラグメントを、（例えば、ユーザ及び／又はＯＳに対して）動的かつ透過的に最も適したタイプの処理要素へマッピングし、それにより、レガシアーキテクチャ機構用のハードウェアを構築する必要性、及び潜在的にシステムプログラマ又はＯＳにマイクロアーキテクチャの詳細をさらす必要性を潜在的に回避する。
【０２２９】
いくつかの例では、最も適したタイプの処理要素は、処理要素の性能及びコードフラグメントの実行特性に基づいて判断される。一般的に、プログラム及び関連するスレッドは、所与の時点で処理されるワークロードに応じて、異なる実行特性を有し得る。例示的な実行特性、又は、実行のフェーズは、例えば、データ並列フェーズ、スレッド並列フェーズ及び直列フェーズを含む。以下のテーブルは、これらのフェーズを識別し、これらの特性を要約したものである。テーブルはまた、例示的なワークロード／オペレーション、各フェーズタイプを処理する場合に有用な例示的なハードウェア、及び、用いられるフェーズ及びハードウェアの典型的な目的を含む。
【表２】
0006988040.tif 000003
【０２３０】
いくつかの実施例において、ヘテロジニアススケジューラは、スレッド移行及びエミュレーションのどちらかを選択するように構成される。各タイプの処理要素が、任意のタイプのワークロードを処理できる構成（そうするためのエミュレーションを要求する場合）では、例えば、ワークロードのレイテンシ要件、エミュレーションと関連付けられた増加した実行レイテンシ、処理要素の電力及び熱的特性及び制約などを含む１又は複数の基準に基づいて、最も適した処理要素がプログラムフェーズごとに選択される。後で詳細に説明されるように、適した処理要素の選択は、いくつかの実施例において、実行中のスレッドの数を考慮して、コードフラグメント内のＳＩＭＤ命令又はベクトル化可能コードの存在を検出することにより実現される。
【０２３１】
処理要素間でスレッドを移動することは、不利益がないわけではない。例えば、データは、共有キャッシュから下位レベルキャッシュに移動される必要がある可能性があり、元の処理要素及び受け手の処理要素の両方は、移動に順応するために、これらのパイプラインをフラッシュさせるだろう。状況に応じて、いくつかの実施例では、ヘテロジニアススケジューラは、（例えば、上記で参照した１又は複数の基準に対する閾値、又は、同じもののサブセットを設定することによる）非常に頻繁な移行を回避するためにヒステリシスを実装する。いくつかの実施形態において、ヒステリシスは、予め定義されたレート（例えば、１移行毎ミリ秒）を超えないようにスレッド移行を制限することにより実装される。したがって、当該移行のレートは、コード生成、同期及びデータ移行に起因する過剰なオーバーロードを回避するために制限される。
【０２３２】
いくつかの実施形態において、例えば、特定のスレッドに対する好ましアプローチであるものとして、ヘテロジニアススケジューラにより移行が選択されない場合、ヘテロジニアススケジューラは、割り当てられた処理要素にスレッドのための欠落した機能をエミュレートする。例えば、オペレーティングシステムに対して利用可能なスレッドの総数を一定に維持する実施形態において、ヘテロジニアススケジューラは、（例えば、ワイド同時マルチスレッディングコアにおいて）利用可能なハードウェアスレッドの数がオーバサブスクライブされる場合に、マルチスレッディングをエミュレートしてよい。スカラ又はレイテンシコア上で、スレッドの１又は複数のＳＩＭＤ命令がスカラ命令に変換される、又は、ＳＩＭＤコア上で、より多くのスレッドがスポーンされ、及び／又は、命令が、パックドデータを利用するために変換される。
【０２３３】
図５は、処理要素の３つのタイプに対するプログラムフェーズのマッピングに基づいたスレッド移行の例を示す。図示されるように、処理要素の３つのタイプは、レイテンシの最適化（例えば、アウトオブオーダコア、アクセラレータなど）、スカラ（命令毎時間で１つのデータ項目を処理すること）及びＳＩＭＤ（命令毎に複数のデータ要素を処理すること）を含む。典型的には、このマッピングは、スレッド毎又はコードフラグメント毎に、プログラマ及びオペレーティングシステムに対して透過的な態様で、ヘテロジニアススケジューラにより実行される。
【０２３４】
一実施例では、ヘテロジニアススケジューラを用いて、ワークロードの各フェーズを最も適したタイプの処理要素にマッピングする。理想的には、これは、レガシ機能用のハードウェアを構築する必要性を軽減し、コンパイルコード（マシンコード）、組み込み関数（プロセッサ又はアクセラレータ命令に直接マッピングするプログラミング言語論理構成）、アセンブリコード、ライブラリ、中間（ＪＩＴベース）、オフロード（一方のマシンタイプから別のマシンタイプへの移動）及びデバイスに固有などの複数のコードタイプをサポートする完全なプログラミングモデルをヘテロジニアススケジューラが提示するマイクロアーキテクチャの詳細をさらすことを回避する。
【０２３５】
特定の構成において、ターゲット処理要素に対するデフォルトの選択は、レイテンシが最適化される処理要素である。
【０２３６】
図５を再び参照すると、ワークロードに対する直列フェーズの実行５０１では、１又は複数のレイテンシが最適化された処理要素で最初に処理される。（例えば、実行の前又は実行中のコードにおいて得られた命令のタイプにより例えば見られるような、コードがより多くのデータを並列化するような動的なやり方で、又は、実行の前に）位相シフトを検出すると、ワークロードは、データ並列フェーズの実行５０３を完了するために、１又は複数のＳＩＭＤ処理要素に移行される。さらに、実行スケジューリング及び／又は変換は、典型的にはキャッシュされる。その後、ワークロードは、１又は複数のレイテンシが最適化された処理要素、又は、１又は複数のレイテンシが最適化された処理要素の第２のセットに戻って移行されて、次の直列フェーズの実行５０５を完了する。次に、ワークロードは、スレッド並列フェーズの実行５０７を処理するために、１又は複数のスカラコアに移行される。次に、ワークロードは、次の直列フェーズの実行５０９の完了のために、１又は複数のレイテンシが最適化された処理要素に戻って移行される。
【０２３７】
この図示された例は、レイテンシが最適化されたコアへの復帰を示す一方、ヘテロジニアススケジューラは、スレッドが終了されるまで１又は複数の対応するタイプの処理要素において、任意の後続のフェーズの実行についての実行を継続してよい。いくつかの実施例では、処理要素は、ワークキューを利用して、完了していないタスクを格納する。その結果、タスクは、すぐに開始しなくてもよいが、キュー内のこれらのスポットが現れたときに実行される。
【０２３８】
図６は、ヘテロジニアススケジューラ、例えば、ヘテロジニアススケジューラ１０１などにより実行される例示的な実施フローである。このフローは、処理要素（例えば、コア）の選択を図示する。図示されるように、ヘテロジニアススケジューラによりコードフラグメントが受信される。いくつかの実施形態において、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す１又は複数の命令を含むイベントが発生する。
【０２３９】
６０１において、ヘテロジニアススケジューラは、例えば、検出されたデータの依存性、命令タイプ及び／又は制御フロー命令に基づいて、（例えば、直列フェーズ又は並列フェーズにおけるコードフラグメントである）コードフラグメントに並列性があるか否かを判断する。例えば、ＳＩＭＤコードでいっぱいのスレッドは、並列とみなされるであろう。コードフラグメントが並列処理に適していない場合、ヘテロジニアススケジューラは、１又は複数のレイテンシに敏感なオペレーション要素（例えば、ＯＯＯコア）を選択し、直列フェーズの実行６０３においてコードフラグメントを処理する。典型的には、ＯＯＯコアは、（深層）推論及び動的なスケジューリングを有し、通常、より簡単な代替物と比較してワット性能が低い。
【０２４０】
いくつかの実施形態では、典型的には、レイテンシに敏感なオペレーション要素はスカラコアより多くの電力及びダイ空間を消費するので、利用可能なレイテンシに敏感なオペレーション要素がない。これらの実施形態では、スカラ、ＳＩＭＤ及びアクセラレータコアのみが利用可能である。
【０２４１】
６０５において、並列コードフラグメント、並列化可能なコードフラグメント及び／又はベクトル化可能コードフラグメントに関し、ヘテロジニアススケジューラは、コードの並列性についてのタイプを判断する。６０７において、スレッド並列コードフラグメントに関し、ヘテロジニアススケジューラは、スレッド並列処理要素（例えば、マルチプロセッサスカラコア）を選択する。スレッド並列コードフラグメントは、別々のスカラコアで同時に実行され得る独立した命令シーケンスを含む。
【０２４２】
各処理要素が異なる数のデータに同じタスクを実行した場合に、データ並列コードが発生する。データ並列コードは、パックド及びランダムという異なるデータレイアウトの形式があり得る。６０９において、データレイアウトが判断される。ランダムデータは、ＳＩＭＤ処理要素に割り当てられてよいが、異なるメモリ位置からデータを引き出すギャザー命令６１３、（小型のプログラマブル処理要素のアレイ、例えば、ＦＰＧＡのアレイ上に計算を空間的にマッピングする）空間計算アレイ６１５、又は、スカラ処理要素６１７のアレイを利用することが必要である。パックドデータは、６１１において密な算術のプリミティブを用いるＳＩＭＤ処理要素又は処理要素に割り当てられる。
【０２４３】
いくつかの実施形態において、選択された宛先処理要素をより良く適合させるようにコードフラグメントの変換が実行される。例えば、コードフラグメントは、１）異なる命令セットを利用するために変換され、２）より多く並列化され、３）あまり並列化されず（直列化され）、４）データを並列化し（例えば、ベクトル化され）、及び／又は、５）データをあまり並列化しない（例えば、非ベクトル化される）。
【０２４４】
処理要素が選択された後、コードフラグメントは、実行のために判断された処理要素のうちの１つに送信される。
【０２４５】
図７は、ヘテロジニアススケジューラによるスレッド宛先選択のための方法についての例を示す。いくつかの実施形態において、この方法は、バイナリトランスレータにより実行される。７０１において、評価対象のスレッド又はこれらのコードフラグメントが受信される。いくつかの実施形態において、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す１又は複数の命令を含むイベントが発生する。
【０２４６】
７０３において、コードフラグメントがアクセラレータにオフロードされるか否かの判断が行われる。例えば、アクセラレータに送信されるコードフラグメントである。ヘテロジニアススケジューラは、コードがアクセラレータを用いるという要望を識別するコードを含む場合、これが訂正動作であることを知り得る。この要望は、コードの領域がアクセラレータ上で実行され、又は、ネイティブに（例えば、本明細書で説明されたＡＢＥＧＩＮ／ＡＥＮＤ）実行されてよいことを示す識別子、又は、特定のアクセラレータを用いる明示的なコマンドであってよい。
【０２４７】
いくつかの実施形態では、７０５において、選択された宛先処理要素をより良く適合させるようにコードフラグメントの変換が実行される。例えば、コードフラグメントは、１）異なる命令セットを利用するために変換され、２）より多く並列化され、３）あまり並列化されず（直列化され）、４）データを並列化し（例えば、ベクトル化され）、及び／又は、５）データをあまり並列化しない（例えば、非ベクトル化される）。
【０２４８】
典型的には、７０７において、変換されたスレッドは、後の使用のためにキャッシュされる。いくつかの実施形態において、バイナリトランスレータは、将来におけるバイナリトランスレータの使用のために利用可能となるように変換されたスレッドをローカルにキャッシュする。例えば、コードが「ホット」になる（繰り返し実行される）場合、キャッシュは、（送信コストがあり得るが）変換の不利益なく将来の利用のためのメカニズムを提供する。
【０２４９】
７０９において、（変換された）スレッドは、処理のために宛先処理要素に送信される（例えば、オフロードされる）。いくつかの実施形態において、変換されたスレッドは、将来の利用のためにローカルに利用可能であるように受け手によりキャッシュされる。さらに、受け手又はバイナリトランスレータは、コードが「ホット」であると判断した場合、このキャッシングは、使用されるエネルギーが少ない状態でより高速な実行を可能にする。
【０２５０】
７１１において、ヘテロジニアススケジューラは、例えば、検出されたデータの依存性、命令タイプ及び／又は制御フロー命令に基づいて、（例えば、直列フェーズ又は並列フェーズにおけるコードフラグメントである）コードフラグメントに並列性があるか否かを判断する。例えば、ＳＩＭＤコードでいっぱいのスレッドは、並列とみなされるであろう。コードフラグメントが並列処理に適していない場合、ヘテロジニアススケジューラは、１又は複数のレイテンシに敏感なオペレーション要素（例えば、ＯＯＯコア）を選択し、直列フェーズの実行７１３においてコードフラグメントを処理する。典型的には、ＯＯＯコアは、（深層）推論及び動的なスケジューリングを有し、故に、スカラの代替物と比較してワット性能が良好であり得る。
【０２５１】
いくつかの実施形態では、典型的には、レイテンシに敏感なオペレーション要素はスカラコアより多くの電力及びダイ空間を消費するので、利用可能なレイテンシに敏感なオペレーション要素がない。これらの実施形態では、スカラ、ＳＩＭＤ及びアクセラレータコアのみが利用可能である。
【０２５２】
７１５において、並列コードフラグメント、並列化可能なコードフラグメント及び／又はベクトル化可能コードフラグメントに関し、ヘテロジニアススケジューラは、コードの並列性についてのタイプを判断する。７１７において、スレッド並列コードフラグメントに関し、ヘテロジニアススケジューラは、スレッド並列処理要素（例えば、マルチプロセッサスカラコア）を選択する。スレッド並列コードフラグメントは、別々のスカラコアで同時に実行され得る独立した命令シーケンスを含む。
【０２５３】
各処理要素が異なる数のデータに同じタスクを実行した場合に、データ並列コードが発生する。データ並列コードは、パックド及びランダムという異なるデータレイアウトの形式があり得る。７１９において、データレイアウトが判断される。ランダムデータは、ＳＩＭＤ処理要素に割り当てられてよいが、ギャザー命令７２３、空間計算アレイ７２５又はスカラ処理要素７２７のアレイを利用することが必要である。パックドデータは、７２１において密な算術のプリミティブを用いるＳＩＭＤ処理要素又は処理要素に割り当てられる。
【０２５４】
いくつかの実施形態において、判断される宛先処理要素をより良く適合させるようにオフロードされていないコードフラグメントの変換が実行される。例えば、コードフラグメントは、１）異なる命令セットを利用するために変換され、２）より多く並列化され、３）あまり並列化されず（直列化され）、４）データを並列化し（例えば、ベクトル化され）、及び／又は、５）データをあまり並列化しない（例えば、非ベクトル化される）。
【０２５５】
処理要素が選択された後、コードフラグメントは、実行のために判断された処理要素のうちの１つに送信される。
【０２５６】
ＯＳは、コア及びアクセラレータがアクセス可能であることに関わらず、潜在的に利用可能なスレッドの総数を参照する。以下の説明では、論理ＩＤと呼ばれるスレッド識別子（ＩＤ）によって各スレッドが列挙される。いくつかの実施例において、オペレーティングシステム及び／又はヘテロジニアススケジューラは、論理ＩＤを利用して、特定の処理要素のタイプ（例えば、コアタイプ）、処理要素ＩＤ及びその処理要素上のスレッドＩＤ（例えば、コアタイプのタプル、コアＩＤ、スレッドＩＤ）にスレッドをマッピングする。例えば、スカラコアは、コアＩＤ及び１又は複数のスレッドＩＤを有し、ＳＩＭＤコアは、コアＩＤ及び１又は複数のスレッドＩＤを有し、ＯＯＯコアは、コアＩＤ及び１又は複数のスレッドＩＤを有し、及び／又は、アクセラレータは、コアＩＤ及び１又は複数のスレッドＩＤを有する。
【０２５７】
図８は、論理ＩＤに対する縞模様マッピングの使用についての概念を示す。縞模様マッピングは、ヘテロジニアススケジューラにより用いられてよい。この例では、８つの論理的なＩＤ、及び、それぞれが１又は複数のスレッドを有する３つのコアタイプがある。典型的には、論理ＩＤから（コアＩＤ、スレッドＩＤ）へのマッピングは、除算及びモジュロを用いて計算され、ソフトウェアスレッドの共通性を保つために固定されていてよい。論理ＩＤから（コアタイプ）へのマッピングは、ＯＳに利用しやすい将来の新たなコアタイプに順応するように、ヘテロジニアススケジューラにより柔軟に実行される。
【０２５８】
図９は、論理ＩＤに対する縞模様マッピングの使用についての例を示す。例では、論理ＩＤ１、４及び５が第１のコアタイプにマッピングされ、その他すべての論理ＩＤが第２のコアタイプにマッピングされる。第３のコアタイプは利用されていない。
【０２５９】
いくつかの実施例では、コアタイプのグループ化が作成される。例えば、「コアグループ」タプルが、１つのＯＯＯタプル及びすべてのスカラ、ＳＩＭＤ、並びに、論理ＩＤが同じＯＯＯタプルにマッピングするアクセラレータコアタプルからなってよい。図１０は、コアグループの例を示す。典型的には、直列フェーズ検出及びスレッド移行が同じコアグループ内で実行される。
【０２６０】
図１１は、バイナリトランスレータ切替メカニズムを利用するシステムにおけるスレッド実行の方法の例を示す。１１０１において、スレッドがコア上で実行される。コアは、アクセラレータを含む、本明細書で詳細に説明されるタイプのいずれかであってよい。
【０２６１】
１１０３において、スレッドの実行中のいくつかの時点で、潜在的なコアの再割り当てイベントが発生する。例示的なコアの再割り当てイベントは、限定されることはないが、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び異なるコアへの所望の再割り当てを示す１又は複数の命令を含む。
【０２６２】
１１０５において、イベントは、処理されて、コア割り当てに変更があるか否かに応じた判断が行われる。ある特定のコア割り当ての処理に関する例示的な方法を以下に詳細に説明する。
【０２６３】
いくつかの実施形態において、コアの（再）割り当ては、移動率の制限及び電力消費の制限などの１又は複数の制限要因を対象とする。移動率の制限は、コアタイプ、コアＩＤ及びスレッドＩＤ毎に追跡される。一旦スレッドがターゲット（コアタイプ、コアＩＤ、スレッドＩＤ）に割り当てられると、タイマが開始されてバイナリトランスレータにより維持される。タイマが期限切れになるまで、同じターゲットに移行されるスレッドは他にない。その結果、スレッドは、タイマが期限切れになる前にその現在のコアから離れて移行してもよい一方、その逆は成り立たない。
【０２６４】
詳細に説明されるように、より多くのコアタイプ（アクセラレータを含む）がコンピューティングシステム（オン又はオフダイのいずれか一方）に追加されるにつれて、電力消費の制限に対する注目が高まる可能性が高い。いくつかの実施形態において、すべてのコア上のすべての実行スレッドにより消費される瞬間的な電力が計算される。計算された電力消費が閾値を超える場合、新たなスレッドが、より低い電力のコア、例えば、ＳＩＭＤ、スカラ及び専用のアクセラレータコアに割り当てられるだけであり、１又は複数のスレッドは、ＯＯＯコアからより低い電力のコアに強制的に移行させられる。いくつかの実施例では、電力消費の制限は、移動率の制限よりも優先されることに留意する。
【０２６５】
図１２は、アクセラレータに対するホットコードのコア割り当てについての例示的な方法を示す。１２０１において、コードが「ホット」であるという判断が行われる。コードのホット部分は、電力、性能、熱、他の既知のプロセッサ基準又はこれらの組み合わせなどの考慮に基づいて、その他のコアを介して１つのコア上で実行するのにより適しているコードの一部を指し得る。この判断は、任意の数の技術を用いて行われてよい。例えば、動的バイナリオプティマイザが、スレッドの実行をモニタリングするために利用されてよい。ホットコードは、プログラム実行中などに、静的コードの動的な実行頻度を記録するカウンタ値に基づいて検出されてよい。コアがＯＯＯコアであり、別のコアがインオーダコアである実施形態において、次に、コードのホット部分は、直列コア上で実行されるのにより適しているプログラムコードのホットスポットを指してよく、高反復セクションの実行のために、より多くの利用可能なリソースを潜在的に有する。多くの場合、高反復パターンを有するコードのセクションは、インオーダコア上でより効率的に実行されるように最適化され得る。本質的には、この例において、コールドコード（低反復）が、ネイティブＯＯＯコアに分配され、一方、ホットコード（高反復）は、ソフトウェア管理されたインオーダコアに分配される。コードのホット部分は、静的、動的又はこれらの組み合わせで識別されてよい。第１のケースでは、コンパイラ又はユーザは、プログラムコードおセクションがホットコードであると判断してよい。コア内のデコード論理は、一実施形態において、プログラムコードからのホットコード識別子命令をデコードするために適合され、当該命令は、プログラムコードのホット部分を識別する。そのような命令のフェッチ又はデコードは、コア上のコードのホットセクションの変換及び／又は実行をトリガし得る。別の例では、コード実行は、プロファイルされた実行であり、プロファイルの特性−実行と関連付けられた電力及び／又は性能メトリック−に基づいており、プログラムコードの領域は、ホットコードとして識別され得る。ハードウェアのオペレーションと同様に、他のコア上で実行されているプログラムコードのモニタリング／プロファイリングを実行するために、モニタリングコードが１つのコア上で実行されてよい。そのようなモニタリングコードは、コア内のストレージ構造において保持される又はプロセッサを含むシステムにおいて保持されるコードであってよいことに留意する。例えば、モニタリングコードは、マイクロコード又は他のコードであってよく、コアのストレージ構造において保持される。さらに別の例として、ホットコードの静的な識別は、暗示として行われる。しかしながら、プログラムコード実行の動的プロファイリングは、ホットとしてのコードの領域静的な識別を無視することができ、このタイプの静的な識別は、多くの場合、どのコアがコード分散に適切であるかを判断する際に動的プロファイリングが考慮してよいコンパイラ又はユーザ暗示と称される。さらに、動的プロファイリングの特性と同様に、ホットとしてのコードの領域の識別は、そのコードのセクションが常にホットとして識別されるように制限されるわけではない。変換及び／又は最適化の後、コードセクションの変換バージョンが実行される。
【０２６６】
１２０３において、適切なアクセラレータが選択される。バイナリトランスレータ、仮想マシンモニタ又はオペレーティングシステムは、利用可能なアクセラレータ及び所望の性能に基づいてこの選択を行う。多くの例では、アクセラレータは、より大きくてより一般的なコアよりも１ワットあたりの向上した性能でホットコードを実行するのにより適切である。
【０２６７】
１２０５において、ホットコードは、選択されたアクセラレータに送信される。この送信は、本明細書で詳細に説明されるように、適切な接続タイプを利用する。
【０２６８】
最後に、１２０７において、ホットコードは、選択されたアクセラレータにより受信されて実行される。実行の間、ホットコードは、異なるコアへの割り当てについて評価されてよい。
【０２６９】
図１３は、ページディレクトリベースレジスタイベントに対するウェイクアップ又は書き込みのための可能性があるコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。１３０１において、ウェイクアップイベント又はページディレクトリベースレジスタ（例えば、タスク切替）イベントのいずれか一方が検出される。例えば、ウェイクアップイベントは、停止されたスレッド又は待機状態終了により受信された割込みのために発生する。ページディレクトリベースレジスタへの書き込みは、直列フェーズの開始又は停止を示し得る。典型的には、この検出は、バイナリトランスレータを実行しているコア上で発生する。
【０２７０】
１３０３において、ウェイクアップした又はタスク切替を経験したスレッドと同じページテーブルベースポインタを共有するコアの数がカウントされる。いくつかの実施例において、テーブルは、論理ＩＤを特定のヘテロジニアスコアにマッピングするために用いられる。テーブルは、論理ＩＤによりインデックス付けされる。テーブルの各エントリは、論理ＩＤが現在有効であるか又は停止されているかを示すフラグ、ＳＩＭＤ又はスカラコアのどちらを好むかを示すフラグ、ページテーブルベースアドレス（例えば、ＣＲ３）、論理ＩＤが現在マッピングされているコアのタイプを示す値、及び、移動率を制限するカウンタを含む。
【０２７１】
同じ処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する。
【０２７２】
１３０５において、カウントされたコアの数が１より大きいか否かに応じた判断が行われる。このカウントは、スレッドが、直列又は並列フェーズにあるか否かを判断する。カウントが１である場合、次に、イベントを経験しているスレッドは、直列フェーズ１３０７にある。その結果、直列フェーズスレッドは、同じコアグループ内のすべてのスレッドの中で一意的なページディレクトリベースレジスタ値を有するスレッドである。図１４は、直列フェーズスレッドの例を示す。図示されるように、処理は、１又は複数のスレッドを有し、各処理は独自に割り当てられたアドレスを有する。
【０２７３】
１３１３又は１３１５において、イベントを経験しているスレッドがＯＯＯコアに割り当てられていない場合、それはＯＯＯコアに移行され、ＯＯＯコア上の既存のスレッドは、ＳＩＭＤ又はスカラコアに移行される。イベントを経験しているスレッドがＯＯＯコアに割り当てられている場合、それは、多くの状況でそこに留まる。
【０２７４】
カウントが１より大きい場合、次に、１３０９において、イベントを経験しているスレッドは、並列フェーズにあり、並列フェーズのタイプの判断が行われる。イベントを経験しているスレッドがデータ並列フェーズにあるときに、スレッドがＳＩＭＤコアに割り当てられていない場合、当該スレッドはＳＩＭＤコアに割り当てられ、そうでない場合、１３１３において、既にそこにあるならば、当該スレッドはＳＩＭＤコア上に維持される。
【０２７５】
イベントを経験しているスレッドがデータ並列フェーズにあるときに、スレッドがＳＩＭＤコアに割り当てられていない場合、当該スレッドはＳＩＭＤコアに割り当てられ、そうでない場合、１３１３において、既にそこにあるならば、当該スレッドはＳＩＭＤコア上に維持される。
【０２７６】
イベントを経験しているスレッドが、スレッド並列フェーズにあるときに、スレッドがスカラコアに割り当てられていない場合、当該スレッドはスカラコアに割り当てられ、そうでない場合、既に１３１５においてそこにあるならば、当該スレッドはスカラコア上に維持される。
【０２７７】
さらに、いくつかの実施例では、スレッドが実行中であることを示すフラグがスレッドの論理ＩＤに対して設定される。
【０２７８】
図１５は、スリープコマンドイベントに対するスレッド応答のための潜在的なコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。１５０１において、スレッドに影響を与えるスリープイベントが検出される。例えば、停止、待機エントリ及びタイムアウト又は一時停止コマンドが発生する。典型的には、この検出は、バイナリトランスレータを実行しているコア上で発生する。
【０２７９】
いくつかの実施形態では、１５０３において、スレッドが実行中であることを示すフラグがスレッドの論理ＩＤに対してクリアされる。
【０２８０】
１５０５において、スリープスレッドと同じページテーブルベースポインタを共有するコアのスレッドの数がカウントされる。いくつかの実施例において、テーブルは、論理ＩＤを特定のヘテロジニアスコアにマッピングするために用いられる。テーブルは、論理ＩＤによりインデックス付けされる。テーブルの各エントリは、論理ＩＤが現在有効であるか又は停止されているかを示すフラグ、ＳＩＭＤ又はスカラコアのどちらを好むかを示すフラグ、ページテーブルベースアドレス（例えば、ＣＲ３）、論理ＩＤが現在マッピングされているコアのタイプを示す値、及び、移動率を制限するカウンタを含む。グループからの（任意のページテーブルベースポインタを有する）第１の実行スレッドについて触れる。
【０２８１】
１５０７において、システム内のＯＯＯコアがアイドルであるか否かに応じた判断が行われる。アイドルのＯＯＯコアは、アクティブに実行しているＯＳのスレッドがない。
【０２８２】
ページテーブルベースポインタが、コアグループ内の完全に１つのスレッドにより共有されている場合、次に、１５０９において、共有スレッドは、ＳＩＭＤ又はスカラコアからＯＯＯコアに移動される。ページテーブルベースポインタが１つより多くのスレッドにより共有されている場合、次に、１５１１において、前に述べたグループの第１の実行スレッドは、（第１の実行スレッドの場所で実行する）解除されたスレッドのためにスペースを空けるべく、ＳＩＭＤ又はスカラコアからＯＯＯコアに移行されたスレッドである。
【０２８３】
図１６は、フェーズ変更イベントに応じたスレッドのための可能性があるコア割り当てについての例示的な方法を示す。例えば、これは、コードフラグメントのフェーズを判断することを示す。１６０１において、潜在的なフェーズ変更イベントが検出される。典型的には、この検出は、バイナリトランスレータを実行するコアで発生する。
【０２８４】
１６０３において、スレッドの論理ＩＤがスカラコア上で有効であり、ＳＩＭＤ命令が存在するか否かに応じた判断が行われる。そのようなＳＩＭＤ命令がない場合、次に、スレッドは、通常通りに実行を継続する。しかしながら、スカラコアで実行中のスレッドに存在するＳＩＭＤ命令がある場合、次に、スレッドは、１６０５においてＳＩＭＤコアに移行される。
【０２８５】
１６０７において、スレッドの論理ＩＤがＳＩＭＤコア上で有効であり、ＳＩＭＤ命令が存在しないか否かに応じた判断が行われる。ＳＩＭＤ命令がある場合、次に、スレッドは、通常通りに実行を継続する。しかしながら、ＳＩＭＤコア上で実行中のスレッドに存在するＳＩＭＤ命令がない場合、次に、スレッドは、１６０９においてスカラコアに移行される。
【０２８６】
この説明を通じて述べたように、バイナリトランスレータからアクセス可能なアクセラレータは、より効率的な実行（よりエネルギーの効率的な実行を含む）を提供し得る。しかしながら、それぞれの潜在的に利用可能なアクセラレータに対してプログラムを作成することを可能にすることは、不可能ではないにしても、難しい課題であるかもしれない。
【０２８７】
本明細書において詳細に説明されるのは、スレッドの一部についての潜在的なアクセラレータベースの実行の開始及び終了を明示的に示す記述命令を用いる実施形態である。利用可能なアクセスレータがない場合、記述命令間のコードは、アクセラレータの使用がないままで実行される。いくつかの実施例において、これらの命令間のコードは、実行しているコアのいくつかのセマンティクスを緩和し得る。
【０２８８】
図１７は、加速領域を記述するコードの例を示す。この領域の第１の命令は、加速開始（ＡＢＥＧＩＮ）命令１７０１である。いくつかの実施形態において、ＡＢＥＧＩＮ命令は、非アクセラレータコアに関する実行についての緩和された（サブ）モードに入るための許可を与える。例えば、いくつかの実施例におけるＡＢＥＧＩＮ命令は、どのサブモードの特徴が標準モードとは異なるかをプログラマ又はコンパイラが命令のフィールドにおいて示すことを可能にする。例示的な特徴は、限定されることはないが、自己書き換えコード（ＳＭＣ）を無視すること、メモリ一貫性モデル制限を弱めること（例えば、格納オーダリング要求を緩和する）、浮動小数セマンティクスを変更すること、パフォーマンスモニタリング（ｐｅｒｆｍｏｎ）を変更すること、アーキテクチャフラグの利用を変更すること、などのうちの１又は複数を含む。いくつかの実施例では、ＳＭＣは、関連するキャッシュライン（又はライン）を無効にさせるプロセッサに現在キャッシュされているコードセグメント内のメモリ位置への書き込みである。書き込みがプリフェッチ命令に影響を与える場合、プリフェッチキューは無効にされる。この後者のチェックは、命令の線形アドレスに基づいている。ターゲット命令が既にデコードされており、トレースキャッシュ内に存在するコードセグメント内の命令の書き込み又はスヌープは、トレースキャッシュ全体を無効にする。ＳＭＣは、トランスレーションルックアサイドバッファ内のＳＭＣ検出回路の調整により無視されてよい。例えば、１又は複数のレジスタ又はテーブル（例えば、メモリタイプ範囲レジスタ又はページ属性テーブル）内の設定を変更することにより、メモリ一貫性モデル制限が変更されてよい。例えば、浮動小数セマンティクスを変更する場合、浮動小数点実行回路が浮動小数点計算を実行する方法は、これらの回路の動作を制御する１又は複数の制御レジスタ（例えば、浮動小数点演算ユニット（ＦＰＵ）制御ワードレジスタを設定する）の使用を通じて変更される。変更する可能性がある浮動小数セマンティクスは、限定されることはないが、丸めモード、例外マスク及びステータスフラグがどのように処理されるか、フラッシュトゥゼロ（ｆｌｕｓｈ−ｔｏ−ｚｅｒｏ）、非正規化の設定、及び、精度（例えば、単精度、倍精度、拡張精度）制御を含む。さらに、いくつかの実施形態において、ＡＢＥＧＩＮ命令は、好ましいタイプのアクセラレータが利用可能である場合にそれが選択されるように、明示的なアクセラレータタイプの好みを考慮する。
【０２８９】
非アクセラレータコード１７０３は、ＡＢＥＧＩＮ命令１７０１に従う。このコードは、システムのプロセッサコアに対してネイティブである。最悪の場合、利用可能なアクセスレータがない、又は、ＡＢＥＧＩＮがサポートされていない場合、このコードがそのままコア上で実行されてしまう。しかしながら、いくつかの実施例において、サブモードがその実行のために用いられる。
【０２９０】
加速終了（ＡＥＮＤ）命令１７０５を有することにより、アクセラレータが実行を完了したように見えるようになるまで、その実行は、プロセッサコア上でゲート（ｇａｔｅｄ）される。効果的には、ＡＢＥＧＩＮ及びＡＥＮＤの使用は、アクセラレータ及び／又は緩和モードの実行を用いて、プログラマがオプトイン／アウトをすることを可能にする。
【０２９１】
図１８は、ハードウェアプロセッサコアにおけるＡＢＥＧＩＮを用いた実行についての方法の実施形態を示す。１８０１において、スレッドのＡＢＥＧＩＮ命令がフェッチされる。前に述べたように、ＡＢＥＧＩＮ命令は、典型的には、異なる（サブ）モードの実行を定義するために用いられる１又は複数のフィールドを含む。
【０２９２】
１８０３において、フェッチされたＡＢＥＧＩＮ命令は、デコード回路を用いてデコードされる。いくつかの実施形態において、ＡＢＥＧＩＮ命令は、マイクロオペレーションにデコードされる。
【０２９３】
１８０５において、デコードされたＡＢＥＧＩＮ命令は、ＡＢＥＧＩＮ命令に従うが、ＡＥＮＤ命令の前である命令に対する、（ＡＢＥＧＩＮ命令の１又は複数のフィールドにより明示的に規定されてよい）異なるモードへとスレッドが入るように実行回路により実行される。実行のこの異なるモードは、アクセラレータの可用性及び選択範囲に応じて、アクセラレータ上又は既存のコア上であってよい。いくつかの実施形態において、アクセラレータの選択は、ヘテロジニアススケジューラにより実行される。
【０２９４】
１８０７において、後続の非ＡＥＮＤ命令は、実行の異なるモードで実行される。アクセラレータが実行のために用いられる場合に、当該命令は、まず、バイナリトランスレータにより異なる命令セットに変換されてよい。
【０２９５】
図１９は、ハードウェアプロセッサコアにおけるＡＥＮＤを用いた実行についての方法の実施形態を示す。１９０１において、ＡＥＮＤ命令がフェッチされる。
【０２９６】
１９０３において、フェッチされたＡＥＮＤ命令は、デコード回路を用いてデコードされる。いくつかの実施形態において、ＡＥＮＤは、マイクロオペレーションにデコードされる。
【０２９７】
１９０５において、デコードされたＡＥＮＤ命令は、実行回路により実行されて、前にＡＢＥＧＩＮ命令により設定された実行の異なるモードから戻る。実行のこの異なるモードは、アクセラレータの可用性及び選択範囲に応じて、アクセラレータ上又は既存のコア上であってよい。
【０２９８】
１８０７において、後続の非ＡＥＮＤ命令は、実行の元のモードで実行される。アクセラレータが実行のために用いられる場合、当該命令は、まず、バイナリトランスレータにより異なる命令セットに変換され得る。
【０２９９】
図１２４は、ＡＢＥＧＩＮ／ＡＥＮＤがサポートされていない場合の実行の例を示す。１２４０１において、ＡＢＥＧＩＮ命令がフェッチされる。１２４０３において、ＡＢＥＧＩＮがサポートされていないとの判断が行われる。例えば、ＣＰＵＩＤは、サポートがないことを示す。
【０３００】
サポートがない場合、典型的には、１２４０５において、スレッドと関連付けられるコンテキストを変更しないオペレーション（ｎｏｐ）が実行される。１２４０７において、実行モードにおける変更がないので、サポートされていないＡＢＥＧＩＮに続く命令を通常通り実行する。
【０３０１】
いくつかの実施形態では、ＡＢＥＧＩＮ／ＡＥＮＤの同等の利用法が少なくともパターンマッチングを用いて実現される。このパターンマッチングは、ハードウェア、ソフトウェア及び／又は両方に基づいてよい。図２０は、パターンマッチングを用いてＡＢＥＧＩＮ／ＡＥＮＤ等価を提供するシステムを示す。図示されるシステムは、メモリ２００５に格納された変換器２００１（例えば、バイナリトランスレータ、ＪＩＴなど）を含むスケジューラ２０１５（例えば、詳細に上述されたようなヘテロジニアススケジューラ）を含む。コア回路２００７は、スケジューラ２０１５を実行する。スケジューラ２０１５は、明示的なＡＢＥＧＩＮ／ＡＥＮＤ命令を有しても有していなくてもよいスレッド２０１９を受信する。
【０３０２】
スケジューラ２０１５は、ソフトウェアベースのパターンマッチャ２００３を管理し、オフロード中にトラップ及びコンテキストスイッチを実行し、ユーザ空間保存エリア（後で詳細に説明される）を管理し、アクセラレータコード２０１１を生成又はアクセラレータコード２０１１に変換する。パターンマッチャ２００３は、アクセラレータの利用及び／又は緩和された実行状態から利益を得てよいが、ＡＢＥＧＩＮ／ＡＥＮＤを用いて記述されていない受信したスレッド２０１９において得られるメモリに格納された（予め定義された）コードシーケンスを認識する。典型的には、各自のパターンは、変換器２００１に格納されるが、少なくとも、パターンマッチャ２００３にアクセス可能である。セレクタ２０１９は、前に詳細に説明したものとして機能する。
【０３０３】
スケジューラ２０１５は、パフォーマンスモニタリングの特徴を提供してもよい。例えば、コードが、完全なパターンマッチを有していない場合、スケジューラ２０１５は、コードが、より効率的である要件の緩和をさらに必要とし得ることを認識し、状況に応じて、スレッドと関連付けられる動作モードを調整する。動作モードの関係は、詳細に上述されている。
【０３０４】
スケジューラ２０１５はまた、ＡＢＥＧＩＮ／ＡＥＮＤ領域内でコアを循環させること、アクティブにされ又はストールされるアクセラレータを循環させること、ＡＢＥＧＩＮ呼び出しをカウントすること、アクセラレータのキューイングを遅延させること（同期処理）、及び、メモリ／キャッシュ統計値のモニタリングのうちの１又は複数を実行する。いくつかの実施形態において、バイナリトランスレータ２００１は、ボトルネックを識別する際に有用であり得るアクセラレータコードを解釈するために用いられるアクセラレータに固有のコードを含む。アクセラレータは、この変換されたコードを実行する。
【０３０５】
いくつかの実施形態において、コア回路２００７は、格納されたパターン２０１７を用いて、受信したスレッド２０１９内の（予め定義された）コードシーケンスを認識するハードウェアパターンマッチャ２００９を含む。典型的には、このパターンマッチャ２００９は、ソフトウェアパターンマッチャ２００３と比較して軽量であり、表現が簡単な領域（例えば、ｒｅｐ  ｍｏｖｓ）を探す。認識されたコードシーケンスは、スケジューラ２０１５によるアクセラレータの使用のために変換されてよく、及び／又は、スレッド用の動作モードの緩和を結果的にもたらし得る。
【０３０６】
システムへ結合されているのは、アクセラレータコード２０１１を受信して実行する１又は複数のアクセラレータ２０１３である。
【０３０７】
図２１は、パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。この方法は、パターンマッチャの少なくとも１つのタイプを含むシステムにより実行される。
【０３０８】
いくつかの実施形態では、２１０１において、スレッドが実行される。典型的には、このスレッドは、非アクセラレータコア上で実行される。実行中のスレッドの命令は、パターンマッチャへと供給される。しかしながら、当該スレッドの命令は、任意の実行の前にパターンマッチャへと供給されてもよい。
【０３０９】
２１０３において、スレッド内のパターンが認識（検出）される。例えば、ソフトウェアベースのパターンマッチャ又はハードウェアパターンマッチャ回路は、利用可能なアクセラレータと通常関連付けられているパターンを見つける。
【０３１０】
２１０５において、認識されたパターンは、利用可能なアクセラレータのために変換される。例えば、バイナリトランスレータは、当該パターンをアクセラレータコードに変換する。
【０３１１】
変換されたコードは、実行のために、２１０７において利用可能なアクセラレータに転送される。
【０３１２】
図２２は、パターン認識にさらされる非加速型記述スレッドについての方法の実施形態を示す。この方法は、図２０のシステムに示すように、パターンマッチャの少なくとも１つのタイプを含むシステムにより実行される。
【０３１３】
いくつかの実施形態では、２２０１において、スレッドが実行される。典型的には、このスレッドは、非アクセラレータコア上で実行される。実行中のスレッドの命令は、パターンマッチャへと供給される。しかしながら、当該スレッドの命令は、任意の実行前にパターンマッチャへと供給されてもよい。
【０３１４】
２２０３において、スレッド内のパターンが認識（検出）される。例えば、ソフトウェアベースのパターンマッチャ又はハードウェアパターンマッチャ回路は、利用可能なアクセラレータと通常関連付けられているパターンを見つける。
【０３１５】
２２０５において、バイナリトランスレータは、認識されたパターンに基づいて、緩和要求を用いるために、スレッドと関連付けられた動作モードを調整する。例えば、バイナリトランスレータは、認識されたパターンと関連付けられた設定を利用する。
【０３１６】
詳細に説明されたように、いくつかの実施形態では、コードの並列領域は、ＡＢＥＧＩＮ及びＡＥＮＤ命令により区切られる。ＡＢＥＧＩＮ／ＡＥＮＤブロック内では、特定のメモリロード及びストア操作の独立性が保証されている。他のロード及びストアは、潜在的な依存性を考慮する。これは、実装が、メモリ依存性をほとんど又は全くチェックしないで、ブロックを並列化することを可能にする。いかなる場合でも、直列の場合は、ブロックを実行するのに可能な方式の中に含まれているので、ブロックの直列実行が許可される。バイナリトランスレータは、静的依存性解析を実行して並列実行のインスタンスを作成し、これらのインスタンスをハードウェアにマッピングする。静的依存性解析は、外側、中間又は内側ループの反復を並列化し得る。スライスは、実装に依存する。ＡＢＥＧＩＮ／ＡＥＮＤの実装は、実装に最も適切なサイズにおける並列性を抽出する。
【０３１７】
ＡＢＥＧＩＮ／ＡＥＮＤブロックは、ネステッドループについての複数のレベルを含んでよい。実装は、自由に、サポートされる並列実行の量を選択する、又は、直列実行に対してフォールバックする。ＡＢＥＧＩＮ／ＡＥＮＤは、ＳＩＭＤ命令よりもはるかに大きい領域にわたる並列性を提供する。特定のタイプのコードに関し、ＡＢＥＧＩＮ／ＡＥＮＤは、マルチスレッディングより効率的なハードウェア実装を可能にする。
【０３１８】
ＡＢＥＧＩＮ／ＡＥＮＤの使用を通じて、プログラマ及び／又はコンパイラは、並列化の基準が満たされていない場合、ＣＰＵコアによる従来の直列実行に対してフォールバックすることができる。従来のアウトオブオーダＣＰＵコア上で実行されている場合、ＡＢＥＧＩＮ／ＡＥＮＤは、緩和されたメモリオーダリングの結果として、エリア、及び、メモリオーダリングバッファ（ＭＯＢ）の所要電力を縮小する。
【０３１９】
ＡＢＥＧＩＮ／ＡＥＮＤブロック内では、プログラマは、メモリ依存性を規定する。図２３は、メモリ依存性の様々なタイプ２３０１、これらのセマンティクス２３０３、オーダリング要求２３０５及び使用事例２３０７を示す。さらに、いくつかのセマンティクスは、実装に応じて、ＡＢＥＧＩＮ／ＡＥＮＤブロック内の命令に適用される。例えば、いくつかの実施形態において、レジスタの依存性が許容されているが、レジスタに対する修正は、ＡＥＮＤを超えて持続していない。さらに、いくつかの実施形態において、ＡＢＥＧＩＮ／ＡＥＮＤブロックは、ＡＢＥＧＩＮ／ＡＥＮＤブロックへの／からの分岐がない状態で、ＡＢＥＧＩＮで入り、ＡＥＮＤで終了され（又はパターン認識に基づいて同様の状態に入る）なければならない。最後に、典型的には、命令ストリームは、修正できない。
【０３２０】
いくつかの実施例において、ＡＢＥＧＩＮ命令は、メモリデータブロックに対するポインタを含むソースオペランドを含む。このデータメモリブロックは、ＡＢＥＧＩＮ／ＡＥＮＤブロック内のコードを処理するために、ランタイム及びコア回路により利用される多くの情報を含む。
【０３２１】
図２４は、ＡＢＥＧＩＮ命令により指し示されるメモリデータブロックの例を示す。図示されるように、実装に応じて、メモリデータブロックは、シーケンス番号２４０１用のフィールド、ブロッククラス２４０３用のフィールド、実装識別子２４０５用のフィールド、保存状態エリアサイズ２４０７用のフィールド及びローカルストレージエリアサイズ２４０９用のフィールドを含む。
【０３２２】
シーケンス番号２４０１は、割込み前に、プロセッサがどれだけの（並列）計算を経たかを示す。ソフトウェアは、ＡＢＥＧＩＮの実行前に、シーケンス番号２４０１をゼロに初期化する。ＡＢＥＧＩＮの実行は、ゼロ以外の値をシーケンス番号２４０１に書き込んで、実行の進み具合を追跡する。完了すると、ＡＥＮＤの実行は、ゼロを書き込んで、その次の使用のために、シーケンス番号２４０１を再度初期化する。
【０３２３】
予め定義されたブロッククラス識別子２４０３（すなわち、ＧＵＩＤ）は、予め定義されたＡＢＥＧＩＮ／ＡＥＮＤブロッククラスを規定する。例えば、ＤＭＵＬＡＤＤ及びＤＧＥＭＭは、ブロッククラスとして予め定義され得る。予め定義されたクラスを用いて、バイナリトランスレータは、ヘテロジニアスハードウェアに対するマッピング解析を実行するために、バイナリを解析する必要はない。代わりに、変換器（例えば、バイナリトランスレータ）は、入力値を単に取得することにより、このＡＢＥＧＩＮ／ＡＥＮＤクラスのために予め生成された変換を実行する。ＡＢＥＧＩＮ／ＡＥＮＤに同封されたコードは、単に、非特化型コア中でこのクラスを実行するために用いられるコードとしての機能を果たすに過ぎない。
【０３２４】
実装ＩＤフィールド２４０５は、用いられる実行ハードウェアのタイプを示す。ＡＢＥＧＩＮの実行は、用いられるヘテロジニアスハードウェアのタイプを示すために、このフィールド２４０５を更新する。これは、実装が、ＡＢＥＧＩＮ／ＡＥＮＤコードを、異なるアクセラレーションハードウェアタイプを有し、又は、アクセラレータを一切有していないマシンへ移行する助けとなる。このフィールドは、ターゲット実装を適合させるように、保存されたコンテキストの可能な変換を可能にする。すなわち、エミュレータは、ＡＢＥＧＩＮ／ＡＥＮＤコードが割り込まれ、かつ、同じアクセラレータタイプを有していないマシンに移行される場合の移行後に、それがＡＥＮＤを抜けるまで、コードを実行するために用いられる。このフィールド２４０５はまた、ＡＢＥＧＩＮ／ＡＥＮＤブロックの実行の最中に割り込まれた場合でさえ、システムが、ＡＢＥＧＩＮ／ＡＥＮＤブロックを同じマシン内の異なるヘテロジニアスハードウェアに動的に再度割り当てられることを可能にし得る。
【０３２５】
状態保存エリアフィールド２４０７は、実装に固有である状態保存エリアのサイズ及びフォーマットを示す。実装は、状態保存エリアの実装に固有の部分が、ＣＰＵＩＤにおいて特定されたある最大値を超えないことを保証する。典型的には、ＡＢＥＧＩＮ命令の実行は、ＡＢＥＧＩＮ／ＡＥＮＤブロック、関連するフラグ及び追加の実装に固有の状態内で修正される汎用及びパックドデータレジスタの状態保存エリアへの書き込みを引き起こす。並列実行を容易にするために、レジスタの複数のインスタンスが書き込まれてよい。
【０３２６】
ローカルストレージエリア２４０９は、ローカルストレージエリアとして割り当てられる。予約するための記憶量は、典型的には、ＡＢＥＧＩＮに対する即値オペランドとして特定される。ＡＢＥＧＩＮ命令が実行されると、特定のレジスタ（例えば、Ｒ９）への書き込みが、ローカルストレージ２４０９のアドレスを用いて行われる。障害がある場合、このレジスタは、シーケンス番号を指し示すことが行われる。
【０３２７】
並列実行の各インスタンスは、一意的なローカルストレージエリア２４０９を受ける。アドレスは、並列実行のインスタンスごとに異なる。直列実行では、１つのストレージエリアが割り当てられる。ローカルストレージエリア２４０９は、アーキテクチャの汎用及びパックドデータレジスタを超えた一時的なストレージを提供する。ローカルストレージエリア２４０９は、ＡＢＥＧＩＮ／ＡＥＮＤブロックの外部にアクセスされるべきではない。
【０３２８】
図２５は、ＡＢＥＧＩＮ／ＡＥＮＤセマンティクスを用いるように構成されるメモリ２５０３の例を示す。ＡＢＥＧＩＮ／ＡＥＮＤをサポートし、かつ、このメモリ２５０３を利用するハードウェア（例えば、本明細書で説明される様々な処理要素）は図示されていない。詳細に説明されるように、メモリ２５０３は、使用対象のレジスタ２５０１、フラグ２５０５及び実装に固有の情報２５１１のインジケーションを含む保存状態エリア２５０７を含む。さらに、並列実行インスタンス毎にローカルストレージ２５０９がメモリ２５０３に格納される。
【０３２９】
図２６は、ＡＢＥＧＩＮ／ＡＥＮＤを用いた実行についての異なるモードでの動作の方法の例を示す。典型的には、この方法は、エンティティの組み合わせ、例えば、変換器及び実行回路により実行される。いくつかの実施形態において、スレッドは、このモードに入る前に変換される。
【０３３０】
２６０１において、実行の異なるモードは、例えば、実行の緩和モード（アクセラレータを用いる又は用いない）などに入る。通常、ＡＢＥＧＩＮ命令の実行からこのモードに入る。しかしながら、詳細に上述されるように、パターンマッチにより、このモードに入ることもあり得る。このモードに入ることは、シーケンス番号のリセットを含む。
【０３３１】
２６０３において、保存状態エリアへの書き込みが行われる。例えば、修正される汎用及びパックドデータレジスタ、関連するフラグ、追加の実装に固有の情報が書き込まれる。このエリアは、ブロック内で何か不具合（例えば、割込み）があった場合の実行の再開又はロールバックを可能にする。
【０３３２】
２６０５において、並列実行インスタンス毎にローカルストレージエリアが予約される。詳細に上述されたように、このエリアのサイズは、状態保存エリアフィールドにより指示される。
【０３３３】
２６０７において、ブロックの実行中、ブロックの進行具合が追跡される。例えば、命令が、実行に成功してリタイアされた場合、ブロックのシーケンス番号が更新される。
【０３３４】
２６０９において、ＡＥＮＤ命令が到達したか否かに応じた判断が、（例えば、ブロックが完了したか否かを判断するために）行われる。ＡＥＮＤ命令が到達していない場合、次に、２６１３において、ローカルストレージエリアは、中間結果を用いて更新される。可能ならば、実行は、これらの結果から取り出す。しかしながら、いくつかの例では、２６１５において、ＡＢＥＧＩＮ／ＡＥＮＤ前へのロールバックが発生する。例えば、ＡＢＥＧＩＮ／ＡＥＮＤブロックの実行中に例外又は割込みが発生した場合、命令ポインタは、ＡＢＥＧＩＮ命令を指し示し、Ｒ９レジスタは、中間結果を用いて更新されるメモリデータブロックを指し示す。再開すると、メモリデータブロックに保存された状態は、訂正ポイントで再開するために用いられる。さらに、状態保存エリアを含むメモリデータブロックの初期部が存在しない又はアクセス可能でない場合、ページフォールトが引き起こされる。ローカルストレージエリアに対するロード及びストアについて、通常の方式、すなわち、存在しない又はアクセス可能ではないページへの第１のアクセスでページフォールトが報告される。いくつかの例において、非アクセラレータ処理要素が再開時に用いられる。
【０３３５】
２６１１において、ブロックの完了に成功した場合、次に、破棄されたレジスタがフラグと共に元の状態に戻される。メモリ状態だけがブロック後に異なる。
【０３３６】
図２７は、ＡＢＥＧＩＮ／ＡＥＮＤを用いた実行についての異なるモードでの動作の方法の例を示す。典型的には、この方法は、エンティティの組み合わせ、例えば、バイナリ変換器及び実行回路により実行される。
【０３３７】
２７０１において、実行の異なるモードは、例えば、実行の緩和モード（アクセラレータを用いる又は用いない）などに入る。通常、ＡＢＥＧＩＮ命令の実行からこのモードに入る。しかしながら、詳細に上述されたように、パターンマッチにより、このモードに入ることもあり得る。このモードに入ることは、シーケンス番号のリセットを含む。
【０３３８】
２７０３において、保存状態エリアへの書き込みが行われる。例えば、修正される汎用及びパックドデータレジスタ、関連するフラグ及び追加の実装に固有の情報が書き込まれる。このエリアは、ブロック内で何か不具合（例えば、割込み）があった場合の実行の再開又はロールバックを可能にする。
【０３３９】
２７０５において、並列実行インスタンス毎にローカルストレージエリアが予約される。詳細に上述されたように、このエリアのサイズは、状態保存エリアフィールドにより指示される。
【０３４０】
２７０６において、ブロック内のコードが実行のために変換される。
【０３４１】
２７０７において、変換されたブロックの実行中、ブロックの進行具合が追跡される。例えば、命令が、実行に成功してリタイアされた場合、ブロックのシーケンス番号が更新される。
【０３４２】
２７０９において、ＡＥＮＤ命令が到達したか否かに応じた判断が、（例えば、ブロックが完了したか否かを判断するために）行われる。ＡＥＮＤ命令が到達していない場合、次に、２７１３において、ローカルストレージエリアは、中間結果を用いて更新される。可能ならば、実行は、これらの結果から取り出す。しかしながら、いくつかの例では、２７１５において、ＡＢＥＧＩＮ／ＡＥＮＤの前へのロールバックが発生する。例えば、ＡＢＥＧＩＮ／ＡＥＮＤブロックの実行中に例外又は割込みが発生した場合、命令ポインタは、ＡＢＥＧＩＮ命令を指し示し、Ｒ９レジスタは、中間結果を用いて更新されるメモリデータブロックを指し示す。再開すると、メモリデータブロックに保存された状態は、訂正ポイントで再開するために用いられる。さらに、状態保存エリアを含むメモリデータブロックの初期部が存在しない又はアクセス可能でない場合、ページフォールトが引き起こされる。ローカルストレージエリアに対するロード及びストアについて、通常の方式、すなわち、存在しない又はアクセス可能ではないページへの第１のアクセスでページフォールトが報告される。いくつかの例において、非アクセラレータ処理要素が再開時に用いられる。
【０３４３】
ブロックの完了に成功した場合、次に、２７１１において、破棄されたレジスタがフラグと共に元の状態に戻される。メモリ状態だけがブロック後に異なる。
【０３４４】
上述したように、いくつかの実施例では、（マルチプロトコル共通リンク（ＭＣＬ）を呼び出す）共通のリンクが、デバイス（例えば、図１及び図２において説明した処理要素）に到達するために用いられる。いくつかの実施形態において、これらのデバイスは、ＰＣＩエクスプレス（ＰＣＩｅ）デバイスとして見られる。このリンクは、リンク上で動的に多重化される３又はそれより多いプロトコルを有する。例えば、共通のリンクは、１）１又は複数の独自又は業界標準（例えば、ＰＣＩエクスプレス仕様又は同等の代替手段など）において規定され得るように、デバイス発見、デバイス構成、エラー報告、割込み、ＤＭＡスタイルのデータ転送及び様々なサービスを可能にする生産者／消費者、発見、構成、割込み（ＰＤＣＩ）プロトコル、２）デバイスが、コヒーレントな読み出し及び書き込み要求を処理要素に発行することを可能にするキャッシングエージェントコヒーレンス（ＣＡＣ）プロトコル、及び、３）処理要素が、別の処理要素のローカルメモリにアクセスすることを可能にするメモリアクセス（ＭＡ）プロトコルからなるプロトコルをサポートする。これらのプロトコルの特定の例では、（例えば、インテル（登録商標）オンチップシステムファブリック（ＩＯＳＦ）、インダイ相互接続（ＩＤＩ）、スケーラブルメモリ相互接続３＋（ＳＭＩ３＋））が提供される一方、本発明の基礎となる原理は、任意の特定のプロトコルのセットに限定されない。
【０３４５】
図１２０は、例示的なマルチチップリンク（ＭＣＬ）１２０２０を用いて通信可能に接続される２又はそれより多いチップ又はダイ（例えば、１２０１０、１２０１５）を含む例示的なマルチチップ構成１２００５を示す簡易ブロック図１２０００である。図１２０は、例示的なＭＣＬ１２０２０を用いて相互接続される２つ（又はそれより多い）ダイの例を示す一方、ＭＣＬの実装に関して本明細書で説明される原理及び特徴は、数ある潜在的な例の中でも特に、２又はそれより多いダイ（例えば、１２０１０、１２０１５）を接続すること、ダイ（又はチップ）を別のコンポーネントオフダイに接続すること、ダイを別のデバイス又はダイオフパッケージ（例えば、１２００５）に接続すること、ダイをＢＧＡパッケージ、インターポーザ上のパッチの実装（ＰＯＩＮＴ）を含む、ダイ（例えば、１２０１０）及び他のコンポーネントを接続する任意の相互接続又はリンクに適用され得ることを理解されたい。
【０３４６】
いくつかの例において、より大きなコンポーネント（例えば、ダイ１２０１０、１２０１５）は、それら自体を、例えば、システムオンチップ（ＳｏＣ）、マルチプロセッサチップ、又は、デバイス上、例として単一のダイ（例えば、１２０１０、１２０１５）上の、コア、アクセラレータなどのような複数のコンポーネント（１２０２６〜１２０３０及び１２０４０〜１２０４５）を含む他のコンポーネントなどのＩＣシステムであり得る。ＭＣＬ１２０２０は、潜在的に複数の別個のコンポーネント及びシステムから複雑かつ多様なシステムを構築すること対する柔軟性をもたらす。例として、ダイ１２０１０、１２０１５のそれぞれが製造されてよく、そうでなければ、２つの異なるエンティティにより提供され得る。さらに、ダイ及び他のコンポーネントは、それら自体が、デバイス（例えば、１２０１０、１２０１５のそれぞれ）内のコンポーネント（例えば、１２０２６〜１２０３０及び１２０４０〜１２０４５）の間の通信のためのインフラストラクチャを提供する相互接続又は他の通信ファブリック（例えば、１２０３１、１２０５０）を含むことができる。様々なコンポーネント及び相互接続（例えば、１２０３１、１２０５０）は、複数の異なるプロトコルをサポートする又は用いる。さらに、ダイ（例えば、１２０１０、１２０１５）の間の通信は、複数の異なるプロトコルを介したダイ上の様々なコンポーネント間のトランザクションを潜在的に含むことができる。
【０３４７】
マルチチップリンク（ＭＣＬ）の実施形態は、複数のパッケージオプション、複数のＩ／Ｏプロトコル、並びに、信頼性・可用性・保守性（ＲＡＳ）機能をサポートする。さらに、物理層（ＰＨＹ）は、物理的な電気層及び論理層を含むことができ、最大で、いくつかの場合において約４５ｍｍを超えるチャネル長を含む、より長いチャネル長をサポートできる。いくつかの実施例では、例示的なＭＣＬは、８〜１０Ｇｂ／ｓを超えるデータレートを含む、高データレートで動作できる。
【０３４８】
ＭＣＬの１つの例示的な実施例において、ＰＨＹ電気層は、従来のマルチチャネル相互接続解決手段（例えば、マルチチャネルＤＲＡＭ  Ｉ／Ｏ）を改善し、数ある潜在的な例の中でも特に、例として、調整された中間レール終端、低電力アクティブクロストーク除去、回路冗長、ビット毎のデューティサイクル訂正及びデスキュー、ライン符号化及び送信機等化を含む多数の機能により、例として、データレート及びチャネル構成を拡張する。
【０３４９】
ＭＣＬの１つの例示的な実施例において、ＰＨＹ論理層は、データレート及びチャネル構成を拡張する一方、電気層にわたって複数のプロトコルを転送する相互接続もできるようにする場合に（例えば、電気層機能）をさらに支援するように実装される。そのような実施例が、プロトコルに依存せず、潜在的に任意の既存又は将来の相互接続プロトコルと連動するように設計されるモジュラ共通物理層を提供及び定義する。
【０３５０】
図１２１を参照すると、簡易ブロック図１２１００は、マルチチップリンク（ＭＣＬ）の例示的な実装を含むシステムの少なくとも一部を表すことを示す。ＭＣＬは、第１のデバイス１２１０５（例えば、１又は複数のサブコンポーネントを含む第１のダイ）を、第２のデバイス１２１１０（例えば、１又は複数の他のサブコンポーネントを含む第２のダイ）と接続する物理的な電気接続（例えば、レーンとして実装されるワイヤ）を用いて実装され得る。図１２１００の高水準表現において示される具体例では、（チャネル１２１１５、１２１２０内の）すべての信号は、単方向であり得、レーンは、アップストリーム及びダウンストリームデータ転送の両方を有するデータ信号を提供し得る。図１２１のブロック図１２１００は、アップストリームコンポーネントとしての第１のコンポーネント１２１０５、ダウンストリームコンポーネントとしての第２のコンポーネント１２１１０、ダウンストリームチャネル１２１１５としてデータを送信するときに用いられるＭＣＬの物理レーン及びアップストリームチャネル１２１２０として（コンポーネント１２１１０から）データを受信するために用いられるレーンを指す一方、デバイス１２１０５、１２１１０間のＭＣＬが、デバイス間でデータを送信及び受信の両方を行うために、各デバイスにより用いられ得ることを理解されたい。
【０３５１】
１つの例示的な実施例において、ＭＣＬは、電気ＭＣＬ物理層（ＰＨＹ）１２１２５ａ，ｂ（又は、総称して１２１２５）を含む物理層と、実行可能な論理実装ＭＣＬ論理ＰＨＹ１２１３０ａ,ｂ（又は、総称して１２１３０）とを提供できる。電気又は物理ＰＨＹ１２１２５は、デバイス１２１０５、１２１１０間でデータが通信される物理的な接続を提供する。信号調整コンポーネント及び論理は、リンクの高データレート及びチャネル構成機能を確立するために、物理ＰＨＹ１２１２５と関連して実装されることができ、いくつかのアプリケーションが約４５ｍｍ又はそれより長い長さでの、密接にクラスタ化された物理的接続に関する。論理ＰＨＹ１２１３０は、クロック、リンクステート管理（例えば、リンク層１２１３５ａ、１２１３５ｂ）及びＭＣＬを介した通信に用いられる潜在的に複数の異なるプロトコル間でのプロトコル多重を容易にするための回路を含む。
【０３５２】
１つの例示的な実施例において、物理ＰＨＹ１２１２５は、チャネルごと（例えば、１２１１５、１２１２０）に、インバンドデータが送信されるデータレーンのセットを含む。この具体例では、５０個のデータレーンがアップストリーム及びダウンストリームチャネル１２１１５、１２１２０のそれぞれに提供されるが、レイアウト及び電力制約、所望のアプリケーション、デバイス制約などにより許される場合には、その他の数のレーンが用いられ得る。各チャネルは、チャネルに関するストローブ又はクロック信号用の１又は複数の専用レーン、チャネルに関する有効な信号用の１又は複数の専用レーン、ストリーム信号用の１又は複数の専用レーン、及び、リンクステートマシン管理又はサイドバンド信号用の１又は複数の専用レーンをさらに含むことができる。物理ＰＨＹは、サイドバンドリンク１２１４０をさらに含むことができ、いくつかの例では、数ある例の中でも特に、デバイス１２１０５、１２１１０を接続するＭＣＬについての状態遷移及び他の属性を調整するために用いられる双方向低周波制御信号リンクであり得る。
【０３５３】
上述したように、ＭＣＬの実装を用いて、複数のプロトコルがサポートされている。実際には、複数の独立したトランザクション層１２１５０ａ、１２１５０ｂが、各デバイス１２１０５、１２１１０において提供され得る。例として、各デバイス１２１０５、１２１１０は、数ある中でも、ＰＣＩ、ＰＣＩｅ、ＣＡＣなど、２又はそれより多いプロトコルをサポート及び利用してよい。ＣＡＣは、コアと、ラストレベルキャッシュ（ＬＬＣ）と、メモリと、グラフィックスとＩ／Ｏコントローラとの間で通信するオンダイに用いられるコヒーレントなプロトコルである。イーサネット（登録商標）プロトコル、インフィニバンドプロトコル及び他のＰＣＩｅファブリックベースのプロトコルを含む他のプロトコルもサポートされ得る。論理ＰＨＹ及び物理ＰＨＹの組み合わせは、数ある例の中でも特に、１つのダイ上のＳｅｒＤｅｓ  ＰＨＹ（ＰＣＩｅ、イーサネット（登録商標）、インフィニバンド又は他の高速ＳｅｒＤｅｓ）を、他のダイ上に実装されているその上位層に接続するダイ間相互接続として用いられることもできる。
【０３５４】
論理ＰＨＹ１２１３０は、ＭＣＬにおけるこれら複数のプロトコル間の多重化をサポートする。例として、専用のストリームレーンは、どのプロトコルが、チャネルのデータレーン上で実質的に同時に送信されるデータに適用されるかを識別するエンコードされたストリーム信号をアサートするために用いられ得る。さらに、論理ＰＨＹ１２１３０は、様々なプロトコルがサポート又は要求し得る様々なタイプのリンク状態遷移とネゴシエートする。いくつかの例において、チャネルの専用ＬＳＭ＿ＳＢレーンを介して送信されたＬＳＭ＿ＳＢ信号は、デバイス１２１０５、１２１１０間のリンク状態遷移を通信及びネゴシエートするために、サイドバンドリンク１２１４０と一緒に用いられ得る。さらに、リンクトレーニング、エラー検出、スキュー検出、デスキュー及び従来の相互接続についての他の機能が、論理ＰＨＹ１２１３０を部分的に用いて、置き換えられ又は統制され得る。例として、各チャネルにおける１又は複数の専用の有効な信号レーンを介して送信される有効な信号は、数ある例の中でも特に、リンクアクティビティをシグナリングし、スキュー及びリンクエラーを検出し、及び、他の特徴を実現させるために用いられ得る。図１２１の具体例では、複数の有効なレーンがチャネル毎に提供されている。例として、チャネル内のデータレーンは、（物理的に及び／又は論理的に）バンドル化又はクラスタ化され得、有効なレーンは、クラスタごとに提供され得る。さらに、複数のストローブレーンは、いくつかの場合において、数ある例の中でも特に、チャネルにおける複数のデータレーンクラスタ内のクラスタごとに専用のストローブ信号を提供するために提供され得る。
【０３５５】
上述したように、論理ＰＨＹ１２１３０は、ＭＣＬにより接続されたデバイス間で送信されるリンク制御信号をネゴシエート及び管理する。いくつかの実施例において、論理ＰＨＹ１２１３０は、ＭＣＬを介してリンク層制御メッセージを送信（すなわち、インバンド）するリンク層パケット（ＬＬＰ）生成回路１２１６０を含む。そのようなメッセージは、数ある例の中でも特に、データがリンク層制御データなどのリンク層−リンク層間メッセージングであることを識別するストリームレーンを有する、チャネルのデータレーンを介して送信され得る。ＬＬＰモジュール１２１６０を用いてイネーブルにされたリンク層メッセージは、デバイス１２１０５、１２１１０のリンク層１２１３５ａ、１２１３５ｂ間のそれぞれの他のリンク層間の特徴の中でも特に、リンク層状態遷移、電源管理、ループバック、ディセーブル、再センタリングスクランブルについてのネゴシエーション及び動作を支援する。
【０３５６】
図１２２を参照すると、例示的なＭＣＬの例示的な論理ＰＨＹを示す簡易ブロック図１２２００が示される。物理ＰＨＹ１２２０５は、論理ＰＨＹ１２２１０と、ＭＣＬのリンク層をサポートする追加の論理とを含むダイに接続され得る。ダイは、この例において、ＭＣＬ上に複数の異なるプロトコルをサポートする論理をさらに含み得る。例として、図１２２の例では、ＰＣＩｅ論理１２２１５がＣＡＣ論理１２２２０と共に提供され、その結果、２より多いプロトコル、又は、ＰＣＩｅ及びＣＡＣ以外のプロトコルがＭＣＬを介してサポートされる例を含む、潜在的に数多くある例の中でも特に、ダイは、２つのダイを接続する同じＭＣＬを介してＰＣＩｅ又はＣＡＣのいずれか一方を用いて通信できる。ダイ間でサポートされる様々なプロトコルは、サービス及び特徴のレベルを変化させることを提供できる。
【０３５７】
論理ＰＨＹ１２２１０は、（例えば、ＰＣＩｅ又はＣＡＣを介して受信した）ダイの上位層論理の要求と関連してリンク状態遷移をネゴシエートするためのリンクステートマシン管理論理１２２２５を含むことができる。いくつかの実施例において、論理ＰＨＹ１２２１０は、リンク試験及びデバッグ論理（例えば、１２２３０）をさらに含むことができる。上述したように、例示的なＭＣＬは、ＭＣＬの（数ある例示的な機能の中でも特に）プロトコルに依存せず、高性能かつ電力効率の良い機能を容易にするために、ＭＣＬを介してダイ間で送信される制御信号をサポートできる。例として、論理ＰＨＹ１２２１０は、上記の例において説明したように、専用のデータレーンを介したデータの送信及び受信と関連して、有効な信号、ストリーム信号及びＬＳＭサイドバンド信号の生成及び送信並びに受信及び処理をサポートできる。
【０３５８】
いくつかの実施例では、多重化（例えば、１２２３５）及び逆多重化（例えば、１２２４０）論理は、論理ＰＨＹ１２２１０に含まれ得る、又は、そうでなければ論理ＰＨＹ１２２１０にアクセス可能であり得る。例として、多重化論理（例えば、１２２３５）は、ＭＣＬ上に送信されるデータ（例えば、パケット、メッセージなどとして具現化される）を識別するために用いられ得る。多重化論理１２２３５は、データを統制するプロトコルを識別し、プロトコルを識別するためにエンコードされたストリーム信号を生成できる。例として、１つの例示的な実施例では、ストリーム信号は、１バイトの２つの１６進数のシンボル（例えば、ＣＡＣ：ＦＦｈ；ＰＣＩｅ：Ｆ０ｈ；ＬＬＰ：ＡＡｈ；サイドバンド：５５ｈなど）としてエンコードされ得、識別されたプロトコルにより統制されるデータについての同じウィンドウ（例えば、１バイトの時間周期ウィンドウ）中に送信され得る。同様に、逆多重化論理１２２４０は、到着したストリーム信号を解釈してストリーム信号をデコードし、データレーン上のストリーム信号と共に同時に受信したデータに適用されるプロトコルを識別するために使用され得る。次に、逆多重化論理１２２４０は、プロトコルに固有のリンク層の処理を適用（又は確保）し、対応するプロトコル論理（例えば、ＰＣＩｅ論理１２２１５又はＣＡＣ論理１２２２０）によりデータを処理させることができる。
【０３５９】
論理ＰＨＹ１２２１０は、電源管理タスク、ループバック、ディセーブル、再センタリング、スクランブルなどを含む様々なリンク制御機能を処理するために用いられ得るリンク層パケット論理１２２５０をさらに含むことができる。ＬＬＰ論理１２２５０は、数ある機能の中でも特に、ＭＣＬＰを介したリンク層−リンク層間メッセージを容易にすることができる。ＬＬＰシグナリングに対応するデータはまた、そのデータレーンＬＬＰデータを識別するためにエンコードされた専用のストリーム信号レーン上に送信されたストリーム信号により識別され得る。多重化及び逆多重化論理（例えば、１２２３５、１２２４０）は、ＬＬＰトラフィックに対応するストリーム信号を生成及び解釈し、並びに、適切なダイ論理（例えば、ＬＬＰ論理１２２５０）によりそのようなトラフィックを処理させるために用いられこともできる。同様に、ＭＣＬＰのいくつかの実施例では、専用のサイドバンド（例えば、サイドバンド１２２５５及びサポート論理）、例えば、数ある例の中でも特に、非同期及び／又は低周波サイドバンドチャネルを含むことができる。
【０３６０】
論理ＰＨＹ論理１２２１０は、専用のＬＳＭサイドバンドレーンを介してリンクステート管理メッセージングを生成及び受信（及び使用）できるリンクステートマシン管理論理をさらに含むことができる。例として、ＬＳＭサイドバンドレーンは、数ある潜在的な例の中でも特に、リンクトレーニング状態に進むためにハンドシェーキングを実行し、電源管理状態（例えば、Ｌ１状態）を終了するために用いられ得る。ＬＳＭサイドバンド信号は、数ある例の中でも特に、リンクのデータ信号、有効信号及びストリーム信号と整合していないが、代わりにシグナリング状態遷移に対応し、リンクにより接続された２つのダイ又はチップ間のリンクステートマシンを調整するという点で非同期信号であり得る。専用のＬＳＭサイドバンドレーンを提供することは、いくつかの例では、数ある例示的な利益の中でも特に、アナログフロントエンド（ＡＦＥ）の従来のスケルチ及び受信検出回路が除去されることを可能にし得る。
【０３６１】
図１２３を参照すると、簡易ブロック図１２３００は、ＭＣＬを実装するために用いられる論理の別の表現を図示することが示されている。例として、論理ＰＨＹ１２２１０は、複数の異なるプロトコル（例えば、ＰＣＩｅ、ＣＡＣ、ＰＤＣＩ、ＭＡなど）１２３１５、１２３２０、１２３２５及びシグナリングモード（例えば、サイドバンド）のうちのいずれか一つが、例示的なＭＣＬの物理層とインタフェース接続できる規定の論理ＰＨＹインタフェース（ＬＰＩＦ）１２３０５と共に提供される。いくつかの実施例において、多重化及びアービトレーション論理１２３３０は、論理ＰＨＹ１２２１０から分離した層として提供されることもできる。一例では、ＬＰＩＦ１２３０５は、このＭｕｘＡｒｂ層１２３０の両側におけるインタフェースとして提供され得る。論理ＰＨＹ１２２１０は、別のインタフェースを通じて、物理ＰＨＹ（例えば、ＭＣＬ  ＰＨＹのアナログフロントエンド（ＡＦＥ）１２２０５）とインタフェース接続できる。
【０３６２】
ＬＰＩＦは、上位層に対して透過的なＬＰＩＦの下で完全に異なるＰＨＹが実装され得るように、上位層（例えば、１２３１５、１２３２０、１２３２５）からＰＨＹ（論理及び電気／アナログ）を取り除くことができる。これは、モジュール方式を促進することを支援し、設計において再利用でき、数ある例の中でも特に、基礎となるシグナリング技術ＰＨＹが更新された場合に、上位層は無傷のままでいることができる。さらに、ＬＰＩＦは、多重化／逆多重化、ＬＳＭ管理、エラー検出及びハンドリング、及び、論理ＰＨＹの他の機能をイネーブルにする多数の信号を定義できる。例として、以下のテーブルは、例示的なＬＰＩＦに関して定義され得る信号の少なくとも一部を要約したものである。
【表３】
0006988040.tif 000004
【０３６３】
テーブルで触れられているように、いくつかの実施例では、アライメントメカニズムが、ＡｌｉｇｎＲｅｑ／ＡｌｉｇｎＡｃｋハンドシェイクを通じて提供され得る。例えば、物理層は、リカバリに入る場合、いくつかのプロトコルは、パケットフレーミングを失うかもしれない。パケットのアライメントは、例として、リンク層による訂正フレーミング識別を保証するために、訂正され得る。物理層は、リカバリに入った場合、ＳｔａｌｌＲｅｑ信号をアサートでき、その結果、リンク層は、新たにアラインされたパケットを転送する準備ができた場合に、ストール信号をアサートする。物理層論理は、パケットがアラインされるか否かを判断するために、ストール及び有効の両方をサンプリングできる。例として、パケットアライメントを支援するために有効を使用する他の代替的な実装を含む、数ある潜在的な実装の中でも特に、ストール及び有効がサンプリングされてアサートされるまで、物理層はｔｒｄｙを駆動してリンク層パケットを排出することを継続できる。
【０３６４】
様々なフォールトトレンランスがＭＣＬ上の信号に対して定義され得る。例として、フォールトトレンランスは、有効、ストリーム、ＬＳＭサイドバンド、低周波サイドバンド、リンク層パケット及び他のタイプの信号に対して定義され得る。ＭＣＬの専用のデータレーンを介して送信されたパケット、メッセージ及び他のデータに対するフォールトトレンランスは、データを統制する特定のプロトコルに基づき得る。いくつかの実施例において、エラー検出及びハンドリングメカニズムは、数ある潜在的な例の中でも特に、巡回冗長検査（ＣＲＣ）、リトライバッファなどが提供され得る。例として、ＭＣＬを介して送信されるＰＣＩｅパケットに関して、３２ビットのＣＲＣが、（（例えば、再生メカニズムを通じた）保証された配信を用いた）ＰＣＩｅトランザクション層パケット（ＴＬＰ）に利用され得、１６ビットのＣＲＣが、（損失が多くなるように設計され得る（例えば、再生が適用されない））ＰＣＩｅリンク層パケットに利用され得る。さらに、ＰＣＩｅフレーミングトークンに関して、特定のハミング距離（例えば、４（４）のハミング距離）は、数ある例の中でも特に、トークン識別子に対して定義され得、パリティ及び４ビットのＣＲＣも利用され得る。他方では、ＣＡＣパケットに関して、１６ビットのＣＲＣが利用され得る。
【０３６５】
いくつかの実施例において、フォールトトレンランスは、（例えば、保証ビット及びシンボルロックを支援するために）低から高（すなわち、０から１）に遷移するために有効な信号を利用するリンク層パケット（ＬＬＰ）に対して定義される。さらに、一例において、ＭＣＬ上のＬＬＰデータ内の障害を判断する基礎として用いられ得る数ある定義された特性の中でも特に、特定の数の連続的な同一のＬＬＰは、送信されるように定義され得、応答はタイムアウトした後にリトライするリクエスタを用いて、応答は、各要求に対して予期され得る。さらなる例において、フォールトトレンランスは、有効な信号に対してもたらされる可能性があり、例として、（例えば、８つのＵＩに対して有効な信号を高に保持することにより）、有効な信号を通じて時間周期ウィンドウ又はシンボル全体にわたって広がる。さらに、ストリーム信号内のエラー又は障害は、数ある例の中でも特に、ストリーム信号のエンコーディング値に関するハミング距離を維持することにより、防止され得る。
【０３６６】
論理ＰＨＹの実装は、エラー検出、エラー報告及びエラー処理論理を含む。いくつかの実施例において、例示的なＭＣＬの論理ＰＨＹは、数ある例の中でも特に、（例えば、有効及びストリームレーン上の）ＰＨＹ層デフレーミングエラー、（例えば、ＬＳＭ状態遷移に関する）サイドバンドエラー、（例えば、ＬＳＭ状態遷移にとって重大な）ＬＬＰ内のエラーを検出する論理を含むことができる。いくつかのエラー検出／解決は、数ある例の中でも特に、ＰＣＩｅに固有のエラーを検出するのに適合するＰＣＩｅ論理などの上位層論理に委任され得る。
【０３６７】
デフレーミングエラーの場合、いくつかの実施例では、１又は複数のメカニズムが、エラー処理論理を通じて提供され得る。デフレーミングエラーは、関連するプロトコルに基づいて処理され得る。例として、いくつかの実施例では、リンク層が、リトライをトリガするためにエラーを通知できる。デフレーミングは、論理ＰＨＹデフレーミングの再再アライメントも引き起こし得る。さらに、数ある技術の中でも特に、論理ＰＨＹの再センタリングが実行され得、シンボル／ウィンドウロックが再獲得され得る。センタリングは、いくつかの例において、到着したデータを検出するのに最適なポイントに受信機クロックフェーズを移動するＰＨＹを含むことができる。この文脈における「最適」は、ノイズ及びクロックジッタに対して最も余裕があることを指し得る。数ある例の中でも特に、再センタリングは、例としてＰＨＹが低電力状態からウェイクアップした場合に実行される簡易センタリング機能を含むことができる。
【０３６８】
他のタイプのエラーは、他のエラー処理技術に関連し得る。例として、サイドバンドで検出されたエラーは、（例えば、ＬＳＭの）対応する状態のタイムアウトメカニズムを通じて捕まえられ得る。エラーは、ログに記録され得、次に、リンクステートマシンは、リセットに遷移され得る。ＬＳＭは、再開コマンドがソフトウェアから受信されるまで、リセット状態に維持することができる。別の例では、ＬＬＰエラー、例えば、リンク制御パケットエラーは、ＬＬＰシーケンスに対する確認応答が受信されなかった場合、ＬＬＰシーケンスを再開できるタイムアウトメカニズムを用いて処理され得る。
【０３６９】
いくつかの実施形態において、上記のプロトコルのそれぞれは、ＰＣＩｅの変形である。ＰＣＩｅデバイスは、バスと関連付けられた共通のアドレス空間を用いて通信する。このアドレス空間は、バスアドレス空間又はＰＣＩｅアドレス空間である。いくつかの実施形態において、ＰＣＩｅデバイスは、ＰＣＩｅアドレス空間とは異なり得る内部アドレス空間内のアドレスを用いる。
【０３７０】
ＰＣＩｅ仕様は、ＰＣＩｅデバイスがそのローカルメモリ（又はその一部）をバスにさらし得るメカニズムを定義し、ひいては、ＣＰＵ、又は、そのメモリに直接アクセスするバスに取り付けられる他のデバイスをイネーブルにする。典型的には、各ＰＣＩｅデバイスは、ＰＣＩベースアドレスレジスタ（ＢＡＲ）と称されるＰＣＩｅアドレス空間内の専用の領域を割り当てられる。さらに、デバイスがさらすアドレスは、ＰＣＩ  ＢＡＲ内のそれぞれのアドレスにマッピングされる。
【０３７１】
いくつかの実施形態において、ＰＣＩｅデバイス（例えば、ＨＣＡ）は、入力／出力メモリマッピングユニット（ＩＯＭＭＵ）を用いて、その内部アドレスとＰＣＩｅバスアドレスとを変換する。他の実施形態において、ＰＣＩｅデバイスは、ＰＣＩアドレス変換サービス（ＡＴＳ）を用いて、アドレス変換及び解決を実行してよい。いくつかの実施形態において、タグ、例えば、処理アドレス空間ＩＤ（ＰＡＳＩＤ）タグは、特定の処理の仮想アドレス空間に属するように変換されるアドレスを規定するために用いられる。
【０３７２】
図２８は、一実施例に関する追加の詳細を示す。上記で説明される実施例に示すように、この実施例は、ホストメモリ２８６０を有するホストプロセッサ２８０２にマルチプロトコルリンク２８００を介して結合される、アクセラレータメモリ２８５０を有するアクセラレータ２８０１を含む。すでに述べたように、アクセラレータメモリ２８５０は、ホストメモリ２８６０とは異なるメモリ技術を利用してよい（例えば、アクセラレータメモリは、ＨＢＭ又はスタック型ＤＲＡＭであってよく、一方、ホストメモリは、ＳＤＲＡＭであってよい）。
【０３７３】
マルチプレクサ２８１１及び２８１２は、マルチプロトコルリンク２８００がＰＣＤＩ、ＣＡＣ及びＭＡプロトコル（例えば、ＳＭＩ３＋）トラフィックをサポートする動的に多重化されたバスであり、それぞれがアクセラレータ２８０１及びホストプロセッサ２８０２内の異なる機能コンポーネントに転送され得るという事実を強調表示するように示されている。例として、制限されるものではないが、これらのプロトコルは、ＩＯＳＦ、ＩＤＩ及びＳＭＩ３＋を含んでよい。一実施例において、アクセラレータ２８０１のＰＣＩｅ論理２８２０は、コマンドを実行する場合、１又は複数のアクセラレータコア２８３０による使用のために仮想−物理アドレス変換をキャッシングするためのローカルＴＬＢ２８２２を含む。すでに述べたように、仮想メモリ空間は、アクセラレータメモリ２８５０とホストメモリ２８６０との間で分配される。同様に、ホストプロセッサ２８０２上のＰＣＩｅ論理は、ＰＣＩｅ  Ｉ／Ｏデバイス２８０６のメモリアクセスを管理するためのＩ／Ｏメモリ管理ユニット（ＩＯＭＭＵ）２８１０、及び、一実施例においてアクセラレータ２８０１を含む。図示されるように、アクセラレータ上のＰＣＩｅ論理２８２０及びホストプロセッサ上のＰＣＩｅ論理２８０８では、ＰＣＤＩプロトコルを用いて通信して、デバイス発見、レジスタアクセス、デバイス構成及び初期化、割込み処理、ＤＭＡ処理及びアドレス変換サービス（ＡＴＳ）などの機能を実行する。すでに述べたように、ホストプロセッサ２８０２上のＩＯＭＭＵ２８１０は、これらの機能に対する制御及び調整を主要目的として動作し得る。
【０３７４】
一実施例において、アクセラレータコア２８３０は、アクセラレータにより必要とされる機能を実行する処理エンジン（要素）を含む。さらに、アクセラレータコア２８３０は、ホストメモリ２８６０に格納されているページをローカルにキャッシングするためのホストメモリキャッシュ２８３４と、アクセラレータメモリ２８５０に格納されているページをキャッシングするためのアクセラレータメモリキャッシュ２８３２とを含んでよい。一実施例において、アクセラレータコア２８３０は、アクセラレータ２８０１とホストプロセッサ２８０２との間で共有されるキャッシュラインがコヒーレントを維持することを確保するために、ＣＡＣプロトコルを介してホストプロセッサ２８０２のコヒーレンス及びキャッシュ論理２８０７と通信する。
【０３７５】
アクセラレータ２８０１のバイアス／コヒーレンス論理２８４０は、マルチプロトコルリンク２８００を介した不必要な通信を減らしつつ、データコヒーレンスを確保するために本明細書で説明される様々なデバイス／ホストバイアス技術（例えば、ページレベルの粒度）を実装する。図示されるように、バイアス／コヒーレンス論理２８４０は、ＭＡメモリトランザクション（例えば、ＳＭＩ３＋）を用いてホストプロセッサ２８０２のコヒーレンス及びキャッシュ論理２８０７と通信する。コヒーレンス及びキャッシュ論理２８０７は、そのＬＬＣ２８０９、ホストメモリ２８６０、アクセラレータメモリ２８５０及びキャッシュ２８３２、２８３４、及び、コア２８０５の個別のキャッシュのそれぞれに格納されるデータのコヒーレンシを維持することを担っている。
【０３７６】
要約すると、アクセラレータ２８０１の一実施例は、ホストプロセッサ２８０２で実行されるソフトウェアに対するＰＣＩｅデバイスとして現れ、（多重化されたバスに対してＰＣＩｅプロトコルを効果的に再フォーマット化する）ＰＤＣＩプロトコルによりアクセスされる。アクセラレータ２８０１は、アクセラレータデバイスＴＬＢ及び標準のＰＣＩｅアドレス変換サービス（ＡＴＳ）を用いて共有仮想メモリに参加してよい。アクセラレータはまた、コヒーレンス／メモリエージェントとして処理され得る。特定機能（例えば、以下で説明されるＥＮＱＣＭＤ、ＭＯＶＤＩＲ）は、（例えば、ワークサブミッションのために）ＰＤＣＩ上で利用可能であり、一方、アクセラレータは、ＣＡＣを用いて、アクセラレータで、及び、特定のバイアス遷移フローにおいて、ホストデータをキャッシュしてよい。ホストからアクセラレータメモリへのアクセス（又は、アクセラレータからのホストバイアスアクセス）は、説明されるように、ＭＡプロトコルを用いてよい。
【０３７７】
図２９に示されるように、一実施例において、アクセラレータは、デバイスバックエンドリソース２９０５へのアクセスを提供するようにプログラミングされ得るＰＣＩ構成レジスタ２９０２及びＭＭＩＯレジスタ２９０６を含む。一実施例において、ＭＭＩＯレジスタ２９０６用のベースアドレスは、ＰＣＩ構成空間内のベースアドレスレジスタ（ＢＡＲ）２９０１のセットにより特定される。以前の実装とは異なり、本明細書で説明されるデータストリーミングアクセラレータ（ＤＳＡ）の一実施例は、複数のチャネル又はＰＣＩ機能を実装しておらず、そのため、デバイスには、各レジスタについての１つのインスタンスのみがある。しかしながら、単一プラットフォームでは、１より多いＤＳＡデバイスがあってよい。
【０３７８】
実施例では、ここでは説明されない追加の性能を提供してよい、又は、レジスタをデバッグしてよい。任意のそのようなレジスタは、実装ごとに決まることが考慮されるべきである。
【０３７９】
ＰＣＩ構成空間アクセスは、アラインされた１バイトアクセス、２バイトアクセス又は４バイトアクセスとして実行される。ＰＣＩ構成空間において、未実装のレジスタ及び予約されたビットにアクセスする規則については、ＰＣＩエクスプレスベースの仕様を参照する。
【０３８０】
ＢＡＲ０領域（機能、構成及びステータスレジスタ）へのＭＭＩＯ空間アクセスは、アラインされた１バイトアクセス、２バイトアクセス、４バイトアクセス又は８バイトアクセスとして実行される。８バイトアクセスは、８バイトレジスタにのみ用いられるべきである。ソフトウェアは、未実装のレジスタを読み出し又は書き込みすべきではない。ＢＡＲ２及びＢＡＲ４領域へのＭＭＩＯ空間アクセスは、ＥＮＱＣＭＤ、ＥＮＱＣＭＤＳ又はＭＯＶＤＩＲ６４Ｂ命令（以下で詳細に説明される）を用いて、６４バイトアクセスとして実行されるべきである。ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳは、共有されるように構成されるワークキュー（ＳＷＱ）にアクセスするために用いられるべきであり、ＭＯＶＤＩＲ６４Ｂは、専用として構成されるワークキュー（ＤＷＱ）にアクセスするために用いられなければならい。
【０３８１】
ＤＳＡ  ＰＣＩ構成空間の一実施例は、３つの６４ビットＢＡＲ２９０１を実装する。デバイス制御レジスタ（ＢＡＲ０）は、デバイス制御レジスタの物理ベースアドレスを含む６４ビットＢＡＲである。これらのレジスタは、デバイス性能、デバイスを構成及びイネーブルにする制御、及び、デバイスステータスに関する情報を提供する。ＢＡＲ０領域のサイズは、割込みメッセージストレージ２９０４のサイズに依存する。サイズは、割込みメッセージストレージエントリ２９０４の数×１６を３２ＫＢに加えて、次の２のべき乗に切り上げられる。例えば、デバイスが１０２４個の割込みメッセージストレージエントリ２９０４をサポートする場合、割込みメッセージストレージは１６ＫＢであり、ＢＡＲ０のサイズは６４ＫＢである。
【０３８２】
ＢＡＲ２は、特権及び非特権ポータルの物理ベースアドレスを含む６４ビットＢＡＲである。各ポータルは、６４バイトのサイズであり、別々の４ＫＢページ上に配置される。これは、ポータルがＣＰＵページテーブルを用いて異なるアドレス空間に独立にマッピングされることを可能にする。ポータルは、記述子をデバイスにサブミットするために用いられる。特権ポータルは、カーネルモードソフトウェアにより用いられ、非特権ポータルは、ユーザモードソフトウェアにより用いられる。非特権ポータルの数は、サポートされるワークキューの数と同じである。特権ポータルの数は、ワークキュー（ＷＱ）の数×（ＭＳＩ‐Ｘテーブルのサイズ−１）である。記述子をサブミットするために用いられるポータルのアドレスは、デバイスがどのＷＱに記述子を配置するか、ポータルは特権が与えられているか又は特権が与えられていないか、及び、どのＭＳＩ−Ｘテーブルエントリが完了割込みのために用いられ得るか、を判断することを可能にする。例えば、デバイスが８つのＷＱをサポートする場合、所与の記述子に対するＷＱは、（ポータルアドレス＞＞１２）かつ０ｘ７である。ポータルアドレス＞＞１５が０である場合、ポータルは、特権が与えられていない。そうでなければ、ポータルは、特権が与えられており、完了割込みに用いられるＭＳＩ−Ｘ２９０３テーブルインデックスは、ポータルアドレス＞＞１５である。ビット５：０は０でなければならない。ビット１１：６は無視される。したがって、ページ上で任意の６４バイトでアラインされたアドレスは、同じ効果を伴って用いられ得る。
【０３８３】
ワークキュー構成（ＷＱＣＦＧ）レジスタを用いて構成される場合、非特権ポータルを用いる記述子サブミッションは、ＷＱの占有閾値を対象とする。特権ポータルを用いた記述子サブミッションは、当該閾値を対象とはしない。ＳＷＱに対する記述子サブミッションは、ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ用いてサブミットされなければならない。ＳＷＱポータルに対するその他の書き込み動作は無視される。ＤＷＱに対する記述子サブミッションは、６４バイト書き込み動作を用いてサブミットされなければならない。ソフトウェアは、切れ目のない６４バイト書き込みを保証するために、ＭＯＶＤＩＲ６４Ｂを用いる。ディセーブルにされ、又は、専用のＷＱポータルに対するＥＮＱＣＭＤ又はＥＮＱＣＭＤＳは、リトライを返す。ＤＷＱポータルに対するその他の書き込み動作は無視される。ＢＡＲ２アドレス空間に対する任意の読み出し処理は、オール１を返す。カーネルモード記述子は、完了割込みを受信するために、特権ポータルを用いてサブミットされるべきである。カーネルモード記述子が、非特権ポータルを用いてサブミットされた場合、要求され得る完了割込みがない。ユーザモード記述子は、特権又は非特権ポータルのいずれか一方を用いてサブミットされてよい。
【０３８４】
ＢＡＲ２領域内のポータルの数は、デバイスによりサポートされているＷＱの数×ＭＳＩ−Ｘ２９０３テーブルのサイズである。ＭＳＩ‐Ｘテーブルのサイズは、典型的には、ＷＱの数に１を加えたものである。そのため、例えば、デバイスが８つのＷＱをサポートする場合、ＢＡＲ２の有用なサイズは、８×９×４ＫＢ＝２８８ＫＢとなるであろう。ＢＡＲ２合計サイズは、次の２のべき乗に切り上げられる、又は、５１２ＫＢとなるであろう。
【０３８５】
ＢＡＲ４は、ゲストポータルの物理ベースアドレスを含む６４ビットＢＡＲである。各ゲストポータルは、６４バイトのサイズであり、別々の４ＫＢページに配置される。これは、ポータルがＣＰＵ拡張ページテーブル（ＥＰＴ）を用いて異なるアドレス空間に独立にマッピングされることを可能にする。ＧＥＮＣＡＰ内の割込みメッセージストレージサポートフィールドが０である場合、このＢＡＲは実装されていない。
【０３８６】
ゲストポータルは、記述子をデバイスにサブミットするために、ゲストカーネルモードソフトウェアにより用いられてよい。ゲストポータルの数は、割込みメッセージストレージ内のエントリの数×サポートされるＷＱの数である。記述子をサブミットするために用いられるゲストポータルのアドレスは、デバイスが記述子用のＷＱを判断することを可能にし、また、割込みメッセージストレージエントリが、記述子完成用の完了割込みを生成するために用いることを可能にする（カーネルモード記述子である場合で、要求完了割込みフラグが記述子に設定されている場合）。例えば、デバイスが８つのＷＱをサポートする場合、所与の記述子に対するＷＱは、（ゲストポータルアドレス＞＞１２）及び０ｘ７であり、完了割込みに用いられる割込みテーブルエントリインデックスは、ゲストポータルアドレス＞＞１５である。
【０３８７】
一実施例において、ＭＳＩ−Ｘは、ＤＳＡが提供し、かつ、ＤＳＡがレガシＰＣＩ割込み又はＭＳＩを実装していないＰＣＩｅ割込み機能のみである。このレジスタ構造の詳細については、ＰＣＩエクスプレス仕様に従う。
【０３８８】
一実施例において、３つのＰＣＩエクスプレス機能が、アドレス変換を制御する。これらの機能の値の特定の組み合わせのみが、テーブルＡに示されるように、サポートされ得る。一般的な制御レジスタ（ＧＥＮＣＴＲＬ）内のイネーブルビットが１に設定されるときに、値がチェックされる。
【表４】
0006988040.tif 000005
【０３８９】
これらの機能のいずれかが、ソフトウェアによりに変更される一方、デバイスがイネーブルである場合、デバイスは、停止してよく、エラーがソフトウェアエラーレジスタに報告される。
【０３９０】
一実施例において、ソフトウェアは、デバイスが、ＰＡＳＩＤを用いてアドレス変換を実行するか否かを制御するために、ＰＡＳＩＤ機能を構成する。ＰＡＳＩＤがディセーブルである場合、物理アドレスのみが用いられてよい。ＰＡＳＩＤがイネーブルである場合、仮想又は物理アドレスが、ＩＯＭＭＵ構成に応じて用いられてよい。ＰＡＳＩＤがイネーブルである場合、アドレス変換サービス（ＡＴＳ）及びページ要求サービス（ＰＲＳ）の両方がイネーブルにされるべきである。
【０３９１】
一実施例において、ソフトウェアは、メモリアクセスを実行する前に、デバイスがアドレスを変換すべきか否かを制御するために、ＡＴＳ機能を構成する。アドレス変換がＩＯＭＭＵ２８１０においてイネーブルである場合、ＡＴＳは、受諾可能なシステム性能を取得するために、デバイスにおいてイネーブルでなければならない。アドレス変換がＩＯＭＭＵ２８１０においてイネーブルにされない場合、ＡＴＳは、ディセーブルにされなければならない。ＡＴＳがディセーブルである場合、物理アドレスのみが用いられてよく、すべてメモリアクセスは、未変換アクセスを用いて実行される。ＰＡＳＩＤがイネーブルにされる場合、ＡＴＳがイネーブルにされなければならない。
【０３９２】
一実施例において、ソフトウェアは、アドレス変換が失敗した場合に、デバイスがページを要求できるか否かを制御するために、ＰＲＳ機能を構成する。ＰＡＳＩＤがイネーブルにされる場合、ＰＲＳは、イネーブルにされなければならず、ＰＡＳＩＤがディセーブルにされる場合、ＰＲＳは、ディセーブルにされなければならない。
【０３９３】
いくつかの実施例では、１又は複数のプロセッサコア、アクセラレータデバイス及び／又は他のタイプの処理デバイス（例えば、Ｉ／Ｏデバイス）間でシームレスに共有される仮想メモリ空間を利用する。特に、一実施例では、同じ仮想メモリ空間がコア、アクセラレータデバイス及び／又は他の処理デバイス間で共有される共有仮想メモリ（ＳＶＭ）アーキテクチャを利用する。さらに、いくつかの実施例では、共通の仮想メモリ空間を用いてアドレス指定されるヘテロジニアス形式の物理システムメモリを含む。ヘテロジニアス形式の物理システムメモリは、ＤＳＡアーキテクチャと接続するために、異なる物理インタフェースを用いてよい。例えば、アクセラレータデバイスは、高帯域幅メモリ（ＨＢＭ）などのローカルアクセラレータメモリに直接結合されてよく、各コアは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などのホスト物理メモリに直接結合されてよい。この例において、共有仮想メモリ（ＳＶＭ）は、アクセラレータ、プロセッサコア及び／又は他の処理デバイスが、仮想メモリアドレスの整合性セットを用いて、ＨＢＭ及びＤＲＡＭにアクセスできるように、ＨＢＭ及びＤＲＡＭの組み合わせられた物理メモリにマッピングされる。
【０３９４】
これら及び他の特徴のアクセラレータは、以下で詳細に説明される。概要の目的で、異なる実装は、以下のインフラストラクチャ機能のうちの１又は複数を含んでよい。
【０３９５】
共有仮想メモリ（ＳＶＭ）：いくつかの実施例では、ユーザレベルアプリケーションが、記述子内の仮想アドレスを用いて直接的にＤＳＡにコマンドをサブミットすることを可能にするＳＶＭをサポートする。ＤＳＡは、ページフォールトの処理を含む入力／出力メモリ管理ユニット（ＩＯＭＭＵ）を用いて、仮想アドレスを物理アドレスに変換することをサポートしてよい。記述子により参照される仮想アドレス範囲は、複数のヘテロジニアスメモリタイプにわたって分散された複数のページにまたがってよい。さらに、一実施例ではまた、データバッファが物理メモリ内で連続的である限り、物理アドレスの使用をサポートする。
【０３９６】
部分的な記述子完成：ＳＶＭサポートを用いて、動作は、アドレス変換中に、ページフォールトに遭遇する可能性がある。いくつかのケースでは、デバイスは、障害に遭遇した時点で、対応する記述子の処理を終了し、部分的な完了及び障害情報を示す完了記録をソフトウェアに提供して、ソフトウェアが、改善策を講じて、障害の解決後に動作をリトライすることを可能にしてよい。
【０３９７】
バッチ処理：いくつかの実施例では、「バッチ」に記述子をサブミットすることをサポートする。バッチ記述子は、実質的に連続的なワーク記述子（すなわち、実際のデータ処理を含む記述子）のセットを指し示す。バッチ記述子を処理する場合、ＤＳＡは、特定メモリ及びからワーク記述子をフェッチして、これらを処理する。
【０３９８】
ステートレスデバイス：一実施例における記述子は、記述子ペイロード自体に入っている記述子を処理するためにすべての情報が必要とされるように、設計される。これは、デバイスが、そのスケーラビリティを改善するわずかなクライアント固有の状態を格納することを可能にする。用いられる場合に、トラステッドソフトウェアにより構成される１つの例外が、完了割込みメッセージである。
【０３９９】
キャッシュ割り当て制御：これは、アプリケーションが、キャッシュに書き込むか、キャッシュをバイパスしてメモリに直接的に書き込むかを規定することを可能にする。一実施例において、完了記録は、常にキャッシュに書き込まれる。
【０４００】
共有のワークキュー（ＳＷＱ）サポート：以下で詳細に説明されるように、いくつかの実施例では、エンキューコマンド（ＥＮＱＣＭＤ）及びエンキューコマンド（ＥＮＱＣＭＤＳ）命令を用いて、共有のワークキュー（ＳＷＱ）を通じてスケーラブルなワークサブミッションをサポートする。この実施例において、ＳＷＱは、複数のアプリケーションにより共有される。
【０４０１】
専用のワークキュー（ＤＷＱ）サポート：いくつかの実施例では、ＭＯＶＤＩＲ６４Ｂ命令を用いた、専用のワークキュー（ＤＷＱ）を通じた高スループットワークサブミッションに対するサポートがある。この実施例では、ＤＷＱは、ある特定のアプリケーションに専用のものである。
【０４０２】
ＱｏＳサポート：いくつかの実施例では、サービス品質（ＱｏＳ）レベルが、（例えば、カーネルドライバにより）ワークキューごとに特定されることを可能にする。次に、異なるワークキューを異なるアプリケーションに割り当ててよく、異なるアプリケーションからのワーク（ｗｏｒｋ）が、異なる優先度を用いてワークキューからディスパッチされることを可能にする。ワークキューは、ファブリックＱｏＳに対して特定のチャネルを用いるためにプログラミングされ得る。
【０４０３】
バイアスキャッシュコヒーレンスメカニズム
【０４０４】
一実施例では、スタック型ＤＲＡＭ又はＨＢＭなどの直接的に取り付けられたメモリを用いてアクセラレータの性能を改善し、直接的に取り付けられたメモリを用いてアクセラレータを使用するアプリケーションに関するアプリケーション開発を簡略化する。この実施例では、アクセスレータ付属メモリが、システムメモリの一部としてマッピングされ、（例えば、現在のＩＯＭＭＵ実装において用いられる）共有仮想メモリ（ＳＶＭ）技術を用いるが、完全なシステムのキャッシュコヒーレンスと関連付けられる典型的な性能上の欠点を被ることなく、アクセスされることを可能にする。
【０４０５】
面倒なキャッシュコヒーレンスのオーバヘッドなしで、システムメモリの一部としてアクセスレータ付属メモリにアクセスする能力は、有益な動作環境をアクセラレータオフロードにもたらす。システムアドレスマッピングの一部としてメモリにアクセスする能力は、ホストソフトウェアが、オペランドをセットアップし、従来のＩ／Ｏ  ＤＭＡデータコピーのオーバヘッドなしで、計算結果にアクセスすることを可能にする。そのような従来のコピーは、簡単なメモリアクセスと比較してすべて非効率であるドライバコール、割込み、及び、メモリマッピングされたＩ／Ｏ（ＭＭＩＯ）アクセスに関する。同時に、キャッシュコヒーレンスのオーバヘッドなしでアクセスレータ付属メモリにアクセスする能力は、オフロードされた計算の実行時間にとって重要であり得る。実質的なストリーミング書き込みメモリトラフィックを伴う場合、例えば、キャッシュコヒーレンスのオーバヘッドは、アクセラレータにより見られる有効な書き込み帯域幅を半分に削減できる。オペランドセットアップの効率性、結果的なアクセスの効率性、アクセラレータ計算の効率性のすべては、どれくらいアクセラレータのオフロードが機能しているかを判断する役割を果たす。（例えば、オペランドをセットアップし、結果を得る）オフロード機能のコストは非常に高く、オフロードしても全く効果がない場合がある、又は、非常に大きなジョブのみにアクセラレータを制限し得る。アクセラレータが計算を実行する効率性は、同じ効果を有し得る。
【０４０６】
一実施例では、メモリアクセスを開始するエンティティ（例えば、アクセラレータ、コアなど）及びアクセスされるメモリ（例えば、ホストメモリ又はアクセラレータメモリ）に応じて異なるメモリアクセス及びコヒーレンス技術を適用する。これらの技術は、一般に、アクセスレータ付属メモリを提供する「コヒーレンスバイアス」メカニズムと称され、２つのセットのキャッシュコヒーレンスフローは、１つがその付属メモリへの効率的なアクセラレータのアクセスを最適化し、２つ目が、アクセスレータ付属メモリへのホストアクセス及びアクセスレータ付属メモリに対する共有アクセラレータ／ホストアクセスを最適化する。さらに、これらのフロー間の切り替えに関する２つの技術を含み、１つは、アプリケーションソフトウェアにより駆動され、もう一つは、独立したハードウェアの暗示により駆動される。コヒーレンスフローのセットの両方において、ハードウェアは、完全なキャッシュコヒーレンスを維持する。
【０４０７】
図３０に概して示されるように、一実施例では、アクセラレータ３００１と、プロセッサコア及びＩ／Ｏ回路３００３を有する１又は複数のコンピュータプロセッサチップとを含むコンピュータシステムを適用し、アクセラレータ３００１は、マルチプロトコルリンク２８００を介してプロセッサと結合される。一実施例において、マルチプロトコルリンク３０１０は、それらに限定されないが、詳細に上述されたものを含む複数の異なるプロトコルをサポートする動的に多重化されたリンクである。しかしながら、本発明の基礎となる原理は、任意の特定のプロトコルのセットに限定されるものではないことに留意されたい。さらに、アクセラレータ３００１及びコアＩ／Ｏ３００３は、実装に応じて、同じ半導体チップ又は異なる半導体チップ上に集積されてよいことに留意する。
【０４０８】
例示された実施例では、アクセラレータメモリバス３０１２は、アクセラレータ３００１をアクセラレータメモリ３００５に結合し、別々のホストメモリバス３０１１は、コアＩ／Ｏ３００３をホストメモリ３００７に結合する。すでに述べたように、アクセラレータメモリ３００５は、高帯域幅メモリ（ＨＢＭ）又はスタック型ＤＲＡＭ（これらのいくつかの例は、本明細書で説明される）を有してよく、ホストメモリ３００７は、ＤＲＡＭ、例えば、ダブルデータレート・シンクロナスダイナミックランダムアクセスメモリ（例えば、ＤＤＲ３  ＳＤＲＡＭ、ＤＤＲ４  ＳＤＲＡＭなど）を有してよい。しかしながら、本発明の基礎となる原理は、任意の特定のタイプのメモリ又はメモリプロトコルに限定されない。
【０４０９】
一実施例において、アクセラレータ３００１、及び、プロセッサチップ３００３内の処理コア上で実行する「ホスト」ソフトウェアの両方は、「ホストバイアス」フロー及び「デバイスバイアス」フローと称されるプロトコルフローについての２つの別個のセットを用いて、アクセラレータメモリ３００５にアクセスする。以下で説明されるように、一実施例では、特定のメモリアクセスのためにプロトコルフローを変調すること及び／又は選択することに関する複数のオプションをサポートする。
【０４１０】
コヒーレンスバイアスフローは、アクセラレータ３００１と、プロセッサチップ３００３のうちの１つとの間のマルチプロトコルリンク３０１０の２つのプロトコル層、すなわち、ＣＡＣプロトコル層及びＭＡプロトコル層上に部分的に実装される。一実施例において、コヒーレンスバイアスフローは、（ａ）新たな方式でＣＡＣプロトコルにおける既存のオペコードを用いること、（ｂ）既存のＭＡ標準に対して新たなオペコードを加えること、及び、（ｃ）（リンクがＣＡＣ及びＰＣＤＩのみを含む前の）マルチプロトコルリンク３００１にＭＡプロトコルのサポートを加えることにより、イネーブルにされる。マルチプロトコルリンクは、ただ単にＣＡＣ及びＭＡをサポートすることに限定されないことに留意する。一実施例では、少なくともそれらのプロトコルをサポートすることが単に要求される。
【０４１１】
本明細書で用いられるように、図３０に示される「ホストバイアス」フローは、アクセラレータ３００１が取り付けられるプロセッサチップ３００３内の標準コヒーレンスコントローラ３００９を通じてアクセラレータメモリ３００５に、アクセラレータ自体からの要求を含むすべての要求を集中させるフローのセットである。これは、独自のメモリにアクセスするために、アクセラレータ３００１に迂回路を取らせるが、アクセラレータ３００１及びプロセッサコアＩ／Ｏ３００３の両方からのアクセスが、プロセッサの標準コヒーレンスコントローラ３００９を用いてコヒーレントに維持されることを可能にする。一実施例において、プロセッサコア３００９がコヒーレンスコントローラ３００９に要求を発行する方式と同じ又は同様の方式で、フローは、ＣＡＣオペコードを用いて、マルチプロトコルリンクを介してプロセッサのコヒーレンスコントローラ３００９に要求を発行する。例えば、プロセッサチップのコヒーレンスコントローラ３００９は、アクセラレータ３００１からの要求に起因するＵＰＩ及びＣＡＣコヒーレンスメッセージ（例えば、スヌープ）を、アクセラレータに代わってすべてのピアプロセッサコアチップ（例えば、３００３）及び内部プロセッサエージェントに発行してよく、それらは、プロセッサコア３００３からの要求の場合と同じ程度であろう。この態様において、コヒーレンシは、アクセラレータ３００１によりアクセスされるデータと、プロセッサコアＩ／Ｏ３００３との間で維持される。
【０４１２】
一実施例において、コヒーレンスコントローラ３００９はまた、マルチプロトコルリンク２８００を介してアクセラレータのメモリコントローラ３００６にメモリアクセスメッセージを条件付きで発行する。これらのメッセージはまた、データに、マルチプロトコルリンク２８００のプロセッサのコヒーレンスコントローラ３００９に返されることを強制し、その結果、マルチプロトコルリンク２８００を介したＣＡＣ応答としてアクセラレータ３００１に返される代わりに、コヒーレンスコントローラ３００９がこれらのプロセッサダイに対してローカルにあるメモリコントローラに送信し、データがアクセラレータ３００１の内部のエージェントに直接返されることを可能にする新たなオペコードを含むメッセージと同様である。
【０４１３】
図３０に示される「ホストバイアス」モードの一実施例では、アクセスレータ付属メモリ３００５をターゲットとするプロセッサコア３００３からのすべて要求は、通常のホストメモリ３００７をターゲットにしていたのと同様に、直接的にプロセッサコヒーレンシコントローラ３００９に送信される。コヒーレンスコントローラ３００９は、これらの標準キャッシュコヒーレンスアルゴリズムを適用して、それらがアクセラレータ３００１からのアクセスのために行うのと同様に、及び、それらが、通常のホストメモリ３００７へのアクセスのために行うのと同様に、これらの標準キャッシュコヒーレンスメッセージを送信してよい。コヒーレンスコントローラ３００９はまた、このクラスの要求のためにマルチプロトコルリンク２８００を介してＭＡコマンドを条件付きで送信するが、この場合、ＭＡフローは、マルチプロトコルリンク２８００にわたってデータを返す。
【０４１４】
図３１に示される「デバイスバイアス」フローは、アクセラレータ３００１が、ホストプロセッサのキャッシュコヒーレンスコントローラ３００７に尋ねることなくそのローカルの付属メモリ３００５にアクセスすることを可能にするフローである。より具体的には、これらのフローは、アクセラレータ３００１が、マルチプロトコルリンク２８００を介して要求を送信することなく、メモリコントローラ３００６を介してそのローカルの付属メモリにアクセスすることを可能にする。
【０４１５】
「デバイスバイアス」モードにおいて、プロセッサコアＩ／Ｏ３００３からの要求は、上記の「ホストバイアス」に関する説明のように発行されるが、これらのフローのＭＡ部分において異なって完了される。「デバイスバイアス」の場合、アクセスレータ付属メモリ３００５に対するプロセッサ要求は、あたかも、それらが「未キャッシュ」の要求として発行されていたかのように完了される。この「未キャッシュ」の慣例は、デバイスバイアスフローの対象であるデータがプロセッサのキャッシュ階層に決してキャッシュされることがないように採用されている。これは、アクセラレータ３００１が、プロセッサ上のキャッシュコヒーレンスコントローラ３００９に尋ねることなくそのメモリ３００５内のデバイスバイアスデータにアクセスすることを可能にするという事情がある。
【０４１６】
一実施例において、「未キャッシュ」プロセッサコア３００３アクセスフローに対するサポートは、プロセッサのＣＡＣバス上で、グローバルに監視される１回使用（「ＧＯ−ＵＯ」）応答で実装される。この応答は、データの一部をプロセッサコア３００３に返し、データの値のみを一旦用いるようプロセッサに命令する。これは、データのキャッシングを防止し、「未キャッシュ」フローの要求を満たす。ＧＯ−ＵＯ応答をサポートしていないコアを有するシステムにおいて、「未キャッシュ」フローは、マルチプロトコルリンク２８００のＭＡ層上、及び、プロセッサコア３００３のＣＡＣバス上のマルチメッセージ応答シーケンスを用いて実装されてよい。
【０４１７】
具体的には、プロセッサコアが、アクセラレータ３００１における「デバイスバイアス」ページをターゲットとするように得られる場合、アクセラレータは、アクセラレータからターゲットキャッシュラインに対する将来の要求をブロックするように、いくつかの状態をセットアップし、特別な「デバイスバイアスヒット」応答をマルチプロトコルリンク２８００のＭＡ層上に送信する。このＭＡメッセージに応じて、プロセッサのキャッシュコヒーレンスコントローラ３００９は、要求するプロセッサコア３００３にデータを返し、当該データを返した直後にスヌープ無効メッセージが続く。プロセッサコア３００３がスヌープ無効を完了したものとして認めた場合、キャッシュコヒーレンスコントローラ３００９は、別の特別なＭＡ「デバイスバイアスＢｏｃｋ完了」メッセージをマルチプロトコルリンク２８００のＭＡ層上のアクセラレータ３００１に送り返す。この完了メッセージは、アクセラレータ３００１に前述のブロック状態をクリアにさせる。
【０４１８】
図１０７は、バイアスを用いた実施形態を示す。一実施例において、デバイスとホストバイアスフローとの選択は、アクセラレータメモリ３００５内にバイアステーブル１０７０７として維持され得るバイアストラッカーデータ構造により駆動される。このバイアステーブル１０７０７は、アクセラレータ付属メモリページ毎に１又は２ビットを含むページ−グラニュラ構造（ｐａｇｅ-ｇｒａｎｕｌａｒ  ｓｔｒｕｃｔｕｒｅ）（すなわち、メモリページの粒度で制御される）であってよい。バイアステーブル１０７０７は、（例えば、バイアステーブル１０７０７の頻繁に／最近用いられたエントリをキャッシュする）アクセラレータ内のバイアスキャッシュ１０７０３を用いて、又は、用いることなく、アクセスレータ付属メモリ３００５のスティールされたメモリ（ｓｔｏｌｅｎ  ｍｅｍｏｒｙ）範囲で実装されてよい。代替的に、バイアステーブル１０７０７全体が、アクセラレータ３００１内に維持されてもよい。
【０４１９】
一実施例において、アクセスレータ付属メモリ３００５へのそれぞれのアクセスと関連付けられるバイアステーブルエントリは、アクセラレータメモリへの実際のアクセスの前にアクセスされ、以下の動作を実行させる。
・デバイスバイアス内でこれらのページを見つけるアクセラレータ３００１からのローカル要求が、アクセラレータメモリ３００５に直接的に転送される。
・ホストバイアス内でこれらのページを見つけるアクセラレータ３００１からのローカル要求が、マルチプロトコルリンク２８００上のＣＡＣ要求としてプロセッサ３００３に転送される。
・デバイスバイアス内でこれらのページを見つけるプロセッサ３００３からのＭＡ要求が、上記で説明した「未キャッシュ」フローを用いて要求を完了する。
・ホストバイアス内でこれらのページを見つけるプロセッサ３００３からのＭＡ要求が、通常のメモリ読み出しのように要求を完了する。
【０４２０】
ページのバイアス状態は、ソフトウェアベースのメカニズム、ハードウェア支援型のソフトウェアベースのメカニズムのいずれか一方により、又は、制限されたセットの場合、純粋にハードウェアベースのメカニズムにより変更され得る。
【０４２１】
バイアス状態を変更するための１つのメカニズムは、ＡＰＩコール（例えば、ＯｐｅｎＣＬ）を採用し、バイアス状態を変更するように指示するアクセラレータ３００１にメッセージを順番に送信（又は、コマンド記述子をエンキュー）するアクセラレータのデバイスドライバを順番に呼び出し、いくつかの遷移に関して、ホストにおいてキャッシュフラッシュ処理を実行する。キャッシュフラッシュ処理は、ホストバイアスからデバイスバイアスへの遷移に必要とされるが、逆の遷移には必須ではない。
【０４２２】
いくつかの場合、ソフトウェアが、いつバイアス遷移ＡＰＩコールを行い、いつページ要求バイアス遷移を識別するかを判断することは難しい。そのような場合、アクセラレータは、バイアス遷移（暗示）メカニズムを実装してよく、バイアス遷移の必要性を検出し、それを示すメッセージをそのドライバに送信する。暗示メカニズムは、ホストバイアスページへのアクセラレータのアクセス、又は、デバイスバイアスページへのホストのアクセスをトリガし、かつ、割込みを介してアクセラレータのドライバにイベントをシグナリングするバイアステーブルルックアップに対応するメカニズムと同じくらい簡単であり得る。
【０４２３】
いくつかの実施例では、バイアス遷移状態の値をイネーブルにするために、第２のバイアス状態ビットを必要とし得ることに留意する。これは、システムが、メモリページにアクセスすることを継続することを可能にする一方、それらのページは、バイアス変更の処理にある（すなわち、キャッシュが部分的にフラッシュされ、後続の要求に起因するインクリメントキャッシュ汚染が抑制されなければならない場合）。
【０４２４】
一実施例に従う例示的な処理が図３２に示される。処理は、本明細書で説明されるシステム及びプロセッサアーキテクチャ上に実装され得るが、任意の特定のシステム又はプロセッサアーキテクチャに限定されない。
【０４２５】
３２０１において、ページの特定のセットがデバイスバイアス内に置かれる。すでに述べたように、これは、（例えば、各ページと関連付けられたビットを設定することにより）ページがデバイスバイアス内にあることを示すために、バイアステーブル内のこれらのページに対するエントリを更新することにより実現され得る。一実施例において、一旦デバイスバイアスに設定されると、ページは、ホストキャッシュメモリにキャッシュされていないことが保証される。３２０２において、ページがデバイスメモリから割り当てられる（例えば、ソフトウェアが、ドライバ／ＡＰＩコールを開始することによりページを割り当てる）。
【０４２６】
３２０３において、オペランドがプロセッサコアから割り当てられたページにプッシュされる。一実施例において、これは、（例えば、ＯｐｅｎＣＬ  ＡＰＩコールを介して）ホストバイアスｎオペランドページをフリップするために、ＡＰＩコールを用いるソフトウェアにより実現される。必要とされるデータコピー又はキャッシュフラッシュがなく、オペランドデータは、ホストキャッシュ階層内の一部の任意の位置におけるこのステージで終了してよい。
【０４２７】
３２０４において、アクセラレータデバイスは、オペランドを用いて結果を生成する。例えば、それは、コマンドを実行して、そのローカルメモリから直接的にデータを処理してよい（例えば、上述した３００５）。一実施例において、ソフトウェアは、ＯｐｅｎＣＬ  ＡＰＩを用いて、オペランドページをデバイスバイアスにフリップして戻す（例えば、バイアステーブルを更新する）。ＡＰＩコールの結果として、ワーク記述子は、（例えば、以下で説明されるように、専用のワークキュー上での共有を介して）デバイスにサブミットされる。ワーク記述子は、ホストキャッシュからオペランドページをフラッシュするようデバイスに命令してよく、結果として（例えば、ＣＡＣプロトコルにおけるＣＬＦＬＵＳＨを用いて実行される）キャッシュフラッシュをもたらす。一実施例において、アクセラレータは、ホスト関連コヒーレンスオーバヘッドなしで実行され、データを結果ページにダンプする。
【０４２８】
３２０５において、割り当てられたページから結果が引き出される。例えば、一実施例において、ソフトウェアは、結果ページをホストバイアスにフリップするために、（例えば、ＯｐｅｎＣＬ  ＡＰＩを介して）１又は複数のＡＰＩコールを行う。この動作は、一部のバイアス状態を変更させ得るが、任意のコヒーレンス又はキャッシュフラッシュ動作を生じさせない。次に、ホストプロセッサコアは、必要に応じて、結果のデータにアクセスし、キャッシュし、共有することができる。最後に、３２０６において、割り当てられたページは、（例えば、ソフトウェアを介して）解放される。
【０４２９】
オペランドが１又は複数のＩ／Ｏデバイスから解放される同様の処理が、図３３に示される。３３０１において、ページの特定のセットがデバイスバイアス内に置かれる。すでに述べたように、これは、（例えば、各ページと関連付けられたビットを設定することにより）ページがデバイスバイアス内にあることを示すために、バイアステーブル内のこれらのページに対するエントリを更新することにより実現され得る。一実施例において、一旦デバイスバイアスに設定されると、ページは、ホストキャッシュメモリにキャッシュされていないことが保証される。３３０２において、ページがデバイスメモリから割り当てられる（例えば、ソフトウェアが、ドライバ／ＡＰＩコールを開始することによりページを割り当てる）
【０４３０】
３３０３において、オペランドは、Ｉ／Ｏエージェントから割り当てられたページにプッシュされる。一実施例において、これは、データを書き込むために、非割り当て格納を用いて、Ｉ／Ｏエージェント及びＩ／ＯエージェントにＤＭＡ要求をポストするソフトウェアにより実現される。一実施例において、データは、ホストキャッシュ階層に決して割り当てられることはなく、ターゲットページがデバイスバイアス内に留まる。
【０４３１】
３３０４において、アクセラレータデバイスは、オペランドを用いて結果を生成する。例えば、ソフトウェアは、アクセラレータデバイスにワークをサブミットしてよく、必要とされるページ遷移はない（すなわち、ページはデバイスバイアス内に留まる）。一実施例において、アクセラレータデバイスは、ホスト関連コヒーレンスオーバヘッドなしで実行され、アクセラレータは、データを結果ページにダンプする。
【０４３２】
３３０５において、（例えば、ソフトウェアからの指示の下）Ｉ／Ｏエージェントは、割り当てられたページから結果を引き出す。例えば、ソフトウェアは、ＤＭＡ要求をＩ／Ｏエージェントにポストしてよい。ソースページが、デバイスバイアスに留まる場合、必要とされるページ遷移はない。一実施例において、Ｉ／Ｏブリッジは、ＲｄＣｕｒｒ（現在の読み出し）要求を用いて、結果ページからデータのキャッシュ不能なコピーをつかむ。
【０４３３】
いくつかの実施例において、ワークキュー（ＷＱ）は、ソフトウェア、サービス品質（ＱｏＳ）を実装するために用いられるアービタ及び公平性ポリシ、記述子を処理するための処理エンジン、アドレス変換及びキャッシングインタフェース、及び、メモリ読み出し／書き込みインタフェースによりサブミットされた「記述子」を保持する。記述子は、行われるワークの範囲を定義する。図３４に図示されるように、一実施例では、専用のワークキュー３４００及び共有のワークキュー３４０１といった２つの異なるタイプのワークキューがある。専用のワークキュー３４００は、単一のアプリケーション３４１３に対する記述子を格納する一方、共有のワークキュー３４０１は、複数のアプリケーション３４１０−３４１２によりサブミットされた記述子を格納する。ハードウェアインタフェース／アービタ３４０２は、特定のアービトレーションポリシに従って（例えば、各アプリケーション３４１０−３４１３及びＱｏＳ／公平性ポリシの処理要件に基づいて）、ワークキュー３４００−３４０１からアクセラレータ処理エンジン３４０５に記述子をディスパッチする。
【０４３４】
図１０８ａ〜図１０８Ｂは、ワークキューベースの実装と共に用いられるメモリマッピングされたＩ／Ｏ（ＭＭＩＯ）空間レジスタを示す。バージョンレジスタ１０８０７は、デバイスによりサポートされているこのアーキテクチャ仕様のバージョンを報告する。
【０４３５】
一般的な機能レジスタ（ＧＥＮＣＡＰ）１０８０８は、デバイスの一般的な機能、例えば、最大転送サイズ、最大バッチサイズなどを規定する。テーブルＢは、ＧＥＮＣＡＰレジスタにおいて特定され得る様々なパラメータ及び値を列挙する。
【表５】
0006988040.tif 000006
【０４３６】
一実施例において、ワークキュー機能レジスタ（ＷＱＣＡＰ）１０８１０は、ワークキューの機能、例えば、動作についての専用及び／又は共有モードに関するサポート、エンジンの数、ワークキューの数などを規定する。以下のテーブルＣは、構成され得る様々なパラメータ及び値を列挙する。
【表６】
0006988040.tif 000007
【０４３７】
一実施例において、オペレーション機能レジスタ（ＯＰＣＡＰ）１０８１１は、デバイスによりサポートされるオペレーションタイプを規定するビットマスクである。各ビットは、ビット位置と同じコードを有するオペレーションタイプに対応する。例えば、このレジスタのビット０は、Ｎｏ−ｏｐオペレーション（コード０）に対応する。ビットは、オペレーションがサポートされている場合に設定され、オペレーションがサポートされていない場合にクリアされる。
【表７】
0006988040.tif 000008
【０４３８】
一実施例において、一般的な構成レジスタ（ＧＥＮＣＦＧ）１０８１２は、仮想チャネル（ＶＣ）ステアリングタグを規定する。以下のテーブルＥを参照する。
【表８】
0006988040.tif 000009
【０４３９】
一実施例において、一般的な制御レジスタ（ＧＥＮＣＴＲＬ）１０８１３は、ハードウェア又はソフトウェアエラーに対して割込みが生成したか否かを示す。以下のテーブルＦを参照する。
【表９】
0006988040.tif 000010
【０４４０】
一実施例において、デバイスイネーブルレジスタ（ＥＮＡＢＬＥ）は、エラーコード、デバイスがイネーブルか否かに応じたインジケータ、及び、デバイスリセット値を格納する。さらなる詳細については、以下のテーブルＧを参照する。
【表１０】
0006988040.tif 000011
【０４４１】
一実施例において、割込み要因レジスタ（ＩＮＴＣＡＵＳＥ）は、割込みの要因を示す値を格納する。以下のテーブルＨを参照する。
【表１１】
0006988040.tif 000012
【０４４２】
一実施例において、コマンドレジスタ（ＣＭＤ）１０８１４は、ドレインＷＱ、ドレインＰＡＳＩＤ及びドレインオールコマンドをサブミットするために用いられる。アボート領域は、要求されたオペレーションがドレインであるか、アボートであるかを示す。このレジスタに書き込む前に、ソフトウェアは、任意のコマンドが、このレジスタを介してサブミットされる前に完了したことを確保し得る。このレジスタに書き込む前に、ソフトウェアは、コマンド構成レジスタ、及び、完了記録が要求された場合はコマンド完了記録アドレスレジスタも構成してよい。
【０４４３】
ドレインオールコマンドは、すべてのＷＱ及びすべてのエンジン内のすべての未処理の記述子をドレイン又はアボートする。ドレインＰＡＳＩＤコマンドは、すべてのＷＱ及びすべてのエンジン内の特定のＰＡＳＩＤを用いて記述子をドレイン又はアボートする。ドレインＷＱは、特定のＷＱ内のすべての記述子をドレイン又はアボートする。実装に応じて、任意のドレインコマンドは、待機する必要がある記述子に加えて、他の記述子の完了を待ってよい。
【０４４４】
アボート領域が１である場合、ソフトウェアは、影響のある記述子が廃棄されることを要求している。しかしながら、ハードウェアは、これらの一部又はすべてをさらに完了してよい。記述子が廃棄された場合、書き込まれる完了記録はなく、その記述子に対して生成される完了割込みはない。他のメモリアクセスの一部又はすべてが発生し得る。
【０４４５】
コマンドの完了は、完了割込みを生成することにより（要求された場合）、このレジスタのステータスフィールドをクリアにすることにより示される。完了がシグナリングされたときに、すべての影響のある記述子は、完了又は廃棄のいずれか一方であり、任意の影響のある記述子に起因して生成されるさらなるアドレス変換、メモリ読み出し、メモリ書き込み又は割込みはない。以下のテーブルＩを参照する。
【表１２】
0006988040.tif 000013
【０４４６】
一実施例において、ソフトウェアエラーステータスレジスタ（ＳＷＥＲＲＯＲ）１０８１５は、記述子をサブミットした場合のエラー、記述子内の完了記録アドレスを変換するときのエラー、記述子内の完了記録アドレス有効フラグが０である場合、記述子を検証するときのエラー、及び、記述子内の完了記録アドレス有効フラグが０である場合にページフォールトなど、記述子を処理している間のエラーなど、複数の異なるタイプのエラーを格納する。以下のテーブルＪを参照する。
【表１３】
0006988040.tif 000014
0006988040.tif 000015
【０４４７】
一実施例において、ハードウェアエラーステータスレジスタ（ＨＷＥＲＲＯＲ）１０８１６は、ソフトウェアエラーステータスレジスタと同様の方式である（上記を参照）。
【０４４８】
一実施例において、グループ構成レジスタ（ＧＲＰＣＦＧ）１０８１７は、ワークキュー／エンジングループごとに構成データを格納する（図３６〜図３７を参照）。特に、グループ構成テーブルは、エンジンに対するワークキューのマッピングを制御するＢＡＲ０におけるレジスタのアレイである。エンジンと同じ数のグループがあるが、ソフトウェアは、必要とするグループの数を構成してよい。それぞれのアクティブなグループは、１又は複数のワークキュー及び１又は複数のエンジンを含む。任意の未使用のグループは、０に等しいＷＱフィールド及びエンジンフィールドの両方を有していなければならない。グループ内の任意のＷＱにサブミットされた記述子は、グループ内の任意のエンジンにより処理されてよい。それぞれのアクティブなワークキューは、単一のグループ内になければならない。アクティブなワークキューは、対応するＷＱＣＦＧレジスタのＷＱサイズフィールドがゼロ以外のものである。グループ内に無いエンジンはいずれもインアクティブである。
【０４４９】
各ＧＲＰＣＦＧレジスタ１０８１７は、３つのサブレジスタに分割されてよく、各サブレジスタは、１又は複数の３２ビットワードである（テーブルＫ〜Ｍを参照）。デバイスはイネーブルである間、これらのレジスタは、読み取り専用であり得る。それらは、ＷＱＣＡＰのワークキュー構成サポートフィールドが０である場合も読み取り専用である。
【０４５０】
ＢＡＲ０内のサブレジスタのオフセットは、グループＧごとに、０≦Ｇ＜エンジンの数であり、一実施例では以下のとおりである。
【表１４】
0006988040.tif 000016
【表１５】
0006988040.tif 000017
【表１６】
0006988040.tif 000018
【０４５１】
一実施例において、ワークキュー構成レジスタ（ＷＱＣＦＧ）１０８１８は、各ワークキューのオペレーションを規定するデータを格納する。ＷＱ構成テーブルは、ＢＡＲ０における１６バイトレジスタのアレイである。ＷＱ構成レジスタの数は、ＷＱＣＡＰ内のＷＱフィールドの数と一致する。
【０４５２】
各１６バイトＷＱＣＦＧレジスタは、４つの３２ビットサブレジスタに分割され、アラインされた６４ビット読み出し又は書き込み動作を用いて、読み出され又は書き込まれてよい。
【０４５３】
デバイスがイネーブルの間、又は、ＷＱＣＡＰのワークキュー構成サポートフィールドが０である場合、各ＷＱＣＦＧ−Ａサブレジスタは、読み取り専用である。
【０４５４】
ＷＱＣＡＰのワークキュー構成サポートフィールドが０でない限り、各ＷＱＣＦＧ−Ｂはいつでも書き込み可能である。ＷＱがイネーブルであるときに、ＷＱ閾値フィールドがＷＱサイズより大きい値を含む場合、ＷＱはイネーブルにされず、ＷＱエラーコードは４に設定される。ＷＱがイネーブルの間、ＷＱ閾値フィールドがＷＱサイズより大きい値で書き込まれている場合、ＷＱはディセーブルであり、ＷＱエラーコードは４に設定される。
【０４５５】
ＷＱがイネーブルの間、各ＷＱＣＦＧ−Ｃサブレジスタは読み取り専用である。それは、ＷＱイネーブルを１に設定する前又は同時に書き込まれてよい。ＷＱＣＡＰのワークキュー構成サポートフィールドが０である場合、以下のフィールド、すなわち、ＷＱモード、ＷＱ障害のブロック・イネーブル（ＷＱ  Ｆａｕｌｔ  ｏｎ  Ｂｌｏｃｋ  Ｅｎａｂｌｅ）及びＷＱ優先度のフィールドは、常に読み取り専用である。たとえＷＱＣＡＰのワークキュー構成サポートフィールドが０であるとしても、ＷＱＣＦＧ−Ｃの以下のフィールド、すなわち、ＷＱ  ＰＡＳＩＤ及びＷＱ  Ｕ／Ｓのフィールドは、ＷＱがイネーブルにされていない場合に書き込み可能である。
【０４５６】
各ＷＱＣＦＧ−Ｄサブレジスタは、いつでも書き込み可能である。しかしながら、デバイスがイネーブルにされていない場合、それは、ＷＱイネーブルを１に設定するエラーである。
【０４５７】
ＷＱイネーブルが１に設定されている場合、ＷＱイネーブル及びＷＱエラーコードフィールドの両方がクリアされる。次に、ＷＱイネーブル又はＷＱエラーコードのいずれか一方は、ＷＱのイネーブル化に成功したか否かを示すゼロ以外の値に設定される。
【０４５８】
すべてのＷＱＣＦＧレジスタのＷＱサイズフィールドの合計は、ＧＥＮＣＡＰ内のＷＱサイズフィールドの合計より大きくすることができない。この制約は、デバイスがイネーブルにされたときにチェックされる。ＷＱサイズフィールドが０であるＷＱは、イネーブルにされることができず、そのようなＷＱＣＦＧレジスタのすべての他のフィールドが無視される。デバイスがイネーブルの間、ＷＱサイズフィールドは読み取り専用である。サブレジスタのそれぞれに関するデータについては、テーブルＮを参照する。
【表１７】
0006988040.tif 000019
0006988040.tif 000020
【０４５９】
一実施例において、ワークキュー占有割込み制御レジスタ１０８１９（ワークキュー（ＷＱ）毎に１つ）は、ワークキューの占有率が特定の閾値に低下した場合、ソフトウェアが割込みを要求することを可能にする。ＷＱに対するＷＱ占有割込みイネーブルが１であり、現在のＷＱ占有率が、ＷＱ占有率の制限又はそれを下回る場合、以下の動作が実行され得る。１．ＷＱ占有割込みイネーブルフィールドがクリアされる。２．割込み理由レジスタのビット３が１に設定される。３．割込み理由レジスタのビット３が、段階２の前に０であった場合、ＭＳＩ−Ｘテーブルエントリ０を用いて割込みが生成される。４．レジスタがイネーブル＝１、及び、制限≧現在のＷＱ占有率で書き込まれた場合、割込みがすぐ生成される。結果として、レジスタがイネーブル＝１、及び、制限≧ＷＱサイズで書き込まれた場合、常に割込みはすぐに生成される。
【表１８】
0006988040.tif 000021
【０４６０】
一実施例において、ワークキューステータスレジスタ（ＷＱ毎に１つ）１０８２０は、各ＷＱにおける現在のエントリの数を規定する。この数は、記述子がキューにサブミットされ、又は、キューからディスパッチされるときにはいつでも変更する可能性があるので、ＷＱに空きがあるか否かを判断することに信頼できない。
【０４６１】
一実施例において、ＭＳＩ−Ｘエントリ１０８２１は、ＭＳＩ−Ｘテーブルデータを格納する。オフセット及びエントリの数は、ＭＳＩ−Ｘ機能にある。提案されたエントリの数は、ＷＱの数に２を加えた値である。
【０４６２】
一実施例において、ＭＳＩ−Ｘ未処理ビットアレイ１０８２２は、ＭＳＩ−Ｘ機能にあるオフセット及びエントリの数を格納する。
【０４６３】
一実施例において、割込みメッセージストレージエントリ１０８２３は、テーブル構造内に割込みメッセージを格納する。このテーブルのフォーマットは、ＰＣＩｅで規定されるＭＳＩ−Ｘテーブルのフォーマットと同様であるが、サイズは、２０４８個のエントリに限定されない。しかしながら、いくつかの実施例において、このテーブルのサイズは、異なるＤＳＡ実装間で変化してよく、２０４８個のエントリより少なくてもよい。一実施例において、エントリの数は、一般的な機能レジスタの割込みメッセージストレージサイズフィールド内にある。割込みメッセージストレージサポート機能が０である場合、このテーブルは提示されない。ＤＳＡが多数の仮想マシン又はコンテナをサポートするために、サポートされるテーブルのサイズは、かなり大きい必要がある。
【０４６４】
一実施例において、ＩＭＳ内の各エントリのフォーマットは、以下のテーブルＰにおいて説明される。
【表１９】
0006988040.tif 000022
【０４６５】
図３５は、Ｉ／Ｏファブリックインタフェース３５０１（例えば、上記で説明されたマルチプロトコルリンク２８００など）を介してサブミットされた記述子を受信する複数のワークキュー３５１１−３５１２を有するデータストリーミングアクセラレータ（ＤＳＡ）デバイスの一実施例を示す。ＤＳＡは、クライアント（プロセッサコア、ピア入力／出力（ＩＯ）エージェント（ネットワークインタフェースコントローラ（ＮＩＣ）など）及び／又は、ソフトウェアチェーンオフロード要求など）からのダウンストリームワーク要求を受信するために、及び、アップストリーム読み出し、書き込み、及びアドレス変換オペレーションのためにＩ／Ｏファブリックインタフェース３５０１を用いる。例示された実施例では、ワークキュー間のアービトレーションを実行し、複数のエンジン３５５０のうちの１つにワーク記述子をディスパッチするアービタ３５１３を含む。アービタ３５１３及びワークキュー３５１１−１０１２の処理は、ワークキュー構成レジスタ３５００を通じて構成されてよい。例えば、アービタ３５１３は、ワークキュー３５１１−１０１２のそれぞれからの記述子をエンジン３５５０のそれぞれにディスパッチするために、様々なＱｏＳ及び／又は公平性ポリシを実装するように構成されてよい。
【０４６６】
一実施例において、ワークキュー３５１１−３５１２にキューイングされる記述子のいくつかは、ワーク記述子のバッチを含む／識別するバッチ記述子３５１５である。アービタ３５１３は、変換キャッシュ３５２０（プロセッサ上の潜在的に他のアドレス変換サービス）を通じて変換されたアドレスを使用いて、メモリから記述子３５１８のアレイを読み出すことによりバッチ記述子を処理するバッチ処理ユニット３５１６にバッチ記述子を転送する。一旦物理アドレスが識別されると、データ読み出し／書き込み回路３５４０は、メモリから記述子のバッチを読み出す。
【０４６７】
第２のアービタ３５１９は、バッチ処理ユニット３５１６により提供されるワーク記述子３５１８と、ワークキュー３５１１−３５１２から取得される個々のワーク記述子３５１４とのバッチ間でアービトレーションを実行し、ワーク記述子をワーク記述子処理ユニット３５３０に出力する。一実施例において、ワーク記述子処理ユニット３５３０は、（データＲ／Ｗユニット３５４０を介して）メモリを読み出し、データに対して要求されたオペレーションを実行し、出力データを生成し、（データＲ／Ｗユニット３５４０を介して）出力データ、完了記録及び割込みメッセージを書き込むステージを有する。
【０４６８】
一実施例において、ワークキュー構成は、ノンポステッドＥＮＱＣＭＤ／Ｓ命令を使用する記述子を受信する共有のワークキュー（ＳＷＱ）として、又は、ポステッドＭＯＶＤＩＲ６４Ｂ命令を使用する記述子を受信する専用のワークキュー（ＤＷＱ）としての、いずれか一方として、ソフトウェアが（ＷＱ構成レジスタ３５００を介して）各ＷＱを構成することを可能にする。図３４に関して上記ですでに述べたように、ＤＷＱは、単一のアプリケーションからサブミットされたワーク記述子及びバッチ記述子を処理してよく、他方、ＳＷＱは、複数のアプリケーションの中で共有されてよい。ＷＱ構成レジスタ３５００は、どのＷＱ３５１１−３５１２がどのアクセラレータエンジン３５５０に供給するか、及び、各エンジンを供給するＷＱ３５１１−３５１２に関連する優先度をソフトウェアが制御することも可能にする。例えば、オーダリングされた優先度のセットは、（例えば、高、中、低：１、２、３などに）規定されてよく、記述子は、一般に、より低い優先度のワークキューの前に、又は、より低い優先度のワークキューからディスパッチするも頻繁に、より高い優先度のワークキューからディスパッチされてよい。例えば、高い優先度及び低い優先度として識別される２つのワークキューを用いて、ディスパッチされる各１０個の記述子について、１０個の記述子のうちの８個が、高い優先度のワークキューからディスパッチされてよく、一方、１０個の記述子のうちの２個が、低い優先度のワークキューからディスパッチされる。様々な他の技術が、ワークキュー３５１１−３５１２間で異なる優先度のレベルを実現するために用いられてよい。
【０４６９】
一実施例において、データストリーミングアクセラレータ（ＤＳＡ）は、ＰＣＩエクスプレス構成メカニズムとの互換性があるソフトウェアであり、その構成マッピングレジスタセット内にＰＣＩヘッダ及び拡張空間を実装する。構成レジスタは、ルートコンプレックスからＣＦＣ／ＣＦ８又はＭＭＣＦＧを通じてプログラミングされ得る。同様に、すべての内部レジスタは、ＪＴＡＧ又はＳＭバスインタフェースを通じてもアクセス可能であってよい。
【０４７０】
一実施例において、ＤＳＡデバイスは、そのオペレーションを制御するためにメモリマップレジスタを用いる。機能、構成及びワークサブミッションレジスタ（ポータル）は、ＢＡＲ０、ＢＡＲ２及びＢＡＲ４レジスタにより規定されるＭＭＩＯ領域を通じてアクセス可能である（以下で説明される）。各ポータルは、それらがプロセッサページテーブルを用いて異なるアドレス空間（クライアント）に独立にマッピングされ得るように、別々の４Ｋページ上にあってよい。
【０４７１】
すでに述べたように、ソフトウェアは、記述子を通じてＤＳＡに対するワークを規定する。記述子は、ＤＳＡに対するオペレーションのタイプを特定して、データ及びステータスバッファのアドレス、即値オペランド、完了属性などを実行する（記述子のフォーマットに関する追加の詳細及び詳細は、以下で説明する）。完了属性は、完了記録を書き込むアドレスと、選択的な完了割込みを生成するのに必要とされる情報とを規定する。
【０４７２】
一実施例において、ＤＳＡは、デバイス上のクライアント固有の状態を維持することを回避する。記述子を処理するすべての情報は、記述子自体に入っている。これは、ユーザモードアプリケーション間、並びに、仮想化されたシステム内の異なる仮想マシン（マシンコンテナ）間のその共有能力を改善する。
【０４７３】
記述子は、オペレーション及び関連するパラメータを含んでよい（ワーク記述子と呼ばれる）、又は、記述子は、ワーク記述子のアレイのアドレスを含むことができる（バッチ記述子と呼ばれる）。ソフトウェアは、メモリに記述子を準備して、デバイスのワークキュー（ＷＱ）３５１１−３５１２に記述子をサブミットする。記述子は、ＷＱのモード及びクライアントの特権レベルに応じて、ＭＯＶＤＩＲ６４Ｂ、ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ命令を用いるデバイスにサブミットされる。
【０４７４】
各ＷＱ３５１１−３５１２は、固定数のスロットを有し、それによって、重い負荷の下、いっぱいになり得る。一実施例において、デバイスは、ソフトウェアがフロー制御を実装するのを助けるために、必要なフィードバックを提供する。デバイスは、ワークキュー３５１１−３５１２から記述子をディスパッチし、さらなる処理のためにエンジンにこれらをサブミットする。エンジン３５５０が、記述子を完了し、結果的にアボートをもたらす特定の障害又はエラーに遭遇した場合、ホストメモリ内の完了記録に書き込むこと又は割込みを発行することのいずれか一方により、又は、その両方によりホストソフトウェアを通知する。
【０４７５】
一実施例において、各ワークキューは、それぞれがデバイスＭＭＩＯ空間内の別々の４ＫＢページにある複数のレジスタを介してアクセス可能である。各ＷＱに関して、１つのワークサブミッションレジスタは、「非特権ポータル」と呼ばれ、ユーザモードクライアントにより用いられるユーザ空間にマッピングされる。もう一つのワークサブミッションレジスタは、「特権ポータル」と呼ばれ、カーネルモードドライバにより用いられる。残りは、ゲストポータルであり、仮想マシン内のカーネルモードクライアントにより用いられる。
【０４７６】
すでに述べたように、各ワークキュー３５１１−３５１２は、専用又は共有の２つのモードのうちの１つにおいて実行するように構成され得る。ＤＳＡは、専用及び共有モードに対するサポートを示すように、ワークキュー機能レジスタにおける機能ビットをさらす。また、ＤＳＡは、モードのうちの１つで動作するように各ＷＱを構成するために、ワークキュー構成レジスタ３５００に制御をさらす。ＷＱのモードは、ＷＱがディセーブルの間、すなわち、（ＷＱＣＦＧイネーブル＝０）の間だけ、変更され得る。ＷＱ機能レジスタ及びＷＱ構成レジスタの追加の詳細は、以下で説明する。
【０４７７】
一実施例では、共有モードにおいて、ＤＳＡクライアントは、ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ命令を用いて、記述子をワークキューにサブミットする。ＥＮＱＣＭＤ及びＥＮＱＣＭＤＳは、６４バイトのノンポステッド書き込みを用いており、完了する前に、デバイスからの応答を待機する。ＤＳＡは、ワークキューに空きがある場合には（例えば、要求したクライアント／アプリケーションに）「成功」、又は、ワークキューが満杯の場合には「リトライ」を返す。ＥＮＱＣＭＤ及びＥＮＱＣＭＤＳ命令は、コマンドサブミッションのステータスをゼロフラグで返してよい（０は成功を示し、１はリトライを示す）。ＥＮＱＣＭＤ及びＥＮＱＣＭＤＳ命令を用いて、複数のクライアントは、同じワークキューに記述子を直接かつ同時にサブミットし得る。デバイスがこのフィードバックを提供するので、クライアントは、これらの記述子が受け取られたか否かを伝えることができる。
【０４７８】
共有モードにおいて、ＤＳＡは、カーネルモードクライアント用の特権ポータルを介して、サブミッションのための一部のＳＷＱ容量を予約してよい。非特権ポータルを介したワークサブミッションは、ＳＷＱ内の記述子の数が、ＳＷＱ用に設定された閾値に達するまで受け取られる。特権ポータルを介したワークサブミッションは、ＳＷＱが満杯になるまで受け取られる。ゲストポータルを介したワークサブミッションは、非特権ポータルと同じ方法で閾値により制限される。
【０４７９】
ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ命令が、「成功」を返した場合、記述子は、デバイスにより受け取られ、処理のためにキューイングされる。命令が、「リトライ」を返した場合、ソフトウェアは、記述子をＳＷＱに再サブミットすることを試み得る、又は、それが非特権ポータルを用いるユーザモードクライアントであった場合、特権ポータルを用いて、ユーザモードクライアントの代わりに記述子をサブミットすることをカーネルモードドライバに要求し得るのいずれか一方を行う。これは、サービス妨害を回避するのに役立ち、将来への前進保証を提供する。代替的に、ソフトウェアは、ＳＷＱが満杯になった場合、他の方法（例えば、ＣＰＵを用いてワークを実行する）を用いてよい。
【０４８０】
クライアント／アプリケーションは、処理アドレス空間ＩＤ（ＰＡＳＩＤ）と呼ばれる２０ビットのＩＤを使用してデバイスにより識別される。ＰＡＳＩＤは、デバイスＴＬＢ１７２２内のアドレスを検索して、アドレス変換又はページ要求をＩＯＭＭＵ１７１０に（例えば、マルチプロトコルリンク２８００を介して）送信するために、デバイスにより用いられる。共有モードにおいて、各記述子と共に用いられるＰＡＳＩＤは、記述子のＰＡＳＩＤフィールドに含まれる。一実施例において、ＥＮＱＣＭＤは、特定のレジスタ（例えば、ＰＡＳＩＤ  ＭＳＲ）から現在のスレッドのＰＡＳＩＤを記述子にコピーする一方、ＥＮＱＣＭＤＳは、スーパバイザモードのソフトウェアが記述子にＰＡＳＩＤをコピーすることを可能にする。
【０４８１】
「専用」モードにおいて、ＤＳＡクライアントは、ＭＯＶＤＩＲ６４Ｂ命令を用いて、記述子をデバイスのワークキューにサブミットしてよい。ＭＯＶＤＩＲ６４Ｂは、６４バイトのポステッド書き込みを用い、命令は、書き込み動作のポステッド特性に起因してより高速完了する。専用のワークキューに関し、ＤＳＡは、ワークキュー内のスロットの総数をさらし、ソフトウェアに依存してフロー制御を提供してよい。ソフトウェアは、ワークキューの満杯条件を検出するために、サブミットされ、完了した記述子の数をトラッキングする役割を担う。ワークキューに空きがないときに、ソフトウェアが、記述子を専用のＷＱに誤ってサブミットした場合、記述子はドロップされ、エラーが、（例えば、ソフトウェアエラーレジスタに）記録されてよい。
【０４８２】
ＭＯＶＤＩＲ６４Ｂ命令は、ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ命令が行うように、ＰＡＳＩＤを書き込まないので、専用モードにおいて、記述子内のＰＡＳＩＤフィールドを用いることができない。ＤＳＡは、専用のワークキューにサブミットされた記述子内のＰＡＳＩＤフィールドを無視してよく、代わりに、ＷＱ構成レジスタ３５００のＷＱ  ＰＡＳＩＤフィールドを用いてアドレス変換を行う。一実施例において、ＷＱ  ＰＡＳＩＤフィールドは、専用モードでワークキューを構成する場合、ＤＳＡドライバにより設定される。
【０４８３】
専用モードは、複数のクライアント／アプリケーションにより単一のＤＷＱを共有するものではないが、ＤＳＡデバイスは、複数のＤＷＱを有するように構成され得、ＤＷＱのそれぞれは、クライアントに独立に割り当てられ得る。さらに、ＤＷＱは、異なるクライアント／アプリケーションのために提供された異なる性能レベルに対して同じ又は異なるＱｏＳレベルを有するように構成され得る。
【０４８４】
一実施例において、データストリーミングアクセラレータ（ＤＳＡ）は、ワークキュー３５１１−１０１２にサブミットされた記述子を処理する２又はそれより多いエンジン３５５０を含む。ＤＳＡアーキテクチャの一実施例は、０から３の番号が付された４つのエンジンを含む。エンジン０及び１は、それぞれ、最大でデバイスの全帯域幅（例えば、読み出し用に３０ＧＢ／ｓ及び書き込み用に３０ＧＢ／ｓ）まで利用することが可能である。もちろん、すべてのエンジンについての組み合わられる帯域幅はまた、デバイスに対して利用可能な最大の帯域幅に制限される。
【０４８５】
一実施例において、ソフトウェアは、グループ構成レジスタを用いて、ＷＱ３５１１−３５１２及びエンジン３５５０をグループに構成する。それぞれのグループは、１又は複数のＷＱ及び１又は複数のエンジンを含む。ＤＳＡは、グループ内の任意のエンジンを用いて、グループ内の任意のＷＱにポステッドされた記述子を処理してよく、各ＷＱ及び各エンジンは、１つのグループのみにあってよい。グループの数はエンジンの数と同じであってよいので、各エンジンは別々のグループにあり得るが、任意のグループが１より多いエンジンを含む場合に、すべてのグループが用いられる必要があるわけではない。
【０４８６】
ＤＳＡアーキテクチャは、ワークキュー、グループ及びエンジンを構成するときに大きな柔軟性を可能にするが、ハードウェアは、特定の構成の使用のために狭く設計されてよい。エンジン０及び１は、ソフトウェアの要件に応じて、２つの異なる方式のうちの１つで構成されてよい。１つの推奨される構成は、同じグループ内にエンジン０及び１の両方を配置することである。ハードウェアは、グループ内の任意のワークキューから記述子を処理するエンジンのいずれか一方を用いる。この構成において、一方のエンジンが高レイテンシメモリアドレス変換又はページフォールトに起因してストールを有する場合、他方のエンジンは、動作を継続して、全体的なデバイスのスループットを最大化することができる。
【０４８７】
図３６は、各グループ３６１１及び３６１２内の２つのワークキュー３６２１−３６２２及び３６２３−３６２４をそれぞれ示すが、サポートされるＷＱの最大数までの任意の数があってよい。グループ内のＷＱは、異なる優先度を有する共有のＷＱ、１つの共有のＷＱ及び他の専用のＷＱ、又は、同じ又は異なる優先度を有する複数の専用のＷＱであってよい。図示された例では、グループ３６１１は、エンジン０及び１  ３６０１によりサービス提供され、グループ３６１２は、エンジン２及び３  ３６０２によりサービス提供される。
【０４８８】
図３７に示されるように、エンジン０  ３７００及びエンジン１  ３７０１を使用する別の構成では、別々のグループ３７１０及び３７１１にそれぞれこれらを配置する。同様に、グループ２  ３７１２は、エンジン２  ３７０２に割り当てられ、グループ３は、エンジン３  ３７０３に割り当てられる。さらに、グループ０  ３７１０は、２つのワークキュー３７２１及び３７２２から構成され、グループ１  ３７１１は、ワークキュー３７２３から構成され、ワークキュー２  ３７１２は、ワークキュー３７２４から構成され、グループ３  ３７１３は、ワークキュー３７２５から構成される。
【０４８９】
レイテンシに敏感なオペレーションが他のオペレーションの背後でブロックされた状態になる可能性を低減したい場合に、ソフトウェアは、この構成を選択してよい。この構成において、ソフトウェアは、レイテンシに敏感なオペレーションをエンジン１  ３７０２に接続されたワークキュー３７２３に、他のオペレーションをエンジン０  ３７００に接続されたワークキュー３７２１−３７２２にサブミットする。
【０４９０】
エンジン２  ３７０２及びエンジン３  ３７０３は、例えば、相変化メモリなどの高帯域幅の不揮発性メモリに書き込むために用いられてよい。これらのエンジンの帯域幅の機能は、このタイプのメモリの予期される書き込み帯域幅に一致するサイズであってよい。この利用に関し、エンジン構成レジスタのビット２及び３は、１に設定されるべきであり、仮想チャネル１（ＶＣ１）が、これらのエンジンからのトラフィックに用いられるべきであることを示す。
【０４９１】
高帯域幅の不揮発性メモリ（例えば、相変化メモリ）がないプラットフォームにおいて、又は、ＤＳＡデバイスがこのタイプのメモリに書き込むために用いられない場合、エンジン２及び３は、未使用であってよい。しかしながら、サブミットされたオペレーションが制限された帯域幅に耐えるという条件で、ソフトウェアが、追加の低レイテンシパスとしてこれらの使用を行うことが可能である。
【０４９２】
各記述子がワークキューのヘッドに到着したときに、それは、スケジューラ／アービタ３５１３により除去され、グループ内のエンジンの１つに転送されてよい。メモリ内のワーク記述子３５１８を指す、バッチ記述子３５１５について、エンジンは、メモリから（すなわち、バッチ処理ユニット３５１６を用いて）ワーク記述子のアレイをフェッチする。
【０４９３】
一実施例において、各ワーク記述子３５１４について、エンジン３５５０は、完了記録アドレスのための変換をプリフェッチし、ワーク記述子処理ユニット３５３０にオペレーションを渡す。ワーク記述子処理ユニット３５３０はソース及び宛先アドレス変換のために、デバイスＴＬＢ１７２２及びＩＯＭＭＵ１７１０を用いて、ソースデータを読み出し、特定のオペレーションを実行し、宛先データをメモリに書き戻す。オペレーションが完了した場合、エンジンは、ワーク記述子により要求されている場合、予め変換された完了アドレスに完了記録を書き込み、割込みを生成する。
【０４９４】
一実施例において、ＤＳＡの複数のワークキューは、サービス品質（ＱｏＳ）の複数のレベルを提供するために用いられ得る。各ＷＱの優先度は、ＷＱ構成レジスタ３５００において特定されてよい。ＷＱの優先度は、同じグループ内の他のＷＱに関連する（例えば、単独でグループ内に存在するＷＱについての優先度レベルには意味がない）。グループ内のワークキューは、同じ又は異なる優先度を有し得る。しかしながら、単一のＳＷＱは、同じ用途をサービス提供するであろうから、同じグループ内に同じ優先度を有する複数の共有のＷＱを構成しても意味がない。スケジューラ／アービタ３５１３は、これらの優先度に従って、ワークキュー３５１１−３５１２からエンジン３５５０にワーク記述子をディスパッチする。
【０４９５】
図３８は、実行対象となるオペレーションを規定するオペレーションフィールド３８０１、複数のフラグ３８０２、処理アドレス空間識別子（ＰＡＳＩＤ）フィールド３８０３、完了記録アドレスフィールド３８０４、ソースアドレスフィールド３８０５、宛先アドレスフィールド３８０６、完了割込みフィールド３８０７、転送サイズフィールド３８０８、及び、（潜在的に）１又は複数のオペレーションに固有のフィールド３８０９を含む記述子１３００の一実施例を示す。一実施例では、完了記録アドレス有効、要求完了記録及び要求完了割込みという３つのフラグがある。
【０４９６】
共通のフィールドは、トラステッドフィールド及び非トラステッドフィールドの両方を含む。トラステッドフィールドは、それらがホスト上のＣＰＵにより又は特権（リング０又はＶＭＭ）ソフトウェア入力されるので、常にＤＳＡデバイスにより信頼されている。非トラステッドフィールドは、ＤＳＡクライアントにょり直接供給される。
【０４９７】
一実施例において、トラステッドフィールドは、ＰＡＳＩＤフィールド３８０３、予約フィールド３８１１及びＵ／Ｓ（ユーザ／スーパバイザ）フィールド３８１０（すなわち、０のオフセットで始まる４バイト）を含む。記述子が、ＥＮＱＣＭＤ命令を用いてサブミットされる場合、ソース記述子内のこれらのフィールドは無視されてよい。ＭＳＲに含まれる値（例えば、ＰＡＳＩＤ  ＭＳＲ）は、記述子がデバイスに送信される前に、これらのフィールドに置かれてよい。
【０４９８】
一実施例において、記述子がＥＮＱＣＭＤＳ命令を用いてサブミットされる場合、ソース記述子内のこれらのフィールドは、ソフトウェアにより初期化される。ＰＣＩエクスプレスＰＡＳＩＤ機能がイネーブルにされていない場合、Ｕ／Ｓフィールド３８１０は１に設定され、ＰＡＳＩＤフィールド３８０３は０に設定される。
【０４９９】
記述子が、ＭＯＶＤＩＲ６４Ｂ命令を用いてサブミットされる場合、記述子内のこれらのフィールドは無視されてよい。デバイスは、代わりに、ＷＱコンフィグレジスタ３５００のＷＱ  Ｕ／Ｓ及びＷＱ  ＰＡＳＩＤフィールドを用いる。
【０５００】
これらのフィールドは、バッチ内のどの記述子に対しても無視され得る。バッチ記述子３５１５の対応するフィールドは、バッチ内の各記述子３５１８に対して用いられる。テーブルＱは、これらのトラステッドフィールドのそれぞれについての説明及びビット位置を提供する。
【表２０】
0006988040.tif 000023
【０５０１】
以下のテーブルＲは、記述子のオペレーションフィールド３８０１に従う一実施例において実行されるリストである。
【表２１】
0006988040.tif 000024
【０５０２】
以下のテーブルＳは、記述子の一実施例で用いられるフラグを列挙する。
【表２２】
0006988040.tif 000025
0006988040.tif 000026
【０５０３】
一実施例において、完了記録アドレス３８０４は、完了記録のアドレスを規定する。完了記録は、３２バイトであってよく、完了記録アドレスは３２バイト境界上にアラインされる。完了記録アドレス有効フラグが０である場合、このフィールドは予約されている。要求完了記録フラグが１である場合、完了記録は、オペレーションの完了時にこのアドレスに書き込まれる。要求完了記録が０である場合、完了記録は、ページフォールト又はエラーがある場合のみ、このアドレスに書き込まれる。
【０５０４】
比較などの結果をもたらす任意のオペレーションについて、完了記録アドレス有効及び要求完了記録フラグは、両方とも１であるべきであり、完了記録アドレスは有効であるべきである。
【０５０５】
仮想アドレスを用いる任意の処理について、完了記録アドレスは、要求完了記録フラグが設定されているか否かについて有効であるべきであり、その結果、完了記録は、ページフォールト又はエラーがある場合に書き込まれ得る。
【０５０６】
最良の結果について、このフィールドは、記述子をサブミットしたソフトウェアにデバイスがエラーを報告することを可能するので、すべての記述子において有効であるべきである。このフラグが０であり、予期しないエラーが発生した場合、エラーは、ＳＷＥＲＲＯＲレジスタに報告され、要求をサブミットしたソフトウェアは、エラーが通知されなくてもよい。
【０５０７】
完了記録アドレスフィールド３８０４は、バッチ記述子において完了キューイネーブルフラグが設定されている場合、バッチ内の記述子を無視し、バッチ記述子内の完了キューアドレスが代わりに用いられる。
【０５０８】
一実施例において、メモリからデータを読み出すオペレーションについて、ソースアドレスフィールド３８０５は、ソースデータのアドレスを規定する。ソースアドレスに対するアライメント要求はない。メモリにデータを書き込むオペレーションについて、宛先アドレスフィールド３８０６は、宛先バッファのアドレスを規定する。宛先アドレスに対するアライメント要求はない。いくつかのオペレーションタイプについて、このフィールドは、第２のソースバッファのアドレスとして用いられる。
【０５０９】
一実施例において、転送サイズフィールド３８０８は、オペレーションを実行するために、ソースアドレスから読み出されるバイト数を示す。このフィールドの最大値は、２３２‐１であってよいが、最大の可能な転送サイズは、より小さくてよく、かつ、一般的な機能レジスタの最大転送サイズフィールドから判断されなければならない。転送サイズは０であるべきではない。多くのオペレーションタイプに関して、転送サイズに対するアライメント要求はない。オペレーションの説明において例外が言及されている。
【０５１０】
一実施例において、使用割込みメッセージストレージフラグが１である場合、完了割込み処理フィールド３８０７は、完了割込みを生成するために用いられる割込みメッセージストレージエントリを規定する。このフィールドの値は、ＧＥＮＣＡＰ内の割込みメッセージストレージサイズフィールドの値より小さくするべきである。一実施例において、完了割込み処理フィールド３８０７は、使用割込みメッセージストレージフラグが０である、要求完了割込みフラグが０である、Ｕ／Ｓビットが０である、一般的な機能レジスタの割込みメッセージストレージサポートフィールドが０である、又は、記述子が、ゲストポータルを介してサブミットされている、という条件のいずれかの下で予約される。
【０５１１】
図３９に示されるように、完了記録３９００の一実施例は、オペレーションが完了又はエラーに遭遇した場合にＤＳＡが書き込むメモリ内の３２バイト構造である。完了記録アドレスは、３２バイトアラインであるべきである。
【０５１２】
このセクションは、多くのオペレーションタイプに共通である完了記録のフィールドを説明する。各オペレーションタイプの説明は、フォーマットがこれとは異なる場合の完了記録図を含む。追加のオペレーションに固有のフィールドは、以下でさらに説明される。完了記録３９００は、たとえ、必要とされるフィールドが全くなくても、常に３２バイトであり得る。完了記録３９００は、ページフォールトに起因して部分的に完了した場合にオペレーションを継続するのに十分な情報を含む。
【０５１３】
完了記録は、（記述子３８００の完了記録アドレス３８０４により識別される）メモリ内の３２バイトアライン構造として実装され得る。完了記録３９００は、オペレーションが完了したか否かを示す完了ステータスフィールド３９０４を含む。オペレーションの完了に成功した場合、完了記録は、もしあればオペレーションのタイプに応じたオペレーションの結果を含んでよい。オペレーションが完了に成功しなかった場合、完了記録は、障害又はエラー情報を含む。
【０５１４】
一実施例において、ステータスフィールド３９０４は、記述子の完了ステータスを報告する。ソフトウェアは、このフィールドを０に初期化すべきであり、それにより、完了記録が書き込まれたときを検出できる。
【表２３】
0006988040.tif 000027
【０５１５】
上記のテーブルＴは、様々なステータスコードを提供し、一実施例に関する説明に関連する。
【０５１６】
以下のテーブルＵは、障害アドレスが読み出されたか、書き込まれたかを示す第１のビット、及び、フォールトアクセスがユーザモードであったか、スーパバイザモードアクセスであったかを示す第２のビットを含む一実施例において利用可能な障害コード３９０３を示す。
【表２４】
0006988040.tif 000028
【０５１７】
一実施例において、この完了記録３９００がバッチの一部としてサブミットされた記述子のためのものであった場合、インデックスフィールド３９０２は、この完了記録を生成した記述子のバッチ内のインデックスを含む。バッチ記述子について、このフィールドは、０ｘｆｆであってよい。バッチの一部ではないその他の記述子について、このフィールドは、予約済であってよい。
【０５１８】
一実施例において、オペレーションが、ページフォールトに起因して部分的に完了した場合、バイト完了フィールド３９０１は、障害が発生した前に処理されたソースバイトの数を含む。このカウントにより表されるソースバイトのすべては、完全に処理されていて、結果は、必要に応じてオペレーションタイプに従って宛先アドレスに書き込まれる。いくつかのオペレーションタイプについて、このフィールドは、障害以外のいくつかの理由に対する完了の前にオペレーションが停止した場合に用いられてもよい。オペレーションが完全に完了した場合、このフィールドは、０に設定されてよい。
【０５１９】
この値から出力サイズが容易に判断可能でないオペレーションタイプについて、完了記録は、宛先アドレスに書き込まれるバイト数も含む。
【０５２０】
オペレーションがページフォールトに起因して部分的に完了した場合、このフィールドは、障害を発生させたアドレスを含む。一般的な規則として、すべての記述子は、有効な完了記録アドレス３８０４を有するべきであり、完了記録アドレス有効フラグは１であるべきである。この規則に対するいくつかの例外が以下に説明される。
【０５２１】
一実施例において、完了記録の第１のバイトはステータスバイトである。デバイスにより書き込まれるステータス値はすべてゼロ以外の値である。ソフトウェアは、いつデバイスが完了記録に書き込まれたかを示すことを可能にするために、記述子をサブミットする前に、完了記録のステータスフィールドを０に初期化すべきである。完了記録を初期化することはまた、それがマッピングされることを確実にし、そのため、デバイスは、アクセスする場合にページフォールトに遭遇することはない。
【０５２２】
要求完了記録フラグは、たとえオペレーションの完了に成功したとしても、完了記録を書き込むべきであることをデバイスに示す。このフラグが設定されていない場合、デバイスは、もしエラーがあれば、完了記録のみを書き込む。
【０５２３】
記述子完成は、以下の方法のいずれかを用いるソフトウェアにより検出され得る。
【０５２４】
１．完了記録をポーリングして、ステータスフィールドがゼロ以外になるのを待つ。
【０５２５】
２．完了記録アドレスに対する（本明細書で説明されるような）ＵＭＯＮＩＴＯＲ／ＵＭＷＡＩＴ命令を用いて、書き込まれるまで又はタイムアウトするまでブロックする。次に、ソフトウェアは、オペレーションが完了したか否かを判断するために、ステータスフィールドがゼロ以外か否かをチェックすべきである。
【０５２６】
３．カーネルモード記述子について、オペレーションが完了した場合、割込みを要求する。
【０５２７】
４．記述子がバッチ内にある場合、同じバッチに後続の記述子内のフェンスフラグを設定する。フェンスを有する記述子又は同じバッチ内の任意の後続の記述子の完了は、フェンスに先行するすべての記述子の完了を示す。
【０５２８】
５．記述子がバッチ内にある場合、バッチを初期化したバッチ記述子の完了は、バッチ内のすべての記述子の完了を示す。
【０５２９】
６．ドレイン記述子又はドレインコマンドを発行して、それが完了するのを待つ。
【０５３０】
完了ステータスがページフォールトに起因して部分的な完了を示す場合、完了記録は、（もしあれば、）障害が引き起こされる前に、処理がどれくらい完了していたか、及び、障害が引き起こされた仮想アドレスを示す。ソフトウェアは、（プロセッサから障害アドレスをタッチすることにより、）障害を正常な状態に戻すことを選択し、新たな記述子内のワークの残りを再サブミット、又は、ソフトウェアにおけるワークの残りを完了し得る。記述子リスト及び完了記録アドレス上の障害は、異なって処理され、以下により詳細に説明される。
【０５３１】
ＤＳＡの一実施例では、メッセージシグナリング割込みのみをサポートする。ＤＳＡは、２つのタイプの割込みメッセージストレージ、すわなち、（ａ）ホストドライバにより用いられる割込みメッセージを格納する、ＭＳＩ−Ｘ機能を通じて列挙されたＭＳＩ−Ｘテーブル、及び、（ｂ）ゲストドライバにより用いられる割込みメッセージを格納するデバイスに固有の割込みメッセージストレージ（ＩＭＳ）テーブルを提供する。
【０５３２】
一実施例において、割込みは、３つのタイプのイベント、すなわち、（１）カーネルモード記述子の完了、（２）ドレイン又はアボートコマンドの完了、及び、（３）ソフトウェア又はハードウェアエラーレジスタにおいてポストされたエラーに対して生成され得る。イベントのタイプごとに、別々の割込みイネーブルがある。エラー及びアボート／ドレインコマンドの完了に起因する割込みは、ＭＳＩ−Ｘテーブル内のエントリ０を用いて生成される。割込み理由レジスタは、割込みの理由を判断するために、ソフトウェアにより読み出されてよい。
【０５３３】
カーネルモード記述子の完了（例えば、Ｕ／Ｓフィールドが１である記述子）について、用いられる割込みメッセージは、どのように記述子がサブミットされたか、及び、記述子内の使用割込みメッセージストレージフラグに依存する。
【０５３４】
特権ポータルを介してサブミットされたカーネルモード記述子に対する完了割込みメッセージは、一般にＭＳＩ−Ｘテーブル内のエントリであり、ポータルアドレスにより判断される。しかしながら、ＧＥＮＣＡＰ内の割込みメッセージストレージサポートフィールドが１である場合、特権ポータルを介してサブミットされた記述子は、記述子内に使用割込みメッセージストレージフラグを設定することによりこの挙動をオーバーライドしてよい。この場合、記述子内の完了割込み処理フィールドは、割込みメッセージストレージへのインデックスとして用いられる。
【０５３５】
ゲストポータルを介してサブミットされたカーネルモード記述子に対する完了割込みメッセージは、割込みメッセージストレージ内のエントリであり、ポータルアドレスにより判断される。
【０５３６】
ＤＳＡにより生成された割込みは、カーネル又はＶＭＭソフトウェアにより構成されるように、割込み再マッピング及びポスティングハードウェアを通じて処理される。
【表２５】
0006988040.tif 000029
【０５３７】
すでに述べたように、ＤＳＡは、一度に複数の記述子をサブミットすることをサポートする。バッチ記述子は、ホストメモリ内のワーク記述子のアレイのアドレス及び当該アレイの要素の数を含む。ワーク記述子のアレイは、「バッチ」と呼ばれる。バッチ記述子の使用は、ＤＳＡクライアントが、単一のＥＮＱＣＭＤ、ＥＮＱＣＭＤＳ又はＭＯＶＤＩＲ６４Ｂ命令を用いて複数のワーク記述子をサブミットすることを可能にし、全体的なスループットを潜在的に向上させることができる。ＤＳＡは、バッチ内のワーク記述子の数に対する制限を実行する。一般的な機能レジスタにおける最大バッチサイズフィールドにおいて制限が示される。
【０５３８】
バッチ記述子は、他のワーク記述子と同じ方法で、ワークキューにサブミットされる。バッチ記述子がデバイスにより処理される場合、デバイスは、メモリからワーク記述子のアレイを読み出して、次に、ワーク記述子のそれぞれを処理する。ワーク記述子は、必ずしも順番通りに処理されるわけではない。
【０５３９】
バッチ記述子のＰＡＳＩＤ３８０３及びＵ／Ｓフラグは、バッチ内のすべての記述子に用いられる。バッチ内の記述子におけるＰＡＳＩＤ及びＵ／Ｓフィールド３８１０は無視される。バッチ内の各ワーク記述子は、ちょうど、直接サブミットされたワーク記述子と同様に、完了記録アドレス３８０４を特定できる。代替的に、バッチ記述子は、バッチからのすべてのワーク記述子の完了記録がデバイスにより書き込まれる「完了キュー」アドレスを特定できる。この場合、バッチ内の記述子における完了記録アドレスフィールド３８０４は無視される。完了キューは、記述子総数よりも１エントリ分大きくすべきであり、そのため、バッチ内のすべての記述子に対する完了記録とバッチ記述子とのための空間がある。完了記録は、記述子が完了した順序で生成され、それらが記述子アレイに現れる順序と同じでなくてよい。各完了記録は、その完了記録を生成したバッチ内の記述子のインデックスを含む。０ｘｆｆのインデックスは、バッチ記述子自体に用いられる。０のインデックスは、バッチ記述子以外の直接サブミットされた記述子に用いられる。バッチ内のいくつかの記述子は、それらが完了記録を要求せず、それらが完了に成功した場合、完了記録を生成しなくてよい。この場合完了キューに書き込まれる完了記録の数は、バッチ内の記述子の数より少ない可能性がある。バッチ記述子の完了記録（要求された場合）は、バッチ内のすべての記述子に対する完了記録の後に完了キューに書き込まれる。
【０５４０】
バッチ記述子は、完了キューを規定せず、バッチ記述子に対する完了記録（要求された場合）は、バッチ内のすべての記述子が完了した後に、自体の完了記録アドレスに書き込まれる。バッチ記述子に対する完了記録は、バッチ内の記述子のいずれもが成功に相当しないステータスで完了したか否かについてのインジケーションを含む。これは、バッチ内のすべての記述子が完了に成功した通常の場合において、ソフトウェアがバッチ記述子に対する完了記録のみを検査することを可能にする。
【０５４１】
完了割込みは、必要に応じて、バッチ内の１又は複数のワーク記述子により要求されてもよい。バッチ記述子に対する完了記録（要求された場合）は、バッチ内のすべての記述子に対する完了記録及び完了割込みの後に書き込まれる。バッチ記述子に対する完了割込み（要求された場合）は、ちょうどその他の記述子と同様に、バッチ記述子に対する完了記録の後に生成される。
【０５４２】
バッチ記述子はバッチに含まれなくてもよい。ネステッド又はチェーン記述子アレイはサポートされていない。
【０５４３】
デフォルト設定で、ＤＳＡは、ワーク記述子を実行している間、いずれのオーダリングも保証していない。記述子は、スループットを最大化するようにデバイスが適切と考える任意の順序でディスパッチ及び完了できる。よって、オーダリングが要求された場合、ソフトウェアは、明示的にオーダリングしなければならない。例えば、ソフトウェアは、記述子をサブミットして、完了を確実にするために記述子からの完了記録又は割込みを待ち、それから、次の記述子をサブミットすることができる。
【０５４４】
ソフトウェアは、バッチ記述子により規定されたバッチ内の記述子に対するオーダリングも特定できる。各ワーク記述子は、フェンスフラグ（Ｆｅｎｃｅ  ｆｌａｇ）を有する。設定された場合、フェンスは、同じバッチ内の前の記述子が完了するまで、記述子の処理が開始されないことを保証する。これは、フェンスを有する記述子が、同じバッチ内の前の記述子により生成されるデータを消費することを可能にする。
【０５４５】
記述子は、オペレーションにより生成されたすべての書き込みがグローバルに観測可能となった後、要求された場合、宛先がリードバックした後、必要とされる場合、完了記録への書き込みがグローバルに観測可能となった後、及び、要求された場合、完了割込みの生成後に、完了する。
【０５４６】
バッチの任意の記述子が成功に相当しないステータスで完了した場合、例えば、それがページフォールトに起因して部分的に完了した場合、１に等しいフェンスフラグを有する後続の記述子、及び、バッチ内の任意の後続の記述子が廃棄される。バッチをサブミットするために用いられたバッチ記述子に対する完了記録は、どれくらいの数の記述子が完了したかを示す。部分的に完了され、完了記録が生成された任意の記述子は、完了されたときにカウントされる。廃棄された記述子のみが、完了していないとみなされる。
【０５４７】
フェンスはまた、完了記録及び割込みに対するオーダリングを確保する。例えば、設定されたフェンス及び要求完了割込みを有するＮｏ−ｏｐ記述子は、バッチ内のすべての先行する記述子が完了した（必要とされる場合、これらの完了記録が書き込まれた）後に生成された割込みを発生させる。完了記録書き込みは、常に、同じワーク記述子により生成されたデータ書き込みの背後でオーダリングされ、完了割込み（要求された場合）は、常に、同じワーク記述子に対する完了記録書き込みの背後でオーダリングされる。
【０５４８】
ドレインは、クライアントがそれ自体のＰＡＳＩＤに属するすべての記述子が完了するのを待つことを可能にする記述子である。それは、ＰＡＳＩＤ全体に対するフェンスオペレーションとして用いられることができる。ドレインオペレーションは、そのＰＡＳＩＤを有するすべての前の記述子が完了した場合に完了する。ドレイン記述子は、ソフトウェアにより用いられ、そのすべての記述子の完了に対する単一の完了記録又は割込みを要求できる。ドレインは、通常のワークキューにサブミットされる通常の記述子である。ドレイン記述子は、バッチに含まれてよい。（フェンスフラグは、バッチ内の前の記述子が完了するのを待つために、バッチ内で用いられてよい。）
【０５４９】
ソフトウェアは、ドレイン記述子がサブミットされた後、かつ、それが完了する前に、デバイスにサブミットされる特定のＰＡＳＩＤを有する記述子がないことを確保しなければならい。追加の記述子がサブミットされた場合、ドレインオペレーションが追加の記述子が完了するのも待つか否かが指定されていない。これは、ドレインオペレーションに長い時間をかけることになり得る。たとえデバイスが、追加の記述子が完了するのを待たなかったとしても、追加の記述子のいくつかは、ドレインオペレーションが完了する前に完了し得る。このように、すべての前のオペレーションが完了するまで、開始する後続のオペレーションがないことをフェンスが確保するので、ドレインは、フェンスとは異なる。
【０５５０】
一実施例において、アボート／ドレインコマンドは、アボート／ドレインレジスタに書き込むことにより、特権が与えられたソフトウェア（ＯＳカーネル又はＶＭＭ）によりサブミットされる。これらのコマンドの１つを受信したときに、ＤＳＡは、特定の記述子の完了を待つ（以下で説明される）。コマンドが完了した場合、ソフトウェアは、デバイスにおいて未処理の特定のカテゴリに記述子がこれ以上ないことを確認できる。
【０５５１】
一実施例では、ドレインオール、ドレインＰＡＳＩＤ及びドレインＷＱという３つのタイプのドレインコマンドがある。各コマンドは、完了へとこれらを処理するよりもむしろ、任意の未処理の記述子を破棄し得るデバイスを示すアボートフラグを有する。
【０５５２】
ドレインオールコマンドは、ドレインオールコマンドの前にサブミットされていたすべての記述子の完了を待機する。ドレインオールコマンドの後にサブミットされた記述子は、ドレインオールが完了したときに進行中であり得る。前の記述子が完了するのをドレインオールコマンドが待っている間に、デバイスは新たな記述子に対するワークを開始してよい。
【０５５３】
ドレインＰＡＳＩＤコマンドは、特定のＰＡＳＩＤと関連付けられたすべての記述子を待つ。ドレインＰＡＳＩＤコマンドが完了した場合、デバイス内のＰＡＳＩＤに対する記述子はこれ以上存在しない。ソフトウェアは、ドレインＰＡＳＩＤコマンドがサブミットされた後、かつ、それが完了する前に、デバイスにサブミットされる特定のＰＡＳＩＤを有する記述子がないことを確保し得る。そうでなければ、挙動が定義されていない。
【０５５４】
ドレインＷＱコマンドは、特定のワークキューにサブミットされたすべての記述子を待機する。ソフトウェアは、ドレインＷＱコマンドがサブミットされた後、かつ、それが完了する前にＷＱにサブミットされる記述子がないことを確保し得る。
【０５５５】
ＤＳＡを使用しているアプリケーション又はＶＭが一時停止された場合、それは、ＤＳＡにサブミットされた未処理の記述子を有している可能性がある。このワークは、完了されなければならず、そのため、クライアントは、後で再開され得るコヒーレント状態にある。ドレインＰＡＳＩＤ及びドレインオールコマンドは、任意の未処理の記述子を待機するために、ＯＳ又はＶＭＭにより用いられる。ドレインＰＡＳＩＤコマンドは、単一のＰＡＳＩＤを使用していたアプリケーション又はＶＭに用いられる。ドレインオールコマンドは、複数のＰＡＳＩＤを使用するＶＭに用いられる。
【０５５６】
ＤＳＡを使用しているアプリケーションが抜け出た、又は、オペレーティングシステム（ＯＳ）により終了された場合、ＯＳは、アドレス空間、割り当てられたメモリ及びＰＡＳＩＤを解放又は再利用し得る前に、未処理の記述子がないことを確保する必要がある。任意の未処理の記述子を処分するために、ＯＳは、終了されるクライアントのＰＡＳＩＤを有するドレインＰＡＳＩＤコマンドを使用し、アボートフラグは１に設定される。このコマンドを受信したときに、ＤＳＡは、さらなる処理を行うことなく特定のＰＡＳＩＤに属するすべての記述子を破棄する。
【０５５７】
ＤＳＡの一実施例では、複数のＷＱからワークをディスパッチするためにサービス品質を特定するメカニズムを提供する。ＤＳＡは、ソフトウェアがＷＱ空間の合計を複数のＷＱに分割することを可能にする。各ＷＱは、ワークをディスパッチするために、異なる優先度が割り当てられ得る。一実施例において、ＤＳＡスケジューラ／アービタ３５１３は、より高い優先度のＷＱが、より低い優先度のＷＱより多くサービス提供されるように、ＷＱからワークをディスパッチする。しかしながら、ＤＳＡは、より高い優先度のＷＱが、より低い優先度のＷＱを枯渇させないことを確保する。すでに述べたように、様々な優先順位付けのスキームは、実装要件に基づいて採用されてよい。
【０５５８】
一実施例において、ＷＱ構成レジスタテーブルは、ＷＱを構成するために用いられる。ソフトウェアは、所望のＱｏＳレベルの数に一致するように、アクティブなＷＱの数を構成できる。ソフトウェアは、ＷＱサイズ及びいくつかの追加のパラメータをＷＱ構成レジスタテーブルにプログラミングすることにより各ＷＱを構成する。これは、ＷＱ空間全体をＷＱの所望の数に効果的に分割する。未使用のＷＱは、０のサイズを有する。
【０５５９】
エラーは、１）特定のＰＡＳＩＤの記述子を処理するときに生じた関連エラー、２)事実上広範囲であり、ＰＡＳＩＤに特定のものではない非関連エラー、の２つのカテゴリに広く分けられる。ＤＳＡは、１つのＰＡＳＩＤからのエラーが、他のＰＡＳＩＤを停止させたり影響を与えたりすることをできる限り回避しようと試みる。ＰＡＳＩＤ固有のエラーは、エラーが完了記録自体（例えば、完了記録アドレス上のページフォールト）にある場合を除き、それぞれの記述子の完了記録に報告される。
【０５６０】
記述子サブミッション内又は記述子の完了記録上のエラーは、ソフトウェアエラーレジスタ（ＳＷＥＲＲＯＲ）を通じてホストドライバに報告されてよい。ハードウェアエラーは、ハードウェアエラーレジスタ（ＨＷＥＲＲＯＲ）を通じて報告されてよい。
【０５６１】
ＤＳＡの一実施例では、デバイスイネーブルレジスタ内のイネーブルビットが１に設定されたときに、以下のチェックを実行する。
・バスマスタイネーブルが１である。
・ＰＡＳＩＤ、ＡＴＳ及びＰＲＳ機能の組み合わせが有効である（テーブル６−３、セクション６．１．３を参照）。
・すべてのＷＱＣＦＧレジスタのＷＱサイズフィールドの合計が、総ＷＱサイズより大きくない。
・各ＧＲＰＣＦＧレジスタについて、ＷＱ及びエンジンフィールドが、両方とも０である、又は、両方ともゼロ以外であるのいずれか一方である。
・ＷＱＣＦＧレジスタ内のサイズフィールドがゼロ以外である各ＷＱが１つのグループにある。
・ＷＱＣＦＧレジスタ内のサイズフィールドがゼロである各ＷＱが、いずれのグループにもない。
・各エンジンが、１つのグループにしかない。
【０５６２】
これらのチェックのいずれかが不合格であった場合、デバイスはイネーブルにされず、エラーコードがデバイスイネーブルレジスタのエラーコードフィールドに記録される。これらのチェックは、任意の順序で実行されてよい。したがって、あるタイプのエラーのインジケーションは、他のエラーもあることを示唆するものではない。同じ構成エラーは、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを結果としてもたらす可能性がある。不合格になったチェックが一つもない場合、デバイスはイネーブルにされ、イネーブルフィールドが１に設定される。
【０５６３】
デバイスは、ＷＱＣＦＧレジスタ内のＷＱイネーブルビットが１に設定されたときに、以下のチェックを実行する。
・デバイスがイネーブルである（すなわち、デバイスイネーブルレジスタ内のイネーブルフィールドが１である）。
・ＷＱサイズフィールドがゼロ以外である。
・ＷＱ閾値が、ＷＱサイズフィールドより大きくない。
・ＷＱモードフィールドが、サポートされているモードを選択している。つまり、ＷＱＣＡＰ内の共有モードサポートフィールドが０である場合、ＷＱモードは１であり、又はＷＱＣＡＰ内の専用モードサポートフィールドが０である場合、ＷＱモードは０である。共有モードサポート及び専用モードサポートフィールドの両方が１である場合、ＷＱモードの値のいずれか一方は許可されている。
・ＧＥＮＣＡＰ内の障害のブロックサポートビットが０である場合、ＷＱ障害のブロックイネーブルフィールドは０である。
【０５６４】
これらのチェックのいずれかが不合格であった場合、ＷＱはイネーブルにされず、エラーコードがＷＱコンフィグレジスタ３５００のＷＱエラーコードフィールドに記録される。これらのチェックは、任意の順序で実行されてよい。したがって、あるタイプのエラーのインジケーションが、他のエラーもあることを示唆するものではない。同じ構成エラーは、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを結果としてもたらす可能性がある。不合格になったチェックが一つもない場合、デバイスはイネーブルにされ、ＷＱイネーブルフィールドが１に設定される。
【０５６５】
一実施例において、ＤＳＡは、記述子が受信されたときに、以下のチェックを実行する。
・記述子をサブミットするために用いられるレジスタアドレスにより識別されたＷＱが、アクティブなＷＱである（ＷＱＣＦＧレジスタ内のサイズフィールドがゼロ以外である）。このチェックが不合格であった場合、エラーがソフトウェアエラーレジスタ（ＳＷＥＲＲＯＲ）に記録される。
・記述子が共有のＷＱにサブミットされていた場合、
・それは、ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳと共にサブミットされていた。このチェックが不合格であった場合、エラーがＳＷＥＲＲＯＲに記録される。
・特権が与えられていない又はゲストポータルを介して記述子がサブミットされていた場合、現在のキュー占有率は、ＷＱ閾値より大きくない。このチェックが不合格であった場合、リトライ応答が返される。
・記述子が特権ポータルを介してサブミットされていた場合、現在のキュー占有率がＷＱサイズより小さい。このチェックが不合格であった場合、リトライ応答が返される。
・記述子が専用のＷＱにサブミットされていた場合、
・それは、ＭＯＶＤＩＲ６４Ｂを用いてサブミットされていた。
・キュー占有率がＷＱサイズより小さい。
【０５６６】
これらのチェックのいずれかが不合格であった場合、エラーがＳＷＥＲＲＯＲに記録される。
【０５６７】
一実施例において、デバイスは、各記述子が処理されるときに各記述子に対して以下のチェックを実行する。
・オペレーションコードフィールド内の値がサポートされているオペレーションに対応する。これは、サブミットされていたコンテキストにおいてオペレーションが有効であることをチェックすることを含む。例えば、バッチ内のバッチ記述子は、無効なオペレーションコードとして処理されるであろう。
・設定される予約フラグがない。これは、ＧＥＮＣＡＰレジスタ内の対応する機能ビットが０であるフラグを含む。
・設定される非サポートフラグがない。これは、特定のオペレーションとの使用のために予約されるフラグを含む。例えば、フェンスビットは、バッチの一部としてよりもむしろ、直接的にエンキューされる記述子において予約される。構成内でディセーブルされるフラグ、例えば、障害のブロックフラグも含み、ＷＱＣＦＧレジスタ内の障害のブロックイネーブルフィールドが０である場合に予約される。
・要求されたフラグが設定される。例えば、要求完了記録フラグは、比較オペレーション用の記述子において１でなければならない。
・予約フィールドが０である。これは、特定の動作を意味することが定義されていない任意のフィールドを含む。いくつかの実施例では、すべての予約フィールドをチェックしなくてよいが、ソフトウェアは、最大の互換性のためにすべての未使用のフィールドをクリアする処理を行うべきである。バッチ記述子において、記述子総数フィールドは、ＧＥＮＣＡＰレジスタ内の最大バッチサイズフィールドより大きくない。
・（記述子タイプに適用可能なものとして）転送サイズ、ソースサイズ、最大差分記録サイズ、差分記録サイズ及び最大宛先サイズが、ＧＥＮＣＡＰレジスタ内の最大転送サイズフィールドより大きくない。
・デュアルキャストを用いたメモリコピー記述子において、２つの宛先アドレスのビット１１：０は同じである。
・使用割込みメッセージストレージフラグが設定されている場合、完了割込み処理は、割込みメッセージストレージサイズより少ない。
【０５６８】
一実施例において、完了記録アドレス３８０４は変換されることができず、記述子３８００は破棄され、エラーがソフトウェアエラーレジスタに記録される。そうでなければ、これらのチェックのいずれかが不合格であった場合、完了記録は、不合格のチェックのタイプを示すステータスフィールドと共に書き込まれ、バイト完了は０に設定される。要求された場合、完了割込みが生成される。
【０５６９】
これらのチェックは、任意の順序で実行されてよい。したがって、完了記録におけるあるタイプのエラーのインジケーションは、他のエラーもあることを示唆するものではない。同じ無効記述子は、異なる時間で、又は、デバイスの異なるバージョンで、異なるエラーコードを報告してよい。
【０５７０】
記述子内の予約フィールド３８１１は、常に予約されているフィールド、いくつかの条件下で（例えば、機能、構成フィールド、どのように記述子がサブミットされたか、又は、記述子自体における他のフィールドの値に基づいて）予約されているフィールド、及び、オペレーションタイプに基づいて予約されているフィールドの３つのカテゴリに分類されてよい。以下のテーブルでは、フィールドが予約される条件を列挙する。
【表２６】
0006988040.tif 000030
【表２７】
0006988040.tif 000031
0006988040.tif 000032
【０５７１】
すでに述べたように、ＤＳＡは、物理又は仮想アドレスのいずれか一方の使用をサポートする。プロセッサコア上で実行する処理と共有される仮想アドレスの使用は、共有仮想メモリ（ＳＶＭ）と呼ばれる。ＳＶＭをサポートするために、デバイスは、アドレス変換を実行する場合、ＰＡＳＩＤを提供し、それは、アドレス用に存在する変換がない場合に発生するページフォールトを処理する。しかしながら、デバイス自体は、仮想アドレスと物理アドレスとを区別しない。この区別は、ＩＯＭＭＵ１７１０のプログラミングにより制御される。
【０５７２】
一実施例において、ＤＳＡは、ＡＴＳを利用するために、ＰＣＤＩを用いてＰＣＩｅ論理２８０８と通信するＰＣＩｅ論理２８２０を示す図２８に示されるようなアドレス変換サービス（ＡＴＳ）及びページ要求サービス（ＰＲＳ）ＰＣＩエクスプレス機能をサポートする。ＡＴＳは、アドレス変換中のデバイスの挙動を表現する。記述子が記述子処理ユニットに入る場合、デバイス２８０１は、記述子内のアドレスに対する変換を要求してよい。デバイスＴＬＢ２８２２においてヒットがある場合、デバイスは、対応するホスト物理アドレス（ＨＰＡ）を用いる。失敗又は許可障害がある場合、ＤＳＡ２８０１の一実施例では、変換のためにＩＯＭＭＵ２８１０に（すなわち、マルチプロトコルリンク２８００にわたって）アドレス変換要求を送信する。次に、ＩＯＭＭＵ２８１０は、それぞれのページテーブルを散策することにより変換を探し、変換されたアドレス及び有効な許可を含むアドレス変換応答を返してよい。次に、デバイス２８０１は、デバイスＴＬＢ２８２２に変換を格納し、オペレーション用に対応するＨＰＡを用いる。ＩＯＭＭＵ２８１０が、ページテーブル内の変換を探すことが不可能である場合、それは、利用可能な変換がないことを示すアドレス変換応答を返してよい。ＩＯＭＭＵ２８１０の応答が、変換がないことを示す、又は、オペレーションにより要求された許可を含まない有効な許可を示す場合、それは、ページフォールトとみなされる。
【０５７３】
ＤＳＡデバイス２８０１は、１）完了記録アドレス３８０４、２）バッチ記述子内の記述子リストアドレス、又は、３）ソースバッファ又は宛先バッファアドレスのうちの１つでのページフォールトに遭遇する可能性がある。ＤＳＡデバイス２８０１は、ページフォールトが解決されるまでブロックすることができる、又は、記述子を早期に完了して、部分的な完了をクライアントに返すことができる。一実施例において、ＤＳＡデバイス２８０１は、完了記録アドレス３８０４及び記述子リストアドレス上のページフォールトを常にブロックする。
【０５７４】
ＤＳＡがページフォールトをブロックする場合、それは、ＯＳページフォールトハンドラによりサービス提供するために、当該ページフォールトをページ要求サービス（ＰＲＳ）要求としてＩＯＭＭＵ２８１０に報告する。ＩＯＭＭＵ２８１０は、割込みを通じてＯＳに通知してもよい。ＯＳは、アドレスを有効にして、チェックが成功すると、ページテーブルにマッピングを作成し、ＩＯＭＭＵ２８１０を通じてＰＲＳ応答を返す。
【０５７５】
一実施例において、各記述子３８００は、ページフォールトがソース又は宛先バッファアドレス上で発生した場合、ＤＳＡ２８０１が部分的な完了を戻すべきであるか、ブロックするべきであるかを示す障害のブロックフラグを有する。障害のブロックフラグが１であり、障害に遭遇した場合、フォールトに遭遇した記述子は、ＰＲＳ応答が受信されるまでブロックされる。障害を有する記述子の背後の他のオペレーションもブロックされ得る。
【０５７６】
障害のブロックが０であり、ページフォールトがソース又は宛先バッファアドレス上で発生した場合、デバイスは、オペレーションを停止して、部分的な完了ステータスを障害アドレス及び進捗情報と共に完了記録へ書き込む。クライアントソフトウェアが部分的な完了を示す完了記録を受信した場合、それは、（例えば、ページをタッチすることにより）プロセッサ上の障害を正常な状態に戻し、新たなワーク記述子を残りのワークと共にサブミットするオプションを有する。
【０５７７】
代替的に、ソフトウェアは、プロセッサ上で残りのワークを完了できる。一般的な機能レジスタ（ＧＥＮＣＡＰ）内の障害のブロックサポートフィールドは、この機能に対するデバイスのサポートを示してよく、ワークキュー構成レジスタ内の障害のブロックイネーブルフィールドは、アプリケーションが機能を使用することが許可されるか否かをＶＭＭ又はカーネルドライバが制御することを可能にする。
【０５７８】
デバイスページフォールトは、比較的高くつく可能性がある。事実、デバイスページフォールトのために働くコストは、プロセッサページフォールトのために働くコストより高いかも知れない。たとえデバイスが障害のブロックの代わりに部分的なワークの完了を障害時に実行したとしても、ページフォールトのために働き、ワークを再サブミットするために、ソフトウェアの介入を必要とするので、さらにオーバヘッドが発生する。よって、最高のパフォーマンスのためには、ピニング及びアンピニングのオーバヘッドを発生させることなく、ソフトウェアがデバイスページフォールトを最小化することが好ましい。
【０５７９】
バッチ記述子リスト及びソースデータバッファは、典型的には、これらをデバイスにサブミットする直前に、ソフトウェアにより生成される。よって、これらのアドレスは、時間的な局所性に起因して障害を発生させる可能性が低い。しかしながら、完了記述子及び宛先データバッファは、デバイスにサブミットする前に、それらがソフトウェアによりタッチされていない場合、障害を発生させる可能性がよい高い。そのような障害は、サブミッション前にこれらのページを明示的に「書き込みタッチ（ｗｒｉｔｅ  ｔｏｕｃｈｉｎｇ）」するソフトウェアにより最小限に抑えられ得る。
【０５８０】
デバイスＴＬＢ無効要求中に、無効にされているアドレスが記述子処理ユニットにおいて用いられている場合、デバイスは、無効要求を完了する前にエンジンがアドレスを用いて行われるのを待つ。
【０５８１】
追加の記述子タイプ
【０５８２】
いくつかの実施例では、以下の追加の記述子タイプのうちの１又は複数を利用してよい。
【０５８３】
Ｎｏ−ｏｐ
【０５８４】
図４０は、例示的な非ｏｐ記述子４０００及びｎｏ−ｏｐ完了記録４００１を示す。Ｎｏ−ｏｐオペレーション４００５は、ＤＭＡオペレーションを実行しない。それは、完了記録及び／又は完了割込みを要求してよい。それがバッチ内にある場合、バッチ内のすべての前の記述子の完了の後に、Ｎｏ−ｏｐ記述子の完了が発生することを確保するフェンスフラグを規定してよい。
【０５８５】
バッチ
【０５８６】
図４１は、例示的なバッチ記述子４１００及びｎｏ−ｏｐ完了記録４１０１を示す。バッチオペレーション４１０８は一度に複数の記述子をキューイングする。記述子リストアドレス４１０２は、処理対象のワーク記述子の連続的なアレイについてのアドレスである。一実施例において、アレイ内の各記述子は６４バイトである。記述子リストアドレス４１０２は、６４バイトアラインである。記述子総数４１０３は、アレイ内の記述子の数である。アレイ内の記述子のセットは、「バッチ」と呼ばれる。バッチ内で可能とされる記述子の最大数は、ＧＥＮＣＡＰ内の最大バッチサイズフィールドに与えられる。
【０５８７】
バッチ記述子内のＰＡＳＩＤ４１０４及びＵ／Ｓフラグ４１０５は、バッチ内のすべての記述子に用いられる。バッチ内の記述子におけるＰＡＳＩＤ４１０４及びＵ／Ｓフラグフィールド４１０５は無視される。バッチ記述子４１００内の完了キューイネーブルフラグが設定された場合、完了記録アドレス有効フラグは１でなければならず、完了キューアドレスフィールド４１０６は、バッチ内のすべての記述子に用いられる完了キューのアドレスを含む。この場合、バッチ内の記述子における完了記録アドレスフィールド４１０６は無視される。一般的な機能レジスタ内の完了キューサポートフィールドが０である場合、完了キューイネーブルフラグが予約されている。
【０５８８】
バッチ記述子内の完了キューイネーブルフラグが０である場合、バッチ内の各記述子に対する完了記録は、各記述子内の完了記録アドレス４１０６に書き込まれる。この場合、バッチ記述子内の要求完了記録フラグが１である場合、完了キューアドレスフィールドは、もっぱらバッチ記述子用の完了記録アドレス４１０６として用いられる。
【０５８９】
バッチ完了記録４１０１のステータスフィールド４１１０は、バッチにおける記述子のすべてが完了した場合、成功を示し、そうでなければ、それは、１又は複数の記述子が成功に相当しないステータスで完了したことを示す。完了記録の記述子完了フィールド４１１１は、それらが成功したか否かに関わらず、処理されていたバッチ内の記述子の総数を含む。記述子完了４１１１は、バッチ内にフェンスがある場合、又は、バッチを読み出している間にページフォールトが発生した場合、記述子総数４１０３より少なくてよい。
【０５９０】
ドレイン
【０５９１】
図４２は、例示的なドレイン記述子４２００及びドレイン完了記録４２０１を示す。ドレインオペレーション４２０８は、ドレイン記述子４２００がサブミットされたワークキュー内の、ＰＡＳＩＤ４２０２と関連付けられたすべての未処理の記述子の完了を待つ。この記述子は、デバイスを使用している処理により、通常のシャットダウン中に用いられ得る。ＰＡＳＩＤ４２０２と関連付けられたすべての記述子を待つために、ソフトウェアは、ＰＡＳＩＤ４２０２が用いられていた各ワークキューに別々のドレインオペレーションをサブミットすべきである。ソフトウェアは、ドレイン記述子４２０１がサブミットされた後、かつ、それが完了する前に、ワークキューにサブミットされる特定のＰＡＳＩＤ４２０２を有する記述子がないことを確保すべきである。
【０５９２】
ドレイン記述子４２０１は、バッチに含まれていなくてよく、それは、非サポートオペレーションタイプとして処理される。ドレインは、要求完了記録又は要求完了割込みを規定すべきである。完了通知は、他の記述子が完了した後に行われる。
【０５９３】
メモリ移動
【０５９４】
図４３は、例示的なメモリ移動記述子４３００及びメモリ移動完了記録４３０１を示す。メモリ移動オペレーション４３０８は、メモリをソースアドレス４３０２から宛先アドレス４３０３にコピーする。コピーされるバイト数は、転送サイズ４３０４により与えられる。メモリアドレス又は転送サイズに対するアライメント要求はない。ソース及び宛先領域が重複する場合、メモリコピーは、ソースバッファ全体が一時的な空間にコピーされ、次に、宛先バッファにコピーされたかのように行われる。これは、宛先バッファの開始が、ソースバッファの終了と重複する場合に、コピーの方向を反転することにより実施され得る。
【０５９５】
オペレーションが、ページフォールトに起因して部分的に完了した場合、完了記録の方向フィールド４３１０は、ソース及び宛先バッファの先頭から開始するコピーが実行された場合に０であり、方向フィールドは、コピーの方向が反転された場合に１である。
【０５９６】
部分的な完了後にオペレーションを再開するために、方向が０である場合、連続的な記述子内のソース及び宛先アドレスフィールド４３０２−４３０３は、バイト完了により増加されるべきであり、転送サイズは、バイト完了４３１１により低減されるべきである。方向が１である場合、転送サイズ４３０４は、バイト完了４３１１により低減されるべきであるが、ソース及び宛先アドレスフィールド４３０２−４３０３は、元の記述子と同じであるべきである。後続の部分的な完了が発生した場合、方向フィールド４３１０は、第１の部分的な完了に対するものと同じでなくてよいことに留意する。
【０５９７】
満杯（フィル（Ｆｉｌｌ））
【０５９８】
図４４は、例示的なフィル記述子４４００を示す。メモリフィルオペレーション４４０８は、宛先アドレス４４０６におけるメモリをパターンフィールド４４０５内の値で満杯にする。パターンサイズは、８バイトであってよい。より小さいパターンを用いるために、ソフトウェアは、記述子内のパターンを複製しなければならない。書き込まれるバイト数は、転送サイズ４４０７により与えられる。転送サイズは、パターンサイズの倍数である必要はない。宛先アドレス又は転送サイズに対するアライメント要求はない。オペレーションがページフォールトに起因して部分的に完了した場合、完了記録のバイト完了フィールドは、障害が発生する前に宛先に書き込まれたバイト数を含む。
【０５９９】
比較
【０６００】
図４５は、例示的な比較記述子４５００及び比較完了記録４５０１を示す。比較オペレーション４５０８は、ソース１のアドレス４５０４におけるメモリと、ソース２のアドレス４５０５におけるメモリとを比較する。比較されるバイト数は、転送サイズ４５０６により与えられる。メモリアドレス又は転送サイズ４５０６に対するアライメント要求はない。完了記録アドレス有効及び要求完了記録フラグは１でなければならず、完了記録アドレスは有効でなければならない。比較の結果は、完了記録４５０１の結果フィールド４５１０に書き込まれる。０の値は、２つのメモリ領域がマッチすることを示し、１の値は、それらがマッチしないことを示す。結果４５１０が１である場合、完了記録のバイト完了４５１１フィールドは、第１の差のバイトオフセットを示す。オペレーションが、ページフォールトに起因して部分的に完了した場合、結果は０である。差が検出された場合、その差は、ページフォールトの代わりに報告されるであろう。
【０６０１】
オペレーションが成功し、チェック結果フラグが１である場合、完了記録のステータスフィールド４５１２は、以下のテーブルに示されるように、結果及び予測結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、比較の結果に基づいてバッチの実行を継続又は停止することを可能にする。
【表２８】
0006988040.tif 000033
【０６０２】
比較中間
【０６０３】
図４６は、例示的な比較中間記述子４６００を示す。比較中間処理４６０８は、ソースアドレス４６０１におけるメモリをパターンフィールド４６０２における値と比較する。パターンサイズは８バイトである。より小さいパターンを用いるために、ソフトウェアは、記述子内のパターンを複製しなければならない。比較されるバイト数は、転送サイズ４６０３により与えられる。転送サイズは、パターンサイズの倍数である必要はない。完了記録アドレス有効及び要求完了記録フラグは、１でなければならない。完了記録アドレス４６０４は有効でなければならない。比較の結果は、完了記録の結果フィールドに書き込まれる。０の値は、メモリ領域がパターンにマッチすることを示し、１の値は、それがマッチしないことを示す。結果が１である場合、完了記録のバイト完了フィールドは、第１の差の位置を示す。正確なバイト位置ではないかも知れないが、第１の差より大きくないことが保証される。オペレーションが、ページフォールトに起因して部分的に完了した場合、結果は０である。差が検出された場合、その差は、ページフォールトの代わりに報告されるであろう。一実施例において、比較中間に関する完了記録フォーマットと、チェック結果及び予測結果の挙動とは比較と同一である。
【０６０４】
作成差分記録
【０６０５】
図４７は、例示的な作成差分記録記述子４７００及び作成差分記録完了記録４７０１を示す。作成差分記録オペレーション４７０８は、ソース１のアドレス４７０５におけるメモリとソース２のアドレス４７０２におけるメモリとを比較して、ソース２に一致するようにソース１を更新するのに必要とされる情報を含む差分記録を生成する。比較されるバイト数は、転送サイズ４７０３により与えられる。以下で説明されるように、転送サイズは、差分記録に格納され得る最大オフセットの分制限される。メモリアドレス又は転送サイズに対するアライメント要求がない。完了記録アドレス有効及び要求完了記録フラグは、１でなければならず、完了記録アドレス４７０４は、有効でなければならない。
【０６０６】
差分記録の最大サイズは、最大差分記録サイズ４７０９により与えられる。最大差分記録サイズ４７０９は、差分サイズ（１０バイト）の倍数とするべきであり、ＧＥＮＣＡＰ内の最大転送サイズより大きくないものでなければならない。差分記録の実際のサイズは、ソース１とソース２との間で検出された差の数に依存し、それは、完了記録の差分記録サイズフィールド４７１０に書き込まれる。差分記録に必要とされる空間が、記述子に規定された最大差分記録サイズ４７０９を超える場合、オペレーションは、部分的な差分記録で完了する。
【０６０７】
比較の結果は、完了記録４７０１の結果フィールド４７１１に書き込まれる。２つの領域が正確に一致する場合、結果は０であり、差分記録サイズは０であり、バイト完了は０である。２つの領域が一致しない場合、差分の完全なセットが差分記録に書き込まれ、結果は１であり、差分記録サイズは、得られたすべての差の合計サイズを含み、バイト完了は０である。２つの領域が一致せず、すべての差分を記録するのに必要な空間が最大差分記録サイズを超える場合、結果は２であり、差分記録サイズ４７１０は、差分記録に書き込まれた差分のセットのサイズ（典型的には、記述子に規定される差分記録サイズに等しい、又は、ほぼ等しい）を含み、バイト完了４７１２は、差分記録内の空間が超過する前に比較されたバイト数を含む。
【０６０８】
オペレーションが、ページフォールトに起因して部分的に完了した場合、前の段落で説明したように、結果４７１１は０又は１のいずれか一方であり、バイト完了４７１２は、ページフォールトが発生する前に比較されたバイト数を含み、差分記録サイズは、ページフォールトが発生する前に差分記録で用いられた空間を含む。
【０６０９】
差分記録のフォーマットが図４８に示される。差分記録は、差分（ｄｅｌｔａ）のアレイを含む。各差分は、２バイトのオフセット４８０１及びソース１における対応する８バイトとは異なるソース２からの８バイトブロックのデータ４８０２を含む。差分記録の合計サイズは１０の倍数である。オフセット４８０１は、８バイトの倍数を表す１６ビットのフィールドであるので、表現され得る最大オフセットは、０ｘ７ＦＦＦ８であり、そのため、最大転送サイズは、０ｘ８００００バイト（５１２ＫＢ）である。
【０６１０】
オペレーションが成功し、チェック結果フラグが１である場合、完了記録のステータスフィールドは、以下のテーブルに示されるように、結果及び予測結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、差分記録作成の結果に基づいてバッチの実行を継続又は停止することを可能にする。予測結果のビット７：２は無視される。
【表２９】
0006988040.tif 000034
【０６１１】
適合差分記録
【０６１２】
図４９は、例示的な適合差分記録記述子４９０１を示す。適合差分記録オペレーション４９０２は、宛先アドレス４９０３におけるメモリのコンテンツに差分記録を適用する。差分記録アドレス４９０４は、１に等しい結果で完了した作成差分記録オペレーション４９０２により作成された差分記録のアドレスである。差分記録サイズ４９０５は、作成差分記録オペレーション４９０２の完了記録において報告されるような差分記録のサイズである。宛先アドレス４９０３は、差分記録が作成された場合、ソース１のアドレスにおけるメモリと同じコンテンツを含むバッファのアドレスである。転送サイズ４９０６は、差分記録が作成された場合に用いられる転送サイズと同じである。適合差分記録オペレーション４９０２が完了した後に、宛先アドレス４９０３におけるメモリは、差分記録が作成された場合に、ソース２のアドレスにおけるメモリにあったコンテンツと一致する。メモリアドレス又は転送サイズに対するアライメント要求はない。
【０６１３】
適合差分記録オペレーション４９０２中にページフォールトが発生した場合、完了記録のバイト完了フィールドは、宛先に適用されることに成功した差分記録のバイト数を含む。ソフトウェアが、オペレーションを再開するために別の記述子をサブミットすることを選択した場合、連続的な記述子は、元と同じ宛先アドレス４９０３を含む。差分記録アドレス４９０４は、バイト完了により増加されるはずであり（したがって、第１の未適用の差分を指し示す）、差分記録サイズ４９０５は、バイト完了により低減されるはずである。
【０６１４】
図５０は、作成差分記録及び適合差分記録オペレーションの利用についての一実施例を示す。まず、作成差分記録オペレーション５００１が実行される。作成差分記録オペレーション５００１は、２つのソースバッファ−ソース１及び２−を読み出して、その完了記録５００３に実際の差分記録サイズ５００４を記録する差分記録５０１０を書き込む。適合差分記録オペレーション５００５は、作成差分記録オペレーション５００１により書き込まれた差分記録のコンテンツをそのサイズ及びソース１データのコピーと共に取り出し、元のソース２バッファの複製となるように宛先バッファ５０１５を更新する。作成差分記録オペレーションは、最大差分記録サイズ５００２を含む。
【０６１５】
デュアルキャストを用いたメモリコピー
【０６１６】
図５１は、例示的なデュアルキャストを用いたメモリコピー記述子５１００、及び、デュアルキャストを用いたメモリコピー完了記録５１０２を示す。デュアルキャストオペレーション５１０４を用いたメモリコピーは、ソースアドレス５１０５から、宛先１のアドレス５１０６及び宛先２のアドレス５１０７の両方にメモリをコピーする。コピーされるバイト数は、転送サイズ５１０８により与えられる。ソースアドレス又は転送サイズに対するアライメント要求はない。２つの宛先アドレス５１０６−５１０７のビット１１：０は同じであるべきである。
【０６１７】
ソース領域が宛先領域のいずれか一方と重複する場合、メモリコピーは、ソースバッファ全体が一時的な空間にコピーされ、次に、宛先バッファにコピーされたかのように行われる。これは、宛先バッファの先頭がソースバッファの終了と重複する場合にコピーの方向を反転することにより実施され得る。ソース領域が宛先領域の両方と重複する場合、又は、２つの宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、コピーオペレーションは、宛先領域の両方に同じバイト数を書き込んだ後に停止し、完了記録の方向フィールド５１１０は、ソース及び宛先バッファの先頭から開始するコピーが実行される場合に０であり、方向フィールドは、コピーの方向が反転された場合に１である。
【０６１８】
部分的な完了後にオペレーションを再開するために、方向５１１０が０である場合、連続的な記述子内のソース５１０５及び両方の宛先アドレスフィールド５１０６−５１０７は、バイト完了５１１１により増加されるべきであり、転送サイズ５１０８は、バイト完了５１１１により低減される。方向が１である場合、転送サイズ５１０８は、バイト完了５１１１により低減されるべきであるが、ソース５１０５及び宛先５１０６−５１０７アドレスフィールドは、元の記述子と同じであるべきである。後続の部分的な完了が発生した場合、方向フィールド５１１０は、第１の部分的な完了に対するものと同じでなくてもよいことに留意する。
【０６１９】
巡回冗長検査（ＣＲＣ）生成
【０６２０】
図５２は、例示的なＣＲＣ生成記述子５２００及びＣＲＣ生成５２０１を示す。ＣＲＣ生成処理５２０４は、ソースアドレスにおけるメモリ上のＣＲＣを計算する。ＣＲＣ計算に用いられるバイト数は、転送サイズ５２０５により与えられる。メモリアドレス又は転送サイズ５２０５に対するアライメント要求はない。完了記録アドレス有効及び要求完了記録フラグは１でなければならず、完了記録アドレス５２０６は有効でなければならない。計算されたＣＲＣ値は、完了記録に書き込こまれる。
【０６２１】
オペレーションが、ページフォールトに起因して部分的に完了した場合、部分的なＣＲＣ結果は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子のＣＲＣシードフィールドへこの部分的な結果をコピーしなければならない。そうでなければ、ＣＲＣシードフィールドは０であるべきである。
【０６２２】
ＣＲＣ生成を用いたコピー
【０６２３】
図５３は、ＣＲＣ生成記述子５３００を用いた例示的なコピーを示す。ＣＲＣ生成処理５３０５を用いたコピーは、ソースアドレス５３０２から宛先アドレス５３０３にメモリをコピーし、コピーされたデータに対するＣＲＣを計算する。コピーされたバイト数は、転送サイズ５３０４により与えられる。メモリアドレス又は転送サイズに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。完了記録アドレス有効及び要求完了記録フラグは１でなければならず、完了記録アドレスは有効でなければならない。計算されたＣＲＣ値は、完了記録に書き込まれる。
【０６２４】
オペレーションが、ページフォールトに起因して部分的に完了した場合、部分的なＣＲＣ結果は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子のＣＲＣシードフィールドへこの部分的な結果をコピーしなければならない。そうでなければ、ＣＲＣシードフィールドは０とすべきである。一実施例において、ＣＲＣ生成を用いたコピー用の完了記録フォーマットは、ＣＲＣ生成用のフォーマットと同じである。
【０６２５】
データ整合性フィールド（ＤＩＦ）挿入
【０６２６】
図５４は、例示的なＤＩＦ挿入記述子５４００及びＤＩＦ挿入完了記録５４０１を示す。ＤＩＦ挿入オペレーション５４０５は、ソースアドレス５４０２から宛先アドレス５４０３にメモリをコピーし、ソースデータ上のデータ整合性フィールド（ＤＩＦ）を計算し、ＤＩＦを出力データに挿入する。コピーされたソースバイトの数は、転送サイズ５４０６により与えられる。ＤＩＦ計算は、例えば、５１２、５２０、４０９６又は４１０４バイトのソースデータの各ブロックで実行される。転送サイズは、ソースブロックサイズの倍数とすべきである。宛先に書き込まれたバイト数は、ソースブロックごとに、転送サイズに８バイトを加えた値である。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、参照タグ及びアプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子へこれらのフィールドをコピーし得る。
【０６２７】
ＤＩＦストリップ
【０６２８】
図５５は、例示的なＤＩＦストリップ記述子５５００及びＤＩＦストリップ完了記録５５０１を示す。ＤＩＦストリップオペレーション５５０５は、ソースアドレス５５０２から宛先アドレス５５０３にメモリをコピーし、ソースデータ上のデータ整合性フィールド（ＤＩＦ）を計算し、計算されたＤＩＦを、データに含まれるＤＩＦと比較する。読み出されるソースバイトの数は、転送サイズ５５０６により与えられる。ＤＩＦ計算は、５１２、５２０、４０９６又は４１０４バイトであり得るソースデータの各ブロックで実行される。転送サイズは、ソースブロックごとに、ソースブロックサイズの倍数に８バイトを加えた値とすべきである。宛先に書き込まれるバイト数は、ソースブロックごとに、転送サイズから８バイトを差し引いた値である。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、参照タグ及びアプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子へこれらのフィールドをコピーしてよい。
【０６２９】
ＤＩＦ更新
【０６３０】
図５６は、例示的なＤＩＦ更新記述子５６００及びＤＩＦ更新完了記録５６０１を示す。ＤＩＦ更新オペレーション５６０５を用いたメモリ移動は、ソースアドレス５６０２から宛先アドレス５６０３にメモリをコピーし、ソースデータ上のデータ整合性フィールド（ＤＩＦ）を計算し、計算されたＤＩＦを、データに含まれるＤＩＦと比較する。記述子内の宛先ＤＩＦフィールドを用いてソースデータ上のＤＩＦを同時に計算し、計算されたＤＩＦを出力データに挿入する。読み出されるソースバイトの数は、転送サイズ５６０６により与えられる。ＤＩＦ計算は、５１２、５２０、４０９６又は４１０４バイトであり得るソースデータの各ブロックで実行される。転送サイズ５６０６は、ソースブロックごとに、ソースブロックサイズの倍数に８バイトを加えた値とすべきである。宛先に書き込まれるバイト数は、転送サイズ５６０６と同じである。メモリアドレスに対するアライメント要求はない。ソース及び宛先領域が重複する場合、それはエラーである。オペレーションが、ページフォールトに起因して部分的に完了した場合、ソース及び宛先参照タグ、及び、アプリケーションタグの更新された値は、ページフォールト情報と共に完了記録に書き込まれる。ソフトウェアが障害を是正し、オペレーションを再開する場合、連続的な記述子にこれらのフィールドをコピーしてよい。
【０６３１】
以下のテーブルＡＡは、一実施例において用いられるＤＩＦフラグを示す。テーブルＢＢは、一実施例において用いられるソースＤＩＦフラグを示し、テーブルＣＣは、一実施例における宛先ＤＩＦフラグを示す。
【表３０】
0006988040.tif 000035
【０６３２】
ソースＤＩＦフラグ
【表３１】
0006988040.tif 000036
【０６３３】
宛先ＤＩＦフラグ
【表３２】
0006988040.tif 000037
【０６３４】
一実施例において、ＤＩＦ結果フィールドは、ＤＩＦオペレーションのステータスを報告する。このフィールドは、ＤＩＦストリップ及び更新オペレーションのためだけに、かつ、完了記録のステータスフィールドが成功又は誤った述部を伴う成功である場合のみ定義されてよい。以下のテーブルＤＤは、例示的なＤＩＦ結果フィールドコードを示す。
【表３３】
0006988040.tif 000038
【０６３５】
Ｆ検出条件は、テーブルＥＥに以下に示されるうちの１つが真である場合に検出される。
【表３４】
0006988040.tif 000039
【０６３６】
オペレーションが成功し、チェック結果フラグが１である場合、完了記録のステータスフィールドは、以下のテーブルＦＦに示されるように、ＤＩＦ結果に従って設定される。これは、フェンスフラグと同じバッチ内の後続の記述子が、オペレーションの結果に基づいてバッチの実行を継続又は停止することを可能にする。
【表３５】
0006988040.tif 000040
【０６３７】
キャッシュフラッシュ
【０６３８】
図５７は、例示的なキャッシュフラッシュ記述子５７００を示す。キャッシュフラッシュオペレーション５７０５は、宛先アドレスでプロセッサキャッシュをフラッシュする。フラッシュされるバイト数は、転送サイズ５７０２により与えられる。転送サイズは、キャッシュラインサイズの倍数である必要はない。宛先アドレス又は転送サイズに対するアライメント要求はない。宛先領域により部分的にカバーされる任意のキャッシュラインがフラッシュされる。
【０６３９】
宛先キャッシュフィルタグが０である場合、影響を受けるキャッシュラインは、キャッシュ階層の各レベルから無効にされ得る。キャッシュラインは、キャッシュ階層の任意のレベルで修正されたデータを含み、データは、メモリに書き戻される。これは、いくつかのプロセッサに実装されたＣＬＦＬＵＳＨ命令の挙動と同様である。
【０６４０】
宛先キャッシュフィルタグが１である場合、修正されたキャッシュラインは、メインメモリに書き込まれるが、キャッシュから追い出されない。これは、いくつかのプロセッサにおけるＣＬＷＢ命令の挙動と同様である。
【０６４１】
期限アクセラレータ（ｔｅｒｍ  ａｃｃｅｌｅｒａｔｏｒ）は、ホストプロセッサ上で実行中のソフトウェアにより用いられ得る緩く結合したエージェントを参照して、任意の種類の計算又はＩ／Ｏタスクをオフロード又は実行するために本明細書でときどき用いられる。アクセラレータ及び使用モデルのタイプに応じて、これらは、メモリ又はストレージ、計算、通信又はこれらの任意の組み合わせに対するデータ移動を実行するタスクであり得る。
【０６４２】
「緩く結合」とは、ホストソフトウェアにより、これらのアクセラレータがどのようにさらされ、アクセスされるかを指す。具体的には、これらは、プロセッサＩＳＡ拡張としてさらされることはなく、代わりに、プラットフォーム上のＰＣＩエクスプレス可算エンドポイントデバイスとしてさらされる。緩い結合は、これらのエージェントが、ホストソフトウェアからのワーク要求を受け入れ、ホストプロセッサに対して非同期的に動作することを可能にする。
【０６４３】
「アクセラレータ」は、プログラマブルエージェント（例えば、ＧＰＵ／ＧＰＧＰＵ）、固定機能エージェント（例えば、圧縮又は暗号化エンジン）、又は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能エージェントであり得る。これらのいくつかは、計算オフロードに用いられ、一方、その他（例えば、ＲＤＭＡ又はホストファブリックインタフェース）は、パケット処理、通信、ストレージ又はメッセージパッシングオペレーションに用いられてよい。
【０６４４】
アクセラレータデバイスは、オンダイ（すなわち、プロセッサと同じダイ）、オンパッケージ、チップセット、マザーボードを含む、異なるレベルで物理的に集積されてよい、又は、別個のＰＣＩｅ接続型デバイスであり得る。集積されたアクセラレータについて、たとえ、ＰＣＩエクスプレスエンドポイントデバイスとして列挙されるとしても、これらのアクセラレータのいくつかは、（オンダイコヒーレントファブリック又は外部コヒーレントインタフェースに）コヒーレントに取り付けられる一方、その他は、内部非コヒーレントインタフェース又は外部のＰＣＩエクスプレスインタフェースに取り付けられ得る。
【０６４５】
概念的なレベルでの、「アクセラレータ」及び高性能Ｉ／Ｏデバイスコントローラは同様である。これらを区別するものは、統合／共有仮想メモリ、ページング可能なメモリ上で動作する能力、ユーザモードワークサブミッション、タスクスケジューリング／プリエンプション及び低レイテンシ同期に対するサポートなどの機能である。その結果、アクセラレータは、新たな改良型の高性能Ｉ／Ｏデバイスのカテゴリとみなされ得る。
【０６４６】
オフロードオペレーションモデル
【０６４７】
アクセラレータオフロードオペレーションモデルは、３つの利用カテゴリに広く分類され得る。
【０６４８】
１．ストリーミング：ストリーミングオフロードモデルでは、小さい単位のワークが、高いレートでアクセラレータにストリーミングされる。この利用の典型的な例は、高いレートで、様々なタイプのパケット処理を実行するネットワークデータプレーンである。
【０６４９】
２．低レイテンシ：いくつかのオフロード利用に関して、オフロードオペレーション（アクセラレータへのタスクのディスパッチ及びそれを実行するアクセラレータの両方）のレイテンシは重要な意味を持つ。この利用の例は、ホストファブリックを介した遠隔取得、プット及びアトミックオペレーションを含む低レイテンシメッセージパッシング構成モデルである。
【０６５０】
３．スケーラブル：スケーラブルなオフロードは、デバイス上でサポートされる複数のワークキュー又は複数のドアベルなどのアクセラレータデバイスにより課される制約なしで、多数（限りない数）のクライアントアプリケーション（仮想マシン内及び仮想マシンを介して）に（例えば、リング３などの階層保護ドメイン内の最も高いリングから）計算アクセラレータのサービスが直接的にアクセス可能な利用を指す。本明細書で説明されるアクセラレータデバイス及びプロセッサ相互接続のいくつかのは、このカテゴリに含まれる。ＧＰＵ、ＧＰＧＰＵ、ＦＰＧＡ又は圧縮アクセラレータ、又は、メッセージパッシングなど、ワークのタイムシェアリング／スケジューリングをサポートする計算オフロードデバイスに適用されるそのようなスケーラビリティは、ロック無しオペレーションに関する大きなスケーラビリティ要件を有するエンタープライズデータベースなどを利用する。
【０６５１】
オフロードモデルにわたるワークディスパッチ
【０６５２】
上記のオフロードオペレーションモデルのそれぞれは、以下に説明されるような独自のワークディスパッチの課題を負う。
【０６５３】
１．ストリーミングオフロードの利用のためのワークディスパッチ
【０６５４】
ストリーミングの利用に関して、典型的なワークディスパッチモデルは、メモリに存在するワークキューを用いることである。具体的には、デバイスは、メモリ内のワークキューの位置及びサイズを構成される。ハードウェアは、新たなワーク要素をワークキューに加えた場合にソフトウェアにより更新されるドアベル（テールポインタ）レジスタを実装する。ハードウェアは、ワークキュー要素上の生産者−消費者フロー制御を強化するために、ソフトウェアに関する現在のヘッドポインタを報告する。ストリーミングの利用に関して、典型的なモデルは、（多くの場合、ソフトウェアによるＵＣ  ＭＭＩＯ読み出しのオーバヘッドを回避するために、ハードウェアによりホストメモリ内で維持される）ソフトウェアにキャッシュされたヘッドポインタ及びテールポインタを調べることによりワークキュー内に空きがあるか否かをチェックし、新たなワーク要素をメモリに存在するワークキューに加え、デバイスへのドアベルレジスタ書き込みを用いてテールポインタを更新するソフトウェアのためのものである。
【０６５５】
ドアベル書き込みは、典型的には、４バイト又は８バイトのキャッシュ不能な（ＵＣ）、ＭＭＩＯへの、書き込みである。いくつかのプロセッサにおいて、ＵＣ書き込みは、（生産者−消費者利用のために必要とされる）ＵＣ書き込みを発行する前に、より古い格納がグローバルに監視されることを確保するが、ＵＣ書き込みがプラットフォームによりポストされるまでに発行されてしまうことからプロセッサパイプライン内のすべての若い方の格納をブロックする直列化されたオペレーションである。Ｘｅｏｎサーバプロセッサ上でのＵＣ書き込み動作に対する典型的なレイテンシは、８０〜１００ナノ秒のオーダにあり、すべての若い方の格納オペレーションがコアによりブロックされている時間の間、ストリーミングオフロード性能を制限する。
【０６５６】
ＵＣドアベル書き込みに続いて若い方の格納の直列化に取り組む１つのアプローチは、ドアベル書き込みのためのライトコンバイニング（ＷＣ）格納オペレーション（ＷＣの弱いオーダリングに起因する）を用いることであるが、ドアベル書き込みのためにＷＣ格納を用いることは、いくつかの課題を負う。ドアベル書き込みサイズ（典型的には、ＤＷＯＲＤ又はＱＷＯＲＤ）は、キャッシュラインサイズより小さい。これらの部分的な書き込みは、潜在的なライトコンバイニング機会のためのそのライトコンバイニングバッファ（ＷＣＢ）において、プロセッサが部分的な書き込みを維持することに起因して、追加のレイテンシを発生させ、プロセッサから発行されるドアベル書き込みに関するレイテンシを発生させる。ソフトウェアは、これらに、明示的な格納フェンスを通じて発行されることができ、ＵＣドアベルと同様に、若い方の格納に同じ直列化を発生させる。
【０６５７】
ＷＣにマッピングされたＭＭＩＯに関する別の問題点は、（ＭＯＶＮＴＤＱＡを用いた）誤った予測及び推測的な読み出しが、（読み出側に影響を与え得るレジスタを有する）ＷＣにマッピングされたＭＭＩＯにさらされることである。ＵＣマッピングＭＭＩＯレジスタの残りよりも別々のページにおけるＷＣマッピングドアベルレジスタをデバイスがホストする必要があるので、これに対処することはデバイスにとって面倒である。これは、仮想化利用での課題も負うことになり、ＶＭＭソフトウェアは、ゲストメモリタイプを無視して、ＥＰＴページテーブルを用いてゲストにさらされる任意のデバイスＭＭＩＯに対するＵＣマッピングを強制することはもはやできない。
【０６５８】
本明細書で説明されるＭＯＶＤＩＲＩ命令は、これらのストリーミングオフロードの利用でのドアベル書き込みのためにＵＣ又はＷＣ格納を用いる上記の制限に対処する。
【０６５９】
２．低レイテンシオフロードの利用のためのワークディスパッチ
【０６６０】
いくつかのタイプのアクセラレータデバイスは、最小のレイテンシで要求されたオペレーションを完了するために高度に最適化されている。（スループットを最適化された）ストリーミングアクセラレータとは異なって、これらのアクセラレータは、一般に、メモリホスト型ワークキューからワーク要素（及び、いくつかの場合では、同一のデータバッファ）をフェッチするためにＤＭＡの読み出しレイテンシを回避するために、（デバイスＭＭＩＯを通じてさらされる）デバイスホスト型ワークキューを実装する。代わりに、ホストソフトウェアは、ワーク記述子（及び、いくつかの場合では、データも）を直接的に書き込むことによりワークを、デバイスＭＭＩＯ通じてさらされたデバイスホスト型ワークキューにサブミットする。そのようなデバイスの例では、ホストファブリックコントローラ、リモートＤＭＡ（ＲＤＭＡ）デバイス、及び、不揮発性メモリ（ＮＶＭ）エクスプレスなどの新たなストレージコントローラを含む。デバイスホスト型ワークキューの利用は、既存ＩＳＡに関して課題を発生させることはほとんどない。
【０６６１】
ＵＣ書き込みの直列化オーバヘッドを回避するために、デバイスホスト型ワークキューのＭＭＩＯアドレスは、典型的には、ＷＣとしてマッピングされる。これは、ストリーミングアクセラレータのためにＷＣにマッピングされたドアベルと同じ課題をさらす。
【０６６２】
さらに、デバイスホスト型ワークキューへのＷＣ格納を用いるには、デバイスがいくつかのプロセッサの書き込みアトミック性挙動を守る必要がある。例えば、最大で８バイトサイズの書き込み動作のアトミック性がいくつかのプロセッサは、キャッシュライン境界内（及び、ロックオペレーションのため）に書き込むことを保証するだけで、保証されたいずれの書き込み完了のアトミック性を定義するものではない。書き込み動作のアトミック性は、プロセッサ格納オペレーションが他のエージェントにより監視される粒度であり、プロセッサ命令セットアーキテクチャ及びコヒーレンシプロトコルの特性である。書き込み完了のアトミック性は、キャッシュ不可能な格納処理が受信機（メモリの場合では、メモリコントローラ、又は、ＭＭＩＯの場合ではデバイス）により監視される粒度である。書き込み完了のアトミック性は、書き込み動作のアトミック性より強く、プロセッサ命令セットアーキテクチャだけでなくプラットフォームの機能でもある。書き込み完了のアトミック性なしで、Ｎバイトのキャッシュ不可能な格納処理を実行するプロセッサ命令は、デバイスホスト型ワークキューによる複数の（トーン）書き込みトランザクションとして受信され得る。現在では、デバイスハードウェアは、デバイスホスト型ワークキューに書き込まれたワーク記述子の各ワード又はデータをトラッキングすることにより、そのようなトーン書き込みを守る必要がある。
【０６６３】
本明細書で説明されるＭＯＶＤＩＲ６４Ｂ命令は、保証された６４バイト書き込み完了のアトミック性で、６４バイト書き込みをサポートすることにより、上記の制限に対処する。ＭＯＶＤＩＲ６４Ｂは、永続性メモリ（メモリコントローラに取り付けられたＮＶＭ）への書き込み、及び、非透過型ブリッジ（ＮＴＢ）を通じたシステムを介したデータの複製など、その他の利用にとっても有用である。
【０６６４】
３．スケーラブルなオフロードの利用のためのワークディスパッチ
【０６６５】
アプリケーションからＩ／Ｏデバイスにワークをサブミットするための従来のアプローチは、Ｉ／Ｏコントローラデバイスに対してカーネルデバイスドライバを通じた要求を転送するカーネルＩ／Ｏスタックにシステムコールを行うことに関する。このアプローチは、スケーラブルである（任意の数のアプリケーションがデバイスのサービスを共有できる）一方、多くの場合、高性能デバイス及びアクセラレータに関する性能のボトルネックとなる直列化カーネルＩ／Ｏスタックのレイテンシ及びオーバヘッドを発生させる。
【０６６６】
低オーバヘッドのワークディスパッチをサポートするために、いくつかの高性能デバイスは、デバイスに対する直接的なワークディスパッチを可能にし、ワーク完了をチェックするダイレクトリング３アクセスをサポートする。このモデルでは、デバイスいくつかのリソース（ドアベル、ワークキュー、完了キューなど）がアプリケーションの仮想アドレス空間に割り当てられ、マッピングされる。一旦マッピングされると、リング３ソフトウェア（ユーザモードのドライバ又はライブラリ）は、アクセラレータにワークを直接ディスパッチできる。共有仮想メモリ（ＳＶＭ）機能をサポートするデバイスに関して、ドアベル及びワークキューがマッピングされるアプリケーション処理の処理アドレス空間識別子（ＰＡＳＩＤ）を識別するために、ドアベル及びワークキューは、カーネルモードドライバによりセットアップされる。特定のワークキューを通じてディスパッチされたワークアイテムを処理する場合、デバイスは、Ｉ／Ｏメモリ管理ユニット（ＩＯＭＭＵ）を通じた物理アドレス変換に対して仮想的なそのワークキューに構成されるそれぞれのＰＡＳＩＤを用いる。
【０６６７】
ダイレクトリング３ワークサブミッションに関する課題の１つは、スケーラビリティ問題である。アクセラレータデバイスに直接的にワークをサブミットできるアプリケーションクライアントの数は、アクセラレータデバイスによりサポートされるキュー／ドアベル（又は、デバイスホスト型ワークキュー）の数に依存する。これは、ドアベル又はデバイスホスト型ワークキューが、アプリケーションクライアントに静的に割り当てられ／マッピングされ、アクセラレータデバイス設計によりサポートされるこれらのリソースの数が固定されるからである。いくつかのアクセラレータデバイスは、（アプリケーションに対する要求についてドアベルを動的に取り外して再度取り付けることにより）それらが有するドアベルのリソースを過度に収容することで、このスケーラビリティの課題に「対処する」しようとしているが、多くの場合、拡大することが煩雑で難しい。これらが異なる仮想マシンに割り当てられる様々な仮想機能（ＶＦ）にわたって区分化される必要があるので、Ｉ／Ｏ仮想化（例えば、単一のルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ））をサポートするデバイスに関して、制限されたドアベル／ワークキューのリソースは、さらに制約される。
【０６６８】
スケーリング問題は、ロック無しオペレーション用のデータベースなどの企業アプリケーションにより用いられる（６４Ｋ〜１ＭのキューペアをサポートするＲＤＭＡデバイスのいくつかを有する）高性能なメッセージパッシングアクセラレータにとって、及び、多数のクライアントからサブミットされたタスクにわたるアクセラレータのリソースを共有することをサポートする計算アクセラレータにとって、最も重要な意味を持つ。
【０６６９】
本明細書で説明されるＥＮＱＣＭＤ／Ｓ命令は、アクセラレータ上のワークキューのリソースをサブスクライブし共有する限りない数のクライアントをイネーブルにするために、上記のスケーリングの制限に対処する。
【０６７０】
一実施例では、直接格納及びエンキュー格納を含むプロセッサコアによる新たなタイプの格納オペレーションを含む。
【０６７１】
一実施例において、直接格納は、本明細書で説明されるＭＯＶＤＩＲＩ及びＭＯＶＤＩＲ６４Ｂ命令により生成される。
【０６７２】
キャッシュ可能性：ＵＣ及びＷＣ格納と同様に、直接格納は、キャッシュ可能ではない。キャッシュされるアドレスに直接格納が発行された場合、直接格納前に、ラインは、キャッシュからライトバック（修正される場合）及び無効にされる。
【０６７３】
メモリオーダリング：ＷＣ格納と同様に、直接格納は、弱くオーダリングされる。具体的には、それらは、より古いＷＢ／ＷＣ／ＮＴ格納、ＣＬＦＬＵＳＨＯＰＴ及びＣＬＷＢに対して、異なるアドレスへのオーダリングは行われない。異なるアドレスへのより若いＷＢ／ＷＣ／ＮＴ格納、ＣＬＦＬＵＳＨＯＰＴ又はＣＬＷＢは、より古い直接格納をパスできる。同じアドレスに対する直接格納は、同じアドレスに対する（直接格納を含む）より古い格納を用いて常にオーダリングされる。直接格納は、格納フェンシング（例えば、ＳＦＥＮＣＥ、ＭＦＥＮＣＥ、ＵＣ／ＷＰ／ＷＴ格納、ロック、ＩＮ／ＯＵＴ命令など）を強化する任意のオペレーションによりフェンスされる。
【０６７４】
ライトコンバイニング：直接格納は、通常のＷＣ格納とは異なるライトコンバイニングの挙動を有する。具体的には、直接格納は、ライトコンバインバッファからの即時エビクションの対象となり、ひいては、同じアドレスへの若い方の格納（直接格納を含む）と組み合わせられない。ライトコンバイニングバッファにおいて保持されるより古いＷＣ／ＮＴ格納は、同じアドレスへの若い方の直接格納と組み合わせられてよく、そのような組み合わせを回避する必要がある利用は、同じアドレスへの直接格納を実行する前にフェンスＷＣ／ＮＴ格納を明示的に格納しなければならない。
【０６７５】
アトミック性：直接格納は、直接格納を発行する命令の書き込みサイズに関する書き込み完了のアトミック性をサポートする。ＭＯＶＤＩＲＩの場合では、宛先が４バイトアライン（又は、８バイトアライン）の場合、書き込み完了のアトミック性は、４バイト（又は、８バイト）である。ＭＯＶＤＩＲ６４Ｂに関して、宛先は、６４バイトアラインに強制され、書き込み完了のアトミック性は、６４バイトである。書き込み完了のアトミック性は、メモリコントローラ又はルートコンプレックスにより処理されるような複数の書き込みトランザクションに直接格納が分裂（ｔｏｒｎ）されていないことを保証する。直接格納をサポートするプロセッサ上のルートコンプレックス実装は、単一の非トーン・ポステッド（ｎｏｎ−ｔｏｒｎ  ｐｏｓｔｅｄ）書き込みトランザクションとして、外部のＰＣＩエクスプレスファブリック（及び、ＰＣＩエクスプレスのオーダリングに従うＳｏＣ内の内部Ｉ／Ｏファブリック）上で直接格納が転送されることを保証する。任意のエージェント（プロセッサ又は非プロセッサエージェント）からメモリ位置への読み出し処理は、直接格納オペレーションを発行する命令により書き込まれたデータのすべてか、そのいずれでもないかのいずれか一方を参照する。
【０６７６】
宛先メモリタイプの無視：直接格納は、（ＵＣ／ＷＰタイプを含む）宛先アドレスメモリタイプを無視し、常に弱いオーダリングに従う。これは、マッピングされたＵＣのメモリタイプ毎のＵＣオーダリングに従う通常のＭＯＶオペレーションを用いて、厳密な直列化要件を有し得る他のレジスタにアクセスし続けている間、ソフトウェアが、直接格納命令（ＭＯＶＤＩＲＩ又はＭＯＶＤＩＲ６４Ｂ）を用いて、デバイスＭＭＩＯをＵＣとしてマッピングし、特定のレジスタ（例えば、ドアベル又はデバイスホスト型ワークキューレジスタ）にアクセスすることを可能にする。これは、直接格納命令をゲストソフトウェア内から動作させることも可能にする一方、（デバイスに固有の知識を有していない）仮想マシンモニタ（ＶＭＭ）ソフトウェアは、プロセッサ拡張ページテーブル（ＥＰＴ）内のＵＣとしてゲスト露出ＭＭＩＯをマッピングし、ゲストメモリタイプを無視する。
【０６７７】
直接格納をサポートするＳｏＣは、以下のように、直接格納に関する書き込み完了のアトミック性を確保する必要がある。
【０６７８】
メインメモリへの直接格納：メインメモリへの直接格納に関して、コヒーレントファブリック及びシステムエージェントは、直接格納内のすべてのデータバイトが、単一の（非トーン（ｎｏｎ−ｔｏｒｎ））書き込みトランザクションとして、メモリへの要求に対してホームエージェント又は他のグローバルな可観測性（ＧＯ）ポイントに発行されることを確保する。永続性メモリをサポートするプラットフォームに関して、ホームエージェント、メモリコントローラ、メモリ側キャッシュ、インラインメモリ暗号化エンジン、永続性メモリを取り付けるメモリバス（例えば、ＤＤＲ−Ｔ）、及び、永続性メモリコントローラの各自が、直接格納に対して同じ又はより高い粒度の書き込み完了のアトミック性をサポートしなければならない。したがって、ソフトウェアは、メモリ（揮発性又は永続性）へのＭＯＶＤＩＲ６４Ｂを用いた６４バイトの直接格納を実行でき、すべての６４バイト書き込みがすべてのエージェントによりアトミックに処理されることが保証され得る。永続性メモリへの通常の書き込みと同様に、ソフトウェアが永続性に明示的にコミットする必要がある場合、ソフトウェアは、フェンス／コミット／フェンスシーケンスで直接格納を行う。
【０６７９】
メモリマッピングされたＩ／Ｏへの直接格納：メモリマッピングされたＩ／Ｏ（ＭＭＩＯ）への直接格納に関して、コヒーレントファブリック及びシステムエージェントは、直接格納におけるすべてのデータバイトが、単一の（非トーン（ｎｏｎ−ｔｏｒｎ））書き込みトランザクションとして、ルートコンプレックス（ＭＭＩＯへの要求に対してグローバルな可観測性ポイント）に発行されることを確保しなければならない。ルートコンプレックス実装は、ＰＣＩエクスプレスルートコンプレックス統合エンドポイント（ＲＣＩＥＰ）及びルートポート（ＲＰ）を取り付ける内部Ｉ／Ｏファブリック上で単一の（非トーン（ｎｏｎ−ｔｏｒｎ））ポステッド書き込みトランザクションとして、各直接格納が処理及び転送されることを確保しなければならない。ＰＣＩエクスプレスルートポート及びスイッチポートは、単一のポステッド書き込みトランザクションとして各直接格納を転送しなければならない。書き込み完了のアトミック性は、セカンダリブリッジ（例えば、レガシＰＣＩ、ＰＣＩ−Ｘブリッジ）又はセカンダリバス（例えば、ＵＳＢ、ＬＰＣなど）上、又は、その背後でデバイスをターゲットとする直接格納のために規定又は保証されていない。
【０６８０】
いくつかのＳｏＣの実装は、ＷＣ書き込み要求に対する書き込み完了のアトミック性を既に保証していることに留意する。具体的には、部分的なラインＷＣ書き込み（ＷＣｉＬ）及び全ラインＷＣ書き込み（ＷＣｉＬＦ）は、システムエージェント、メモリコントローラ、ルートコンプレックス及びＩ／Ｏファブリックにより、書き込み完了のアトミック性で既に処理されている。そのような実施例に関して、プロセッサが直接書き込みをＷＣ書き込みと区別する必要はなく、直接格納とＷＣ格納との挙動の違いは、プロセッサコアの内部にある。したがって、直接書き込みのための内部又は外部ファブリック仕様に対して提案される変更はない。
【０６８１】
ＰＣＩエクスプレスエンドポイント又はＲＣＩＥＰにより受信された直接書き込みの処理は、デバイス実装に固有のものである。デバイスのプログラミングインタフェースに応じて、デバイス及びそのドライバは、直接格納命令（例えば、ＭＯＶＤＩＲ６４Ｂ）を用いて常に書き込まれるそのレジスタのいくつか（例えば、ドアベルレジスタ又はデバイスホスト型ワークキューレジスタ）を必要とし、デバイス内でアトミックにこれらを処理してよい。デバイス上の他のレジスタへの書き込みは、アトミック性をなんら考慮又は期待することなく、デバイスにより処理され得る。ＲＣＩＥＰに関して、書き込みのアトミック性要件を有するレジスタがサイドバンド又はプライベートワイヤインタフェースを通じたアクセスのために実装されている場合、そのような実施例は、実装に固有の手段を通じて書き込みのアトミック性の特性を確保しなければならない。
【０６８２】
一実施例におけるエンキュー格納は、本明細書で説明されるＥＮＱＣＭＤ及びＥＮＱＣＭＤＳ命令により生成される。エンキュー格納の指定されたターゲットは、アクセラレータデバイス上の共有のワークキュー（ＳＷＱ）である。一実施例において、エンキュー格納は、以下の特性を有する。
【０６８３】
ノンポステッド：エンキュー格納は、ターゲットアドレスへの６４バイトの非ポスト書き込みトランザクションを生成し、成功又はリトライステータスを示す完了応答を受信する。完了応答で返される成功／リトライステータスは、ＥＮＱＣＭＤ／Ｓ命令により（例えば、ゼロフラグにおいて）ソフトウェアに返されてよい。
【０６８４】
キャッシュ可能性：一実施例において、エンキュー格納は、キャッシュ可能ではない。エンキュー格納をサポートするプラットフォームは、エンキュー・ノン・ポステッドライトが、これらの格納を受け入れるために、明示的に可能とされるアドレス（ＭＭＩＯ）範囲に転送されることのみに強制する。
【０６８５】
メモリオーダリング：エンキュー格納は、ノンポステッド書き込み完了ステータスを有するアーキテクチャの状態（例えば、ゼロフラグ）を更新してよい。したがって、多くても１つのエンキュー格納は、所与の論理プロセッサから未処理となる可能性がある。その意味では、論理プロセッサからのエンキュー格納は、同じ論理プロセッサから発行される別のエンキュー格納を渡すことができない。エンキュー格納は、より古いＷＢ／ＷＣ／ＮＴ格納、ＣＬＦＬＵＳＨＯＰＴ又はＣＬＷＢに対して、異なるアドレスへのオーダリングは行わない。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納の後、かつ、エンキュー格納前に明示的な格納フェンシングを用いてよい。エンキュー格納は、常に、より古い格納で同じアドレスにオーダリングされる。
【０６８６】
アライメント：ＥＮＱＣＭＤ／Ｓ命令は、エンキュー格納宛先アドレスが６４バイトアラインであることを強制する。
【０６８７】
アトミック性：ＥＮＱＣＭＤ／Ｓ命令により生成されるエンキュー格納は、６４バイト書き込み完了のアトミック性をサポートする。書き込み完了のアトミック性は、ルートコンプレックスにより処理されるような複数のトランザクションにエンキュー格納が分裂（ｔｏｒｎ）されていなことを保証する。エンキュー格納をサポートするプロセッサ上のルートコンプレックス実装は、単一の（非トーン（ｎｏｎ−ｔｏｒｎ））６４バイトの非ポスト書き込みトランザクションとして、各エンキュー格納がエンドポイントデバイスに転送されることを保証する。
【０６８８】
宛先メモリタイプの無視：直接格納と同様に、エンキュー格納は、宛先アドレスメモリタイプ（ＵＣ／ＷＰタイプを含む）を無視し、上記で説明されるようなオーダリングに常に従う。これは、通常のＭＯＶの命令を用いて、又は、直接格納（ＭＯＶＤＩＲＩ又はＭＯＶＤＩＲ６４Ｂ）命令を通じて、他のレジスタにアクセスし続けている間、ソフトウェアが、ＥＮＱＣＭＤ／Ｓ命令を用いて、デバイスＭＭＩＯをＵＣとしてマッピングし、共有のワークキュー（ＳＷＱ）レジスタにアクセスし続けることを可能にする。これは、エンキュー格納命令をゲストソフトウェア内から動作させることも可能にする一方、（デバイスに固有の知識を有していない）ＶＭＭソフトウェアは、プロセッサ拡張ページテーブル（ＥＰＴ）内のＵＣとしてゲスト露出ＭＭＩＯをマッピングし、ゲストメモリタイプを無視する。
【０６８９】
エンキュー格納に対するプラットフォームの検討
【０６９０】
いくつかの実施例について、プラットフォーム統合デバイスの特定のセットは、共有のワークキュー（ＳＷＱ）機能をサポートする。これらのデバイスは、内部Ｉ／Ｏファブリックを通じてルートコンプレックスに取り付けられてよい。これらのデバイスは、ＰＣＩエクスプレスルートコンプレックス統合エンドポイント（ＲＣＩＥＰ）、又は、仮想ルートポート（ＶＲＰ）の背後のＰＣＩエクスプレスエンドポイントデバイスのうちのいずれか一方としてホストソフトウェアにさらされ得る。
【０６９１】
ＳＷＱを有する統合デバイスをサポートするプラットフォームは、そのようなデバイスのみに対する内部Ｉ／Ｏファブリック上でのエンキュー・ノン・ポステッドライト要求の転送を制限すべきである。これは、新たなトランザクションタイプ（エンキュー・ノン・ポステッドライト）が、エンキューが認識していないエンドポイントデバイスによる不正な形式のトランザクション層パケット（ＴＬＰ）として処理されないことを確保するためのものである。
【０６９２】
（メインメモリアドレス範囲及びすべての他のメモリマップアドレス範囲を含む）すべての他のアドレスへのエンキュー格納は、プラットフォームにより終了し、通常の（エラーでない）応答が、リトライ完了ステータスと共に発行元のプロセッサに返される。特権のないソフトウェア（ＶＭＸ非ルートモードにおけるリング３ソフトウェア、又は、リング０ソフトウェア）が、ＥＮＱＣＭＤ／Ｓ命令を実行することによりエンキュー・ノンポステッド・書き込みトランザクションを生成できるので、そのようなエンキュー格納の終端上で生成されるプラットフォームのエラーはない。
【０６９３】
ルートコンプレックス実装は、ＳＷＱをサポートする統合デバイスに対する内部Ｉ／Ｏファブリック上での単一の（非トーン（ｎｏｎ−ｔｏｒｎ））ノンポステッド書き込みトランザクションとしてエンキュー格納が処理及び転送されることを確保すべきである。
【０６９４】
プラットフォーム性能の検討
【０６９５】
このセクションは、システムエージェント及びシステムエージェントによりエンキュー格納の処理におけるいくつかの性能の検討を説明する。
【０６９６】
エンキュー格納のためのシステムエージェントトラッカー（ＴＯＲ）エントリ割り当てに対して緩和されたオーダリング。
【０６９７】
メモリの整合性を維持するために、システムエージェント実装は、典型的には、コヒーレントメモリ及びＭＭＩＯに対するキャッシュラインアドレス（ＴＯＲエントリを割り当てる場合）への要求に対して厳密なオーダリングを強制する。これは、コヒーレントメモリアクセスに対して総合的なオーダリングをサポートするために必要とされる一方、エンキュー格納に対するこの厳密なオーダリングは、性能の問題を負う。これは、エンキュー格納が、デバイス上の共有のワークキュー（ＳＷＱ）をターゲットとしており、それによって、同じ宛先ＳＷＱアドレスを有する複数の論理プロセッサからエンキュー格納要求を発行させることが一般的だからである。また、システムエージェントにポストされた通常の格納とは異なり、エンキュー格納は、ノンポステッドであり、読み出しと同様のレイテンシを発生させる。共有のワークキューに対して未処理のエンキュー格納１つだけ許可するという条件を無効にするためには、システムエージェント実装は、同じアドレスへのエンキュー格納要求に対する厳密なオーダリングを緩和することが必要とされ、代わりに、同じアドレスに対する複数のインフライト（ｉｎ−ｆｌｉｇｈｔ）エンキュー格納のためのＴＯＲ割り当てを許可する。論理プロセッサは、同時に多くても１つのエンキュー格納だけを発行し得るので、システムエージェント／プラットフォームは、オーダリングを心配することなく独立に各エンキュー格納を処理できる。
【０６９８】
Ｉ／Ｏブリッジエージェントにおける複数の未処理のエンキュー・ノン・ポステッドライトのサポート。
【０６９９】
Ｉ／Ｏブリッジ実装は、典型的には、少数への（多くの場合、単一の要求への）ダウンストリームパスにおいてサポートされるノンポステッド（読み出し）要求の数を制限する。これは、（通常ＵＣ読み出しである）ＭＭＩＯへのプロセッサからの読み出しは、ほとんどの利用にとって重大な性能ではなく、返されるデータの読み出しに必要なバッファのために大きなキューデプスをサポートしているからであり、ハードウェア費用を増大させる。エンキュー格納が、アクセラレータデバイスに対するワークディスパッチに通常用いられることが予期されるので、エンキュー・ノン・ポステッドライトに対するこの制限されたキューイングを適用してしまうと、性能に弊害をもたらす可能性がある。Ｉ／Ｏブリッジ実装は、改善されたエンキュー・ノン・ポステッドライト帯域幅のために、（論理プロセッサの数のいくつかの実際の割合、論理プロセッサは、一度に１つの未処理のエンキュー格納要求しか有することができないので）増加したキューデプスをサポートすることが推奨される。読み出し要求とは異なり、エンキュー格納は、エンキュー・ノン・ポステッドライト完了が単に完了ステータス（成功対リトライ）を返すだけでデータを返さないので、データバッファのハードウェア費用を発生させない。
【０７００】
エンキュー・ノン・ポステッドライトに対する仮想チャネルサポート
【０７０１】
（例えば、ＰＣＩエクスプレストランザクションオーダリングにより特定される）生産者−消費者オーダリング要求を有するＩ／Ｏバス上の典型的なメモリ読み出し及び書き込み要求とは異なり、エンキュー・ノン・ポステッドライトは、Ｉ／Ｏバス上でのオーダリング要求を行わない。これは、エンキュー・ノン・ポステッドライトを発行し、それぞれの完了を返すために、非ＶＣ０仮想チャネルの使用を可能にする。非ＶＣ０チャネルを用いすることの利益は、エンキュー・ノン・ポステッドライト完了が、デバイスからホストにＶＣ０上のアップストリームポステッド書き込みの背後でオーダリングされることを回避することにより、より良好なレイテンシ（コアを遅延させるより少ないサイクル）を有することができる。実装では、統合デバイスの利用を慎重に考慮して、エンキュー・ノンポステッド完了レイテンシを最小化することが推奨される。
【０７０２】
エンキュー・ノン・ポステッドライトの中間停止
【０７０３】
高レイテンシな状況（例えば、内部リンクをウェイクアップさせる、又は、ロックフロー上での電源管理）で特定のフロー制御を処理するために、中間エージェント（システムエージェント、Ｉ／Ｏブリッジなど）は、正規のエンキュー格納要求をドロップして、発行したコアに、完了をリトライ応答と共に返すことを可能にする。エンキュー格納を発行するソフトウェアは、リトライ応答が、中間エージェント又はターゲットからのものである場合、又は、ソフトウェアにおいて、通常のリトライする（潜在的にいくつかのバックオフを伴う）場合、直接的な可視性を有していない。
【０７０４】
そのような中間停止を実行する実装では、そのような挙動は、ＳＷＱを共有するソフトウェアクライアントにわたる任意のサービス妨害攻撃をさらすことができないことを確認するように、非常に注意しなければならない。
【０７０５】
エンドポイントデバイス上での共有のワークキューのサポート
【０７０６】
図３４は、共有のワークキュー（ＳＷＱ）の概念を示し、複数の非協同ソフトウェアエージェント（アプリケーション３４１０−３４１２）が、本明細書で説明されるＥＮＱＣＭＤ／Ｓ命令を利用して、共有のワークキュー３４０１を通じてワークをサブミットすることを可能にする。
【０７０７】
以下の検討は、共有のワークキュー（ＳＷＱ）を実装するエンドポイントデバイスに適用可能である。
【０７０８】
ＳＷＱ及びその列挙：デバイス物理ファンクション（ＰＦ）は、１又は複数のＳＷＱをサポートしてよい。各ＳＷＱは、デバイスＭＭＩＯアドレス範囲内の６４バイトアライン、及び、サイズレジスタ（ここでは、ＳＷＱ＿ＲＥＧと称される）を通じてエンキュー・ノン・ポステッドライトがアクセス可能である。デバイス上のそのような各ＳＷＱ＿ＲＥＧは、一意的なシステムページサイズ（４ＫＢ）領域に配置されることが推奨される。デバイス用のデバイスドライバは、ＳＷＱ機能、サポートされるＳＷＱの数、及び、対応するＳＷＱ＿ＲＥＧアドレスを、適切なソフトウェアインタフェースを通じてソフトウェアに報告／列挙する役割を担う。ドライバは、（これは、機能の正確性にとって必須ではないが）ソフトウェアのチューニング又は情報の用途のためにサポートされるＳＷＱのデプスを選択的に報告してもよい。複数の物理ファンクションをサポートするデバイスについては、物理ファンクションごとに独立してＳＷＱをサポートすることが推奨される。
【０７０９】
単一のルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）デバイス上でのＳＷＱサポート：ＳＲ−ＩＯＶをサポートするデバイスは、それぞれのＶＦベースアドレスレジスタ（ＢＡＲ）におけるＳＷＱ＿ＲＥＧを通じてさらされる仮想機能（ＶＦ）ごとに独立してＳＷＱをサポートしてよい。この設計のポイントは、ＶＦにわたるワークサブミッションに関する最大の性能分離を考慮している点にあり、少数から中程度の数のＶＦに適切し得る。多数のＶＦをサポートするデバイス（ＶＦ毎の独立したＳＷＱは実用的ではない）について、単一のＳＷＱは、複数のＶＦにわたって共有されてよい。たとえこの場合であっても、各ＶＦは、ＳＷＱを共有するＶＦにわたって共通のＳＷＱにより補助されることを除いて、そのＶＦ  ＢＡＲに自体のプライベートなＳＷＱ＿ＲＥＧを有する。そのようなデバイス設計について、ＳＷＱを共有するＶＦは、ハードウェア設計により静的に決定されてよく、又は、ＳＷＱインスタンスに対する所与のＶＦのＳＷＱ＿ＲＥＧ間のマッピングは、物理ファンクション及びそのドライバを通じて動的にセットアップ／トーンダウンされてよい。ＶＦにわたってＳＷＱを共有するデバイス設計は、このセクションにおいて後で説明されるように、サービス妨害攻撃に対するＱｏＳ及び保護に特別な注意を払う必要がある。ＶＦにわたってＳＷＱを共有する場合、どのＶＦがＳＷＱに受け入れられたエンキュー要求を受信したかを識別するように、デバイス設計において注意払われなければなければならない。ＳＷＱからワーク要求をディスパッチする場合、デバイスは、アップストリーム要求が、（エンキュー要求ペイロード内で伝達されたＰＡＳＩＤに加えて）それぞれのＶＦのリクエスタＩＤ（バス／デバイス／機能＃）と適切にタグ付けされているかを確認すべきである。
【０７１０】
エンキュー・ノン・ポステッドライトアドレス：ＳＷＱをサポートするエンドポイントデバイスは、これらのＰＦ又はＶＦメモリＢＡＲを通じて転送される任意のアドレスへのエンキュー・ノン・ポステッドライトを受け入れることが必要とされる。ＳＷＱ＿ＲＥＧアドレスではないアドレスへの、エンドポイントデバイスにより受信された任意のエンキュー・ノン・ポステッドライト要求について、デバイスは、エラー（例えば、不正な形式のＴＬＰなど）としてこれを処理しない代わりに、リトライの完了ステータス（ＭＲＳ）と共に完了を返すことが必要とされ得る。これは、ＳＷＱ可能なデバイス上の非ＳＷＱ＿ＲＥＧアドレスにエンキュー格納を誤って又は悪意をもって発行するＥＮＱＣＭＤ／Ｓ命令の非特権（リング３又はリング０ＶＭＸゲスト）ソフトウェアの使用は、プラットフォーム固有のエラー処理結果と共に致命的でないエラー又は致命的なエラーを報告するという結果をもたらすことができないことを確保するために行われてよい。
【０７１１】
ＳＷＱ＿ＲＥＧに対する非エンキュー要求処理：ＳＷＱをサポートするエンドポイントデバイスは、致命的又は致命的でないエラーとしてこれらを処理することなく、ＳＷＱ＿ＲＥＧアドレスに対する非エンキュー要求（通常のメモリ書き込み及び読み出し）を無許可でドロップしてよい。ＳＷＱ＿ＲＥＧアドレスに対する読み出し要求は、要求されたデータバイトに対してオール１の値を有する正常完了応答（ＵＲ又はＣＡとは対照的に）を返してよい。ＳＷＱ＿ＲＥＧアドレスへの通常のメモリ（ポステッド）書き込み要求は、エンドポイントデバイスによる動作なしで単にドロップされる。これは、特権のないソフトウェアが、プラットフォーム固有のエラー処理結果と共に致命的でないエラー又は致命的なエラーを誤って又は悪意をもって報告させるようにＳＷＱ＿ＲＥＧアドレスへの通常の読み出し及び書き込み要求を生成できないことを確保するために行われ得る。
【０７１２】
ＳＷＱキューデプス及びストレージ：ＳＷＱキューデプス及びストレージは、デバイス実装に固有のものである。デバイス設計は、デバイスの最大限の利用を実現するために、十分なキューデプスがＳＷＱにサポートされることを確保すべきである。ＳＷＱに対するストレージは、デバイス上に実装されてよい。ＳｏＣ上の統合デバイスは、ＳＷＱのバッファ溢れとして、スティールされたメインメモリ（デバイスの使用のために予約された非ＯＳ可視プライベートメモリ）を利用してよく、オンデバイスストレージを用いて実現するよりも、より大きなＳＷＱキューデプスを可能にする。そのような設計について、バッファ溢れの使用は、デバイスハードウェアが、（エンキュー要求をドロップして、リトライ完了ステータスを送信することと対比して）いつあふれさせ、コマンド実行に対するバッファ溢れからフェッチし、任意のコマンドに固有のオーダリング要求を維持するかを決定するので、ソフトウェアに対して透過的である。すべての用途に対して、そのようなバッファ溢れの利用は、ＳＷＱストレージに対してローカルデバイスが取り付けられたＤＲＡＭを用いる別個のデバイスと同等である。スティールされたメモリ（ｓｔｏｌｅｎ  ｍｅｍｏｒｙ）内のバッファ溢れを伴うデバイス設計は、そのようなスティールされたメモリ（ｓｔｏｌｅｎ  ｍｅｍｏｒｙ）が、割り当てられたデバイスによりバッファ溢れの読み出し及び書き込み以外の任意のアクセスから保護されることを確認するために非常に注意しなければならない。
【０７１３】
非ブロックＳＷＱの挙動：性能上の理由で、デバイス実装は、成功又はリトライ完了ステータスを有するエンキュー・ノン・ポステッドライト要求に迅速に応答すべきであり、要求を受け入れるために解放されるＳＷＱ容量のエンキュー完了をブロックすべきでない。ＳＷＱに対するエンキュー要求を受け入れ又は拒絶する決定は、容量、ＱｏＳ／占有率又はその他のポリシに基づき得る。いくつかの例示的なＱｏＳの検討が次に説明される。
【０７１４】
ＳＷＱ  ＱｏＳの検討：ＳＷＱ＿ＲＥＧアドレスをターゲットととするエンキュー・ノン・ポステッドライトについて、エンドポイントデバイスは、承認制御を適用して、それぞれのＳＷＱに対する要求を受け入れ（及び、成功完了ステータスを送信する）、又は、それをドロップする（及び、リトライ完了ステータスを送信する）ことを決定してよい。承認制御は、デバイス及び利用に固有のものであってよく、ハードウェアによりサポート／強制される特定のポリシは、物理ファンクション（ＰＦ）ドライバインタフェースを通じてソフトウェアにさらされてよい。ＳＷＱが、複数の生産者クライアントを有する共有リソースであるので、デバイス実装は、生産者にわたるサービス妨害攻撃に対して適切な保護を確保しなければならない。ＳＷＱに対するＱｏＳは、単にＳＷＱに対する（エンキュー要求を通じた）ワーク要求の受け入れのみを指し、異なる生産者によりサブミットされたワーク要求を処理する場合、デバイスの実行リソースを共有するために、ＱｏＳがどのように適用されるかについて、デバイスハードウェアにより適用される任意のＱｏＳに直交する。ＳＷＱに対するエンキュー要求を受け入れるための承認ポリシを強制するようにエンドポイントデバイスを構成することについて、いくつかの例示的なアプローチが以下に説明される。これらは、単に例示の目的で記録され、正確な実施例の選択はデバイスに固有である。
【０７１５】
一実施例において、ＭＯＶＤＩＲＩ命令は、直接格納処理を用いて、ソースオペランド（第２のオペランド）内のダブルワード整数を宛先オペランド（第１のオペランド）移動させる。ソースオペランドは、汎用レジスタであってよい。宛先オペランドは、３２ビットのメモリ位置であってよい。６４ビットモードにおいて、命令のデフォルトの処理サイズは３２ビットである。ＭＯＶＤＩＲＩは、ダブルワード又はクワッドワードアラインとなるように宛先を定義する。
【０７１６】
直接格納は、データを書き込むためのライトコンバイニング（ＷＣ）メモリタイププロトコルを用いることにより実装され得る。このプロトコルを用いることで、プロセッサは、キャッシュ階層にデータを書き込むことも、キャッシュ階層にメモリから対応するキャッシュラインをフェッチすることもしない。宛先アドレスがキャッシュされる場合、直接格納前に、ラインは、キャッシュからライトバック（修正される場合）及び無効にされる。宛先に対する未キャッシュ（ＵＣ）及び書き込み保護（ＷＰ）メモリタイプが非一時的な暗示をオーバーライドすることを可能にする非一時的な暗示を用いた格納とは異なり、直接格納は、（ＵＣ及びＷＰタイプを含む）宛先アドレスメモリタイプに拘わらず、ＷＣメモリタイププロトコルに常に従う。
【０７１７】
ＷＣ格納及び非一時的な暗示を用いた格納とはことなり、直接格納は、ライトコンバイニングバッファからの即時エビクションの対象となり、ひいては、同じアドレスへの若い方の格納（直接格納を含む）と組み合わせられない。ライトコンバインバッファにおいて保持されるより古いＷＣ及び非一時的な格納は、同じアドレスへの若い方の直接格納と組み合わせられてよい。
【０７１８】
直接格納により用いられるＷＣプロトコルは、弱くオーダリングされたメモリ整合性モデルに従うので、フェンシング処理は、必要なときに、オーダリングを強制するためにＭＯＶＤＩＲＩ命令に従うはずである。
【０７１９】
宛先へＭＯＶＤＩＲＩにより発行された直接格納は、４バイト境界にアラインされ、４バイト書き込み完了のアトミック性を保証する。これは、データが、単一の非トーン４バイト（又は、８バイト）書き込みトランザクションにおける宛先に到達することを意味する。宛先が書き込みサイズに整合しない場合、ＭＯＶＤＩＲＩにより発行された直接格納は、２つの部分の宛先に分割されて到達する。そのような分割直接格納の各部は、若い方の格納とマージすることはないが、任意の順序で宛先に到達できる。
【０７２０】
図５９は、ＭＯＶＤＩＲＩ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７２１】
５９０１において、命令がフェッチされる。例えば、ＭＯＶＤＩＲＩがフェッチされる。ＭＯＶＤＩＲＩ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）、宛先オペランドを表す宛先フィールド、及び、ソースレジスタオペランドを表すソースフィールドを含む。
【０７２２】
５９０３において、フェッチされた命令がデコードされる。例えば、ＭＯＶＤＩＲＩ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７２３】
５９０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７２４】
５９０７において、デコードされた命令は、データをキャッシングすることなく、ソースレジスタオペランドから宛先レジスタオペランドにダブルワードサイズのデータを移動する、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。
【０７２５】
いくつかの実施形態では、５９０９において、命令がコミット又はリタイアされる。
【０７２６】
６４バイト書き込みアトミック性を有する直接格納として、ソースメモリアドレスから宛先メモリアドレスに６４バイトを移動する。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリ位置である。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくＥＳセグメントへのオフセットとして解釈される。６４ビットモードにおいて、レジスタオペランド幅は、６４ビット（又は、３２ビット）である。６４ビットモードの外部では、レジスタ幅は、３２ビット又は１６ビットである。ＭＯＶＤＩＲ６４Ｂは、宛先アドレスが６４バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
【０７２７】
ＭＯＶＤＩＲ６４Ｂは、ソースメモリアドレスから６４バイトを読み出して、宛先アドレスに対する６４バイトの直接格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。直接格納は、データを書き込むためのライトコンバイニング（ＷＣ）メモリタイププロトコルを用いることにより実装される。このプロトコルを用いることで、プロセッサは、キャッシュ階層にデータを書き込まなくてよく、キャッシュ階層にメモリから対応するキャッシュラインをフェッチしなくてよい。宛先アドレスがキャッシュされる場合、直接格納前に、ラインは、キャッシュからライトバック（修正される場合）及び無効にされる。
【０７２８】
宛先に対するＵＣ／ＷＰメモリタイプが、非一時的な暗示をオーバーライドすることを可能にする非一時的な暗示を用いた格納とは異なり、直接格納は、（ＵＣ／ＷＰタイプを含む）宛先アドレスメモリタイプに拘わらず、ＷＣメモリタイププロトコルに従ってよい。
【０７２９】
ＷＣ格納及び非一時的な暗示を用いた格納とは異なり、直接格納は、ライトコンバイニングバッファからの即時エビクションの対象となり、ひいては、同じアドレスへお若い方の格納（直接格納を含む）と組み合わせられない。ライトコンバインバッファにおいて保持されるより古いＷＣ及び非一時的な格納は、同じアドレスへの若い方の直接格納と組み合わせられてよい。
【０７３０】
直接格納により用いられるＷＣプロトコルは、弱くオーダリングされたメモリ整合性モデルに従うので、フェンシング処理は、必要なときに、オーダリングを強制するためにＭＯＶＤＩＲ６４Ｂ命令に従うはずである。
【０７３１】
ソースアドレスから６４バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて、６４バイトを読み出すしてよい。ＭＯＶＤＩＲ６４Ｂにより発行される６４バイト直接格納は、６４バイト書き込み完了のアトミック性を保証する。これは、データが、単一の非トーン６４バイト書き込みトランザクションにおける宛先に到達することを意味する。
【０７３２】
図６０は、ＭＯＶＤＩＲＩ６４Ｂ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７３３】
６００１において、命令がフェッチされる。例えば、ＭＯＶＤＩＲＩ６４Ｂがフェッチされる。ＭＯＶＤＩＲＩ６４Ｂ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）、宛先オペランドを表す宛先フィールド、及び、ソースレジスタオペランドを表すソースフィールドを含む。
【０７３４】
６００３において、フェッチされた命令がデコードされる。例えば、ＭＯＶＤＩＲＩ６４Ｂ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７３５】
６００５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７３６】
６００７において、デコードされた命令は、データをキャッシングすることなく、ソースレジスタオペランドから宛先レジスタオペランドに６４バイトデータを移動する、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。
【０７３７】
いくつかの実施形態では、６００９において、命令がコミット又はリタイアされる。
【０７３８】
一実施例において、ＥＮＱＣＭＤコマンドは、ソースメモリアドレス（第２のオペランド）から宛先オペランド内のデバイス共有型ワークキュー（ＳＷＱ）メモリアドレスに６４バイト書き込みアトミック性を有するノンポステッド書き込みを用いて、６４バイトのコマンドをエンキューする。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリアドレスである。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくＥＳセグメントへのオフセットとして解釈される。６４ビットモードにおいて、レジスタオペランド幅は、６４ビット又は３２ビットである。６４ビットモードの外部では、レジスタ幅は、３２ビット又は１６ビットである。ＥＮＱＣＭＤは、宛先アドレスが６４バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
【０７３９】
一実施例において、ＥＮＱＣＭＤは、ソースメモリアドレスから６４バイトのコマンドを読み出し、６４バイトのエンキュー格納データをフォーマット化し、宛先アドレスに対する格納データの６４バイトのエンキュー格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。一般的な保護エラーは、ソースメモリアドレスから読み出される６４バイトのコマンドデータの下位４バイトが、ゼロ以外の値を有する場合、又は、ＰＡＳＩＤ有効フィールドビットが０である場合に引き起こされ得る。そうでなければ、６４バイトのエンキュー格納データは、以下のようにフォーマット化される。
エンキュー格納データ［５１１：３２］＝コマンドデータ［５１１：３２］
エンキュー格納データ[３１]＝０
エンキュー格納データ［３０：２０］＝０
エンキュー格納データ［１９：０］＝ＰＡＳＩＤ  ＭＳＲ［１９：０］
【０７４０】
一実施例において、ＥＮＱＣＭＤにより生成された６４バイトのエンキュー格納データは、図５８に示されるフォーマットを有する。コマンド記述子内の上位６０バイトは、ターゲットデバイスに固有のコマンド５８０１を規定する。ＰＲＩＶフィールド５８０２（ビット３１）は、ＥＮＱＣＭＤ命令により生成されたエンキュー格納に対するユーザ特権を伝達するために０に強制されてよい。ＰＡＳＩＤフィールド（ビット１９：０）５８０４は、ＥＮＱＣＭＤ１を実行するソフトウェアスレッド用のシステムソフトウェアにより割り当てられる（ＰＡＳＩＤ  ＭＳＲにおいてプログラミングされるような）処理アドレス空間識別を伝達する。
【０７４１】
エンキュー格納処理は、６４バイトのデータを書き込むためにノンポステッド書き込みプロトコルを用いる。ノンポステッド書き込みプロトコルは、キャッシュ階層にデータを書き込まなくてよく、キャッシュ階層に対応するキャッシュラインをフェッチしなくてよい。エンキュー格納は、（ＵＣ／ＷＰタイプを含む）宛先アドレスメモリタイプに拘わらず、ノンポステッド書き込みプロトコルに常に従う。
【０７４２】
ノンポステッド書き込みプロトコルは、ノンポステッド書き込みに対する成功又はリトライステータスを示すために、完了応答を返してよい。ＥＮＱＣＭＤ命令は、ゼロフラグでこの完了ステータスを返してよい（０は成功を示し、１はリトライを示す）。成功ステータスは、ノンポステッド書き込みデータ（６４バイト）が、目標の共有のワークキューにより受け入れられることを示す（が、必ずしも作用を受けるわけではない）。リトライステータスは、ノンポステッド書き込みが容量又は他の一時的な理由に起因して（又は、宛先アドレスが有効な共有のワークキューアドレスではないことに起因して）、宛先アドレスによって受け入れられなかったことを示す。
【０７４３】
一実施例において、多くても１つのエンキュー格納は、所与の論理プロセッサから未処理となる可能性がある。その意味では、エンキュー格納は、別のエンキュー格納を渡すことができない。エンキュー格納は、より古いＷＢ格納、ＷＣ及び非一時的な格納、ＣＬＦＬＵＳＨＯＰＴ又はＣＬＷＢに対して、異なるアドレスへのオーダリングは行わない。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納の後、かつ、エンキュー格納前に明示的な格納フェンシングを用いなければならない。ＥＮＱＣＭＤは、他の格納により影響されない共有のワークキュー（ＳＷＱ）アドレスだけに影響を与える。
【０７４４】
ソースアドレスから６４バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて６４バイトを読み出してよい。ＥＮＱＣＭＤにより発行された６４バイトのエンキュー格納は、６４バイト書き込み完了のアトミック性を保証する。データは、単一の非トーン（ｎｏｎ−ｔｏｒｎ）６４バイトの非ポステッド書き込みトランザクションとして宛先に到達し得る。
【０７４５】
いくつかの実施形態において、ＰＡＳＩＤアーキテクチャのＭＳＲがＥＮＱＣＭＤ命令により用いられる。
【表３６】
0006988040.tif 000041
【０７４６】
図６１は、ＥＮＣＱＭＤ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７４７】
６１０１において、命令がフェッチされる。例えば、ＥＮＣＱＭＤがフェッチされる。ＥＮＣＱＭＤ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）、宛先メモリアドレスオペランドを表す宛先フィールド、及び、ソースメモリオペランドを表すソースフィールドを含む。
【０７４８】
６１０３において、フェッチされた命令がデコードされる。例えば、ＥＮＣＱＭＤ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７４９】
６１０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７５０】
６１０７において、デコードされた命令は、コマンド（取得したデータ）を宛先メモリアドレスに書き込む、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。いくつかの実施形態において、宛先メモリアドレスは共有のワークキューである。
【０７５１】
いくつかの実施形態では、６１０９において、命令がコミット又はリタイアされる。
【０７５２】
一実施例において、ＥＮＱＣＭＤＳ命令は、ソースメモリアドレス（第２のオペランド）から宛先オペランド内のデバイス共有型ワークキュー（ＳＷＱ）メモリアドレスに６４バイト書き込みアトミック性を有するノンポステッド書き込みを用いて、６４バイトのコマンドをエンキューする。ソースオペランドは、通常のメモリオペランドである。宛先オペランドは、汎用レジスタにおいて特定されるメモリアドレスである。レジスタコンテンツは、いずれのセグメントオーバーライドを用いることなくＥＳセグメントへのオフセットとして解釈されてよい。６４ビットモードにおいて、レジスタオペランド幅は、６４ビット又は３２ビットである。６４ビットモードの外部では、レジスタ幅は３２ビット又は１６ビットである。ＥＮＱＣＭＤは、宛先アドレスが６４バイトでアラインされている必要がある。ソースオペランドに対して強制されるアライメント制限はない。
【０７５３】
（任意の特権レベルから実行され得る）ＥＮＱＣＭＤとは異なり、ＥＮＱＣＭＤＳは、特権命令である。プロセッサが、保護モードで実行している場合、ＣＰＬは、この命令を実行する０でなければならない。ＥＮＱＣＭＤＳは、ソースメモリアドレスから６４バイトのコマンドを読み出して、宛先アドレスに対して、このデータを用いて６４バイトのエンキュー格納処理を実行する。ロードオペレーションは、ソースアドレスのメモリタイプに基づく通常の読み出しオーダリングに従う。６４バイトのエンキュー格納データは、以下のようにフォーマット化される。
エンキュー格納データ［５１１：３２］＝コマンドデータ［５１１：３２］
エンキュー格納データ[３１]＝コマンドデータ[３１]
エンキュー格納データ［３０：２０］＝０
エンキュー格納データ［１９：０］＝コマンドデータ［１９：０］
【０７５４】
ＥＮＱＣＭＤＳにより生成された６４バイトのエンキュー格納データは、ＥＮＱＣＭＤと同じフォーマットを有してよい。一実施例において、ＥＮＱＣＭＤＳは、図６２に示されるフォーマットを有する。
【０７５５】
コマンド記述子内の上位６０バイトは、ターゲットデバイスに固有のコマンド６２０１を規定する。ＰＲＩＶフィールド（ビット３１）６２０２は、ＥＮＱＣＭＤＳ命令により生成されるエンキュー格納のためのユーザ（０）又はスーパバイザ（１）特権のいずれか一方を伝達するために、ソースオペランドアドレスにおけるコマンドデータ内のビット３１により規定される。ＰＡＳＩＤフィールド（ビット１９：０）６２０４は、ソースオペランドアドレス１におけるコマンドデータ内のビット１９：０に規定されるような処理アドレス空間識別を伝達する。
【０７５６】
一実施例において、エンキュー格納処理は、６４バイトのデータを書き込むために、ノンポステッド書き込みプロトコルを用いる。ノンポステッド書き込みプロトコルは、キャッシュ階層にデータを書き込むことも、キャッシュ階層に対応するキャッシュラインをフェッチすることもしない。エンキュー格納は、（ＵＣ／ＷＰタイプを含む）宛先アドレスメモリタイプに拘わらず、ノンポステッド書き込みプロトコルに常に従う。
【０７５７】
ノンポステッド書き込みプロトコルは、ノンポステッド書き込みに対する成功又はリトライステータスを示すために、完了応答を返す。ＥＮＱＣＭＤ命令は、ゼロフラグでこの完了ステータスを返す（０は成功を示し、１はリトライを示す）。成功ステータスは、ノンポステッド書き込みデータ（６４バイト）が、目標の共有のワークキューにより受け入れられることを示す（が、必ずしも作用を受けるわけではない）。リトライステータスは、ノンポステッド書き込みが、容量又は他の一時的な理由に起因して（又は、宛先アドレスが有効な共有のワークキューアドレスではないことに起因して）宛先アドレスにより受け入れられなかったことを示す。
【０７５８】
多くても１つのエンキュー格納（ＥＮＱＣＭＤ又はＥＮＱＣＭＤＳ）は、所与の論理プロセッサから未処理となる可能性がある。その意味では、エンキュー格納は、別のエンキュー格納を渡すことができない。エンキュー格納は、より古いＷＢ格納、ＷＣ及び非一時的な格納、ＣＬＦＬＵＳＨＯＰＴ又はＣＬＷＢに対して、異なるアドレスへのオーダリングは行われなくてよい。そのようなオーダリングを強制する必要があるソフトウェアは、そのような格納後、かつ、エンキュー格納前に明示的な格納フェンシングを用いてよい。
【０７５９】
ＥＮＱＣＭＤＳは、他の格納により影響されない共有のワークキュー（ＳＷＱ）アドレスだけに影響を与える。
【０７６０】
ソースアドレスから６４バイトのロードオペレーションにもたらされるアトミック性の保証はなく、プロセッサ実装は、複数のロードオペレーションを用いて６４バイトを読み出してよい。ＥＮＱＣＭＤＳにより発行された６４バイトのエンキュー格納は、６４バイト書き込み完了のアトミック性を保証する（すなわち、単一の非トーン（ｎｏｎ−ｔｏｒｎ）６４バイトの非ポステッド書き込みトランザクションとしての宛先に到達する）。
【０７６１】
図６３は、ＥＮＣＱＭＤ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７６２】
６３０１において、命令がフェッチされる。例えば、ＥＮＣＱＭＤがフェッチされる。ＥＮＣＱＭＤ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）、宛先メモリアドレスオペランドを表す宛先フィールド、及び、ソースメモリオペランドを表すソースフィールドを含む。
【０７６３】
６３０３において、フェッチされた命令がデコードされる。例えば、ＥＮＣＱＭＤ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７６４】
６３０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７６５】
６３０７において、デコードされた命令は、コマンド（取得したデータ）を宛先メモリアドレスに書き込む、本明細書で詳細に説明されるような実行回路（ハードウェア）により、特権モードで実行される。いくつかの実施形態において、宛先メモリアドレスは、共有のワークキューである。
【０７６６】
いくつかの実施形態では、６３０９において、命令がコミット又はリタイアされる。
【０７６７】
一実施例では、アクセラレータとホストプロセッサ、すなわち、ＵＭＯＮＩＴＯＲとＵＭＷＡＩＴとの間の効率的な同期を確実にするために２つの命令を利用する。簡潔に、ＵＭＯＮＩＴＯＲ命令は、ソースレジスタにおいて特定されたアドレスを用いて、アドレスモニタリングハードウェアを作動可能にし、ＵＭＷＡＩＴ命令は、アドレスの範囲をモニタリングしている間、実装に依存して最適化された状態に入れるようプロセッサに命令する。
【０７６８】
ＵＭＯＮＩＴＯＲ命令は、ｒ３２/ｒ６４ソースレジスタにおいて特定されるアドレスを用いてアドレスモニタリングハードウェアを作動可能にする（格納オペレーションに対するモニタリングハードウェアがチェックするアドレス範囲が、ＣＰＵＩＤモニタリーフ機能を用いることにより判断され得る）。特定のアドレス範囲内のアドレスへの格納は、モニタリングハードウェアをトリガする。モニタハードウェアの状態は、ＵＭＷＡＩＴにより用いられる。
【０７６９】
以下のオペランドのエンコーディングは、ＵＭＯＮＩＴＯＲ命令の一実施例に用いられる。
【表３７】
0006988040.tif 000042
【０７７０】
ｒ３２/ｒ６４ソースレジスタのコンテンツはが有効なアドレスである（６４ビットモードにおいて、ｒ６４が用いられる）。デフォルト設定により、ＤＳセグメントは、モニタリングされる線形アドレスを作成するために用いられる。セグメントオーバーライドが用いられ得る。アドレス範囲は、ライトバックタイプのメモリを用いなければならない。ライトバックメモリだけが、モニタリングハードウェアを正確にトリガすることを保証する。
【０７７１】
ＵＭＯＮＩＴＯＲ命令は、他のメモリトランザクションに関するロードオペレーションとしてオーダリングされる。命令は、バイトロードと関連付けられる許可チェック及びフォールトを対象とする。ロードと同様に、ＵＭＯＮＩＴＯＲは、ページテーブル内のＤビットではなく、Ａビットを設定する。
【０７７２】
ＵＭＯＮＩＴＯＲ及びＵＭＷＡＩＴは、任意の特権レベルで実行されてよい。命令のオペレーションは、非６４ビットモード及び６４ビットモードにおいて同じである。
【０７７３】
ＵＭＯＮＩＴＯＲは、レガシＭＷＡＩＴ命令と同時に使用しない。ＭＷＡＩＴを実行し、続けて、レガシＭＯＮＩＴＯＲ命令の最新の実行の前に、ＵＭＯＮＩＴＯＲが実行された場合、ＭＷＡＩＴは、最適化された状態に入らなくてよい。実行は、ＭＷＡＩＴの後に続く命令において再開する。
【０７７４】
ＵＭＯＮＩＴＯＲ命令は、トランザクション領域内で用いられる場合、トランザクションをアボートさせる。
【０７７５】
ＵＭＯＮＩＴＯＲは、有効なアドレスとしてソースレジスタのコンテンツを用いてモニタハードウェアのアドレス範囲をセットアップし、モニタハードウェアを作動可能状態（ａｒｍｅｄ  ｓｔａｔｅ）に置く。特定のアドレス範囲に対する格納は、モニタハードウェアをトリガする。
【０７７６】
図６４は、ＵＭＯＮＩＴＯＲ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７７７】
６４０１において、命令がフェッチされる。例えば、ＵＭＯＮＩＴＯＲがフェッチされる。ＵＭＯＮＩＴＯＲ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）、及び、明示的なソースレジスタオペランドを含む。
【０７７８】
６４０３において、フェッチされた命令がデコードされる。例えば、ＵＭＯＮＩＴＯＲ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７７９】
６４０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７８０】
６４０７において、デコードされた命令は、取得したソースレジスタデータにより規定されるアドレスへの格納のためにモニタリングハードウェアを作動可能にする、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。
【０７８１】
いくつかの実施形態では、６４０９において、命令がコミット又はリタイアされる。
【０７８２】
ＵＭＷＡＩＴは、アドレスの範囲をモニタリングしている間に、実装に依存して最適化された状態に入るようプロセッサに命令する。最適化された状態は、軽量電力／性能が最適化された状態又は改善された電力／性能が最適化された状態のいずれか一方であってよい。その２つの状態の選択は、明示的な入力レジスタビット［０］ソースオペランドにより統制される。
【表３８】
0006988040.tif 000043
【０７８３】
ＵＭＷＡＩＴは、任意の特権レベルで実行されてよい。この命令のオペレーションは、非６４ビットモード及び６４ビットモードにおいて同じである。
【０７８４】
入力レジスタは、以下のテーブルにおいて説明さるように、プロセッサが入るべきである好ましく最適化された状態などの情報を含んでよい。ビット０以外のビットは、予約済みであり、ゼロ以外である場合、＃ＧＰを結果としてもたらす。
【表３９】
0006988040.tif 000044
【０７８５】
命令は、タイムスタンプカウンタが暗黙的な６４ビット入力値に達した又はこれを超えた場合（モニタリングハードウェアが予めトリガされていなかった場合）にウェイクアップする。
【０７８６】
ＵＭＷＡＩＴ命令を実行する前に、オペレーティングシステムは、２つの電力／性能が最適化された状態のいずれか一方を含み得るそのオペレーションをプロセッサが一時停止することを可能にする最大遅延を規定してよい。それは、以下の３２ビットＭＳＲにＴＳＣ量子値を書き込むことによりそうすることができる。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［３１：２］−Ｃ０．１又はＣ０．２のいずれか一方にプロセッサが存在し得るＴＳＣ量子における最大時間を判断する。ゼロの値は、ＯＳがプロセッサに対して課した制限がないことを示す。最大時間値は、上位３０ｂがこのフィールドから来ており、下位２ビットがゼロであると仮定される３２ｂの値である。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［１］−予約済。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［０］−Ｃ０．２はＯＳにより許可されていない。１の値は、すべてのＣ０．２要求がＣ０．１に戻ることを意味する。
【０７８７】
一実施例において、ＵＭＷＡＩＴ命令を実行したプロセッサがオペレーティングシステム時間制限の期限切れに起因して起きた場合、命令は、キャリーフラグを設定し、そうでなければ、そのフラグがクリアされる。
【０７８８】
ＵＭＷＡＩＴ命令は、トランザクション領域内で用いられる場合、トランザクションをアボートさせる。一実施例において、ＵＭＷＡＩＴ命令は、ＵＭＯＮＩＴＯＲ命令と共に動作する。２つの命令は、待機するアドレス（ＵＭＯＮＩＴＯＲ）の定義を可能にし、実装に依存して最適化されたオペレーションが待機アドレス（ＵＭＷＡＩＴ）で開始することを可能にする。ＵＭＷＡＩＴの実行は、ＵＭＯＮＩＴＯＲにより作動可能なアドレス範囲に対するイベント又は格納処理を待機している間に、実装に依存して最適化された状態に入ることができるプロセッサに対する暗示である。
【０７８９】
次のような場合には、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。ＵＭＯＮＩＴＯＲ命令により作動可能なアドレス範囲への格納、非マスク可能な割込み（ＮＭＩ）又はシステム管理割込み（ＳＭＩ）、デバッグ例外、マシンチェック例外、ＢＩＮＩＴ＃信号、ＩＮＩＴ＃信号及びＲＥＳＥＴ♯信号。他の実装に依存するイベントは、プロセッサに、実装に依存して最適化された状態を抜けさせてもよい。
【０７９０】
さらに、外部の割込みは、マスク可能割込みが阻害されるか否かに関わらず、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。
【０７９１】
実装に依存して最適化された状態からの抜け出しに続いて、制御が、ＵＭＷＡＩＴ命令に続く命令に渡される。マスクされていない未処理の割込み（ＮＭＩ又はＳＭＩを含む）は、命令の実行前に配信されてよい。
【０７９２】
ＨＬＴ命令とは異なり、ＵＭＷＡＩＴ命令は、ＳＭＩの処理に続くＵＭＷＡＩＴ命令での再開をサポートしていない。先行するＵＭＯＮＩＴＯＲ命令が、アドレス範囲を正常に作動可能していなかった場合、又は、ＵＭＷＡＩＴを実行し、続けてレガシＭＯＮＩＴＯＲ命令の最新の実行の前に、ＵＭＯＮＩＴＯＲが実行されなかった（ＵＭＷＡＩＴがＭＯＮＩＴＯＲと同時に使用されていない）場合、プロセッサは、最適化された状態に入らない。実行は、ＵＭＷＡＩＴの後に続く命令において再開する。
【０７９３】
ＵＭＷＡＩＴが、Ｃ１より数値的に低いＣ０−サブ状態に入るために用いられ、従って、ＵＭＯＮＩＴＯＲ命令により作動可能なアドレス範囲に対する格納は、他のプロセッサエージェントにより格納が発せられた場合、又は、非プロセッサエージェントにより格納が発せられた場合のいずれか一方の場合、プロセッサにＵＭＷＡＩＴを終了させることに留意する。
【０７９４】
図６５は、ＵＭＷＡＩＴ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０７９５】
６５０１において、命令がフェッチされる。例えば、ＵＭＷＡＩＴがフェッチされる。ＵＭＷＡＩＴ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）及び明示的なソースレジスタオペランドを含む。
【０７９６】
６５０３において、フェッチされた命令がデコードされる。例えば、ＵＭＷＡＩＴ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０７９７】
６５０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０７９８】
６５０７において、デコードされた命令は、アドレスの範囲をモニタリングしている間に、プロセッサ（又は、コア）を、明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に入れる、本明細書で詳細に説明されるような、実行回路（ハードウェア）により実行される。
【０７９９】
いくつかの実施形態では、６５０９において、命令がコミット又はリタイアされる。
【０８００】
ＴＰＡＵＳＥは、実装に依存して最適化された状態に入るようプロセッサに命令する。軽量電力／性能が最適化された状態、及び、改善された電力／性能が最適化された状態の中から選択するそのような２つの最適化された状態がある。当該２つの中からの選択は、明示的な入力レジスタビット［０］ソースオペランドにより統制される。
【表４０】
0006988040.tif 000045
【０８０１】
ＴＰＡＵＳＥは、任意の特権レベルで実行されてよい。この命令のオペレーションは、非６４ビットモード及び６４ビットモードにおいて同じである。
【０８０２】
ＰＡＵＳＥとは異なり、ＴＰＡＵＳＥ命令は、トランザクション領域の内部で用いられるときにアボートを生じさせない。入力レジスタは、以下のテーブルで説明されるように、プロセッサが入る好ましく最適化された状態のような情報を含む。ビット０以外のビットは、予約済みであり、ゼロ以外である場合、＃ＧＰをもたらす。
【表４１】
0006988040.tif 000046
【０８０３】
命令は、タイムスタンプカウンタが暗黙的な６４ビット入力値に達した又はこれを超えた場合（モニタリングハードウェアが予めトリガされていなかった場合）にウェイクアップする。ＴＰＡＵＳＥ命令を実行する前に、オペレーティングシステムは、２つの電力／性能が最適化された状態のいずれか一方におけるそのオペレーションをプロセッサが一時停止することを可能にする最大遅延を規定してよい。それは、以下の３２ビットＭＳＲにＴＳＣ量子値を書き込むことによりそうすることができる。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［３１：２］−Ｃ０．１又はＣ０．２のいずれか一方にプロセッサが存在し得るＴＳＣ量子における最大時間を判断する。ゼロの値は、ＯＳがプロセッサに対して課した制限がないことを示す。最大時間値は、上位３０ｂがこのフィールドから来ており、下位２ビットがゼロであると仮定される３２ｂの値である。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［１］−予約済。
ＵＭＷＡＩＴ＿ＣＯＮＴＲＯＬ［０］−Ｃ０．２はＯＳにより許可されていない。'１の値は、すべてのＣ０．２要求がＣ０．１に戻ることを意味する。
【０８０４】
ＯＳの時間制限の期限切れに起因するウェイクアップ理由は、キャリーフラグを設定することにより示されてよい。
【０８０５】
ＴＰＡＵＳＥ命令を実行したプロセッサがオペレーティングシステム時間制限の期限切れに起因して起きた場合、命令は、キャリーフラグを設定し、そうでなければ、そのフラグがクリアされる。
【０８０６】
複数のアドレス範囲をモニタリングすることに関して、ＴＰＡＵＳＥ命令は、モニタするためのアドレスのセット及び後続のＴＰＡＵＳＥ命令から構成されるトランザクション領域内に置かれ得る。トランザクション領域は、待機するアドレスのセットの定義を可能にし、実装に依存して最適化されたオペレーションがＴＰＡＵＳＥ命令の実行時に開始することを可能にする。一実施例において、ＴＰＡＵＳＥの実行は、読み出しセットにより規定される範囲内のアドレスに対するイベント又は格納処理を待機している間に、実装に依存して最適化された状態に入るようプロセッサに指示する。
【０８０７】
トランザクションメモリ領域内でのＴＰＡＵＳＥの用は、Ｃ０．１（軽量電力／性能が最適化された状態）に制限され得る。たとえ、ソフトウェアが、Ｃ０．２（改善された電力／性能が最適化された状態）に対するその優先度を示すべく、ビット［０］＝０を設定したとしても、プロセッサは、Ｃ０．１に入ってよい。
【０８０８】
次のような場合は、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。トランザクション領域内の読み出しセット範囲への格納、ＮＭＩ又はＳＭＩ、デバッグ例外、マシンチェック例外、ＢＩＮＩＴ＃信号、ＩＮＩＴ＃信号及びＲＥＳＥＴ♯信号。すべてのこれらのイベントはまた、トランザクションをアボートする。
【０８０９】
他の実装に依存するイベントは、プロセッサに、実装に依存して最適化された状態を抜けさせてよく、ＴＰＡＵＳＥに続く命令に進んで、アボートされていないトランザクション領域を結果としてもたらし得る。さらに、外部の割込みは、いくつかの実施形態において、マスク可能割込みが阻害されるか否かに関わらず、プロセッサに、実装に依存して最適化された状態を抜けさせてよい。マスク可能割込みが阻害される場合、実行はＴＰＡＵＳＥに続く命令に進み、一方、割込みがイネーブルにされたフラグが設定されている場合、トランザクション領域がアボートされることに留意されたい。
【０８１０】
図６６は、ＴＰＡＵＳＥ命令を処理するために、プロセッサにより実行される方法の実施形態を示す。例えば、ここでは、ハードウェアの詳細が用いられる。
【０８１１】
６６０１において、命令がフェッチされる。例えば、ＴＰＡＵＳＥがフェッチされる。ＴＰＡＵＳＥ命令は、オペコード（及び、いくつかの実施形態において、プレフィックス）及び明示的なソースレジスタオペランドを含む。
【０８１２】
６６０３において、フェッチされた命令がデコードされる。例えば、ＴＰＡＵＳＥ命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【０８１３】
６６０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。さらに、いくつかの実施形態において、命令がスケジューリングされる。
【０８１４】
６６０７において、デコードされた命令は、明示的なソースレジスタオペランドについてのデータにより規定される実装ごとに決まる状態にプロセッサ（又は、コア）を入れる、本明細書で詳細に説明されるような、実行回路（ハードウェア）により実行される。
【０８１５】
いくつかの実施形態では、６６０９において、命令がコミット又はリタイアされる。
【０８１６】
図６７は、ＵＭＷＡＩＴ及びＵＭＯＮＩＴＯＲ命令を用いた実行の例を示す。
【０８１７】
６７０１において、ＵＭＷＡＩＴ命令は、モニタリングするためにアドレスの範囲を設定するように実行される。
【０８１８】
６７０３において、ＵＭＯＮＩＴＯＲ命令は、モニタされているアドレスの範囲に対して、命令の明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に、命令を実行するコアを入れるように実行される。
【０８１９】
６７０５において、実装依存状態は、モニタリングされたアドレスへの格納、ＮＭＩ、ＳＭＩ、デバッグ例外、マシンチェック例外、ｉｎｉｔ信号又はリセット信号のうちの１つに応じて抜ける。
【０８２０】
図６８は、ＴＰＡＵＳＥ及びＵＭＯＮＩＴＯＲ命令を用いた実行の例を示す。
【０８２１】
６８０１において、ＴＰＡＵＳＥ命令は、モニタリングするためにアドレスの範囲を設定するように実行される。
【０８２２】
６８０３において、ＵＭＯＮＩＴＯＲ命令は、モニタリングされているアドレスの範囲に対して、命令の明示的なソースレジスタオペランドについてのデータにより規定される実装依存状態に、命令を実行するコアを入れるように実行される。
【０８２３】
６８０５において、実装依存状態は、モニタリングされたアドレスへの格納、ＮＭＩ、ＳＭＩ、デバッグ例外、マシンチェック例外、ｉｎｉｔ信号又はリセット信号のうちの１つに応じて抜ける。
【０８２４】
６８０７において、スレッドと関連付けられたトランザクションは、実装依存状態から抜け出たときにアボートされる。
【０８２５】
いくつかの実施例では、アクセラレータは、特定のタイプのオペレーション、数例をあげると、グラフィックスオペレーション、機械学習オペレーション、パターン解析オペレーション、及び、（以下で詳細に説明されるような）疎行列乗算演算などを加速させるプロセッサコア又は他の処理要素に結合される。アクセラレータは、バス又は他の相互接続（例えば、ポイントツーポイント相互接続）を介してプロセッサ／コアに通信可能に結合されてよい、又は、プロセッサと同じチップ上に統合され、内部プロセッサバス／相互接続を介してコアに通信可能に結合されてよい。アクセラレータが接続される態様に関わらず、プロセッサコアは、これらのタスクを効率的に処理する専用の回路／論理を含むアクセラレータに、特定の処理タスク（例えば、命令又はＵＯＰのシーケンスの形式で）を割り当ててよい。
【０８２６】
図６９は、アクセラレータ６９００が、キャッシュコヒーレントインタフェース６９３０を通じて複数のコア６９１０−６９１１に通信可能に結合される例示的な実装を示す。コア６９１０−６９１１のそれぞれは、仮想−物理アドレス変換を格納するためのトランスレーションルックアサイドバッファ６９１２−６９１３と、データ及び命令をキャッシングするための１又は複数のキャッシュ６９１４−６９１５（例えば、Ｌ１キャッシュ、Ｌ２キャッシュなど）とを含む。メモリ管理ユニット６９２０は、ダイナミックランダムアクセスメモリＤＲＡＭであり得るシステムメモリ６９５０へのコア６９１０−６９１１によるアクセスを管理する。Ｌ３キャッシュなどの共有キャッシュ６９２６は、プロセッサコア６９１０−６９１１間で、及び、キャッシュコヒーレントインタフェース６９３０を介してアクセラレータ６９００と共有されてよい。一実施例において、コア６９１０−１０１１、ＭＭＵ６９２０及びキャッシュコヒーレントインタフェース６９３０は、シングルプロセッサチップ上に統合される。
【０８２７】
図示されたアクセラレータ６９００は、キャッシュ６９０７及び複数の処理要素６９０１−６９０２、Ｎに対するスケジューリングオペレーションのためのスケジューラ６９０６を有するデータ管理ユニット６９０５を含む。例示された実施例において、各処理要素は、独自のローカルメモリ６９０３−６９０４、Ｎを有する。以下で詳細に説明されるように、各ローカルメモリ６９０３−６９０４、Ｎは、スタック型ＤＲＡＭとして実装されてよい。
【０８２８】
一実施例において、キャッシュコヒーレントインタフェース６９３０は、コア６９１０−６９１１とアクセラレータ６９００との間にキャッシュコヒーレントな接続性をもたらし、実際には、アクセラレータをコア６９１０−６９１１のピアとして扱う。例えば、キャッシュコヒーレントインタフェース６９３０は、アクセラレータ６９００によりアクセス／修正され、かつ、アクセラレータキャッシュ６９０７及び／又はローカルメモリ６９０３−６９０４、Ｎに格納されるデータが、コアキャッシュ６９１０−６９１１、共有キャッシュ６９２６及びシステムメモリ６９５０に格納されるデータとコヒーレントであることを確保するために、キャッシュコヒーレンシプロトコルを実装してよい。例えば、キャッシュコヒーレントインタフェース６９３０は、共有キャッシュ６９２６及びローカルキャッシュ６９１４−６９１５内のキャッシュラインの状態を検出するために、コア６９１０−６９１１及びＭＭＵ６９２０により用いられるスヌーピングメカニズムに参加してよく、プロキシとして動作してよく、処理要素６９０１−６９０２、Ｎにより、キャッシュラインに対するアクセス及び試みた修正に応じてスヌープ更新を提供する。さらに、キャッシュラインが、処理要素６９０１−６９０２、Ｎにより修正された場合、キャッシュコヒーレントインタフェース６９３０は、共有キャッシュ６９２６又はローカルキャッシュ６９１４−６９１５内にそれらが格納されている場合にキャッシュラインのステータスを更新してよい。
【０８２９】
一実施例において、データ管理ユニット１００５は、システムメモリ６９５０及び共有キャッシュ６９２６へのアクセスをアクセラレータ６９００に提供するメモリ管理回路を含む。さらに、データ管理ユニット６９０５は、必要に応じて（例えば、キャッシュラインに対する状態の変化を判断するために）、キャッシュコヒーレントインタフェース６９３０への更新を提供、及び、キャッシュコヒーレントインタフェース６９３０から更新を受信する。例示された実施例において、データ管理ユニット６９０５は、処理要素６９０１−６９０２により実行される命令／処理をスケジューリングするためのスケジューラ６９０６を含む。そのスケジューリング処理を実行するために、スケジューラ６９０６は、命令／処理間の依存性を評価して、命令／処理がコヒーレントな順序で実行されることを確保する（例えば、第１の命令が、第１の命令からの結果に依存する第２の命令の前に実行することを確保する）。内部依存していない命令／処理は、処理要素６９０１−６９０２で並列に実行されてよい。
【０８３０】
図７０は、（例えば、一実施例においてスタックされたローカルのＤＲＡＭを用いて実装された）データ管理ユニット６９０５、複数の処理要素６９０１−Ｎ及び高速オンチップストレージ７０００を含む前述のアクセラレータ６９００及び他のコンポーネントの別の図を示す。一実施例において、アクセラレータ６９００は、ハードウェアアクセラレータアーキテクチャであり、処理要素６９０１−Ｎは、疎／密行列に対する演算を含む行列×ベクトル及びベクトル×ベクトル演算を実行するための回路を含む。特に、処理要素６９０１−Ｎは、列及び行方向の行列処理に対するハードウェアサポートを含んでよく、機械学習（ＭＬ）アルゴリズムで用いられるような「スケール及び更新」オペレーションに対するマイクロアーキテクチャ上のサポートを含んでもよい。
【０８３１】
説明される実装は、高速オンチップストレージ７０００において、頻繁に用いられ、ランダムにアクセスされ、潜在的に疎な（例えば、ギャザー／スキャッタ）ベクトルデータを保持することにより、ストリーミング様式で、可能なときにはいつでもアクセスされるオフチップメモリ（例えば、システムメモリ６９５０）において、大きくて低い頻度で用いられる行列データを維持することにより、及び、スケールアップするためにイントラ／インター行列ブロック並列処理をさらすことにより、最適化される行列／ベクトル演算を実行する。
【０８３２】
処理要素６９０１−Ｎの実施例では、疎行列、密行列、疎ベクトル及び密ベクトルの様々な組み合わせを処理する。本明細書で用いられるように、「疎（ｓｐａｒｓｅ）」行列又はベクトルは、成分のほとんどがゼロである行列又はベクトルである。一方、「密（ｄｅｎｓｅ）」行列又はベクトルは、成分のほどんとがゼロ以外である行列又はベクトルである。行列／ベクトルの「まばら（ｓｐａｒｓｉｔｙ）」は、ゼロの値の成分の数を成分の総数（例えば、ｍ×ｎ行列に対してｍ×ｎ）で割ることに基づいて規定され得る。一実施例において、行列／ベクトルは、そのまばらさが特定の閾値を上回る場合、「疎（ｓｐａｒｓｅ）」であるとみなされる。
【０８３３】
処理要素６９０１−Ｎにより実行される処理の例示的なセットが図７１内のテーブルに示される。特に、オペレーションタイプは、疎行列を用いる第１の乗算７１００、密行列を用いる第２の乗算７１０１、スケール及び更新演算７１０２及びドット積演算７１０３を含む。列には、第１の入力オペランド７１１０及び第２の入力オペランド７１１１（それぞれが、疎又は密行列／ベクトルを含み得る）、出力フォーマット７１１２（例えば、密ベクトル又はスカラ）、行列データフォーマット（例えば、圧縮された疎行、圧縮された疎列、行方向など）７１１３、及び、オペレーション識別子７１１４が規定されている。
【０８３４】
いくつかの現在のワークロードにおいて得られるランタイムドメイン計算パターンは、行方向及び列方向の様式でベクトルに対する行列の乗算の変形を含む。周知の行列上のそれらの機能は、圧縮された疎行（ＣＳＲ）及び圧縮された疎列（ＣＳＣ）の形式を合わせる。図７２ａは、ベクトルｙを生成するために、ベクトルｘに対する疎行列間の乗算の例を図示する。図７２ｂは、各値が（値、行インデックス）ペアとして格納される行列ＡのＣＳＲ表現を示す。例えば、行０に対する（３、２）は、３の値が、行０の成分位置２に格納されていることを示す。図７２ｃは、（値、列インデックス）ペアを用いる行列ＡのＣＳＣ表現を示す。
【０８３５】
図７３ａ、図７３ｂ及び図７３ｃは、各計算パターンの擬似コードを示し、以下に詳細に説明される。特に、図７３ａは、行方向の疎行列・密ベクトル乗算（ｓｐＭｄＶ＿ｃｓｒ）を示し、図７３ｂは、列方向の疎行列・疎ベクトル乗算（ｓｐＭｓｐＣ＿ｃｓｃ）を示し、図７３ｃは、スケール及び更新演算（ｓｃａｌｅ＿ｕｐｄａｔｅ）を示す。
【０８３６】
Ａ．行方向の疎行列・密ベクトル乗算（ｓｐＭｄＶ＿ｃｓｒ）
【０８３７】
これは、高性能な計算など多くのアプリケーション分野で重要な周知の計算パターンである。ここで、行列Ａの各行に対して、ベクトルｘに対するその行のドット積が実行され、その結果が、行インデックスにより指し示されるｙベクトル成分に格納される。この計算は、サンプリングのセット（すなわち、行列の行）にわたって解析を実行する機械学習（ＭＬ）アルゴリズムにおいて用いられる。それは、「ミニバッチ」などの技術において用いられてもよい。例えば、学習アルゴリズムの確率論的な確率変数において、ＭＬアルゴリズムが、密ベクトルに対する疎ベクトルのドット積を単に実行する場合（すなわち、ｓｐＭｄＶ＿ｃｓｒループの反復）もある。
【０８３８】
この計算の性能に影響を与え得る既知の要因は、ドット積計算において、疎ｘベクトル成分にランダムにアクセスする必要があることである。従来のサーバシステムに関して、ｘベクトルが大きい場合、これは、メモリ又はラストレベルキャッシュへの不規則なアクセス（収集）を結果としてもたらしたであろう。
【０８３９】
これに対処するために、処理要素の一実施例では、行列Ａを列ブロックに、ｘベクトルを（行列Ａの列ブロックにそれぞれ対応する）複数のサブセットに分割する。ブロックサイズは、ｘベクトルのサブセットがチップに合致できるように選択され得る。よって、それへのランダムなアクセスは、局在化されたオンチップであり得る。
【０８４０】
Ｂ．列方向の疎行列・疎ベクトル乗算（ｓｐＭｓｐＶ＿ｃｓｃ）
【０８４１】
疎ベクトルに対して疎行列を乗算するこのパターンは、ｓｐＭｄＶ＿ｃｓｒほど周知ではない。しかしながら、いくつかのＭＬアルゴリズムにおいて重要である。それは、アルゴリズムが特徴のセットに作用する場合に用いられ、データセット内の行列の列として表される（よって列方向の行列アクセスが必要になる）。
【０８４２】
この計算パターンでは、行列Ａの各列が、読み出されて、ベクトルｘの対応する非ゼロ成分に対して乗算される。その結果は、ｙベクトルで保持される部分的なドット積を更新するために用いられる。ゼロ以外のｘベクトル成分と関連付けられたすべての列が処理されると、ｙベクトルは、最終的なドット積を含むことになる。
【０８４３】
行列Ａへのアクセス（すなわち、Ａの列におけるストリーム）が正常である一方、部分的なドット積を更新するｙベクトルへのアクセスは不規則である。アクセスするｙ成分は、処理されるＡベクトル成分の行インデックスに依存する。これに対処するために、行列Ａは、行ブロックに分割され得る。その結果、ベクトルｙは、これらのブロックに対応するサブセットに分割され得る。この方式では、行列の行ブロックを処理する場合に、そのｙベクトルサブセットに不規則にアクセス（ギャザー／スキャッタ）することのみが必要である。適切にブロックサイズを選択することにより、ｙベクトルサブセットは、オンチップで保持され得る。
【０８４４】
Ｃ．スケール及び更新（ｓｃａｌｅ＿ｕｐｄａｔｅ）
【０８４５】
このパターンは、典型的には、行列内の各サンプルにスケーリングファクタを適用するＭＬアルゴリズムにより用いられ、それぞれが特徴（すなわち、Ａ内の列）に対応する、それらが重みのセットへと低減される。ここで、ｘベクトルはスケーリングファクタを含む。（ＣＳＲフォーマットにおける）行列Ａの各行に対して、その行に対するスケーリングファクタは、ｘベクトルから読み出され、次に、その行におけるＡの各成分に適用される。その結果は、ｙベクトルの成分を更新するために用いられる。すべて行が処理されると、ｙベクトルは、低減された重みを含むことになる。
【０８４６】
前の計算パターンと同様に、ｙベクトルに対する不規則なアクセスは、ｙが大きい場合の性能に影響を与え得る。行列Ａを列ブロックに、ｙベクトルをこれらのブロックに対応する複数のサブセットに分割することは、各ｙサブセット内に不規則なアクセスを局所化するのに役立てることができる。
【０８４７】
一実施例では、上述した計算パターンを効率的に実行できるハードウェアアクセラレータを含む。アクセラレータは、汎用プロセッサと統合され得るハードウェアＩＰブロックである。一実施例において、アクセラレータ６９００は、プロセッサと共有される相互接続を通じてメモリ６９５０に独立にアクセスして、計算パターンを実行する。それは、オフチップメモリ内に存在するいずれか任意の大規模行列データセットをサポートする。
【０８４８】
図７４は、データ管理ユニット６９０５及び処理要素６９０１−６９０２の一実施例に関する処理フローを示す。この実施例において、データ管理ユニット６９０５は、処理要素スケジューラ７４０１、読み出しバッファ７４０２、書き込みバッファ７４０３及び低減ユニット７４０４を含む。各ＰＥ６９０１−６９０２は、入力バッファ７４０５−７４０６、乗算器７４０７−７４０８、加算器７４０９−７４１０、ローカルＲＡＭ７４２１−７４２２、合計レジスタ（ｓｕｍ  ｒｅｇｉｓｔｅｒ）７４１１−７４１２及び出力バッファ７４１３−７４１４を含む。
【０８４９】
アクセラレータは、いずれか任意の大規模行列データをサポートするために、上述した行列ブロッキングスキーム（すなわち、行及び列のブロック化）をサポートする。アクセラレータは、行列データのブロックを処理するように設計される。各ブロックは、ＰＥ６９０１−６９０２により並列に処理されるサブブロックにさらに分割される。
【０８５０】
動作中、データ管理ユニット６９０５は、メモリサブシステムからその読み出しバッファ７４０２に行列の行又は列を読み出し、次に、処理するためにＰＥ６９０１−６９０２にわたってＰＥスケジューラ７４０１により動的に分配される。それはまた、その書き込みバッファ７４０３からメモリに結果を書き込む。
【０８５１】
各ＰＥ６９０１−６９０２は、行列のサブブロックを処理する役割を担う。ＰＥは、ランダムにアクセスされる必要があるベクトル（すなわち、上記で説明されたようなｘ又はｙベクトルのサブセット）を格納するオンチップＲＡＭ７４２１−７４２２を含む。また、乗算器７４０７−７４０８及び加算器７４０９−７４１０を含む浮動小数点積和（ＦＭＡ）ユニットと、入力データから行列成分を抽出する入力バッファ７４０５−７４０６内のアンパック論理と、累算されたＦＭＡ結果を保持する合計レジスタ（ｓｕｍ  ｒｅｇｉｓｔｅｒ）７４１１−７４１２と含む。
【０８５２】
アクセラレータの一実施例は、（１）不規則にアクセス（ギャザー／スキャッタ）されるデータをオンチップＰＥ  ＲＡＭ７４２１−７４２２に配置し、（２）ＰＥが十分に利用されることを確保するためにハードウェアＰＥスケジューラ７４０１を利用し、（３）汎用プロセッサを用いる場合とは異なり、アクセラレータが、疎行列演算に不可欠なハードウェアリソースのみからなるので、最高の効率性を実現する。全体的には、アクセラレータは、それに提供される利用可能なメモリ帯域幅を性能へと効率的に変換する。
【０８５３】
性能のスケーリングは、１つのアクセラレータブロックにおいて多くのＰＥを使用して、並列に複数の行列のサブブロックを処理することにより、及び／又は、より多くのアクセラレータブロック（それぞれがＰＥのセットを有する）を使用して、並列に複数の行列ブロックを処理することにより行われ得る。これらのオプションの組み合わせが以下で検討される。ＰＥ及び／又はアクセラレータブロックの数は、メモリ帯域幅に一致するように調整されるべきである。
【０８５４】
アクセラレータ６９００の一実施例では、ソフトウェアライブラリを通じてプログラミングされ得る。そのようなライブラリは、メモリに行列データを準備し、計算に関する情報（例えば、計算タイプ、行列データに対するメモリポインタ）と共にアクセラレータ６９００内に制御レジスタを設定し、アクセラレータを開始させる。次に、アクセラレータは、メモリ内の行列データに独立にアクセスして、計算を実行し、消費するソフトウェアに関する結果をメモリに書き戻す。
【０８５５】
アクセラレータは、図７５ａ〜図７５ｂに図示されるように、適切なデータパス構成に対してそのＰＥを設定することにより、様々な計算パターンを処理する。特に、図７５ａは、ｓｐＭｓｐＶ＿ｃｓｃ及びｓｃａｌｅ＿ｕｐｄａｔｅ演算に関する（点線を用いて）パスを強調表示し、図７５ｂは、ｓｐＭｄＶ＿ｃｓｒ演算に関するパスを示す。各計算パターンを実行するアクセラレータのオペレーションが以下に詳細に説明される。
【０８５６】
ｓｐＭｓｐＶ＿ｃｓｃに関して、ＤＭＵ６９０５により、最初のｙベクトルサブセットがＰＥのＲＡＭ７４２１にロードされる。次に、メモリからｘベクトル成分を読み出す。各ｘ成分に対して、ＤＭＵ６９０５は、メモリから対応する行列の列の成分をストリームして、これらをＰＥ６９０１に供給する。各行列成分は、ＰＥのＲＡＭ７４２１から読み出すことをｙ成分に指し示す値（Ａ．ｖａｌ）及びインデックス（Ａ．ｉｄｘ）を含む。ＤＭＵ６９０５はまた、積和（ＦＭＡ）ユニットによりＡ．ｖａｌに対して乗算されるｘベクトル成分（ｘ．ｖａｌ）も提供する。結果は、Ａ．ｉｄｘにより指し示されるＰＥのＲＡＭ内のｙ成分を更新するために用いられる。たとえ、本願のワークロードにより用いられなかったとしても、アクセラレータは、サブセットのみの代わりにすべての行列の列を処理することにより、密ｘベクトル（ｓｐＭｄＶ＿ｃｓｃ）に対して列のような乗算をサポートすることに留意する（ｘが密なので）。
【０８５７】
ｓｃａｌｅ＿ｕｐｄａｔｅオペレーションは、ＣＳＣフォーマットの代わりにＣＳＲフォーマットに表される行列Ａの行をＤＭＵ６９０５が読み出すことを除き、ｓｐＭｓｐＶ＿ｃｓｃと同様である。ｓｐＭｄＶ＿ｃｓｒに関して、ｘベクトルのサブセットは、ＰＥのＲＡＭ７４２１にロードされる。ＤＭＵ６９０５は、メモリから行列の行成分（すなわち、｛Ａ.ｖａｌ、Ａ.ｉｄｘ｝のペア）にストリームする。Ａ．ｉｄｘは、ＲＡＭ７４２１から適切なｘベクトル成分を読み出すために用いられ、ＦＭＡによりＡ．ｖａｌに対して乗算される。結果は、合計レジスタ（ｓｕｍ  ｒｅｇｉｓｔｅｒ）７４１２へと累算される。合計レジスタ（ｓｕｍ  ｒｅｇｉｓｔｅｒ）は、ＤＭＵ６９０５により供給される行の終わりを示すマーカをＰＥが参照する度に、出力バッファに書き込まれる。このようにして、各ＰＥは、それが担う行のサブブロックに対する合計を生成する。行についての最終的な合計を生成するために、すべてのＰＥにより生成されたサブブロックの合計は、ＤＭＵ内の低減ユニット７４０４によりまとめて加えられる（図７４を参照）。最終的な合計は、出力バッファ７４１３−７４１４に書き込まれ、その結果、ＤＭＵ６９０５はそれをメモリに書き込む。
【０８５８】
グラフデータ処理
【０８５９】
一実施例において、本明細書で説明されるアクセラレータアーキテクチャは、グラフデータを処理するように構成される。グラフ分析は、グラフとして表されるデータ間の関係に関する知識を抽出するために、グラフアルゴリズムに依存する。グラフデータの拡散（ソーシャルメディアなどのソースから）は、グラフ分析に対する強い要求及び幅広い利用をもたらしてきた。その結果、できるだけ効率的にグラフ分析をできるようにすることが非常に重要である。
【０８６０】
この要求に対処するために、一実施例では、所与の入力グラフアルゴリズムにカスタマイズされるハードウェアアクセラレータアーキテクチャ「テンプレート」にユーザ定義型のグラフアルゴリズムを自動的にマッピングする。アクセラレータは、上記で説明されるアーキテクチャを有してよく、ＦＰＧＡ／ＡＳＩＣとして実装されてよく、それは最高の効率性で実行できる。要約すると、一実施例では以下の構成を含む。
【０８６１】
（１）汎用の疎行列ベクトル乗算（ＧＳＰＭＶ）アクセラレータに基づくハードウェアアクセラレータアーキテクチャテンプレート。グラフアルゴリズムが行列演算として定式化されることができることが示されているので、任意のグラフアルゴリズムをサポートする。
【０８６２】
（２）アーキテクチャテンプレートに対して、広く用いられている「頂点主体」グラフプログラミング抽象化をマッピング及び調整する自動アプローチ。
【０８６３】
既存の疎行列乗算ハードウェアアクセラレータがあるが、それらは、グラフアルゴリズムのマッピングを可能にするカスタマイズ性をサポートしていない。
【０８６４】
設計フレームワークの一実施例では、以下のように動作する。
【０８６５】
（１）ユーザは、頂点−中心のグラフプログラミング抽象化に従う「頂点プログラム」としてグラフアルゴリズムを規定する。この抽象化は、その人気に起因して、ここでは例として選択される。頂点プログラムは、ハードウェアの詳細をさらすことはなく、そのため、ハードウェアの専門的知識（例えば、データ科学者）のないユーザでも、それを作成できる。
【０８６６】
（２）（１）のグラフアルゴリズムと共に、フレームワークの一実施例では、以下の入力を受け入れる。
【０８６７】
生成させるターゲットハードウェアアクセラレータのパラメータ（例えば、オンチップＲＡＭの最大量）。これらのパラメータは、ユーザにより提供されてよい、又は、既存のシステム（例えば、特定のＦＰＧＡボード）をターゲットとする場合、既知のパラメータの既存のライブラリから取得されてよい。
【０８６８】
ｂ．設計最適化目標（例えば、最大性能、最小エリア）
【０８６９】
ｃ．ターゲットグラフデータの特性（例えば、グラフのタイプ）又はグラフデータ自体これは選択的であり、自動チューニングを補助するために用いられる。
【０８７０】
（３）上記の入力を前提として、フレームワークの一実施例では、自動チューニングを実行して、入力グラフアルゴリズムを最適化するために、ハードウェアテンプレートに適用するカスタマイズのセットを判断し、これらのパラメータをアーキテクチャテンプレート上にマッピングして、合成可能なＲＴＬにアクセラレータインスタンスを生成し、入力グラフアルゴリズム仕様から導き出される機能及び性能のソフトウェアモデルに対する、生成したＲＴＬの機能及び性能の検証を行う。
【０８７１】
一実施例において、上記で説明されるアクセラレータアーキテクチャは、（１）それをカスタマイズ可能なハードウェアテンプレートにすること、（２）頂点プログラムにより必要とされる機能をサポートすることにより、頂点プログラムの実行をサポートするように拡張される。このテンプレートに基づいて、設計フレームワークは、ユーザ供給型の頂点プログラムをハードウェアテンプレートにマッピングして、頂点プログラムに対して最適化された合成可能なＲＴＬ（例えば、Ｖｅｒｉｌｏｇ）の実装インスタンスを生成するために説明される。フレームワークはまた、生成したＲＴＬが訂正及び最適化されることを確保するために、自動検証及びチューニングを実行する。このフレームワークに関しては、複数の使用事例がある。例えば、生成された合成可能なＲＴＬは、所与の頂点プログラムを効率的に実行するために、ＦＰＧＡプラットフォーム（例えば、Ｘｅｏｎ−ＦＰＧＡ）に配置され得る。又は、それは、ＡＳＩＣの実装を生成するように、さらに改良され得る。
【０８７２】
グラフは、隣接行列として表されることができ、グラフ処理は、疎行列演算として定式化されることができる。図７６ａ〜図７６ｂは、隣接行列としてのグラフを表す例を示す。行列内のそれぞれのゼロ以外は、グラフ内の２つのノード中のエッジを表す。例えば、０行２列における１は、ノードＡからＣのエッジを表す。
【０８７３】
グラフデータの計算を表現するための最もポピュラーなモデルの１つは、頂点プログラミングモデルである。一実施例では、汎用の疎行列ベクトル乗算（ＧＳＰＭＶ）として、頂点プログラムを定式化するグラフマットソフトウェアフレームワークからの頂点プログラミングモデルの変形をサポートする。図７６ｃに示されるように、頂点プログラムは、（プログラムコードの最上部に示されるような）グラフ内のエッジ／頂点と関連付けられた複数のタイプのデータ（ｅデータ／ｖデータ）、グラフ内の頂点を介して送信されるメッセージ（ｍデータ）、及び、一時的なデータ（ｔデータ）、並びに、（プログラムコードの下部に示さるような）グラフデータを読み出して更新する予め定義されたＡＰＩを用いるステートレスなユーザ定義型の計算機能からなる。
【０８７４】
図７６ｄは、頂点プログラムを実行するための例示的なプログラムコードを示す。エッジデータは、（図７６ｂに示すように）隣接行列Ａとして、頂点データをベクトルｙとして、メッセージを疎ベクトルｘとして表される。図７６ｅは、ＧＳＰＭＶの策定を示し、ＳＰＭＶにおける乗算（）及び加算（）演算は、ユーザ定義型のＰＲＯＣＥＳＳ＿ＭＳＧ（）及びＲＥＤＵＣＥ（）により一般化される。
【０８７５】
ここでの１つの見解は、頂点プログラムを実行するのに必要とされるＧＳＰＭＶの変形が、疎ベクトルｘ（すなわち、メッセージ）に対する疎行列Ａ（すなわち、隣接行列）の列方向乗算を実行して、出力ベクトルｙ（すなわち、頂点データ）を生成することである。この演算は、（上記のアクセラレータに関して前述した）ｃｏｌ＿ｓｐＭｓｐＶと称される。
【０８７６】
設計フレームワークテンプレートマッピングコンポーネント７７１１、検証コンポーネント７７１２及び自動チューニングコンポーネント７７１３を含むフレームワークの一実施例が図７７に示される。その材料は、ユーザ規定型の頂点プログラム７７０１、設計最適化目標７７０３（例えば、最大性能、最小エリア）及びターゲットハードウェア設計制約７７０２（例えば、オンチップＲＡＭの最大量、メモリンタフェース幅）である。自動チューニングを補助する選択的な材料として、フレームワークは、グラフデータ特性７７０４（例えば、タイプ＝自然グラフ）又はサンプリンググラフデータも許容する。
【０８７７】
これらの材料を前提として、フレームワークのテンプレートマッピングコンポーネント７７１１は、入力ベクトルプログラムをハードウェアアクセラレータアーキテクチャテンプレートにマッピングし、頂点プログラム７７０１を実行するために最適化されたアクセラレータインスタンスのＲＴＬ実装７７０５を生成する。自動チューニングコンポーネント７７１３は、自動チューニング７７１３を実行して、所与の設計目標のために、生成したＲＴＬを最適化しつつ、ハードウェア設計制約を満たす。さらに、検証コンポーネント７７１２は、当該材料から導き出された機能及び性能モデルに対して生成したＲＴＬを自動的に検証する。検証テストベンチ７７０６及びチューニング報告７７０７は、ＲＴＬと共に生成される。
【０８７８】
汎用の疎行列ベクトル乗算（ＧＳＰＭＶ）ハードウェアアーキテクチャテンプレート
【０８７９】
ＧＳＰＭＶに関するアーキテクチャテンプレートの一実施例が図７７に示され、それは、上記で説明したアクセラレータアーキテクチャに基づいている（例えば、図７４及び関連する文章を参照）。図７７に示されるコンポーネントの多くがカスタマイズ可能である。一実施例において、頂点プログラムの実行をサポートするアーキテクチャは、以下のように拡張されている。
【０８８０】
図７８に示されるように、カスタマイズ可能な論理ブロックが、頂点プログラムにより必要とされるＰＲＯＣＥＳＳ＿ＭＳＧ（）１９１０、ＲＥＤＵＣＥ（）７８１１、適用７８１２及びＳＥＮＤ＿ＭＳＧ（）７８１３をサポートするために、各ＰＥ内に提供される。さらに、一実施例では、ユーザ定義型のグラフデータ（すなわち、ｖデータ、ｅデータ、ｍデータ、ｔデータ）をサポートするカスタマイズ可能なオンチップストレージ構造及びパック／アンパック論理７８０５を提供する。図示されるデータ管理ユニット６９０５は、ＰＥスケジューラ７４０１（上記で説明したようなＰＥをスケジューリングするためのもの）、補助バッファ７８０１（アクティブな列、ｘデータを格納するためのもの）、読み出しバッファ７４０２、システムメモリへのアクセスを制御するためのメモリコントローラ７８０３、及び、書き込みバッファ７４０３を含む。さらに、図７８に示される実施例では、古い及び新しいｖデータ及びｔデータがローカルＰＥメモリ７４２１内に格納されている。様々な制御ステートマシンは、頂点プログラムを実行すること、図７６ｄ及び図７６ｅにおけるアルゴリズムにより規定される機能に対する不変性をサポートするために修正されてよい。
【０８８１】
各アクセラレータタイルの処理が図７９に要約されている。７９０１において、ｙベクトル（ｖデータ）がＰＥ  ＲＡＭ７４２１にロードされる。７９０２において、ｘベクトル及び列ポインタが補助バッファ７８０１にロードされる。７９０３において、ｘベクトル成分ごとに、列は（ｅデータ）にストリーミングされ、ＰＥは、ＰＲＯＣ＿ＭＳＧ（）７８１０及びＲＥＤＵＣＥ（）７８１１を実行する。７９０４において、ＰＥは、ＡＰＰＬＹ（）７８１２を実行する。７９０５において、ＰＥは、ＳＥＮＤ＿ＭＳＧ（）７８１３を実行してメッセージを生成し、データ管理ユニット６９０５は、これらうぃｘベクトルとしてメモリに書き込む。７９０６において、データ管理ユニット６９０５は、ＰＥ  ＲＡＭ７４２１に格納された、更新されたｙベクトル（ｖデータ）をメモリに書き戻す。上記の技術は、図７６ｄ及び図７６ｅに示される頂点プログラム実行アルゴリズムに適合する。性能を高めるするために、アーキテクチャは、設計において、タイル内のＰＥの数及び／又はタイルの数を増加させることを可能にする。この方式では、アーキテクチャは、（すなわち、（隣接行列の、又は、各サブグラフ内のブロックにわたる）サブグラフにわたる）グラフの並列処理の複数のレベルを利用する。図８０ａ内の表は、テンプレートの一実施例についてのカスタマイズ可能なパラメータを要約したものである。最適化用のタイル（例えば、別のタイルより多くのＰＥを有する１つのタイル）にわたって非対称なパラメータを割り当てることも可能である。
【０８８２】
自動マッピング、検証及びチューニング
【０８８３】
チューニング。入力に基づいて、フレームワークの一実施例では、入力ベクトルプログラム及び（選択的に）グラフデータに対してハードウェアアーキテクチャテンプレートを最適化するために、それをカスタマイズするために用いるように最良な設計パラメータを判断する自動チューニングを実行する。多くのチューニング検討事項があり、それらは図８０ｂ内のテーブルに要約されている。図示されるように、これらは、データの局所性、グラフデータサイズ、グラフ計算機能、グラフデータ構造、グラフデータアクセス属性、グラフデータタイプ及びグラフデータパターンを含む。
【０８８４】
テンプレートマッピング。このフェーズでは、フレームワークは、チューニングフェーズにより判断されたテンプレートパラメータを取得し、テンプレートのカスタマイズ可能な部分において「フィル」することによりアクセラレータインスタンスを生成する。ユーザ定義型の計算機能（例えば、図７６ｃ）は、既存の高位合成（ＨＬＳ）ツールを用いて、入力仕様から適切なＰＥ計算ブロックにマッピングされてよい。ストレージ構造（例えば、ＲＡＭ、バッファ、キャッシュ）及びメモリンタフェースは、これらの対応する設計パラメータを用いてインスタンス化される。パック／アンパック論理は、データタイプ仕様（例えば、図７６ａ）から自動的に生成されてよい。制御有限ステートマシン（ＦＳＭ）の一部はまた、提供された設計パラメータ（例えば、ＰＥスケジューリングスキーム）に基づいて生成される。
【０８８５】
検証。一実施例において、テンプレートマッピングにより生成されたアクセラレータアーキテクチャインスタンス（合成可能なＲＴＬ）は、次に、自動的に検証される。これをするために、フレームワークの一実施例では、「ゴールデン」リファレンスとして用いられる頂点プログラムの関数型モデルを導出する。テストベンチは、アーキテクチャインスタンスのＲＴＬ実装のシミュレーションに対して、このゴールデンリファレンスの実行を比較するために生成される。フレームワークはまた、解析性能モデル及びサイクルが正確なソフトウェアシミュレータに対して、ＲＴＬシミュレーションを比較することにより、性能検証を実行する。それは、ランタイムの内訳を報告し、性能に影響を与える設計のボトルネックを特定する。
【０８８６】
疎データセットの計算−ほとんどの値がゼロであるベクトル又は行列−は、ますます増加する数の商業的に重要なアプリケーションにとって重大であるが、典型的には、今日のＣＰＵ上で実行した場合、ピークパフォーマンスのわずか数パーセントしか実現していない。科学コンピューティング分野において、疎行列計算は、数十年間、線形ソルバの重要なカーネルであった。近年では、機械学習及びグラフ分析の爆発的な成長が疎計算を主流へと移動させてきた。疎行列計算は、多くの機械学習アプリケーションの中核をなし、多くのグラフアルゴリズムのコアを形成する。
【０８８７】
疎行列計算は、計算上制限されるよりもむしろメモリ帯域幅上制限される傾向があり、それが、ＣＰＵの変更によってこれらの性能を向上させることを困難にしている。それらは、行列データ要素毎に演算をほとんど実行しておらず、多くの場合、任意のデータを再利用する前に行列全体にわたって反復するため、キャッシュを役立たせていない。さらに、多くの疎行列アルゴリズムは、かなりの数のデータに依存したギャザー及びスキャッタ、例えば、疎行列−ベクトル乗算において得られる、ｒｅｓｕｌｔ［ｒｏｗ］＋＝ｍａｔｒｉｘ［ｒｏｗ］［ｉ］.ｖａｌｕｅ*ｖｅｃｔｏｒ［ｍａｔｒｉｘ［ｒｏｗ］［ｉ］.ｉｎｄｅｘ］演算、を含み、それらは、プリフェッチャの有効性を予測し低減することが難しい。
【０８８８】
従来のマイクロプロセッサより良好な疎行列の性能を実現させるためには、システムは、現在のＣＰＵよりもかなり高いメモリ帯域幅及び非常にエネルギー効率の良いコンピューティングアーキテクチャを提供しなければならない。メモリ帯域幅を増加させることで、性能を向上させることができるが、ＤＲＡＭアクセスの高いエネルギー／ビットコストが、その帯域幅を処理するために利用可能な電力量を制限する。エネルギー効率の良い計算アーキテクチャなしでは、システムは、そのパワーバジェットを超えることなく、高帯域幅のメモリシステムからのデータを処理することができない状況に置かれるかもしれない。
【０８８９】
一実施例では、スタック型ＤＲＡＭを用いて、エネルギー効率の良い方式でその帯域幅を処理するために、疎行列アルゴリズムがカスタム計算アーキテクチャと組み合わせられる必要がある帯域幅を提供する疎行列計算のためのアクセラレータを有する。
【０８９０】
疎−行列概要
【０８９１】
多くのアプリケーションは、値の大部分がゼロであるデータ設定を作成する。有限要素方法は、各ポイントの状態がメッシュ内のそれに近いポイントの状態の関数であるポイントのメッシュとしてオブジェクトをモデル化する。数学的には、これは、各行が１つのポイントの状態を表現し、行が表現するポイントの状態に直接的には影響を与えないポイントのすべてに対して行の値がゼロである行列として表される連立方程式になる。グラフは、隣接行列として表されることができ、行列内の各成分｛ｉ,ｊ｝は、グラフ内の頂点ｉとｊとの間のエッジについての重みを与える。多くの頂点は、グラフ内の他の頂点のごく一部だけを結びつけるので、隣接行列内の成分の大部分はゼロである。機械学習において、モデルは、典型的には、多くのサンプルからなるデータセットを用いてトレーニングされ、それぞれが、特徴のセット（システム又はオブジェクトの状態についての見解）及びその特徴のセットのモデルについての所望の出力を含む。サンプルの多くで、可能な機能の小さなサブセットだけを含めることはよくあることであり、例えば、機能がドキュメント内に存在し得る様々なワードを表す場合、値のほとんどがゼロであるデータセットを再び作成している。
【０８９２】
値のほとんどがゼロであるデータセットは、「疎（ｓｐａｒｓｅ）」として説明され、それは、これらの要素のうちの１％より少ない要素においてゼロ以外の値を有する、疎データセットが極めて疎であることはよくあることである。これらのデータセットは、多くの場合、行列として表され、行列内のゼロ以外の成分の値だけを規定するデータ構造を用いる。これは、各ゼロ以外の成分を表すのに必要とされる空間の量を増やす一方で、成分の位置及びその値の両方を規定する必要があるので、行列が十分に疎である場合、全体的な空間（メモリ）の節約はかなりのものとなる。例えば、疎行列の最も単純表現のうちの１つは、調整リスト（ＣＯＯ）表現であり、ゼロ以外のそれぞれは、｛行インデックス、列インデックス、値｝のタプルにより規定される。これは、ゼロ以外の値ごとに必要とされる記憶量を３倍にする一方、たった１％の行列内の成分がゼロ以外の値を有する場合、ＣＯＯ表現は、密な表現（行列内の各成分の値を表すもの）が取るであろう空間のたった３％しか引き上げない。
【０８９３】
図８１は、最も一般的な疎行列フォーマット、圧縮行格納（ＣＲＳ、時には、短縮型ＣＳＲ）フォーマットの１つを示す。ＣＲＳフォーマットにおいて、行列８１００は、ゼロ以外の成分の値を含む値配列８１０１、行列のその行内の各ゼロ以外の成分の位置を規定するインデックスアレイ８１０２、及び、インデックス及び値のリストにおいて行列の各行が始まる位置を規定する行開始アレイ８１０３、という３つの配列により表現される。したがって、例示的な行列の第２行の第１のゼロ以外の成分は、インデックス及び値アレイ内の位置２において見つけられることができ、タプル｛０，７｝で表現されており、成分が行内の位置０に存在し、値７を有することを示す。他の一般に用いられる疎行列フォーマットは、ＣＲＳに対してデュアルな列優先である圧縮された疎列（ＣＳＣ）、及び、行列の各行をゼロ以外の値についての固定幅リスト及びこれらのインデックスとして表し、行列内の最長の行より少ないゼロ以外の成分を行が有する場合、明示的なゼロでパディングするＥＬＬＰＡＣＫを含む。
【０８９４】
疎行列の計算は、これらの密行列の対応部分と同じ構造を有するが、疎データの特性は、これらの密行列の対応部分よりも、これらをはるかに多くの帯域幅集約的にする傾向がある。例えば、行列−行列乗算の疎及び密の変形の両方は、すべてのｉ，ｊについて、Ｃｉ，ｊ＝Ａｉ，・Ｂ，ｊを計算することにより、Ｃ＝Ａ・Ｂであることが分かる。密行列−行列計算では、Ａの各成分は、Ｂの各要素がそうであるように、Ｎ回の積和演算（Ｎ×Ｎ行列と仮定した場合）に関与するので、これは、かなりのデータ再利用につながる。行列−行列乗算がキャッシュの局所性のためにブロック化される限り、この再利用は、低バイト／ｏｐレートを有し、計算上制限された計算（ｃｏｍｐｕｔａｔｉｏｎ）の原因となる。しかしながら、疎な変形では、Ａの各成分は、Ｂの対応する行にあるゼロ以外の値と同じ数の積和演算に関与するのみである一方、Ｂの各成分は、Ａの対応する列にあるゼロ以外の成分と同じ数の積和演算に関与するのみである。バイト／ｏｐレートがそうであるように、行列のまびき（ｓｐａｒｓｅｎｅｓｓ）が向上するにつれて、密行列−行列乗算が基準計算−バウンド計算であるという事実にも関わらず、多くの疎行列−行列計算の性能をメモリ帯域幅により制限させている。
【０８９５】
４つの演算は、今日のアプリケーション、すなわち、疎行列−疎ベクトル乗算（ＳｐＭＶ）、疎行列−疎ベクトル乗算、疎行列−疎行列乗算及び緩和／平滑化演算、例えば、高性能な共役勾配基準の実装で用いられるガウス−ザイデルスムーザで見られる疎行列計算のバルクを埋め合わせする。これらの演算は、疎行列アクセラレータを実用的にする２つの特性を共有する。第１に、それらは、ベクトルドット積が大半を占め、４つの重要な計算のすべてを実装できるシンプルなハードウェアを実装することを可能にする。例えば、行列−ベクトル乗算は、ベクトルと行列内の各行とのドット積を取ることにより実行される一方、行列−行列乗算は、一方の行列の各列と他方の行列の各行とのドット積を取る。第２に、アプリケーションは、一般に同じ行列に対して複数の計算、例えば、サポートベクトルマシンアルゴリズムがモデルをトレーニングして実行する、同じ行列の異なるベクトルとの数千回もの乗算を実行する。同じ行列のこの繰り返し使用は、データ転送／変換のコストが各行列に対する多くの演算にわたってならされ得るので、ハードウェアのタスクを簡略化する方式でプログラム実行中にアクセラレータへ／から行列を転送し、及び／又は、行列を再フォーマット化することを実用的にする。
【０８９６】
疎行列計算は、典型的には、それらが実行するシステムのピークパフォーマンスのわずか数パーセントしか実現していない。なぜこれが発生するかを明らかにするために、図８２は、ＣＲＳデータフォーマットを用いた疎行列−密ベクトル乗算の実装に関する段階８２０１−８２０４を示す。第１に、８２０１において、行列の行を表すデータ構造がメモリから読み出され、通常、予測及びプリフェッチすることが容易であるシーケンシャルな読み出しのセットに関する。第２に、８２０２において、行列の行内のゼロ以外の成分のインデックスは、多数のデータ依存型の予測困難なメモリアクセス（ギャザーオペレーション）を必要とする、ベクトルの対応する成分を収集するために用いられる。さらに、これらのメモリアクセスは、多くの場合、各参照されるキャッシュライン内の１又は２ワードしか触れないので、ベクトルがキャッシュに適合していない場合、かなり多くの無駄な帯域幅をもたらす。
【０８９７】
第３に、８２０３において、プロセッサは、行列の行のゼロ以外の成分及びベクトルの対応する成分のドット積を計算する。最後に、８２０４において、ドット積の結果が、結果ベクトルに書き込まれ、また、連続的にアクセスされ、プログラムは、行列の次の行に進む。これは、計算の概念的／アルゴリズムの観点であり、プログラムが実行するオペレーションの正確なシーケンスは、プロセッサのＩＳＡ及びベクトル幅に依存することに留意する。
【０８９８】
この例は、疎行列計算の多数の重要な特性を示す。３２ビットデータタイプ、及び、行列もベクトルもキャッシュに合致していないと仮定して、出力される行の第１の成分を計算するには、ＤＲＡＭから３６バイトを読み出す必要があるが、７．２：１のバイト／ｏｐレートに対して、５つの計算命令（３つが乗算及び２つが加算）だけである。
【０８９９】
しかしながら、メモリ帯域幅は、高性能な疎行列計算に対する唯一の課題ではない。図８２が示すように、ＳｐＭＶにおけるベクトルへのアクセスは、データ依存しており、予測が困難であるので、アプリケーションへのベクトルアクセスのレイテンシをさらす。ベクトルがキャッシュに適合しない場合、ＳｐＭＶの性能は、たとえ、データを待機する多くのスレッドがストールされた場合であっても、ＤＲＡＭ帯域幅を飽和させるのに十分な並列性をプロセッサが提供しない限り、ＤＲＡＭレイテンシ並びに帯域幅に敏感になる。
【０９００】
したがって、疎行列計算のアーキテクチャは、いくつかの事項を有効にしなければならない。疎計算についてのバイト／ｏｐの必要性を満たすように高いメモリ帯域幅を実現させなければならない。また、キャッシュに適合しない可能性がある大きなベクトルからの高帯域幅収集をサポートしなければならない。最後に、ＤＲＡＭ帯域幅に追従するために十分な算術演算／秒を実行することそれ自体が課題ではないとはいえ、アーキテクチャは、システムのパワーバジェット内に維持するために、エネルギー効率の良い方式で、それらのオペレーション及びそれらが必要とするメモリアクセスのすべてを実行しなければならない。
【０９０１】
一実施例では、高いメモリ帯域幅、大きなベクトルからの高帯域幅収集及びエネルギー効率の良い計算という、高い疎−行列性能に必要な３つの機能を提供するように設計されたアクセラレータを有する。図８３に示されるように、アクセラレータの一実施例は、アクセラレータ論理ダイ８３０５と、ＤＲＡＭダイの１又は複数のスタック８３０１−８３０４とを含む。以下により詳細に説明されるスタック型ＤＲＡＭは、低エネルギー／ビットで高いメモリ帯域幅を提供する。例えば、スタック型ＤＲＡＭは、２．５ｐＪ／ｂｉｔで２５６−５１２ＧＢ／秒を実現することが予期され、一方、ＬＰＤＤＲ４  ＤＩＭＭは、たった６８ＧＢ／秒しか実現しないことが予期され、１２ｐＪ／ｂｉｔのエネルギーコストを有する。
【０９０２】
アクセラレータスタックの最下層にあるアクセラレータ論理チップ８３０５は、疎行列計算の必要性に合わせてカスタマイズされ、ＤＲＡＭスタック８３０１−８３０４により提供される帯域幅を消費することができ、一方、エネルギー消費がスタックの帯域幅に比例するが、２〜４ワットの電力しか費やしていない。本願の残りの部分については、２７３ＧＢ／秒のスタックの帯域幅（ＷＩＯ３スタックの予期される帯域幅）が想定される。より高い帯域幅のスタックに基づいた設計では、メモリ帯域幅を消費するために、より多くの並列性を組み込むであろう。
【０９０３】
図８４ａは、ＤＲＡＭダイ８３０１−８３０４のスタックを貫通する上部視点から配向されたアクセラレータ論理チップ８３０５の一実施例を示す。スタックＤＲＡＭチャネルブロック８４０５は、論理チップ８３０５をＤＲＡＭ８３０１−８３０４に接続するシリコンビアを表す図の中心に向いており、一方、メモリコントローラブロック７４１０は、ＤＲＡＭチャネルに対する制御信号を生成する論理を含む。８つのＤＲＡＭチャネル８４０５が図に示される一方、アクセラレータチップに実装されるチャネルの実際の数は、用いられるスタック型ＤＲＡＭに応じて変化する。開発中のスタックＤＲＡＭ技術のほとんどは、４つ又は８つのチャネルのいずれか一方を提供する。
【０９０４】
ドット積エンジン（ＤＰＥ）８４２０は、アーキテクチャの計算要素である。図８４ａ〜図８４ｂに示される特定の実施例において、８つのＤＰＥから成る各セットは、ベクトルキャッシュ８４１５と関連付けられる。図８５は、２つのバッファ８５０５−８５０６、２つの６４ビット積和演算ＡＬＵ８５１０及び制御論理８５００を含ＤＰＥの大まかな概観図を提供する。計算中、チップ制御ユニット８５００は、処理されるデータのチャンクをバッファメモリ８５０５−８５０６へとストリームする。一旦、各バッファが満杯になると、ＤＰＥの制御論理がバッファを通じて順序付けられ、それらが含むベクトルのドット積を計算し、その結果をＤＰＥの結果ラッチ８５１２に書き込み、他のＤＰＥの結果ラッチと共にデイジーチェーンに接続され、計算の結果をスタックＤＲＡＭ８３０１−８３０４に書き戻す。
【０９０５】
一実施例において、アクセラレータ論理チップは、（特定の動作周波数及び電圧が異なるアプリケーションに対して修正され得るが）電力消費を最小化するために、約１ＧＨｚ及び０．６５Ｖで動作する。１４ｎｍ設計研究に基づいた解析では、３２〜６４ＫＢのバッファがその電圧でこの周波数スペックを満たしていることを示しているが、弱いエラーを防止するためには強いＥＣＣが必要とされ得る。積和演算ユニットは、０．６５Ｖの供給電圧及び浅いパイプラインでのタイミングを満たすために、基本クロックレートの半分で動作され得る。２つのＡＬＵを用いて、ＤＰＥ毎に１つの倍精度の積和演算／サイクルのスループットを提供する。
【０９０６】
２７３ＧＢ／秒及び１．０６６ＭＨｚのクロックレートで、ＤＲＡＭスタック８３０１−８３０４は、論理チップのクロックサイクルあたり２５６バイトのデータを供給する。アレイインデックス及び値が、少なくとも３２ビットの量であると仮定すると、これは、１サイクルあたり３２個の疎行列成分（インデックスの４バイト＋値の４バイト＝８バイト／成分）に変換し、チップが、追従するために１サイクルあたり３２個の積和演算を実行することを要求する。（これは、行列−ベクトル乗算に対するものであり、１００％のスタックＤＲＡＭ帯域幅が行列をフェッチするために用いられるようなベクトルキャッシュ内の高いヒット率を前提としている）。図８４ａ及び図８４ｂに示される６４個のＤＰＥは、２−４ｘの必要な計算スループットを提供し、たとえ、ＡＬＵ８５１０が１００％の時間用いられていないとしても、チップが、ピークスタックＤＲＡＭ帯域幅で処理データすることを可能にする。
【０９０７】
一実施例において、ベクトルキャッシュ８４１５は、行列−ベクトル乗算内のベクトルの成分をキャッシュする。これは、以下で説明される行列−ブロッキングスキームの効率性を著しく向上させる。一実施例において、各ベクトルキャッシュブロックは、８つのチャネルアーキテクチャにおいて、２５６〜５１２ＫＢの総容量に対して、キャッシュの３２〜６４ＫＢを含む。
【０９０８】
チップ制御ユニット８４０１は、計算のフローを管理し、アクセラレータ内の他のスタック及びシステム内の他のソケットとの通信を処理する。複雑性及び電力消費を低減するために、ドット積エンジンが、メモリからデータを要求することは決してない。代わりに、チップ制御ユニット８４０１は、メモリシステムを管理し、データの適切なブロックをＤＰＥのそれぞれにプッシュする転送を開始する。
【０９０９】
一実施例において、マルチスタックアクセラレータ内のスタックは、図に示される隣接接続８４３１を用いて実装されるＫＴＩリンク８４３０のネットワークを介して互いに通信する。チップはまた、マルチソケットシステム内の他のソケットと通信するために用いられる３つの追加のＫＴＩリンクを提供する。マルチスタックアクセラレータにおいて、スタックのオフパッケージＫＴＩリンク８４３０のうちの１つだけがアクティブにされる。他のスタック上のメモリをターゲットとするＫＴＩトランザクションは、オンパッケージＫＴＩネットワークを介して適切なスタックに転送される。
【０９１０】
アクセラレータの一実施例についての疎行列−密ベクトル及び疎行列−疎ベクトル乗算を実装する技術及びハードウェアがここで説明される。これはまた、疎行列演算をサポートするアクセラレータを作成するために、行列−行列乗算、緩和演算及び他の機能をサポートするために拡張されることもできる。
【０９１１】
疎−疎及び疎−密行列−ベクトル乗算が、（行列及びベクトル内の各行のドット積を取る）同じ基本アルゴリズムを実行する一方、ベクトルが密である場合と比較して、それが疎である場合に、どのようにこのアルゴリズムが実装されるかについて著しい差があり、それは、以下のテーブルに要約されている。
【表４２】
0006988040.tif 000047
【０９１２】
疎行列−密ベクトル乗算において、ベクトルのサイズは固定され、行列内の列の数に等しい。科学技術計算で得られる行列の多くが、１行あたりおよそ１０個の非ゼロ要素が平均であるので、疎行列−密ベクトル乗算内のベクトルが行列自体の５〜１０％の空間を占めることは珍しくない。一方で、疎ベクトルは、多くの場合、かなり短く、行列の行に同様の数のゼロ以外の値を含んでおり、これらをンチップメモリ内にかなりキャッシュしやすくする。
【０９１３】
疎行列−密ベクトル乗算において、ベクトル内の各成分の位置は、そのインデックスにより判断され、それが行列の領域内のゼロ以外の値に対応するベクトル成分を収集し、行列が乗算される任意の密ベクトルに対して収集される必要があるベクトル成分のセットを予め計算することを実現可能にする。しかしながら、疎ベクトル内の各成分の位置は、予測不可能であり、ベクトル内のゼロ以外の成分の分散に依存する。これは、どの行列内のゼロ以外がベクトル内のゼロ以外の値に対応するかを判断するために、疎ベクトル及び行列の非ゼロ成分を検査する必要がある。
【０９１４】
疎行列−疎ベクトルのドット積を計算するために必要とされる命令／処理の数は、予測不可能であり、行列及びベクトルの構造に依存するので、行列及びベクトル内のゼロ以外の成分をインデックスと比較するのに役立つ。例えば、単一のゼロ以外の成分を有する行列の行と多くのゼロ以外の成分を有するベクトルとのドット積を取ることを検討する。行のゼロ以外の値が、ベクトル内のゼロ以外の値のいずれよりも低いインデックスを有する場合、ドット積は、１つのインデックス比較のみを必要とする。行のゼロ以外の値がベクトル内のゼロ以外の値のいずれより高いインデックスを有する場合、ドット積を計算することは、行のゼロ以外の値のインデックスとベクトル内の各インデックスとを比較する必要がある。これは、ベクトルを通じた線形探索を前提としており、一般的なやり方である。バイナリ探索など、他の探索は、最悪の場合においてより高速であろう。しかしながら、行及びベクトル内のゼロ以外の値が重複するよくある例において、著しいオーバヘッドを追加することになるであろう。一方、疎行列−密ベクトル乗算を実行するために必要とされるオペレーションの数が固定され、行列内のゼロ以外の値の数により判断されるので、計算に必要とされる時間を予測し易くする。
【０９１５】
これらの違いに起因して、アクセラレータの一実施例では、疎行列−密ベクトル及び疎行列−疎ベクトル乗算を実施するために同じ高水準なアルゴリズムを用いており、ベクトルがドット積エンジンにわたってどのように分配されるかについて、及び、ドット積がどのように計算についての差を有する。アクセラレータは、大きな疎行列計算を対象としているので、行列又はベクトルのいずれか一方がオンチップメモリに合致することができないと仮定される。代わりに、一実施例では、図８６に概説されるブロッキングスキームを用いる。
【０９１６】
特に、この実施例において、アクセラレータは、オンチップメモリに合致するようなサイズであり、データ８６０１−８６０２の固定サイズのブロックに行列を分割し、次のブロックに進む前に、出力ベクトルのチャンクを生成するために、ベクトルによりブロック内の行を乗算する。このアプローチは２つの課題をもたらす。第１に、疎行列の各行における非ゼロの数は、調査対象のデータセットの低くて１から高くても４６０００まで、データセット間で広く変化する。これは、１又は固定数の行を各ドット積エンジンに割り当てることを非実用的にしている。故に、一実施例では、行列データの固定サイズのチャンクを各ドット積エンジンに割り当て、チャンクが複数の行列の行を含む場合及び単一の行が複数のチャンクにわたって分割される場合に処理する。
【０９１７】
第２の課題は、行列のブロックごとにスタックＤＲＡＭからベクトル全体をフェッチすると、大量の帯域幅を無駄にする可能性があるということである（すなわち、ブロック内に対応する非ゼロがないベクトル成分をフェッチする）。これは、特に、疎行列−密ベクトル乗算に対する問題点であり、ベクトルは、疎行列のかなりの部分を占め得る。これに対処するために、一実施例は、行列内のブロック８６０１−８６０２ごとにフェッチリスト８６１１−８６１２を構成し、ブロック内のゼロ以外の値に対応するベクトル８６１０の成分のセットを列挙し、ブロックを処理する場合にそれらの成分をフェッチするだけである。フェッチリストはまた、スタックＤＲＡＭからフェッチされなければない一方、ほとんどのブロックに対するフェッチリストがブロックのごく一部を占めると判断されている。ランレングス符号化などの技術は、フェッチリストのサイズを低減するために用いられてもよい。
【０９１８】
したがって、アクセラレータ上の行列−ベクトル乗算は、オペレーションの以下のシーケンスに関する。
【０９１９】
１．ＤＲＡＭスタックから行列データのブロックをフェッチし、それをドット積エンジンにわたって分散する。
【０９２０】
２．行列データ内のゼロ以外の成分に基づいてフェッチリストを生成する。
【０９２１】
３．スタックＤＲＡＭからフェッチリスト内の各ベクトル成分をフェッチし、それをドット積エンジンに分散する。
【０９２２】
４．ベクトルを有するブロック内の行のドット積を計算し、スタックＤＲＡＭに結果を書き込む。
【０９２３】
５．計算と並列して、行列データの次のブロックをフェッチし、行列全体が処理されるまで繰り返す。
【０９２４】
アクセラレータが複数のスタックを含む場合、行列の「区分」は、異なるスタックに静的に割り当てられてよく、次に、ブロックアルゴリズムは、各区分に対して並列実行されてよい。このブロック及びブロードキャストスキームは、メモリ参照のすべてが中央制御装置から由来する利点を有しており、ネットワークは、予測不可能な要求及びドット積エンジンとメモリコントローラとの間の応答を転送する必要がないので、オンチップネットワークの設計を大幅に簡略化する。また、個別のドット積エンジンに、それらが計算のこれらの部分を実行する必要があるベクトル成分に対してメモリ要求を発行させることとは対照的に、所与のブロックが必要とするベクトル成分ごとに１つのメモリ要求のみを発行することによりエネルギーを節約する。最後に、インデックスの体系化されたリストからベクトル成分をフェッチすることは、それらがスタック型ＤＲＡＭにおけるページヒット、ひいては、帯域幅の利用を最大化する方式で要求をフェッチするメモリ要求をスケジューリングし易くする。
【０９２５】
本明細書で説明されるアクセラレータの実装で疎行列−密ベクトル乗算を実施する場合の１つの課題は、各ドット積エンジンのバッファにおいて行列成分のインデックスにメモリからストリーミングされるベクトル成分をマッチングさせることである。一実施例において、ベクトルの２５６バイト（３２〜６４成分）は、１サイクル毎にドット積エンジンに到達し、行列データの固定サイズのブロックが、各ドット積エンジンの行列バッファにフェッチされているので、各ベクトル成分は、ドット積エンジンの行列バッファ内の非ゼロのうちのいずれかに対応し得る。
【０９２６】
サイクルごとにそのほとんどの比較を実行することは、エリア及び電力において非常に高価であろう。代わりに、一実施例では、図８７に示されるフォーマットを用いて、多くの疎行列アプリケーションが、同じ又は異なるベクトルのいずれか一方により同じ行列を繰り返し乗算し、各ドット積エンジンが行列のそのチャンクを処理する必要があるフェッチリストの要素を予め計算するという事実を利用する。ベースラインＣＲＳフォーマットにおいて、行列は、その行内の各ゼロ以外の値の位置を定義するインデックス８７０２のアレイにより説明され、アレイは、各ゼロ以外の値８７０３及び各行が、インデックス及び値配列において開始する場所を示すアレイ８７０１を含む。そのために、一実施例では、各ドット積エンジンが全体的な計算のその一部を実行するためにキャプチャするのに必要なベクトルデータのバーストがどれかを識別するブロック記述子８７０５のアレイを加える。
【０９２７】
図８７に示されるように、各ブロック記述子は、８つの１６ビット値及びバースト記述子のリストからなる。最初の１６ビット値は、どれくらいの数バースト記述子がブロック記述子にあるかをハードウェアに示し、一方、残りの７つは、最初のものを除くスタックＤＲＡＭデータチャネルのすべてに対するバースト記述子のリスト内の開始ポイントを識別する。これらの値の数は、スタック型ＤＲＡＭが提供するデータチャネルの数に応じて変更する。各バースト記述子は、注意を払う必要があるデータのバーストがどれかをハードウェアに示す２４ビットのバーストカウント、及び、ドット処理エンジンが必要とする値を含むバースト内のワードを識別する「必要とされるワード」ビットベクトルを含む。
【０９２８】
一実施例に含まれる他のデータ構造は、行列バッファインデックス（ＭＢＩ）８７０４のアレイであり、行列内のゼロ以外毎に１つのＭＢＩである。各ＭＢＩは、ゼロ以外に対応する密ベクトル成分が関連するドット積エンジンのベクトル値バッファに格納される位置を与える（例えば、図８９を参照）。疎行列−密ベクトル乗算を実行する場合、元の行列インデックスではなくむしろ行列バッファインデックスは、ドット積エンジンの行列インデックスバッファ８７０４にロードされ、ドット積を計算する場合の対応するベクトル値を検索するために用いられるアドレスの代わりになる。
【０９２９】
図８８は、１つのスタック型ＤＲＡＭデータチャネル及び４ワードデータバーストのみを有するシステムにおいて、単一のドット積エンジンのバッファ内に合致する２行行列に対してこれがどのように作用するかを示す。行開始値８８０１、行列インデックス８８０２及び行列値８８０３を含む元のＣＲＳ表現が図の左側に示される。２行は、列｛２，５，６｝及び｛２，４，５｝内のゼロ以外の成分を有するので、ベクトルの成分２、４、５及び６がドット積を計算するために必要とされる。ブロック記述子は、これを反映し、第１の４ワードバーストのうちのワード２（ベクトルの成分２）及び第２の４ワードバーストのうちのワード０、１及び２（ベクトルの成分４−６）が必要とされることを示す。ベクトルの成分２は、ドット積エンジンが必要とするベクトルの第１のワードであるので、ベクトル値バッファ内の位置０に入る。ベクトルの成分４は、位置１などに入る。
【０９３０】
行列バッファインデックスアレイデータ８８０４は、ハードウェアが、行列内の非ゼロに対応する値を見つけたベクトル値バッファ内の位置を保持する。行列インデックスアレイ内の第１のエントリは、値「２」を有するので、行列バッファインデックスアレイ内の第１のエントリは、ベクトルの成分２がベクトル値バッファに格納される位置に対応する値「０」を取得する。同様に、「４」が行列インデックスアレイに現れるときはいつでも、「１」が行列バッファインデックスに現れ、行列インデックスアレイ内の各「５」は、行列バッファインデックス内で対応する「２」を有し、行列インデックスアレイ内の各「６」は、行列バッファインデックス内の「３」に対応する。
【０９３１】
本発明の一実施例は、行列がアクセラレータ上いロードされる場合、密ベクトルからの高速収集をサポートするのに必要な事前計算を実行し、マルチスタックアクセラレータの総帯域幅は、ＣＰＵからアクセラレータにデータを転送するために用いられるＫＴＩリンクの帯域幅よりはるかに大きいという事実を利用する。この事前計算された情報は、同じ行列インデックスの複数のコピーがドット積エンジン上にマッピングされる行列のチャンク内でどれくらい発生するかに応じて、最大で７５％まで行列を保持するために必要とされるメモリの量を向上させる。しかしながら、１６ビットの行列バッファインデックスアレイは、行列−ベクトル乗算が実行される場合、行列インデックスアレイの代わりにフェッチされるので、スタックＤＲＡＭからフェッチされるデータ量は、多くの場合、特に、６４ビットインデックスを用いる行列に関して、元のＣＲＳ表現より少ない。
【０９３２】
図８９は、このフォーマットを用いるドット積エンジン内のハードウェアの一実施例を示す。行列−ベクトル乗算を実行するために、ブロックを作成する行列のチャンクは、行列インデックスバッファ８９０３及び行列値バッファ８９０５にコピーされ（元の行列インデックスの代わりに行列バッファインデックスをコピーし）関連するブロック記述子は、ブロック記述子バッファ８９０２にコピーされる。次に、フェッチリストは、密ベクトルから必要な要素をロードして、これらをドット積エンジンにブロードキャストするために用いられる。各ドット積エンジンは、各データチャネルを過ぎるベクトルデータのバーストの数をカウントする。所与のデータチャネルのカウントが、バースト記述子において特定される値と一致する場合、マッチ論理８９２０は、特定されたワードをキャプチャして、これらをそのベクトル値バッファ８９０４に格納する。
【０９３３】
図９０は、このキャプチャを行うマッチ論理８９２０ユニットの内容を示す。ラッチ９００５は、カウンタがバースト記述子内の値と一致する場合、データチャネルのワイヤ上の値をキャプチャする。シフタ９００６は、バースト９００１から必要なワード９００２を抽出し、これらを、サイズがベクトル値バッファ内の行とマッチするラインバッファ９００７内の適切な位置に転送する。バーストカウント９００１が内部カウンタ９００４に等しい場合、ロード信号が生成される。ラインバッファが満杯になった場合、（ｍｕｘ９００８を通じて）ベクトル値バッファ８９０４に格納される。このように複数のバーストからラインにワードアセンブルすることで、ベクトル値バッファがサポートする必要がある書き込み／サイクルの数を低減し、そのサイズを低減する。
【０９３４】
一旦、ベクトルの必要な成分のすべてが、ベクトル値バッファ内にキャプチャされると、ドット積エンジンは、ＡＬＵ８９１０を用いて必要なドット積を計算する。制御論理８９０１は、サイクル毎に１成分の順番で行列インデックスバッファ８９０３及び行列値バッファ８９０４を通る。行列インデックスバッファ８９０３の出力は、次のサイクルでベクトル値バッファ８９０４に対する読み出しアドレスとして用いられ、一方、行列値バッファ８９０４の出力は、ベクトル値バッファ８９０４から対応する値と同時にＡＬＵ８９１０に到達するようにラッチされる。例えば、図８８からの行列を用いて、ドット積計算の第１のサイクルにおいて、ハードウェアは、行列値バッファ８９０５から値「１３」と共に行列インデックスバッファ８９０３から行列バッファインデックス「０」を読み出すであろう。第２のサイクルにおいて、行列インデックスバッファ８９０３からの値「０」は、ベクトル値バッファ８９０４に対するアドレスとしての機能を果たし、ベクトル成分「２」の値をフェッチし、次に、サイクル３において「１３」を乗算する。
【０９３５】
行開始ビットベクトル８９０１内の値は、いつ行列の行を終了して新しい行が開始するかをハードウェアに示す。ハードウェアが行の終了に到達した場合、その出力ラッチ８９１１に、行に対して累算されたドット積を配置し、次の行に対するドット積を累算することを開始する。各ドット積エンジンのドット積ラッチは、ライトバックのために出力ベクトルをアセンブルするデイジーチェーンに接続される。
【０９３６】
疎行列−疎ベクトル乗算において、ベクトルは、疎行列−密ベクトル乗算におけるものよりもはるかに少ないメモリを占有する傾向があるが、それが疎であるので、所与のインデックスに対応するベクトル成分を直接フェッチすることはできない。代わりに、ベクトルは、検索されなければならず、各ドット積エンジンが必要とする成分のみをドット積エンジンに転送することは実用的ではなく、各ドット積エンジンに割り当てられる行列データのドット積を計算するために必要とされる時間を予測不可能にする。これに起因して、疎行列−疎ベクトル乗算のためのフェッチリストは、行列ブロック内の最低及び最大のゼロ以外の成分のインデックスを規定するだけであり、それらのポイント間のベクトルのゼロ以外の成分のすべてがドット積エンジンにブロードキャストされなければならない。
【０９３７】
図９１は、疎行列−疎ベクトル乗算をサポートするドット積エンジン設計の詳細を示す。行列データのブロックを処理するために、インデックス（疎−密乗算に用いられる行列バッファインデックスではない）及び行列のドット積エンジンのチャンクの値は、行列インデックス及び値バッファに書き込まれ、ブロックを処理するために必要なベクトルの領域のインデックス及び値である。次に、ドット積エンジン制御論理９１４０は、インデックスバッファ９１０２−９１０３を通じて順序付けし、４×４コンパレータ９１２０に４つのインデックスのブロックを出力する。４×４コンパレータ９１２０は、ベクトル９１０２からのインデックスのそれぞれを、行列９１０３からのインデックスのそれぞれと比較し、任意の一致したバッファアドレスをマッチしたインデックスキュー９１３０に出力する。マッチしたインデックスキュー９１３０の出力は、行列値バッファ９１０５及びベクトル値バッファ９１０４の読み出しアドレス入力を駆動し、その一致に対応する値を積和演算ＡＬＵ９１１０に出力する。このハードウェアは、マッチしたインデックスキュー９１３０が空きスペースを有する限り、少なくとも４つで、１サイクルあたり８つのインデックスをドット積エンジンが消費することを可能にし、インデックスのマッチングがまれである場合に、データのブロックを処理するために必要とされる時間を低減する。
【０９３８】
疎行列−密ベクトルドット積エンジンと同様に、行開始９１０１のビットベクトルは、行列の新たな行を開始する行列バッファ９１０２−９１０３内のエントリを識別する。そのようなエントリが遭遇された場合、制御論理９１４０は、ベクトルインデックスバッファ９１０２の先頭にリセットし、これらの最低値からベクトルインデックスを検査することを開始することで、行列インデックスバッファ９１０３の出力とこれらを比較する。同様に、ベクトルの最後に到達した場合、制御論理９１４０は、行列インデックスバッファ９１０３内の次の行の先頭に進み、ベクトルインデックスバッファ９１０２の先頭にリセットする。「行われた」出力は、ドット積エンジンがデータのブロック又はベクトルの領域の処理を終了したときにチップ制御ユニットに知らせ、次のものに進む準備をする。アクセラレータの一実施例を簡略化するために、制御論理９１４０は、ドット積エンジンのすべてが処理を終了するまで、次のブロック／領域に進まない。
【０９３９】
多くの場合、ベクトルバッファは、ブロックを処理するために必要とされる疎ベクトルのすべてを保持するのに十分な大きさである。一実施例において、１０２４個又は２０４８個のベクトル成分に対するバッファ空間が、３２が用いられるか、又は、６４ビット値が用いられるかに応じて提供される。
【０９４０】
ベクトルの必要な要素がベクトルバッファに適合しない場合、マルチパスアプローチが用いられてよい。制御論理９１４０は、ベクトルの完全なバッファを各ドット積エンジンにブロードキャストし、その行列バッファ内の行を通じて反復することを開始する。行の最後に到達する前に、ドット積エンジンがベクトルバッファの最後に到達した場合、ベクトルの次の領域が到達したときの行を処理することを再開しなければならない場所を示すべく、現在の行位置のビットベクトル９１１１にビットを設定し、行の開始が、ここまで処理されてきたベクトルインデックスのいずれより高いインデックス値を有する限り、行の開始に対応する行列値バッファ９１０５の位置において累算された部分的なドット積を保存し、次の行に進む。行列バッファ内の行のすべてが処理された後に、ドット積エンジンは、ベクトルの次の領域を要求するためにその終了した信号をアサートし、ベクトル全体が読み出されるまで処理を繰り返す。
【０９４１】
図９２は、特定の値を用いる例を示す。計算の開始時に、行列の４つの成分のチャンクは、行列バッファ９１０３、９１０５に書き込まれ、ベクトルの４つの成分の領域は、ベクトルバッファ９１０２、９１０４に書き込まれている。行開始９１０１及び現在の行の位置ビット−ベクトル９１０６の両方は、「１０１０の値」を有し、行列のドット積エンジンチャンクが２つの行、行列バッファ内の第１の成分において開始するもののうちの１つ、及び、第３の成分で開始するもののうちの１つを含むことを示す。
【０９４２】
第１の領域が処理される場合、チャンク内の第１行は、インデックス３におけるインデックスのマッチングを参照し、行列及びベクトルバッファの対応する要素の積（４×１＝４）を計算し、行の開始に対応する行列値バッファ９１０５の位置にその値を書き込む。第２行は、インデックス１における１つのインデックスのマッチングを参照し、ベクトル及び行列の対応する成分の積を計算し、その開始に対応する位置における行列値バッファ９１０５に結果（６）を書き込む。現在の行位置のビットベクトルの状態は、各行の第１の成分が処理されており、計算が第２の成分を用いて再開すべきであることを示す「０１０１」に変更する。次に、ドット積エンジンは、その終了ラインをアサートして、ベクトルの別の領域に対する準備が整ったことをシグナリングする。
【０９４３】
ドット積エンジンがベクトルの第２の領域を処理する場合、それは、行１がインデックス４におけるインデックスのマッチングを有することを参照し、行列及びベクトルの対応する値の積（５×２＝１０）を計算し、その値を、第１のベクトル領域が処理された後に保存されている部分的なドット積に加算し、その結果（１４）を出力する。図に示されるように、第２行は、インデックス７における一致を見つけて、結果３８を出力する。このように、部分的なドット積及び計算の状態を保存することで、部分的な積に対する大量の追加のストレージを要求することなく、（ベクトルが、昇順でインデックスを用いてソートされているので）ベクトルの後の領域においてインデックスを一致させることができない可能性がある行列の冗長的な作業処理要素を回避する。
【０９４４】
図９３は、両方のタイプの計算を処理できるドット積エンジンを生じさせるために、上記で説明された疎−密及び疎−疎ドット積エンジンがどのように組み合わせられるかを示す。２つの設計間で類似点を考慮すると、唯一の必要な変更は、疎−密ドット積エンジンのマッチ論理９３１１及び疎−疎ドット積エンジンのコンパレータ９３２０の両方と、マッチしたインデックスキュー９３３０とを、どのモジュールが読み出しアドレスを駆動し、バッファ９１０４−９１０５、及び、行列値バッファの出力又は行列値バッファのラッチされた出力が積和演算ＡＬＵ９１１０に送信されるかを選択するマルチプレクサ９３５１のデータ入力を書き込むかを判断するマルチプレクサ９３５０のセットと共にインスタンス化することである。一実施例において、これらのマルチプレクサは、行列−ベクトル乗算の開始時に設定される制御ユニット９１４０内の構成ビットにより制御され、オペレーション全体を通じて同じ構成に維持される。
【０９４５】
単一のアクセラレータスタックは、疎行列演算上のサーバＣＰＵに相当する性能を実現させており、スマートフォン、タブレット及び他のモバイルデバイスに対してアクセラレータに魅力的にする。例えば、１又は複数のサーバ上でモデルをトレーニングし、次に、到着したデータストリームを処理するために、モバイルデバイス上にそれらのモデルを展開する機械学習アプリケーションに関する多数の提案がある。モデルは、これらをトレーニングするために用いられるデータセットよりはるかに小さい傾向があるので、単一のアクセラレータスタックの制限された容量は、これらのアプリケーションにおいてそれほど制限されることはなく、一方、アクセラレータの性能及び電力効率は、モバイルデバイスが、これらプライマリＣＰＵ上で実現可能なものよりもはるかに複雑なモデルを処理することを可能する。非モバイルシステムに対するアクセラレータは、極めて高帯域幅かつ高性能を実現させるべく、複数のスタックを組み合わせる。
【０９４６】
マルチスタック実装についての２つの実施例が図９４ａ及び図９４ｂに示される。これらの実施例の両方では、現代のサーバＣＰＵとのピン互換性のあるパッケージ上にいくつかのアクセラレータスタックを統合する。図９４ａは、１２個のアクセラレータスタック９４０１−９４１２とのソケット交換の実装を示し、図９４ｂは、プロセッサ／コアのセット９４３０（例えば、低コアカウントＸｅｏｎ）及び８つのスタック９４２１−９４２４を用いたマルチチップパッケージ（ＭＣＰ）の実装を示す。図９４ａ内の１２個のアクセラレータスタックは、現在のパッケージで用いられる３９ｍｍ×３９ｍｍのヒートスプレッダの条件下で合致するアレイに置かれ、一方、図９４ｂにおける実施例では、同じフットプリント内で８つのスタック及びプロセッサ／コアのセットを組み込む。一実施例において、スタックに用いられる物理的な次元は、８ＧＢ  ＷＩＯ３スタック用の次元である。他のＤＲＡＭ技術は、異なる次元を有してよく、パッケージに合致するスタックの数を変更してよい。
【０９４７】
これらの実装の両方は、ＣＰＵとアクセラレータとの間のＫＴＩリンクを介した低レイテンシなメモリベースの通信を提供する。Ｘｅｏｎ実装に関するソケット交換設計は、マルチソケットシステム内のＣＰＵの１又は複数を置換え、９６ＧＢの容量及び３．２ＴＢ／ｓのスタックＤＲＡＭ帯域幅を提供する。予期される電力消費は９０Ｗであり、Ｘｅｏｎソケットのパワーバジェットの範囲内である。ＭＣＰのアプローチは、６４ＧＢの容量及び２．２ＴＢ／ｓの帯域幅を提供する一方、アクセラレータにおいて、６０Ｗの電力を消費する。これにより、中規模のＸｅｏｎ  ＣＰＵをサポートするのに十分な、１ソケットあたり１５０Ｗのパワーバジェットを想定すると、ＣＰＵに対して９０Ｗが残る。詳細なパッケージ設計が、パッケージ内により多くの論理用空間を可能にする場合、追加のスタック又はより多くの強力なＣＰＵが用いられ得るが、これは、ソケットのパワーバジェット内に総電力消費を保持するために、Ｘｅｏｎ+ＦＰＧＡのハイブリッド部分に関して研究されているコアパーキング技術などのメカニズムを必要とするであろう。
【０９４８】
これらの設計の両方は、シリコンインターポーザ又は他の精巧な統合技術を必要とすることなく実装され得る。現在のパッケージで用いられている有機基板は、ダイの周囲の１ｃｍあたりおよそ３００個の信号を許容し、中間スタックＫＴＩネットワーク及びオフパッケージＫＴＩリンクをサポートするのに十分である。スタック型ＤＲＡＭ設計は、冷却が問題になるまえに、〜１０Ｗの電力を消費する論理チップを典型的にはサポートでき、これは、２５６ＧＢ／秒の帯域幅のを提供するスタックに対する２Ｗの論理ダイ電力の推定を十分に超える。最後に、マルチチップパッケージは、現在の設計と整合する配線用のチップ間に１〜２ｍｍの空間を必要とする。
【０９４９】
実施例では、ＰＣＩｅカード上に、及び／又は、ＤＤＲ４−Ｔベースのアクセラレータを用いて実装されてもよい。ＰＣＩｅカードに対して３００Ｗの電力制限は、３２０ＧＢの総容量及び１１ＴＢ／秒の帯域幅に対して４０個のアクセラレータスタックをカードがサポートすることを可能にすることを想定している。しかしながら、ＰＣＩｅチャネルのレイテンシが長く帯域幅が制限されているということが、ＰＣＩｅベースのアクセラレータを、ＣＰＵとの頻繁でないインタラクションでしか必要としないという大きな問題に制限する。
【０９５０】
代替的に、アクセラレータスタックは、図９５に示されるように、ＤＤＲ−Ｔ  ＤＩＭＭベースのアクセラレータ９５０１−９５１６を実装するために用いられ得る。ＤＤＲ−Ｔは、ＤＤＲ４ソケット及びマザーボードとの互換性を有するように設計されたメモリンタフェースである。ＤＤＲ４と同じピン配列及びコネクタフォーマットを用いて、ＤＤＲ−Ｔは、異なるタイミング特性を有するメモリデバイスの使用を可能にするトランザクションベースのインタフェース９５００を提供する。この実施例において、アクセラレータスタック９５０１−９５１６は、計算を実行するために用いられていない場合にシンプルなメモリとして動作する。
【０９５１】
１２６〜２５６ＧＢのメモリ容量及び４〜８ＴＢ／秒の総帯域幅を考慮して、カードの両面が用いられる場合、ＤＤＲ−Ｔ  ＤＩＭＭは、１６個のアクセラレータスタック又は３２個のアクセラレータスタックにとって十分な空間を提供する。しかしながら、そのようなシステムは、ＤＤＲ４−ＤＩＭＭにより消費される〜１０Ｗよりはるかに多い１２０〜２４０ワットの電力を消費するであろう。これは、マザーボード上のＤＩＭＭごとに割り当てられる制限された空間に合致させることを困難にするアクティブな冷却を必要とするであろう。さらに、ＤＤＲ−Ｔベースのアクセラレータは、ユーザが、アクセラレーション用の任意のＣＰＵ性能を諦めようとせず、ファン又は他の冷却システムに関するアクセラレータＤＩＭＭ間に十分な空間を含めるカスタムマザーボード設計のコストを進んで払うアプリケーションにとっては魅力的であり得る。
【０９５２】
一実施例において、マルチスタックアクセラレータ内のスタックは、別個のＫＴＩノードに分けられ、システムソフトウェアにより別々のデバイスとして管理される。システムファームウェアは、存在するアクセラレータスタックの数に基づいて、ブート時間において静的にマルチスタックアクセラレータ内のルーティングテーブルを判断しており、トポロジを一意に判断すべきである。
【０９５３】
一実施例において、アクセラレータに対する低レベルインタフェースは、ソケットベースのアクセラレータに関するその適切性に起因して、アクセラレータ抽象化層（ＡＡＬ）ソフトウェアを用いて実装される。アクセラレータは、コアキャッシュインタフェース仕様（ＣＣＩ）により説明されるようなキャッシングエージェントを実装してよく、ホストシステムによりアクセス可能でないアクセラレータ（すなわち、キャッシングエージェント＋プライベートキャッシュメモリ構成、例えば、ＣＡ＋ＰＣＭ）に対するプライベート（非コヒーレントな）メモリとしてのスタック型ＤＲＡＭを処理する。ＣＣＩ仕様は、アクセラレータを制御するドライバにより用いられるアクセラレータごとに別々のコンフィグ／ステータスレジスタ（ＣＳＲ）アドレス空間を義務付けている。その仕様に従って、各アクセラレータは、デバイスステータスメモリ（ＤＳＭ）を介してホストにそのステータスを通信し、ピニングされたメモリ領域は、アクセラレータのステータスを示すために用いられるホストメモリにマッピングされている。したがって、１２スタックシステムにおいて、単一の統合されたドライバエージェントにより管理される１２個の別個のＤＳＭ領域がある。これらのメカニズムは、スタックごとにコマンドバッファを作成するために用いられてよい。コマンドバッファは、システムメモリにマッピングされたピニングされたメモリ領域であり、ＡＡＬドライバにより管理される循環キューとして実装される。ドライバは、各スタックのコマンドバッファにコマンドを書き込み、各スタックは、その専用のコマンドバッファからアイテムを消費する。したがって、コマンドの生産及び消費は、この実施例においてデカップリングされる。
【０９５４】
例として、ホストＣＰＵに接続される単一のアクセラレータスタックから構成されるシステムを考慮する。ユーザは、コードを書き込んで以下の計算を実行する。ｗｎ＋１＝ｗｎ−αＡｗｎ。Ａは行列であり、ｗｘはベクトルである。ソフトウェアフレームワーク及びＡＡＬドライバは、このコードを以下のシーケンスコマンドにデコンポーズする。
【０９５５】
ＴＲＡＮＳＭＩＴ−一連の区分（ｗｎ＋１、ｗｎ、α、Ａ）をプライベートキャッシュメモリにロードする。
【０９５６】
ＭＵＬＴＩＰＬＹ−一連の区分（ｔｍｐ＝ｗｎ×α×Ａ）を乗算する。
【０９５７】
ＳＵＢＴＲＡＣＴ−一連の区分（ｗｎ＋１＝ｗｎ−ｔｍｐ）をサブミットする。
【０９５８】
ＲＥＣＥＩＶＥ−結果（ｗｎ＋１）を含むホストメモリに一連の区分を格納する。
【０９５９】
これらのコマンドは、ホスト又はプライベートキャッシュメモリのいずれか一方に配置される「区分」、データの粗粒度（およそ１６ＭＢ〜５１２ＭＢ）単位で演算を行う。区分は、ＭａｐＲｅｄｕｃｅ又はＳｐａｒｋ分散コンピューティングシステムが、アクセラレータを用いて分散された計算の加速を容易にするために用いるデータのブロック上に容易にマッピングすることを目的としている。ＡＡＬドライバは、ホストメモリ領域又はアクセラレータスタックに対する区分についての静的な１対１のマッピングを作成する役割を担う。アクセラレータスタックは、それぞれ個々に、これらのプライベートキャッシュメモリ（ＰＣＭ）アドレス空間に対して、これら割り当てられた区分をマッピングする。区分は、一意的な識別子である区分インデックス、さらに（ホストメモリに配置された区分に対して）対応するメモリ領域及びデータフォーマットにより表現される。ＰＣＭ内に配置された区分は、中央制御装置により管理され、区分に対するＰＣＭアドレス領域を判断する。
【０９６０】
一実施例において、アクセラレータのＰＣＭを初期化するために、ホストは、ホストメモリからデータをロードするようアクセラレータに指示する。ＴＲＡＮＳＭＩＴオペレーションは、アクセラレータにホストメモリを読み出させて、読み出したデータをアクセラレータのＰＣＭに格納させる。送信されるデータは、一連の｛区分インデックス、ホストメモリ領域、データフォーマット｝のタプルにより説明される。データのオーバヘッドがホストドライバによりまとめられることを回避するために、アクセラレータは、システムプロトコル２（ＳＰＬ２）共有仮想メモリ（ＳＶＭ）を実装してよい。
【０９６１】
各タプルにおけるデータフォーマットは、メモリ内の区分のレイアウトを表現する。アクセラレータがサポートするフォーマットの例は、圧縮された疎行（ＣＳＲ）及び多次元密アレイである。上記の例に関して、Aは、ＣＳＲフォーマットにあってよく、他方、ｗｎはアレイフォーマットにあってよい。コマンドの仕様は、ＰＣＭにＴＲＡＮＳＭＩＴオペレーションにより参照される区分をすべてロードするようアクセラレータに指示するために必要な情報及びホストメモリアドレスを含む。
【０９６２】
各オペレーションは、一連の区分の形式で少数のオペランドを参照してよい。例えば、乗算演算は、アクセラレータに、スタック型ＤＲＡＭを読み出させ、行列−ベクトル乗算を実行させる。故に、この例では、４つのオペランド、すなわち、宛先ベクトルｔｍｐ、乗算器Ａ、被乗数ｗｎ及びスカラαを有する。宛先ベクトルｔｍｐは、オペレーションを含むコマンドの一部として、ドライバにより特定される一連の区分に累算される。コマンドは、必要な場合、一連の区分を初期化するようアクセラレータに指示する。
【０９６３】
ＲＥＣＥＩＶＥオペレーションは、アクセラレータに、ＰＣＭを読み出させ、ホストメモリを書き込ませる。このオペレーションは、すべての他のオペレーション上の選択的なフィールドとして実装されてよく、ホストメモリに結果を格納する指示を用いてＭＵＬＴＩＰＬＹなどの演算を実行するようにコマンドを潜在的に融合する。ＲＥＣＥＩＶＥオペレーションの宛先オペランドは、オンチップに累算され、次に、ホストメモリ内の区分にストリーミングされ、（アクセラレータがＳＰＬ２  ＳＶＭを実装しない限り）コマンドのディスパッチの前に、ドライバによりピニングされなければならない。
【０９６４】
コマンドのディスパッチフロー
【０９６５】
一実施例において、スタック用のコマンドバッファにコマンドを挿入した後に、ドライバは、消費される新たなコマンドをスタックに通知するために、ＣＳＲ書き込みを生成する。ドライバによるＣＳＲ書き込みは、アクセラレータスタックの中央制御装置により消費され、スタックに対してドライバによりディスパッチされたコマンドを読み出すために、コマンドバッファに対する一連の読み出しを制御ユニットに生成させる。アクセラレータスタックがコマンドを完了した場合、ステータスビットをそのＤＳＭに書き込む。ＡＡＬドライバは、コマンドの完了を判断するために、これらのステータスビットをポーリング又はモニタリングのいずれか一方を行う。ＤＳＭへのＴＲＡＮＳＭＩＴ又はＭＵＬＴＰＬＹオペレーションに関する出力は、完了を示すステータスビットである。ＲＥＣＥＩＶＥオペレーションに関して、ＤＳＭへの出力は、ホストメモリに書き込まれるステータスビット及び一連の区分である。ドライバは、アクセラレータにより書き込まれるメモリの領域を識別する役割を担う。スタック上の制御ユニットは、スタック型ＤＲＡＭへの一連の読み出し処理及びホストメモリ内の宛先の区分への対応する書き込みを生成する役割を担う。
【０９６６】
ソフトウェアイネーブル
【０９６７】
一実施例において、ユーザは、ルーチンのライブラリを呼び出して、データをアクセラレータ上に移動し、疎行列計算を実行するなどを行うことにより、アクセラレータとインタラクトする。このライブラリに対するＡＰＩは、既存のアプリケーションを修正して、アクセラレータを利用するために必要とされる労力を低減するために、既存の疎行列ライブラリと可能な限り同様であり得る。ライブラリベースのインタフェースの別の利点は、アクセラレータ及びそのデータフォーマットの詳細を隠すことであり、プログラムが、ランタイムでライブラリの訂正バージョンを動的に連結することにより異なる実装を利用することを可能にする。ライブラリは、Ｓｐａｒｋのような分散コンピューティング環境からアクセラレータを呼び出すために実装されてもよい。
【０９６８】
アクセラレータスタックのエリア及び電力消費は、モジュール（メモリ、ＡＬＵなど）に設計を分割すること、及び、同様の構造の１４ｎｍ設計からデータを収集するにより推定されてよい。１０ｎｍプロセスにスケールするために、５０％のエリアの削減が、２５％のＣｄｙｎの削減及び２０％の漏れ電力の削減と共に想定され得る。エリアは、すべてのオンチップメモリ及びＡＬＵを含むと推定する。ワイヤが、論理／メモリ上を走るものと仮定する。電力推定は、ＡＬＵ及びメモリに対するアクティブなエネルギー、メモリに対する漏れ電力、我々の主要なネットワーク所のワイヤ電力を含む。１ＧＨｚのベースクロックレートが想定されていて、１４ｎｍ及び１０ｎｍプロセスの両方において、０．６５Ｖの供給電圧であった。上記ですでに述べたように、ＡＬＵは、基本クロックレートの半分で実行してよく、これは、電力予測において考慮されるものとする。ＫＴＩリンク及び中間スタックネットワークは、アクセラレータが計算を実行している場合にアイドル又はほぼアイドルであると予測されるので、電力推定に含まれていない。一実施例では、これらのネットワークでのアクティビティを追跡し、これらを電力推定に含める。
【０９６９】
当該推定は、本明細書で説明されるようなアクセラレータが、１４ｎｍプロセスにおけるチップ面積の１７ｍｍ２及び１０ｎｍプロセスにおける８．５ｍｍ２を占有すると予測し、チップ面積の大部分がメモリにより占有されている。図９６は、６４個のドット積エンジン８４２０、８個のベクトルキャッシュ８４１５及び統合メモリコントローラ８４１０を含むＷＩＯ３  ＤＲＡＭスタックの下に位置することを目的とするアクセラレータの潜在的なレイアウトを示す。示されるＤＲＡＭスタックＩ／Ｏバンプ９６０１、９６０２のサイズ及び配置は、ＷＩＯ３標準により規定されており、アクセラレータ論理は、これらの間の空間に合致する。しかしながら、アセンブリを簡単にするために、ＤＲＡＭスタックの下方の論理ダイは、少なくともＤＲＡＭダイとほぼ同じ大きさとすべきである。故に、実際のアクセラレータチップは、およそ８ｍｍ〜１０ｍｍであるが、エリアのほとんどが未使用であろう。一実施例において、この未使用のエリアは、帯域幅が制限されたアプリケーションの異なるタイプに関するアクセラレータに用いられ得る。
【０９７０】
スタック型ＤＲＡＭは、その名称が示唆するように、より高い帯域幅、計算ダイとのより密接な物理的統合、ＤＤＲ４  ＤＩＭＭなどの従来のＤＲＡＭモジュールより低いエネルギー／ビットを実現させるために、複数のＤＲＡＭダイを鉛直にスタックするメモリ技術である。図９７におけるテーブルでは、７つのＤＲＡＭ技術、すなわち、非スタック型ＤＤＲ４及びＬＰＤＤＲ４、ピコモジュール、ＪＥＤＥＣ標準の高帯域幅（ＨＢＭ２）及びワイドＩ／Ｏ（ＷＩＯ３）スタック、スタック型ＤＲＡＭ、並びに、崩壊型ＲＡＭ（ｄｉｓ−ｉｎｔｅｇｒａｔｅｄ  ＲＡＭ、ＤｉＲＡＭ）を比較する。
【０９７１】
スタック型ＤＲＡＭは、２種類の形式、すなわち、オンダイ及び横側ダイがある。オンダイスタック８３０１−８３０４は、図９８ａに示されるように、スルーシリコンビアを用いて、論理ダイ又はＳｏＣ８３０５に直接的に接続する。一方、横側ダイスタック８３０１−８３０４は、図９８ｂに示されるように、シリコンインターポーザ又はブリッジ９８０２上の論理／ＳｏＣダイ８３０５の横に置かれており、インターポーザ９８０２及びインタフェース層９８０１を通じて走るＤＲＡＭと論理ダイとの間の接続を有する。オンダイＤＲＡＭスタックは、それらが横側ダイスタックより小さいパッケージを可能にするという利点を有するが、１より多くのスタックを論理ダイに取り付けることが難しく、それらがダイ毎に提供できるメモリの量を制限するという短所を有する。一方、シリコンインターポーザ９８０２の使用は、論理ダイが、エリア内によってはいくらかのコストはあるが、複数の横側ダイスタックと通信することを可能にする。
【０９７２】
ＤＲＡＭについての２つの重要な特性は、それらがパッケージに合致する帯域幅及びその帯域幅を消費するために必要とされる電力を定義するといったような、１スタックあたりの帯域幅及び１ビットあたりのエネルギーである。ピコモジュールだと、十分な帯域幅を提供せず、ＨＢＭ２のエネルギー／ビットが電力消費を著しく上昇させるので、これらの特性は、ＷＩＯ３、ＩＴＲＩ及びＤｉＲＡＭを、本明細書で説明されるようなアクセラレータに対して最も期待できる技術にする。
【０９７３】
それら３つの技術について、ＤｉＲＡＭは、最も高い帯域幅及び容量並びに最も低いレイテンシを有しているので、非常に魅力的である。ＷＩＯ３は、ＪＥＤＥＣ標準になることが想定されるさらなる別の有望なオプションであり、良好な帯域幅及び容量を提供する。ＩＴＲＩメモリは、３つのうちで最も低いエネルギー／ビットを有しており、より多くの帯域幅が所与のパワーバジェットに合致することを可能にする。それはまた、レイテンシが低く、そのＳＲＡＭのようなインタフェースは、アクセラレータのメモリコントローラについての複雑性を低減するであろう。しかしながら、ＩＴＲＩ  ＲＡＭは、３つのうちで最も容量が小さく、その設計は、性能に関して容量とトレードオフになる。
【０９７４】
本明細書で説明されるアクセラレータは、コア疎行列ベクトル乗算（ＳｐＭＶ）プリミティブ上に構築されるデータ解析及び機械学習アルゴリズムに取り組むために設計される。ＳｐＭＶは、多くの場合、これらのアルゴリズムのランタイムを支配する一方、他のオペレーションは、同様にこれらを実装するために必要とされる。
【０９７５】
例として、図９９に示される幅優先探索（ＢＦＳ）のリストを検討する。この例では、ワークのバルクがライン４上のＳｐＭＶにより実行されている。しかしながら、ベクトル−ベクトル減算（ライン８）、内積演算（ライン９）及びデータ並列マップオペレーション（ライン６）もある。ベクトルの減算及び内積は、ベクトルＩＳＡにおいて一般にサポートされている比較的単純な演算であり、説明をほとんど必要としない。
【０９７６】
一方、データ並列マップオペレーションは、プログラミング性を概念的に要素単位のオペレーションに導入するので、はるかに興味深いものである。ＢＦＳの例は、一実施例のマッピング機能により提供されるプログラミング性を明らかにする。特に、ＢＦＳにおけるラムダ関数（図９９のライン６を参照）は、頂点が最初にアクセスされていたときのトラックを保持するために用いられる。これは、ラムダ関数に２つのアレイ及び１つのスカラを渡すことにより一実施例において行われる。ラムダ関数に渡される第１のアレイは、ＳｐＭＶ演算の出力であり、どの頂点が現在到達可能であるかを反映する。第２のアレイは、値が、頂点が最初に見られた反復数である、又は、頂点がまだ到達していない場合は０である頂点ごとにエントリを有する。ラムダ関数に渡されるスカラは、単純なループ反復カウンタである。一実施例において、ラムダ関数は、出力ベクトルを生成するために入力ベクトルの各成分に対して実行される一連のスカラ演算にコンパイルされる。
【０９７７】
ＢＦＳに関する一連のオペレーションの中間表現（ＩＲ）が図９９に示される。ＢＦＳラムダＩＲは、いくつかの興味深い特性を明らかにする。生成されたラムダコードは、単一の基本ブロックのみを有することが保証されている。一実施例では、ラムダ関数における反復的な構築を防止し、制御フローを回避するためにｉｆ変換（ｉｆ-ｃｏｎｖｅｒｓｉｏｎ）を実行する。この制約は、一般的な制御フローをサポートする必要はなので、ラムダを実行するために用いられる計算構造の複雑性を著しく低減させる。
【０９７８】
すべてのメモリオペレーションは、基本ブロックの開始（図９９のライン２から４）で実行される。アセンブリに変換された場合、メモリオペレーションは、コードレット（ｃｏｄｅｌｅｔ）のプリアンブル（ライン２から５）に引き上げられる（ｈｏｉｓｔｅｄ）。
【０９７９】
統計値の評価は、ラムダ関数を使用するアクセラレータと共に実装されるベンチマークに関して実行されていた。命令の数が記録されており、レジスタの総数及び関心のある様々なラムダ関数の「複雑性」を定量化するロードの総数であった。さらに、クリティカルパス長は、各ラムダ関数における従属命令の最も長いチェーンを反映する。命令の数が、クリティカルパスよりも著しく長い場合、命令−レベル並列性技術は、性能を向上させるために適用可能な解決手段である。いくつかのロードは、マッピングの所与の呼び出し又は低減コールに関して不変である（ラムダ関数のすべての実行が同じ値をロードする）。この状況は、「ラムダ不変ロード」と称され、それを検出するために解析が実行される。
【０９８０】
解析結果に基づいて、比較的少ない命令格納は、ラムダ関数の実行をサポートするレジスタファイルを必要とする。並行処理（複数のラムダ関数の実行をインタリーブする）を向上させる技術は、レジスタファイルのサイズ及び複雑性を改善する。しかしながら、ベースライン設計は、わずか１６エントリであり得る。さらに、比較及び条件移動オペレーションで使用するために単一ビット述語レジスタファイルも提供されている場合、２Ｒ１Ｗレジスタファイルは、すべてのオペレーションに対して十分なはずである。
【０９８１】
以下で説明されるように、ラムダ不変ロードは、ギャザーエンジンにおいて実行され、その結果、それらは、ラムダ関数を呼び出す毎に一度実行されるだけである。これらのロードにより返される値は、それらが、必要に応じてラムダデータパスのローカルレジスタファイルに読み出され得るように処理要素に渡される。
【０９８２】
一実施例において、ラムダ関数の実行は、各ユニットの異なる機能を活用するために、ギャザーエンジンとプロセッサ要素（ＰＥ）（例えば、上記で説明されたようなドット積エンジン）との間で分割される。ラムダ関数は、３つのタイプの引数、すなわち、定数、スカラ及びベクトルを有する。定数は、値がコンパイル時に判断され得る引数である。スカラ変数は、上記で説明されたラムダ不変ロードに対応し、ラムダ関数の呼び出し間で値が変化する引数であるが、所与のラムダ関数が動作する要素のすべてにわたって定数を維持する。ベクトル引数は、ラムダ関数が処理するデータのアレイであり、当該関数における命令をベクトル引数内の各要素に適用する。
【０９８３】
一実施例において、ラムダ関数は、当該関数を実装するコード、当該関数が参照する任意の定数、及び、その入出力変数に対するポインタを含む記述子データ構造により規定される。ラムダ関数を実行するために、最上位のコントローラは、ラムダ関数の記述子と、ギャザーエンジン及びその関連するＰＥが処理するためのものである関数のベクトル引数の一部の開始及び終了インデックスとを規定する１又は複数のギャザーエンジンにコマンドを送信する。
【０９８４】
ギャザーエンジンがコマンドを受信してラムダ関数を実行する場合、記述子の最後のセクションに到達するまで、メモリから関数の記述子をフェッチして、当該関数のスカラ変数のアドレスを含む当該記述子をその関連するＰＥに渡す。次に、メモリから関数のスカラ変数のそれぞれをフェッチして、記述子内の各引数のアドレスをその値と置換え、修正した記述子をＰＥに渡す。
【０９８５】
ＰＥが、そのギャザーエンジンから関数記述子の開始を受信した場合、それは、関数のベクトル入力のアドレスを制御レジスタにコピーし、ＰＥのフェッチハードウェアは、ＰＥのローカルバッファにベクトル入力のページをロードすることを開始する。次に、ラムダ関数を実装する命令のそれぞれをデコードし、その結果を、小型のデコードされた命令バッファに格納する。次に、ＰＥは、関数のスカラ変数の値がそのギャザーエンジンから到着するのを待ち、関数のベクトル引数のそれぞれの第１のページが、メモリから到着するのを待つ。関数の引数が到着すると、ＰＥは、入力ベクトルのその範囲内の各成分にラムダ関数を適用することを開始し、ＰＥのフェッチ及びライトバックハードウェアに依存して、入力データのページをフェッチし、必要に応じて、出力値のページをライトバックする。ＰＥが、データの割り当てられる範囲の最後に達した場合、それが行われる最上位のコントローラをシグナリングし、別の処理を開始する準備を行う。
【０９８６】
図１００は、一実施例に従うラムダ関数を規定するために用いられる記述子のフォーマットを示す。特に、図１００は、メモリ１０００１内のラムダ記述子フォーマットと、ＰＥ１０００２に渡されるラムダフォーマット記述子とを示す。命令を除く記述子内のすべてのフィールドは、６４ビット値である。命令は、３２ビット値であり、２つが６４ビットワードにパックされる。記述子は、スカラ変数が最後に現れるように体系化され、ギャザーエンジンがメモリからスカラ変数をフェッチする前に、それがＰＥにスカラ変数以外のすべてを渡すことを可能にする。これは、ＰＥが関数の命令をデコードし、そのベクトル引数をフェッチすることを開始することを可能にする一方、スカラ変数をフェッチするためにギャザーエンジンを待機させる。ラムダ関数の記述子及びスカラ変数は、ラムダ関数が複数のギャザーエンジン／ＰＥペアにわたって分散されている場合、冗長化ＤＲＡＭアクセスを除去するために、ベクトルキャッシュを通じてフェッチされる。図示されるように、メモリ１０００１内のラムダ記述子フォーマットは、スカラ変数１０００３に対するポインタを含み得る一方、ギャザーエンジンは、ＰＥ１０００２に渡されるときに、ラムダ記述子フォーマット内のスカラ変数１０００４の値をフェッチする。
【０９８７】
一実施例において、各記述子の第１のワードは、記述子内の各ワードの意味を規定するヘッダである。図１０１に示されるように、ヘッダワードの下位６バイトは、ラムダ関数１０１０１に対するベクトル引数の数、定数引数１０１０２の数、ベクトル及びスカラ出力１０１０３−１０１０４の数、関数内の命令１０１０５の数、及び、関数におけるスカラ変数１０１０６の数を規定する（各タイプのデータが記述子に現れる場所を一致させるためにオーダリングされる）。ヘッダワードの第７バイトは、関数のコード内のループ開始命令１０１０７（例えば、ハードウェアが、第１のバイトの後の各反復を開始すべき命令）の位置を規定する。ワード内の高次のバイトは未使用１０１０８である。残りのワードは、図に示される順序で、関数命令、定数及び入出力アドレスを含む。
【０９８８】
すべての必要なオペレーションが制御論理を修正することによりサポートされ得るので、ラムダ関数をサポートするために必要されるギャザーエンジンデータパスに対する変更がない。ギャザーエンジンがメモリからラムダ記述子をフェッチした場合、それは、ベクトル成分ラインバッファ及び列記述子バッファの両方に記述子のラインをコピーする。スカラ変数のアドレスを含まない記述子ラインは、未変更のＰＥに渡される一方、それらは、スカラ変数の値がメモリからフェッチされて、これらのアドレスの配置にあるラインバッファに挿入されるまで、ラインバッファ内に実行する維持する既存の収集及び未応答バッファハードウェアは、変更することなくこのオペレーションをサポートできる。
【０９８９】
ラムダ関数をサポートするために処理要素に対する変更
【０９９０】
一実施例において、ラムダ関数をサポートするために、図１０２に示されるように、別々のデータパスがＰＥに追加され、上記で説明される行列値バッファ９１０５、行列インデックスバッファ９１０３及びベクトル値バッファ９１０４を示す。ＰＥのバッファは同じものを維持しつつ、これらの名称は、現在の実装におけるこれらのより一般的な使用を反映するために、入力バッファ１、入力バッファ２及び入力バッファ３に変更されている。ＳｐＭＶデータパス９１１０も、ベースアーキテクチャから変更されないままである。ラムダ関数としてＳｐＭＶを実装することが可能であろうが、専用のハードウェア１０２０１を構築することで、電力を低減し、ＳｐＭＶの性能を向上させる。ＳｐＭＶデータパス９１１０及びラムダデータパス１０２０１からの結果は、出力バッファ１０２０２に、及び最終的にシステムメモリに送信される。
【０９９１】
図１０３は、ラムダデータパスの一実施例の詳細を示し、述語レジスタファイル１０３０１、レジスタファイル１０３０２、デコード論理１０３０３、デコードされた命令バッファ１０３０５を含み、ロード・ストアＩＳＡを実装するインオーダ実行パイプライン１０３０４を中心に展開する。単一の発行実行パイプラインが十分な性能を提供することができない場合、１つは、ラムダオペレーションに固有のデータ並列性を利用して、実行パイプラインをベクトル化して並列に複数のベクトル成分を処理してよく、それは、個別のラムダ関数におけるＩＬＰを活用するよりも、並列性を改善するよりエネルギー効率の良い方式とするべきである。実行パイプラインは、１レジスタあたり６４ビットを有する１６〜３２エントリレジスタファイル１０３０２からその入力を読み出し、１６〜３２エントリレジスタファイル１０３０２に結果を書き戻す。ハードウェアは、整数及び浮動小数点レジスタを区別しておらず、任意のレジスタが任意のタイプのデータを保持してよい。述語レジスタファイル１０３０１は、比較オペレーションの出力を保持しており、それは述語命令実行に用いられる。一実施例において、ラムダデータパス１０３０４は、分岐命令をサポートしていないので、任意の条件実行が述語命令を通じて行われなければならない。
【０９９２】
各ラムダ関数の開始時に、ギャザーエンジンは、関数の命令を入力バッファ３  ９１０４（ベクトル値バッファ）に配置する。次に、デコード論理１０３０３は、順次、各命令をデコードし、その結果を３２エントリデコードされた命令バッファ１０３０５に配置する。これは、ループ１のすべての反復に対する各命令を繰り返しデコーディングするエネルギーコストを節約する。
【０９９３】
ラムダデータパスは、４つの特別な制御レジスタ１０３０６を含む。インデックスカウンタレジスタは、ラムダデータパスが現在処理しているベクトル成分のインデックスを保持し、ラムダの各反復の終了時に自動的にインクリメントされる。最後のインデックスレジスタは、ＰＥが処理するはずの最後のベクトル成分のインデックスを保持する。ループ開始レジスタは、ラムダ関数の繰り返される部分において第１の命令のデコードされた命令バッファ内の位置を保持する一方、ループ終了レジスタは、ラムダ関数内の最後の命令の位置を保持する。
【０９９４】
ラムダ関数の実行は、デコードされた命令バッファ内の第１の命令と共に開始し、パイプラインが、ループ終了レジスタにより指し示される命令に到達するまで進める。そのポイントにおいて、パイプラインは、インデックスカウンタレジスタの値を、最後のインデックスレジスタの値と比較し、インデックスカウンタが最後のインデックスより小さい場合、ループ開始レジスタにより指し示される命令に暗黙的な分岐を戻す。インデックスカウンタレジスタが、各反復の終了時にインクリメントされるだけなので、このチェックは、パイプライン内のバブルを回避するために予め行うことができる。
【０９９５】
このスキームは、ラムダ関数の第１の反復においてのみ実行される必要がある「プリアンブル」命令を簡単に含めることができる。例えば、２つのスカラ及び１つの定数入力を有するラムダ関数は、３つのロード命令を用いて開始して、それらの入力の値をレジスタファイルにフェッチし、入力が、関数の各反復におけるよりもむしろ、１回が読み出されるのみとなるように、ループ開始レジスタを設定して、デコードされた命令バッファ内の第４の命令を指し示す。
【０９９６】
一実施例において、ラムダデータパスは、多くのＲＩＳＣプロセッサと同様にロード・ストアＩＳＡを実行する。ラムダデータパスのロード及びストア命令は、ＰＥのＳＲＡＭバッファ内の位置を参照する。ＳＲＡＭバッファとＤＲＡＭとの間のデータのすべての転送は、ＰＥのフェッチ及びライトバックハードウェアにより管理されている。ラムダデータパスは、２つのタイプのロード命令、すなわち、スカラ及び成分をサポートする。スカラロードは、ＳＲＡＭバッファのうちの１つにおいて特定された位置のコンテンツをフェッチし、それをレジスタ内に配置する。ラムダ関数内のスカラロード命令のほとんどは、関数のプリアンブルにおいて発生するが、レジスタプレッシャは、ループ本体に置かれるスカラロードを時々必要するかもしれない。
【０９９７】
成分ロードは、ラムダ関数の入力ベクトルの成分をフェッチする。ＰＥは、そのバッファにマッピングされる第１の入力ベクトルの現在の成分を指し示すバッファごとに計算ポインタを保持する。成分ロードは、計算ポインタからターゲットバッファ及びオフセットを特定する。成分命令が実行される場合、ハードウェアは、特定したオフセットを、適切なバッファのサイズを法とする（ｍｏｄｕｌｏ）計算ポインタの値に加算し、レジスタ内のその位置からデータをロードする。成分ストア命令は、同様であるが、ＰＥ出力バッファ１０２０２内の適切なアドレスにデータを書き込む。
【０９９８】
このアプローチは、ＰＥの既存のフェッチハードウェアと共にサポートされる複数の入出力ベクトルを可能にする。入力ベクトルは、ラムダ関数の記述子により特定される順序で、入力バッファ１  ９１０５及び２  ９１０３を交互に行い、フェッチハードウェアは、同時にバッファ内の各ベクトルのページ全体を読み出す。
【０９９９】
例として、３つの入力ベクトル、Ａ、Ｂ、及びＣを有する関数を検討する。入力ベクトルＡは、０のオフセットにおいて、ＰＥの入力バッファ１  ９１０５上にマッピングされる。入力Ｂは、再び０のオフセットにおいて、入力バッファ２  ９１０３上にマッピングされる。入力Ｃは、２５６のオフセットにおいて、入力バッファ１  ９１０５上にマッピングされる（Ｔｅｚｚａｒｏｎスタイルの２５６バイトのページを想定する）。ＰＥのフェッチハードウェアは、入力Ａ及びＣのページを入力バッファ１  ９１０５にインタリーブする一方、入力バッファ２  ９１０３は、入力Ｂのページで満たされている。ラムダ関数の各反復は、０のオフセットを有するバッファ１  ９１０５から成分ロードを実行することにより、入力Ａの適切な成分をフェッチし、０のオフセットを有するバッファ２  ９１０３から成分ロードを有する入力Ｂの適切な成分をフェッチし、２５６のオフセットを有するバッファ１  ９１０５から成分ロードを有する入力Ｃのその成分をフェッチする。各反復の終了時に、ハードウェアは、計算ポインタをインクリメントして、各入力ベクトルの次の成分に進む。計算ポインタが、ページの終了に到達した場合、ハードウェアは、（ページサイズ×（−１上にマッピングされたベクトル入力の＃））バイトによりそれをインクリメントして、バッファの第１の入力ベクトルの次のページの第１の成分にそれを進める。同様のスキームが、複数の出力ベクトルを生成するラムダ関数を処理するために用いられる。
【１０００】
図１０４に示されるように、一実施例において、８ビットは、オペコード１０４０１に専用である。残りの２４ビットは、６ビットのレジスタ指示子を結果としてもたらす単一の宛先１０４０２及び３つの入力オペランド１０４０３−１０４０５間で分割される。制御フロー命令は、一実施例において用いられておらず、定数は、補助レジスタファイルから供給され、ビット割り当てアクロバティクスは、命令ワード内の大きな即値に合致させる必要はない。一実施例において、すべての命令は、図１０４に存在する命令エンコーディングに合致する。ある特定の命令のセットに対するエンコーディングは、図１０５に示される。
【１００１】
一実施例において、比較命令は、比較述語を用いる。例示的な比較述語のエンコーディングは、図１０６のテーブルに列挙されている。
【１００２】
詳細に上述されたように、いくつかの例において、所与のタスクに対してアクセラレータを使用することが有利である。しかしながら、実現可能でない及び／又は有利でないインスタンスがあり得る。例えば、利用可能でないアクセラレータ、不利益が大き過ぎるアクセラレータへのデータの異同、アクセラレータの速度がプロセッサコアより遅いなどでる。その結果、いくつかの実施例では、追加の命令が、いくつかのタスクに対する性能及び／又はエネルギー効率性を提供し得る。
【１００３】
行列の乗算の例が図１０９に示される。行列の乗算は、Ｃ［ｒｏｗｓＡ，ｃｏｌｓＢ］＋＝Ａ［ｒｏｗｓＡ，ｃｏｍｍ］×Ｂ［ｃｏｍｍ，ｃｏｌｓＢ］である。ＭＡＤＤ（積和演算命令）に関して本明細書で用いられるように、行列×ベクトル乗算命令は、ｃｏｌｓＢ＝１を設定することにより規定される。この命令は、行列入力Ａ、ベクトル入力Ｂ及びベクトル出力Ｃを取る。５１２ビットベクトルのコンテキストにおいて、倍精度についてｒｏｗｓＡ＝８であり、単精度について１６である。
【１００４】
多くのＣＰＵは、１次元ベクトルに対して演算を行うＳＩＭＤ命令を介して密行列乗算を実行する。本明細書における詳細では、サイズ８×４、８×８及びそれらより大きい２次元行列（タイル）を含むようにＳＩＭＤアプローチを拡張する命令（及び基礎となるハードウェア）である。この命令の使用を通じて、小さな行列が、ベクトルと、宛先ベクトルに追加された結果と共に乗算され得る。すべての演算は、１つの命令で実行されるので、多数の積和演算を介して命令及びデータをフェッチするエネルギーコストをならす。さらに、いくつかの実施例では、２分木を利用して総和（削減）を実行する、及び／又は、レジスタの集合として、入力行列を保持する乗算器アレイに組み込まれるレジスタファイルを含む。
【１００５】
行列の乗算に関して、ＭＡＤＤ命令の実施形態の実行では、
（ｉ＝０；ｉ＜Ｎ；ｉ＋＋）ついて／／ｒｏｗｓＡ（例えば、８）のＮ＝８のパックドデータ要素サイズ（例えば、ベクトル長）
（ｋ＝０；ｋ＜Ｍ；ｋ＋＋）について、／／ｃｏｍｍ＝Ｍ
Ｃ［ｉ］＋＝Ａ［ｉ，ｋ］×Ｂ［ｋ］
を計算する。
【１００６】
典型的には、「Ａ」オペランドは、８つのパックドデータレジスタに格納される。「Ｂ」オペランドは、１つのパックドデータレジスタに格納されてよい、又は、メモリから読み出されてよい。「Ｃ」オペランドは、１つのパックドデータレジスタに格納される。
【１００７】
この命令についての残りの考察を通じて、「ｏｃｔｏＭＡＤＤ」バージョンが説明される。このバージョンは、８つのパックドデータ要素のソース（例えば、８つのパックドデータレジスタ）にパックドデータ要素のソース（例えば、単一のレジスタ）を掛ける。内側ループを拡張することにより、シーケンシャルな実装に関して（ｏｃｔｏＭＡＤＤ命令に関して）以下のような実行を提供する。
（ｉ＝０；ｉ＜８；ｉ＋＋）について、Ｃ［ｉ］＋＝Ａ［ｉ，０］×Ｂ［０］＋
Ａ［ｉ，１］×Ｂ［１］＋
Ａ［ｉ，２］×Ｂ［２］＋
Ａ［ｉ，３］×Ｂ［３］＋
Ａ［ｉ，４］×Ｂ［４］＋
Ａ［ｉ，５］×Ｂ［５］＋
Ａ［ｉ，６］×Ｂ［６］＋
Ａ［ｉ，７］×Ｂ［７］。
【１００８】
示されるように、「Ａ」及び「Ｂ」オペランドの対応するパックドデータ要素位置からのパックドデータ要素の各乗算の後に続いて加算がある。シーケンシャルな加算は、最小の一時なストレージを用いて複数のより簡単なオペレーションに分解される。
【１００９】
いくつかの実施例では、２分木アプローチが用いられる。２分木は、並列に２つのサブツリーを合計して、次に、結果をまとめて加算することにより、レイテンシを最小化する。これは、２分木全体に再帰的に適用される。最終結果は、「Ｃ」宛先オペランドに追加される。
【１０１０】
内側ループを拡張することにより、バイナリ実装に関して（ｏｃｔｏＭＡＤＤ命令に関して）以下のような実行を提供する。
（ｉ＝０；ｉ＜８；ｉ＋＋）について、
Ｃ［ｉ］＋＝（（Ａ［ｉ，０］×Ｂ［０］＋Ａ［ｉ，１］×Ｂ［１］）＋
（Ａ［ｉ，２］×Ｂ［２］＋Ａ［ｉ，３］×Ｂ［３］））＋
（（Ａ［ｉ，４］×Ｂ［４］＋Ａ［ｉ，５］×Ｂ［５］）＋
（Ａ［ｉ，６］×Ｂ［６］＋Ａ［ｉ，７］×Ｂ［７］））。
【１０１１】
図１１０は、２分木低減ネットワークを用いたｏｃｔｏＭＡＤＤ命令処理を示す。図は、オペレーションの１つのベクトルレーンを示す。５１２ビットベクトルを用いて、倍精度のｏｃｔｏＭＡＤＤは、８つのレーンを有する一方、単精度のｏｃｔｏＭＡＤＤは、１６個のレーンを有する。
【１０１２】
図示されるように、複数の乗算回路１１００１−１１０１５は、Ａ［ｉ，０］×Ｂ［０］、Ａ［ｉ，１］×Ｂ［１］、Ａ［ｉ，２］×Ｂ［２］、Ａ［ｉ，３］×Ｂ［３］、Ａ［ｉ，４］×Ｂ［４］、Ａ［ｉ，５］×Ｂ［５］、Ａ［ｉ，６］×Ｂ［６］及びＡ［ｉ，７］×Ｂ［７］のそれぞれについての乗算を実行する。この例において、ｉはＡレジスタである。典型的には、乗算は、並列で実行される。
【１０１３】
乗算回路１１００１−１１０１５に結合される加算回路１１０１７−１１０２３は、乗算回路１１００１−１１０１５の結果を加算する。例えば、加算回路は、Ａ［ｉ，０］×Ｂ［０］＋Ａ［ｉ，１］×Ｂ［１］、Ａ［ｉ，２］×Ｂ［２］＋Ａ［ｉ，３］×Ｂ［３］、Ａ［ｉ，４］×Ｂ［４］＋Ａ［ｉ，５］×Ｂ［５］、及び、Ａ［ｉ，６］×Ｂ［６］＋Ａ［ｉ，７］×Ｂ［７］を実行する。典型的には、総和は、並列で実行される。
【１０１４】
最初の総和の結果は、加算回路１１０２５を用いて合計され、まとめて加算される。この加算の結果は、宛先に格納される新たな値１１０３３を生成するために、宛先から元の（古い）値１１０３１に、加算回路１１０２７により加算される。
【１０１５】
ほとんどの実施例では、命令は、８つの独立したソースレジスタに加え、他のソース及びレジスタの宛先に対するレジスタ又はメモリオペランドを規定することができない。したがって、いくつかの例では、ｏｃｔｏＭＡＤＤ命令は、行列オペランドに対して８つのレジスタの制限された範囲を規定する。例えば、ｏｃｔｏＭＡＤＤ行列オペランドは、レジスタ０−７であってよい。いくつかの実施形態において、第１のレジスタが規定され、第１のレジスタに連続したレジスタは、追加の（例えば、７つの）レジスタである。
【１０１６】
図１１１は、積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【１０１７】
１１１０１において、命令がフェッチされる。例えば、積和演算命令がフェッチされる。積和演算命令は、オペコード、第１のパックドデータオペランド（メモリ又はレジスタのいずれか一方）のためのフィールド、第２から第Ｎのパックドデータソースオペランドのための１又は複数のフィールド、及び、パックドデータ宛先オペランドを含む。いくつかの実施形態において、積和演算命令は、書き込みマスクオペランドを含む。いくつかの実施形態において、命令は、命令キャッシュからフェッチされる。
【１０１８】
１１１０３において、フェッチされた命令がデコードされる。例えば、フェッチされた積和演算命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【１０１９】
１１１０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。一連の積和演算命令を実行する場合に、メインレジスタファイルから繰り返しこれらの値を読み出す必要性を回避するために、（以下に詳細に説明されるように）これらのレジスタのコピーが、乗算器−加算器のアレイ自体に構築される。当該コピーは、メインレジスタファイルのキャッシュとして維持される。
【１０２０】
１１１０７において、デコードされた命令は、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、２）一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）宛先の対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納する、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。Ｎは、典型的には、オペコード又はプレフィックスにより示される。例えば、ｏｃｔｏＭＡＤＤについて、Ｎは９（Ａに対して８つのレジスタがあるような）である。乗算は、並列で実行されてよい。
【１０２１】
いくつかの実施形態では、１１１０９において、命令がコミット又はリタイアされる。
【１０２２】
図１１２は、積和演算命令を処理するために、プロセッサにより実行される方法の実施形態を示す。
【１０２３】
１１２０１において、命令がフェッチされる。例えば、積和演算命令がフェッチされる。融合積和演算命令は、オペコード、第１のパックドデータオペランド（メモリ又はレジスタのいずれか一方）のためのフィールド、第２から第Ｎのパックドデータソースオペランドのための１又は複数のフィールド、及び、パックドデータ宛先オペランドを含む。いくつかの実施形態において、融合積和演算命令は、書き込みマスクオペランドを含む。いくつかの実施形態において、命令は、命令キャッシュからフェッチされる。
【１０２４】
１１２０３において、フェッチされた命令がデコードされる。例えば、フェッチされた積和演算命令は、本明細書で詳細に説明されるようなデコード回路によりデコードされる。
【１０２５】
１１２０５において、デコードされた命令のソースオペランドと関連付けられたデータ値が取得される。一連の積和演算命令を実行する場合に、メインレジスタファイルから繰り返しこれらの値を読み出す必要性を回避するために、（以下に詳細に説明されるように）これらのレジスタのコピーが、乗算器−加算器のアレイ自体に構築される。当該コピーは、メインレジスタファイルのキャッシュとして維持される。
【１０２６】
１１２０７において、デコードされた命令は、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、そのソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、２）対で一時的な結果を合計し、３）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に一時的な結果の合計を加え、４）宛先の対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納する、本明細書で詳細に説明されるような実行回路（ハードウェア）により実行される。Ｎは、典型的には、オペコード又はプレフィックスにより示される。例えば、ｏｃｔｏＭＡＤＤについて、Ｎは９（Ａに対して８つのレジスタがあるような）である。乗算は、並列で実行されてよい。
【１０２７】
いくつかの実施形態では、１１２０９において、命令がコミット又はリタイアされる。
【１０２８】
いくつかの実施例において、ＭＡＤＤ命令がまず遭遇された場合、リネーマは、マイクロオペレーションを注入して、メインレジスタをキャッシュにコピーすることにより、キャッシュされたコピーをメインレジスタファイルと同期させる。後続のＭＡＤＤ命令は、それらが変更されないままである限り、キャッシュされたコピーを使用し続ける。いくつかの実施例では、ｏｃｔｏＭＡＤＤ命令により、レジスタの制限された範囲の使用を予期し、レジスタ値が生成されるときに、メインレジスタファイル及びキャッシュされたコピーの両方に書き込みをブロードキャストする。
【１０２９】
図１１３（Ａ）〜図１１３（Ｃ）は、ＭＡＤＤ命令を実行するための例示的なハードウェアを示す。図１１３（Ａ）は、ＭＡＤＤ命令を実行するコンポーネントを示す。図１１３（Ｂ）は、これらのコンポーネントのサブセットを示す。特に、複数の乗算回路１１３２３は、ソースレジスタのパックドデータ要素を、加算回路１１３２７に結合される各乗算回路１１３２３と乗算するために用いられる。各加算回路は、チェーン様式で加算回路１１３２７に供給する。セレクタ１１３２１は、外部入力又は加算回路のフィードバックを選択するために用いられる。レジスタファイルは、レジスタファイルの一部として複数の加算器アレイ内に組み込まれ、マルチプレクサ１１３２５を読み出す。特定のレジスタが、積和演算器の各列に有線で接続される。
【１０３０】
図１１３（Ｂ）は、レジスタファイルを示し、マルチプレクサ１１３２５を読み出す。レジスタファイル１１３２７は、キャッシュとしてＡを格納する複数のレジスタ（例えば、４つ又は８つのレジスタ）である。訂正されたレジスタは、読み出しｍｕｘ１１３２９を用いて選択される。
【１０３１】
ｏｃｔｏＭＡＤＤ命令の予期される使用は、以下のとおりである。
//Ｃ＋＝Ａ×Ｂを計算する
//Ａは、ＲＥＧ０−７における８×８タイルとしてロードされる
//Ｂは、メモリから１×８タイルとしてロードされる
//Ｃは、ＲＥＧ８−３１における２４×８タイルとしてロード及び格納される
for (outer loop) {
load [24,8] tile of C matrix into REG 8-31 // 24 loads
for (middle loop) {
load [8,8] tile of A matrix into REG 0-7 // 8 loads
for (inner loop) {
// 24 iterations
REG [8-31 from inner loop] += REG 0-7 * memory[inner loop];
// 1 load
}
}
store [24,8] tile of C matrix from REG8-31 // 24 stores
}
【１０３２】
内側ループは、２４個のｏｃｔｏＭＡＤＤ命令を含む。それぞれは、メモリから１つの「Ｂ」オペランドを読み出して、２４個の「Ｃ」アキュムレータのうちの１つに合計する。中間ループは、新たなタイルを有する８つの「Ａ」レジスタをロードする。外側ループは、２４個の「Ｃ」アキュムレータをロード及びストアする。内側ループは、ｏｃｔｏＭＡＤＤハードウェアの高利用率（＞９０％）を実現するために、展開されて、プリフェッチを追加する。
【１０３３】
以下の図は、上記の実施形態を実施するための例示的なアーキテクチャ及びシステムを詳細に説明する。特に、上述したコアタイプ（例えば、アウトオブオーダ、スカラ、ＳＩＭＤ）の態様（例えば、レジスタ、パイプラインなど）が説明される。さらに、コプロセッサ（例えば、アクセラレータ、コア）を含むシステム及びチップ上のシステム実装が示される。いくつかの実施形態において、上記で説明された１又は複数のハードウェアコンポーネント及び／又は命令は、以下で詳細に説明されるようにエミュレートされ、ソフトウェアモジュールとして実装される。
例示的なレジスタアーキテクチャ
【１０３４】
図１２５は、本発明の一実施形態に係るレジスタアーキテクチャ１２５００のブロック図である。図示される実施形態において、５１２ビット幅である３２個のベクトルレジスタ１２５１０があり、これらのレジスタは、ｚｍｍ０からｚｍｍ３１として参照される。下位１６ｚｍｍレジスタの下位２５６ビットは、レジスタｙｍｍ０〜１６上にオーバーレイされる。下位１６ｚｍｍレジスタの下位１２８ビット（ｙｍｍレジスタの下位１２８ビット）は、レジスタｘｍｍ０〜１５上にオーバーレイされる。特定のベクトルに適した命令フォーマットＱＡＣ００は、以下のテーブルに示されるように、これらのオーバーレイされたレジスタファイル上で動作する。
【表４３】
0006988040.tif 000048
【１０３５】
つまり、ベクトル長フィールドＱＡＢ５９Ｂは、最大の長さ及び１又は複数の他のより短い長さから選択し、それぞれのそのようなより短い長さは、先行する長の半分の長さであり、ベクトル長フィールドＱＡＢ５９Ｂなしで命令テンプレートは、最大ベクトル長で動作する。さらに、一実施形態において、特定のベクトルに適した命令フォーマットＱＡＣ００のクラスＢ命令テンプレートは、パックド又はスカラ単一／倍精度の浮動小数点データ、及び、パックド又はスカラ整数データで動作する。スカラ演算は、ｚｍｍ／ｙｍｍ／ｘｍｍレジスタ内の最下位のデータ要素位置で実行されるオペレーションである。上位のデータ要素位置は、それらが命令前と同じままであるか、実施形態に応じてゼロにされるかのいずれか一方である。
【１０３６】
書き込みマスクレジスタ１２５１５−図示された実施形態中では、８個の書き込みマスクレジスタ（ｋ０からｋ７）が存在し、各々６４ビットのサイズである。代替的な実施形態において、書き込みマスクレジスタ１２５１５は、１６ビットのサイズである。前述したように、本発明の一実施形態において、ベクトルマスクレジスタｋ０は、書き込みマスクとして用いられることができない。ｋ０を通常示すであろうエンコーディングが書き込みマスクに用いられる場合、それは、０ｘＦＦＦＦのハードワイヤ型書き込みマスクを選択し、その命令に対する書き込みマスキングを効果的に無効にする。
【１０３７】
汎用レジスタ１２５２５−図示される実施形態において、メモリオペランドをアドレス指定する既存のｘ８６アドレッシングモードと共に用いられる１６個の６４ビット汎用レジスタが存在する。これらのレジスタは、ＲＡＸ、ＲＢＸ、ＲＣＸ、ＲＤＸ、ＲＢＰ、ＲＳＩ、ＲＤＩ、ＲＳＰ及びＲ８からＲ１５という名称により参照される。
【１０３８】
ＭＭＸパックド整数フラットレジスタファイル１２５５０がエイリアスされる、スカラ浮動小数点スタックレジスタファイル（ｘ８７スタック）１２５４５−図示される実施形態では、ｘ８７スタックは、ｘ８７命令セット拡張を用いて３２／６４／８０ビットの浮動小数点データに対するスカラ浮動小数点演算を実行するために用いられる８要素スタックである。一方、ＭＭＸレジスタは、６４ビットのパックド整数データに対する演算を実行するために、並びに、ＭＭＸ及びＸＭＭレジスタ間で実行されるいくつかの演算用にオペランドを保持するために用いられる。
【１０３９】
本発明の代替的な実施形態は、より広い又はより狭いレジスタを用いてよい。さらに、本発明の代替的な実施形態は、より多くの、より少ない又は異なるレジスタファイル及びレジスタを用いてよい。
例示的なコアアーキテクチャ、プロセッサ及びコンピュータアーキテクチャ
【１０４０】
プロセッサコアは、様々な目的のために、様々な方式で、及び、様々なプロセッサにおいて実装されてよい。例として、そのようなコアの実装は、１）汎用計算を対象とする汎用インオーダコア、２）汎用計算を対象とする高性能汎用アウトオブオーダコア、３）主にグラフィックス及び／又は科学技術（スループット）コンピューティングを対象とする特定用途コアを含んでよい。様々なプロセッサの実装は、１）汎用計算を対象とする１又は複数の汎用インオーダコア、及び／又は、汎用計算を対象とする１又は複数の汎用アウトオブオーダコアを含むＣＰＵ、及び、２）主にグラフィックス及び／又は科学技術（スループット）を対象とする１又は複数の特定用途コアを含むコプロセッサを含んでよい。そのような様々なプロセッサは、異なるコンピュータシステムアーキテクチャもたらし、それは、１）ＣＰＵとは別々のチップ上のコプロセッサ、２）ＣＰＵと同じパッケージ内の別々のダイ上のコプロセッサ、３）ＣＰＵと同じダイ上のコプロセッサ（この場合、当該コプロセッサは、統合グラフィックス及び／又は科学技術（スループット）論理などの特定用途論理又は特定用途コアと称されることもある）、及び、４）同じダイ上に、説明されたＣＰＵ（アプリケーションコア又はアプリケーションプロセッサと称されることもある）、上記で説明したコプロセッサ及び追加の機能を含み得るチップ上のシステムを含んでよい。例示的なコアアーキテクチャが次に説明され、後に例示的なプロセッサ及びコンピュータアーキテクチャの説明が続く。
例示的なコアアーキテクチャ
インオーダ及びアウトオブオーダコアブロック図
【１０４１】
図１２６Ａは、本発明の実施形態に係る、例示的なインオーダパイプライン及び例示的なレジスタリネーミング・アウトオブオーダ発行／実行パイプラインの両方を示すブロック図である。図１２６Ｂは、本発明の実施形態に係るプロセッサに含まれるインオーダアーキテクチャコアの例示的な実施形態及び例示的なレジスタリネーミング・アウトオブオーダ発行／実行アーキテクチャコアの両方を示すブロック図である。図１２６Ａ〜図１２６Ｂの実線の枠は、インオーダパイプライン及びインオーダコアを示し、一方、破線の枠の選択的な追加部分は、レジスタリネーミング・アウトオブオーダ発行／実行パイプライン及びコアを示す。インオーダ態様がアウトオブオーダ態様のサブセットであることを前提に、アウトオブオーダ態様が説明される。
【１０４２】
図１２６Ａにおいて、プロセッサパイプライン１２６００は、フェッチステージ１２６０２、長さデコードステージ１２６０４、デコードステージ１２６０６、割り当てステージ１２６０８、リネーミングステージ１２６１０、スケジューリング（ディスパッチ又は発行としても知られている）ステージ１２６１２、レジスタ読み出し／メモリ読み出しステージ１２６１４、実行ステージ１２６１６、ライトバック／メモリ書き込みステージ１２６１８、例外処理ステージ１２６２２、及び、コミットステージ１２６２４を含む。
【１０４３】
図１２６Ｂは、実行エンジンユニット１２６５０に結合されるフロントエンドユニット１２６３０を含むプロセッサコア１２６９０を示し、両方とも、メモリユニット１２６７０に結合される。コア１２６９０は、縮小命令セットコンピューティング（ＲＩＳＣ）コア、複合命令セットコンピューティング（ＣＩＳＣ）コア、超長命令語（ＶＬＩＷ）コア、又は、ハイブリッド又は代替的なコアタイプであってよい。さらなる別のオプションとして、コア１２６９０は、例えば、ネットワーク又は通信コア、圧縮エンジン、コプロセッサコア、汎用コンピューティンググラフィックス処理ユニット（ＧＰＧＰＵ）コア又はグラフィックスコアなどの特定用途コアであってよい。
【１０４４】
フロントエンドユニット１２６３０は、命令キャッシュユニット１２６３４に結合される分岐予測ユニット１２６３２を含み、命令キャッシュユニット１２６３４は、命令トランスレーションルックアサイドバッファ（ＴＬＢ）１２６３６に結合され、命令トランスレーションルックアサイドバッファ（ＴＬＢ）１２６３６は、命令フェッチユニット１２６３８に結合され、命令フェッチユニット１２６３８は、デコードユニット１２６４０に結合される。デコードユニット１２６４０（又は、デコーダ）は、命令をデコードし、１又は複数のマイクロオペレーション、マイクロコードエントリポイント、マイクロ命令、他の命令又は他の制御信号を出力として生成してよく、これらは、元の命令からデコードされる、又は、そうでなければ元の命令を反映する、又は、元の命令から導き出される。デコードユニット１２６４０は、様々な異なるメカニズムを用いて実装されてよい。好適なメカニズムの例では、限定されることはないが、ルックアップテーブル、ハードウェア実装、プログラマブル論理アレイ（ＰＬＡ）、マイクロコードリードオンリメモリ（ＲＯＭ）などを含む。一実施形態において、コア１２６９０は、特定のマクロ命令に関するマイクロコードを（例えば、デコードユニット１２６４０内、そうでなければ、フロントエンドユニット１２６３０内に）格納するマイクロコードＲＯＭ又は他の媒体を含む。デコードユニット１２６４０は、実行エンジンユニット１２６５０内のリネーム／アロケータユニット１２６５２に結合される。
【１０４５】
実行エンジンユニット１２６５０は、リタイアメントユニット１２６５４と１又は複数のスケジューラユニット１２６５６のセットとに結合されるリネーム／アロケータユニット１２６５２を含む。スケジューラユニット１２６５６は、予約ステーション、中央命令ウィンドウなどを含む任意の数の様々なスケジューラを表す。スケジューラユニット１２６５６は、物理レジスタファイルユニット１２６５８に結合される。物理レジスタファイルユニット１２６５８のそれぞれは、１又は複数の物理レジスタファイル、１又は複数の異なるデータタイプを格納するもののうちの異なるいくつか、例えば、スカラ整数、スカラ浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点、ステータス（例えば、実行される次の命令のアドレスである命令ポインタ）などを表す。一実施形態において、物理レジスタファイルユニット１２６５８は、ベクトルレジスタユニット、書き込みマスクレジスタユニット及びスカラレジスタユニットを有する。これらのレジスタユニットは、アーキテクチャのベクトルレジスタ、ベクトルマスクレジスタ及び汎用レジスタを提供してよい。物理レジスタファイルユニット１２６５８は、レジスタリネーミング及びアウトオブオーダ実行が、（例えば、リオーダバッファ及びリタイアレジスタファイルを用いて、将来のファイル、履歴バッファ及びリタイアレジスタファイルを用いて、レジスタマッピング及びレジスタのプールなどを用いて）実装され得る様々な方式を示すために、リタイアメントユニット１２６５４により重ね合わせられる。リタイアメントユニット１２６５４及び物理レジスタファイルユニット１２６５８は、実行クラスタ１２６６０に結合される。実行クラスタ１２６６０は、１又は複数の実行ユニット１２６６２のセット及び１又は複数のメモリアクセスユニット１２６６４のセットを含む。実行ユニット１２６６２は、様々なオペレーション（例えば、シフト、加算、減算、乗算）を、様々なタイプのデータ（例えば、スカラ浮動小数点、パックド整数、パックド浮動小数点、ベクトル整数、ベクトル浮動小数点）に対して実行してよい。いくつかの実施形態では、特定の機能又は機能のセットに専用の多数の実行ユニットを含み得る一方、他の実施形態では、１つの実行ユニットのみ、又は、すべての機能をすべてが実行する複数の実行ユニットを含み得る。特定の実施形態では、特定のタイプのデータ／オペレーションに対して別々のパイプライン（例えば、スカラ整数パイプライン、スカラ浮動小数点／パックド整数／パックド浮動小数点／ベクトル整数／ベクトル浮動小数点パイプライン、及び／又は、メモリアクセスパイプラインは、これら自体のスケジューラユニット、物理レジスタファイルユニット、及び／又は、実行クラスタをそれぞれが有する、−別々のメモリアクセスパイプラインの場合、このパイプラインの実行クラスタがメモリアクセスユニット１２６６４のみを有する特定の実施形態で実装される）を作成するので、スケジューラユニット１２６５６、物理レジスタファイルユニット１２６５８及び実行クラスタ１２６６０は、場合によっては複数のものとして示されている。別々のパイプラインが用いられる場合、これらのパイプラインのうちの１又は複数が、アウトオブオーダ発行／実行であってよく、残りがインオーダであってよいことも理解されたい。
【１０４６】
メモリアクセスユニット１２６６４のセットは、メモリユニット１２６７０に結合され、メモリユニット１２６７０は、レベル２（Ｌ２）キャッシュユニット１２６７６に結合されるデータキャッシュユニット１２６７４に結合されるデータＴＬＢユニット１２６７２を含む。１つの例示的な実施形態において、メモリアクセスユニット１２６６４は、ロードユニット、格納アドレスユニット及び格納データユニットを含んでよく、それぞれが、メモリユニット１２６７０内のデータＴＬＢユニット１２６７２に結合される。命令キャッシュユニット１２６３４は、メモリユニット１２６７０内のレベル２（Ｌ２）キャッシュユニット１２６７６にさらに結合される。Ｌ２キャッシュユニット１２６７６は、キャッシュの１又は複数の他のレベルに結合されて、最終的にメインメモリに結合される。
【１０４７】
例として、例示的なレジスタリネーミング、アウトオブオーダ発行／実行コアアーキテクチャは、以下のようなパイプライン１２６００を実施してよい。１）命令フェッチ１２６３８は、フェッチ及び長さデコーディングステージ１２６０２及び１２６０４を実行し、２）デコードユニット１２６４０は、デコードステージ１２６０６を実行し、３）リネーム／アロケータユニット１２６５２は、割り当てステージ１２６０８及びリネーミングステージ１２６１０を実行し、４）スケジューラユニット１２６５６は、スケジューリングステージ１２６１２を実行し、５）物理レジスタファイルユニット１２６５８及びメモリユニット１２６７０は、レジスタ読み出し／メモリ読み出しステージ１２６１４を実行し、実行クラスタ１２６６０は、実行ステージ１２６１６を実行し、６）メモリユニット１２６７０及び物理レジスタファイルユニット１２６５８は、ライトバック／メモリ書き込みステージ１２６１８を実行し、７）様々なユニットは、例外処理ステージ１２６２２に関するものであってよく、８）リタイアメントユニット１２６５４及び物理レジスタファイルユニット１２６５８は、コミットステージ１２６２４を実行する。
【１０４８】
コア１２６９０は、本明細書で説明される命令を含む１又は複数の命令セット（例えば、ｘ８６命令セット（より新しいバージョンで追加されたいくつかの拡張を伴う））、カリフォルニア州サニーベールのＭＩＰＳ技術のＭＩＰＳ命令セット、ＡＲＭ命令セット（カリフォルニア州サニーベールのＡＲＭホールディングスのＮＥＯＮなどの選択的な追加の拡張を伴う）をサポートしてよい。一実施形態において、コア１２６９０は、パックドデータ命令セット拡張（例えば、ＡＶＸ１、ＡＶＸ２）をサポートする論理を含み、それにより、パックドデータを用いて実行される多くのマルチメディアアプリケーションにより用いられるオペレーションを可能にする。
【１０４９】
コアはマルチスレッディング（オペレーション又はスレッドの２又はそれより多い並列セットを実行する）をサポートしてよく、タイムスライス型マルチスレッディング、同時マルチスレッディング（物理コアが同時にマルチスレッディングするスレッドのそれぞれに対して、単一物理コアが論理コアを提供する）、又は、それらの組み合わせ（例えば、それ以降のインテルのハイパースレッディングテクノロジーなどのタイムスライス型フェッチング及びデコーディング、並びに、同時マルチスレッディング）を含む様々な方式で行われてよいことを理解されたい。
【１０５０】
レジスタリネーミングが、アウトオブオーダ実行のコンテキストで説明される一方、レジスタリネーミングは、インオーダアーキテクチャにおいて用いられてよいことに理解されたい。プロセッサの例示された実施形態では、別々の命令及びデータキャッシュユニット１２６３４／１２６７４及び共有のＬ２キャッシュユニット１２６７６も含み、一方で、代替的な実施形態では、例えば、レベル１（Ｌ１）内部キャッシュ又は内部キャッシュの複数のレベルなど、命令及びデータの両方に対して単一の内部キャッシュを有してよい。いくつかの実施形態において、システムは、内部キャッシュと、コア及び／又はプロセッサの外部にある外部キャッシュとの組み合わせを含んでよい。代替的に、キャッシュのすべては、コア及び／又はプロセッサの外部にあってよい。
具体的な例示的インオーダコアアーキテクチャ
【１０５１】
図１２７Ａ〜図１２７Ｂは、より具体的な例示的インオーダコアアーキテクチャのブロック図を示し、コアは、チップ内の（同じタイプ及び／又は異なるタイプの他のコアを含む）いくつかの論理ブロックのうちの１つであろう。論理ブロックは、用途に応じて、高帯域幅相互接続ネットワーク（例えば、リングネットワーク）を通じて、いくつかの固定機能論理、メモリＩ／Ｏインタフェース及び他の必要なＩ／Ｏ論理と通信する。
【１０５２】
図１２７Ａは、本発明の実施形態に係る、シングルプロセッサコアのオンダイ相互接続ネットワーク１２７０２への接続及びそのレベル２（Ｌ２）キャッシュ１２７０４のローカルサブセットとの接続と併せたシングルプロセッサコアについてのブロック図である。一実施形態において、命令デコーダ１２７００は、パックドデータ命令セット拡張を伴うｘ８６命令セットをサポートする。Ｌ１キャッシュ１２７０６は、スカラ及びベクトルユニット内のキャッシュメモリへの低レイテンシなアクセスを可能にする。一実施形態において（設計を簡略化するために）、スカラユニット１２７０８及びベクトルユニット１２７１０は、別々のレジスタセット（それぞれ、スカラレジスタ１２７１２及びベクトルレジスタ１２７１４）を用い、これらの間で転送されるデータは、メモリに書き込まれて、次にレベル１（Ｌ１）キャッシュ１２７０６からリードバックされ、一方で、本発明の代替的な実施形態では、異なるアプローチ（例えば、単一のレジスタセットを用いる、又は、書き込み及びリードバックされることなく２つのレジスタファイル間でデータが転送されることを可能にする通信パスを含む）を用いてよい。
【１０５３】
Ｌ２キャッシュ１２７０４のローカルサブセットは、プロセッサコア毎に１つずつ、別々のローカルサブセットに分割されるグローバルＬ２キャッシュの一部である。各プロセッサコアは、Ｌ２キャッシュ１２７０４の独自のローカルサブセットに対して直接的なアクセスパスを有する。プロセッサコアにより読み出されるデータは、そのＬ２キャッシュサブセット１２７０４に格納され、これら自体のローカルＬ２キャッシュサブセットにアクセスする他のプロセッサコアと並列に、迅速にアクセスされ得る。プロセッサコアにより書き込まれるデータは、独自のＬ２キャッシュサブセット１２７０４に格納され、必要な場合には、他サブセットからフラッシュされる。リングネットワークは、共有データに対するコヒーレンシを確保する。リングネットワークは、プロセッサコア、Ｌ２キャッシュ及び他論理ブロックなどのエージェントがチップ内で互いに通信することを可能にするために双方向である。各リングデータパスは、一方向あたり１０１２ビット幅である。
【１０５４】
図１２７Ｂは、本発明の実施形態に係る、図１２７Ａにおけるプロセッサコアの一部の拡大図である。図１２７Ｂは、Ｌ１キャッシュ１２７０４のＬ１データキャッシュ１２７０６Ａ部分、並びに、ベクトルユニット１２７１０及びベクトルレジスタ１２７１４に関するさらなる詳細を含む。具体的には、ベクトルユニット１２７１０は、１６幅ベクトル処理ユニット（ＶＰＵ）（１６幅ＡＬＵ１２７２８を参照）であり、これは、整数、単精度浮動及び倍精度浮動命令のうちの１又は複数を実行する。ＶＰＵは、スウィズルユニット１２７２０を用いたレジスタ入力のスウィズル、数値変換ユニット１２７２２Ａ−Ｂを用いた数値変換、及び、複製ユニット１２７２４を用いたメモリ入力に対する複製をサポートする。書き込みマスクレジスタ１２７２６は、結果としてもたらされるベクトル書き込みのプレディケートを可能にする。
【１０５５】
図１２８は、本発明の実施形態に係る、１つより多くのコアを有してよく、統合メモリコントローラを有してよく、かつ、統合グラフィックスを有してよいプロセッサ１２８００のブロック図である。図１２８内の実線の枠は、単一のコア１２８０２Ａ、システムエージェント１２８１０、１又は複数のバスコントローラユニット１２８１６のセットを有するプロセッサ１２８００を示す一方、破線の枠の選択的な追加部分は、複数のコア１２８０２Ａ−Ｎ、システムエージェントユニット１２８１０内の１又は複数の統合メモリコントローラユニット１２８１４のセット、及び特定用途論理１２８０８を有する代替的なプロセッサ１２８００を示す。
【１０５６】
したがって、プロセッサ１２８００の異なる実装は、１）統合グラフィックス及び／又は科学技術（スループット）論理である特定用途論理１２８０８（１又は複数のコアを含んでよい）、及び、１又は複数の汎用コアであるコア１２８０２Ａ−Ｎ（例えば、汎用インオーダコア、汎用アウトオブオーダコア、その２つの組み合わせ）を有するＣＰＵ、２）グラフィックス及び／又は科学技術（スループット）を主に対象とする多数の特定用途コアであるコア１２８０２Ａ−Ｎを有するコプロセッサ、及び、３）多数の汎用インオーダコアであるコア１２８０２Ａ−Ｎを有するコプロセッサを含んでよい。したがって、プロセッサ１２８００は、汎用プロセッサ、コプロセッサ又は特定用途プロセッサ、例えば、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、ＧＰＧＰＵ（汎用グラフィックス処理ユニット）、高スループットの多集積コア（ＭＩＣ）コプロセッサ（３０又はそれより多いコアを含む）、又は、埋め込み型プロセッサなどであってよい。プロセッサは、１又は複数のチップ上に実装されてよい。プロセッサ１２８００は、１又は複数の基板の一部であってよい、及び／又は、例えば、ＢｉＣＭＯＳ、ＣＭＯＳ又はＮＭＯＳなどの多数の処理技術のいずれかを用いて１又は複数の基板上に実装されてもよい。
【１０５７】
メモリ階層は、コア、１又は複数の共有キャッシュユニット１２８０６のセット、及び、統合メモリコントローラユニット１２８１４のセットに結合される外部メモリ（図示しない）内に１又は複数のレベルのキャッシュを含む。共有キャッシュユニット１２８０６のセットは、レベル２（Ｌ２）、レベル３（Ｌ３）、レベル４（Ｌ４）又は他のレベルのキャッシュなどの１又は複数の中レベルキャッシュ、ラストレベルキャッシュ（ＬＬＣ）及び／又はその組み合わせを含んでよい。一実施形態において、リングベースの相互接続ユニット１２８１２は、統合グラフィックス論理１２８０８（統合グラフィックス論理１２８０８は、特定用途論理の一例であり、本明細書ではまた特定用途論理と称されている）、共有キャッシュユニット１２８０６のセット及びシステムエージェントユニット１２８１０／統合メモリコントローラユニット１２８１４を相互接続し、一方で、代替的な実施形態では、そのようなユニットを相互接続するための任意の数の周知技術を用いてよい。一実施形態において、コヒーレンシが、１又は複数のキャッシュユニット１２８０６及びコア１２８０２Ａ−Ｎの間で維持されている。
【１０５８】
いくつかの実施形態において、コア１２８０２Ａ−Ｎのうちの１又は複数は、マルチスレッディングが可能である。システムエージェント１２８１０は、コア１２８０２Ａ−Ｎを調整し、動作させるそれらのコンポーネントを含む。システムエージェントユニット１２８１０は、例えば、電力制御ユニット（ＰＣＵ）及びディスプレイユニットを含んでよい。ＰＣＵは、コア１２８０２Ａ−Ｎ及び統合グラフィックス論理１２８０８の電力状態を調整するために必要とされる論理及びコンポーネントであってよい又は含んでよい。ディスプレイユニットは、１又は複数の外部に接続されたディスプレイを駆動させるためのものである。
【１０５９】
コア１２８０２Ａ−Ｎは、アーキテクチャ命令セットの観点からホモジニアス又はヘテロジニアスであってよい。つまり、コア１２８０２Ａ−Ｎの２又はそれより多くは、同じ命令セットを実行することが可能であってよく、一方、その他は、その命令セット又は異なる命令セットのサブセットのみを実行することが可能であってよい。
例示的なコンピュータアーキテクチャ
【１０６０】
図１２９〜図１３２は、例示的なコンピュータアーキテクチャのブロック図である。ラップトップ、デスクトップ、ハンドヘルドＰＣ、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバ、ネットワークデバイス、ネットワークハブ、スイッチ、埋め込み型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、グラフィックスデバイス、ビデオゲームデバイス、セットトップボックス、マイクロコントローラ、携帯電話、ポータブルメディアプレーヤ、ハンドヘルドデバイス及び他の様々な電子デバイスに関する技術分野で知られている他のシステム設計及び構成にも適している。一般的に、本明細書に開示されるようなプロセッサ及び／又は他の実行論理を組み込むことができる多様なシステム又は電子デバイスが概して適している。
【１０６１】
ここで図１２９を参照すると、示されているのは、本発明の一実施形態に従うシステム１２９００のブロック図である。システム１２９００は、コントローラハブ１２９２０に結合される１又は複数のプロセッサ１２９１０、１２９１５を含んでよい。一実施形態において、コントローラハブ１２９２０は、グラフィックメモリコントローラハブ（ＧＭＣＨ）１２９９０及び入力／出力ハブ（ＩＯＨ）１２９５０（別々のチップ上にあってよい）を含み、ＧＭＣＨ１２９９０は、メモリ１２９４０及びコプロセッサ１２９４５に結合されるメモリ及びグラフィックスコントローラを含み、ＩＯＨ１２９５０は、入力／出力（Ｉ／Ｏ）デバイス１２９６０をＧＭＣＨ１２９９０に結合する。代替的に、メモリ及びグラフィックスコントローラの一方又は両方は、（本明細書で説明されるように）プロセッサ内に統合されてよく、メモリ１２９４０及びコプロセッサ１２９４５は、プロセッサ１２９１０と、ＩＯＨ１２９５０を有する単一のチップ内のコントローラハブ１２９２０とに直接的に結合される。
【１０６２】
追加のプロセッサ１２９１５の選択的な特性が、破線で図１２９に示されている。各プロセッサ１２９１０、１２９１５は、本明細書で説明される処理コアのうちの１又は複数を含んでよく、プロセッサ１２８００のいくつかのバージョンであってよい。
【１０６３】
メモリ１２９４０は、例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、相変化メモリ（ＰＣＭ）又はその２つの組み合わせであってよい。少なくとも１つの実施形態について、コントローラハブ１２９２０は、例えば、フロントサイドバス（ＦＳＢ）などのマルチドロップバス、ＱｕｉｃｋＰａｔｈ相互接続（ＱＰＩ）などのポイントツーポイントインタフェース、又は、同様の接続１２９９５を介してプロセッサ１２９１０、１２９１５と通信する。
【１０６４】
一実施形態において、コプロセッサ１２９４５は、例えば、ハイスループットＭＩＣプロセッサ、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、ＧＰＧＰＵ、又は、埋め込み型プロセッサなどの特定用途プロセッサである。一実施形態において、コントローラハブ１２９２０は、統合グラフィックスアクセラレータを含んでよい。
【１０６５】
アーキテクチャ特性、マイクロアーキテクチャ特性、熱的特性及び電力消費特性などを含む広範な価値基準の観点から、物理リソース１２９１０、１２９１５間には、様々な差異があり得る。
【１０６６】
一実施形態において、プロセッサ１２９１０は、一般的なタイプのデータ処理オペレーションを制御する命令を実行する。命令内に組み込まれるものは、コプロセッサ命令であってよい。プロセッサ１２９１０は、取り付けられたコプロセッサ１２９４５により実行されるべきタイプのものとしてこれらのコプロセッサ命令を認識する。状況に応じて、プロセッサ１２９１０は、これらのコプロセッサ命令（又は、コプロセッサ命令を表す制御信号）を、コプロセッサバス又は他の相互接続を介してコプロセッサ１２９４５に発行する。コプロセッサ１２９４５は、受信したコプロセッサ命令を受け入れて実行する。
【１０６７】
ここで図１３０を参照すると、示されているのは、本発明の実施形態に従う第１のより具体的な例示的システム１３０００のブロック図である。図１３０に示されるように、マルチプロセッサシステム１３０００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続１３０５０を介して結合される第１のプロセッサ１３０７０及び第２のプロセッサ１３０８０を含む。プロセッサ１３０７０及び１３０８０のそれぞれは、プロセッサ１２８００の何らかのバージョンであってよい。本発明の一実施形態において、プロセッサ１３０７０及び１３０８０は、それぞれプロセッサ１２９１０及び１２９１５であり、一方、コプロセッサ１３０３８はコプロセッサ１２９４５である。別の実施形態において、プロセッサ１３０７０及び１３０８０は、それぞれプロセッサ１２９１０及びコプロセッサ１２９４５である。
【１０６８】
統合メモリコントローラ（ＩＭＣ）ユニット１３０７２及び１３０８２をそれぞれ含むプロセッサ１３０７０及び１３０８０が示されている。プロセッサ１３０７０は、そのバスコントローラユニットの一部として、ポイントツーポイント（Ｐ―Ｐ）インタフェース１３０７６及び１３０７８も含む。同様に第２のプロセッサ１３０８０は、Ｐ−Ｐインタフェース１３０８６及び１３０８８を含む。プロセッサ１３０７０、１３０８０は、Ｐ―Ｐインタフェース回路１３０７８、１３０８８を用いて、ポイントツーポイント（Ｐ―Ｐ）インタフェース１３０５０を介して情報を交換してよい。図１３０に示されるように、ＩＭＣ１３０７２及び１３０８２は、メモリのそれぞれ、すなわち、メモリ１３０３２及びメモリ１３０３４にプロセッサを結合し、それぞれのプロセッサにローカルに取り付けられたメインメモリの一部であってよい。
【１０６９】
プロセッサ１３０７０、１３０８０は、ポイントツーポイントインタフェース回路１３０７６、１３０９４、１３０８６、１３０９８を用いて、個別のＰ−Ｐインタフェース１３０５２、１３０５４を介して各チップセット１３０９０と情報を交換してよい。チップセット１３０９０は、高性能インタフェース１３０９２を介してコプロセッサ１３０３８と選択的に情報を交換してよい。一実施形態において、コプロセッサ１３０３８は、例えば、ハイスループットＭＩＣプロセッサ、ネットワーク又は通信プロセッサ、圧縮エンジン、グラフィックスプロセッサ、ＧＰＧＰＵ又は埋め込み型プロセッサなどの特定用途プロセッサである。
【１０７０】
共有キャッシュ（図示しない）は、いずれかのプロセッサ内又は両方のプロセッサの外部に含まれてよく、さらに、Ｐ―Ｐ相互接続を介してプロセッサと接続されてよく、その結果、プロセッサが低電力モードに置かれている場合、一方又は両方のプロセッサのローカルキャッシュ情報は、共有キャッシュに格納されてよい。
【１０７１】
チップセット１３０９０は、インタフェース１３０９６を介して第１のバス１３０１６に結合されてよい。一実施形態において、第１のバス１３０１６は、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス、又は、ＰＣＩエクスプレスバス又は別の第３世代Ｉ／Ｏ相互接続バスなどのバスであってよいが、本発明の範囲は制限されることはない。
【１０７２】
図１３０に示されるように、様々なＩ／Ｏデバイス１３０１４は、第１のバス１３０１６を第２のバス１３０２０に結合するバスブリッジ１３０１８と共に、第１のバス１３０１６に結合されてよい。一実施形態において、コプロセッサ、ハイスループットＭＩＣプロセッサ、ＧＰＧＰＵのアクセラレータ（例えば、グラフィックスアクセラレータ又はデジタル信号プロセッシング（ＤＳＰ）ユニットなど）、フィールドプログラマブルゲートアレイ又は任意の他のプロセッサなどの１又は複数の追加のプロセッサ１３０１５は第１のバス１３０１６に結合される。一実施形態において、第２のバス１３０２０は、ローピンカウント（ＬＰＣ）バスであってよい。一実施形態において、様々なデバイスは、例えば、キーボード及び／又はマウス１３０２２、通信デバイス１３０２７、及び、命令／コード及びデータ１３０３０を含み得るディスクドライブ又は他の大容量ストレージデバイスなどのストレージユニット１３０２８を含む第２のバス１３０２０に結合されてよい。さらに、オーディオＩ／Ｏ１３０２４は、第２のバス１３０２０に結合されてよい。他のアーキテクチャが可能であることに留意する。例えば、図１３０のポイントツーポイントアーキテクチャの代わりに、システムは、マルチドロップバス又は他のそのようなアーキテクチャを実装してよい。
【１０７３】
ここで図１３１を参照すると、示されているのは、本発明の実施形態に従う第２のより具体的な例示的システム１３１００のブロック図である。図１３０及び図１３１内の同様の要素には、同様の参照番号を付しており、図１３１の他の態様が曖昧になることを回避するために、図１３０の特定の態様が図１３１から省略されている。
【１０７４】
図１３１は、プロセッサ１３０７０、１３０８０が、統合メモリ及びＩ／Ｏ制御論理（「ＣＬ」）１３０７２及び１３０８２をそれぞれ含み得ることを示す。したがって、ＣＬ１３０７２、１３０８２は、統合メモリコントローラユニットを含み、Ｉ／Ｏ制御論理を含む。図１３１は、メモリ１３０３２、１３０３４がＣＬ１３０７２、１３０８２に結合されるだけでなく、Ｉ／Ｏデバイス１３１１４も制御論理１３０７２、１３０８２に結合されることを示す。レガシＩ／Ｏデバイス１３１１５は、チップセット１３０９０に結合される。
【１０７５】
ここで図１３２を参照すると、示されているのは、本発明の実施形態に従うＳｏＣ１３２００のブロック図である。図１２８内の同様の要素には同様の参照番号を付している。また、破線の枠は、より高度なＳｏＣ上の選択的な特徴である。図１３２において、相互接続ユニット１３２０２は、キャッシュユニット１２８０４Ａ−Ｎを含む１又は複数のコア１２８０２Ａ−Ｎのセットと共有キャッシュユニット１２８０６とを含むアプリケーションプロセッサ１３２１０と、システムエージェントユニット１２８１０と、バスコントローラユニット１２８１６と、統合メモリコントローラユニット１２８１４と、統合グラフィックス論理、画像プロセッサ、オーディオプロセッサ及びビデオプロセッサを含み得る１又は複数のコプロセッサ１３２２０のセットと、スタティックランダムアクセスメモリ（ＳＲＡＭ）ユニット１３２３０と、ダイレクトメモリアクセス（ＤＭＡ）ユニット１３２３２と、１又は複数の外部ディスプレイに結合するためのディスプレイユニット１３２４０とに結合される。一実施形態において、コプロセッサ１３２２０は、例えば、ネットワーク又は通信プロセッサ、圧縮エンジン、ＧＰＧＰＵ、ハイスループットＭＩＣプロセッサ又は埋め込み型プロセッサなどの特定用途プロセッサを含む。
【１０７６】
本明細書で開示されるメカニズムについての実施形態は、ハードウェア、ソフトウェア、ファームウェア又はそのような実装アプローチの組み合わせで実装されてよい。本発明の実施形態は、少なくとも１つのプロセッサ、ストレージシステム（揮発性及び不揮発性メモリ、及び／又は、ストレージエレメントを含む）、少なくとも１つの入力デバイス及び少なくとも１つの出力デバイスを有するプログラマブルシステム上で実行するコンピュータプログラム又はプログラムコードとして実装されてよい。
【１０７７】
プログラムコード、例えば、図１３０に示されるコード１３０３０は、本明細書で説明される機能を実行し、出力情報を生成するための入力命令に適用されてよい。出力情報は、既知の様式で、１又は複数の出力デバイスに適用されてよい。本願の目的のために、処理システムは、例えば、デジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）又はマイクロプロセッサなどのプロセッサを有する任意のシステムを含む。
【１０７８】
プログラムコードは、処理システムと通信するために、高水準手続き型又はオブジェクト指向プログラミング言語で実装されてよい。プログラムコードは、必要に応じて、アセンブリ言語又は機械語で実装されてもよい。実際には、本明細書で説明されるメカニズムは、任意の特定のプログラミング言語の範囲に限定されない。いずれの場合でも、言語は、コンパイル型言語又はインタープリタ型言語であってよい。
【１０７９】
少なくとも１つの実施形態のうちの１又は複数の態様では、マシンにより読み出される場合、本明細書で説明される技術を実行するために、マシンに論理を構築させるプロセッサ内の様々な論理を表す機械可読媒体上に格納された代表的な命令により実施されてよい。「ＩＰコア」として知られるそのような表現は、有形の機械可読媒体上に格納され、論理又はプロセッサを実際に作る製造マシンにロードするために、様々な顧客又は製造施設に供給されてよい。
【１０８０】
そのような機械可読記憶媒体は、制限なく、マシン又はデバイスにより製造又は形成される非一時的な有形の構成をした物品を含んでよく、ハードディスク、フロッピーディスクを含むその他のタイプのディスク、光ディスク、コンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）、コンパクトディスクリライタブル（ＣＤ−ＲＷ）、及び、磁気−光ディスクなどの記憶媒体と、リードオンリメモリ（ＲＯＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、フラッシュメモリ、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、相変化メモリ（ＰＣＭ）、磁気又は光カードなどの半導体デバイスと、又は、電子的命令を格納するのに適したその他のタイプの媒体とを含む。
【１０８１】
状況に応じて、本発明の実施形態は又はドウェア記述言語（ＨＤＬ）などの命令を含む又は設計データを含む非一時的な有形の機械可読媒体を含み、本明細書で説明される構造、回路、装置、プロセッサ及び／又はシステム機能を定義する。そのような実施形態では、プログラム製品とも称されてよい。
エミュレーション（バイナリ変換、コード、モーフィングなどを含む）
【１０８２】
いくつかの場合では、ソース命令セットからターゲット命令セットに命令を変換するために、命令変換器が用いられてよい。例えば、命令変換器は、コアにより処理されるために、命令を１又は複数の他の命令に、変換（例えば、静的なバイナリ変換、動的なコンパイルを含む動的なバイナリ変換を用いる）、モーフィング、エミュレート又は別の方法でコンバートしてよい。命令変換器は、ソフトウェア、ハードウェア、ファームウェア又はそれらの組み合わせで実装されてよい。命令変換器は、プロセッサ上、プロセッサ外、又は、プロセッサ上の一部及びプロセッサ外の一部にあってよい。
【１０８３】
図１３３は、本発明の実施形態に係る、ソース命令セット内のバイナリ命令をターゲット命令セット内のバイナリ命令に変換するソフトウェア命令変換器の利用を対比するブロック図である。例示された実施形態では、命令変換器はソフトウェア命令変換器であるが、代替的に、命令変換器は、ソフトウェア、ファームウェア、ハードウェア又はそれらの様々な組み合わせで実装されてよい。図１３３は、少なくとも１つのｘ８６命令セットコア１３３１６を有するプロセッサにより実質的に実行され得るｘ８６バイナリコード１３３０６を生成するために、高水準言語１３３０２におけるプログラムがｘ８６コンパイラ１３３０４を用いてコンパイルされ得ることを示す。少なくとも１つのｘ８６命令セットコア１３３１６を有するプロセッサは、少なくとも１つのｘ８６命令セットコアを有するインテル（登録商標）プロセッサと実質的に同じ結果を実現するために、（１）インテル（登録商標）ｘ８６命令セットコアの命令セットの実質的な部分、又は、（２）少なくとも１つのｘ８６命令セットコアを有するインテル（登録商標）プロセッサ上で実行することを目的としたアプリケーション又は他のソフトウェアのオブジェクトコードのバージョンを、互換性のある状態で実行する又は別の方法で処理することにより、少なくとも１つのｘ８６命令セットコアを有するインテル（登録商標）プロセッサと同じ機能を実質的に実行できる任意のプロセッサを表す。ｘ８６コンパイラ１３３０４は、追加のリンケージ処理を用いて又はこれを用いることなく、少なくとも１つのｘ８６命令セットコア１３３１６を有するプロセッサ上で実行され得るｘ８６バイナリコード１３３０６（例えば、オブジェクトコード）を生成するように動作可能なコンパイラを表す。同様に、図１３３は、高水準言語１３３０２におけるプログラムが、少なくとも１つのｘ８６命令セットコア１３３１４（例えば、カリフォルニア州サニーベールの命令セットＭＩＰＳ技術のＭＩＰＳを実行する、及び／又は、カリフォルニア州サニーベールのＡＲＭホールディングスのＡＲＭ命令セットを実行するコアを有するプロセッサ）なしのプロセッサによりネイティブに実行され得る代替的な命令セットのバイナリコード１３３１０を生成するために、代替的な命令セットのコンパイラ１３３０８を用いてコンパイルされてよいことを示す。命令変換器１３３１２は、ｘ８６命令セットコア１３３１４なしのプロセッサによりネイティブに実行され得るコードにｘ８６バイナリコード１３３０６を変換するために用いられる。この変換済みコードは、これができる命令変換器が作成するのが難しいので、代替的な命令セットのバイナリコード１３３１０と同じである可能性が低い。しかしながら、変換済みコードは、一般的なオペレーションを実現し、代替的な命令セットからの命令で構成される。したがって、命令変換器１３３１２は、エミュレーション、シミュレーション又はその他の処理を通じてｘ８６命令セットプロセッサ又はコアを有していないプロセッサ又は他の電子デバイスが、ｘ８６バイナリコード１３３０６を実行することを可能にするソフトウェア、ファームウェア、ハードウェア又はそれらの組み合わせを表す。
【１０８４】
機能及び態様の例示的な実装、実施形態及び特定の組み合わせが以下に詳細に説明される。これらの例は、有益なものであるが限定するものではない。
【１０８５】
例１．複数のヘテロジニアス処理要素と、複数のヘテロジニアス処理要素のうちの１又は複数の実行のために命令のディスパッチを行うハードウェアヘテロジニアススケジューラであって、命令は、複数のヘテロジニアス処理要素のうちの１又は複数により処理されるコードフラグメントに対応し、命令は、複数のヘテロジニアス処理要素の１又は複数のうちの少なくとも１つに対するネイティブ命令である、ハードウェアヘテロジニアススケジューラとを含むシステム。
【１０８６】
例２：複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例１に記載のシステム。
【１０８７】
例３：複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例２に記載のシステム。
【１０８８】
例４：ハードウェアヘテロジニアススケジューラは、コードフラグメントのプログラムフェーズを検出するプログラムフェーズ検出器をさらに含み、複数のヘテロジニアス処理要素は、第１のマイクロアーキテクチャを有する第１の処理要素、及び、第１のマイクロアーキテクチャとは異なる第２のマイクロアーキテクチャを有する第２の処理要素を含み、プログラムフェーズは、第１のフェーズ及び第２のフェーズを含む複数のプログラムフェーズのうちの１つであり、命令のディスパッチは、検出されたプログラムフェーズに部分的に基づいており、第１の処理要素によるコードフラグメントの処理は、第２の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例１−３のいずれかに記載のシステム。
【１０８９】
例５：ハードウェアヘテロジニアススケジューラは、受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、ディスパッチを用いて、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングするセレクタをさらに備える、例１−４のいずれかに記載のシステム。
【１０９０】
例６：コードフラグメントは、ソフトウェアスレッドと関連付けられた１又は複数の命令である、例１に記載のシステム。
【１０９１】
例７：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例５−６のいずれかに記載のシステム。
【１０９２】
例８：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例５−７のいずれかに記載のシステム。
【１０９３】
例９：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例５−７のいずれかに記載のシステム。
【１０９４】
例１０：データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素を有する、例５−９のいずれかに記載のシステム。
【１０９５】
例１１：スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例５−１０のいずれかに記載のシステム。
【１０９６】
例１２：スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐を有する、例５−１１のいずれかに記載のシステム。
【１０９７】
例１３：直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアである、例２−１２のいずれかに記載のシステム。
【１０９８】
例１４：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例２−１３のいずれかに記載のシステム。
【１０９９】
例１５：ハードウェアヘテロジニアススケジューラは、コンパイル、組み込み関数（ｉｎｔｒｉｎｓｉｃ）、アセンブリ、ライブラリ、中間、オフロード及びデバイスを含む複数のコードタイプをサポートする、例１−１４のいずれかに記載のシステム。
【１１００】
例１６：ハードウェアヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例５−１５のいずれかに記載のシステム。
【１１０１】
例１７：ハードウェアヘテロジニアススケジューラは、利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする、例１−１５のいずれかに記載のシステム。
【１１０２】
例１８：ハードウェアヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例５−１５のいずれかに記載のシステム。
【１１０３】
例１９：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例５−１８のいずれかに記載のシステム。
【１１０４】
例２０：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例５−１９のいずれかに記載のシステム。
【１１０５】
例２１：ハードウェアヘテロジニアススケジューラは、各スレッドがスカラコア上で実行中であるかのようにプログラマに見えるようにするべく、ホモジニアスマルチプロセッサプログラミングモデルを提示する、例１−２０のいずれかに記載のシステム。
【１１０６】
例２２：提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例２１に記載のシステム。
【１１０７】
例２３：複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例１−２２のいずれかに記載のシステム。
【１１０８】
例２４：ハードウェアヘテロジニアススケジューラは、複数のヘテロジニアス処理要素のうちの１つで実行されるバイナリトランスレータを含む、例１−２３のいずれかに記載のシステム。
【１１０９】
例２５：複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例５−２４のいずれかに記載のシステム。
【１１１０】
例２６：ヘテロジニアスハードウェアスケジューラは、ディスパッチされた命令に対してマルチプロトコルインタフェースで用いるプロトコルを選択する、例１−２５のいずれかに記載のシステム。
【１１１１】
例２７：マルチプロトコルバスインタフェースによりサポートされている第１のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例２６のいずれかに記載のシステム。
【１１１２】
例２８：マルチプロトコルバスインタフェースによりサポートされる第２のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例２６−２７のいずれかに記載のシステム。
【１１１３】
例２９：マルチプロトコルバスインタフェースによりサポートされる第３のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例２６−２８のいずれかに記載のシステム。
【１１１４】
例３０：第３のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス（ＰＣＩｅ）プロトコルを有する、例２９に記載のシステム。
【１１１５】
例３１：アクセラレータを含むヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素と、ヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素のうちの少なくとも１つにより実行可能されるプログラムコードを格納するメモリとを含み、プログラムコードは、複数のヘテロジニアス処理要素のうちの１又は複数の実行のために命令のディスパッチを行うヘテロジニアススケジューラであって、命令は、複数のヘテロジニアス処理要素のうちの１又は複数により処理されるコードフラグメントに対応し、命令は、複数のヘテロジニアス処理要素の１又は複数のうちの少なくとも１つに対するネイティブ命令である、ヘテロジニアススケジューラとを含むシステム。
【１１１６】
例３２：複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例３１に記載のシステム。
【１１１７】
例３３：複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例３２に記載のシステム。
【１１１８】
例３４：ヘテロジニアススケジューラは、コードフラグメントのプログラムフェーズを検出するプログラムフェーズ検出器をさらに含み、複数のヘテロジニアス処理要素は、第１のマイクロアーキテクチャを有する第１の処理要素、及び、第１のマイクロアーキテクチャとは異なる第２のマイクロアーキテクチャを有する第２の処理要素を含み、プログラムフェーズは、第１のフェーズ及び第２のフェーズを含む複数のプログラムフェーズのうちの１つであり、命令のディスパッチは、検出したプログラムフェーズに部分的に基づいており、第１の処理要素によるコードフラグメントの処理は、第２の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例３１−３３のいずれかに記載のシステム。
【１１１９】
例３５：ヘテロジニアススケジューラは、受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、ディスパッチを用いて、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングするセレクタをさらに備える、例３１−３４のいずれかに記載のシステム。
【１１２０】
例３６：コードフラグメントは、ソフトウェアスレッドと関連付けられた１又は複数の命令である、例３１−３５のいずれかに記載のシステム。
【１１２１】
例３７：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例３４−３６のいずれかに記載のシステム。
【１１２２】
例３８：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例３４−３７のいずれかに記載のシステム。
【１１２３】
例３９：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例３４−３８のいずれかに記載のシステム。
【１１２４】
例４０：データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素を有する、例３４−３９のいずれかに記載のシステム。
【１１２５】
例４１：スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例３０−３５のいずれかに記載のシステム。
【１１２６】
例４２：スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐を有する、例３０−３６のいずれかに記載のシステム。
【１１２７】
例４３：直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアである、例３０−３７のいずれかに記載のシステム。
【１１２８】
例４４：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例３０−３８のいずれかに記載のシステム。
【１１２９】
例４５：ヘテロジニアススケジューラは、コンパイル、組み込み関数（ｉｎｔｒｉｎｓｉｃ）、アセンブリ、ライブラリ、中間、オフロード及びデバイスを含む複数のコードタイプをサポートする、例３１−４４のいずれかに記載のシステム。
【１１３０】
例４６：ヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例３１−４５のいずれかに記載のシステム。
【１１３１】
例４７：ヘテロジニアススケジューラは、利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする、例３１−４６のいずれかに記載のシステム。
【１１３２】
例４８：ヘテロジニアススケジューラは、選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする、例３１−４７のいずれかに記載のシステム。
【１１３３】
例５０：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例３１−４９のいずれかに記載のシステム。
【１１３４】
例５１：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例３１−５０のいずれかに記載のシステム。
【１１３５】
例５２：ヘテロジニアススケジューラは、各スレッドがスカラコア上で実行中であるかのようにプログラマに見えるようにするべく、ホモジニアスプログラミングモデルを提示する、例３１−５１のいずれかに記載のシステム。
【１１３６】
例５３：提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例５２のいずれかに記載のシステム。
【１１３７】
例５４ａ：複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例３１−５３のいずれかに記載のシステム。
【１１３８】
例５４ｂ：ヘテロジニアススケジューラは、複数のヘテロジニアス処理要素のうちの１つで実行されるバイナリトランスレータを含む、例３１−５３のいずれかに記載のシステム。
【１１３９】
例５５：複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例３１−５４のいずれかに記載のシステム。
【１１４０】
例５６：ヘテロジニアスソフトウェアスケジューラは、ディスパッチされた命令に対してマルチプロトコルインタフェースで用いるプロトコルを選択する、例３１−５５のいずれかに記載のシステム。
【１１４１】
例５７：マルチプロトコルバスインタフェースによりサポートされる第１のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例５６のいずれかに記載のシステム。
【１１４２】
例５８：マルチプロトコルバスインタフェースによりサポートされる第２のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例５６−５７のいずれかに記載のシステム。
【１１４３】
例５９：マルチプロトコルバスインタフェースによりサポートされる第３のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例５６−５８のいずれかに記載のシステム。
【１１４４】
例６０：第３のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス（ＰＣＩｅ）プロトコルを有する、例５９に記載のシステム。
【１１４５】
例６１：複数の命令を受信する段階と、複数のヘテロジニアス処理要素のうちの１又は複数の実行のために、受信した複数の命令をディスパッチする段階であって、受信した複数の命令は、複数のヘテロジニアス処理要素のうちの１又は複数により処理されるコードフラグメントに対応し、その結果、複数の命令は、複数のヘテロジニアス処理要素の１又は複数のうちの少なくとも１つに対するネイティブ命令である、段階とを含む方法。
【１１４６】
例６２：複数のヘテロジニアス処理要素は、インオーダプロセッサコア、アウトオブオーダプロセッサコア及びパックドデータプロセッサコアを有する、例６１に記載の方法。
【１１４７】
例６３：複数のヘテロジニアス処理要素は、アクセラレータをさらに有する、例６２に記載の方法。
【１１４８】
例６４：コードフラグメントのプログラムフェーズを検出する段階をさらに含み、複数のヘテロジニアス処理要素は、第１のマイクロアーキテクチャを有する第１の処理要素、及び、第１のマイクロアーキテクチャとは異なる第２のマイクロアーキテクチャを有する第２の処理要素を含み、プログラムフェーズは、第１のフェーズ及び第２のフェーズを含む複数のプログラムフェーズのうちの１つであり、第１の処理要素によりコードフラグメントの処理は、第２の処理要素によるコードフラグメントの処理と比較してワット性能特性を改善する、例６１−６３のいずれかに記載の方法。
【１１４９】
例６５：受信したコードフラグメントを実行するために、複数の処理要素についての処理要素のタイプを選択し、複数の処理要素のうち選択されたタイプの処理要素にコードフラグメントをスケジューリングする段階をさらに含む、例６１−６４のいずれかに記載の方法。
【１１５０】
例６６：コードフラグメントは、ソフトウェアスレッドと関連付けられた１又は複数の命令である、例６１−６３のいずれかに記載の方法。
【１１５１】
例６７：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例６４−６６のいずれかに記載の方法。
【１１５２】
例６８：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、密な算術のプリミティブをサポートする回路である、例６４−６６のいずれかに記載の方法。
【１１５３】
例６９：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、アクセラレータである、例６４−６８のいずれかに記載の方法。
【１１５４】
例７０：データ並列プログラムフェーズは、同じ制御フローを同時に用いて処理されるデータ要素により特徴付けられる、例６４−６９のいずれかに記載の方法。
【１１５５】
例７１：スレッド並列プログラムフェーズの場合、処理要素の選択されたタイプは、スカラ処理コアである、例６４−７０のいずれかに記載の方法。
【１１５６】
例７２：スレッド並列プログラムフェーズは、一意的な制御フローを用いるデータ依存の分岐により特徴付けられる、例６４−７１のいずれかに記載の方法。
【１１５７】
例７３：直列プログラムフェーズの場合、処理要素の選択されたタイプは、アウトオブオーダコアでる、例６４−７２のいずれかに記載の方法。
【１１５８】
例７４：データ並列プログラムフェーズの場合、処理要素の選択されたタイプは、単一命令複数データ（ＳＩＭＤ）命令を実行する処理コアである、例６４−７３のいずれかに記載の方法。
【１１５９】
例７５：選択されたタイプの処理要素がコードフラグメントをネイティブに処理できない場合、機能をエミュレートする段階をさらに含む、例６１−７４のいずれかに記載の方法。
【１１６０】
例７６：利用可能なハードウェアスレッドの数がオーバサブスクライブされている場合、機能をエミュレートする段階をさらに含む、例６１−７４のいずれかに記載の方法。
【１１６１】
例７７：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、ユーザに対して透過的である、例６１−７６のいずれかに記載の方法。
【１１６２】
例７８：複数のヘテロジニアス処理要素についての処理要素のタイプの選択は、オペレーティングシステムに対して透過的である、例６１−７７のいずれかに記載の方法。
【１１６３】
例７９：各スレッドがスカラコア上で実行中であるかのように見えるようにするべく、ホモジニアスマルチプロセッサプログラミングモデルを提示する段階をさらに含む、例６１−７４のいずれかに記載の方法。
【１１６４】
例８０：提示されたホモジニアスマルチプロセッサプログラミングモデルは、完全な命令セットに対するサポートの出現を提示する、例７９に記載の方法。
【１１６５】
例８１：複数のヘテロジニアス処理要素は、メモリアドレス空間を共有する、例６１−７９のいずれかに記載の方法。
【１１６６】
例８２：複数のヘテロジニアス処理要素のうちの１つで実行されるコードフラグメントをバイナリ変換する段階をさらに含む、例６１−８１のいずれかに記載の方法。
【１１６７】
例８３：複数のヘテロジニアス処理要素についての処理要素のタイプのデフォルト選択は、レイテンシが最適化されたコアである、例６１−８２のいずれかに記載の方法。
【１１６８】
例８４：ハードウェアにより実行される場合に、プロセッサが、例５１−８３のうちの１つに記載の方法を実行する命令を格納する非一時的な機械可読媒体。
【１１６９】
例８５：ヘテロジニアススケジューラにおいてコードフラグメントを受信する段階と、コードフラグメントが並列フェーズにあるか否かを判断する段階と、コードフラグメントが並列フェーズにない場合、レイテンシに敏感なオペレーション要素を選択してコードフラグメントを実行する段階と、コードフラグメントが並列フェーズにある場合、並列性のタイプを判断し、及びスレッド並列コードフラグメントに関して、スカラ処理要素を選択してコードフラグメントを実行する段階と、データ並列コードフラグメントに関して、データ並列コードフラグメントのデータレイアウトを判断する段階と、パックドデータレイアウトに関して、単一命令複数データ（ＳＩＭＤ）処理要素及び算術プリミティブ処理要素のうちの１つを選択し、ランダムデータレイアウトに関して、ギャザー命令、空間計算アレイ、又は、複数のスカラコアのアレイから１つのスカラコアを用いるＳＩＭＤ処理要素のうちの１つを選択する段階と、実行のために処理要素にコードフラグメントを送信する段階とを含む方法。
【１１７０】
例８６：コードフラグメントが並列フェーズにあるか否かを判断する段階の前に、コードフラグメントがアクセラレータへのオフロードの対象となるときを判断する段階と、コードフラグメントがオフロードの対象となったときに、アクセラレータにコードフラグメントを送信する段階とをさらに含む、例８５に記載の方法。
【１１７１】
例８７：コードフラグメントが並列フェーズにあるか否かを判断する段階は、検出されたデータの依存性、命令タイプ及び制御フロー命令のうちの１又は複数に基づいている、例８５−８６のいずれかに記載の方法。
【１１７２】
例８８：単一の命令、複数のデータ命令についての命令のタイプは、並列フェーズを示す、例８７に記載の方法。
【１１７３】
例８９：ヘテロジニアススケジューラにより処理される各オペレーティングシステムスレッドは、論理スレッド識別子が割り当てられる、例８５−８８のいずれかに記載の方法。
【１１７４】
例９０：ヘテロジニアススケジューラは、処理要素タイプ、処理要素識別子及びスレッド識別子から成るタプルに各論理スレッド識別子がマッピングされるように、論理スレッド識別子の縞模様マッピングを利用する、例８９に記載の方法。
【１１７５】
例９１：論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、除算及びモジュロを用いて計算される、例９０に記載の方法。
【１１７６】
例９２：論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、スレッドの共通性を保つために固定される、例９１に記載の方法。
【１１７７】
例９３：論理スレッド識別子から処理要素タイプへのマッピングは、ヘテロジニアススケジューラにより実行される、例９０に記載の方法。
【１１７８】
例９４：論理スレッド識別子から処理要素タイプへのマッピングは、将来の処理要素タイプに順応するように柔軟である、例９３に記載の方法。
【１１７９】
例９５：ヘテロジニアススケジューラは、少なくとも１つのアウトオブオーダタプル、及び、同じアウトオブオーダタプルに論理スレッド識別子がマッピングするスカラ及びＳＩＭＤタプルを複数のコアグループのうちの少なくとも１つが有するように、複数のコアグループを利用する、例９１に記載の方法。
【１１８０】
例９６：複数のコアグループのうちの１つに属するスレッド間で一意的なページディレクトリベースレジスタ値を有するスレッドにより、非並列フェーズが判断される、例９５に記載の方法。
【１１８１】
例９７：処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する、例９６に記載の方法。
【１１８２】
例９８：イベントを検出する段階であって、イベントは、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込、スリープコマンド、スレッドのフェーズ変更、異なるコアへの所望の再割り当てを示す１又は複数の命令のうちの１つである、段階をさらに含む、例８５−９７のいずれかに記載の方法。
【１１８３】
例９９：イベントがスレッドウェイクアップコマンドである場合、コードフラグメントが並列フェーズにあると判断して、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数をカウントする段階と、カウントされた処理要素の数が１より大きいか否かを判断する段階であって、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが１である場合、当該スレッドは直列フェーズであり、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが１ではない場合、当該スレッドは並列フェーズにある、段階をさらに含む、例９８に記載の方法。
【１１８４】
例１００：イベントがスレッドスリープコマンドである場合、スレッドと関連付けられた実行フラグをクリアする段階と、影響を受けるスレッドと同じページテーブルベースポインタを共有する処理要素のスレッドの数をカウントする段階と、アウトオブオーダ処理要素がアイドルであるか否かを判断する段階とをさらに含み、ページテーブルベースポインタがコアグループ内のちょうど１つのスレッドにより共有されている場合、その共有しているスレッドがアウトオブオーダ処理要素から移動され、ページテーブルベースポインタが１つより多くのスレッドにより共有されている場合、コアグループの第１の実行スレッドがアウトオブオーダ処理要素に移行される、例９８に記載の方法。
【１１８５】
例１０１：スレッドスリープコマンドは、停止、待ちエントリ及びタイムアウト又は一時停止コマンドのうちの１つである、例１００に記載の方法。
【１１８６】
例１０２：イベントがフェーズ変更である場合、スカラ処理要素上でスレッドが実行中であり、かつ、ＳＩＭＤ命令があることをスレッドの論理スレッド識別子が示す場合、当該スレッドをＳＩＭＤ処理要素に移行する段階と、ＳＩＭＤ処理要素上でスレッドが実行中であり、かつ、ＳＩＭＤ命令がないことをスレッドの論理スレッド識別子が示す場合、当該スレッドをスカラ処理要素に移行する段階とをさらに含む、例９８に記載の方法。
【１１８７】
例１０３：コードフラグメントを送信する前に、選択された処理要素をより良く適合させるようにコードフラグメントを変換する段階をさらに含む、例８５−１０２のいずれかに記載の方法。
【１１８８】
例１０４：ヘテロジニアススケジューラは、変換を実行するバイナリトランスレータを含む、例１０３に記載の方法。
【１１８９】
例１０５：ヘテロジニアススケジューラは、変換を実行するＪＩＴコンパイラを含む、例１０３に記載の方法。
【１１９０】
例１０６：方法は、例６１−８３についての方法の例のうちのいずれかの方法の段階をさらに備える、例８５−１０５のいずれかに記載の方法。
【１１９１】
例１０７：複数のヘテロジニアス処理要素と、コードフラグメントのフェーズを判断して、判断されたフェーズに少なくとも部分的に基づく実行のために複数のヘテロジニアス処理要素のうちの１つにコードフラグメントを送信するヘテロジニアススケジューラとを含むシステム。
【１１９２】
例１０８：ヘテロジニアススケジューラは、コードフラグメントが並列フェーズにあるか否かを判断し、コードフラグメントが並列フェーズにない場合、レイテンシに敏感なオペレーション要素を選択してコードフラグメントを実行し、コードフラグメントが並列フェーズにある場合、並列性のタイプを判断し、スレッド並列コードフラグメントに関して、スカラ処理要素を選択してコードフラグメントを実行し、データ並列コードフラグメントに関して、データ並列コードフラグメントのデータレイアウトを判断し、パックドデータレイアウトに関して、単一命令複数データ（ＳＩＭＤ）処理要素及び算術プリミティブ処理要素のうちの１つを選択し、ランダムデータレイアウトに関して、ギャザー命令、空間計算アレイ、又は、複数のスカラコアのアレイから１つのスカラコアを用いるＳＩＭＤ処理要素のうちの１つを選択する、例１０７に記載のシステム。
【１１９３】
例１０９：ヘテロジニアススケジューラは、さらに、コードフラグメントが並列フェーズにあるか否かを判断する前に、いつコードフラグメントがアクセラレータへのオフロードの対象になるかを判断し、コードフラグメントがオフロードの対象になったときに、アクセラレータにコードフラグメントを送信する、例１０８に記載のシステム。
【１１９４】
例１１０：ヘテロジニアススケジューラは、さらに、検出されたデータの依存性、命令タイプ及び制御フロー命令のうちの１又は複数に基づいて、コードフラグメントが並列フェーズにあるか否かを判断する、例１０８−１０９のいずれかに記載のシステム。
【１１９５】
例１１１：単一の命令、複数のデータ命令についての命令のタイプは、並列フェーズを示す、例１１０に記載のシステム。
【１１９６】
例１１２：ヘテロジニアススケジューラにより処理される各オペレーティングシステムスレッドは、論理スレッド識別子が割り当てられる、例１０８−１１１のいずれかに記載のシステム。
【１１９７】
例１１３：ヘテロジニアススケジューラは、処理要素タイプ、処理要素識別子及びスレッド識別子から成るタプルに各論理スレッド識別子がマッピングされるように、論理スレッド識別子の縞模様マッピングを利用する、例１１２に記載のシステム。
【１１９８】
例１１４：論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、除算及びモジュロを用いて計算される、例１１２に記載のシステム。
【１１９９】
例１１５：論理スレッド識別子から処理要素識別子及びスレッド識別子へのマッピングは、スレッドの共通性を保つために固定される、例１１４に記載のシステム。
【１２００】
例１１６：論理スレッド識別子から処理要素タイプへのマッピングは、ヘテロジニアススケジューラにより実行される、例１１５に記載のシステム。
【１２０１】
例１１７：論理スレッド識別子から処理要素タイプへのマッピングは、将来の処理要素タイプに順応するように柔軟である、例１１６に記載のシステム。
【１２０２】
例１１８：ヘテロジニアススケジューラは、少なくとも１つのアウトオブオーダタプル、及び、同じアウトオブオーダタプルに論理スレッド識別子がマッピングするスカラ及びＳＩＭＤタプルをコアグループが有するように、コアグループを利用する、例１０８−１１７のいずれかに記載のシステム。
【１２０３】
例１１９：複数のコアグループのうちの１つに属するスレッド間で一意的なページディレクトリベースレジスタ値を有するスレッドにより、非並列フェーズが判断される、例１１８に記載のシステム。
【１２０４】
例１２０：処理に属するスレッドは、同じアドレス空間、ページテーブル及びページディレクトリベースレジスタ値を共有する、例１１９に記載のシステム。
【１２０５】
例１２１：ヘテロジニアススケジューラは、イベントを検出し、当該イベントは、スレッドウェイクアップコマンド、ページディレクトリベースレジスタへの書き込み、スリープコマンド、スレッドのフェーズ変更及び所望の再割り当てを示す１又は複数の命令のうちの１つである、例１０８−１２０のいずれかに記載のシステム。
【１２０６】
例１２２：ヘテロジニアススケジューラは、イベントがスレッドウェイクアップコマンドである場合、コードフラグメントが並列フェーズにあると判断して、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数をカウントし、カウントされた処理要素の数が１より大きいか否かを判断し、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが１である場合、当該スレッドは直列フェーズにあり、ウェイクアップしたスレッドと同じページテーブルベースポインタを共有する処理要素の数のカウントが１ではない場合、当該スレッドは並列フェーズにある、例１２１に記載のシステム。
【１２０７】
例１２３：ヘテロジニアススケジューラは、イベントがスレッドスリープコマンドである場合、スレッドと関連付けられている実行フラグをクリアし、影響を受けるスレッドと同じページテーブルベースポインタを共有する処理要素のスレッドの数をカウントし、アウトオブオーダ処理要素がアイドルであるか否かを判断し、ページテーブルベースポインタがコアグループ内のちょうど１つのスレッドにより共有されている場合、その共有しているスレッドがアウトオブオーダ処理要素から移動され、ページテーブルベースポインタが１つより多くのスレッドにより共有されている場合、グループの第１の実行スレッドがアウトオブオーダ処理要素に移行される、例１２１に記載のシステム。
【１２０８】
例１２４：スレッドスリープコマンドは、停止、待ちエントリ及びタイムアウト又は一時停止コマンドのうちの１つである、例１２３に記載のシステム。
【１２０９】
例１２５：ヘテロジニアススケジューラは、イベントがフェーズ変更である場合、スカラ処理要素上でスレッドが実行中であり、かつ、ＳＩＭＤ命令があることをスレッドの論理スレッド識別子が示す場合、当該スレッドをＳＩＭＤ処理要素に移行し、ＳＩＭＤ処理要素上でスレッドが実行中であり、かつ、ＳＩＭＤ命令がないことをスレッドの論理スレッド識別子が示す場合、当該スレッドをスカラ処理要素に移行する、例１２１に記載のシステム。
【１２１０】
例１２６：ヘテロジニアススケジューラは、コードフラグメントを送信する前に、選択された処理要素をより良く適合させるようにコードフラグメントを変換する、例１０８−１２５のいずれかに記載のシステム。
【１２１１】
例１２７：ヘテロジニアススケジューラは、実行されると変換を実行するために、非一時的な機械可読媒体に格納されるバイナリトランスレータを含む、例１２６に記載のシステム。
【１２１２】
例１２８：ヘテロジニアススケジューラは、実行されると変換を実行するために、非一時的な機械可読媒体に格納されるＪＩＴコンパイラを含む、例１２６に記載のシステム。
【１２１３】
例１２９：ヘテロジニアススケジューラを提供するヘテロジニアプロセッサ内の複数のヘテロジニアス処理要素のうちの少なくとも１つにより実行可能なプログラムコードを格納するメモリをさらに含む、例１０８−１２８のいずれかに記載のシステム。
【１２１４】
例１３０：ヘテロジニアススケジューラは回路を有する、例１０８−１２８のいずれかに記載のシステム。
【１２１５】
例１３１：プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな少なくとも１つの命令をデコードするデコーダと、少なくとも１つのデコードされた命令を実行する１又は複数の実行ユニットであって、少なくとも１つのデコードされた命令は加速開始命令に対応し、加速開始命令はアクセラレータにオフロードされるコードの領域の開始を示す、１又は複数の実行ユニットとを含むプロセッサ。
【１２１６】
例１３２：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１３１に記載のプロセッサ。
【１２１７】
例１３３：加速開始命令に対応する少なくとも１つのデコードされた命令の実行に応じて、プロセッサコアは、実行の第１のモードから実行の第２のモードに遷移する、例１３１に記載のプロセッサ。
【１２１８】
例１３４：実行の第１のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例１３３に記載のプロセッサ。
【１２１９】
例１３５：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１３４に記載のプロセッサ。
【１２２０】
例１３６：実行の第１のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例１３３−１３５のいずれか１つに記載のプロセッサ。
【１２２１】
例１３７：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１３３−１３６のいずれか１つに記載のプロセッサ。
【１２２２】
例１３８：プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速開始命令に対応するデコードされた命令を実行する段階であって、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、段階とを含み方法。
【１２２３】
例１３９：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１３８に記載の方法。
【１２２４】
例１４０：加速開始命令に対応するデコードされた命令の実行に応じて、プロセッサコアは、実行の第１のモードから実行の第２のモードに遷移する、例１３８に記載の方法。
【１２２５】
例１４１：実行の第１のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例１４０に記載の方法。
【１２２６】
例１４２：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１４１に記載の方法。
【１２２７】
例１４３：実行の第１のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例１４０−１４２のいずれか１つに記載の方法。
【１２２８】
例１４４：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１４０−１４３のいずれか１つに記載の方法。
【１２２９】
例１４５：プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速開始命令に対応するデコードされた命令を実行する段階であって、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、段階とを含む、非一時的な機械可読媒体。
【１２３０】
例１４６：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１４５に記載の方法。
【１２３１】
例１４７：加速開始命令に対応するデコードされた命令の実行に応じて、プロセッサコアは、実行の第１のモードから実行の第２のモードに遷移する、例１４５に記載の方法。
【１２３２】
例１４８：実行の第１のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例１４７に記載の方法。
【１２３３】
例１４９：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１４８に記載の方法。
【１２３４】
例１５０：実行の第１のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例１４８−１４９のいずれか１つに記載の方法。
【１２３５】
例１５１：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１４８−１５０のいずれか１つに記載の方法。
【１２３６】
例１５２：プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな少なくとも１つの命令をデコードするデコーダと、少なくとも１つのデコードされた命令を実行する１又は複数の実行ユニットであって、少なくとも１つのデコードされた命令は加速開始命令に対応し、加速開始命令は、アクセラレータにオフロードされるコードの領域の開始を示す、１又は複数の実行ユニットとを含む、システム。
【１２３７】
例１５３：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１５２に記載のシステム。
【１２３８】
例１５４：加速開始命令に対応する少なくとも１つのデコードされた命令の実行に応じて、プロセッサコアは、実行の第１のモードから実行の第２のモードに遷移する、例１５２に記載のシステム。
【１２３９】
例１５５：実行の第１のモードにおいて、プロセッサコアは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサコアは、自己書き換えコードに対するチェックをディセーブルにする、例１５４に記載のシステム。
【１２４０】
例１５６：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１５５に記載のシステム。
【１２４１】
例１５７：実行の第１のモードにおいて、メモリ一貫性モデル制限は、メモリオーダリング要求を緩和することにより弱められる、例１５２−１５６のいずれか１つに記載のプロセッサ。
【１２４２】
例１５８：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１５２−１５７のいずれか１つに記載のプロセッサ。
【１２４３】
例１５９：プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな命令をデコードするデコーダと、加速終了命令に対応するデコードされた命令を実行する１又は複数の実行ユニットであって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、１又は複数の実行ユニットとを含むプロセッサ。
【１２４４】
例１６０：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１５９に記載のプロセッサ。
【１２４５】
例１６１：実行の第１のモードから実行の第２のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例１５９に記載のプロセッサ。
【１２４６】
例１６２：実行の第１のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例１６１に記載のプロセッサ。
【１２４７】
例１６３：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１６２に記載のプロセッサ。
【１２４８】
例１６４：実行の第１のモードにおいて、メモリ一貫性モデル制限が弱められる、例１６１−１６３のいずれか１つに記載のプロセッサ。
【１２４９】
例１６５：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１６１−１６４のいずれか１つに記載のプロセッサ。
【１２５０】
例１６６：アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例１５９−１６５のいずれか１つに記載のプロセッサ。
【１２５１】
例１６７：プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速終了命令に対応するデコードされた命令を実行する段階であって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、段階とを含む方法。
【１２５２】
例１６８：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１６７に記載の方法。
【１２５３】
例１６９：実行の第１のモードから実行の第２のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例１６７に記載の方法。
【１２５４】
例１７０：実行の第１のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例１６９に記載の方法。
【１２５５】
例１７１：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１７０に記載の方法。
【１２５６】
例１７２：実行の第１のモードにおいて、メモリ一貫性モデル制限が弱められる、例１６９−１７１のいずれか１つに記載の方法。
【１２５７】
例１７３：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１６９−１７２のいずれか１つに記載の方法。
【１２５８】
例１７４：アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例１６７−１７３のいずれか１つに記載の方法。
【１２５９】
例１７５：プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、プロセッサコアに対してネイティブな命令をデコーディングする段階と、加速終了命令に対応するデコードされた命令を実行する段階であって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、段階とを含む、非一時的な機械可読媒体。
【１２６０】
例１７６：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１７５に記載の非一時的な機械可読媒体。
【１２６１】
例１７７：実行の第１のモードから実行の第２のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例１７５に記載の非一時的な機械可読媒体。
【１２６２】
例１７８：実行の第１のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例１７７に記載の非一時的な機械可読媒体。
【１２６３】
例１７９：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１７８に記載の非一時的な機械可読媒体。
【１２６４】
例１８０：実行の第１のモードにおいて、メモリ一貫性モデル制限が弱められる、例１７７−１７９のいずれか１つに記載の非一時的な機械可読媒体。
【１２６５】
例１８１：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１７７−１８０のいずれか１つに記載の非一時的な機械可読媒体。
【１２６６】
例１８２：アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例１７５−１８１のいずれか１つに記載の非一時的な機械可読媒体。
【１２６７】
例１８３：プロセッサコアを含み、プロセッサコアは、プロセッサコアに対してネイティブな命令をデコードするデコーダと、加速終了命令に対応するデコードされた命令を実行する１又は複数の実行ユニットであって、加速終了命令は、アクセラレータにオフロードされるコードの領域の終了を示す、１又は複数の実行ユニットと、オフロードされた命令を実行するアクセラレータとを含むシステム。
【１２６８】
例１８４：コードの領域は、ターゲットアクセラレータがプロセッサコアに結合され、コードの領域を処理するために利用可能であるか否かに基づいてオフロードされ、コードの領域を受信及び処理するプロセッサコアにターゲットアクセラレータが結合されていない場合、コードの領域は、プロセッサコアにより処理される、例１８３に記載のシステム。
【１２６９】
例１８５：実行の第１のモードから実行の第２のモードにプロセッサコアを遷移させる加速開始命令に対応するデコードされた命令の実行により、コードの領域が記述される、例１８４に記載のシステム。
【１２７０】
例１８６：実行の第１のモードにおいて、プロセッサは、自己書き換えコードをチェックし、実行の第２のモードにおいて、プロセッサは、自己書き換えコードに対するチェックをディセーブルにする、例１８５に記載のシステム。
【１２７１】
例１８７：自己書き換えコードチェックをディセーブルにするために、自己書き換えコード検出回路がディセーブルにされる、例１８６に記載のシステム。
【１２７２】
例１８８：実行の第１のモードにおいて、メモリ一貫性モデル制限が弱められる、例１８５−１８７のいずれか１つに記載のシステム。
【１２７３】
例１８９：実行の第１のモードにおいて、浮動小数セマンティクスは、浮動小数点制御ワードレジスタを設定することにより変更される、例１８５−１８８のいずれか１つに記載のシステム。
【１２７４】
例１９０：アクセラレータ開始命令の実行は、アクセラレータ終了命令が実行されるまで、プロセッサコア上でコードの領域の実行をゲート制御する、例１８３−１９０のいずれか１つに記載のシステム。
【１２７５】
例１９１：スレッドを実行するアクセラレータを含むシステム。
【１２７６】
システムは、プロセッサコアと、ヘテロジニアススケジューラを実装するソフトウェアを内部に格納したメモリとを含み、プロセッサコアにより実行されるときに、ヘテロジニアススケジューラは、アクセラレータ上で可能な実行に適したスレッドにおいてコードシーケンスを検出し、検出されたコードシーケンスを実行するアクセラレータを選択し、検出されたコードシーケンスを選択されたアクセラレータに送信する。
【１２７７】
例１９２：アクセラレータによる実行に適していないスレッドのプログラムフェーズを実行する複数のヘテロジニアス処理要素をさらに含む、例１９１に記載のシステム。
【１２７８】
例１９３：ヘテロジニアススケジューラは、コードシーケンスをパターンの予め決定されたセットと比較することにより、コードシーケンスを認識するパターンマッチャをさらに有する、例１９１−１９２のいずれかに記載のシステム。
【１２７９】
例１９４：パターンの予め決定されたセットは、メモリに格納される、例１９３に記載のシステム。
【１２８０】
例１９５：ヘテロジニアススケジューラは、パターンマッチを有するコードを認識し、無視自己書き換えコードが無視されること、メモリ一貫性モデル制限を弱め、浮動小数セマンティクスを変更すること、パフォーマンスモニタリングを変更すること、アーキテクチャフラグの利用を変更することのうちの１又は複数を行うプロセッサコアを構成することによりスレッドと関連付けられた動作モードを調整するパフォーマンスモニタリングを用いる、例１９１−１９４のいずれかに記載のシステム。
【１２８１】
例１９６：ヘテロジニアススケジューラは、認識されたコードを、実行するアクセラレータに対するアクセラレータコードに変換する変換モジュールをさらに有する、例１９１−１９５のいずれかに記載のシステム。
【１２８２】
例１９７：プロセッサコアは、格納されたパターンを用いて、スレッド内のコードシーケンスを検出するパターンマッチング回路を有する、例１９１−１９６のいずれかに記載のシステム。
【１２８３】
例１９８：プロセッサコアは、システムにおいて実行している各スレッドの実行ステータスを維持する、例１９１−１９７のいずれかに記載のシステム。
【１２８４】
例１９９：ヘテロジニアススケジューラは、システムにおいて実行している各スレッドのステータスを維持する、例１９１−１９７のいずれかに記載のシステム。
【１２８５】
例２００：ヘテロジニアススケジューラは、プロセッサ要素情報、追跡されたスレッド及び検出されたコードシーケンスのうちの１又は複数に基づいて、アクセラレータを選択する、例１９１−１９９のいずれかに記載のシステム。
【１２８６】
例２０１：複数のヘテロジニアス処理要素と、複数の処理要素に結合されるヘテロジニアススケジューラ回路とを含み、ヘテロジニアススケジューラ回路は、実行中の各スレッド及び各処理要素の実行ステータスを維持するスレッド及び処理要素トラッカテーブルと、コードフラグメントを処理する複数のヘテロジニアス処理要素についての処理要素のタイプを選択して、スレッド及び処理要素トラッカからのステータス及び処理要素情報に基づいて、実行のために複数のヘテロジニアス処理要素のうちの１つ上でコードフラグメントをスケジューリングするセレクタとを含む、システム。
【１２８７】
例２０２：プロセッサコアにより実行可能なソフトウェアを格納するメモリをさらに含み、ソフトウェアは、ヘテロジニアススケジューラ回路に結合される複数のヘテロジニアス処理要素のうちの１つであるアクセラレータ上で可能な実行に対するスレッドにおけるコードシーケンスを検出する、例２０１に記載のシステム。
【１２８８】
例２０３：ソフトウェアパターンマッチャは、格納されたパターンからコードシーケンスを認識する、例２０２に記載のシステム。
【１２８９】
例２０４：ヘテロジニアススケジューラは、認識されたコードをアクセラレータコードに変換する、例２０１−２０３のいずれかに記載のシステム。
【１２９０】
例２０５：セレクタは、ヘテロジニアススケジューラ回路により実行される有限ステートマシンである、例２０１−２０４のいずれかに記載のシステム。
【１２９１】
例２０６：スレッドを実行する段階と、実行中のスレッド内のパターンを検出する段階と、認識されたパターンをアクセラレータコードに変換する段階と、変換されたパターンを実行のために利用可能なアクセラレータに転送する段階とを含む方法。
【１２９２】
例２０７：パターンは、ソフトウェアパターンマッチャを用いて認識される、例２０６に記載の方法。
【１２９３】
例２０８：パターンは、ハードウェアパターンマッチ回路を用いて認識される、例２０６に記載の方法。
【１２９４】
例２０９：スレッドを実行する段階と、実行中のスレッド内のパターンを検出する段階と、パターンに基づいた緩和要求を用いるために、スレッドと関連付けられた動作モードを調整する段階とを含む方法。
【１２９５】
例２１０：パターンは、ソフトウェアパターンマッチャを用いて認識される、例２０９に記載の方法。
【１２９６】
例２１１：パターンは、ハードウェアパターンマッチ回路を用いて認識される、例２０９に記載の方法。
【１２９７】
例２１２：調整された動作モードにおいて、自己書き換えコードが無視されること、メモリ一貫性モデル制限が弱められることと、浮動小数セマンティクスが変更されることと、パフォーマンスモニタリングが変更されることと、アーキテクチャフラグの利用が変更されることとのうちの、１又は複数が適用される、例２０９に記載の方法。
【１２９８】
例２１３：プロセッサコアに対してネイティブな命令をデコードするデコーダと、デコードされた命令を実行する１又は複数の実行ユニットであって、デコードされた命令の１又は複数は、加速開始命令に対応し、加速開始命令は、同じスレッド内の加速開始命令に従う命令に対する実行の異なるモードにエントリさせる、１又は複数の実行ユニットとを含むシステム。
【１２９９】
例２１４：加速開始命令は、メモリデータブロックに対するポインタを規定するフィールドを含み、メモリデータブロックのフォーマットは、割込み前の進み具合を示すシーケンス番号フィールドを含む、例２１３に記載のシステム。
【１３００】
例２１５：加速開始命令は、メモリに格納されたコードの予め定義された変換を規定するブロッククラス識別子フィールドを含む、例２１３−２１４のいずれかに記載のシステム。
【１３０１】
例２１６：加速開始命令は、実行のために用いられるハードウェアのタイプを示す実装識別子フィールドを含む、例２１３−２１５のいずれかに記載のシステム。
【１３０２】
例２１７：加速開始命令は、加速開始命令が実行した後に修正されるレジスタを格納する状態保存エリアのサイズ及びフォーマットを示す保存状態エリアサイズフィールドを含む、例２１３−２１６のいずれかに記載のシステム。
【１３０３】
例２１８：加速開始命令は、ローカルストレージエリアサイズ用のフィールドを含み、ローカルストレージエリアは、レジスタを超えたストレージ（ｓｔｏｒａｇｅ  ｂｅｙｏｎｄ  ｒｅｇｉｓｔｅｒ）を提供する、例２１３−２１７のいずれかに記載のシステム。
【１３０４】
例２１９：ローカルストレージエリアサイズは、加速開始命令の即値オペランドにより規定される、例２１８に記載のシステム。
【１３０５】
例２２０：ローカルストレージエリアは、加速開始命令に続く命令を除いてアクセスされない、例２１８に記載のシステム。
【１３０６】
例２２１：実行の異なるモード内の命令の場合、メモリ依存性タイプが定義可能である、例２１３−２２０のいずれかに記載のシステム。
【１３０７】
例２２２：定義可能なメモリ依存性タイプは、ストア−ロード及びストア−ストア依存性が存在しないことが保証されている独立タイプと、ローカルストレージエリアへのロード及びストアが互いに依存し得るが、他のロード及びストアからは独立しているローカルストレージエリアへの潜在的に依存したアクセスタイプと、ハードウェアが命令間の依存性を動的にチェックして強化する潜在的に依存するタイプと、ロード及びストアがそれらの間で依存しており、メモリがアトミックに更新されるアトミック性タイプとのうちの１つを有する、例２２１に記載のシステム。
【１３０８】
例２２３：使用対象のレジスタを含む保存状態、更新されるフラグ、実装仕様情報を格納するメモリと、レジスタを超える実行（ｅｘｅｃｕｔｉｏｎ  ｂｅｙｏｎｄ  ｒｅｇｉｓｔｅｒ）の間に用いられるローカルストレージとをさらに含む、例２１３−２２２のうちのいずれかに記載のシステム。
【１３０９】
例２２４：並列実行の各インスタンスは、独自のローカルストレージを取得する、例２２３に記載のシステム。
【１３１０】
例２２５：スレッドに対する実行についての異なる緩和モードに入る段階と、異なる緩和モードの実行中、スレッドの実行中に使用対象のレジスタを保存状態エリアに書き込む段階と、異なる緩和モードの実行中に、スレッド内の並列実行毎に用いられるローカルストレージを予約する段階と、スレッドのブロックを実行して、実行の異なる緩和モード内の命令を追跡する段階と、実行の異なるモードの終了が、アクセラレータ終了命令の実行に基づいて到達したか否かを判断する段階と、実行の異なるモードの終了が到達した場合、保存状態エリアからレジスタ及びフラグを元の状態に戻す段階と、実行の異なるモードの終了が到達していない場合、中間結果を用いてローカルストレージを更新する段階とを含む方法。
【１３１１】
例２２６：異なる緩和モード実行の間、自己書き換えコードが無視されることと、メモリ一貫性モデル制限が弱められることと、浮動小数セマンティクスが変更されることと、パフォーマンスモニタリングが変更されることと、アーキテクチャフラグの利用が変更されることとのうちの１又は複数が発生する、例２２５に記載の方法。
【１３１２】
例２２７：アクセラレータ開始命令の実行に基づいて、実行の異なるモードに入る、例２２５又は２２６に記載の方法。
【１３１３】
例２２８：判断されたパターンに基づいて、実行の異なるモードに入る、例２２５に記載の方法。
【１３１４】
例２２９：アクセラレータ開始命令が実行した後に修正されるレジスタを格納する状態保存エリアのサイズ及びフォーマットは、アクセラレータ開始命令により指し示されるメモリブロックに規定される、例２２５−２２８のいずれかに記載の方法。
【１３１５】
例２３０：実行前に、スレッド又はその一部を変換する段階をさらに含む、例２２５−２２９のいずれかに記載の方法。
【１３１６】
例２３１：スレッド又はその一部は、アクセラレータコードに変換される、例２３０に記載の方法。
【１３１７】
例２３２：変換されたスレッド又は変換されたスレッドの一部は、アクセラレータにより実行される、例２３０又は２３１に記載の方法。
【１３１８】
例２３３：ブロックの命令は、スレッドの上記ブロックと関連付けられるメモリブロック内のシーケンス番号を更新することにより追跡される、例２１３−２３２のいずれかに記載の方法。
【１３１９】
例２３４：命令が実行に成功して、リタイアしたときに、スレッドのブロックのシーケンス番号が更新される、例２２３−２３３のいずれかに記載の方法。
【１３２０】
例２３５：アクセラレータ終了命令が実行し、リタイアした場合、実行の異なるモードの終了に到達しない、例２２３−２３４のいずれかに記載の方法。
【１３２１】
例２３６：アクセラレータ終了命令実行により判断されたときに、実行の異なるモードの終了に到達しなかった場合、中間結果を用いてブロックの一部を実行しようと試みる、例２２３−２３５のいずれかに記載の方法。
【１３２２】
例２３７：非アクセラレータ処理要素は、例外又は割込み後に中間結果と共に実行するために用いられる、例２３６の方法。
【１３２３】
例２３８：実行の異なるモードの終了に到達しなかった場合、アクセラレータの利用が開始したポイントに実行をロールバックする、例２２３−２３７のいずれかに記載の方法。
【１３２４】
例２３９：オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースオペランド用の１又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコードするデコーダと、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、２）一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する実行回路とを含むシステム。
【１３２５】
例２４０：Ｎはオペコードにより示される、例２３９に記載のシステム。
【１３２６】
例２４１：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２３９−２４０のいずれかに記載のシステム。
【１３２７】
例２４２：実行回路は２分木低減ネットワークを含む、例２３９−２４１のいずれかに記載のシステム。
【１３２８】
例２４３：実行回路はアクセラレータの一部である、例２４２のいずれかに記載のシステム。
【１３２９】
例２４４：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２４２に記載のシステム。
【１３３０】
例２４５：各乗算は並列に処理される、例２４４に記載のシステム。
【１３３１】
例２４６：パックドデータ要素は、１又は複数の行列の成分に対応する、例２３９−２４５のいずれかに記載のシステム。
【１３３２】
例２４７：オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースオペランド用の１又は複数のフィールド及びパックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、一時的な結果を合計し、３）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に一時的な結果の合計を加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する段階とを含む方法。
【１３３３】
例２４８：Ｎはオペコードにより示される、例２４７に記載の方法。
【１３３４】
例２４９：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２４７−２４８のいずれかに記載の方法。
【１３３５】
例２５０：実行回路は２分木低減ネットワークを含む、例２４７−２４９のいずれかに記載の方法。
【１３３６】
例２５１：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２４７に記載の方法。
【１３３７】
例２５２：各パックドデータオペランドは、８つのパックドデータ要素を有する、例２５１に記載の方法。
【１３３８】
例２５３：各乗算は並列に処理される、例２５１に記載の方法。
【１３３９】
例２５４：パックドデータ要素は、１又は複数の行列の成分に対応する、例２４７−２５３のいずれかに記載の方法。
【１３４０】
例２５５：プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースオペランド用の１又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて一時的な結果を生成し、２）一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する段階とを含む、非一時的な機械可読媒体。
【１３４１】
例２５６：Ｎはオペコードにより示される、例２５５に記載の非一時的な機械可読媒体。
【１３４２】
例２５７：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２５５−２５６のいずれかに記載の非一時的な機械可読媒体。
【１３４３】
例２５８：実行回路は２分木低減ネットワークを含む、例２５５−２５７のいずれかに記載の非一時的な機械可読媒体。
【１３４４】
例２５９：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２５８に記載の非一時的な機械可読媒体。
【１３４５】
例２６０：各パックドデータオペランドは、８つのパックドデータ要素を有する、例２５９に記載の非一時的な機械可読媒体。
【１３４６】
例２６１：各乗算は並列に処理される、例２５９に記載の非一時的な機械可読媒体。
【１３４７】
例２６２：パックドデータ要素は、１又は複数の行列の成分に対応する、例２５５−２６１のいずれかに記載の非一時的な機械可読媒体。
【１３４８】
例２６３：オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースレジスタオペランド用の１又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、２）一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を格納するように、デコードされた命令を実行する段階とを含む方法。
【１３４９】
例２６４：Ｎはオペコードにより示される、例２６３に記載の方法。
【１３５０】
例２６５：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２６３−２６４のいずれかに記載の方法。
【１３５１】
例２６６：実行回路は２分木低減ネットワークである、例２６５に記載の方法。
【１３５２】
例２６７：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２６６に記載の方法。
【１３５３】
例２６８：各パックドデータオペランドは、８つのパックドデータ要素を有する、例２６３−２６７のいずれかに記載の方法。
【１３５４】
例２６９：各乗算は並列に処理される、例２６８−２６８のいずれかに記載の方法。
【１３５５】
例２７０：プロセッサにより実行されるときに、プロセッサに方法を実行させる命令を格納する非一時的な機械可読媒体であって、方法は、オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースレジスタオペランド用の１又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコーディングする段階と、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて、一時的な結果を生成し、２）一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を格納するように、デコードされた命令を実行する段階とを含む、非一時的な機械可読媒体。
【１３５６】
例２７１：Ｎはオペコードにより示される、例２７０に記載の非一時的な機械可読媒体。
【１３５７】
例２７２：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２７０−２７１のいずれかに記載の非一時的な機械可読媒体。
【１３５８】
例２７３：実行回路は２分木低減ネットワークである、例２７２に記載の非一時的な機械可読媒体。
【１３５９】
例２７４：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２７２に記載の非一時的な機械可読媒体。
【１３６０】
例２７５：各パックドデータオペランドは、８つのパックドデータ要素を有する、例２７０−２７４のいずれかに記載の非一時的な機械可読媒体。
【１３６１】
例２７６：各乗算は並列に処理される、例２７０−２７５のいずれかに記載の非一時的な機械可読媒体。
【１３６２】
例２７７：オペコード、第１のパックドデータソースオペランド用のフィールド、第２から第Ｎのパックドデータソースレジスタオペランド用の１又は複数のフィールド、及び、パックドデータ宛先オペランド用のフィールドを有する命令をデコードするデコーダと、第２から第Ｎのパックドデータソースオペランドのパックドデータ要素の位置ごとに、１）そのパックドデータソースオペランドのそのパックドデータ要素の位置のデータ要素に、第１のパックドデータソースオペランドの対応するパックドデータ要素位置のデータ要素を掛けて一時的な結果を生成し、２）対で一時的な結果を合計し、３）一時的な結果の合計をパックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に加え、４）パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素に対する一時的な結果の合計を、パックドデータ宛先オペランドの対応するパックドデータ要素位置に格納するように、デコードされた命令を実行する実行回路とを含むシステム。
【１３６３】
例２７８：Ｎはオペコードにより示される、例２７７に記載のシステム。
【１３６４】
例２７９：ソースオペランドの値は、乗算加算器アレイのレジスタにコピーされる、例２７７−２７８のいずれかに記載のシステム。
【１３６５】
例２８０：実行回路は２分木低減ネットワークである、例２７９に記載のシステム。
【１３６６】
例２８１：２分木低減ネットワークは、対で加算回路の第１セットに結合される複数の乗算回路を有し、加算回路の第１セットは、パックドデータ宛先オペランドの対応するパックドデータ要素位置のデータ要素にも結合される加算回路の第３セットに結合される加算回路の第２セットに結合される、例２７９に記載のシステム。
【１３６７】
例２８２：各パックドデータオペランドは、８つのパックドデータ要素を有する、例２７７−２８１のいずれかに記載のシステム。
【１３６８】
例２８３：各乗算は並列に処理される、例２７７−２８２のいずれかに記載のシステム。
【１３６９】
例２８４：ホストプロセッサにアクセラレータを結合するマルチプロトコルバスインタフェースを含むアクセラレータであって、コマンドを処理する１又は複数の処理要素を含む、アクセラレータと、複数のクライアントによりサブミットされるワーク記述子を格納する複数のエントリを含む共有のワークキューであって、ワーク記述子は、ワーク記述子と、１又は複数の処理要素により実行される少なくとも１つのコマンドと、アドレッシング情報とをサブミットしたクライアントを識別する識別コードを含む、共有のワークキューと、特定のアービトレーションポリシに従って、共有のワークキューから１又は複数の処理要素にワーク記述子をディスパッチするアービタとを含み、１又は複数の処理要素のそれぞれは、アービタからディスパッチされたワーク記述子を受信し、ソース及び宛先アドレス変換を実行し、ソースアドレス変換により識別されたソースデータを読み出し、少なくとも１つのコマンドを実行して宛先データを生成し、宛先アドレス変換を用いてメモリに宛先データを書き込む、システム。
【１３７０】
例２８５：複数のクライアントは、直接ユーザモード入力／出力（ＩＯ）要求をアクセラレータにサブミットするユーザモードアプリケーション、アクセラレータを共有する仮想マシン（ＶＭ）において実行するカーネルモードドライバ、及び／又は、複数のコンテナにおいて実行するソフトウェアエージェントのうちの１又は複数を有する、例２８４に記載のシステム。
【１３７１】
例２８６：複数のクライアントのうちの少なくとも１つのクライアントは、ＶＭ内で実行されるユーザモードアプリケーション又はコンテナを有する、例２８５に記載のシステム。
【１３７２】
例２８７：クライアントは、ピア入力／出力（ＩＯ）エージェント及び／又はソフトウェアチェーンオフロード要求のうちの１又は複数を有する、例２８４−２８６のいずれかに記載のシステム。
【１３７３】
例２８８：ピアＩＯエージェントのうちの少なくとも１つは、ネットワークインタフェースコントローラ（ＮＩＣ）を有する、例２８７に記載のシステム。
【１３７４】
例２８９：１又は複数の処理要素により使用可能な仮想−物理アドレス変換を格納するアドレス変換キャッシュをさらに含む、例２８４−２８８のいずれかに記載のシステム。
【１３７５】
例２９０：特定のアービトレーションポリシは、先入先出ポリシを有する、例２８４−２８９のいずれかに記載のシステム。
【１３７６】
例２９１：特定のアービトレーションポリシは、第１のクライアントのワーク記述子が第２のクライアントのワーク記述子を上回る優先度が与えられるサービス品質（ＱｏＳ）ポリシを有する、例２８４−２９０のいずれかに記載のシステム。
【１３７７】
例２９２：たとえ第２のクライアントのワーク記述子が、第１のクライアントのワーク記述子の前に共有のワークキューに受信されていたとしても、第１のクライアントのワーク記述子は、第２のクライアントのワーク記述子の前に１又は複数の処理要素にディスパッチされる、例２９１に記載のシステム。
【１３７８】
例２９３：識別コードは、クライアントに割り当てられるシステムメモリ内のアドレス空間を識別する処理アドレス空間識別子（ＰＡＳＩＤ）を有する、例２８４−２９２のいずれかに記載のシステム。
【１３７９】
例２９４：１又は複数の専用のワークキューをさらに含み、各専用のワークキューは、専用のワークキューと関連付けられた単一のクライアントによりサブミットされたワーク記述子を格納する複数のエントリを含む、例２８４−２９３のいずれかに記載のシステム。
【１３８０】
例２９５：グループ内の専用のワークキュー及び／又は共有のワークキューのうちの２又はそれより多くを組み合わせるためにプログラミングされるグループ構成レジスタをさらに含み、グループは、複数の処理要素のうちの１又は複数と関連付けられる、例２９４のシステム。
【１３８１】
例２９６：１又は複数の処理要素は、グループ内の専用のワークキュー及び／又は共有のワークキューからのワーク記述子を処理する、例２９５に記載のシステム。
【１３８２】
例２９７：マルチプロトコルバスインタフェースによりサポートされる第１のプロトコルは、システムメモリアドレス空間にアクセスするために用いられるメモリインタフェースプロトコルを有する、例２８４−２９６のいずれかに記載のシステム。
【１３８３】
例２９８：マルチプロトコルバスインタフェースによりサポートされる第２のプロトコルは、アクセラレータのローカルメモリに格納されるデータと、ホストキャッシュ階層及びシステムメモリを含むホストプロセッサのメモリサブシステムとの間のコヒーレンシを維持するキャッシュコヒーレンシプロトコルを有する、例２８４−２９７のいずれかに記載のシステム。
【１３８４】
例２９９：マルチプロトコルバスインタフェースによりサポートされる第３のプロトコルは、デバイス発見、レジスタアクセス、構成、初期化、割込み、ダイレクトメモリアクセス及びアドレス変換サービスをサポートする直列リンクプロトコルを有する、例２８４−２９８のいずれかに記載のシステム。
【１３８５】
例３００：第３のプロトコルは、ペリフェラルコンポーネントインタフェースエクスプレス（ＰＣＩｅ）プロトコルを有する、例２９９に記載のシステム。
【１３８６】
例３０１：処理要素により処理されるソースデータを格納し、１又は複数の処理要素による処理から生じた宛先データを格納するアクセラレータメモリをさらに含む、例２８４−３００のいずれかに記載のシステム。
【１３８７】
例３０２：アクセラレータメモリは、高帯域幅メモリ（ＨＢＭ）を有する、例３０１に記載のシステム。
【１３８８】
例３０３：アクセラレータメモリは、ホストプロセッサにより用いられるシステムメモリアドレス空間の第１の部分に割り当てられる、例３０１に記載のシステム。
【１３８９】
例３０４：システムメモリアドレス空間の第２の部分に割り当てられるホストメモリをさらに含む、例３０３に記載のシステム。
【１３９０】
例３０５：システムメモリアドレス空間に格納されたデータのブロックごとに、ブロック内に含まれるデータがアクセラレータに向けてバイアスがかけられているか否かを示すバイアス回路及び／又は論理をさらに含む、例３０４に記載のシステム。
【１３９１】
例３０６：データの各ブロックはメモリページを有する、例３０５に記載のシステム。
【１３９２】
例３０７：ホストは、まずアクセラレータに要求を送信することなく、アクセラレータに向けてバイアスがかけられているデータを処理することを控える、例３０５に記載のシステム。
【１３９３】
例３０８：バイアス回路及び／又は論理は、アクセラレータに向けたバイアスを示すために、データの固定サイズのブロック毎に設定される１ビットを含むバイアステーブルを含む、例３０７に記載のシステム。
【１３９４】
例３０９：アクセラレータは、アクセラレータメモリに格納されるデータと関連付けられた１又は複数のデータコヒーレンシなトランザクションを実行するホストプロセッサのコヒーレンスコントローラと通信するメモリコントローラを有する、例３０１−３０８のいずれかに記載のシステム。
【１３９５】
例３１０：メモリコントローラは、アクセラレータに向けられたバイアスに設定されるアクセラレータメモリに格納されるデータのブロックにアクセスするデバイスバイアスモードで動作し、デバイスバイアスモードにある場合、メモリコントローラは、ホストプロセッサのキャッシュコヒーレンスコントローラに問い合わせることなく、アクセラレータメモリにアクセスする、例３０９に記載のシステム。
【１３９６】
例３１１：メモリコントローラは、ホストプロセッサに向けたバイアスに設定されるデータのブロックにアクセスするホストバイアスモードで動作し、ホストバイアスモードにある場合、メモリコントローラは、ホストプロセッサ内のキャッシュコヒーレンスコントローラを通じてアクセラレータメモリにすべての要求を送信する、例３０９に記載のシステム。
【１３９７】
例３１２：共有のワークキューは、ワーク記述子のバッチを識別する少なくとも１つのバッチ記述子を格納する、例２８４−３１１のいずれかに記載のシステム。
【１３９８】
例３１３：メモリからワーク記述子のバッチを読み出すことにより、バッチ記述子を処理するバッチ処理回路をさらに含む、例３１２に記載のシステム。
【１３９９】
例３１４：ワーク記述子は、命令の第１のタイプを実行するホストプロセッサに対応する専用のワークキューに追加され、ワーク記述子は、命令の第２のタイプを実行するホストプロセッサに対応する共有のワークキューに追加される、例２９２に記載のシステム。
【１４００】
例３１５：デバイスバイアスでメモリページの第１セットを配置する段階と、ホストプロセッサに結合されるアクセラレータデバイスのローカルメモリからメモリページの第１セットを割り当てる段階と、ホストプロセッサのコア、又は、入力／出力エージェントから割り当てられたページにオペランドデータを転送する段階と、ローカルメモリを用いてアクセラレータデバイスによりオペランドを処理して、結果を生成する段階と、メモリページの第１セットをデバイスバイアスからホストバイアスに変換する段階とを含む方法。
【１４０１】
例３１６：デバイスバイアスでメモリページの第１セットを配置する段階は、ページがアクセラレータデバイスバイアスにあることを示すために、バイアステーブル内のメモリページの第１セットを更新する、例３１５に記載の方法。
【１４０２】
例３１７：エントリを更新する段階は、メモリページの第１セット内の各ページと関連付けられたビットを設定する段階を有する、例３１５−３１６のいずれかに記載の方法。
【１４０３】
例３１８：デバイスバイアスに設定されると、メモリページの第１セットは、ホストキャッシュメモリにキャッシュされないことが保証される、例３１５−３１７のいずれかに記載の方法。
【１４０４】
例３１９：メモリページの第１セットを割り当てることは、ドライバ又はアプリケーションプログラミングインタフェース（ＡＰＩ）コールを開始する段階を有する、例３１５−３１８のいずれかに記載の方法。
【１４０５】
例３２０：オペランドを処理するために、アクセラレータデバイスは、コマンドを実行して、そのローカルメモリから直接データを処理する、例３１５−３１９のいずれかに記載の方法。
【１４０６】
例３２１：割り当てられたページにオペランドデータを転送する段階は、アクセラレータデバイスに１又は複数のワーク記述子をサブミットする段階を有し、ワーク記述子は、オペランドを識別する又は含む、例３１５−３２０のいずれかに記載の方法。
【１４０７】
例３２２：１又は複数のワーク記述子は、割り当てられたページに、コマンドでホストプロセッサキャッシュからフラッシュさせてよい、例３２１に記載の方法。
【１４０８】
例３２３：ホストプロセッサは、メモリページの第１セットがホストバイアスに設定されている場合、結果にアクセスし、結果をキャッシュし、結果を共有することが許可されている、例３１５−３２３のいずれかに記載の方法。
【図１】
0006988040.tif 000049
【図２】
0006988040.tif 000050
【図３】
0006988040.tif 000051
【図４】
0006988040.tif 000052
【図５】
0006988040.tif 000053
【図６】
0006988040.tif 000054
【図７】
0006988040.tif 000055
【図８】
0006988040.tif 000056
【図９】
0006988040.tif 000057
【図１０】
0006988040.tif 000058
【図１１】
0006988040.tif 000059
【図１２】
0006988040.tif 000060
【図１３】
0006988040.tif 000061
【図１４】
0006988040.tif 000062
【図１５】
0006988040.tif 000063
【図１６】
0006988040.tif 000064
【図１７】
0006988040.tif 000065
【図１８】
0006988040.tif 000066
【図１９】
0006988040.tif 000067
【図２０】
0006988040.tif 000068
【図２１】
0006988040.tif 000069
【図２２】
0006988040.tif 000070
【図２３】
0006988040.tif 000071
【図２４】
0006988040.tif 000072
【図２５】
0006988040.tif 000073
【図２６】
0006988040.tif 000074
【図２７】
0006988040.tif 000075
【図２８】
0006988040.tif 000076
【図２９】
0006988040.tif 000077
【図３０】
0006988040.tif 000078
【図３１】
0006988040.tif 000079
【図３２】
0006988040.tif 000080
【図３３】
0006988040.tif 000081
【図３４】
0006988040.tif 000082
【図３５】
0006988040.tif 000083
【図３６】
0006988040.tif 000084
【図３７】
0006988040.tif 000085
【図３８】
0006988040.tif 000086
【図３９】
0006988040.tif 000087
【図４０】
0006988040.tif 000088
【図４１】
0006988040.tif 000089
【図４２】
0006988040.tif 000090
【図４３】
0006988040.tif 000091
【図４４】
0006988040.tif 000092
【図４５】
0006988040.tif 000093
【図４６】
0006988040.tif 000094
【図４７】
0006988040.tif 000095
【図４８】
0006988040.tif 000096
【図４９】
0006988040.tif 000097
【図５０】
0006988040.tif 000098
【図５１】
0006988040.tif 000099
【図５２】
0006988040.tif 000100
【図５３】
0006988040.tif 000101
【図５４】
0006988040.tif 000102
【図５５】
0006988040.tif 000103
【図５６】
0006988040.tif 000104
【図５７】
0006988040.tif 000105
【図５８】
0006988040.tif 000106
【図５９】
0006988040.tif 000107
【図６０】
0006988040.tif 000108
【図６１】
0006988040.tif 000109
【図６２】
0006988040.tif 000110
【図６３】
0006988040.tif 000111
【図６４】
0006988040.tif 000112
【図６５】
0006988040.tif 000113
【図６６】
0006988040.tif 000114
【図６７】
0006988040.tif 000115
【図６８】
0006988040.tif 000116
【図６９】
0006988040.tif 000117
【図７０】
0006988040.tif 000118
【図７１】
0006988040.tif 000119
【図７２ａ】
0006988040.tif 000120
【図７２ｂ】
0006988040.tif 000121
【図７２ｃ】
0006988040.tif 000122
【図７３ａ】
0006988040.tif 000123
【図７３ｂ】
0006988040.tif 000124
【図７３ｃ】
0006988040.tif 000125
【図７４】
0006988040.tif 000126
【図７５ａ】
0006988040.tif 000127
【図７５ｂ】
0006988040.tif 000128
【図７６ａ】
0006988040.tif 000129
【図７６ｂ】
0006988040.tif 000130
【図７６ｃ】
0006988040.tif 000131
【図７６ｄ】
0006988040.tif 000132
【図７６ｅ】
0006988040.tif 000133
【図７７】
0006988040.tif 000134
【図７８】
0006988040.tif 000135
【図７９】
0006988040.tif 000136
【図８０ａ】
0006988040.tif 000137
【図８０ｂ】
0006988040.tif 000138
【図８１】
0006988040.tif 000139
【図８２】
0006988040.tif 000140
【図８３】
0006988040.tif 000141
【図８４ａ】
0006988040.tif 000142
【図８４ｂ】
0006988040.tif 000143
【図８５】
0006988040.tif 000144
【図８６】
0006988040.tif 000145
【図８７】
0006988040.tif 000146
【図８８】
0006988040.tif 000147
【図８９】
0006988040.tif 000148
【図９０】
0006988040.tif 000149
【図９１】
0006988040.tif 000150
【図９２】
0006988040.tif 000151
【図９３】
0006988040.tif 000152
【図９４ａ】
0006988040.tif 000153
【図９４ｂ】
0006988040.tif 000154
【図９５】
0006988040.tif 000155
【図９６】
0006988040.tif 000156
【図９７】
0006988040.tif 000157
【図９８ａ】
0006988040.tif 000158
【図９８ｂ】
0006988040.tif 000159
【図９９】
0006988040.tif 000160
【図１００】
0006988040.tif 000161
【図１０１】
0006988040.tif 000162
【図１０２】
0006988040.tif 000163
【図１０３】
0006988040.tif 000164
【図１０４】
0006988040.tif 000165
【図１０５】
0006988040.tif 000166
【図１０６】
0006988040.tif 000167
【図１０７】
0006988040.tif 000168
【図１０８ａ】
0006988040.tif 000169
【図１０８ｂ】
0006988040.tif 000170
【図１０９】
0006988040.tif 000171
【図１１０】
0006988040.tif 000172
【図１１１】
0006988040.tif 000173
【図１１２】
0006988040.tif 000174
【図１１３（Ａ）】
0006988040.tif 000175
【図１１３（Ｂ）】
0006988040.tif 000176
【図１１３（Ｃ）】
0006988040.tif 000177
【図１１４】
0006988040.tif 000178
【図１１５】
0006988040.tif 000179
【図１１６】
0006988040.tif 000180
【図１１７】
0006988040.tif 000181
【図１１８】
0006988040.tif 000182
【図１１９】
0006988040.tif 000183
【図１２０】
0006988040.tif 000184
【図１２１】
0006988040.tif 000185
【図１２２】
0006988040.tif 000186
【図１２３】
0006988040.tif 000187
【図１２４】
0006988040.tif 000188
【図１２５】
0006988040.tif 000189
【図１２６Ａ】
0006988040.tif 000190
【図１２６Ｂ】
0006988040.tif 000191
【図１２７Ａ】
0006988040.tif 000192
【図１２７Ｂ】
0006988040.tif 000193
【図１２８】
0006988040.tif 000194
【図１２９】
0006988040.tif 000195
【図１３０】
0006988040.tif 000196
【図１３１】
0006988040.tif 000197
【図１３２】
0006988040.tif 000198
【図１３３】
0006988040.tif 000199