(57)【要約】命令ブロックベースのマイクロアーキテクチャにおけるプロセッサコアは、サイズテーブルに対するインデックスを含むヘッダを有する命令ブロックを利用する。サイズテーブルは、メモリ、レジスタ、ロジック又はコードストリームのうちの１つを使用して表されてよい。プロセッサコア内の制御ユニットは、サイズテーブルから示されるブロックサイズに基づいて、命令ウィンドウへマッピングするために、現在の命令ブロックについてどのくらい多くの命令をフェッチすべきかを決定する。命令ブロックのサイズは、所与のプログラムについて不均一に分布されることが多いので、サイズテーブルの利用は、命令ブロックが固定のサイズを有するか、より少ない粒度でサイズ調整される配置と比べて、命令ウィンドウ内の利用可能なスロットのサイズに命令ブロックを一致させる際に更なる柔軟性を可能にする。そのような柔軟性は、所与の命令ブロック内のｎｏｐｓ（ヌル関数等のノーオペレーション）の数を低減することにより、全体的な処理効率を高める高密度の命令パッキングを可能にすることができる。
2018519597.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサ内に配置される命令ウィンドウにおいて命令ブロックを管理するための方法であって：
命令ブロックサイズのサイズテーブルを維持するステップと；
命令ブロックのヘッダ内に符号化されたインデックスを読み出すステップであって、前記命令ブロックが１つ以上の命令を含む、ステップと；
前記インデックスを使用して、前記サイズテーブルから命令ブロックサイズをルックアップするステップと；
命令ウィンドウ内の命令パッキングを最大にするために、前記のサイズのルックアップに基づいて、前記命令ブロックを命令ウィンドウ内の利用可能なスロットへマッピングするステップと；
を有する、方法。
【請求項２】
前記命令ウィンドウをサブウィンドウにセグメント化するステップ、
を更に含む、請求項１に記載の方法。
【請求項３】
共通のサイズを共有するか、２つ以上の異なるサイズを使用して実装されるよう、前記セグメント化されたサブウィンドウを構成するステップ、
を更に含む、請求項２に記載の方法。
【請求項４】
前記セグメント化されたサブウィンドウは、命令ブロックサイズの分布に従って動的にサイズ調整される、
請求項３に記載の方法。
【請求項５】
前記サイズテーブルを、ロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用して表される論理サイズテーブルとして維持するステップ、
を更に含む、請求項１に記載の方法。
【請求項６】
プログラムに関連付けられる命令ブロックサイズの分布の中で、一般的に使用されるサイズに一致するよう、前記サイズテーブル内のサイズを設定するステップ、
を更に含む、請求項１に記載の方法。
【請求項７】
命令ブロックベースのマイクロアーキテクチャであって：
制御ユニットと；
１つ以上のオペランドバッファと；
前記制御ユニットのコントロール下にあるように、プログラムに関連付けられる復号された命令ブロックを格納するよう構成される命令ウィンドウと；を有し、前記コントロールは、
ロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用してサイズテーブルを実装し、該サイズテーブルが、前記プログラムで使用される命令ブロックの分布内で一般に利用されるサイズに対応する２つ以上の異なるサイズを含み、
命令ブロックのヘッダ内のポインタを検査し、前記ポインタが、前記サイズテーブルで識別される命令ブロックサイズを参照し、
前記のテーブルから識別されるサイズに基づいて、前記命令ウィンドウ内の命令ブロックの配置を決定する、
動作を含む、命令ブロックベースのマイクロアーキテクチャ。
【請求項８】
各命令ブロックについてバルク割り当てを実行して、前記のブロック内の命令に関連付けられるリソースを取得する構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項９】
前記命令ブロックのヘッダ内で指定される制限に基づいて、前記命令ブロックをマップする構成を更に含み、前記指定される制限は、アライメント制限又は前記命令ウィンドウの命令ブロックキャパシティ制限のうちの一方を含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項１０】
前記命令ウィンドウ内の前記命令ブロックの順序を追跡し、命令ブロックをアウトオブオーダーでコミットする構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項１１】
前記命令ウィンドウ内で現在マップされている命令ブロックの年代を明示的に追跡して、該明示的に追跡された年代に基づいて命令ブロックをコミットする構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項１２】
前記命令ブロックに適合する前記命令ウィンドウ内のスロットが利用可能であるとき、命令ブロックを前記命令ウィンドウにマップする構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項１３】
循環バッファを使用して命令ブロックを前記命令ウィンドウにマップする構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【請求項１４】
命令キャッシュから前記命令ブロックを再フェッチすることなく、前記命令ブロックをリフレッシュする構成を更に含む、
請求項７に記載の命令ブロックベースのマイクロアーキテクチャ。
【発明の詳細な説明】
【背景技術】
【０００１】
命令セットアーキテクチャ（ＩＳＡｓ：instruction  set  architectures）及びプロセッサの設計者は、電力と性能のトレードオフを行う。例えば設計者が、より高い性能を伝える命令を有するＩＳＡを選択する場合、プロセッサによる電力消費も同様に高くなる可能性がある。あるいは、設計者が、より低い電力消費の命令を有するＩＳＡを選択する場合、性能が低くなる可能性がある。電力消費は、算術論理演算ユニット（ＡＬＵ：arithmetic  logic  unit）、キャッシュライン又はレジスタのように、実行中に命令によって使用されるプロセッサのハードウェアリソースの量に結び付けられることがある。より大量のそのようなハードウェアリソースの使用は、より高い電力消費という代償を払ってより高い性能を伝えることがある。あるいは、より少量のハードウェアリソースの使用は、より低い性能という代償を払ってより低い電力消費をもたらすことがある。コンパイラを使用して、高レベルコードをコンパイルして、ＩＳＡ及びプロセッサアーキテクチャと互換性のある命令にすることができる。
【発明の概要】
【０００２】
命令ブロックベースのマイクロアーキテクチャ内のプロセッサコアは、サイズテーブルへのインデックスを含むヘッダを有する命令ブロックを利用する。サイズテーブルは、メモリ、レジスタ、ロジック又はコードストリームのうちの１つを使用して表されてよい。プロセッサコア内の制御ユニットは、サイズテーブルから指示されるブロックサイズに基づいて、命令ウィンドウへマッピングするために、現在の命令ブロックについてどのくらい多くの命令をフェッチすべきかを決定する。命令ブロックサイズは、所与のプログラムについて不均一に分布されることが多いので、サイズテーブルの利用は、命令ブロックが固定サイズを有するか、より少ない粒度でサイズ調整される構成と比べて、命令ウィンドウ（instruction  window）内の利用可能なスロットのサイズに命令ブロックを一致させる際に更なる柔軟性を可能にする。このような柔軟性は、所与の命令ブロックにおけるｎｏｐｓの数（ヌル関数等のノーオペレーション）を減らすことにより、全体の処理効率を高める高密度の命令パッキング（instruction  packing）を可能にする。
【０００３】
この発明の概要は、以下に発明の詳細な説明で更に説明される概念の選択を簡略化した形で紹介するために提供される。この発明の概要は、特許請求に係る主要な特徴又は本質的特徴を特定するようには意図されておらず、特許請求に係る主題の範囲を画定する際の助けとして用いられるようにも意図されていない。更に、特許請求に係る主題は、本開示のいずれかの部分で示される不都合な点のいずれか又は全てを解決する実装に限定されない。
【図面の簡単な説明】
【０００４】
【図１】複数のプロセッサコアを含むアーキテクチャ上で実行する符号化された命令をコンパイラが提供する、例示のコンピューティング環境を示す図である。
【０００５】
【図２】例示のプロセッサコアについての例示のマイクロアーキテクチャのブロック図である。
【０００６】
【図３】ブロックヘッダについての例示の構成を示す図である。
【０００７】
【図４】例示の方法のフローチャートである。
【図５】例示の方法のフローチャートである。
【図６】例示の方法のフローチャートである。
【図７】例示の方法のフローチャートである。
【図８】例示の方法のフローチャートである。
【図９】例示の方法のフローチャートである。
【図１０】例示の方法のフローチャートである。
【図１１】例示の方法のフローチャートである。
【図１２】例示の方法のフローチャートである。
【図１３】例示の方法のフローチャートである。
【図１４】例示の方法のフローチャートである。
【図１５】例示の方法のフローチャートである。
【０００８】
図面において、同様の参照数字は同様の要素を示す。別段の定めがない限り、要素はスケーリングされて描かれていない。
【発明を実施するための形態】
【０００９】
図１は、本発明の命令ブロックマッピングを利用することができる例示のコンピューティング環境１００を示す。環境はコンパイラ１０５を含み、コンパイラ１０５を利用して、プログラム１１５から、符号化されたマシン実行可能命令１１０を生成してよい。命令１１０をプロセッサアーキテクチャ１２０によって処理することができる。プロセッサアーキテクチャ１２０は、例えば４個と１２８個の命令の間を含め、可変なサイズの命令のブロックを処理するように構成される。
【００１０】
プロセッサアーキテクチャ１２０は、典型的に、（代表的に参照数字１２５によって示される）複数のプロセッサコアをタイル化された構成で含む。複数のプロセッサコアは、オンチップネットワーク（図示せず）によって相互接続され、更に（代表的に参照数字１３０によって示される）１つ以上のレベル２（Ｌ２）キャッシュと相互運用される。コア及びキャッシュの数字及び構成は実装によって変化する可能性があるが、物理コアを、プログラム１１５のランタイム中に「コンポージング（composing）」と呼ばれるプロセスで一緒にマージして、より多くの処理電力をプログラム実行に充てることを可能にすることができる１つ以上の大きな論理プロセッサにすることができる。あるいは、プログラム実行が適切なスレッドレベルの並列性をサポートするとき、独立に機能し、独立のスレッドからの命令を実行するように、コア１２５を、「デコンポージング（decomposing）」と呼ばれるプロセスで分割することができる。
【００１１】
図２は、例示のプロセッサコア１２５の一部の簡略化されたブロック図である。図示されるように、プロセッサコア１２５は、フロントエンド制御ユニット２０２、命令キャッシュ２０４、分岐予測器（branch  predictor）２０６、命令デコーダ１０８、命令ウィンドウ２１０、左オペランドバッファ２１２、右オペランドバッファ２１４、算術論理演算ユニット（ＡＬＵ）２１６、別のＡＬＵ２１８、レジスタ２２０及びロード／ストアキュー（load/store  queue）２２２を含んでよい。場合によっては、（矢印で示される）バスがデータ及び命令を担持してよく、一方、他の場合には、バスがデータ（例えばオペランド）又は制御信号を担持してもよい。例えばフロントエンド制御ユニット２０２は、制御信号のみを担持するバスを介して、他の制御ネットワークと通信してもよい。図２は、プロセッサコア１２５について、特定の配置構成で配置される或る数の例示のコンポーネントを示しているが、特定の実装の必要性に応じて異なるように配置されるより多くの又はより少ないコンポーネントが存在してもよい。
【００１２】
フロントエンド制御ユニット２０２は、プロセッサコア及び回路を通る情報の流れを制御してその中の活動を調整するように構成される回路を含んでよい。フロントエンド制御ユニット２０２は、プロセッサコアが取り得る動作構成の各々を状態が列挙する、有限状態マシン（ＦＳＭ：finite  state  machine）を実装する回路も含んでよい。（以下で説明される）オペコード及び／又は他の入力（例えばハードウェアレベル信号）を使用して、フロントエンド制御ユニット２０２内のＦＳＭ回路は、次の状態を決定して出力を制御することができる。
【００１３】
したがって、フロントエンド制御ユニット２０２は、命令デコーダ２０８により処理するために、命令キャッシュ２０４から命令をフェッチすることができる。フロントエンド制御ユニット２０２は、制御ネットワーク又はバス上で、制御情報をプロセッサコア１２５の他の部分と交換してもよい。例えばフロントエンド制御ユニットは、バックエンド制御ユニット２２４と制御情報を交換してもよい。一部の実装では、フロントエンド制御ユニットとバックエンド制御ユニットが単一の制御ユニットに統合されてもよい。
【００１４】
フロントエンド制御ユニット２０２は、プロセッサアーキテクチャ１２０（図１）の様々なコア及び他の部分のコントロールを調整及び管理してもよい。したがって、例えば命令のブロックが、複数のコア上で同時に実行していることがあり、フロントエンド制御ユニット２０２は、命令の様々なブロックの実行のために、必要に応じて、制御ネットワークを介して制御情報を他のコアと交換して同期を確実にすることができる。
【００１５】
フロントエンド制御ユニット２０２は更に、アトミックに実行される命令ブロックに関する制御情報及びメタ情報を処理してよい。例えばフロントエンド制御ユニット２０２は、命令ブロックに関連付けられるブロックヘッダを処理することができる。以下でより詳細に議論されるように、ブロックヘッダは、命令ブロックに関する制御情報及び／又はメタ情報を含んでもよい。したがって、フロントエンド制御ユニット２０２は、ブロックヘッダ内の様々なフィールドを処理するよう、組合せロジック、状態マシン及びフリップフロップ等の一時ストレージユニットを含むことができる。
【００１６】
フロントエンド制御ユニット２０２２０２は、単一の命令及び複数の命令をクロックサイクルごとにフェッチして復号してよい。復号された命令は、プロセッサコアハードウェア内にバッファとして実装される命令ウィンドウ２１０に格納されてよい。命令ウィンドウ２１０は、一部の実装では、命令スケジューラ２３０をサポートすることができる。命令スケジューラ２３０は、プレディケーション（predications）（叙述）及びオペランドのような各々の復号された命令の入力のレディ状態（ready  state）を維持してよい。例えばその入力（もしあれば）の全ての準備が完了（ready）しているとき、所与の命令が命令スケジューラ２３０によって起こされて、発行する準備ができる。
【００１７】
命令が発行される前に、その命令によって必要とされる全てのオペランドが、必要に応じて左オペランドバッファ２１２及び／又は右オペランドバッファ２１４に格納されてよい。命令のオペコードに依存して、ＡＬＵ２１６及び／又はＡＬＵ２１８又は他の機能ユニットを使用して、オペレーションがオペランドに対して実行されてよい。ＡＬＵの出力は、オペランドバッファに格納されるか、１つ以上のレジスタ２２０内に格納されてよい。データフロー順で発行するストアオペレーション（store  operations）は、命令ブロックがコミットするまで、ロード／ストアキュー２２２内にキューされてよい。命令のブロックがコミットするとき、ロード／ストアキュー２２２は、コミットされたブロックのストアをメモリに書き込んでよい。分岐予測器２０６は、分岐終了タイプ（branch  exit  types）に関するブロックヘッダ情報を処理し、分岐予測を作成する際にその情報を要因として含めてよい。
【００１８】
上記のように、プロセッサアーキテクチャ１２０は典型的に、フェッチされ、実行され、アトミックにコミットされるブロック内に編成される命令を利用する。したがって、プロセッサコアは、ひとまとめに単一のブロックに属している命令をフェッチし、これらをプロセッサコアの内部の実行リソースにマップし、命令を実行し、その結果をアトミックなやり方でコミットしてよい。プロセッサは、全ての命令の結果をコミットするか、全体のブロックの実行を無効にしてよい。ブロックの内部の命令は、データフロー順に実行してよい。加えて、プロセッサは、ブロックの内部の命令が、メッセージ又は他の適切な形の通信を使用して相互に直接通信することを許容してよい。したがって、結果を生じる命令は、結果をレジスタファイルに書き込む代わりに、その結果を使用するブロック内の別の命令にその結果を通信してよい。例として、レジスタＲ１及びＲ２に格納された値を加算（add）する命令は、以下の表１に示されるように表されてよい：
【表１】
2018519597.tif 000003
【００１９】
このように、ソースオペランドは命令では指定されず、代わりに、それらのソースオペランドは、ＡＤＤ命令をターゲットとする命令によって指定される。コンパイラ１０５（図１）は、命令１１０のコンパイル中にコントロール及びデータ依存性を明示的に符号化することができ、これにより、ランタイムにこれらの依存性を再発見することからプロセッサコアを解放することができる。この結果、これらの命令の実行中に、プロセッサの負荷を低減し、エネルギをセーブすることができるので有利である。例として、コンパイラは、全てのコントロール依存性をデータフロー命令に変換するプレディケーションを使用してもよい。これらの技術を使用して、電力を多く必要とする（power-hungry）レジスタファイルへのアクセス数を減らすことができる。以下の表２は、そのような命令のための汎用命令フォーマットの例を示す。
【表２】
2018519597.tif 000004
【００２０】
各命令は、３２ビット、６４ビット又は別のサイズのように適切なサイズであってよい。表２に示される例では、各命令は、OPCODE（オペコード）フィールド、PR（プレディケーション）フィールド、BID（ブロードキャストID）フィールド、XOP（拡張オペコード（extended  OPCODE））フィールド、TARGET1フィールド及びTARGET2フィールドを含んでよい。オペコードフィールドは、命令又は命令のブロックについて、加算（add）、読み出し（read）、書込み（write）又は乗算（multiply）等の一意のオペレーションコードを指定してよい。PR（プレディケーション）フィールドは、命令に関連付けられる任意のプレディケーションを指定してよい。例えば２ビットのPRフィールドは、以下のように使用されてよい：００−プレディケート付でない（not  predicated）、０１−リザーブ（reserved）、１０−プレディケートが偽（predicated  on  false）及び１１−プレディケートが真（predicated  on  true）。したがって、例えば比較の結果が真である場合にのみ命令が実行する場合、その命令は、その比較を実行する別の命令の結果に対してプレディケートされてよい。BID（ブロードキャストID）フィールドは、ブロック内の任意の数のコンシューマ命令（consumer  instructions）に対してオペランドを送ることをサポートすることができる。２ビットのBIDフィールドは、命令がそのオペランドのうちの１つを受け取るブロードキャストチャネルを符号化するために使用されてよい。XOP（拡張オペコード）フィールドは、オペコードのタイプを拡張することをサポートすることができる。TARGET1及びTARGET2フィールドは、最大で２つまでのターゲット命令を符号化することを許容することができる。ターゲットフィールドは、プロデューサ命令（producer  instruction）の結果のコンシューマ命令を指定することができ、したがって命令間の直接通信を許容する。
【００２１】
各命令ブロックは、ブロックに関連する制御情報及び／又はメタ情報等のように、命令ブロックに関連付けられる特定の情報を有することがある。この情報は、プロセッサアーキテクチャ１２０における実行のために命令１１０へのプログラムのコンパイル中にコンパイラ１０５によって生成されてよい。この情報の一部が、命令ブロックのコンパイル中にコンパイラによって抽出されてよく、次いで、ランタイム中に命令の性質を検査する。
【００２２】
加えて、命令ブロックに関連付けられる情報は、メタ情報であってもよい。例えばそのような情報は、特別命令（special  instructions）を使用して、あるいは命令ブロックに関連付けられる関連情報を有する可能性があるレジスタ又は他のメモリに関連するターゲット符号化（target  encoding）を提供する命令を使用して、プロセッサコアに提供されてよい。特別命令の場合、そのような命令のオペコードフィールドを使用して、命令ブロックに関連する情報を伝えることができる。別の例では、そのような情報は、プロセッサ状態語（ＰＳＷ：processor  status  word）の一部として維持されてもよい。例えばこの情報は、有利には、プロセッサが命令ブロックをより効率的に実行することを助けることができる。
【００２３】
ブロックヘッダ、特別命令、メモリ参照位置（memory  referenced  locations）、プロセッサ状態語（ＰＳＷ）又はこれらの様々な組合せを使用して、様々なタイプの情報をプロセッサコアに提供することができる。例示の命令ブロックヘッダ３００が図３に示されている。この説明的な例では、ブロックヘッダ３００は128ビットであり、ブロックのプログラムカウンタからオフセット0で始まる。各フィールドのそれぞれの開始及び終了も示されている。フィールドを以下の表３で説明する。
【表３】
2018519597.tif 000005
2018519597.tif 000006
2018519597.tif 000007
【００２４】
図３に図示され、表３に説明されるブロックヘッダは、複数のフィールドを含むが、これは例示であるように意図されており、特定の実装に他のフィールド配置が利用されてよい。
【００２５】
説明的な例では、コンパイラ１０５（図１）は、ブロックヘッダ内に含めるため又は特定の命令のために情報を選択してよく、そのような情報を、命令の性質に基づいて及び／又は高性能若しくは低電力といった処理要件の性質に基づいて、プロセッサコアに提供することができる。これは、有利には、性能と電力消費との間のトレードオフのより最適なバランシングを可能にすることができる。多数のコアを伴う高性能演算のような特定のタイプの処理アプリケーションにとって、大量の情報が望ましいオプションである可能性がある。あるいは、モノのインターネット（ＩｏＴ：Internet  of  Things）で使用される組込みプロセッサ、モバイルデバイス、ウェアラブルデバイス、ヘッドマウントディスプレイ（ＨＭＤ）デバイス又は他の組込み演算タイプのアプリケーションといった他のタイプの処理アプリケーションにとっては、より少ない情報が望ましいオプションである可能性がある。
【００２６】
ブロックヘッダ又は特別命令を使用して通信される情報の範囲を、ブロック内の命令の性質に応じて調整することができる。例えば命令ブロックが、循環するように実行されるループを含む場合、そのブロックに関連付けられる制御情報をカプセル化するために、より広範な情報が必要とされる可能性がある。追加の制御情報は、プロセッサコアがループをより効率的に実行することを可能にし、これにより性能を改善することができる。
【００２７】
あるいは、めったに実行されない命令ブロックが存在する場合、次いで比較的少ない情報で十分であり得る。例えば命令ブロックが、幾つかのプレディケート制御ループ（predicated  control  loops）を含む場合、より多くの情報が必要とされることがある。同様に、命令ブロックがかなりの命令レベルの並列性を有する場合、ブロックヘッダ又は特別命令の一部として、より多くの情報が必要とされることがある。
【００２８】
ブロックヘッダ又は特別命令内の追加の制御情報を使用して、例えば命令ブロックにおける命令レベルの並列性を効率的に利用することができる。命令ブロックが幾つかの分岐予測を含む場合、より多くの情報が必要とされることがある。分岐予測に関する追加の制御情報は、結果としてパイプラインのフラッシュ（flushes）を減らすことができるため、典型的には、更なる効率性でコードの実行を強化することになる。
【００２９】
ブロックヘッダ内のフィールドに対応する機能性を組み合わせてもよく、あるいは更に分割してもよいことに留意されたい。同様に、特別命令は、図３及び表３に示されるフィールドのうちのいずれか１つに関連する情報を提供してよく、あるいはそのようなフィールドからの情報を組み合わせてもよい。例えば図３及び表３の例示的なブロックヘッダは、別個のIDフィールドとSIZEフィールドを含むが、これらの２つのフィールドを単一のフィールドに組み合わせてもよい。
【００３０】
同様に、単一の特別命令は、復号されるとき、命令ブロックのサイズに関する情報及びIDフィールド内の情報を提供することがある。別段の記載がない限り、特別命令は命令ブロックのどの場所に含まれてもよい。例えばBLOCK_SIZE  #size命令は、命令ブロックのサイズの値を含む即値フィールドを含んでよい。即値フィールドは、サイズ情報を提供する整数値を含んでよい。あるいは、即値フィールドは、サイズ情報に関連する符号化された値を含んでよく、その結果、例えばロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用して表現され得るサイズテーブル内の値をルックアップすることによって、符号化された値を復号することにより、サイズ情報を取得することができる。別の例では、BLOCK_ID  #id特別命令がブロックID番号を伝達することができる。
【００３１】
別個の数学的関数又はメモリベースのテーブルは、ブロックIDをブロックヘッダのメモリアドレスにマップしてもよい。このような命令の一部として伝達されるブロックIDは、命令の各ブロックに一意であり得る。別の例では、BLOCK_HDR_ID  #id命令が、ブロックヘッダID番号を伝達してもよい。別個の数学的関数又はメモリベースのテーブルが、ブロックIDをブロックヘッダのメモリアドレスにマップしてもよい。そのような命令の一部として伝達されるブロックIDは、同じヘッダ構造を有する幾つかの命令ブロック又はフィールドによって共有されてもよい。
【００３２】
別の例では、BLOCK_INFO  #size、#exit  types、#store  mask、#write  mask命令が、列挙される命令のフィールドに関する情報を提供してもよい。これらのフィールドは、表３に関して上述したフィールドのいずれか１つに対応し得る。所与の実装の要件に応じて、他の変更をブロックヘッダ構造及びフォーマット及び特別命令に行ってもよい。例えば命令のブロックの特性に関連する情報を含む追加のフィールドを提供してもよい。命令ブロックの実行の頻度に基づいて特定のフィールドを含めることができる。
【００３３】
ブロックヘッダ構造に含まれるフィールド、あるいは特別命令又は前述の他の機構を介して提供される情報は、特定のプロセッサ又はプロセッサファミリーの公的に利用可能な標準命令セットアーキテクチャ（ＩＳＡ）の一部とすることができる。フィールドのサブセットは、ＩＳＡに対する専用の拡張（proprietary  extension）であってもよい。フィールド内の特定のビット値はプロセッサの標準ＩＳＡの一部であってよいが、フィールド内の特定の他のビット値は専用の機能を提供してよい。この例示的なフィールドは、ＩＳＡ設計者が、専用の拡張に関連付けられる性質及び機能を完全に開示することなく、ＩＳＡに専用の拡張を追加することを可能にする。したがって、この例では、ＩＳＡ設計者によって配布されるコンパイラツールは、フィールド内の専用ビット値、完全に別個の専用フィールド又は特別命令をサポートするであろう。そのようなフィールドの使用は、特定のプロセッサ設計に専用のハードウェア・アクセラレータに特に関連する可能性がある。したがって、プログラムは、ブロックヘッダーフィールド又は認識不可能な特別命令を含んでよいが、プログラムは更に、フィールドを解読するか命令を復号するためのレシピを含んでよい。
【００３４】
コンパイラ１０５（図１）は、メタ情報及び制御情報を含め、命令ブロックに関する情報を生成するために、典型的には１つ以上のプロセッサコアによってアトミックに実行するよう構成される命令ブロックを処理することができる。一部のプログラムは、１つのＩＳＡのみについて、例えばモノのインターネットのためのプロセッサ、モバイルデバイス、ＨＭＤデバイス、ウェアラブルデバイス又は他の組込みコンピューティング環境で使用されるＩＳＡについてコンパイルされ得る。コンパイラは、命令ブロックに関連する情報を生成するために、静的コード分析又はコードプロファイリング等の技術を採用してよい。場合によっては、コンパイラは、命令ブロックの特性及びその実行頻度等の要因を考慮してもよい。命令ブロックの関連する特性は、これらに限定されないが、例えば（１）命令レベル並列性、（２）ループ数、（３）プレディケート制御命令（predicated  control  instructions）の数及び（４）分岐予測の数が含まれ得る。
【００３５】
図４は、プロセッサコア内に配置される命令ウィンドウで命令ブロックを管理するための例示の方法４００のフローチャートである。特段の記載がない限り、図４のフローチャート内の方法又はステップ、並びに図面に示され、下述される他のフローチャートの方法又はステップは、特定の順序又はシーケンスに制限されない。加えて、これらの方法又はステップの一部は同時に生じるか実行される可能性があり、所与の実装では、そのような実装の要件に依存して、方法又はステップの必ずしも全てが実施される必要はなく、一部の方法又はステップが任意選択で利用されてよい。同様に、一部の実装では、オーバーヘッドを減らすために一部のステップが省略されてよいが、例えばこれは脆性の増加につながることがある。任意の所与の適用で実装され得る様々な特徴、コスト、オーバーヘッド、性能又はロバスト性のトレードオフは、典型的に、設計的選択の問題と考えられてよい。
【００３６】
ステップ４０５において、フェッチされる命令ブロックの年代（age）が、例えば年代ベクトル（age  vector）を使用して明示的に追跡される。したがって、典型的に年代を暗黙的に追跡するために使用される命令ウィンドウにおける命令ブロックの順序（すなわち、位置）を使用するのではなく、制御ユニットは、明示的状態を維持する。命令ブロックの年代順のリストが、ステップ４１０において維持される。命令ブロックの優先度（一部の場合にはコンパイラによって優先度が決定され得る場合）も追跡されてよく、一部の実装では、命令ブロックの優先度順リストも維持されてよい。
【００３７】
ステップ４１５において、処理用の命令ブロックが識別されると、年代順リストを検索して、一致する命令ブロックを見つける。一部の実装では、優先度順リストも一致について検索されてもよい。一致する命令ブロックが見つかった場合、次いで、ステップ４２０において、命令キャッシュから再フェッチする必要なく、命令ブロックをリフレッシュすることができ、このことは、プロセッサコアの効率性を改善することができる。そのようなリフレッシュは、例えばプログラムがタイトなループで実行し、命令がこれら自体に戻るよう（back  on  themselves）分岐するという状況で、命令ブロックの再使用を可能にする。そのような効率の向上は、複数のプロセッサコアが大きなスケールアレイへとコンポーズされるときに構成されてもよい。命令ブロックをリフレッシュするとき、命令はその場所に残され、オペランドバッファ及びロード／ストアキュー内の有効ビットのみがクリアにされる。
【００３８】
命令ブロックに対する一致が見つからない場合、年代順リスト（又は優先度順リスト）を再び利用して、新たな命令ブロックについての命令ウィンドウ内のスロットをオープンするためにコミットすることができる命令ブロックを見つけることができる。例えば最も古い命令ブロック又は最も優先度の低い命令ブロックを、コミットしてもよい（優先度の高いブロックは、将来の再使用の可能性があるので、バッファされたままであることが望ましいことがある）。ステップ４２５において、新たな命令ブロックが、利用可能なスロットにマッピングされる。ブロック内の命令と該命令に関連付けられるリソースの全てとを一度に（すなわち、ひとまとめに）フェッチするバルク割り当てプロセス（bulk  allocation  process）を使用して、命令ブロックを割り当てることができる。
【００３９】
ステップ４３０において、新たな命令ブロックが実行され、その結果、その命令ブロックの命令がアトミックにコミットされる。ステップ４３５において、他の命令ブロックを、従来のリオーダバッファと同様の方法で年代順に実行し、これらの命令ブロックのそれぞれの命令を、アトミックな方法でコミットしてよい。
【００４０】
図５は、命令ブロックベースのマイクロアーキテクチャによって実行され得る例示の方法５００のフローチャートである。ステップ５０５において、プロセッサコア内の制御ユニットは、フェッチされた命令ブロックを、連続置換（contiguous  replacement）又は非連続置換（non-contiguous  replacement）のいずれかでバッファさせる。ステップ５１０において、連続命令ブロック置換では、バッファを循環バッファのように操作することができる。ステップ５１５において、非連続命令ブロック置換では、命令ブロックをアウトオブオーダーで置換してよい。例えばステップ５２０において、明示的年代ベースの追跡を実行することができ、その結果、上述と同様な方法で、命令ブロックを、追跡した年代に基づいてコミットして置換する。ステップ５２５において、優先度も追跡することができ、追跡した優先度を使用して、命令ブロックをコミットして置換してもよい。
【００４１】
図６は、プロセッサコア内に配置される制御ユニットによって実行され得る例示の方法６００のフローチャートである。ステップ６０５において、バッファされた命令ブロックの状態を追跡し、ステップ６１０において、追跡した状態を使用して命令ブロックのリストが維持される。例えば状態は、年代、優先度、あるいは特定の実装要件に応じた他の情報又はコンテキストを含むことができる。ステップ６１５において、マッピングのための命令ブロックが識別されると、ステップ６２０に示されるように、一致についてリストをチェックする。ステップ６２５において、リストからの一致する命令ブロックが、再フェッチすることなく、リフレッシュされる。一致する命令ブロックがリスト内で見つからないとき、次いで、ステップ６３０において、上述と同様の方法で、命令ブロックを命令キャッシュからフェッチして、命令ウィンドウ内の利用可能なスロットにマップする。
【００４２】
図７は、プロセッサコア内に配置される命令ウィンドウにおいて命令ブロックを管理するための例示の方法７００のフローチャートである。ステップ７０５において、命令ブロックサイズのサイズテーブルがプロセッサコア内で維持される。サイズテーブルを、様々な方法で、例えばロジック、レジスタ、メモリ、コードストリーム又はたの適切な構造を使用して表すことができる。ステップ７１０において、命令ブロックのヘッダ内に符号化されたインデックスが読み出される。命令ブロックは、１つ以上の復号された命令を含む。したがって、図３及び表３に示されるサイズフィールドを使用して命令ブロックサイズをハードコードするのではなく、このフィールドを使用して、サイズテーブルに対するインデックスを符号化又は格納してよい。すなわち、インデックスは、サイズウィンドウ内のエントリに対するポインタとして機能してよく、特定のサイズを命令ブロックに関連付けることを可能にすることができる。
【００４３】
サイズテーブルに含まれるサイズエントリの数は、実装によって変化する可能性がある。より多数のサイズエントリを使用して、更なる粒度（more  granularity）を可能にすることができる。これは、所与のプログラムに関連付けられる命令ブロックサイズの比較的広範な分布が存在するが、典型的な実装ではオーバーヘッドの増加という代償を払う場合に、有利であり得る。場合によっては、全体的な命令パッキング密度（instruction  packing  density）を最適化する方法で命令ブロックサイズの特定の分布をカバーして、ｎｏ  ｏｐｓを最小にするように、コンパイラが、テーブル内に含まれるサイズの数を選択することができる。ステップ７１５において、インデックスを使用して、サイズテーブルから命令ブロックサイズをルックアップする。ステップ７２０において、命令ブロックは、そのサイズに基づいて命令ウィンドウ内の利用可能なスロットにマップされる。
【００４４】
一部の実装では、ステップ７２５に示されるように、命令ウィンドウは、例えば２つ以上の異なるサイズを使用する２つ以上のサブウィンドウにセグメント化されてよい。セグメント化されたサブウィンドウのそのようなバリエーションは、命令ブロックサイズの所与の分布についての適応（accommodation）を可能にすることができ、命令パッキング密度を更に高めることができる。セグメンテーションは、一部のシナリオでは動的に実行されてもよい。
【００４５】
図８は、命令ブロックベースのマイクロアーキテクチャによって実行され得る例示の方法８００のフローチャートである。ステップ８０５において、サイズテーブルが実装される。上述のように、サイズテーブルは、ロジック、レジスタ、メモリ、コードストリーム又は他の適切な構造を使用して実装されてよく、所与のプログラムによって利用される命令ブロックの分布において一般的に利用されるものに対応するサイズを含んでよい。ステップ８１０において、サイズテーブル内のエントリを参照するポインタについて命令ブロックヘッダが検査される。ステップ８１５において、テーブルエントリによって識別されたサイズを使用して、命令ウィンドウ内の命令ブロックの配置を決定する。
【００４６】
ステップ８２０において、命令ブロックに関連付けられるリソースがバルク割り当て（bulk  allocated）される。命令ブロックヘッダ内で指定される制限は、ステップ８２５において命令ウィンドウ内に命令ブロックをマッピングするときに使用される。これらは、例えばアライメントに対する制限、及び命令ブロックをバッファするための命令ウィンドウのキャパシティに対する制限を含んでよい。ステップ８３０において、命令ウィンドウ内の命令ブロックの順序が制御ユニットによって追跡され、一部の状況では、ブロックはアウトオブオーダーでコミットされてよい。例えばブロックが命令ウィンドウ内のブロックの位置に基づいて処理される命令ブロックの循環バッファを使用するのではなく、多用される（heavily  used）又は特に重要な命令ブロックがアウトオブオーダーで処理されるように、ブロックに優先順位を付けることができ、これは、処理効率を高めることができる。
【００４７】
ステップ８３５において、命令ブロックの年代を明示的に追跡することができ、一部の場合には、このように明示的に追跡した年代に基づいて、命令ブロックをコミットすることができる。命令ブロックは、ステップ８４０においてリフレッシュされる（すなわち、命令キャッシュから命令ブロックを再フェッチする必要なく再使用される）。
【００４８】
図９は、プロセッサコア内に配置される制御ユニットによって実行され得る例示の命令９００のフローチャートである。ステップ９０５において、命令ウィンドウは、上述したものと同様の方法で２つ以上の異なるサイズを有する複数のセグメントで構成される。ステップ９１０において、ブロック命令ヘッダが、その中に符号化されたインデックスについて検査される。ステップ９１５において、インデックスを使用してサイズテーブル内でルックアップを実行し、ステップ９２０において、命令ブロックが、サイズルックアップに基づいて、そのブロックの特定のサイズに適切な命令ウィンドウセグメントに配置される。ステップ９２５において、命令ブロックに関連付けられるリソースが、バルク割り当てを使用してフェッチされる。
【００４９】
図１０は、プロセッサコア内に配置される命令ウィンドウにおいて命令ブロックを管理するための例示の方法１０００のフローチャートである。ステップ１００５において、命令ブロックは命令キャッシュから命令ウィンドウへマップされる。命令ブロックは、１つ以上の復号された命令を含む。ステップ１０１０において、命令ブロック内の命令の各々に関連付けられるリソースが割り当てられる。リソースは典型的に、制御ビットとオペランドを含み、バルク割り当てプロセスを使用して割り当てが実行されてよい。バルク割り当てプロセスでは、リソースの全てがひとまとめに取得又はフェッチされる。
【００５０】
リソース及び命令を密結合する代わりに、命令ウィンドウ及びオペランドバッファは分離（decouple）され、その結果、ステップ１０１５に示されるように、リソース及びブロック内の復号された命令の中で、１つ以上のポインタを維持することにより、これらを独立に操作することができる。ステップ１０２０において、命令ブロックがリフレッシュされる（すなわち、命令キャッシュからの命令ブロックを再フェッチする必要なく、再使用される）と、次いで、ステップ１０２５において、ポインタに従うことによりリソースを再使用することができ、元の制御状態に戻ることができる。
【００５１】
そのような分離は、特に、典型的に生じるような再フェッチを伴わずに命令ブロックがリフレッシュされるとき、例えばプログラムがタイトなループで実行して命令が繰り返し利用されるときに、向上したプロセッサコア効率を提供することができる。ポインタを通して制御状態を確立することにより、処理サイクル及び他のコストの追加の支出なしに、リソースは、効率的に予め検証（pre-validated）される。複数のプロセッサコアが１つの大きなスケールのアレイへとコンポーズされるときに、そのような効率の向上も構成され得る。
【００５２】
図１１は、命令ブロックベースのマイクロアーキテクチャによって実行され得る例示の方法１１００のフローチャートである。ステップ１１０５において、新たな命令ブロックが、コミットされた命令ブロックを置換する方法で、命令ブロックが命令ウィンドウへマップされる。マッピングは、ステップ１１１０で示されるように、例えばアライメントに対する制限、及び命令ブロックをバッファするための命令ウィンドウのキャパシティに対する制限等のように、命令ブロックのヘッダ内で指定される様々な制限の対象となることがある。ステップ１１１５において、新たな命令ブロックについてリソースが割り当てられ、この割り当ては典型的には、上述のようにバルク割り当てプロセスを使用して実装される。
【００５３】
ステップ１１２０において、命令ウィンドウ内の命令ブロックの順序が制御ユニットによって追跡され、一部の状況ではブロックは、アウトオブオーダーでコミットされてよい。例えば命令ウィンドウ内のブロックの位置に基づいてブロックが処理される命令ブロックの循環バッファを使用するのではなく、多用される又は特に重要な命令ブロックがアウトオブオーダーで処理されるように、ブロックに優先順位を付けることができ、これは、処理効率を高めることができる。
【００５４】
ステップ１１２５において、命令ウィンドウがオペランドバッファから分離され、その結果、例えば命令のブロックとオペランドのブロックは独立に（すなわち、命令とオペランドとの間の厳格な対応を使用することなく）管理される。上記のように、分離は、命令ブロックがリフレッシュされるときに、リソースが予め検証されることを可能にすることによって効率を向上させる。
【００５５】
図１２は、プロセッサコア内に配置される制御ユニットによって実行され得る例示の方法１２００のフローチャートである。ステップ１２０５において、命令ウィンドウが、１つ以上の命令ブロックをバッファリングするために維持される。命令ブロック内の命令に関連付けられるリソースをバッファリングするために、ステップ１２１０において、１つ以上のオペランドバッファが維持される。上記のように、リソースは、典型的に制御ビットとオペランドを含む。ステップ１２１５において、命令及びリソースの中でポインタを使用して状態を追跡する。
【００５６】
ブロック１２２０において、命令ブロックがリフレッシュされるとき、ポインタに従って、追跡された状態に戻ることができる。ステップ１２２５において、命令ブロックがコミットするとき、オペランドバッファ内の制御ビットがクリアされて、新たなポインタが設定される。上述の方法と同様に、ステップ１２３０において、命令ウィンドウとオペランドバッファが分離されて、その結果、命令のブロック及びオペランドのブロックが、制御ユニットによって非対応ベース（non-corresponding  basis）で維持される。
【００５７】
図１３は、プロセッサコア内に配置される命令ウィンドウにおいて命令ブロックを管理するための例示の方法１３００のフローチャートである。ステップ１３０５において、ブロック内の命令と、該命令に関連付けられるリソースの全てが一度に（すなわち、ひとまとめに）フェッチされるバルク割り当てプロセスを使用して、命令ブロックが割り当てられる。命令とリソースが小さなチャンクで繰り返しフェッチされる従来のアーキテクチャとの比較では、このバルク割り当ては、ブロック内の命令の全てを同時かつ一貫して管理することを可能にし、これはプロセッサコアのオペレーションの効率を改善することができる。この改善は、所与のプログラミング構造（例えば分岐を最小化するもの）によりコンパイラが比較的大きな命令ブロックを生成することが可能になる状況において、更に一層顕著なものとなり得る。例えば実装によっては、命令ブロックは最大で１２８個の命令を含んでよい。
【００５８】
また、命令ブロックのバルク割り当ては、プログラムがタイトなループで実行して、命令がこれら自体に戻るよう分岐するときに、典型的に起こるような再フェッチを行うことなく命令ブロックが再使用される、リフレッシュ機能を通して、プロセッサコアの効率を高める。そのような効率の向上は、複数のコアが１つの大きなスケールアレイにコンポーズされるときにも構成され得る。命令ブロックをリフレッシュするとき、命令は元の場所に残され、オペランドバッファ及びロード／ストアキュー内の有効ビットのみがクリアされる。これは、リフレッシュされた命令ブロックのフェッチが全体的にバイパスされることを可能にする。
【００５９】
命令ブロックのバルク割り当ては、命令及びリソースのグループが定位置にあるときに、更なる処理効率も可能にする。例えばオペランド及び明示的なメッセージがブロック内のある命令から別の命令に送信されてよい。そのような機能は従来的なアーキテクチャでは可能にされない。なぜなら、１つの命令は、まだ割り当てられていない別の命令に何も送ることができないからである。定数を生成する命令は、オペランドバッファ内の値をピン留めすることもでき、その結果、これらはリフレッシュ後も有効なままであり、命令ブロックを実行するたびに再生成される必要がない。
【００６０】
ステップ１３１０において、命令ブロックが命令ウィンドウ内にマップされるとき、これらは、ステップ１３１５において、マッピングポリシーによって適用され得る制約、ブロックヘッダ内で指定される制限又はその双方の対象となる。場合によっては、ポリシーは、所与のプログラムの特定の要件に応じてコンパイラによって設定されることが可能である。指定される制限は、例えばアライメントに対する制限、及び命令ブロックをバッファするための命令ウィンドウのキャパシティに対する制限を含むことができる。
【００６１】
ステップ１３２０において、一部の実装では、命令ウィンドウを、同じサイズ又は異なるサイズのサブウィンドウにセグメント化することができる。命令ブロックサイズは、所与のプログラムについてランダム又は不均一に分配されることが多いので、セグメント化されたサブウィンドウにおけるそのようなバリエーションは、命令ブロックサイズの所与の分布を、より効率的に適応させることができ、これにより、命令ウィンドウ内の命令パッキング密度を高めることができる。また、セグメンテーションは、一部のシナリオでは、プロセッサコアによって現在処理されているブロックサイズの分布に応じて動的に実行されてもよい。
【００６２】
一部の実装では、命令ブロックヘッダは、インデックスを符号化するか、ロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用して実装されるサイズテーブルへのポインタを含んでもよい。サイズテーブルは命令ブロックサイズエントリを含むことができ、その結果、ステップ１３２５において、このテーブルから命令ブロックサイズをルックアップすることができる。符号化されたインデックス及びサイズテーブルの使用は、利用可能なブロックサイズにおける更なる粒度を与えることにより、命令ブロック内の命令パッキング密度を高めることができ、例えばブロックが比較的少数の命令を含むときに分岐を実装する際に、ｎｏｐｓ（ノーオペレーション）の発生を低減することができる。
【００６３】
図１４は、命令ブロックベースのマイクロアーキテクチャによって実行され得る例示の方法１４００のフローチャートである。ステップ１４０５において、プロセッサコア内の制御ユニットは、命令ブロックを処理するためのポリシーを適用する。ステップ１４１０において、命令と全ての関連するリソースとが一度にフェッチされる上述のバルク割り当てプロセスを使用して、命令ブロックを割り当てる。ステップ１４１５において、命令ブロックは、命令ウィンドウにマッピングされ、そのマッピングは、アライメントに対する制限及び命令ブロックをバッファするための命令ウィンドウのキャパシティに対する制限のように、命令ブロックのヘッダ内で指定される様々な制限の対象となり得る。
【００６４】
ステップ１４２０において、制御ユニットによって命令ウィンドウ内の命令ブロックの順序を追跡することを含むポリシーが適用されてよい。例えば命令ウィンドウ内のブロックの位置に基づいてブロックが処理される、命令ブロックの循環バッファを使用するのではなく、ブロックは、一部の状況では、アウトオブオーダーでコミットされてよい。ステップ１４２５において、（一部のシナリオではコンパイラによって指定され得る）優先度に基づいてブロックを処理することを含むポリシーが適用されてよく、その結果、多用される又は特に重要なブロックが、アウトオブオーダーで処理され、更に処理効率を向上させることができる。
【００６５】
ステップ１４３０において、命令ブロックの年代を明示的に追跡することを含むポリシーが適用されてよく、場合によっては、そのように明示的に追跡した年代に基づいて命令ブロックをコミットすることができる。ステップ１４３５において、命令ウィンドウ（又はウィンドウのセグメント）内で適切にサイズ調整されるスロットの利用可能性に従って命令ブロックをマッピングすることを含むポリシーが適用されてよい。ステップ１４４０において、循環バッファを使用して命令ブロックを命令ウィンドウへマッピングすることを含むポリシーが適用されてよい。
【００６６】
実装によっては、プロセッサコアの効率を更に高めるために、ポリシーの様々な組合せを利用してもよい。例えば制御ユニットはポリシーの中を動的にトグルして、所与の命令ブロック又は命令ブロックのグループについてより最適なオペレーションを提供するポリシーを適用してよい。例えば一部のシナリオでは、命令ブロックが連続的方法で順番に処理される循環バッファリング技術を使用することがより効率的であり得る。他のシナリオでは、アウトオブオーダー及び年代ベースの処理が、より最適なオペレーションを提供することがある。
【００６７】
図１５は、プロセッサコア内に配置される制御ユニットによって実行され得る例示の方法１５００のフローチャートである。ステップ１５０５において、上述と同様な方法で２つ以上の異なるサイズを有する複数のセグメントで命令ウィンドウが構成される。ステップ１５１０において命令ブロックがフェッチされ、ステップ１５１５において命令ブロックに関連付けられる全てのリソースがフェッチされる。
【００６８】
ステップ１５２０において、ウィンドウ内の命令密度を最大にするウィンドウの適切なセグメント内に、命令ブロックが配置される。例えばコンパイラが、（例えばプログラム分岐等を実装するために）低い命令カウント（low  instruction  count）で比較的多数のブロックを含むブロックサイズの分布を生成する場合、命令ウィンドウは、小さな命令ブロックのために特別にサイズ調整されるセグメントを有してよい。同様に、（例えば科学及び同様の適用のために）比較的多数の高い命令カウントのブロックが存在する場合、次いでセグメントは、そのような大きな命令ブロックのために特別にサイズ調整されてよい。命令ウィンドウセグメントのサイジングを、特定のサイズ分布に応じて調整するか、あるいは一部の状況では分布が変化するときに動的に調整することができる。ブロック１５２５において、命令ブロックは、上述のように命令ブロックヘッダ内で指定される制限の対象となり得る。
【００６９】
ブロックサイズに基づく命令ブロックの本マッピングの様々な例示の実施形態が次に説明のために提示されるが、全ての実施形態の包括的なリストとして提示されるものではない。一例は、プロセッサ内に配置される命令ウィンドウにおいて命令ブロックを管理するための方法であって：命令ブロックサイズのサイズテーブルを維持するステップと；命令ブロックのヘッダ内に符号化されたインデックスを読み出すステップであって、命令ブロックが１つ以上の命令を含むステップと；インデックスを使用して、サイズテーブルから命令ブロックサイズをルックアップするステップと；命令ウィンドウ内の命令パッキングを最大にするために、サイズのルックアップに基づいて、命令ブロックを命令ウィンドウ内の利用可能なスロットへマッピングするステップと；を有する方法を含む。更なる例において、方法は、命令ウィンドウをサブウィンドウにセグメント化（segmenting）するステップを更に含む。別の例では、共通のサイズ（common  size）を共有するか、２つ以上の異なるサイズを使用して実装されるよう、セグメント化されたサブウィンドウを構成するステップを更に含む。別の例では、セグメント化されたサブウィンドウは、命令ブロックサイズの分布（distribution）に従って動的にサイズ調整される。別の例において、方法は、サイズテーブルを、ロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用して表される論理サイズテーブル（logical  size  table）として維持するステップを更に含む。別の例において、方法は、プログラムに関連付けられる命令ブロックサイズの分布の中で、一般的に使用されるサイズ（commonly  used  sizes）に一致するよう、サイズテーブル内のサイズを設定するステップを更に含む。
【００７０】
更なる例は、命令ブロックベースのマイクロアーキテクチャを含み：制御ユニットと；１つ以上のオペランドバッファと；制御ユニットのコントロール下にあるように、プログラムに関連付けられる復号された命令ブロックを格納するように構成される命令ウィンドウと；を有し、コントロールは：ロジック、レジスタ、メモリ又はコードストリームのうちの１つを使用してサイズテーブルを実装し、該サイズテーブルが、プログラムで使用される命令ブロックの分布内で一般に利用されるサイズに対応する２つ以上の異なるサイズを含み、命令ブロックのヘッダ内のポインタを検査し、ポインタが、サイズテーブルで識別される命令ブロックサイズを参照し、テーブルから識別されるサイズに基づいて、命令ウィンドウ内の命令ブロックの配置を決定する動作を含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、各命令ブロックについてバルク割り当てを実行して、ブロック内の命令に関連付けられるリソースを取得する構成を更に含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、命令ブロックのヘッダ内で指定される制限に基づいて、命令ブロックをマップする構成を更に含み、指定される制限は、アライメント制限又は命令ウィンドウの命令ブロックキャパシティ制限のうちの一方を含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、命令ウィンドウ内の命令ブロックの順序を追跡し、命令ブロックをアウトオブオーダーでコミットする構成を更に含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、命令ウィンドウ内で現在マップされている命令ブロックの年代を明示的に追跡して、該明示的に追跡された年代に基づいて命令ブロックをコミットする構成を更に含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、命令ブロックに適合する命令ウィンドウ内のスロットが利用可能であるとき、命令ブロックを命令ウィンドウにマップする構成を更に含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、循環バッファを使用して命令ブロックを命令ウィンドウにマップする構成を更に含む。別の例において、命令ブロックベースのマイクロアーキテクチャは、命令キャッシュから命令ブロックを再フェッチすることなく、命令ブロックをリフレッシュする構成を更に含む。
【００７１】
更なる例は、命令ブロック管理のための方法を実行するよう構成される、プロセッサ内に配置される制御ユニットを含み、上記方法は、複数のセグメントで命令ウィンドウを構成することであって、セグメントは２つ以上の異なるサイズを有することと；その中に符号化されたインデックスについて命令ブロックのヘッダを検査することであって、命令ブロックが１つ以上の命令を含むことと；インデックスを使用してサイズテーブルから命令ブロックサイズをルックアップすることと；サイズルックアップに基づいて、命令ブロックを命令ウィンドウのセグメントへ配置することを含む。別の例において、制御ユニットは更に、命令ウィンドウ内の配置に対して指定された制限について、命令ブロックのヘッダを検査することと、指定された命令に従って配置を実行することを含み、指定された制限は、アライメント制限又は命令ブロックキャパシティ制限の一方を含む。別の例において、制御ユニットは、セグメント化された命令ウィンドウを、複数のプロセッサコア上に分散される論理セグメント命令ウィンドウとして構成することを更に含む。別の例において、制御ユニットは、インチップネットワーク上で搬送される通信を使用して論理セグメント命令ウィンドウにわたって状態を維持することを更に含む。別の例では、制御ユニットは、バルク割り当てとしてリソースのフェッチを実行することを更に含む。別の例では、制御ユニットは、命令キャッシュから命令ブロックを再フェッチすることなく、命令ブロックをリフレッシュすることを更に含む。
【００７２】
上述の主題は、例示のために提供されるものにすぎず、限定として解釈されるべきではない。図示され説明される例示の実施形態及び適用に従わずに、特許請求の範囲で説明される本開示の真の精神及び範囲から逸脱することなく、本明細書で説明される主題に対して様々な修正及び変更を行ってもよい。
【図１】
2018519597.tif 000008
【図２】
2018519597.tif 000009
【図３】
2018519597.tif 000010
【図４】
2018519597.tif 000011
【図５】
2018519597.tif 000012
【図６】
2018519597.tif 000013
【図７】
2018519597.tif 000014
【図８】
2018519597.tif 000015
【図９】
2018519597.tif 000016
【図１０】
2018519597.tif 000017
【図１１】
2018519597.tif 000018
【図１２】
2018519597.tif 000019
【図１３】
2018519597.tif 000020
【図１４】
2018519597.tif 000021
【図１５】
2018519597.tif 000022
【国際調査報告】
2018519597.tif 000023
2018519597.tif 000024
2018519597.tif 000025