特許 5661934 アトミック領域の条件コミットのための決定メカニズムを提供する装置、方法、およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5661934

(24)【登録日】2014年12月12日

(45)【発行日】2015年1月28日

(54)【発明の名称】アトミック領域の条件コミットのための決定メカニズムを提供する装置、方法、およびシステム

(51)【国際特許分類】

   G06F 9/46 20060101AFI20150108BHJP

   G06F 9/52 20060101ALI20150108BHJP

   G06F 9/45 20060101ALI20150108BHJP

   G06F 9/32 20060101ALI20150108BHJP

   G06F 9/38 20060101ALI20150108BHJP

【ＦＩ】

   G06F9/46 430

   G06F9/46 472Z

   G06F9/44 322G

   G06F9/44 322H

   G06F9/32 330A

   G06F9/38 310F

【請求項の数】24

【全頁数】50

(21)【出願番号】特願2013-529453(P2013-529453)

(86)(22)【出願日】2011年9月26日

(65)【公表番号】特表2013-541094(P2013-541094A)

(43)【公表日】2013年11月7日

(86)【国際出願番号】US2011053285

(87)【国際公開番号】WO2012040715

(87)【国際公開日】20120329

【審査請求日】2013年3月14日

(31)【優先権主張番号】12/890,639

(32)【優先日】2010年9月25日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】591003943

【氏名又は名称】インテル・コーポレーション

(74)【代理人】

【識別番号】110000877

【氏名又は名称】龍華国際特許業務法人

(72)【発明者】

【氏名】ブレターニッツ ジュニア、マウリシオ

(72)【発明者】

【氏名】ウー、ユーフェン

(72)【発明者】

【氏名】ワン、チェン

(72)【発明者】

【氏名】ボリン、エドソン

(72)【発明者】

【氏名】フー、シーリアン

(72)【発明者】

【氏名】ジレス、クレイグ ビー．

【審査官】 清木 泰

(56)【参考文献】

【文献】 特表２０１３−５３７３３４（ＪＰ，Ａ）

【文献】 特表２００９−５２３２７１（ＪＰ，Ａ）

【文献】 特表２００８−５２５９２３（ＪＰ，Ａ）

【文献】 特開２００５−２５９１３６（ＪＰ，Ａ）

【文献】 特開２００３−０５８５１７（ＪＰ，Ａ）

【文献】 特開平０５−１４３４１８（ＪＰ，Ａ）

【文献】 特開平０１−２１３７３８（ＪＰ，Ａ）

【文献】 国際公開第２００９／１１４６４５（ＷＯ，Ａ１）

【文献】 多田知正，樋口昌宏，藤井護，逐次化グラフを用いた複合トランザクションの並行制御，情報処理学会研究報告，日本，社団法人情報処理学会，１９９８年 ６月 ４日，第98巻，第55号，(98-DPS-89)，Pages:7〜12

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６− ９／５４

Ｇ０６Ｆ ９／３０− ９／４２

Ｇ０６Ｆ ９／４５

Ｇ０６Ｆ１２／００

(57)【特許請求の範囲】

【請求項1】

コードを最適化する装置であって、
プログラムコードを保持するメモリと、
プロセッサと
を備え、
前記プロセッサが、
トランザクション実行をサポートし、ハードウェアリソースの利用可能性の表現を提供する前記ハードウェアリソースと、
前記プログラムコードを実行して、前記ハードウェアリソースの利用可能性の表現に基づいて、前記プログラムコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させるための実行論理と
を有する装置。

【請求項2】

前記プログラムコードを実行して、前記ハードウェアリソースの利用可能性の表現に基づいて、前記プログラムコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させる前記実行論理は、
前記プログラムコード内の、前記トランザクション領域の末尾の前の条件コミット命令を実行するための実行論理を有し、
前記条件コミット命令は、前記ハードウェアリソースの利用可能性の表現が、前記トランザクション領域の実行を完了させるには不十分なことを示している場合、前記トランザクション領域の末尾の前に前記トランザクションをコミットさせるものである、請求項１に記載の装置。

【請求項3】

前記メモリに動的最適化コードを保持するよう適合されており、前記実行論理はさらに、前記動的最適化コードを実行して、ランタイム中に前記トランザクション領域の末尾の前に前記条件コミット命令を挿入することを含む前記プログラムコードの部分の最適化により、前記プログラムコードの前記最適化された部分を取得するためのものである、請求項２に記載の装置。

【請求項4】

前記ハードウェアリソースの利用可能性の表現に基づいて、前記プログラムコードの最適化された部分を含むトランザクション領域のサイズを前記プロセッサに動的に変更させるよう、前記プログラムコードを実行するための実行論理は、
前記トランザクション領域に含まれているトランザクション書き込みを実行するための実行論理を有し、前記トランザクション領域は、前記トランザクション書き込みでハードウェアストアバッファがオーバフローすると、最近のチェックポイントにロールバックされて、コミットされる、請求項１に記載の装置。

【請求項5】

前記メモリは、オンプロセッサキャッシュメモリ、前記プロセッサに直接連結されたシステムメモリ、および、前記プロセッサに間接的に連結されたシステムメモリからなる群から選択される、請求項１に記載の装置。

【請求項6】

トランザクションに関する領域チェック命令をデコードするためのデコード論理と、
前記トランザクションの実行をサポートするハードウェアと
を備える装置であって、
前記ハードウェアはさらに、前記デコード論理に基づいて前記領域チェック命令がデコードされると、ハードウェア利用メトリックの表現を利用メトリック格納エレメントに提供し、前記利用メトリック格納エレメントは、前記トランザクションの条件コミットが前記トランザクションの終了の前に実行されるべきかを判断する際に利用される、装置。

【請求項7】

前記ハードウェアは、投機的キャッシュメモリ、ストアバッファ、投機的レジスタファイル、および投機的チェックポイントレジスタファイルからなる群から選択される、請求項６に記載の装置。

【請求項8】

前記領域チェック命令は、利用予想メトリックの表現を含み、
前記トランザクションの条件コミットが前記トランザクションの終了前に実行されるべきかを判断する際に利用される前記利用メトリック格納エレメントは、前記利用予想メトリックの表現を、前記利用メトリック格納エレメントに提供される前記ハードウェア利用メトリックの表現と比較して、利用比較結果を得て、前記利用比較結果に基づいて前記トランザクションの条件コミットを前記トランザクションの終了前に実行すべきかを判断するハードウェアを有する、請求項６に記載の装置。

【請求項9】

前記領域チェック命令はさらに、分岐対象アドレスを含み、前記ハードウェアは、予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断し、
前記予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うと判断されると、実行が前記分岐対象アドレスにジャンプする、請求項８に記載の装置。

【請求項10】

前記ハードウェアは、予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断し、前記トランザクションに関する条件コードに予め定義されたアルゴリズムを利用して前記利用比較結果に基づいて前記トランザクションの終了前に前記トランザクションの条件コミットを行うかの判断を表し、
前記条件コードが実行されると、
前記ハードウェアが前記トランザクションの終了前に前記トランザクションの条件コミットを行うという表現を表したことに応じて、前記装置は、
条件コミット分岐アドレスにジャンプし、
前記トランザクションをコミットし、
新たなトランザクションを開始するものである、請求項８に記載の装置。

【請求項11】

前記利用メトリック格納エレメントは、前記トランザクションに関する条件コードによって読み出されるレジスタを含み、
前記条件コードが実行されると、前記装置は、
ハードウェアのソフトウェア予想利用メトリックとの比較で前記ハードウェア利用メトリックを評価して、前記ソフトウェア予想利用メトリックとの比較における前記ハードウェア利用メトリックの評価に基づいて、前記トランザクションの終了前に前記トランザクションの条件コミットを行うかを判断するものである、請求項６に記載の装置。

【請求項12】

前記条件コードが実行されると、前記装置は、前記ソフトウェア予想利用メトリックとの比較における前記ハードウェア利用メトリックの評価に基づいて、前記トランザクションの終了の前に前記トランザクションの条件コミットを行うと判断されると、さらに、コミット経路にジャンプして、前記トランザクションの終了前に前記トランザクションをコミットして、新たなトランザクションを開始するものである、請求項１１に記載の装置。

【請求項13】

トランザクションの条件コミット点に関しており、宛先アドレスを参照する条件コミット命令をデコードするためのデコード論理と、
前記デコード論理に基づいて前記条件コミット命令がデコードされると、ハードウェアリソースが前記トランザクションのある領域の実行をサポートするために利用可能なスペースを十分含んでいるかを判断し、前記ハードウェアリソースが前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを十分含んでいないと判断すると、前記宛先アドレスにジャンプ実行するハードウェアと
を備える装置。

【請求項14】

前記ハードウェアリソースはメモリデバイスを有し、
前記ハードウェアは、さらに、前記トランザクションの第２の条件コミット点の前に利用が予想されるエントリ数と、前記メモリデバイスにおける利用可能なエントリ数とに基づいて、前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを前記メモリデバイスが十分含んでいるかを判断し、前記ハードウェアは、前記利用可能なエントリ数が前記予想されるエントリ数より少ない場合に、前記メモリデバイスが前記トランザクションの前記領域の実行をサポートするために利用可能なスペースを十分含んでいないと判断する、請求項１３に記載の装置。

【請求項15】

前記条件コミット命令は、さらに、前記トランザクションで前記第２の条件コミット点の前に利用されることが予想される前記エントリ数を参照するためのものである、請求項１４に記載の装置。

【請求項16】

アトミック領域の末尾の前に条件コミット命令を含む最適化されたコードを有する前記アトミック領域を含むプログラムコードを保持するメモリと、
前記メモリに連結されたプロセッサと
を備えるシステムであって、
前記プロセッサは、前記条件コミット命令を認識するためのデコード論理と、前記デコード論理に基づいて前記条件コミット命令が認識されると、前記アトミック領域の末尾の前に前記アトミック領域をコミットする必要があるかを判断するハードウェアとを有する、システム。

【請求項17】

前記デコード論理に基づいて前記条件コミット命令が認識されると、前記アトミック領域の末尾の前に前記アトミック領域をコミットする必要があるかを判断する前記ハードウェアは、
前記アトミック領域を実行するために利用される前記プロセッサの利用可能なハードウェアリソースの量を追跡して、前記アトミック領域の一部を実行する際の前記ハードウェアリソースの利用予想量を判断して、前記利用可能なハードウェアリソースの量が前記ハードウェアリソースの利用予想量より少ない場合には、前記アトミック領域の末尾の前に前記アトミック領域をコミットすべきであると判断する、請求項１６に記載のシステム。

【請求項18】

前記条件コミット命令は、前記アトミック領域の一部を実行するために利用されるハードウェアリソースの予想量への参照を含み、
前記デコード論理に基づいて前記条件コミット命令が認識されると、前記アトミック領域の末尾の前に前記アトミック領域をコミットする必要があるかを判断する前記ハードウェアは、前記アトミック領域を実行するために利用される、前記プロセッサの利用可能なハードウェアリソースの量を追跡して、前記利用可能なハードウェアリソースの量が前記ハードウェアリソースの利用予想量より少ない場合には、前記アトミック領域の末尾の前に前記アトミック領域をコミットすべきであると判断する、請求項１６に記載のシステム。

【請求項19】

前記ハードウェアリソースは、キャッシュメモリ、投機的キャッシュメモリ、ストアバッファ、レジスタファイル、投機的レジスタファイル、および、投機的チェックポイントレジスタファイルからなる群から選択される、請求項１８に記載のシステム。

【請求項20】

前記メモリは、シンクロノス・ダイナミック・ランダム・アクセス・メモリ（ＳＤＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、およびフラッシュメモリからなる群から選択される、請求項１６に記載のシステム。

【請求項21】

ループを含むトランザクションを実行するための実行論理と、
前記ループのイタレーション数をカウントするカウンタと、
イタレーション閾値に前記イタレーション数が達すると、トランザクションの終了前に前記トランザクションのコミットを開始するハードウェアと
を備える装置。

【請求項22】

前記イタレーション閾値は、前記ループの実行分析に基づいて動的に調節される、請求項２１に記載の装置。

【請求項23】

前記イタレーション閾値は、最初は初期値にセットされており、前記初期値に前記カウンタが達して、前記ハードウェアが前記トランザクションの終了前に前記トランザクションのコミットを開始する前に、ハードウェア制約によるロールバックがないことにより増分され、前記初期値に前記カウンタが達して、前記ハードウェアが前記トランザクションの終了前に前記トランザクションのコミットを開始する前に、ハードウェア制約によるロールバックがあったことにより低減され、
前記初期値は、利用可能なストアバッファのエントリ数を前記ループのイタレーションにおける投機的なストア数で除算して得られる値、メモリデバイス内で利用可能なエントリ数を前記ループのイタレーション中に利用されると推定されるエントリ数で除算して得られる値、ソフトウェアから示される開始値、および、前記ループが以前に実行されたときにハードウェア制約によりロールバックする前に実行されたループイタレーション数からなる群から選択される、請求項２１に記載の装置。

【請求項24】

前記ループのイタレーション数をカウントする前記カウンタは、初期値にセットされており、ゼロに向かってカウントダウンするカウンタを有し、
前記イタレーション閾値に前記イタレーション数が達すると、トランザクションの終了前に前記トランザクションのコミットを開始する前記ハードウェアは、前記カウンタがゼロに到達すると、前記トランザクションの終了前に前記トランザクションのコミットを開始するハードウェアを有する、請求項２１に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願はプロセッサ分野に係り、特にプロセッサでのコードの最適化および実行に係る。

【背景技術】

【0002】

半導体処理および論理設計における進歩によって、集積回路素子に設けることができる論理の量が増えた。以前であれば、シングルスレッドプロセッサでは、バイナリコード等のコードの最適化は、他の実行スレッドの干渉を恐れる必要がなかったために、かなり大胆に許されていた。しかし、今日のコンピュータシステム構成は、かつての１つのシステムに１つまたは複数の集積回路があった時代から、複数のコア、複数のハードウェアスレッド、および複数の論理プロセッサが個々の集積回路に存在する、といった進歩を遂げている。１つのプロセッサまたは集積回路は通常、１つの物理プロセッサダイを含んでおり、プロセッサダイが任意の数のコア、ハードウェアスレッド、または論理プロセッサを含むことができる。集積回路上の処理要素（例えばコア、ハードウェアスレッド、および論理プロセッサ）の数は現在増加の一途を辿っており、達成可能な並列処理数も増えている。シングルスレッドプロセッサから、並列でマルチスレッド実行への進化が、コードの最適化に制約を課している。

【表1】

【0003】

例えば擬似コードＡは、[ｒ２]および[ｒ２+４]におけるメモリからのロードを、ＰＲＬＥ（Partial Redundancy Load Elimination）最適化を使って、ループからヘッダブロック（Ｂ３）にホイストされた、バイナリコードの最適化の一例である。[ｒ２＋４]におけるメモリストアは、ＰＤＳＥ（Partial Dead Store Elimination）最適化によって、ループから最終ブロック（Ｂ４）へとサンクされている。シングルスレッド環境においてはこの最適化が機能する。しかし、マルチスレッドアプリケーションでは、他のスレッドが、ループ実行中にメモリの[ｒ２]または[ｒ２＋４]から読み書きされる可能性があり、そうなると、メモリ処理の実行順序が変化することで、実行が無効になってしまう可能性がある。

【0004】

本発明を、例を挙げて説明するが、添付図面には限定されない。

【図面の簡単な説明】

【0005】

【図1】アトミック実行およびアトミック領域の動的サイズ変更をサポートするよう適合されているマルチプロセシングエレメントプロセッサの論理表現の一実施形態を示す。

【図2a】ハードウェアリソースの制約に基づいてトランザクションを動的にサイズ変更することを含む、コードの最適化方法を示すフロー図の一実施形態である。

【図2b】条件コミットコードを挿入する図２ａのフロー図の一実施形態を示す。

【図3a】実行中にトランザクションのサイズを動的に変更する方法のフロー図の一実施形態を示す。

【図3b】実行を続けるために、条件コミット点に十分なハードウェアリソースが存在するかを決定する図３ａのフロー図の一実施形態を示す。

【図4】トランザクションの動的なサイズ変更をサポートするよう適合されているハードウェアの論理表現の一実施形態を示す。

【図5】トランザクションの動的なサイズ変更をサポートするよう適合されているハードウェアの論理表現の別の実施形態を示す。

【図6】トランザクションの動的なサイズ変更をサポートするよう適合されているハードウェアの論理表現の別の実施形態を示す。

【図7a】トランザクション内に投機的なチェックポイントを提供することを含むコードの最適化方法のフロー図の一実施形態を示す。

【図7b】投機的なチェックポイントコードを挿入する図７ａのフロー図の一実施形態を示す。

【図8】トランザクションの実行中にメモリを投機的にチェックポイント実行する方法のフロー図の一実施形態を示す。

【図9】メモリの投機的チェックポイント実行をサポートするよう適合されたハードウェアの論理表現の一実施形態を示す。

【図10】レジスタファイルの投機的なチェックポイント実行をサポートするよう適合されたハードウェアの論理表現の別の実施形態を示す。

【図11】キャッシュメモリの投機的なチェックポイント実行をサポートするよう適合されたハードウェアの論理表現の別の実施形態を示す。

【発明を実施するための形態】

【0006】

以下の詳細な記載においては、特定の種類のプロセッサコア、特定のプロセッサ構成、特定の種類の命令、特定のハードウェア構造、特定のコード最適技術等数多くの特定の詳細を述べて本発明の実施形態の完全な理解を促している。しかし当業者であれば、本発明の実施形態がこれら特定の詳細なしに実行可能であることを理解する。また、特定の、および別のプロセッサアーキテクチャ、記述されたアルゴリズムのための特定の論理回路／コード、特定のコード実装、特定のコンパイラの詳細、その他の特定のマイクロプロセッサの動作の詳細等の公知のコンポーネントまたは方法については詳細な記載を省くことで、本発明の実施形態を曖昧にしないようにしている箇所もある。

【0007】

ここに記載する方法および装置は、ハードウェアの制約に基づいて動的にトランザクションのサイズを変更することで、コードを最適化する。具体的には、コードの最適化は、ハードウェアの制約を利用した、投機的なチェックポイント実行および／またはトランザクションの条件コミットに関して説明されている。しかし、ここで記載される装置および方法はこれらに限定はされず、任意の形態の動的なトランザクションのサイズの変更として実装することができる。例えば、コードの最適化は、静的に行われても動的に行われてもよく、ハードウェア、ソフトウェア、またはこれらの組み合わせで行われてもよい。

【0008】

図１は、複数のコアを含むプロセッサの一実施形態を示す。プロセッサ１００は、マイクロプロセッサ、エンベデッドプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、その他の、コードを実行するデバイスであってよい。一実施形態ではプロセッサ１００が、非対称コアまたは対称コアを含んでよい少なくとも２つのコア（コア１０１および１０２）を含む（実施形態）。しかしプロセッサ１００は、対象であっても非対称であってもかまわないプロセッサエレメントを任意の数含むことができる。

【0009】

一実施形態では、処理エレメントとは、プロセッサの状態（例えば実行状態またはアーキテクチャ状態）を保持することができるスレッドユニット、スレッドスロット、処理ユニット、コンテキスト、論理プロセッサ、ハードウェアスレッド、コア、および／または、任意のその他のエレメントのことを指してよい。つまり、一実施形態では、処理エレメントが、ソフトウェアスレッド、オペレーティングシステム、アプリケーション、その他のコードに独立して関連付けることができる任意のハードウェアであってよい。通常、物理プロセッサとは、任意の数の他の処理エレメント（コアまたはハードウェアスレッド）を含むことのできる集積回路のことであってよい。

【0010】

コアとは、独立したアーキテクチャ状態を、それぞれが少なくともいくつかの専用実行リソースに関連付けられるように、維持することができる集積回路に位置する論理のことである。コアに対して、ハードウェアスレッドとは通常、独立維持されるアーキテクチャ状態同士が実行リソースに対するアクセスを共有するような独立アーキテクチャ状態を維持することのできる集積回路に位置している任意の論理のことを指す。このことから分かるように、共有リソースと、あるアーキテクチャ状態に専用のリソースとが混在する場合、ハードウェアスレッドとコアとは一概に切り離せない。しかしまたしばしば、コアとハードウェアスレッドとが、オペレーティングシステムからは個々の論理プロセッサとしてとらえ、オペレーティングシステムが個々に各論理プロセッサの処理をスケジュールする場合もある。

【0011】

図１に示すような物理プロセッサ１００は、２つのコア（コア１０１および１０２）を含む。ここでコア１０１および１０２は、対称なコアとしてとらえられる（つまり、同じ構成、機能ユニット、および／または、論理を有するコアのこと）。別の実施形態では、コア１０１が、アウトオブオーダプロセッサコアを含み、コア１０２が、インオーダプロセッサコアを含んでいる。しかし、コア１０１および１０２は、任意の種類のコア（例えばネーティブコア、ソフトウェア管理コア、ネーティブ命令セットアーキテクチャ（ＩＳＡ）を実行するよう適合されたコア、変換命令セットアーキテクチャ（ＩＳＡ）を実行するよう適合されたコア、共通設計されたコア、その他の公知のコア）から選択されてよい。コア１０１内に示されている機能ユニットを以下で詳述するが、コア１０２のユニットも同様の動作をする。

【0012】

図示されているように、コア１０１は２つのハードウェアスレッド１０１ａおよび１０２ｂを含む（ハードウェアスレッドスロット１０１ａおよび１０１ｂとも称される）。従って、一実施形態ではソフトウェア実体（例えばオペレーティングシステム）は、プロセッサ１００を潜在的に４つの別個のプロセッサ（つまり、４つのソフトウェアスレッドを同時実行可能な４つの論理プロセッサまたは処理エレメント）としてみることができる。第１のスレッドは、アーキテクチャ状態レジスタ１０１ａと関連付けられており、第２のスレッドは、アーキテクチャ状態レジスタ１０１ｂと関連付けられおり、第３のスレッドはアーキテクチャ状態レジスタ１０２ａと関連付けられていてよく、第４のスレッドは、アーキテクチャ状態レジスタ１０２ｂと関連付けられていてよい。図示しているように、アーキテクチャ状態レジスタ１０１ａは、アーキテクチャ状態レジスタ１０１ｂに複製されており、論理プロセッサ１０１ａおよび論理プロセッサ１０１ｂについて個々のアーキテクチャ状態／コンテキストを格納できる。コア１０１では、他のより小さなリソース(例えば命令ポインタおよびリネーム割り当て論理１３０のリネーム論理など)が、スレッド１０１ａおよび１０１ｂについて複製されていてよい。リオーダ／リタイヤユニット１３５、ＩＬＴＢ１２０、ロード／ストアバッファおよびキューなどのリオーダバッファ等の一部のリソースは、分割により共有されてよい。他方で、汎用内部レジスタ、ページテーブルベースレジスタ、低レベルデータキャッシュおよびデータＴＬＢ１１５、実行ユニット１４０、およびアウトオブオーダユニット１３５の部分等の他のリソースは、完全に共有されていてよい。

【0013】

通常、プロセッサ１００は、完全に共有されていたり、分割により共有されていたり、処理エレメント専用であったりしてよい、他のリソースを含む。図１には、プロセッサの論理ユニット／リソースの一例を有するプロセッサの純粋な例が示されている。プロセッサにはこれら機能ユニットのいずれかが含まれていても、これら機能ユニットのいずれかがなくてもよく、または、図示されていない任意の他の公知の機能ユニット、論理、またはファームウェアが含まれていてもよいことに留意されたい。図示されているように、コア１０１は、アウトオブオーダ（ＯＯＯ）プロセッサコアの簡略化された代表例を含む。ＯＯＯコアは、実行される／とられる分岐を予測するための分岐対象バッファ１２０と、命令のためのアドレス変換エントリを格納するための命令変換バッファ（Ｉ−ＴＬＢ）１２０とを含む。

【0014】

コア１０１はさらに、フェッチされたエレメントをデコードするフェッチユニット１２０に連結された復号モジュール１２５を含む。一実施形態ではフェッチ論理は、それぞれスレッドスロット１０１ａ、１０１ｂに関連付けられた個々のシーケンサを含む。通常、コア１０１は、プロセッサ１００で実行可能な命令を定義／特定する第１の命令セットアーキテクチャ（ＩＳＡ）を含む。ここで、第１のＩＳＡの一部である機械コード命令が、実行する命令または処理を参照／特定する、命令の一部（オペコードと称される）を含んでいる。デコード論理１２５は、自身のオペコードからこれら命令を認識して、デコードした命令を、第１のＩＳＡにより定義されているように処理させるためにパイプラインに送る回路を含む。例えばデコーダ１２５の説明で詳述するように、一実施形態では、条件コミット命令および／または投機的なチェックポイント命令等の、具体的な新たな命令を認識するよう設計または適合されている論理を含む。この結果、またはデコーダ１２５の認識により、アーキテクチャまたはコア１０１は、適切な命令に関連付けられたタスクを実行するために、具体的な予め定義された動作を行う。

【0015】

一例では、割り当ておよびリネームブロック１３０は、リソースを保持するためのアロケータ（例えば、命令処理結果を格納するためのレジスタファイル）を含む。しかし、スレッド１０１ａおよび１０１ｂは、割り当ておよびリネームブロック１３０も、命令結果を追跡できるリオーダバッファのように他のリソースをリザーブするアウトオブオーダ実行を行うことができる。ユニット１３０はさらに、プロセッサ１００の内部の他のレジスタに、プログラム／命令参照レジスタをリネームするレジスタレネーマを含んでもよい。リオーダ／退避ユニット１３５は、上述したリオーダバッファ、ロードバッファ、およびストアバッファ等のコンポーネントを含み、アウトオブオーダ実行をサポートして、後になっては、アウトオブオーダを実行した命令をインオーダでの退避をサポートする。

【0016】

一実施形態におけるスケジューラおよび実行ユニットブロック１４０は、実行ユニットにおける命令／動作をスケジュールするためのスケジューラユニットを含む。例えば浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットのポートにスケジュールされる。実行ユニットに関連付けられているレジスタファイルも、情報命令処理結果を格納するために含まれていてよい。例である実行ユニットには、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニット、およびその他の公知の実行ユニットが含まれてよい。

【0017】

低レベルデータキャッシュおよびデータ変換バッファ（Ｄ−ＴＬＢ）１５０が、実行ユニット１４０に連結されている。データキャッシュは、潜在的にメモリコヒーレンシー状態で保持される、エレメントに対する最近の利用／動作（例えばデータオペランド）を格納する。Ｄ−ＴＬＢは、最近の仮想／線形から物理へのアドレス変換を格納する。具体的な例としては、プロセッサは、複数の仮想ページに物理メモリを分割するためにページテーブル構造を含んでよい。

【0018】

ここでコア１０１および１０２は、最近フェッチされたエレメントをキャッシュする、高レベルまたは更なるアウトキャッシュ１１０に対するアクセスを共有する。ここで高レベルまたは更なるという用語は、実行ユニットから増加するまたは更に離れる方向のキャッシュレベルのことである。一実施形態では、高レベルキャッシュ１１０は、最後のレベルのデータキャッシュのことであり（つまりプロセッサ１００のメモリ階層の最後のキャッシュ）、例えば第２または第３レベルのデータキャッシュのことである。しかし、高レベルのキャッシュ１１０はこれに限定はされず、命令キャッシュに関連付けられていても、命令キャッシュを含んでもよい。逆にトレースキャッシュは、命令キャッシュの一種であり、デコーダ１２５の後に連結され、最近デコードされたトレースを格納してよい。

【0019】

図示されている構成では、プロセッサ１００が、システムメモリ１７５、チップセット、ノースブリッジ、その他の集積回路等のプロセッサ１００外部のデバイスと通信するバスインタフェースモジュール１０５を含んでいる。メモリ１７５は、プロセッサ１００専用であってもよいし、システム内の他のデバイスと共有されてもよい。よく知られたメモリの種類の例には、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、不揮発性メモリ（ＮＶメモリ）、およびその他の公知の格納デバイスが含まれる。

【0020】

一実施形態では、プロセッサ１００が、ハードウェアトランザクション的な実行、ソフトウェアトランザクション的な実行、またはこれらの組み合わせ、混合物を実行することができる。ここでトランザクションとは、コードのクリティカルセクションまたはアトミックセクション／領域のことを意味しており、アトミック群として実行される命令、演算、またはマイクロ演算のグループを含んでよい。例えば、命令または動作は、トランザクションまたはクリティカルなセクションを区別するために利用されてよい。一実施形態では、後で詳述するように、これら命令は、上述したデコーダ等のプロセッサ１００のハードウェアにより認識可能な命令セット（例えば命令セットアーキテクチャ（ＩＳＡ））の一部である。これら命令は、高レベル言語からハードウェアが認識できるアセンブリ言語にコンパイルされると、デコーダがデコード段階で認識できるオペレーションコード（オペコード）、その他の命令の部分を含む。

【0021】

通常、トランザクション実行中、メモリへの更新は、トランザクションがコミットされるまではグローバルに見ることができない。たとえば、ある位置へのトランザクション書き込みは、ローカルスレッドからは見ることができるが、別のスレッドからの読み出しがあった場合、トランザクション書き込みを含むトランザクションがコミットされるまで、書き込みデータは転送されない。トランザクションが係属している間は、メモリからロードされた、またはメモリに書き込まれたデータのアイテム／エレメントがトラックされるが、これについては以下で詳述する。トランザクションがコミット点に到達すると、そのトランザクションについてコンフリクトが検知されない限り、トランザクションにコミットが行われ、トランザクション中に行われた更新がグローバルに見ることができるようになる。しかしトランザクションが係属中に無効になると、トランザクションがアボートされて、更新をグローバルに見ることができるようになる前に、再開させられる。従って本明細書では、トランザクションの係属とは、実行が開始されているが、コミットもアボートも行われていない、という意味で係属されていることを意味する。

【0022】

ソフトウェアトランザクションメモリ（ＳＴＭ）システムとはしばしば、アクセス追跡、コンフリクト解決、または、内部のトランザクションメモリのタスクの実行、または、少なくとも一義的に、ソフトウェアコードの実行によるタスクのことを示すために利用される。一実施形態では、プロセッサ１００は、ハードウェア／論理を利用して（つまりハードウェアトランザクションメモリ（ＨＴＭ）システム内で）、トランザクションを実行することができる。ＨＴＭの実装にあたっては、アーキテクチャおよびマイクロアーキテクチャ両方の観点から、いくつも具体的な実装の詳細があり、その殆どについてはここでは説明を避けて、本発明を不当に曖昧にしないようにする。しかし、一部の構造、リソース、および実装については例として説明する。しかし、これら構造および実装は必須ではなく、異なる実装の詳細を有する他の構造を追加したり、および／または、他の構造で置き換えたりすることもできる点に留意されたい。

【0023】

組み合わせにより、プロセッサ１００は、無制限トランザクションメモリ（ＵＴＭ）システム内のトランザクションを実行することができ、ＳＴＭおよびＨＴＭシステム両方の利点を享受することができる。例えばＨＴＭは、アクセス追跡、コンフリクト検知、検証、およびトランザクションへのコミットにソフトウェアを利用しないので、小さなトランザクション実行には高速で効率的である。しかしＨＴＭは、小さなトランザクションの処理のみが可能である場合が多く、一方でＳＴＭは、無限サイズのトランザクションを処理することができる。従って一実施形態では、ＵＴＭシステムが、小さなトランザクションの実行にはハードウェアを利用して、ハードウェア処理には大きすぎるトランザクションはソフトウェアに行わせる。後述する事項から分かるに、ソフトウェアがトランザクションを実行中であっても、ハードウェアを利用してソフトウェアを助けたり加速させたりすることが可能である。さらに、同じハードウェアを利用して、純粋なＳＴＭシステムのサポートおよび加速を行うこともできる点も言及に値する。

【0024】

上述したように、トランザクションには、プロセッサ１００内のローカル処理エレメント、および、他の処理エレメントの両方からのデータアイテムに対するトランザクションメモリアクセスが含まれている。トランザクションメモリシステムの安全メカニズムがない場合、これらアクセスの一部が無効なデータおよび実行を行う可能性を秘めている（つまり、データへの書き込みによって、読み出しを無効化してしまったり、無効なデータを読み出してしまったりする場合）。この結果、プロセッサ１００は、潜在的に、読み出しモニタおよび書き込みモニタ等の、データアイテムへのメモリアクセスを追跡またはモニタして、潜在的なコンフリクトを特定する論理を含んでいるが、これについては後述する。

【0025】

データアイテムまたはデータエレメントは、ハードウェア、ソフトウェア、またはこれらの組み合わせにより定義される、任意の粒度レベルのデータを含んでよい。このデータ、データエレメント、データアイテム、またはこれらの参照の非排他的な例としては、メモリアドレス、データオブジェクト、クラス、ある種の動的言語コードのフィールド、ある種の動的言語コード、変数、オペランド、データ構造、およびメモリアドレスへの間接参照が含まれる。しかし、任意の公知のデータの分類を、データエレメントまたはデータアイテムと称してもよい。上述した例のいくつか（例えば、動的言語コード型のフィールド、および、動的言語型コード）は、動的言語コードのデータ構造と称される。例としては、動的言語コード（例えばＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．社のＪａｖａ（登録商標））は、強い型の言語である。各変数は、コンパイルの時点で分かる型を有している。型は２つのカテゴリに分類される（プリミティブ型（ブールまたは値、例えばｉｎｔ、ｆｌｏａｔ）および参照型（クラス、インタフェース、および配列））。参照型の値はオブジェクトへの参照である。Ｊａｖａ（登録商標）では、フィールドからなるオブジェクトが、クラスインスタンスまたはアレイであってよい。クラスＡのオブジェクトａがあるとすると、Ａ：：ｘという表記を利用して、タイプＡのフィールドｘを現し、ａ．ｘという表記を利用して、クラスＡのオブジェクトａのフィールドｘを示す。例えば、ａ．ｘ＝ａ．ｙ＋ａ．ｚと表現することができる。ここでフィールドｙとフィールドｚとは、加算のためにロードされ、結果がフィールドｘに書き込まれる。

【0026】

従って、データアイテムへのメモリアクセスのモニタ／バッファリングは、任意のデータレベル粒度で行うことができる。例えば一実施形態では、データへのメモリアクセスを型のレベルでモニタする。ここでフィールドＡ：：ｘへのトランザクション書き込みおよびフィールドＡ：：ｙへの非トランザクションロードは、同じデータアイテム（つまりタイプＡ）へのアクセスとしてモニタされてよい。別の実施形態では、メモリアクセスモニタ／バッファリングは、フィールドレベルの粒度で行われる。ここではＡ：：ｘへのトランザクション書き込みおよびＡ：：ｙへの非トランザクションロードは、別個のフィールドへの参照なので、同じデータアイテムへのアクセスとしてモニタされない。ここで、データアイテムへのメモリアクセスの追跡には、他のデータ構造またはプログラミング技術を考慮に入れることができる点に留意されたい。例えば、クラスＡのオブジェクトのフィールドｘおよびｙ（つまりＡ：：ｘおよびＡ：：ｙ）が、クラスＢのオブジェクトを指しており、新たな割り当てオブジェクトに初期化され、初期化後に書き込まれないとする。一実施形態では、Ａ：：ｘが示すオブジェクトのフィールドＢ：：ｚへのトランザクション書き込みは、Ａ：：ｙが示すオブジェクトのフィールドＢ：：ｚの非トランザクションロードと同じデータアイテムへのメモリアクセスなので、モニタされない。これら例から推定すると、モニタは、任意のデータ粒度レベルでモニタ／バッファリングが可能であると思われる。

【0027】

一実施形態では、プロセッサ１００は、データアイテムに関して、アクセスおよび後続することが予想されるコンフリクトのモニタおよび検知を行うモニタを含む。一例としては、プロセッサ１００のハードウェアが、モニタすると決めたロードおよびストアを追跡するための読み出しモニタおよび書き込みモニタを含む。一例では、ハードウェア読み出しモニタおよび書き込みモニタは、基礎にある格納構造の粒度とは独立して、データアイテムの粒度でデータアイテムをモニタする。一実施形態では、データアイテムを、格納構造の粒度で関連付けられているメカニズムをトラックすることで制限することで、少なくともそのデータアイテム全体を適切にモニタすることができる。

【0028】

具体例として、読み出しモニタおよび書き込みモニタは、キャッシュ位置に関連する属性を含むことで（例えば、投機的なキャッシュを含みうる低レベルデータキャッシュ１５０内の位置）、これらの位置に関するアドレスへのロードおよびストアをモニタすることができる。ここで、データキャッシュ１５０へのキャッシュ位置の読み出し属性は、同じアドレスへの潜在的なコンフリクト書き込みをモニタするためのキャッシュ位置に関するアドレスへの読み出しイベントがあると設定される。この場合には、書き込みイベント同様に書き込み属性が機能して、同じアドレスに対してコンフリクトを生じうる読み書きがモニタされる。この例で説明を続けると、ハードウェアは、そのキャッシュ位置をモニタする旨を示すように設定されている読み出しおよび／または書き込み属性を有するキャッシュ位置への読み書きスヌープに基づいてコンフリクトを検知することができる。逆に、一実施形態では、読み書きモニタの設定、または、キャッシュ位置のバッファリング状態への更新が、スヌープ（読み出し要求または所有者要求の読み出し等）を生じさせ、他のキャッシュでモニタされているアドレスとのコンフリクトが検知される。

【0029】

従って、設計によって、キャッシュコヒーレンシー要求およびモニタされているキャッシュラインのコヒーレンシー状態のさまざまな組み合わせにより、コンフリクトが生じる可能性がある（例えば、共有読み出しモニタ状態としてデータアイテムを保持しているキャッシュラインおよびデータアイテムへの書き込み要求を示すスヌープ等）。逆に、バッファリングされている書き込み状態にあるデータアイテムを保持するキャッシュラインおよびデータアイテムへの読み出し要求を示す外部スヌープは、潜在的にコンフリクトを生じさせるものとして捉えられる。一実施形態では、これらアクセス要求および属性状態スヌープロジックの組み合わせの検知をコンフリクト検知／報告論理（例えばコンフリクト検知／報告モニタおよび／または論理）およびコンフリクトを報告するステータスレジスタに連結させることができる。

【0030】

しかし、条件およびシナリオのどの組み合わせも、トランザクションにとっては無効であるとみなされる場合がある。トランザクションの非コミットとしてみなされうる要素の例としては、トランザクション的にアクセスされたメモリ位置に対するコンフリクトを検知すること、モニタ情報をなくすこと、バッファリングされたデータをなくすこと、トランザクション的にアクセスされたデータアイテムに関するメタデータをなくすこと、他の無効化イベント（割り込み、リング遷移、または明示的なユーザ命令）を検知することを含む。

【0031】

一実施形態では、プロセッサ１００のハードウェアは、バッファリングによりトランザクション的な更新を保持する。上述したように、トランザクション書き込みは、トランザクションにコミットが行われるまではグローバルに見られる状態にされない。しかし、トランザクション書き込みに関するローカルソフトウェアスレッドは、後続するトランザクションアクセスのトランザクション更新にアクセスすることはできる。最初の例として、別個のバッファ構造をプロセッサ１００内に提供して、バッファリングされた更新を保持させ、更新を、ローカルスレッドには提供するが、他の外部スレッドには提供しない。

【0032】

別の例では、キャッシュメモリ（例えばデータキャッシュ１５０）が、更新をバッファリングするために利用され、同時に同じトランザクション機能を提供してもよい。ここでキャッシュ１５０は、バッファリングされたコヒーレンシー状態でデータアイテムを保持することができ、場合によっては新たなバッファリングコヒーレンシー状態をキャッシュコヒーレンシープロトコル（例えばＭＥＳＩ（Modified Exclusive Shared Invalid）プロトコル）に追加して、ＭＥＳＩＢプロトコルを形成する。バッファリングされているデータアイテムのローカルな要求に対しては（データアイテムはバッファリングコヒーレンシー状態に保持されている）、キャッシュ１５０は、データアイテムをローカル処理エレメントに渡して、内部的なトランザクション連続順序付けを守らせる。しかし外部アクセス要求に対しては、ミス応答を提供して、コミットが行われるまでは、トランザクションで更新されたデータアイテムをグローバルには見られない状態にする。さらに、キャッシュライン１５０がバッファリングされたコヒーレンシー状態に維持されており、退去が選択された場合、バッファリング更新を高レベルレベルキャッシュメモリに書き戻さず、つまり、コミットされるまでは、バッファリング更新をメモリシステム内に増殖させない（グローバルに見える状態にしない）。トランザクションをアボートしてよい（つまり、退去させるラインを、犠牲キャッシュのような高レベルキャッシュメモリとデータキャッシュとの間の投機的な構造に格納することができる）。コミットされると、バッファリングラインを修正済み状態にして、データアイテムをグローバルに見える状態にする。

【0033】

内部および外部という用語は、しばしば、キャッシュを共有するトランザクションまたは処理エレメントの実行をスレッドの観点からみた場合のものである。例えば、トランザクションの実行に関するソフトウェアスレッドを実行する第１の処理エレメントが、ローカルスレッドと称される。従って上述した説明では、保持されているアドレスのキャッシュラインをバッファリングされたコヒーレンシー状態にする第１のスレッドが前に書き込んだアドレスからストアまたはロードが受信される場合、これがローカルスレッドなので、キャッシュラインのバッファリングされているバージョンを第１のスレッドに提供する。これに対して、第２のスレッドは同じプロセッサ内の別の処理エレメントで実行されている場合があるが、バッファリング状態に保持されているキャッシュラインの責任を有さないトランザクションの実行には関与しないので（外部スレッド）、第２のスレッドからのアドレスへのロードまたはストアは、キャッシュラインのバッファリングバージョンをミスして、通常のキャッシュの置き換えを利用して、キャッシュラインのバッファリングされていないバージョンを高レベルメモリから取得する。

【0034】

一実施形態では、プロセッサ１００は、コンパイラ／最適化コード１７７を実行してアプリケーションコード１７６をコンパイルすることで、トランザクション実行をサポートし、且つ、アプリケーションコード１７６を最適化する可能性がある。ここでコンパイラは、処理、呼び出し、機能、その他のトランザクションの実行を行うためのコードを挿入することができる。

【0035】

コンパイラは、ソーステキスト／コードを対象テキスト／コードに変換するプログラムまたはプログラムセットを含む場合が多い。通常、コンパイラを有するプログラム／アプリケーションコードのコンパイルは、複数段階またはマルチパスで行われ、上位のプログラミング言語コードを低レベルの機械またはアセンブリ言語コードに変換するためにパスを行う。しかし、ワンパスのコンパイラも、単純なコンパイルには利用可能である。コンパイラは、辞書解析、前処理、パース、セマンティック解析、コード生成、コード変換、およびコード最適化等の任意のコンパイル技術を利用して、任意の公知のコンパイラ処理を実行することができる。ここで記載する、トランザクション的実行と動的コードコンパイルとの融合により、より積極的に最適化を行い、且つ、必要なメモリ順序付けを保護措置として留保しておくことができる。

【0036】

より大きなコンパイラが、複数の段階を含む場合もあるが、これらは概して２つの一般的な段階（（１）概して統語的処理、セマンティック処理、および変換／最適化が行われる前段階、（２）概して解析、変換、最適化、およびコード生成が行われる後段階）に含まれる場合のほうが多い。コンパイラの中には、コンパイラの前段階と後段階との間の区別が曖昧な中間エンドと称されるものもある。この結果、挿入、関連付け、生成、その他のコンパイラの動作は、前述した段階またはパスのいずれかで、且つ、コンパイラの任意の他の公知の段階またはパスで行うことができる。ある例では、コンパイラが潜在的にトランザクション処理、呼び出し、関数等を潜在的に１以上のコンパイル段階に挿入して、例えばコンパイルの前段階に呼び出し／処理を挿入した後、トランザクションメモリ変換段階において、呼び出し／処理の変換を、低レベルのコードに変換してよい。動的コンパイル中には、コンパイラコードまたは動的最適化コードがこれら処理／呼び出しを挿入して、且つ、ランタイム中に実行のためにコードを最適化することができる。具体例としては、バイナリコード（既にコンパイルされているコード）をランタイム中に動的に最適化してよい。ここでプログラムコードには、動的最適化コード、バイナリコード、またはこれらの組み合わせが含まれてよい。

【0037】

しかし、コンパイラの実行環境および動的または静的な性質にも関わらず、一実施形態におけるコンパイラは、トランザクション実行を実現するべく、および／または、プログラムコードのセクションを最適化するためにプログラムコードをコンパイルする。従って一実施形態では、プログラムコードの実行というと、（１）コンパイラプログラムの実行または最適化コード最適化装置を動的または静的に実行して、主要なプログラムコードをコンパイルしたり、トランザクション構造を維持したり、他のトランザクション関連の処理を実行したり、コードを最適化したりする、（２）トランザクション処理／呼び出し（最適化された／コンパイルされたアプリケーションコード等）を含む主要なプログラムコードを実行する、（３）主要なプログラムコードに関連する、ライブラリ等の他のプログラムコードを実行する、または、（４）これらの組み合わせの実行であってよい。

【0038】

ソフトウェアトランザクションメモリ（ＳＴＭ）システム内では、コンパイラが、コンパイルするアプリケーションコードに沿って、いくつかの処理、呼び出し、他のコードを挿入して、同時に、他の処理、呼び出し、関数、およびコードをライブラリ内に別個に提供する、ということがよく行われる。これにより潜在的に、ライブラリ配信者が、アプリケーションコードをコンパイルしなおさずにライブラリを最適化したり更新したりすることができるようになる。具体例では、コミット関数の呼び出しを、アプリケーションコード内のトランザクションのコミット点に挿入して、同時にコミット関数を更新可能なライブラリ内に提供することができる。加えて、具体的に処理および呼び出しをどこに配置するかの選択によって、アプリケーションコードの効率に影響が出る場合がある。

【0039】

背景技術で述べたように、マルチスレッドシステムにおける積極的なコードの最適化は、メモリの順序体系を脅かす場合がある。しかし一実施形態では、コードの最適化を、トランザクションメモリの保護機能と組み合わせることで、メモリの順序の保護機能を留保しつつ、積極的な最適化を可能としている。一例として、最適化されたコードが実行されてもトランザクション的な保護機能によってメモリの順序が脅かされないようにすることができるような、最適化されたコードを含むアトミック領域をプログラムコードに挿入する。この結果、最適化されたコードの積極的に最適化を許可しつつも、アトミック領域が、メモリ順序が脅かされたときにはそれを検知して、領域をコミットさせないようにすることができる。

【0040】

また、コードの最適化とアトミック領域との組み合わせは、別の修正を行う場合にも利点を生じる。従って、一実施形態では、プロセッサ１００が、プロセッサ１００内のハードウェアリソースの利用可能性に基づいてプログラムコード１７６内のトランザクションのサイズを動的に変更することができる。従来は、アトミック領域は、完全にコミットされるか、アボートされるか、であった。しかし本例では、トランザクションの最終点到達前にトランザクションにコミットすることができる。つまり、たとえばトランザクションを完全に実行するには（またはトランザクションのコードの一部を実行するには）リソースが少なすぎる、または足りない場合、より小さなトランザクションへの動的サイズ変更が可能になる。一例として、キャッシュメモリ１５０を利用して、仮のトランザクション情報に、トランザクション追跡情報を関連付けて保持する場合を想定する。このシナリオでは、キャッシュ１５０の利用可能なキャッシュエントリが少なくなったとき、または溢れてしまったとき（退出すべくトランザクション的にアクセスされたラインを選択して、犠牲キャッシュが満杯の場合）、実行中のトランザクションをその時点でコミットするが、これにより仮の情報をグローバルに公開する。次に新たなトランザクションは、コミット点から元のトランザクションの最終点まで再開することができる。この結果、この例ではキャッシュメモリ１５０であるトランザクションハードウェアリソースが解放される。そしてトランザクションは、２つの小さなハードウェアトランザクションとして完了させることができ、トランザクション全体をロールバックしたり、トランザクションをＵＴＭシステム等におけるソフトウェアに拡張したりする必要がない。

【0041】

従って一実施形態では、プロセッサ１００が、ＨＴＭ、ＳＴＭ、またはＵＴＭであっても、トランザクションメモリシステムをサポートするハードウェアを含んでいる（例えば、デコーダ、キャッシュメモリ、投機的格納構造、追跡メカニズム、ストアバッファ、レジスタファイル、チェックポイント格納メカニズム、および、トランザクションの実行をサポートするために公知なその他の任意のハードウェアの任意の組み合わせが含まれる）。さらにプロセッサ１００は、ハードウェアがトランザクション的な実行をサポートするための利用可能性、有用性、または、その表現を追跡、提供、または示すよう適合されたハードウェア／論理を含む。最初の例としては、利用メトリック（ハードウェア利用表現）が、キャッシュメモリ、犠牲キャッシュ、ストアバッファ、またはロードバッファ等の格納構造における、利用可能なエントリ数、または、逆占拠率を含んでいる。別の例では、利用メトリックが、メモリのオーバフロー、割り込みイベント、またはエントリの退出等のイベントの発生を含んでいてもよい。しかし、利用メトリックは任意のものであってよい（実際のものであっても抽象的なものであってもよい）。

【0042】

より抽象的な利用メトリックの一例として、カウンタがコード内のループイタレーション数をカウントして、カウンタが閾値に到達すると、トランザクションにコミットする場合を考える。ここでは閾値を、一定の期間のコードのプロファイリングに基づいて動的に調節することができる（例えば、トランザクションがハードウェアリソースの不足を理由にアボートされた場合には、閾値を低下させる）。この場合には、ハードウェアまたは特定のイベントが正確且つ実際には利用されない。しかし、カウンタ閾値を動的に調節することにより、ハードウェアが実質的には、ハードウェアが枯渇するまでの（つまり、リソース利用率が高くなることによりアボートまたはロールバックが行われるまでの）ループ数を推定する。この結果一実施形態では、このようなハードウェア推定は、コード実行のリソース利用性を推定することから、ハードウェアリソースの利用のまたは利用の表現と称される。

【0043】

一実施形態では、プロセッサ１００のハードウェアは、トランザクションを動的にサイズ変更すべきときを非同期的に決定することができる。例えばハードウェアリソースの利用率が高いときには、プロセッサ１００はトランザクションにコミットして、プロセッサ１００上で実行中のプログラムコード１７６の観点からトランスペアレントに別のトランザクションを再開してよい。ここでトランザクションを含むプログラムコード１７６が実行論理１４０で実行中である。プログラムコードの観点からは、トランザクションが途切れなく実行されている。しかしハードウェアの観点からは、ストアバッファ等のリソースの利用率が高い（オーバフローしている）ことから、ハードウェアはトランザクションの終了点の前にトランザクションにコミットして、コミット点において第２のトランザクションを再開してから、トランザクションの元の終了点で第２のトランザクションにコミットした。

【0044】

別の実施形態では、トランザクションの動的サイズ変更を、ハードウェアとファームウェア／ソフトウェアの組み合わせで実行する。ここでプロセッサ１００は、トランザクション実行のサポートおよびリソースの利用率／利用可能性の追跡の両方のためにハードウェアリソースを含んでいる。プログラムコード１７６からの条件コードが実行されると、このハードウェアリソースの利用率／利用可能性に基づいて、実行論理１４０に動的サイズ変更を行わせる（終了点の前にトランザクションにコミットさせる）。本質的に、リソース利用率および潜在的な条件コミットのチェックは、ソフトウェア命令で行う結果、同期して行われる（つまり、ハードウェアの非同期に行われる特定の命令の実行から独立して行われるのではない）。

【0045】

例えば、動的コンパイラコードの一部でありうる動的最適化コード１７７は、プロセッサ１００のランタイム中に、実行論理１４０／１４１によってプログラムコード１７６を動的コンパイル／最適化を行う。このコンパイル／最適化中に、アトミック領域がプログラムコード１７６のセクションに、アトミック領域の条件コミットコードとともに挿入される。次に実行論理１４０／１４１は、コード１７６を動的に最適化して、ランタイム中に動的に最適化されたコード１７６を実行する。具体的には、実行論理１４０／１４１は、アトミック領域およびその中の最適化されているコードを実行する。デコード段階１２５が条件コミットコードに遭遇／デコードすると、ハードウェアリソース利用率を決定する。利用率／利用可能性は、前に追跡済みであってよいが、利用率の報告／評価は、条件コミットコードに遭遇／デコードしたときに行われる。次いで、ハードウェアリソース利用可能性／利用率に基づいてアトミック領域にコミットするかについて決定することができる。

【0046】

一実施形態では、リソース利用率に基づくコミットの決定は、条件コードに応じてハードウェアが行うこともできる。言い換えると、ハードウェアが独立してハードウェア利用率を評価して、利用率が高い場合には早期コミットを行う必要があると決定するのである。一例では、条件コミットコードが、デコーダ１２５が認識可能な条件コミット命令を含んでいる。条件コミット命令または領域チェック命令が、分岐対処アドレスを含んでいる。ハードウェアは、デコード論理１２５が条件コミット命令をデコードすると、ハードウェアリソースの利用率が高いすぎないかを判断する、または、不十分なリソースしかないかを判断する。利用率が高すぎる場合、または、不十分なリソースしかない場合には、実行論理１４０が分岐対象アドレスにジャンプ実行する。

【0047】

一実施形態では、ハードウェアが、利用率が高すぎるか、不十分なリソースしかないかを、所定のアルゴリズムに基づいて決定する。例えばハードウェアリソースがストアバッファを含むときには、利用率が高すぎることは、所定数のストアバッファエントリが利用されている、またはオーバフロー（ストアバッファエントリが利用不可能である）が生じている、ということで判断できる。ハードウェアはさらに、前の実行（コードプロファイリング）に基づいてコードの予想利用量を推定して、現在のハードウェア利用率とともにこの推定値を利用することで、条件コミットなしに実行を続けることができるに足るリソースが存在しているかを判断する。

【0048】

または、条件コミット命令が予想利用量を含んでもよい。ハードウェアは、不十分なリソースしかない場合にはハードウェア利用率とこの予想利用量とを比べる。例えば、条件コード１７６がプログラムコード１７６のアトミック領域内のループに挿入されたと想定する。この結果、ループが繰り返されるごとに条件コードが実行される。ここで条件コミット命令は、コードによる推定またはコードの動的プロファイリングにより得られる固有のストアバッファエントリ数に基づいていてよい、ループのイタレーション中に利用されるべきストアバッファエントリの予定数を参照する。デコード論理１２５が条件コミット命令をデコードすると、予測されるエントリ数を、プロセッサ１００のハードウェアが決定するストアバッファで利用可能なエントリ数と比べる。予測されるエントリ数が利用可能なエントリ数より多い場合には、実行は、条件コミット命令が参照する分岐対象アドレスにジャンプする。分岐対象アドレスは、プログラムコード１７６内のアドレス参照コード、または、アトミック領域の早期コミットを実行して第２のアトミック領域を再開するための他のコード（例えばライブラリコード）を含んでよい。

【0049】

別の実施形態では、ソフトウェアが、ハードウェア利用率が高いとき、またはハードウェア利用可能性が非常に低いときを判断する。この例では、プロセッサ１００が、ハードウェア利用率表現（ハードウェア利用メトリック）を保持する、レジスタ等の格納エレメントを含んでいる。ここで、条件コードは、利用メトリックをロードして／読み出して、評価して、早期コミットを実行するかを判断する処理を含む。早期コミットを実行する場合には、条件コードはジャンプ動作を含み、これは実行論理１４０により実行されると、分岐対象アドレスに実行をジャンプさせ、これにより現在のトランザクションがコミットされ、別のアトミック領域を始めることができる。

【0050】

ハードウェアとソフトウェアとは同様の評価を行ってよい。しかしハードウェアによる解決法は、ハードウェアを完全に早期コミットを処理させたり、条件コミット命令のみを受信したりするなど、コードの簡潔化が可能である。しかしソフトウェアに評価を行わせることで、早期コミットを行うときの決定がより柔軟に行われるようになる。この結果、ハードウェアとソフトウェアの組み合わせを任意の割合で利用して、ハードウェア利用率／利用可能性が高すぎたり低すぎたりしないかを、実装と所望の利点とに基づいて決定することができる。

【0051】

図１は、様々なモジュール、ユニット、および／または論理の表現を有するプロセッサ例の抽象的な論理的視点を示す。しかし、ここで記載する方法および装置を利用するプロセッサは、例示されているユニットを必ず含まねばならないわけではない。プロセッサは示されているユニットの一部または全てを備えなくてもよい。加えて図１は２つのコアのみを示しているが、プロセッサには任意の数が含まれていてよい（例えば同じタイプの複数のコア、またはそれぞれが異なるタイプの３つ以上のコア等）。

【0052】

図１は、インタフェースで外部メモリコントローラ（コントローラハブ１７０）にポイントツーポイント連結されているプロセッサの一実施形態を示す。しかし、現在では多くのプロセッサが、複数のコアを相互接続するためにリング構成および共有キャッシュその他のインタフェースを有するオンプロセッサのメモリインタフェースモジュール（オンチップモジュール）を含みはじめている。図示されてはいないが、一実施形態ではプロセッサ１００が、コア、キャッシュ、およびメモリコントローラコンポーネントを連結するリング相互接続を含んでいる。

【0053】

ここではキャッシュエージェントを利用して、物理的に分散配置されているキャッシュの一部を管理している。一例として、各キャッシュコンポーネントがキャッシュの一部を配列コア（キャッシュの分散配置されている部分を管理する目的でキャッシュエージェントと関連付けられているコアのこと）のために管理する。キャッシュエージェントがリング相互接続における通信に対処してキャッシュの部分とインタフェースするのと大体同じように、コアエージェント／コンポーネントが、コアとの通信およびインタフェースに対処する。加えて、リング相互接続は、メモリコントローラインタフェース論理（ＭＣＩＬ）および／またはその他のコントローラを、他のモジュール（例えばメモリおよび／またはグラフィックプロセッサ）とインタフェースするように連結する。

【0054】

図２ａは、アトミック領域を利用するコードの最適化方法のフロー図を示している。図２ａのフローのブロックは、実質的に直列方式で描かれているが、例示される方法のフローは任意の順序で実行されてよく、且つ、その一部または全体が並列処理されてもよい。例えば条件コミットコードがアトミック領域の開始および終了命令の挿入前に挿入されてもよい。さらに、図示されているブロックは実行されなくてもよい。また図示されていない他のブロックが、図示されているブロックとともに、またはその代わりに実行されてもよい。

【0055】

ブロック２０５で、プログラムコードのうち最適化すべきセクションを特定する。上述したようにプログラムコードとはコンパイラコード、最適化コード、アプリケーションコード、ライブラリコード、その他の任意の公知のコードの成り立ちであってよい。具体例として、プログラムコードは、実行準備の整った、プロセッサ１００での実行用に動的にコンパイルされた、および／またはプロセッサ１００での実行用に動的に最適化されたバイナリコード等の、プロセッサ１００で実行されるコードを含む。加えて、コード（演算、関数呼び出し等）の挿入、およびコードの最適化は、プログラムコード（例えばコンパイラおよび／または最適化コード）の実行により行われる。一例として、最適化コードは、プロセッサ１００でランタイムにおいて動的に実行されて、プロセッサ１００でプログラムコードが実行される直前にプログラムコードが最適化される。

【表2】

【0056】

一実施形態では、最適化すべき擬似コードＢの領域等のプログラムコードの１つのセクションを特定することには、コードが、最適化すべきプログラムコードの１つのセクション／領域を示すことを含む。例えば、特定の命令またはデマケーションを利用して、最適化すべき、または、最適化により利点があることが想定されるコードの１つのセクションを示すことが含まれる。別の選択肢としては、プログラマが、プログラムコードのセクションに関するヒントを提供して、これを最適化コードが最適化するセクションを特定する際に利用する、ということも可能である。別の実施形態では、領域をプロファイリング情報に基づいて特定／選択する。例えば、プログラムコードを、ハードウェア、プロセッサで実行されるソフトウェア、ファームウェア、またはこれらの組み合わせで実行している間にプロファイリングを取る。ここでコードのプロファイリングは、ヒントを生成したり、元のソフトウェアを修正したり、最適化のための領域を直接特定したりする。加えて、コードのあるセクションは、具体的なタイプ、フォーマット、またはコードの順序といった特定の属性により潜在的に特定可能である。具体例では、ループを含むコードが、潜在的な最適化対象とされる。そして実行中のループのプロファイリングによって、最適化すべきループが決定される。さらに、ループが最適化すべきロードおよびストアといった特定のコードを含む場合には、これらのコードを含む領域を最適化するべきであるとして特定する。擬似コードＢから分かるように、領域には、ループの実行を最適にするために、ループに対するホイスト、サンクができるロードおよびストアも含まれている。

【表3】

【0057】

一実施形態では、最適化すべきであるとして特定されるコードのセクションをアトミック領域に変換する。または、コードのセクションの少なくとも一部をアトミック領域に変換する。ここで、開始部分および最終部分(コミット)、トランザクション（アトミック領域）命令によってコードの部分が区分される（ブロック２１０から２１５を参照）。擬似コードＣから分かるように、領域の開始および領域のコミット命令が、コードの領域の前後にそれぞれ挿入される。一実施形態では、コードには、複数の入力と複数の退出とが含まれている。この結果、開始アトミック領域命令および終了アトミック領域命令が、各入力点および各退出点にそれぞれ挿入されてよい。しかし、領域をアトミックであると示すためには任意の公知の方法を利用することができる。

【表4】

【0058】

ブロック２２０で、条件コミット点を決定する。ここで、最適化するコードの領域には、複数の条件コミット点を決定／割り当て可能であるが、説明の便宜上、１つのコミット点のみを以下で詳述する。条件コミット点の決定は、条件コミット点の間でハードウェアリソースが枯渇してしまうことを避けるための任意の公知の割り当て／決定アルゴリズムに基づいて行うことができる。最初の例では、イタレーションごとに条件コミット点に遭遇するよう、ループに条件コミット点を挿入する。ここで、条件コミット点は、ループの最初に決定される。別の例として、コードの動的プロファイリングが、しばしばハードウェアリソースを枯渇させてしまう実行経路を示している。従って、条件コミット点をこのような実行経路に割り当てて、これら経路の実行中にリソースが枯渇しないようにすることができる。同様に、リソースを過度に独占しがちであるとして知られている実行経路にも、条件コミット点を割り当てておくことができる。

【0059】

ブロック２２５で、条件コミットコードを少なくとも条件コミット点に挿入する。条件コミットコードによって、次のコミット点までの実行をサポートするにはハードウェアリソースが足りないと判断された場合に、トランザクションのサイズ変更（早期コミット）が行われる。図２ｂを簡単に説明すると、条件コミットコードを挿入するフロー図の一実施形態が示されている。フロー２２６で、条件コミット命令を条件コミット点に挿入する。擬似コードＤから分かるように、一実施形態では条件コミット命令が、アトミック領域のコミット点Ｌ１に挿入された領域チェック命令を含んでいる。

【0060】

最初の例として、条件コミット命令(例えば領域チェック命令または条件分岐命令)には、分岐対象アドレスへの参照が含まれている。次のコミット点までの実行をサポートするにはリソースが足りないと判断した結果、条件コミット命令に呼応して、実行は分岐対処アドレスにジャンプする。ここで条件コミットコードは、さらに、分岐対象アドレスにコミットコードを含んでよい。この例では本質的に、条件コミット命令は、十分なリソースが存在しているかを判断するためのテスト／クエリを開始するものである。そして分岐対象アドレスのコードは、十分なリソースがないとき早期にトランザクションにコミットするものである。従ってブロック２２７で、分岐対象アドレスにコミット命令を挿入する。

【0061】

擬似コードＤで、第１のｒｅｇｉｏｎ＿ｃｏｍｍｉｔ命令が、Ｂ４のアトミック領域の退出／終了点に挿入され、第２のｒｅｇｉｏｎ＿ｃｏｍｍｉｔ命令が、ブロックＢ６の分岐対象アドレス点Ｌ２に挿入される。ここで、Ｌ１のｒｅｇｉｏｎ＿ｃｈｅｃｋ命令によりリソースが不十分であると判断されると、実行はｒｅｇｉｏｎ＿ｃｈｅｃｋ命令が参照する分岐対象アドレス（Ｂ６）にジャンプする。トランザクションライブラリ内のコミット関数の呼び出しまたはアーキテクチャ的に認識されたコミット命令等のｒｅｇｉｏｎ＿ｃｏｍｍｉｔ命令は、アトミック領域を早期にコミットする（終了点Ｂ４の前に）。そしてさらに、ブロック２２８で（擬似コードＤのＢ７で）、第２の開始アトミック領域命令（ｒｅｇｉｏｎ＿ｓｔａｒｔ）が、ｒｅｇｉｏｎ＿ｃｏｍｍｉｔ命令の後に挿入される。この結果、アトミック領域の実行はＢ３（ｒｅｇｉｏｎ＿ｓｔａｒｔ）から始まる。そしてＬ１でｒｅｇｉｏｎ＿ｃｈｅｃｋによって十分なリソースがないと判断されるまで、または終了点Ｂ４に到達するまで続けられる。しかし、Ｌ１で十分なハードウェアリソースがないと判断されると、元のトランザクションのサイズ変更を行う（つまり、コミット点Ｌ２、Ｂ６でコミットする）。そして、第２のアトミック領域がＢ７で始まり、領域実行は、コミット点Ｂ４になるまで、またはリソースが再度Ｌ１で制約されるまで、続けられる。従って１つのアトミック領域を、より小さなトランザクションにサイズ変更することで、ハードウェアリソースが枯渇しないようにしており、以前にはソフトウェアトランザクション実行がアボートされたりソフトウェアに拡張されていたりしたのとは対照的である。

【0062】

ここで、条件コミット命令には任意の情報が含まれてよい。例えば前述したように、一実施形態の条件コミット命令には、次のコミット点までに予想されるハードウェアリソース利用率（擬似コードＤのコードＢ２までのループ中に利用が見込まれるエントリ数）が含まれてよい。ここで予想される利用率は、ループＢ２の別のイタレーションの実行をサポートするために十分なリソースがあるかを判断するために利用される。具体例を挙げると、予想される利用率には、次のコミット点までのコード領域の実行のみにより一意に触れることが予想される格納構造のエントリ数が含まれる。

【0063】

加えて、条件コードは、条件コミット命令に限定はされない。例えばハードウェアが利用率を決定してレジスタに格納する実施形態では（例えば図５を参照して後で詳述する）、条件コードが、レジスタからの利用率を読み出し／ロードし、利用率を評価してから、擬似コードＤのＢ６およびＢ７に類似したコミットおよび再開コードに分岐するジャンプまたは分岐動作を発行する。他の実施形態では、ソフトウェアは、ハードウェアと通信したりクエリを行ったりする代わりに、ハードウェア利用率の推定を行ってもよい。この場合には、条件コードが、推定を行うコードを含んでいる。例えば、図６を参照して後で詳述するカウントを、ソフトウェア実行中ずっと維持しておいて、条件コミットを行う前のループのイタレーション数に制限を課してもよい。この例では、カウントを維持するために実行されるコードを、条件コミットコードと考えることができる。

【0064】

ブロック２３０で、プログラムコードのセクションを最適化する。擬似コードＥは、最適化の後のコードの例を示す。

【表5】

【0065】

アトミック領域のデマケーションおよび条件コミットコードの挿入は、一部の実施形態ではプログラムコードの最適化と捉えられるが、他の実施形態では、プログラムコードのセクションをさらに最適化することで実行の利点を享受することができ、同時にトランザクション実行のメモリ順序の保護機能も利用することができる。具体例を挙げると、ＰＲＬＥおよびＰＤＳＥを利用するループ以外でロードおよびストアをホイスト、サンクすることもできる。擬似コードＥでは、ＰＲＬＥが[Ｒ２][Ｒ２＋４]ロードをホイストして、ＰＤＳＥが[Ｒ２＋４]ストアをサンクした後のアトミック領域を示している。一実施形態では、別のメモリ順序規則も適用可能である点に留意されたい。ここでは、メモリ順序に違反するメモリ最適化は開始およびコミット領域を超えないよう徹底すると好適である。この一例が擬似コードＥに示されており、ここでは[ｒ２＋４]ストアがＢ６のｒｅｇｉｏｎ＿ｃｏｍｍｉｔの前に挿入されており、[Ｒ２][Ｒ２＋４]ロードが、Ｂ７のｒｅｇｉｏｎ＿ｓｔａｒｔ命令の後に再度挿入されている。この結果、領域が早期コミットされると（条件コミット点にサイズ変更されると）、Ｂ６で領域がコミットされる前に[Ｒ２＋４]ストアが実行される。そして[Ｒ２][Ｒ２＋４]ロードが、Ｂ７での新たなトランザクションの再開の後に実行される。

【0066】

上述したようにロードおよびストアが最適化されると、任意の公知のコード最適化技術を利用することができるようになる。コード最適化の例をもう少し紹介すると（全部を網羅することは意図しておらず、純粋に例示を目的としている）、ループ最適化、ソフトウェアパイプライン、データフロー最適化、コード生成最適化、制限チェック除去、分岐オフセット最適化、デッドコード除去、およびジャンプスレッドなどがある。

【0067】

図３ａは、アトミックコードの動的サイズ変更を示すフロー図の一実施形態である。ブロック３０５で、最適化されたプログラムコードを含むトランザクション（アトミック領域）を実行する。一実施形態では、最適化されたプログラムコードは、ランタイム中に動的に最適化される（つまり、実行に間に合わせるために、オンザフライ方式でプログラムコードを最適化するために、ランタイムに動的最適化コードを実行する）。しばしばこの種の動的最適化またはコンパイルは、プログラム全体（例えば静的なコンパイル中）を認識しないことがあるが、セクションにおけるコードのいくつかの部分をコンパイル／最適化することはできる。

【0068】

ブロック３１０で、領域チェック命令に遭遇する。一実施形態では、領域チェック命令に遭遇することには、デコード論理が命令をデコードすることが含まれている。しかし、この遭遇は、命令（または命令の一処理）を受信するまたは処理するパイプラインの任意の段階のことであってよい。例えば、この代わりに、領域チェック命令に遭遇することが、命令に関する処理についてバッファにエントリを割り当てること、処理のディスパッチ、命令の処理またはマイクロ処理を行うための実行ユニットによる命令の実際の実行、またはパイプラインの任意の他の公知の段階であってもよい。上述したように、一実施形態では、領域チェック命令は、プロセッサのデコーダが、ハードウェアのクエリをする際に認識可能なＩＳＡの一部である。クエリは単に、利用についてハードウェアにクエリする際のロードであってよい。そしてソフトウェアは、ハードウェアからの関与をうけずに、十分なリソースが利用可能であるかを判断する。これに対して、クエリは、アトミック領域の実行を継続するのに十分なリソースがあるかの調査をハードウェアに要求することを含んでよい。ここでクエリは、リソースが不十分である場合にハードウェアが分岐する対象アドレスを提供する。しかしクエリの関与が強く、領域チェック命令も、十分なリソースが利用可能であるかを決定する際にハードウェアが利用することが想定される利用率を提供している場合もある。

【0069】

領域チェック命令に呼応して、ブロック３１５で、領域チェック点で、ハードウェアユニットが、例えば次の条件コミット点まで、トランザクションの領域を完了するために十分なリソースを有しているかを判断する。十分なハードウェアリソースがあるかの判断は、実際に計測されてもよいし、どのような方法で概算されてもよい。最初の例では、ハードウェア自身が利用レベルを追跡したり、および／または、決定したりする。ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせは、利用レベル／メトリックが、トランザクションの領域の完了までに十分利用可能かを判断する。しかし、利用レベルは、ソフトウェアの命令で純粋に近似／計測されてもよい。この場合には、計測は、上述した、ハードウェアが自分で追跡する例より精度が落ちるかもしれないが、計測を行うためにハードウェアフックを追加する必要がない。

【0070】

図３ｂは、トランザクションの領域の実行を完了するために十分なリソースがあるかを決定するためのフロー図の一実施形態である。フロー３５０で、ハードウェアユニット、または複数のハードウェアユニットの予想される利用率を決定する。ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせを利用して、利用率を予想する。

【0071】

あるシナリオでは、トランザクションを含むプログラムコードの実行のプロファイリングをとる。プロファイリング中に、リソースの欠如からアボートされた数、アボートされずにコミットされた数、および／または、ハードウェアの利用率を追跡する。そして、コード（例えばコンパイラ）が、過去の実行プロファイリングに基づいて、予想される利用率のヒントまたは示唆を提供する。別のシナリオでは、予想される利用率に推定が含まれてもよい。例えばハードウェアユニットがストアバッファである場合、予想される利用率は、コード領域の固有のストア数を含む（新たなストアバッファエントリに割り当てられる可能性のあるストア処理）。本質的に、コードのストア数は、コード領域の実行中に利用されるストアバッファエントリ数の推定である。しかし、予想される利用率の判断は、ソフトウェアプロファイリングまたは推定に限定はされない。ハードウェアが、同様にプロファイリングまたは推定を行ったり、コードと協同して、予想利用率を決定したりしてもよい。

【0072】

同様にフロー３５５で、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせのいずれであってもよいので、ハードウェアユニットの利用可能性を決定する。上述した例を説明するために、条件コミット命令が、ハードウェアに、３２個のエントリストアバッファの予想される利用率が、推定または過去のプロファイリングに基づいて１０個のストアバッファエントリを含むと想定する。すると、ストアバッファは、先頭および最終ポインタを利用しており、２０個のエントリが現在割り当てられていると判断する（１２個の利用可能なエントリがある）。この決定によって、フロー３６０で比較を行ってよい。利用可能なエントリ数が、予想される利用率より高いので、フロー３６０で、実行を続けるのに十分なリソースがあると判断される。もしも９個のエントリしか利用可能でない場合には、フロー３７０で、十分なリソースがないと判断される。

【0073】

しかし、比較は、ハードウェアリソースにきっちり十分な空間があることを確かめることに限られない。この代わりに、閾値を利用してバッファゾーンを提供してもよい。例えば利用率が高い場合（閾値を超える場合）、または利用可能性が低い場合（閾値を下回る場合）、同様の決定をフロー３６５、３７０で行ってよい。具体例として、６個のエントリを含むバッファゾーンが利用されていると想定する。この場合、利用が予想されるエントリの数は１０であり、２０個が３２個のエントリバッファで利用されているため、１２個のエントリのみが利用可能である。従って予想される１０個のエントリ利用を割り当てるとすると、残りは２個のエントリのみが利用可能となる。６個のエントリのバッファゾーンが利用されているので、フロー３７０でリソースが足りないと判断される。もしも２０個のエントリが利用可能な場合（１２個のエントリのみが利用中である）には、コード領域に１０個のエントリを割り当ててもまだ１０利用可能なエントリがあるので、十分なリソースがあることになる（フロー３６５参照）。

【0074】

加えて、利用率および利用可能性には、スレッドの優先度および利用率を考慮に入れてもよい。ここで複数のスレッドが共通してあるハードウェアリソースにアクセスする場合には、リソースを分割したり、完全に共有化したりすることができる。この結果、予想される利用に比べたときの利用および利用率は、この共有を考慮して、１つのスレッドが１つのハードウェアリソースを占有しないようにする（別のスレッド用に十分な利用可能性が残らないようではいけない、ということである）。例えば２つのスレッドが共通してあるキャッシュに分割によりアクセスする場合には、１以上のスレッドからのトランザクションが、キャッシュのエントリの半分に抑えられる。従って利用および利用可能性は、キャッシュ全体ではなくて、キャッシュの半分に対するものとなる。

【0075】

上述の説明は、ストアバッファに関するもの、または少しキャッシュに関するものであったが、利用／利用可能性は、ストアバッファ、ロードバッファ、キャッシュメモリ、犠牲キャッシュ、レジスタファイル、キュー、実行ユニット、またはその他の公知のプロセッサハードウェアといったハードウェアリソースの１つまたは組み合わせに対するものであってよい。例えば、ハードウェアリソースがキャッシュメモリを含む場合、予想される利用率には、触れられる／利用されるキャッシュライン数が含まれてよく、利用には、共有されている、排他的な、または修正されたキャッシュライン数等の、コヒーレンシー状態にある、またはないキャッシュライン数またはデータを保持するキャッシュライン数が含まれてよく、利用可能性は、例えば無効なコヒーレンシー状態である特定のコヒーレンシー状態にある、またはない利用可能なエントリまたはライン数を含んでよい。加えて、利用可能性／利用率はさらに、利用可能性／利用率を計測するハードウェアとの関連でも説明したとおりである。しかし上述したように、利用および利用可能性を直接または間接的に計測したり、ソフトウェア、ハードウェア、またはこれらの組み合わせで推定したりしてもよい。

【0076】

図３ａに戻り、領域を完成するために十分なリソースがあると判断されると、実行フローはフロー３０５に戻る。言い換えると、実行は、次の条件コミット点に到達するまで続けられ、この時点になると、ハードウェアリソースが再評価されてよい。しかし、十分なリソースがないと判断された場合には、フロー３２０で、トランザクションが終わる前に、トランザクションにコミットする（動的サイズ変更）。一実施形態では、途切れなく実行するために、新たなトランザクションをフロー３２５で開始して、アトミック実行を続ける。ここで１つの、大きなトランザクションを、本質的に仮想またはシステムメモリに拡張しなくてもハードウェアが処理可能になるよう小さなトランザクションに動的に分割して、実行空間を大きくする。

【0077】

図４に戻ると、トランザクションの実行をサポートする論理ブロックの一実施形態が記載されている。図示されているメモリ４０５は、オペレーティングシステム（ＯＳ）コード、ハイパーバイザコード、アプリケーションコード、動的コンパイラコード等のプログラムコード４１０を保持するよう適合されている。一例としては、プログラムコード４１０が、図２ａから図２ｂに従って動的に最適化される（ランタイムまたは部分的なプログラムコンパイル時に）アプリケーションコードの少なくとも一部を含んでいる。ランタイムには、動的サイズ変更をサポートするコードを有するトランザクションを持つ最適化されたコードを含むコード４１０が実行される。一実施形態では、前述したように、プログラムコード４１０が、条件コミット命令４１５（例えば領域チェック命令）を含んでいる。

【0078】

ここでデコーダ４２５（プロセッサのデコード論理）が、条件コミット命令４１５を認識するように適合されている。例えばデコード論理４２５は、オペコード４１８を、命令セットアーキテクチャの一部として特定するよう設計および相互接続される。この結果、特定の（予め定義された）処理／マイクロ処理を、デコーダ４２５がオペレーションコード（オペコード）４１８を含む条件命令４１５をデコードすると、論理４３０、ハードウェア４３５、および実行論理４４０により実行される。図示されているように、条件命令４１５には、予想されるハードウェア利用率（ハードウェア利用メトリック）４１６および分岐アドレス４２０（ベースアドレス、コード内から別の対象アドレスへのオフセット）への参照を含む。

【0079】

一実施形態ではデコーダ４２５が条件命令４１５をデコードすると、または遭遇すると、ハードウェアが、条件コミット命令４１５が示す実行されたハードウェア利用に見合うような、ハードウェアリソースが十分利用可能かを判断する。任意の公知の方法および装置を利用して、ハードウェアリソース利用を決定して、ハードウェアリソースの予想される利用率を満たすために利用可能なリソースが十分あるかを判断してよい。しかし、以下の具体例は、これら決定を実装するための一実施形態を例示する。

【0080】

ここでデコーダ４２５が条件命令４１５を受信すると、他の処理／マイクロ処理が、デコーダ４２５および論理４３０によってプロセッサパイプラインで実行される。例えば、デコーダ４２５は、条件コミット命令４１５を、実行すべき処理のトレース等の複数の処理（マイクロ処理）にデコードすることができる。上述した説明から、トレースは、デコードの後にトレースキャッシュに格納／構築することができる。例えば処理の１つが、ハードウェアリソースの利用レベルを示すレジスタの読み出し、またはハードウェア４３５からのロードを含む場合、論理４３０は、エントリをロードバッファに割り当てて、実行論理４４０でのロードの実行をスケジュールする。

【0081】

さらに、ハードウェア４３５は、条件命令４１５に応じて提供、決定、またはロードされるべき利用レベル４３５を決定するよう適合されている。上述したように、決定された利用レベルを有しうるトランザクション実行をサポートするハードウェアのいくつかの例に、キャッシュメモリ、投機的キャッシュメモリ、ストアバッファ、ロードバッファ、レジスタファイル、投機的レジスタファイル、チェックポイントレジスタファイル等を有してよい。この結果、命令４１５は、１以上のハードウェアリソースについて１以上の予想される利用メトリックを含んでよい。別個のハードウェアまたはリソース自身のいずれかが、その利用レベルを追跡するべく適合される。例えば、一実施形態では、キャッシュメモリ用のキャッシュ制御論理を、キャッシュメモリに保持される無効なキャッシュライン数またはキャッシュメモリ内で利用可能なライン数等のキャッシュメモリの利用レベルを追跡するべく適合する。

【0082】

次いで、決定されたハードウェア利用レベルに比べたときの予想利用レベルに基づいて、早期コミット（動的サイズ変更）を行わずにトランザクションの実行を続けるに足るリソースが存在しているかを判断する。早期コミットを実行する場合には、図示している例では、実行論理４４０が、条件コミット命令４１５が提供する分岐対象アドレス４２０にジャンプする。上述したように、分岐対象アドレスは、実行されると、早期にトランザクションにコミットして、別のトランザクションを再開してアトミック実行を続けさせるコードを含んでいてよい。

【0083】

具体例として、条件コミット命令４１５がデコーダ４２５に受信された場合を考える。条件命令４１５は、１０個のストアバッファエントリおよび１０個のキャッシュラインについて予想される利用メトリック４１６を含んでいる。ハードウェア４３５（トランザクションキャッシュメモリおよびストアバッファ）は、これらの利用レベルを決定する。これらハードウェアエントリは、利用の追跡を続けてよく、条件コミット命令４１５によるクエリ／要求があると、この利用率を提供する。または、条件コミット命令４１５からの要求を受けたとき、論理が実際に利用率を判断してもよい。いずれにしても、ハードウェア利用レベル／メトリック４３６が格納エレメントに（実行論理４４０による処理用の情報を保持するレジスタ等に）提供される。そして、ハードウェア利用レベル４３６および予想されるハードウェアメトリック４１６を比較して、早期コミットをせずに実行を続けるために利用可能なリソースが十分あるかを判断する。上述したように、比較は、バッファゾーン、閾値、または直接的な比較を利用することで、設計者のアルゴリズムの好みに基づいて利用可能なリソースが十分あるかを判断することができる。

【0084】

ここで、ストアバッファが３２個のストアバッファエントリのうち１６個を利用しており（つまり１６個のエントリが利用可能である）、トランザクションキャッシュの６４個のエントリのうち６０個がトランザクション的にアクセスされたとマークされている場合を想定する（つまり、トランザクションがこれらラインに既にアクセスしており、これらのラインの置き換えにより、情報がなくなり、アボートまたはソフトウェアトランザクション実行へと拡張される、つまり４つのエントリが利用可能である）。そして、設計者のアルゴリズムにより、予想されたエントリ数を考慮して、４つの利用可能なエントリがなくてはならないと規定されている場合を想定する。この場合、１０個の予想ストアバッファエントリがあり１６個の利用可能なエントリがあるので、次の条件コミット点に到達するまでのアトミック実行に対応するためにストアバッファには利用可能な空間が十分あることになる。しかし、トランザクション的にアクセスされたとしてマークされていないキャッシュエントリは４つしかないので、十分なトランザクションキャッシュ空間があるとはいえない。この結果、実行論理（ジャンプ実行ユニット等）が、分岐対象アドレス４２０にジャンプして、トランザクションに早期にコミットして（動的にトランザクションを縮小する）、別のトランザクションを再開するべくコードをフェッチ、デコード、および実行する。

【0085】

上述した例は、予想されたハードウェア利用メトリックおよび分岐対象アドレスを含む条件コミット命令に関するものであった。しかし、条件コミット命令には、ハードウェアが、コードの実行をサポートする上で十分なハードウェアが利用可能であるかを判断する、または推定することができる任意の命令が含まれていてよい。例えば、条件コミット命令は、トランザクションをコミットするかを判断するために、現在の利用レベルを過去のコードのハードウェアプロファイリング条件と比べて評価する、というジャンプ命令のみであってもよい。評価した後で、ハードウェアは、条件コミット命令が提供する分岐アドレスにジャンプすることができる。

【0086】

別の実施形態では、ハードウェアが非同期的に、トランザクションにコミットするかを判断してよい（特定の条件コミット命令に関連せず、またはその応答としてではなく）。ここで、プロセッサがトランザクションコードを実行している間、またはオーバフローイベントを実行している間（これは、既にトランザクション的にマークされたエントリの退去等、ハードウェアリソースにスペースがないことを意味するイベントである）、ハードウェアが、ハードウェアトランザクションをコミットして、コードがその他のよい方法を知らなければ新たなトランザクションを再開しうる。

【0087】

図５は、ハードウェアが動的なトランザクションのサイズ変更をサポートしている別の実施形態を示す。図４を参照して、実行論理４４０により処理用に利用されるレジスタ等の格納エレメントに、決定されたハードウェア利用レベル／メトリックを設けてよいことが説明されていたかと思う。ここでも前の例同様に、決定されたハードウェア利用レベル／メトリックを、格納エレメント（例えばレジスタ５５０）にロードしてよい。しかし一実施形態では、モデル特定レジスタ（ＭＳＲ）を含んでよいレジスタ５５０が、プログラムコード（例えばユーザレベルのアプリケーションコード）により、ハードウェアリソースの利用可能性を評価すべくアクセス可能なよう適合されている。前の例では、ハードウェアが、ソフトウェアが予想した利用率に基づいて評価を行っていた。しかしこの例では、ソフトウェアはハードウェア（ＭＳＲ５５０）にクエリを行い、１以上のハードウェアリソースの利用レベルを受信することができる。そしてソフトウェアは、次のコミット点までアトミック実行を続けることができるリソースを有しているかを、自身のガイドラインに基づいて決定することができる。この方法は、ユーザに利用するハードウェア量を決定させることができるため、ユーザ側により柔軟性がある方法である。この結果、プロセッサ設計者は、プロセッサ側に大きな制御を与えるか、ユーザ側にその決定権を与えるかを選択することができるようになる。

【0088】

具体例として、プロセッサが、潜在的に動的なサイズ変更を行うことのできる挿入／最適化されたトランザクションを含むプログラムコード５１０を最適化、実行する動的コンパイラコードを実行する場合を想定する。ここで、プロセッサのフェッチ論理（不図示）が、プロセッサ（これも不図示）のスレッドの命令ポインタに基づいて、ロード処理５１５をフェッチする。ロードバッファエントリは、ロードバッファの論理５３０／ハードウェア５３５に割り当てられる。ロードは論理５３０によりスケジュールされ、ディスパッチされ、且つ、論理５４０により実行されて、ハードウェア５３５（キャッシュ、バッファ、またはレジスタファイル等のトランザクション実行をサポートするリソース）から決定された利用レベル５３６がロードされる。ロードまたは前の命令は、同期して、ハードウェア５３５に、利用を決定させたり、および／または、ＭＳＲ５５０の利用を配置させたりする。または、ハードウェア５３５が、非同期的に、ＭＳＲ５５０に利用レベルを配置してもよい（イベントに基づいて、であっても、周期的に、であってもよい）。いずれにしても、利用レベルは処理５１６により読み出され、評価される。

【0089】

例えば処理５１６は、ロードされた、ハードウェア利用レベルを、ソフトウェアが定義する予想利用レベルその他の閾値レベルに対して評価するブール式を含んでよい。実際、ブール式は、条件ステートメントおよび／またはジャンプ命令５１７の一部であってよいが、これに関しては後述する。ここで、ハードウェア利用レベルの評価が、トランザクションが早期にコミットされることを示している場合には、デコーダ５２５がオペコード５１７ｏにより認識するジャンプ命令５１７が実行されて、宛先アドレス５２０に上述したように分岐して、トランザクションにコミットして、別のトランザクションを再開する。

【0090】

図６を参照すると、トランザクションの動的サイズ変更をサポートしているハードウェアのまた別の実施形態が示されエチル。一実施形態では、カウンタ６５０が、ループ６１５の実行によるイタレーション数をカウントするよう適合されている。カウンタ６５０は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装されてよい。例えばカウンタ６５０は、値を保持するレジスタであってよい。ソフトウェアコードは、ループが繰り返されるたびに、現在の値を読み出し、現在の値を新たな値に修正し（増分／低減）、レジスタに格納する。本質的には、ソフトウェアがカウンタを維持している。しかしハードウェアカウンタが、ループの各イタレーションの開始および終了時に、増分／低減を行ってよい。

【0091】

一実施形態では、カウンタ６５０のカウンタ値を利用して、トランザクションの早期コミットを行うときを決定する。例えばカウンタ６５０は、閾値に到達するまでループのイタレーション数をカウントする。閾値に到達すると、カウンタが期限切れになり、または、オーバフローして、早期コミットが行われる。カウンタはゼロから開始され、閾値に到達する（オーバフロー）までカウントされてもよいし、あるいは、ある値で開始され、ゼロまでカウントダウンされてもよい（期限切れまたはアンダーフローとなる）。

【0092】

閾値（またはゼロまで低減されるカウンタの開始値）は、いずれの方法で決定されてもよい。ハードウェアに含まれる、またはソフトウェアにより設定される、静的な、予め定義された値であってもよい。ここで、静的な、予め定義された値は、プロセッサに含まれるハードウェアの種類またはサイズ、および、実行中のコードの種類またはサイズ等の、すでにわかっている特性に基づいてハードウェアまたはソフトウェアにより知的に選択されてよい。あるいは、静的な、予め定義された値は、たとえばループのイタレーション数を制限するための保守的な値から、ロールバックが顕著に低減するような十分小さい値に、レイジーに選択されてもよい。

【0093】

別の実施形態として、閾値（開始値）を、動的選択および変更の両方を可能としてもよい。ここで、ハードウェア、ソフトウェア、またはこれらの組み合わせにより、任意の特性に基づいて開始初期値（閾値）を選択することもできる。例えば、利用可能なキャッシュラインまたはストアバッファエントリの数（例えば３２）を、コードの１つのループイタレーションのストア数のカウント（例えば８）で除算して、閾値を求めてもよい（例えば４）。一実施形態では、複数ストアすると、１つのキャッシュラインしか触れられなくなるので、ストア数の推定を合理的に保守的に行う。従って、より積極的な初期値を利用することもできる。別の例としては、コードまたはハードウェアのいずれかが、積極的または保守的な値を、コードサイズ／タイプ、ハードウェアユニットサイズ／タイプ、ループの実行が完了するために必要なリソースがあるようにするためのその他の公知の要素に基づいて選択してもよい。さらに、ハードウェアまたはソフトウェアが、コードのプロファイリングをとり、開始値／閾値を提供してもよい。ここで、閾値の数を含むソフトウェアのヒントを、ループの実行の開始前に提供して、カウンタを閾値の数に基づいてセットしてもよい。または、ハードウェアが同様にコードのプロファイリングをとり、コードの領域のプロファイリング履歴に基づいてカウンタをセットしてもよい。

【0094】

一実施形態では、カウンタを初期化した後で、閾値（開始値）を動的に修正する（例えば、ループのコードプロファイリングまたはロールバック決定等の実行分析に基づいて調節する）。一実施形態では本質的に、カウンタ６５０が、ハードウェアリソースが限られていることから許容範囲のロールバック数に達してしまったりロールバックしたりする前にロールバックをループ６１５が実行することができるイタレーション回数を推定するために利用される。従って、許容できるロールバック数の範囲を超えるロールバックが生じると、コミットを行う前のイタレーション数を低下させて前の閾値を低減させることで、ロールバック数を低下させる。この場合には、あまりにロールバックを頻繁に行いすぎて、実行時間が無駄になり、遅延を生じる可能性がある。しかし、閾値が保守的すぎないようにするために（利用可能なリソースがまだ沢山あるとき、外部的に早期にトランザクションにコミットして、アトミック実行が非効率になる）、一実施形態では、ロールバックが生じるまで閾値を増分させる。増分／低減回数は、１つ、複数、または指数であってよい。一例としては、開始値を６３に初期設定することを想定する（つまり、コミットされるまでに６４回のイタレーションが許可される）。ハードウェア制約によってアボート／ロールバックが複数検知されると、閾値を６２に低下させる。後でロールバックが起こると、さらに２（６０）、４（５６）、８（４８）等に低下されて、最終的にはバランスのとれた開始値に落ち着いて、完全に実行を効率的に行うことができるようになる。

【0095】

図６の説明は、条件コミット命令は特に利用せずに、ループのイタレーション数をカウントするカウンタを参照して行われている。ここで、カウンタが閾値に達すると、ハードウェアで非同期的にコミットを開始することができる。しかし別の実施形態では、カウンタ６５０が、図５および図６の条件コミットコードと協働してよい。一例として、カウンタは、利用可能なハードウェアリソース量を決定／推定するハードウェアメカニズムであってよく、条件コミット命令は、ハードウェアカウンタに基づいてコミットコードにジャンプさせる。例えば、カウンタ６５０が、９に初期化された場合を想定しよう（条件コミットが生じる前に１０回のイタレーションが許可される）。ループ６１５が繰り返されるごとに、条件コミット命令（例えば条件ジャンプ命令）を実行して、カウンタが期限切れになると（ゼロになると）、分岐対象アドレスにジャンプする。１０回目のイタレーションが完了して、条件ジャンプが実行されると、実行フローは、実行中のアトミック領域にコミットするために対象アドレスにジャンプする。

【0096】

カウンタは正確ではないが、個々のハードウェアユニットの具体的な利用レベル測定値は、全て包括した測定値である可能性がある。上述したように、動的な閾値調節により、ハードウェアの制約に基づいてロールバックを減らすための最適なイタレーション回数を見つけることができる。従って、前に特定されていないハードウェアの限定によってロールバックが生じている場合、動的なカウンタ閾値がこれを捉え、一方で、設計者またはプログラマによる個々の特定により、このような特定されていない原因をなくすことができる。さらに、カウンタが特定のハードウェアユニット利用計測値とともに利用されることで、ユニットレベル粒度と、広く網羅できているグローバルな粒度が達成される。

【0097】

前述したことは、主にハードウェアリソースが枯渇する前にトランザクションの条件コミットに注目したものである。または、実行のためのリソースが利用可能かを確かめるために、予想される利用率との比較においてハードウェア利用率を決定する。しかし、一部の実施形態では、アトミック領域により実行すると好適であると思われる。また定期的に（ユーザ命令、イベント、またはハードウェア定義時間に応じて）アトミック領域をチェックポイント実施するとよい。実際のハードウェアの制約、例外、割り込み、その他の不備に遭遇すると、アトミック領域は、最近の内部チェックポイントに戻り、リソースの占有解除にコミットすることができる。本質的に、将来の推定およびトランザクションに先回りしてコミットする代わりに、一実施形態では、トランザクションは、通常トランザクション全体のアボートおよび再開を必要とする実際のリソースの制約に遭遇した場合のみにサイズ変更される。これは、トランザクション内の複数のチェックイベントを実行することで、ロールバックが起こると、許容できる実行量だけがロールバックされるようにすることで達成される。

【0098】

図７ａを参照すると、トランザクション内に投機的なチェックポイントを提供することを含むコードの最適化方法のフロー図の一実施形態を示す。ブロック７０５で、最適化すべきプログラムコードの１つのセクションを特定する。図２ａの説明同様に、コードのセクション／領域は、そのセクションに関するユーザの特定／ヒント、プログラム分析、コードプロファイリング、コード属性（特定のタイプ、フォーマット、順序、またはその領域の特性（ループまたはストア数））、またはその他の最適化すべきコード領域を特定する公知の方法に基づいて特定されてよい。一例ではコードがバイナリコードを含む。バイナリコードの実行中に、動的に最適化される。この結果、実行のための最適化中に、バイナリコードにループが遭遇する。ロールバックにより実行の大きな損失がない程度にチェックポイント間の距離を短くするために、ループを最適化すべきであると判断する（投機的チェックポイントの挿入）。一例としては、以下の擬似コードＦが、最適化すべきコード領域の一例を示している。

【表6】

【0099】

図２ａの説明同様に、フロー７１０、７１５では、コードの領域を区分する（セクションの初めにアトミック領域開始命令を挿入して、セクションの末尾にアトミック領域終了命令を挿入する）。前述したように、コード領域は、複数のエントリと複数の退出とを含みうる。ブロック７２０で、プログラムコード内の投機的チェックポイント位置を決定する。最適化すべきコードの領域内には複数の投機的チェックポイントが決定／割り当てられる可能性があるが、説明の便宜上、１つのチェックポイントのみを例にとって説明する。

【0100】

投機的なチェックポイントの決定は、アトミック領域内のロールバック効果を最小限に抑える任意の公知の割り当て／決定アルゴリズムに基づいて行われてよい。最初の例として、投機的チェックポイントをループ内に挿入して、イタレーションごとに投機的チェックポイントに遭遇するようにする。ここで投機的チェックポイントは、ループの最初またはループのエッジに決定されてよい。コードの動的プロファイリングが、しばしばハードウェアリソースを欠いたり、高い命令カウントを有したりするような実行経路を示している別の例を考える。この例では、投機的チェックポイントをこのような実行経路に割り当てることで、長い実行経路内でのアボートによってアトミック領域全体がロールバックしないようにすることができる。同様に、独占またはリソースがたくさん必要な状態が生じやすいことで知られている実行経路にも投機的チェックポイントを割り当てておく。本質的に、トランザクション全体の前の先行技術のチェックポイントおよび関連するトランザクション全体のロールバックの代わりに、トランザクション内でチェックポイント（ローカル、内部、または一時的なチェックポイント）を利用することでより小さなロールバック（あまり無駄がでない実行）が実行される。この結果、より大きな領域を最適化することができる。リソースの制約に遭遇すると、小さなロールバックを実行する。加えて、ロールバック点では、トランザクションに潜在的にコミットして、最終的な不備を処理して、別のトランザクションを再開する。

【0101】

フロー７２５で、投機的なチェックポイントコードを投機的なチェックポイントの位置に挿入する。投機的なチェックポイントコードは、メモリ、キャッシュメモリ、および／またはレジスタファイル等の投機的なハードウェアリソースのチェックポイント実行である。一実施形態では、投機的なチェックポイントコードも、後続するアボート条件に応じてチェックポイントにハードウェアリソースを復元するコードを含んでよい。図７ｂを簡単に参照すると、投機的なチェックポイントコードを挿入するフロー図の一実施形態が示されている。擬似コードＧはさらに、投機的なチェックポイントコードの挿入後のコードの例を示している。

【表7】

【0102】

フロー７２６で、投機的チェックポイント（Ｂ２、Ｂ５のループバックエッジ）に投機的チェックポイント命令／処理（Ｂ５のＬ１）を挿入する。一実施形態では、投機的なチェックポイント命令が、投機的なハードウェアリソースのチェックポイント（現在のスナップショット）を開始するためのいずれの命令を含んでもよい。例えば、投機的なチェックポイント命令はプロセッサのデコーダにより認識可能である。デコードされ、スケジュールされ、実行されると、投機的なレジスタファイル、ストアバッファ、またはこれらの両方が、チェックポイント投機的レジスタファイルおよび投機的なキャッシュ等のチェックポイント格納構造へと、チェックポイント実行される（現在の状態のスナップショットがとられる）。

【0103】

さらに一実施形態では、投機的なチェックポイントコードが、現在のロールバックを生じさせたのと同じロールバック状況を潜在的に避けるためになんらかの動作を実行するためのその他のコードを含む。例えば、ハードウェアリソースの制約によりロールバックが生じた場合、何らかの補正措置がとられなければ常に同じハードウェアの制約が生じる場合があり、前に進めなくなる。

【0104】

一例として、擬似コードＨの左側のコードを最適化する場合を考える。

【表8】

【0105】

ここで、最適化されたコード内のロールバック処理方法には複数のシナリオがある。以下の擬似コードＩに示す最初の例では、投機的なチェックポイント命令を、通常のループ実行か、投機的なチェックポイントへのロールバック後の再実行かを差別化することができる条件（分岐）命令と対にする。分岐命令は、実行されると、前のチェックポイントの状態にロールバックするための任意の公知の方法でロールバックを処理することができる。

【表9】

【0106】

下の擬似コードＪに示す別の例では、一部の実施形態で説明されたように、投機的なチェックポイント命令を分岐命令と組み合わせて、１つのチェックポイントと分岐命令とすることができる。

【表10】

【0107】

擬似コードＧの説明に戻ると、一実施形態では、投機的なチェックポイントコードが修正を含み（ロールバック、復元、再構成、復帰等と称される場合もある）、実行されると、チェックポイント格納構造の最新のチェックポイントの正確な状態を復帰または復元する。一部の実施形態では、上述した他のシナリオも、投機的なチェックポイントコードおよび／または修正と捉えられる場合がある。しかしここでは、擬似コードＧに示すように、修正コードが、トランザクション／アトミック領域にコミットするためのコミットコード（Ｂ６）も含むことができる、とする。本質的には、投機的なチェックポイントコードが、投機的なハードウェアのチェックポイントを実行する。投機的なハードウェアがなくなること、または、アボートを生じさせるイベントに遭遇すること（割り込み、動的なアサート、メモリエイリアスチェック等）が生じると、チェックポイントコードが、投機的なハードウェアの正確な状態を復元する。代替策として、再実行および継続した実行のために、投機的なハードウェアを解放するべく、トランザクションにコミットしてもよい。従い、修正コードを得る方法は複数あることが分かるだろう。いくつかの例として、（１）チェックポイント格納構造が投機的ハードウェアチェックポイントに十分なスペースを有さない場合、投機的なチェックポイント処理を実行する、（２）投機的なハードウェアに対応できない投機的な処理を実行する、（３）投機的な実行中の例外、または、（４）トランザクション内の一時的な内部チェックポイントになりうる任意の他のイベントから修正コードを入力することができる。

【0108】

さらに、投機的なチェックポイントを条件コミットと組み合わせると、投機的リソースがないのでアボートが回避され、且つ、チェックポイント実行で、不備、例外、その他の予測不可能な事象を（アトミック領域の開始の代わりにチェックポイントに戻るとき実行をあまり無駄にしない、ということ）より安価なものとすることができ、さらなる利点が得られる。以下の擬似コードＫは、これら組み合わせの一例を示している。

【表11】

【0109】

さらに一実施形態では、以下の擬似コードＬのように、条件コミット命令に、投機的チェックポイントを認識させる。

【表12】

【0110】

この場合、システムにリソースがなくなると（上述したとおりである）、または、ロールバックリプレーが実行されると（実行が投機的チェックポイントにロールバックした後で）、ｒｅｇｉｏｎ＿ｃｈｅｃｋ（条件コミット）命令は、Ｌ２にジャンプする。

【0111】

加えて、投機的チェックポイントおよび条件コミット命令を一緒に利用するだけでなく、一実施形態では、これら命令自身が組み合わせられて、以下の擬似コードＭとして記述される。

【表13】

【0112】

ここで、組み合わせられた命令が実行されるとき、チェックポイントを行い、条件コミットを評価する（ハードウェアリソースなくなりかけていたり、少なくなっていたりする状態であれば、コミットする）。ここで、もしシステムの投機的リソースが少なくなった場合、または実行が記録されている投機的なチェックポイントにロールバックした場合には、実行はＬ２にジャンプして、（この例では）投機的リソースにコミットして最終的な欠陥に対処することで対処する。

【0113】

前述した説明は、ハードウェアが少なくなってきたとき、不備が検知された場合、例外が生じたとき、またはその他の予測不能なイベントが割り込みを生じたときに前の（または最近の投機的な）チェックポイントにロールバックすることに関していたが、これらの割り込みに応じて他の経路を探すこともできる。一実施形態では、割り込みが生じると、ハードウェア、ソフトウェア、またはこれらの組み合わせで、次に何をするかが決定される。例えば、ハードウェアが不備のある／イベントを生成した場合等、不備がアトミック実行中に生じたと想定する。アトミック実行が中断される。通常は制御がソフトウェアに渡されて、不備の種類が判断され、不備に対する対処が行われる。

【0114】

ここで、ハンドラ等のソフトウェアが、不備の種類、最新の投機的なチェックポイントにロールバックする難しさ、最新の投機的なチェックポイントではなく末尾のコミット点にロールバックすることで失われる実行量または命令数、または、戻るためのプログラムの実行点を選択する際に考慮するその他の要素等、任意の数の要素に基づいて次にすべきことを決定してよい。本質的に、この例では、ハンドラ等のソフトウェアが、実行がアトミック領域の最初、アトミック領域の末尾のコミット点、または、アトミック領域の最新の投機的なチェックポイントのいずれにロールバックすべきかを決定している。例では決定を行うソフトウェアに着目されているが、ハードウェアも決定を行う。一実施形態では、新たな命令（ｓｐｅｃｕｌａｔｉｖｅ＿ｒｏｌｌｂａｃｋ）が決定に利用される。ここでｓｐｅｃｕｌａｔｉｖｅ＿ｒｏｌｌｂａｃｋ命令が、プログラムコードの適切なもの（投機的なチェックポイントまたは最近のコミット点）に戻すための結果をデコードおよび実行した任意の情報を含んでいる。

【0115】

ここで記載するコードは、同じブロック、領域、プログラム、またはメモリ空間内に連結される必要はない。実際、投機的なチェックポイント処理は、主要なプログラムコード内のループバックエッジに挿入されてよい。一番近いチェックポイントにロールバックし、任意でトランザクションにコミットするコードを含む修正コードが、コードのライブラリまたはその他の部分に配置されてよい。ここでは、主要なプログラムコードが実行中である。修正コードが入力されると、ライブラリコードの１以上の関数の呼び出しを実行して、ロールバックおよびコミットを実行する。さらに、ハードウェアは、ソフトウェアの命令なしに同様のチェックポイント処理を実行してよい。ここで、ハードウェアはトランスペアレントに（例えば周期的に、またはイベント駆動ベースで）投機的なハードウェアをチェックポイント実行してよい。投機的なハードウェアがなくなると、プロセッサは実行を最新のチェックポイントにロールバックして、トランザクションにコミットして、トランザクションを再開して、チェックポイントとロールバック点との間の命令をリプレーする。ソフトウェアの観点からは、通常の実行が続いているよう見えるが、ハードウェアは、リソースの制約および再実行の全てを処理している。しかし、ハードウェアとソフトウェアとの間の任意のレベルの協力を利用して、ローカルな内部トランザクション的チェックポイントを達成することができる。

【0116】

図７ａに戻ると、ブロック７３０で、プログラムコードのセクションを最適化する。以下の擬似コードＮが、最適化後の擬似コードＭからのコード領域の一例を示している。

【表14】

【0117】

最適化の別の例として、以下の擬似コードＯが、別の最適化の例を示している（擬似コードＧのコード領域の最適化）。

【表15】

【0118】

上述したように、任意の公知の最適化技術をアトミック領域内のコードに実行することができる。コード最適化の数例としては（全部を網羅することは意図しておらず、純粋に例示を目的としている）、ＰＲＬＥ，ＰＤＳＥ，ループ最適化、データフロー最適化、コード生成最適化、デマケーションチェック除去、分岐オフセット最適化、デッドコード除去、およびジャンプスレッドが含まれる。擬似コードＯでは、Ｂ６にコミットした後で、Ｂ６で別のトランザクションが開始され、Ｂ２で実行が引き続き行われる。他の実施形態（不図示）では、Ｂ３でコードを再入力する。アトミック領域のデマケーションおよび条件コミットコードの挿入も、一部の実施形態ではプログラムコードの最適化とみなすことができる。

【0119】

次に図８に戻ると、トランザクションの実行中に投機的にメモリをチェックポイント実行する方法のフロー図の一実施形態が示されている。フロー８０５で、トランザクションを実行する。一例として、トランザクションが、ランタイム中に動的に最適化されるバイナリコードとされて、コード最適化の周りにトランザクションを挿入して、アトミック性能を保つ。

【0120】

フロー８１０で、トランザクションからの投機的なチェックポイント命令に遭遇する。投機的なチェックポイント命令がさらに最適化装置により投機的チェックのポイントにランタイム中に挿入されたことは、図７ａから図７ｂを参照して上述したとおりである。プロセッサは、投機的チェックポイント命令を認識する（通常は、予め指定され／定義されたオペレーションコードを検知するデコーダであってよい）。投機的なチェックポイント命令に呼応して、フロー８１５で、投機的なレジスタファイルをチェックポイント（投機的）レジスタファイルにチェックポイント実行を行う。加えて、フロー８２０で、投機的なキャッシュには、ストアバッファをチェックポイント実行するために十分なスペースが含まれているかが判断される。フロー８２５で、もし利用可能なスペースが十分な場合には、ストアバッファを投機的なキャッシュにチェックポイント実行する。しかし十分なスペースがない場合には、修正／ロールバック手順（以下で詳述するブロック８４５−８５５）を実行する。

【0121】

この結果、トランザクションの実行中に短期のロールバックイベントに遭遇すると、現在の実行に利用されている投機的なレジスタファイルおよびストアバッファが、チェックポイント実行された状態に復元される。一例として、フロー８３０で、ストア処理に遭遇する。フロー８３５で、ストアバッファが利用可能なエントリ（例えばストア処理のために割り当て可能なエントリ等）を含むかを判断する。容易に利用可能なエントリが存在する場合、または、割り当て解除、再割り当てが可能なエントリが存在している場合には、そのエントリをブロック８４０で割り当てる。ストアバッファエントリが利用可能ではない場合には、ロールバック手順を実行する（ブロック８４５−８５５）。

【0122】

ロールバック／復元手順８４５−８５５は、前のチェックポイントからの正確なアーキテクチャ状態を復元するものである。ここでロールバックは、コミットされていない（グローバルに見られる状態にされていない）投機的実行中に生じる。従ってグローバルに見ることができる状態（非投機的格納構造）は同じ状態に留まる必要がある。しかし、現在の投機的な実行をサポートしている投機的なハードウェア構造が復元される。投機的なキャッシュは既にストアバッファから最新のチェックポイントまでの投機的な更新を保持しているので、ストアバッファをブロック８５０でフラッシュする。言い換えると、トランザクションの最初から最近のチェックポイントまでのストアが投機的キャッシュに保持される。そして、最近のチェックポイントから現在の実行ユニット(ロールバックの開始)までを、ストアバッファに保持する。そして、ロールバックされたストアを、ストアバッファから単にアボートする。

【0123】

加えて、投機的レジスタファイルをチェックポイントレジスタファイルから復元する。ここで投機的レジスタファイルは、最近のチェックポイントからのものを含むトランザクションの開始からの更新の全てを保持しており、投機的なレジスタファイルはチェックポイントレジスタファイルからの値でリロードされる。元のチェックポイントが投機的なレジスタファイル全体のコピーを含む場合（投機的な実行中に修正されたレジスタのみを選択的に格納するだけでなく）、チェックポイントレジスタファイルのラベルを、投機的なレジスタファイルとしてつけなおし（利用し）、前の投機的なレジスタファイルをフラッシュして、チェックポイントレジスタファイルとして後で利用する点に留意されたい。または、投機的なレジスタファイルを、投機的なチェックポイントレジスタファイルにフラッシュコピーする（１またはいくつかのサイクルで）。

【0124】

フロー８６０で、任意にトランザクションをコミットしてもよい。例外、投機的なキャッシュのスペース不足、またはストアバッファのスペース不足により、ロールバック手順に達するので、トランザクションをコミットしてこれらリソースを解放する。ここで、ストアバッファおよび投機的なキャッシュ更新は、非投機的なキャッシュメモリにコミットされ、これらリソースが解放される（フロー８７５−８８０）。そして同様に投機的なレジスタファイルを非投機的なレジスタファイルにコミットして、さらなる投機的な実行用に解放する（フロー８７５−８８０に示す）。さらに、トランザクションの完全なアボートを実行して（８６５）、ストアバッファおよび投機的なキャッシュをフラッシュして、ブロック８７０のトランザクション前の（非投機的）状態に復元する。

【0125】

図９を参照すると、投機的なチェックポイント実行をサポートするよう適合されたハードウェアの論理表現の一実施形態が示されている。デコーダ（デコード論理）９１０を適合させ、または相互接続して、投機的なチェックポイント命令（ＳＣＰＩ）９０５を認識する。例えば、図９のハードウェアを含むプロセッサの命令の予め定義されたフォーマットが特定されて、ハードウェア内に設計される。特定のビットパターンを持つ命令の一部が特定の命令に対応しており、その１つがＳＣＰＩ９０５である。

【0126】

次にＳＣＰＩに呼応して、投機的格納構造に格納されている投機的値９３５を、投機的チェックポイント格納構造の投機的チェックポイント値９４０としてチェックポイント実行する。実行論理９２０は、ＳＣＰＩ９２０を実行するデコーダに連結されたものとして示されている。しかし明らかにデコードと実行との間のパイプラインには数多くの段階が存在する。例えばＳＣＰＩは、１つのトレースキャッシュ内の処理トレースにデコードされてよく、これら処理はバッファにキュー待ち状態にされ、ここで記載する処理／方法を実行するためにスケジュール、ディスパッチ、および実行されてよい。

【0127】

簡単に上述したように、チェックポイントは、ある時点での値の状態のスナップショットを含み、または、少なくともその時点での値の状態を復元するために十分な情報を含む。従って、一実施形態では、チェックポイントが、投機的な値９３５全体の写しを投機的なチェックポイント値９４０として含む。投機的な値９３５は、投機的なレジスタファイルからの投機的なレジスタファイル値を含んでよく、投機的なチェックポイント値９４０は、時間的に最近のチェックポイント投機的なレジスタファイルのコピーを含む。別の例としては、投機的なチェックポイント値が、最後のチェックポイントから修正された投機的な値９３５のみを含む。ここで投機的な値９３５は、投機的なレジスタファイルからの投機的なレジスタファイル値を含んでよく、投機的なチェックポイント値９４０は、最後のチェックポイントから修正された投機的なレジスタファイル内のレジスタだけの最後のチェックポイントからの投機的なレジスタファイル値を含む。また別の例では、投機的なチェックポイント値９４０が、時間的にアトミック領域からチェックポイント時点までの値全てを含み、一方で、投機的な値９３５が、チェックポイントから現在の実行店までの投機的な値全てを含む。ここで、ストアバッファが投機的な値９３５を保持してよく、これは投機的キャッシュに保持されている古い値（最初から最後のチェックポイントまで）に加えられる。

【0128】

図１０を参照すると、レジスタファイルの投機的なチェックポイント実行をサポートするよう適合されているハードウェアの論理表現の別の実施形態を示す。上述の説明同様に、デコーダ１０１０および実行論理１０２０は、それぞれＳＣＰＩ１００５を受信して、認識して、実行するよう適合されている。ＳＣＰＩ１００５に呼応して、投機的なレジスタファイル１０３５を投機的なチェックポイントレジスタファイル１０４０にチェックポイント実行する。上述したように、チェックポイントは、レジスタファイル１０３５のフラッシュコピーをチェックポイントレジスタファイル１０４０に含んでいてよい。または、ファイル１０３５のレジスタを修正する場合には、古い値をレジスタファイル１０４０にチェックポイント実行する。ここでＳＣＰＩ１００５に呼応して値をコピーする代わりに、ファイル１０３５の対応するものを修正したものをコピーした、ファイル１０４０からの古いチェックポイント値をクリアして、無効とする。実行が続けられる場合、修正されたレジスタを再度ファイル１０４０にチェックポイントとして入力する。

【0129】

ロールバック（図８のブロック８２０等の投機的キャッシュのスペース不足、図８のブロック８４０等のストアバッファのスペース不足、例外、その他のロールバックイベント）から最近のチェックポイントに呼応して、チェックポイント値（修正版のみであっても全コピーであっても）を、投機的チェックポイントレジスタファイル１０４０から投機的レジスタファイル１０３５に復元する。しかしトランザクション領域の最初の部分にロールバックがある場合（例えばトランザクションのアボート等）、一実施形態では、投機的なレジスタファイル１０３５を非投機的案レジスタファイル１０３０からリロードする。本質的に、投機的なファイル１０３５は、作業用の投機的なレジスタファイルである。従ってトランザクションは投機的なレジスタファイル１０３５とともに作動する（読み出し、書き込み）。トランザクションの最初でロードを再実行する場合、非投機的値をリロードしない場合、ロードは、アボート前に投機的なレジスタファイル１０３５に保持されていた、後に修正された投機的な値を不注意でロードしてしまう場合がある。

【0130】

加えて、トランザクションのコミットに呼応して、投機的レジスタファイル１０３５を非投機的レジスタファイル１０３０にコミット（コピー）する。ここでは、投機的な更新を非投機的な結果としてグローバルに見えるようにする。ここでもまた、レジスタファイル１０３５全体を非投機的なレジスタファイル１０３０にコピーしてよい。修正された投機的なレジスタファイル１０３５のレジスタだけを、非投機的なレジスタファイル１０３０にコピーしてよい。

【0131】

図１１を参照すると、キャッシュメモリの投機的なチェックポイントをサポートするよう適合されたハードウェアの論理的表現の別の実施形態が示されている。図９から図１０に関して上述したように、デコーダ１１１０および実行論理１１２０は、ＳＣＰＩ１１０５をデコードして実行するよう適合されている。ここで実行論理１１２０は、アトミック領域から投機的ストアを実行するとき、投機的な更新を保持するためにストアバッファ１１４０を利用する。ここで、前のストアからロードする同じ領域（ローカルスレッド）からのロードは、ストアバッファ１１４０に保持されている投機的値からロードされる。従って、実行中のストアをロードする同様のメカニズムをストアバッファ１１４０と実行論理１１２０のロード実行ユニットとの間で利用することができる。しかし、ストアバッファ１１４０のストアのアドレスへの非投機または非ローカルのロードが、ストアバッファ１１４０の値ではなく、キャッシュ１１３０に保持されている非投機の値を受ける。加えて、アトミック領域の読み出し／ロードから、チェックポイントされたり、投機的なキャッシュ１１３５に移動されたりしたストアのアドレスがある場合には、直接またはストアバッファ１１４０経由で投機的なキャッシュ値がロードに提供されるべきである。

【0132】

ＳＣＰＩ１１０５に呼応して、バッファ１１４０内のストアバッファ更新が、投機的なキャッシュ１１３５に移動させられる。この結果、投機的なキャッシュ１１３５は、アトミック領域の最初から、最近のチェックポイントへの投機的な更新を保持する。そしてストアバッファ１１４０が、最近のチェックポイントから現在の実行チェックポイントへの投機的更新を保持する。従ってアトミック領域がコミットされると、投機的キャッシュ１１３５およびストアバッファ１１４０の全ての更新が、非投機的なキャッシュ１１３０にコミット／移動／コピーされる。例示したように、このコミットは、ストアバッファ１１４０を投機的なキャッシュ１１３５に、および、投機的なキャッシュ１１３５を非投機的なキャッシュ１１３０にコミットすることで実行される。別の実施形態では、ストアバッファ１１４０および投機的なキャッシュ１１３５両方からの更新を、非投機的なキャッシュ１１３０に直接提供することができる。コミット後、更新がグローバルに見えるようになり、メモリ階層１１５０を介して伝播されてよい（より高いレベルのメモリおよびホーム位置に）。

【0133】

さらに、本実施形態では、ローカルの内部ロールバックに呼応して、ストアバッファ１１４０をフラッシュする。上述したように、本実施形態では、ストアバッファ１１４０が本質的に最近のチェックポイントから現在の実行ポイントまでの更新を保持している。従いロールバックが生じると、これら更新はアボートされる。一例では、ストアバッファ１１４０がアトミック領域からの新たなストア処理に対応できないことに呼応して（図８のブロック８４０）ローカルロールバックが開始されてもよい。ブロック８２０で、ロールバックは、投機的キャッシュ１１３５が満杯であり、ＳＣＰＩ１１０５にストアバッファ１１４０更新を行えない場合に開始されてもよい。しかし、アボート（アトミック領域全体のロールバック）が生じると、ストアバッファ１１４０と投機的なキャッシュ１１３５の両方が（アトミック領域から現在の実行点までの更新）フラッシュされる。

【0134】

ここで利用するモジュールとは、ハードウェア、ソフトウェア、またはこれらの組み合わせのことであってよい。別個に描かれているモジュールのデマケーションは共通変化して、潜在的に重なっている。例えば第１モジュールおよび第２モジュールが、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを含み、一方で、独立したハードウェア、ソフトウェア、ファームウェアを維持してもよい。一実施形態では、論理という用語の利用には、トランジスタ、レジスタ、その他のハードウェア（プログラム可能論理デバイス）等のハードウェアが含まれる。しかし別の実施形態では、論理に、ソフトウェアまたはハードウェアと集積されたコード（例えばファームウェアまたはマイクロコード）が含まれる。

【0135】

ここで利用する値とは、数、状態、論理状態、またはバイナリ論理状態の公知の表現形態を含む。論理レベル、論理値、または論理値は、１および０で表されることが多く、単にバイナリ論理状態を表している。例えば１は高論理状態を表し、０は低論理状態を表す。一実施形態では、格納セル（例えばトランジスタまたはフラッシュセル）は、１つの論理値または複数の論理値を保持することができてよい。しかしコンピュータシステムにおける他の値の表現形態をとってもよい。例えば１０進法の数は１０１０のバイナリ値、または１６進法の文字Ａで表すことができる。従って値は、コンピュータシステムでの保持が可能な情報の任意の表現形態を含む。

【0136】

さらに、状態は値または値の部分で表すことができる。一例としては、第１の値（例えば論理１）が、初期値または最初の状態を表してよく、第２の値（例えば論理０）が、初期値ではない値を表してよい。加えて、リセットおよびセットという用語は、一実施形態では、初期値または更新値または状態と称される。例えば初期値は潜在的に高い論理値（つまりリセット）を含んでよく、一方で、更新値は、潜在的に低い論理値（つまりセット）を含んでよい。値の任意の組み合わせを利用することで任意の数の状態を表すことができる。

【0137】

上述した方法、ハードウェア、ソフトウェア、ファームウェア、またはコード処理エレメントが事項可能な機械アクセス可能または機械可読媒体に格納される命令またはコードを介して実装可能であってよい。機械アクセス可能／可読媒体は、機械（例えばコンピュータまたは電子システム）が可読な形態の情報を提供する（格納する、および／または、送信する）。例えば、機械アクセス可能媒体は、ランダムアクセスメモリ（静的ＲＡＭ（ＳＲＡＭ）または動的ＲＡＭ（ＤＲＡＭ）、ＲＯＭ、磁気または光格納媒体、フラッシュメモリデバイス、電気格納デバイス、光格納デバイス、音響格納デバイス、その他の形態の、伝播信号（例えば搬送波、赤外線信号、デジタル信号等）を保持するための格納デバイスであってよい）。

【0138】

本明細書全体で、「一実施形態」「１つの実施形態」といった言い回しは、その実施形態との関連で記載されている特定の特徴、構造、または特性が、本発明に含まれる少なくとも１つの実装例に含まれることを意味している。従って、「一実施形態」「１つの実施形態」という言い回しが使われていても、これらが必ずしも同じ実施形態のことを言及しているわけではない。さらに、特定の特徴、構造、または特性は、記載された特定の実施形態以外の適切な形態で実装することもでき、これら全ての形態が本願の請求項の範囲に含まれることが意図されている。

【0139】

前述の明細書では、詳細な説明が特定の実施形態を参照していた。しかし、本発明の広義の精神および範囲から逸脱せずに、添付請求項に示すようなさまざまな変形例および変更例が可能であることは明らかである。従い明細書および図面は、限定的な意味ではなく例示的な意味で捉えられるべきである。さらに、前述した実施形態および例は、必ずしも同じ実施形態または同じ例のことばかりではなく、異なる別の実施形態のことを指している場合もあり、同じ実施形態である場合もある。

【図1】

【図2a】

【図2b】

【図3a】

【図3b】

【図4】

【図5】

【図6】

【図7a】

【図7b】

【図8】

【図9】

【図10】

【図11】