JP2013537996A - コミット時における状態アップデート実行インストラクション、装置、方法、およびシステム - Google Patents

Abstract

本発明に係る装置は、インストラクションを実行する回路を含む実行ロジックと、実行ロジックに結合されたインストラクション実行スケジューラーロジックを含んでいる。インストラクション実行スケジューラーロジックは、コミット時における状態アップデート実行インストラクションを受け取る。インストラクション実行スケジューラーロジックは、コミット時における状態アップデート実行インストラクションがコミットする次のインストラクションになるまで、そのコミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待つ、コミット時における状態アップデートロジックを含む。他の装置、方法、そしてシステムも開示される。

Description

本発明は、プロセッサおよび他の命令処理装置に関する。より特定的には、本発明は、プロセッサおよび他の命令処理装置の内部状態をアップデートする方法、装置、またはインストラクションに関する。

特定のプロセッサは、実行フェーズをオーバーラップ（ｏｖｅｒｌａｐ）させるためにパイプライン（ｐｉｐｅｌｉｎｅ）実行を使用する。これにより、マルチインストラクションを同時に異なる実行フェーズにおくことができ、パフォーマンスの改善に役に立つ。パイプラインの深さが増加すると、達成された並行処理の量が増加する傾向がある。長い間、特定のプロセッサは、より深いパイプラインをパフォーマンス改善の試みに組み入れてきた。パイプラインは、インストラクションストリーム（ｓｔｒｅａｍ）が既知の場合により効果的である傾向がある。パイプラインが完全に保持されることができ、後のインストラクションの実行は、パイプラインにおける実行結果を待つ必要がないからである。

より完全なパイプラインであることを保持するために、パイプラインプロセッサは、動的予測（例えば、分岐予測）と投機的実行を使用してきた。動的予測は、インストラクションストリームにおけるインストラクションフローを予測して、パイプラインの中に予測されたパス（ｐａｔｈ）のインストラクションを注入するために使用され得る。分岐予測は、正しい分岐の方向が最終的に知られる前に、例えば条件分岐インストラクションの方向といった、分岐の方向を予測すること含む。例えば、プロセッサは、過去の履歴に基づいて、条件分岐インストラクションがとる最も確からしい方向が何であるかを経験的に推測することができる。プロセッサは、次に、予測された分岐方向が正しいという仮定に基づいて、投機的にインストラクションの実行を開始し得る。しかし、それはプロセッサが、予測された分岐方向が正しいか否かを知る以前のことである。

動的予測（例えば、予測された分岐方向）は、後になって、正しかったのか、正しくなかったのかがわかる。予測された分岐方向が、後に正しいものであるとわかった場合には、投機的実行の結果が利用され得る。この場合、投機的実行は、分岐の正しい方向がわかるまで待っている間に、もしそうでなければ休止しているか少なくとも低い利用しかされていなかったであろうパイプラインステージのより多くを使用できることで価値を提供する。代替的には、予測された分岐方向が正しくなかったことがわかった場合、または分岐方向が間違って予測された場合には、条件付分岐インストラクションを過ぎた投機的な実行は典型的には捨てられ、そして、コントロールフローで間違って予測された条件付分岐までジャンプまたは分岐戻りすることにより実行は典型的には巻き戻されるべきである。実行は、次に、非投機的に、最終的に既知の正しい分岐方向と供に再開することができる。

本発明は、プロセッサおよび他の命令処理装置の内部状態をアップデートする方法、装置、またはインストラクションに関する。

本発明に係る装置は、インストラクションを実行する回路を含む実行ロジックと、実行ロジックに結合されたインストラクション実行スケジューラーロジックを含んでいる。インストラクション実行スケジューラーロジックは、コミット時における状態アップデート実行インストラクションを受け取る。インストラクション実行スケジューラーロジックは、コミット時における状態アップデート実行インストラクションがコミットする次のインストラクションになるまで、そのコミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待つ、コミット時における状態アップデートロジックを含む。

本発明の実施例を説明するために使用される以降の記載および添付の図面を参照することによって、本発明は最もよく理解され得る。
図１は、機械で読取り可能なストレージ媒体上に保管されたコミット時における状態アップデート実行インストラクションに係る実施例のブロックダイヤグラムである。 図２は、コミット時における状態アップデート実行インストラクションを発行するためのインストラクション実行スケジューラーキュー（ｓｃｈｅｄｕｌｅｒ ｑｕｅｕｅ）を有するプロセッサまたは他の命令処理装置に係る実施例のブロックダイヤグラムである。 図３は、コミット時における状態アップデート実行インストラクションを発行する方法の実施例に係るフローチャートである。 図４は、コミット時における状態アップデート実行インストラクションを発行するためのアウトオブオーダーインストラクション実行スケジューラーキュー（ｓｃｈｅｄｕｌｅｒ ｑｕｅｕｅ）の実行を有するアウトオブオーダープロセッサまたは他の命令処理装置に係る実施例のブロックダイヤグラムである。 図５は、コミット時における状態アップデート実行インストラクションを発行するためのアウトオブオーダーインストラクション実行スケジューラーキュー（ｓｃｈｅｄｕｌｅｒ ｑｕｅｕｅ）の実行を有するアウトオブオーダープロセッサまたは他の命令処理装置に係る実施例のブロックダイヤグラムである。 図６は、コミット時における状態アップデート実行インストラクションを発行するためのコミット時における状態アップデートロジックに係る特定の実施例を有する予約ステーションに係る特定の実施例のブロックダイヤグラムである。 図７は、ここにおいて開示されるプロセッサの実施をする好適なコンピューターシステムの実施例に係るブロックダイヤグラムである。

以下の記載においては、特定のプロセッサコンポーネントや構成、特定のスケジュールロジック、等といった、数多くの所定の詳細が明らかにされる。しかしながら、本発明の実施例は、これらの所定の詳細が無くても実行され得ることが理解されるだろう。他の実施例においては、既知の回路、構成、そして技術は詳細には示されていない。こうした記載の理解を妨げないためである。

プロセッサ内での投機的実行によって引き起こされるチャレンジの一つは、プロセッサの内部状態のアップデートまたは変更である。プロセッサは、一般的に、投機的には変更されるべきでない数多くの内部状態を有している。いくつかのプロセッサは、百または千のオーダーの内部状態に係るビットを有している。内部状態は、システムフラグ、コントロールレジスターのビット、等といったものを含んでいる。プロセッサのオペレーション中、つまりプロセッサがコードを実行している間に、この内部状態は、例えば、プロセッサのマイクロコード及び／又はソフトウェア／ＢＩＯＳによって、マイクロコードにより提供されるインターフェイスを通じて変更され得る。しかしながら、典型的には、この内部状態は投機的にアップデートされるべきではない。例えば、投機的な実行の間である。いくつかのプロセッサにおいては、最も頻繁に変更されるプロセッサ状態はリネイム（ｒｅｎａｍｅ）され（例えば、アウトオブオーダープロセッサの場合には、リオーダーバッファー（ｒｅ−ｏｒｄｅｒ ｂｕｆｆｅｒ）に配置され、リネイムされることによってである）、投機的実行に対抗してこの状態をプロテクト（ｐｒｏｔｅｃｔ）する手助けをする。しかしながら、いくつかのプロセッサにおいては数多くのプロセッサ状態があるため、このプロセッサ状態の全てが一般的にはリネイムされるわけではなく、従ってリネイムを通じたプロセッサ状態のプロテクトは達成されない。

本発明の実施例は、状態アップデートインストラクションに関するもので、プロセッサをコントロールして、投機的実行を使用しているパイプラインプロセッサにおいてプロセッサの内部状態（例えば、非リネイムプロセッサ状態）を非投機的にアップデートさせるように動作可能である。種々の実施例では、状態アップデートインストラクションは、コミット（ｃｏｍｍｉｔ）時において、プロセッサをコントロールして、プロセッサの内部状態をアップデートさせる（例えば、リタイアまたはリタイアのすぐ後において、コンプリートまたはコンプリートのすぐ後において、動的予測の決定の後において、分岐決定信号を受け取った後において、等である）。コミット時における状態アップデート実行インストラクションは、そのアップデートが非投機的なものであることがわかる後までは、内部状態がアップデートされないように手助けする。いくつかの実施例はアウトオブオーダープロセッサに適用可能であるが、一方、他の実施例はインオーダー（ｉｎ−ｏｒｄｅｒ）プロセッサに適用可能である。別の実施例は、状態アップデートインストラクションに対応して実行される方法に関するものである。さらに、別の実施例は、状態アップデートインストラクションを処理する装置に関するものである。

図１は、機械で読取り可能なストレージ媒体１００上に保管されたコミット時における状態アップデートインストラクション１０２の実行に係る実施例のブロックダイヤグラムである。種々の実施例において、機械で読取り可能なストレージ媒体とは、いくつか例を挙げると、メモリー（例えば、リードオンリーメモリー（ＲＯＭ））、インストラクションストア（ｓｔｏｒｅ）、インストラクションキャッシュ、インストラクションキュー（ｑｕｅｕｅ）、インストラクションバッファー、ディスク（例えば、磁気的または光学的ディスク）、といったものである。

コミット時における状態アップデート実行インストラクションは、プロセッサまたは他の命令実行装置といった機械に対して提供され、アクセスされ、そうでなければ処理され得る。機械は、状態アップデートインストラクションが、コミット時に実行されるタイプの状態アップデートインストラクションであることを認識し得る。例えば、機械は、状態アップデートインストラクションの一つまたはそれ以上のビットが、それはコミット時に実行されるタイプの状態アップデートインストラクションであることを示していることを認識し得る。このことが行われるのに種々の異なった方法がある。このことが行われる好適な方法の例は、これらに限定されるわけではないが、いくつか例を挙げると、コミット時における状態アップデート実行インストラクションのためのセパレートしたオペコード（ｏｐｃｏｄｅ）を提供すること、オペコードによって特定された状態アップデートインストラクションがコミットバラエティ（ｖａｒｉｅｔｙ）時における実行であること示すためにオペコードの中に一つまたはそれ以上のビットのタグ（ｔａｇ）を備えること、および、インストラクションがコミット時のインストラクションの実行であることを示すためにインストラクションの別のフィールド（例えば、そうでなければそのインストラクションのために使用されていたフィールド）の中に一つまたはそれ以上のビットのタグを備えること、である。

コミット時における状態アップデート実行インストラクションは、機械によって処理される場合には、その状態アップデートインストラクションがコミットする次のインストラクションになるまで、その状態アップデートインストラクションをスケジュール／発行および実行することを機械に待たせることになり得る。または、そうでなければ、状態アップデートインストラクションが非投機的なものである場合である。それから、機械は、その状態アップデートインストラクションをスケジュール／発行、実行、およびコミットすることができる。状態アップデートインストラクションが実行、または、いくつかのケースにおいてはコミットされると、機械の内部状態はアップデートされ得る。コミット時における状態アップデート実行インストラクションは、プロセッサまたは他の命令処理装置をコントロールして、特定のパイプラインステージ、すなわちコミット時において、その状態アップデートインストラクションが生じさせるように実行可能である。

一つの特定の実施例に置いては、コミット時における状態アップデート実行インストラクションは、内部状態のタイプの例を表しているコントロールレジスターを書き込みまたは変更するように動作可能な、コントロールレジスターライトインストラクションのコミット時における実行であり得る。コントロールレジスターの内容は、システムフラグ、アドレス翻訳のためのページテーブルロケーション、セグメントデータ、メモリー領域のタイプ、プロセッサのモード（例えば、プロテクションまたはキャッシュ）、といったものである。一つの態様では、コントロールレジスターは、レジスターリネイムを通じてリネイムされるようには構成されず、コントロールレジスターまたは内部状態を、投機的な実行の間の変更からより影響を受けやすく、またはよりプロテクトされないようにしている。

一つまたはそれ以上の実施例においては、コミット時における状態アップデート実行インストラクションは、マイクロインストラクション（ｍｉｃｒｏｉｎｓｔｒｕｃｔｉｏｎ）である。他の実施例は、マイクロコードでコントロールされるプロセッサに限定されない。

有利なことに、コミット時における状態アップデート実行インストラクションは、内部状態の投機的なアップデートを避けるのを手助けし得る。コミット時における状態アップデート実行インストラクションは、その状態アップデートインストラクションがコミットする次のインストラクションになるまで、その状態アップデートインストラクションをスケジュール／発行および実行することを機械に待たせることになるので、その状態アップデートインストラクションが非投機的なものであることがわかる後までは、状態アップデートインストラクションは機械の内部状態のアップデートを生じさせない。さらに、状態アップデートインストラクション自身をコミット時におけるインストラクションの実行とすることは、内部状態の投機的なアップデートを避ける直接的で効果的な方法である。基本的に、内部状態の投機的な変更を避けるために投機的には発生しないものは、状態アップデートインストラクションであって、条件的マイクロ分岐インストラクションまたは他のタイプのインストラクションではない。

図２は、コミット時における状態アップデート実行インストラクション２０２をスケジュールするためのインストラクション実行スケジューラーロジック２１２を有するプロセッサまたは他の命令処理装置２０４に係る実施例のブロックダイヤグラムである。プロセッサまたは他の命令処理装置とは種々のタイプのものであり、例を挙げるとすれば、例えば、複合命令セットコンピューティング（ＣＳＩＣ）タイプ、縮小命令セットコンピューティング（ＲＩＳＣ）タイプ、超長命令語（ＶＬＩＷ）タイプ、そして、それらの組合せといったものである。プロセッサまたは他の命令処理装置は、インオーダーまたはアウトオブオーダーどちらかの命令を実行し得る。

一つまたはそれ以上の実施例において、プロセッサは汎用プロセッサであり得る。例えば、そうである必要もないが、カリフォルニア州サンタクララのインテルコーポレーションによって製造された汎用プロセッサの一つである。インテルコーポレーションから提供される好適な汎用プロセッサのいくつかの実施例は、これらに限定されるわけではないが、インテルＡｔｏｍプロセッサ、インテルＣｏｒｅプロセッサ、インテルＣｏｒｅ２プロセッサ、インテルＰｅｎｔｉｕｍ（登録商標）プロセッサ、そしてインテルＣｅｌｅｒｏｎプロセッサを含んでいる。

代替的には、プロセッサは専用プロセッサであり得る。好適な専用プロセッサの代表的な実施例は、これらに限定されるわけではないが、例を挙げるとすれば、ネットワークプロセッサ、通信プロセッサ、暗号プロセッサ、グラフィックプロセッサ、コプロセッサ（ｃｏ−ｐｒｏｃｅｓｓｏｒ）、エンベットプロセッサ、そして信号プロセッサ（ＤＳＰ）を含んでいる。これらのプロセッサは、また、ＣＩＳＣ，ＲＩＳＣ、ＶＬＩＷ、それらのハイブリッド、または他のタイプのプロセッサに基づいている。さらに他の実施例では、プロセッサまたは他の命令処理装置は、コントローラー（例えば、マイクロコントローラー）、またはマイコロコードやマイクロインストラクションを処理することができる他のタイプのロジック回路を表し得る。

図２を再び参照すると、インストラクション実行スケジューラーロジック２１２は、実行するインストラクションをスケジュールし、または発行するように動作可能である。使用中に、インストラクション実行スケジューラーロジック２１２は、コミット時における状態アップデート実行インストラクション２０２を受け取り得る。述べたように、コミット時における状態アップデート実行インストラクションは、タグ、または、そのインストラクションがコミット時における状態アップデート実行インストラクションであることを示す他の指標を有している。一つの態様では、このタグまたは他の指標は、（例えば、インストラクションフェッチ／シーケンサーロジックによって）フロントエンド（ｆｒｏｎｔ ｅｎｄ）において提供される。インストラクションフェッチ／シーケンサーロジックは、投機的実行を使用するプロセッサにおいて、特定の単一のインストラクションが非投機的に実行されることを指定するためのロジックを含んでいる。ここにおいて開示される実施例において、仕様は（例えば、タグ、またはインストラクションのフィールドの一つまたはそれ以上のビットを通じて）状態アップデートインストラクション上に含まれている。

インストラクション実行スケジューラーは、任意的なインストラクションキュー２０８を含んでいる。任意的なインストラクションキューは、コミット時における状態アップデート実行インストラクション２０２を含むインストラクション２１０を保管するために使用され得る。一つまたはそれ以上の実施例において、任意的なインストラクションキューは、また、オペランド（ｏｐｅｒａｎｄ）や、インストラクションに関する他のデータまたはパラメーターを保管することができる。インストラクションスケジューラーロジックは、実行のためのインストラクションキューにおいてインストラクションをスケジュール／発行するように動作可能である。一つの実施例において、インストラクションスケジューラーロジックはインオーダーのインストラクションをスケジュールし、もしくは、別の実施例において、インストラクションスケジューラーロジックはアウトオブオーダーのインストラクションをスケジュールし得る。

インストラクションスケジューラーロジックは、コミット時における状態アップデートロジック２１４を含んでいる。コミット時における状態アップデートロジックは、その状態アップデートインストラクションがコミットする次のインストラクションになるまで、コミット時における状態アップデート実行インストラクションをスケジュール／発行することを待つように動作可能である。コミット時における状態アップデート実行インストラクションよりも古いインストラクションは、コミット時における状態アップデート実行インストラクションがスケジュール／発行され、そして実行されることが許される以前に、実行されコミットされる。一つまたはそれ以上の実施例では、インストラクション実行スケジューラーロジックは、コミットする次のインストラクションの指標、及び／又は、実行が罰のコンポーネントからの非投機的なものであることの指標を受け取る。例えば、リオーダー（ｒｅｏｒｄｅｒ）バッファー、コミットロジック、または、分岐解決ロジック（例えば、分岐解決信号）、といったものである。状態アップデートインストラクションがコミットする次のインストラクションであり、及び／又は、非投機的なものであるときは、インストラクション実行スケジューラーロジックは、上つぃアップデートインストラクションを実行するようにスケジュール／発行２１６する。

実行ロジック２２０は、インストラクション実行スケジューラーロジックと結合されている。実行ロジックは、発行された状態アップデートインストラクションを受け取ることができる。実行ロジックは、ハードウェア（例えば、回路）、ソフトウェア、ファームウェア、または、これらのいくつかの組合せ、といった状態アップデートインストラクションを実行するためのロジックを含んでいる。一つまたはそれ以上の実施例において、実行ロジックは、状態アップデートインストラクションを実行するための少なくとも一つのいくつかの回路を含んでいる。例えば、回路は、状態アップデートインストラクションまたはマイクロインストラクションに対応する特定の／特別化された回路を含み得る。

一つまたはそれ以上の実施例において、コミット時における状態アップデート実行インストラクションは、プロセッサまたは他の命令処理装置のアウトオブオーダー部分における、スケジュール／発行そして実行から保留され得る。一つまたはそれ以上の実施例において、インストラクションスケジューラーロジックは、プロセッサまたは他の命令処理装置のアウトオブオーダー部分に含まれ得る。

図３は、コミット時における状態アップデート実行インストラクションをスケジュールする方法３７０の実施例に係るフローチャートである。本方法は、ブロック３７１において、コミット時における状態アップデート実行インストラクションを受け取ることを含んでいる。本方法は、ブロック３７２において、そのコミット時における状態アップデート実行インストラクションがコミットする次のインストラクションになるまで、コミット時における状態アップデート実行インストラクションを実行するようにスケジュールするのを待つことを含んでいる。本方法は、ブロック３７３において、それがコミットする次のインストラクションであるときに、コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを含んでいる。

図４は、コミット時における状態アップデート実行インストラクションを発行するためのアウトオブオーダーインストラクション実行スケジューラーキュー４０６の実行を有するアウトオブオーダープロセッサまたは他の命令処理装置４０４に係る実施例のブロックダイヤグラムである。プロセッサまたは他の命令処理装置とは種々のタイプのものであり、例を挙げるとすれば、例えば、複合命令セットコンピューティング（ＣＳＩＣ）タイプ、縮小命令セットコンピューティング（ＲＩＳＣ）タイプ、超長命令語（ＶＬＩＷ）タイプ、そして、それらの組合せといったものである。

一つまたはそれ以上の実施例において、プロセッサは汎用プロセッサであり得る。例えば、そうである必要もないが、カリフォルニア州サンタクララのインテルコーポレーションによって製造された汎用プロセッサの一つである。インテルコーポレーションから提供される好適な汎用プロセッサのいくつかの実施例は、これらに限定されるわけではないが、インテルＡｔｏｍプロセッサ、インテルＣｏｒｅプロセッサ、インテルＣｏｒｅ２プロセッサ、インテルＰｅｎｔｉｕｍ（登録商標）プロセッサ、そしてインテルＣｅｌｅｒｏｎプロセッサを含んでいる。

代替的には、プロセッサは専用プロセッサであり得る。好適な専用プロセッサの代表的なの実施例は、これらに限定されるわけではないが、例を挙げるとすれば、ネットワークプロセッサ、通信プロセッサ、暗号プロセッサ、グラフィックプロセッサ、コプロセッサ（ｃｏ−ｐｒｏｃｅｓｓｏｒ）、エンベットプロセッサ、そして信号プロセッサ（ＤＳＰ）を含んでいる。これらのプロセッサは、また、ＣＩＳＣ，ＲＩＳＣ、ＶＬＩＷ、それらのハイブリッド、または他のタイプのプロセッサに基づいている。さらに他の実施例では、プロセッサまたは他の命令処理装置は、コントローラー（例えば、マイクロコントローラー）、またはマイコロコードやマイクロインストラクションを処理することができる他のタイプのロジック回路であり得る。

プロセッサは、インストラクションをアウトオブオーダーに実行するように動作可能なアウトオブオーダープロセッサである。いくつかのケースにおいて、後のインストラクションは、前のインストラクションの実行に依存することがある。インストラクションをアウトオブオーダーに実行する能力によって、プロセッサは、パイプラインにおける、前のインストラクションの実行に依存しないパイプラインの部分をインストラクションで満たすことができる。一方で、前のインストラクションの実行に依存している部分は、依存しているインストラクションが完了するのを待つ。このことは、プロセッサのパフォーマンスを増加させるのを手伝っている。プロセッサは、しかしながら、オリジナルのプログラム順序において、ソフトウェアまたはユーザーに対してプロセッサのアーキテクチャー（ａｒｃｈｉｔｅｃｔｕｒａｌ）状態を示し得る。これを成し遂げるために、アウトオブオーダープロセッサは、より古いインストラクションの前に実行されたより新しいインストラクションの実行からの状態を、より古いインストラクションが使用可能になる後まで保持されるようにするロジック（例えば、リオーダー（ｒｅ−ｏｒｄｅｒ）バッファー）を含み得る。より古いインストラクションの実行が使用可能になったときに、リタイアメント（ｒｅｔｉｒｅｍｅｎｔ）ロジックまたはコミットロジックは、オリジナルのインストラクション順序における状態をアップデートすることによって、プロセッサの（例えば、リオーダーバッファーからの）アーキテクチャー状態のアップデートをコントロールするように動作可能である。リオーダーバッファーのエントリーに対する可視的状態のマッピング（ｍａｐｐｉｎｇ）は、リネイムによって達成され得る。

図４を再び参照すると、アウトオブオーダープロセッサまたは他の命令処理装置は、インストラクションをインオーダーで処理する、インオーダーのフロントエンドセクションまたは部分４２４を含んでいる。制限なく、フロントエンドは一つまたはそれ以上のコンポーネントを含み得る。例えば、インストラクションフェッチ／シーケンスロジック（例えば、図示されていないが、インストラクションフェッチ／シーケンスロジックまたは回路）、インストラクションデコードロジック（例えば、図示されていないが、デコーダーまたはデコード回路）、そして、インストラクションディスパッチロジック（例えば、図示されていないが、インストラクションディスパッチロジックまたは回路）といったものであるが、本発明の範囲がフロントエンドにおけるあらゆる既知のコンポーネントに限定されることはない。一つまたはそれ以上の実施例において、フロントエンドまたは部分（例えば、フェッチ／スケジューラーロジック）におけるロジックは、状態アップデートインストラクションがコミットバラエティ（ｖａｒｉｅｔｙ）において実行できることをタグ（ｔａｇ）し、または、そうでなければ指定する。

アウトオブオーダープロセッサまたは装置は、また、フロントエンドセクションまたは部分と併せて、コミット時における状態アップデート実行インストラクション４０２を含む命令を受け取るためのバックエンドセクションまたは部分を含んでいる。アウトオブオーダーバックエンドは、インストラクションをリオーダー（ｒｅｏｒｄｅｒ）し、その命令をアウトオブオーダーに処理し得る。

示したように、アウトオブオーダーバックエンドは、アウトオブオーダーバックエンドスケジューラーキュー４０６を含んでいる。アウトオブオーダーバックエンドスケジューラーキューは、また、ダイナミックインストラクション実行スケジューラーキューとしても参照される。アウトオブオーダーバックエンドは、また、インストラクションリオーダーロジック（例えば、リオーダーバッファー、図示なし）および命令実行ロジック（例えば、実行ロジック、図示なし）を含んでいる。命令実行ロジックは、インストラクションをアウトオブオーダーに実行し、実行結果４３０を提供する。

図示されたアウトオブオーダーインストラクション実行スケジューラーキューは、インストラクションキュー４０８、アウトオブオーダーインストラクションスケジューラーロジック４２８、そして、コミット時における状態アップデートロジック４１４を含んでいる。インストラクションキューは、前述されている。コミット時における状態アップデートロジックは、一つまたはそれ以上の実施例に従って、状態アップデートインストラクションがコミットする次のインストラクションになるまで、アウトオブオーダーインストラクション実行スケジューラーキューに、コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待たせる。

アウトオブオーダーインストラクションスケジューラーロジックは、インストラクションキューの中のインストラクションをアウトオブオーダーにスケジュールし得る。一つの態様では、アウトオブオーダーインストラクションスケジューラーロジックは、インストラクションを実行するようにスケジュールする前に、数多くの要素を保証し、確認し、または評価するロジックを含んでいる。こうした要素の典型的な例は、インストラクションの入力（例えば、ソース（ｓｏｕｒｃｅ）オペランド）がこれまでのところ実行されていないインストラクションの実行結果に依存しているかどうか、インストラクションの入力がメモリーからロードされる必要があるかどうか、そして、インストラクションがビジー（ｂｕｓｙ）な実行ロジックまたは他のリソースが使用可能になるまで待つ必要があるかどうか、を潜在的に含んでいる。

有利なことに、インストラクション実行スケジューラー４０６は、アウトオブオーダーインストラクション実行スケジューラーキューであり、プロセッサのアウトオブオーダー部分またはセクション４２６に配置されており、アウトオブオーダーインストラクションスケジューラーロジックを有しているので、アウトオブオーダーインストラクション実行スケジューラーキューは、コミット時における状態アップデート実行インストラクション４０２を実行するためのスケジュール／発行の前に、一つまたはそれ以上のより新しいインストラクション４１０を実行するためのスケジュール／発行をするように動作可能であり、コミット時における状態アップデート実行インストラクションがコミットする次のインストラクションになるまでスケジュール／発行および実行を引き止められる。明確化のためであるが、より新しいインストラクション４１０がコミット時における状態アップデート実行インストラクション４０２の実行よりも新しいということは、それらのインストラクションがコミット時における状態アップデート実行インストラクションの実行の後でオリジナルのプログラム順序において年代順に起こるということ（例えば、コミット時における状態アップデート実行インストラクションがインオーダーフロントエンドにおいて実行された後で、より新しいインストラクションはフェッチされデコードされるだろう）を意味している。

有利なことに、引き止められたコミット時における状態アップデート実行インストラクションを避けて、より新しいインストラクションを発行し実行できるようにすることは、実行におけるバブル（ｂｕｂｂｌｅ）を避けることを手助けする。そうでなければ、パフォーマンスが低下してしまうであろう。もし、替わりに、コミット時における状態アップデート実行インストラクションが、インオーダーフロントエンド部分またはセクションにおいて、実行から引き止められる場合には、そのコミット時における状態アップデート実行インストラクションより新しい全てのマイクロインストラクションも、また、コミット時における状態アップデート実行インストラクションの後ろでの発行および実行から引き止められるであろう。より新しいマイクロインストラクションは、引き止められたコミット時における状態アップデート実行インストラクションをうまく避けることができない。コミット時における状態アップデート実行インストラクションと全てのより新しいインストラクションは、そのコミット時における状態アップデート実行インストラクションより古い全てのインストラクションがパイプラインをトラバース（ｔｒａｖｅｒｓｅ）する間に引き止められ、そのコミット時における状態アップデート実行インストラクションとあらゆるより新しいインストラクションを発行し実行する前に、潜在的にレイテンシー（例えば、ロードミスによるもの、等）を生じる。このことは、パフォーマンスを低下させてしまい、実行におけるバブルを引き起こし得る。

図４を再び参照すると、アウトオブオーダープロセッサまたは装置は、また、アウトオブオーダーバックトエンドセクションまたは部分と併せて、実行結果４３０を受け取るためのインオーダーコミットロジック４３２を含んでいる。インオーダーコミットロジックは、実行結果がインオーダーであり、次に実行結果をインオーダーにコミットするように、実行結果をリオーダーする。一つの態様においては、コミットロジックは、オリジナルのプログラム順序において先にある全てのより古いインストラクションがコミットされるまでは、インストラクションをコミットしない。インストラクションをコミットすることは、インオーダーのインストラクションに関する実行結果を、プログラムのレジスターファイルまたは他のプログラマーが見ることができるアーキテクチャー（ａｒｃｈｉｔｅｃｔｕａｌ）状態４３４に書き込むことを含む。インストラクション結果がプロセッサに書き込まれるときに、そのインストラクションはコミットされたと言われる。以前に述べた状態アップデートインストラクションの場合は、アーキテクチャー状態は、上述の内部状態（例えば、フラグ、コントロールレジスター、等）を含み得る。一つの態様では、内部状態は、状態アップデートインストラクションが実行されるとき、実際にコミットされる前に、アップデートされる。例えば、これはリネイムされていない内部状態の場合である。プロセッサは、リネイムされたプロセッサ状態をコミット時においてアップデートし得るが、リネイムされていないプロセッサ状態は実行時においてアップデートできる。

図５は、コミット時における状態アップデート実行インストラクション５０２を発行するためのアウトオブオーダーインストラクション実行スケジューラーキュー５０６に係る特定の実施例を有するアウトオブオーダープロセッサまたは他の命令処理装置５０４に係る実施例のブロックダイヤグラムである。プロセッサまたは他の命令処理装置は、上述した種々のタイプのあらゆるものであり得る（例えば、ＣＩＳＣ，ＲＩＳＣ、汎用、専用、等）

プロセッサまたは他の装置は、発行リオーダーバッファー５４０を含んでいる。一つまたはそれ以上の実施例において、発行リオーダーバッファーは、インオーダーフロントエンドと実行ロジックとの間に接続されたバッファーであり得る。インストラクションは、発行リオーダーバッファーにインオーダーで入り、発行リオーダーバッファーは、インストラクションに関する情報と同様にインストラクションを保管、またはバッファーし得る。例えば、インストラクションステイタス（ｓｔａｔｕｓ）、オペランド、そして、プログラム順序またはシーケンスにおけるインストラクションのオリジナルな場所または位置、といったものである。インストラクション（例えば、入力オペランド）を実行するために必要なデータが使用可能になり、インストラクションを実行するために必要なリソースが使用可能になるまで、インストラクションは、発行リオーダーバッファーの中で待つことができる。

プロセッサまたは他の装置は、また、アウトオブオーダーインストラクション実行スケジューラーキューを含み、コミット時における状態アップデート実行インストラクション５０２を受け取るよう動作可能である。示したように、一つまたはそれ以上の実施例において、コミット時における状態アップデート実行インストラクションは、任意的にプロセッサのアロケーター（ａｌｌｏｃａｔｏｒ）ロジック５４２から受け取られ、アウトオブオーダーインストラクション実行キューと結合される。

アウトオブオーダーインストラクション実行スケジューラーキューは、インストラクションキュー５０８を含んでおり、上述のようにコミット時における状態アップデート実行インストラクションを含むインストラクションを保管するために使用され得る。アウトオブオーダーインストラクション実行スケジューラーキューは、また、アウトオブオーダーインストラクションスケジューラーロジック５１２を含んでおり、上述のように潜在的にアウトオブオーダーでインストラクションを実行するようにスケジュールし得る。アウトオブオーダーインストラクション実行スケジューラーキューは、また、コミット時における状態アップデートロジック５１４を含んでおり、上述のように一つまたはそれ以上の実施例において、状態アップデートインストラクションがコミットする次のインストラクションになるまで、その状態アップデートインストラクションを実行するようにスケジュールするのを待つことができる。示したように、アウトオブオーダーインストラクション実行スケジューラーロジックは、コミットする次のインストラクション５４４の指標を受け取ることができる。

プロセッサまたは他の装置は、また、アウトオブオーダーインストラクション実行スケジューラーキューに結合されたアウトオブオーダー実行ロジック５２０を含んでいる。実行ロジックは、インストラクション実行スケジューラーキューから発行またはスケジュールされたインストラクションを受け取ることができる。インストラクションは、コミットされるべき次のインストラクションであることが示されたときは、コミット時における状態アップデート実行インストラクションを含んでいる。アウトオブオーダー実行ロジックは、少なくともいくつかの回路の一つの実施例において、この場合のインストラクションをアウトオブオーダーで実行するようなロジックを含み得る。

プロセッサまたは他の装置は、また、実行結果を受け取るためにアウトオブオーダー実行ロジックに結合されたインオーダーコミットロジック５３２を含んでいる。示したように、一つまたはそれ以上の実施例において、コミットロジックは、コンプリート（ｃｏｍｐｌｅｔｅ）リオーダーバッファー５４６を含んでいる。コンプリートリオーダーバッファー５４６と発行リオーダーバッファー５４０は、同一のバッファーでも異なるバッファーでもどちらでもよい。一つのまたはそれ以上の実施例において、発行リオーダーバッファーとコンプリートリオーダーバッファーは、特定のアウトオブオーダープロセッサにおいて採用されているように、従来の、または実質的に従来のリオーダーバッファー（ＲＯＢ）であり得る。別の実施例においては、リオーダーバッファーは、コンプリーション（ｃｏｍｐｌｅｔｉｏｎ）キューに置き換えられ得る。

コンプリートリオーダーバッファーは、インストラクションと実行結果を、それらがインオーダーにコミットされる準備ができるまでバッファーする。リオーダーバッファーは、実行されたインストラクションを記録し、実行されたインストラクションをインオーダーにリタイアまたはコミットすることを手伝う。コンプリートリオーダーバッファーは、インストラクションとプロセッサのアウトオブオーダーセクションから来る関連する結果データを、インストラクションがプロセッサのインオーダーフロントエンドセクションに持っていたのと同一のオーダー（ｏｒｄｅｒ）に入れ込むためのロジックを有している。インストラクションはコミットすると、リオーダーバッファーから結果データを読み出し、その結果データをプロセッサのアーキテクチャー状態に対して書き込む。上述のコミット時における状態アップデート実行インストラクションの場合は、アーキテクチャー状態は、上述した内部状態を含み得る（例えば、フラグ、コントロールレジスター、等）。一つの態様において、内部状態は、状態アップデートインストラクションが実行されるとき、それが実際にコミットされる前に、アップデートされる。例えば、リネイムされていない内部状態がこの場合である。プロセッサは、リネイムされたプロセッサ状態をコミット時においてアップデートするが、リネイムされていないプロセッサ状態は実行時においてアップデートする。

示したように、一つまたはそれ以上の実施例において、コンプリートリオーダーバッファーは、リタイアされたインストラクションを記録しており、アウトオブオーダー実行スケジューラーキューに対してリタイアポインターまたはリタイアする次のインストラクションの他の指標５４４を提供する。リタイアする次のインストラクションは、コミットする次のインストラクションの例である。追加的な例をいくつか挙げるとすれば、インストラクションがコミットする準備ができていることの指標の他の例は、コンプリート信号を含み、または、動的予測解決（例えば、分岐解決信号）に基づいている。また、リタイアの概念は、ここではアウトオブオーダープロセッサのために示されているが、アウトオブオーダープロセッサに限定されるものではないことが明確にされるべきである。コミット時における実行インストラクションがコミットする次のインストラクションであるときには、コンプリートリオーダーバッファーは、アウトオブオーダーインストラクション実行スケジューラーキューに対して、そのコミット時における状態アップデート実行インストラクションがコミットする次のインストラクションであることの指標を提供する。そして、コミット時における状態アップデート実行インストラクションは発行され、実行され、内部状態５３６をアップデートする。

アウトオブオーダープロセッサがインストラクションを投機的に実行するときは、投機的に実行されたインストラクションとその実行結果は、非投機的に実行されたインストラクションと一緒にリオーダーバッファーに保管される。しかしながら、リオーダーバッファーは、投機的に実行されたインストラクションと実行結果を記録し、投機的な実行が必要であることが確認されるまでは（例えば、条件付分岐インストラクションの方向が正しく予測されたと確認されること）、その投機的に実行されたインストラクションと実行結果をコミットしない。現在必要であることが確認されたインストラクションと実行結果は、次にコミットされ、アーキテクチャー状態に対して書き込まれる。代替的には、投機的な実行がエラーであり必要でないこと（例えば、条件的分岐インストラクションの方向が間違って予測されたこと）が判明した場合は、投機的に実行されたインストラクションと実行結果はコミットされず、アーキテクチャー状態に対して書き込まれない（例えば、それらはリオーダーバッファーから削除される）。有利なことに、この実施例においては、コミット時における状態アップデート実行インストラクションがコミットする次のインストラクションであること（そのコミット時における状態アップデート実行インストラクションが投機的なものではないことの決定を含む）を、リオーダーバッファーが示す後までプロセッサの内部状態のアップデートまたは変更を保留することによって、内部状態の投機的なアップデートが防がれ、少なくとも減少される。

図６は、コミット時における状態アップデート実行インストラクション６０２を発行するためのコミット時における状態アップデートロジック６１４に係る特定の実施例を有する予約ステーション６０６に係る特定の実施例のブロックダイヤグラムである。予約ステーションは、アウトオブオーダーインストラクション実行スケジューラーキューまたはインストラクションスケジュールロジックの実施例を表している。以下に述べる特徴は別として、もしくはコミット時における状態アップデートロジックまたはコミット時における状態アップデート実行インストラクションの予約ステーションとの相互作用に適用して、予約ステーションは他の従来的な、または実質的に従来的な特徴を有している。予約ステーションは、プロセッサの実行ロジックに対して中心的であっても、プロセッサの実行ロジックによって共有されてもよい。または、ことなる予約ステーションが異なる実行ロジックのセットに対して提供され得る。

予約ステーションは、６５０−０から６５０−ｎまでの複数のエントリーを有しており、数字ｎは２より大きい整数であって、例えば、およそ１０から１００までである。それぞれのエントリーは、６０８−０から６０８−ｎのキューを有しており、インストラクションと、いくつかの場合には、インストラクションに関する雑多な予約ステーションデータ（例えば、インストラクションに関するオペランド）をキューする。一つまたはそれ以上の実施例において、予約ステーションは、レジスターへのデータが書き込まれる結果バスを探り、またはモニターするように動作可能であり、そして予約ステーションは、データキューにおける結果バスからのデータを保管するように動作可能である。これにより、後でレジスターからデータにアクセスする必要がないように手助けする。

予約ステーションは、また、複数のフィジカルデスティネーション（ｐｄｓｔ）ポインター保管場所６５２−０から６５２−ｎを有している。これらの場所は、対応するインストラクションのためのデータが存在するところのリオーダーバッファーにおけるフィジカルデスティネーションまたはエントリーに対するポインターを保管するように動作可能である。それぞれのインストラクションおよびそれぞれのエントリーは、フィジカルデスティネーション（ｐｄｓｔ）ポインターを有し得る。これらのフィジカルデスティネーション（ｐｄｓｔ）ポインターのそれぞれは、予約ステーションにおける対応するエントリーに保管されたインストラクションの指標を表している。

予約ステーションは、また、コミット時における状態アップデートロジック６１４を有している。コミット時における状態アップデートロジックは、非投機的に、及び／又はコミット時に実行するようにタグ（ｔａｇｇｅｄ）された状態アップデートインストラクションのスケジュールを、その状態アップデートインストラクションが次にリタイアするか、もしそうでなければコミットするまで、ブロックするように動作可能である。

コミット時における状態アップデートロジックは、状態アップデートインストラクションが非投機的に、及び／又はコミット時に実行すべきことの指標をコミット時における状態アップデートインストラクションに結合させ、インストラクションシーケンスの中でコミット時における状態アップデートインストラクションのエイジオーダー（ａｇｅ−ｏｒｄｅｒ）と結合させるためのロジックを含んでいる。例えば、図示された実施例において、コミット時における状態アップデートロジックは、コミット時におけるビット６５４−０から６５４−ｎの一つまたはそれ以上の複数のセットを含んでいる。コミット時における一つまたはそれ以上のビットのセットそれぞれは、予約ステーションにおける異なるエントリーに対応している。コミット時における状態アップデートロジックは、また、コミット時におけるビットのセットそれぞれに結合されたビット値調整ロジック６５６を含んでいる。ビット値調整ロジックは、コミット時における状態アップデートインストラクション６０３に応じて、一つまたはそれ以上のコミット時おけるビットのセットの値を、コミット時における状態アップデートインストラクションに応じて予約ステーションにおけるエントリー時において（例えば、コミット時における状態アップデートインストラクションがキューされるべきエントリー時において）、与えられた値に調整するように動作可能である。

例として、コミット時におけるビットは、コミット時における状態アップデートインストラクションに応じて（一つの慣習に従って）値１に設定されるか、（別の慣習に従って）値０にクリアされるかどちらでもよい。一つまたはそれ以上の実施例において、コミット時における状態アップデートロジックは、インストラクションがコミット時におけるインストラクションのフレーバー（ｆｌａｖｏｒ）であるかを決定するためのコミット時における状態アップデートインストラクションに係るオペコードをデコードするためのデコーダーを含み、そして、それに応じてビットを調整する。デコーダーは、種々の異なるタイプのメカニズムを使用して実行され得る。好適なメカニズムのタイプの例は、これらに限定されるわけではないが、マイクロコード読み出し専用メモリー（ＲＯＭ）、ルックアップテーブル、ハードウェアによる実行、プログラム可能なロジックアレイ（ＰＬＡ）、といったものである。デコーダーは、ハードウェア（例えば、回路）、ファームウェア、ソフトウェア、または、これらの組合せにおいて実行され得る。コミット時における実行の指標がオペコードを通じて提供されることは必要ではなく、むしろ別のフィールドを通じて提供され得るものである。

コミット時における状態アップデートロジックは、また、決定ロジック６５８を含んでいる。一つの態様では、決定ロジックは、インストラクションキューにおける異なるエントリーにそれぞれ対応する６５８−０から６５８−ｎの決定ロジックの複数のセットを含む。決定ロジックのセットのそれぞれは、異なる一つのフィジカルデスティネーション（ｐｄｓｔ）ポインターを受け取るために、対応する異なる一つのフィジカルデスティネーション（ｐｄｓｔ）ポインター保管場所に結合されている。決定ロジックのセットのそれぞれは、また、例えば、リタイアポインター６４４（例えば、リタイアテイル（ｔａｉｌ）ポインター）を受け取るためにリオーダーバッファーに結合され、リタイアか、そうでなければコミットする次のインストラクションの指標の実施例を表している。決定ロジックのセットのそれぞれは、また、異なった対応するコミット時におけるビットのセットの一つを受け取るために、異なった対応する一つまたはそれ以上のコミット時におけるビットのセットの一つに結合されている。

決定ロジックは、エイジオーダー（ａｇｅ−ｏｒｄｅｒ）コンパレーターロジックを含んでおり、状態アップデートインストラクションが非投機的に、及び／又はコミット時において実行されるべきであるコミット時におけるビット６５４を介した指標とのエイジオーダー比較（例えば、リタイアポインター６４４とｐｄｓｔ６５２の比較）を適格とするロジックを含んでいる。コミット時における状態アップデートインストラクションに対応する、インストラクションキューにおけるエントリーでのコミット時におけるビットの一つまたはそれ以上のセットが値（例えば、コミット時における状態アップデートインストラクションの実行のために取るであろう値）を与えられるときに、決定ロジックは、コミットする次のインストラクションの指標（例えば、リタイアポインター）が、コミット時における状態アップデートインストラクションに対応するインストラクションキューにおけるエントリーでのコミット時における状態アップデートインストラクションの指標（例えば、コミット時における状態アップデート実行インストラクションがキューされているところのエントリーでのフィジカルデスティネーション（ｐｄｓｔ）ポインター）と一致するかどうかを決定するように動作可能である。

予約またはスケジュールロジックは、マイクロインストラクションが次にコミット（例えば、リタイア）するまで、コミット時における状態アップデートインストラクションを実行のためにスケジュールすることからブロックする。フィジカルデスティネーション（ｐｄｓｔ）ポインターがリタイアポインターと一致しないか、同じでない場合には、コミット時における状態アップデート実行インストラクションは、リタイアか、そうでなければコミットする次のインストラクションではないものと推察され、デスティネーションロジックは、コミット時における状態アップデート実行インストラクションをスケジュールまたは発行するのを待ち続ける。例えば、デスティネーションロジックは、アウトオブオーダースケジュールロジックに対してブロック信号を提供する。このことは、コミット時における状態アップデート実行インストラクションは、まだコミットの準備ができていないことを意味する。コミット時における状態アップデート実行インストラクションの前のより古いインストラクションは、そのコミット時における状態アップデート実行インストラクションがコミットすることを許される以前にリタイアか、そうでなければコミットする必要がある。コミット時における状態アップデート実行インストラクションが予約ステーションにおいて最も古いインストラクションであり、リタイアか、そうでなければコミットする準備ができるときまでに、最も古いインストラクションはリタイアされる。いくつかのポイントにおいて、フィジカルデスティネーション（ｐｄｓｔ）ポインターがリタイアポインターと一致または同じである場合には、コミット時における状態アップデート実行インストラクションはコミットする次のインストラクションであると推察または決定され、決定ロジックはコミット時における状態アップデート実行インストラクションをスケジュールまたは発行することが可能であると決定する。

一つまたはそれ以上の実施例において、デスティネーションロジックのセットそれぞれは、これは要求されるものではないのだが。コンペアイコールタイプ（ｃｏｍｐａｒｅ ｅｑｕａｌ ｔｙｐｅ）のロジックを含み得る。コンペアイコールロジックは、例えば、イクスクルーシブオア（ｅｘｃｌｕｓｉｖｅ ＯＲ）で実施され得る。代替的には、リタイアポインターがフィジカルデスティネーション（ｐｄｓｔ）ポインターと一致または同じであるかどうかを決定するのに好適な別のタイプのデスティネーションまたはコンペアロジックが、代わりに使用され得る。

アウトオブオーダースケジュールロジックは、デスティネーションロジックからブロック信号または非ブロック信号を受け取る。コミット時における状態アップデート実行インストラクションに対応するエントリーのための一つまたはそれ以上のコミット時におけるビットが与えられた値であるときは、それらはコミット時における状態アップデート実行インストラクションのために調整され、アウトオブオーダースケジュールロジックは、ブロック信号が示されているときには、コミット時における状態アップデート実行インストラクションをスケジュールしない。しかし、非ブロック信号が示されているときは、アウトオブオーダーインストラクションスケジュールにおいて従来的に考慮されている他の要因（例えば、リソース、及び／又はデータ使用可能性）に応じて、コミット時における状態アップデート実行インストラクションをスケジュールし得る。一つまたはそれ以上の実施例において、アウトオブオーダースケジュールロジックは、ブロック信号、レディー（ｒｅａｄｙ）信号、そしてピッカー（ｐｉｃｋｅｒ）ロジックを含んでおり、コミット時における状態アップデート実行インストラクションによるブロック／非ブロック信号または態様を考慮することは別としてであるが、アウトオブオーダースケジュールロジックは従来的または実質的に従来的であり得る。

これは、一つの説明的な実施例にすぎない。状態アップデートインストラクションの実行を異なる形でブロックするロジックを有し、リタイア時におけるのとは別の異なる信号（例えば、分岐解決信号または他のコミット時での信号）を使用する他の実施例が考えられる。

さらに別の実施例が、ここにおいて述べた一つまたはそれ以上のプロセッサを有し、及び／又は、ここにおいて述べた方法を実行するシステム（例えば、コンピューターシステム、または他の電子デバイス）に適用される。図７は、好適なコンピューターシステム、または他の電子デバイス７８０の実施例に係るブロックダイヤグラムである。

コンピューターシステムは、プロセッサ７８２を含んでいる。一つまたはそれ以上の実施例において、プロセッサは、ここにおいて述べたように、マイクロコードのエイリアスされた（ａｌｉａｓｅｄ）パラメーターを通過させるロジック、及び／又はマイクロコードのエイリアスされたパラメーターをセーブし保管するロジックを含んでいる。

プロセッサは、一つまたはそれ以上のコアを有している。マルチコアプロセッサの場合には、マルチコアはモノリシックに（ｍｏｎｏｌｉｔｈｉｃａｌｌｙ）単一の集積回路（ＩＣ）チップまたはダイ上に統合され得る。一つの態様において、それぞれのコアは、少なくとも一つの実行ユニットと少なくとも一つのキャッシュを含んでいる。プロセッサは、また、一つまたはそれ以上の共有キャッシュを含み得る。

一つの特定な実施例において、プロセッサは、統合されたグラフィックコントローラー、統合されたビオデコントローラー、そして、これは要求されるものではないが、汎用マイクロプロセッサの単一のダイ上にそれぞれモノリシックに統合されたメモリーコントローラー、を含んでいる。代替的には、これらのコンポーネントのいくつか、または全ては、プロセッサの外に配置され得る。例えば、統合されたメモリーコントローラーはプロセッサから除外することができ、チップセットはメモリーコントローラーハブ（ＭＣＨ）を有する。

プロセッサは、バス（例えば、フロントサイドバス）または他の相互接続を介してチップセット７８４に結合されている。相互接続は、プロセッサとシステムの中の他のコンポーネントとの間でチップセットを介してデータ信号を伝送するために使用される。

メモリー７８５はチップセットに結合されている。種々の実施例において、メモリーは、ランダムアクセスメモリー（ＲＡＭ）を含んでいる。ダイナミックＲＡＭ（ＤＲＡＭ）は、全てではないがいくつかのコンピューターシステムにおいて使用されるＲＡＭのタイプの例である。

コンポーネント相互接続７８６も、また、チップセットに結合される。一つまたはそれ以上の実施例において、コンポーネント相互接続は、一つまたはそれ以上のペリフェラルコンポーネント相互接続エクスプレス（ＰＣＩｅ）インターフェイスを含み得る。コンポーネント相互接続は、他のコンポーネントが、チップセットを通じて残りのシステムに結合されるようにする。こうしたコンポーネントの一つの例は、任意的であり必要とされるものではないが、グラフィックチップ、または他のグラフィックデバイスである。

データストレージ７８８はチップセットに結合されている。種々の実施例において、データストレージはハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭデバイス、フラッシュメモリーデバイス、ダイナミックランダムアクセスメモリー（ＤＲＡＭ）等、または、これらの組み合わせを含んでいる。

ネットワークコントローラー７８７も、また、チップセットに結合されている。ネットワークコントローラーは、システムをネットワークに結合させる。

シリアル拡張ポート７８９も、また、チップセットに結合されている。一つまたはそれ以上の実施例において、シリアル拡張ポートは、一つまたはそれ以上のユニバ−サルシリアルバス（ＵＳＢ）ポートを含んでいる。シリアル拡張ポートは、他のタイプの入力／出力デバイスが、チップセットを通じて残りのシステムに結合されるようにする。

チップセットに任意的に結合され得る他のコンポーネントの説明的ないくつかの例は、これらに限定されるわけではないが、オーディオコントローラー、ワイヤレストランシーバー、そしてユーザー入力デバイス（例えば、キーボード、マウス）を含んでいる。

一つまたはそれ以上の実施例において、コンピューターシステムは、ワシントン州レッドモンドにあるマイクロソフトコーポレーションから提供されるＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムを実行し得る。代替的には、例えば、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）、またはエンベッドされたシステムといった、他のオペレーティングシステムが使用され得る。

これは、一つの好適なコンピューターシステムの特定な例にすぎない。ラップトップ、デスクトップ、ハンドヘルドＰＣ、パーソナルデジタルアシスタント、エンジニアリングワークステーション、サーバー、ネットワークデバイス、ネットワークハブ、スイッチ、ビデオゲームデバイス、セットトップボックス、そしてプロセッサを有する種々の他のデバイスのための技術として知られている他のシステムデザインや構成も、また、好適である。いくつかの場合に、システムはマルチプロセッサを有している。

明細書と特許請求の範囲において、用語「結合された（ｃｏｕｐｌｅｄ）」および「接続された（ｃｏｎｎｅｃｔｅｄ）」が、その派生語と一緒に使用されている。むしろ、特定の実施例において、「接続された（ｃｏｎｎｅｃｔｅｄ）」は、２つまたはそれ以上のエレメントが、物理的または電気的に直接お互いに接触していることを示すために使用され得る。「結合された（ｃｏｕｐｌｅｄ）」は、２つまたはそれ以上のエレメントが、物理的または電気的に直接接触していることを意味している。しかしながら、「結合された（ｃｏｕｐｌｅｄ）」は、また、２つまたはそれ以上のエレメントが、物理的または電気的に直接お互いに接触しているのではないが、それでもお互いに協働または相互作用し得ることをも意味している。例えば、インストラクション実行スケジューラーキューは、一つまたはそれ以上の介在するコンポーネントを通じて実行ロジックに結合され得る。

上記において、説明目的として、本発明の実施例の完全な理解を提供するために、数多くの特定の詳細が明らかにされてきた。しかしながら、当業者にとっては、これら特定の詳細のいくつかが無くても一つまたはそれ以上の他の実施例が実行できることが明らかであろう。上記の特定の実施例は、本発明を限定するために提供されたのではなく、本発明の実施を説明するためのものである。本発明の範囲は、上記の特定の実施例によって決定されるのではなく、添付の請求項によってのみ決定されるものである。他の実施例においては、よく知られた回路、構成、デバイス、そしてオペレーションがブロックダイヤグラムの形式で示されており、もしくは、説明の理解の妨害を避けるために詳細を除いて示されている。適切であると考えられる場所においては、任意的に同様な特性をもった、対応または類似するエレメントを示すために、参照数字または参照数字の末端部分が、図において繰り返されている。

種々のオペレーション及び方法が述べられてきている。いくつかの方法はフローチャートにおいて基本的な形式で記述されているが、任意的なオペレーションが、その方法に対して加えられ、及び／又は、除外され得る。加えて、フローチャートは、実施例に従ったオペレーションの特定の順序を示しているが、そうした特定の順序は典型的なものであることが理解されるべきである。代替的な実施例では、任意的に、異なる順序でオペレーションを実行し、あるオペレーションを組み合わせ、あるオペレーションをオーバーラップ等、することができる。方法に対して多くの変形や改造がなされ、考慮され得る。

特定のオペレーションは、ハードウェアコンポーネントによって実行され、または機械で実行可能もしくは回路で実行可能なインストラクションにおいて具現化され、回路またはオペレーションを実行するインストラクションでプログラムされたハードウェアを生じさせるために使用され、もしくは少なくとも結果として生じる。回路は、いくつか例を挙げるとすれば、汎用または専用のプログラム、ロジック回路を含み得る。オペレーションは、また、任意的にハードウェアとソフトウェアの組み合わせによって実行され得る。実行ロジック、及び／又はプロセッサは、特定もしくは所定の回路、または、インストラクションもしくはマイクロインストラクションに対応する他のロジック、または、特定のオペレーションを実行するためのマシンインストラクションから派生した一つまたはそれ以上のコントロール信号、を含み得る。

一つまたはそれ以上の実施例は、機械でアクセス可能、及び／又は機械で読取り可能な媒体を含む製品（例えば、コンピュータープログラム製品）を含み得る。媒体は、機械でアクセス可能、及び／又は読取り可能な形式で情報を提供、例えば保管または伝送する、メカニズムを提供する。機械でアクセス可能、及び／又は読取り可能な媒体は、一つまたはそれ以上のインストラクションのシーケンスを提供し、または媒体上に保管し得るし、及び／又は、機械によって実行される場合に、機械の実施を生じ、または結果として生じさせ、及び／又は、機械に、ここにおいて開示された図に示されたオペレーションまたは方法または技術の一つまたはそれ以上の部分を実施させるようなデータ構造を提供し得る。

一つの実施例においては、機械で読取り可能な媒体は、有形で固定の機械で読取り可能なストレージ媒体を含み得る。例えば、有形で固定の機械で読取り可能なストレージ媒体は、フロッピー（登録商標）ディスク、光記録媒体、光ディスク、ＣＤ−ＲＯＭ、磁気ディスク、光磁気ディスク、リードオンリーメモリー（ＲＯＭ）、プログラム可能なＲＯＭ（ＰＲＯＭ）、消去可能でプログラム可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能でプログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、ランダムアクセスメモリー（ＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、フラッシュメモリー、位相変化メモリー、または、これらの組合せ、を含み得る。有形の媒体は、一つまたはそれ以上の、例えば、半導体材料、位相変化材料、磁性材料、等といった、固形または有形の物理的な材料を含み得る。

別の実施例において、機械で読取り可能な媒体は、無形で一時的な機械で読取り可能な通信媒体を含んでいる。例えば、一時的な機械で読取り可能な通信媒体は、電気的、光学的、音響的、または、キャリア（ｃａｒｒｉｅｒ）波形、赤外線信号、デジタル信号といった伝播信号の他の形式、を含み得る。

好適な機械の例は、これらに限定されるわけではないが、コンピューターシステム、デスクトップ、ラップトップ、ネットブック、ネットトップ、モバイルインターネットデバイス（ＭＩＤ）、ネットワークデバイス、ルーター、スイッチ、携帯電話、メディアプレーヤー、そして、一つまたはそれ以上のプログラムまたは他の命令実行デバイスを有する他の電子デバイスを含んでいる。こうした電子デバイスは、典型的には、一つまたはそれ以上の他のコンポーネントと結合された一つまたはそれ以上のプロセッサを含んでいる。コンポーネントは、一つまたはそれ以上のストレージデバイス（固定の機械で読取り可能なストレージ媒体）、ユーザー入力／出力デバイス（例えば、キーボード、タッチスクリーン、及び／又は、ディスプレイ）、及び／又は、ネットワーク接続といったものである。プロセッサと他のコンポーネントとの結合は、典型的には、一つまたはそれ以上のバスおよびブリッジ（いわゆるバスコントローラーも同様）を通じたものである。このように、与えられた電子デバイスのストレージデバイスは、その電子デバイスの一つまたはそれ以上のプロセッサ上に実行するためのコード及び／又はデータを保管し得る。代替的には、本発明の実施例に係る一つまたはそれ以上の部分は、ソフトウェア、ファームウェア、及び／又はハードウェアの異なる組合せを使用して実施され得る。

この明細書における「一つの実施例（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ、ａｎ ｅｍｂｏｄｉｍｅｎｔ）」または「一つまたはそれ以上の実施例」に対する参照は、例えば、所定の特徴が、本発明の実施において含まれ得ることを意味するものであることも正しく理解されるべきである。同様に、明細書においては、開示を合理化して種々の発明の態様の理解を助ける目的で、ときどき種々の特徴が単一の実施例、図、または記載にまとめられていることも正しく理解されるべきである。しかしながら、この開示の方法は、本発明が、それぞれの請求項において明確に説明されたものより多くの特徴を要するという意図を反映したものと解釈されるべきではない。むしろ、添付の請求項が示すように、発明的な態様は、一つの開示された実施例に係る特徴の全てよりも少ないものに基づいている。従って、明細書に添付の請求項は、明確に明細書に組み入れらており、それぞれの請求項は、本発明のそれぞれの実施例に基づくものである。

Claims (20)

1. インストラクションを実行するための回路を含む実行ロジックと；
   前記実行ロジックに結合されたインストラクション実行スケジューラーロジックと、を含み、
   前記インストラクション実行スケジューラーロジックは、コミット時における状態アップデート実行インストラクションを受け取り、
   前記インストラクション実行スケジューラーロジックは：
   コミット時における状態アップデートロジックを含み、前記コミット時における状態アップデート実行インストラクションが、コミットする次のインストラクションになるまで、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待つ、
   ことを特徴とする装置。
2. 前記インストラクション実行スケジューラーロジックは、アウトオブオーダーインストラクション実行スケジューラーキューを含み、
   前記アウトオブオーダーインストラクション実行スケジューラーキューは、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールする前に、より新しいインストラクションを実行するようにスケジュールするよう動作可能である、
   請求項１に記載の装置。
3. 前記装置は、さらに、
   前記アウトオブオーダーインストラクション実行スケジューラーキューに結合されたリオーダーバッファーを含み、
   前記リオーダーバッファーは、前記アウトオブオーダーインストラクション実行スケジューラーキューに対して、前記コミット時における状態アップデート実行インストラクションが前記コミットする次のインストラクションであることの指標を提供する、
   請求項２に記載の装置。
4. 前記コミット時における状態アップデート実行インストラクションは、コミット時におけるコントロールレジスター書き込みインストラクションを含み、コントロールレジスターに書き込みをする、
   請求項１に記載の装置。
5. 前記コミット時における状態アップデート実行インストラクションは、リネイムされるように構成されてはいない状態をアップデートする、
   請求項１に記載の装置。
6. 前記インストラクション実行スケジューラーロジックは、予約ステーションを含む、
   請求項１に記載の装置。
7. 前記コミット時における状態アップデートロジックは：
   一つまたはそれ以上のコミット時でのビットの複数のセットを含み、前記一つまたはそれ以上のコミット時でのビットの前記セットのそれぞれは、前記インストラクション実行スケジューラーロジックのインストラクション実行スケジューラーキューにおける異なるエントリーに対応しており；
   ビット値調整ロジックを含み、前記コミット時における状態アップデート実行インストラクションに応じて、前記コミット時における状態アップデート実行インストラクションに応じた前記インストラクション実行スケジューラーキューにおけるエントリーにおいて、一つまたはそれ以上のコミット時でのビットのセットの値を与えられた値に調整するように動作可能であり；
   決定ロジックを含み、前記コミット時における状態アップデート実行インストラクションに応じた前記インストラクション実行スケジューラーキューにおけるエントリーにおいて前記一つまたはそれ以上のコミット時でのビットが前記与えられた値を有するときに、前記コミットする次のインストラクションの指標が、前記コミット時における状態アップデート実行インストラクションに応じた前記インストラクション実行スケジューラーキューにおけるエントリーにおける前記コミット時における状態アップデート実行インストラクションの指標と一致するかどうかを決定するように動作可能である、
   請求項１に記載の装置。
8. 前記ビット値調整ロジックは、前記コミット時における状態アップデートインストラクションをデコードするように動作可能なデコーダーを含み、
   前記決定ロジックは、それぞれが異なるエントリーに対応する決定ロジックの複数のセットを含み、前記コミット時における状態アップデート実行インストラクションに応じた前記エントリーのための決定ロジックのセットは、前記コミットする次のインストラクションを表す複数のビットが前記コミット時における状態アップデート実行インストラクションを表す複数のビットと同じであるかを決定するように動作可能である、
   請求項７に記載の装置。
9. 前記インストラクションスケジューラーロジックは、前記コミットする次のインストラクションの前記指標が前記コミット時における状態アップデート実行インストラクションの前記指標と一致しないと前記決定ロジックが決定する場合に、前記コミット時における状態アップデート実行インストラクションの発行をブロックするように動作可能である、
   請求項７に記載の装置。
10. コミット時における状態アップデート実行インストラクションを受け取るステップと；
    前記コミット時における状態アップデート実行インストラクションが、コミットする次のインストラクションになるまで、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待つステップと；
    前記コミット時における状態アップデート実行インストラクションが、前記コミットする次のインストラクションであるときに、実行するようにスケジュールするステップと、を含む
    ことを特徴とする方法。
11. 前記方法は、さらに、
    前記インストラクションを受け取った後で、前記インストラクションを実行するようにスケジュールする前に、より新しいインストラクションを実行するようにスケジュールするステップを含み、
    前記より新しいインストラクションは、前記コミット時における状態アップデート実行インストラクションより新しい、
    請求項１０に記載の方法。
12. 前記方法は、さらに、
    前記状態アップデートインストラクションを実行するときにインストラクション処理装置の内部状態をアップデートするステップを含み、
    前記内部状態は、リネイムされるように構成されてはいないコントロールレジスターを含む、
    請求項１０に記載の方法。
13. 前記インストラクションをスケジュールすることを待つステップは、インストラクション実行スケジューラーキューのインストラクションキューにおいて前記インストラクションを保管するステップを含む、
    請求項１０に記載の方法。
14. 前記方法は、さらに、
    前記インストラクションを受け取るステップに対応して、一つまたはそれ以上のコミット時におけるビットの値を変更するステップと；
    前記一つまたはそれ以上のコミット時におけるビットの値が変更された後で、前記コミット時における状態アップデート実行インストラクションの指標が前記コミットする次のインストラクションの指標と一致するまで、前記インストラクションをスケジュールするのをブロックするステップと、を含む
    請求項１０に記載の方法。
15. 媒体上にコミット時における状態アップデート実行インストラクションを保管した機械で読取り可能なストレージ媒体を有し、
    インストラクションが機械によって処理されると前記機械にオペレーションを実行させ、
    前記オペレーションは、
    前記コミット時における状態アップデート実行インストラクションが、コミットする次のインストラクションになるまで、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることを待つステップと；
    前記コミット時における状態アップデート実行インストラクションが、前記コミットする次のインストラクションであるときに、実行するようにスケジュールするステップと、を含む
    ことを特徴とする製品。
16. 前記コミット時における状態アップデート実行インストラクションは、さらに、前記機械にオペレーションを実行させ、
    前記オペレーションは：
    前記コミット時における状態アップデート実行インストラクションを受け取った後で、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールする前に、より新しいインストラクションを実行するようにスケジュールするステップを含み、
    前記より新しいインストラクションは、前記コミット時における状態アップデート実行インストラクションより新しい、
    請求項１５に記載の製品。
17. 前記コミット時における状態アップデート実行インストラクションは、さらに、前記機械にオペレーションを実行させ、
    前記オペレーションは：
    前記コミット時における状態アップデート実行インストラクションをコミットするときに前記機械の内部状態をアップデートするステップを含み、
    前記内部状態は、レジスターのリネイムを通じてはリネイムされないコントロールレジスターを含む、
    請求項１５に記載の製品。
18. 相互接続と；
    前記相互接続に結合されたプロセッサであり、前記プロセッサはインストラクション実行スケジューラーロジックを有し、
    前記インストラクション実行スケジューラーロジックは：
    前記コミット時における状態アップデート実行インストラクションに対応して、前記コミット時における状態アップデート実行インストラクションが、コミットする次のインストラクションになるまで、前記コミット時における状態アップデート実行インストラクションを実行するようにスケジュールすることをブロックするロジックを有する、
    プロセッサと；
    前記相互接続に結合されたダイナミックランダムアクセスメモリー（ＤＲＡＭ）と、を含む
    ことを特徴とするシステム。
19. 前記インストラクション実行スケジューラーロジックは、前記プロセッサのアウトオブオーダー部分に含まれる、
    請求項１８に記載のシステム。
20. 前記コミット時における状態アップデート実行インストラクションは、
    前記プロセッサにコントロールレジスターへの書き込みをさせるように動作可能なコントロールレジスター書き込みインストラクションを含み、
    前記コントロールレジスターはリネイムされるように構成されていない、
    請求項１８に記載のシステム。

Images