JP2017526059A - 複数の変換テーブルを用いた命令セットアグノスティックランタイムアーキテクチャの実施 - Google Patents

Abstract

アグノスティックランタイムアーキテクチャのためのシステムアーキテクチャが開示される。本システムは、システムエミュレーション／仮想化変換器と、アプリケーションコード変換器と、システム変換器とを備え、システムエミュレーション／仮想化変換器及びアプリケーションコード変換器がシステムエミュレーションプロセスを実施し、システム変換器が、ゲストイメージからのコードを実行するためにシステム変換プロセスを実施する。システム変換器は、複数のゲスト命令にアクセスするためのゲストフェッチロジック構成部と、ゲストフェッチロジック構成部及び分岐予測構成部に結合され、複数のゲスト命令をアセンブルしてゲスト命令ブロックにするためのゲストフェッチバッファと、ゲストフェッチバッファに結合された第１のレベルの変換テーブル及び第２のレベルの変換テーブルを含み、ゲスト命令ブロックを対応するネイティブ変換ブロックに変換するための複数の変換テーブルとを備える。本システムは、変換テーブルに結合され、対応するネイティブ変換ブロックを記憶するためのネイティブキャッシュと、ネイティブキャッシュに結合され、ゲスト命令ブロックと、対応するネイティブ変換ブロックとのマッピングを記憶するための変換ルックアサイドバッファとを更に備える。ゲスト命令の後続の要求時に、変換ルックアサイドバッファは、ヒットが生じたか否かを判断するようにインデックス付けされ、マッピングは、ゲスト命令がネイティブキャッシュ内に対応する変換されたネイティブ命令を有することを示し、ヒットに応答して、変換ルックアサイドバッファは、変換されたネイティブ命令を実行のために転送する。【選択図】 図９

Description

発明の分野

[001]本発明は、一般に、デジタルコンピューターシステムに関し、より詳細には、命令シーケンスを含む命令を選択するためのシステム及び方法に関する。本出願は、２０１４年７月２５日に出願された、Mohammad A. Abdallahによる、「A RUNTIME ARCHITECTURE FOR EFFICIENTLY OPTIMIZING AND EXECUTING GUEST CODE AND CONVERTING TO NATIVE CODE」と題する、本発明の譲受人に譲渡された同時継続中の米国仮特許出願第６２／０２９３８３号の利益を主張する。この米国仮特許出願は全体が本明細書に援用される。

発明の背景

[002]プロセッサは、依存型又は完全に独立型の複数のタスクを処理することを要求される。そのようなプロセッサの内部状態は通例、プログラム実行の各特定の時点に異なる値を保持し得るレジスタからなる。プログラム実行の各時点において、内部状態イメージは、プロセッサのアーキテクチャ状態と呼ばれる。

[003]コード実行が別の機能（例えば、別のスレッド、プロセス又はプログラム）を実行するように切り替えられるとき、新たな機能が内部レジスタを利用して新たな状態を構築することができるように、マシン／プロセッサの状態を保存しなくてはならない。新たな機能が終了すると、その状態は破棄され、前のコンテキストの状態が復元され、実行が再開する。そのような切り替えプロセスは、コンテキスト切り替え（context switch、コンテキストスイッチ）と呼ばれ、通例、特に、多数のレジスタ（例えば、６４個、１２８個、２５６個）及び／又はアウトオブオーダ実行（out of order execution）を利用する最新のアーキテクチャを用いて、数十又は数百サイクルを含む。

[004]スレッドアウェア（thread-aware）ハードウェアアーキテクチャにおいて、ハードウェアが、ハードウェアによりサポートされた限られた数のスレッドのための複数のコンテキスト状態をサポートすることは一般的である。この場合、ハードウェアは、サポートされるスレッドごとに全てのアーキテクチャ状態要素を複製する。これによって、新たなスレッドを実行するときのコンテキスト切り替えの必要性がなくなる。一方、これは依然として、複数の欠点を有し、すなわち、ハードウェアにおいてサポートされる追加のスレッドごとに全てのアーキテクチャ状態要素（すなわち、レジスタ）を複製するエリア、電力及び複雑性を有する。更に、ソフトウェアスレッド数が明示的にサポートされるハードウェアスレッド数を超えた場合には、依然としてコンテキスト切り替えを実行しなくてはならない。

[005]これは、多数のスレッドを要する細かい粒度で並列処理が必要とされるので、一般的となる。複製コンテキスト状態ハードウェアストレージを有するハードウェアスレッドアウェアアーキテクチャは、スレッド化されていないソフトウェアコードには役立たず、スレッド化されたソフトウェアのためのコンテキスト切り替え数を低減するのみである。一方、これらのスレッドは、通例、粗い粒度の並列処理のために構築され、結果として、開始及び同期のための大幅なソフトウェアオーバーヘッドが生じ、効率的なスレッド化の開始／自動生成を行うことなく、関数の呼び出し及びループの並列実行等の、細かい粒度の並列処理が残される。そのような上記のオーバーヘッドに加えて、そのようなコードの自動並列化は、非明示的に／容易に並列化／スレッド化されたソフトウェアコードのための最先端のコンパイラ又はユーザ並列化技法を用いても困難である。

[006]１つの実施形態において、本発明は、アグノスティックランタイムアーキテクチャ（agnostic runtime architecture）のためのシステムとして実施される。システムは、システムエミュレーション／仮想化変換器と、アプリケーションコード変換器と、システム変換器とを備え、システムエミュレーション／仮想化変換器及びアプリケーションコード変換器がシステムエミュレーションプロセスを実施し、システム変換器が、ゲストイメージからのコードを実行するためにシステム変換プロセスを実施する。システム変換器は、複数のゲスト命令にアクセスするためのゲストフェッチロジック構成部と、ゲストフェッチロジック構成部及び分岐予測構成部に結合され、複数のゲスト命令をアセンブルしてゲスト命令ブロックにするためのゲストフェッチバッファと、ゲストフェッチバッファに結合された第１のレベルの変換テーブル及び第２のレベルの変換テーブルを含み、ゲスト命令ブロックを対応するネイティブ変換ブロックに変換するための複数の変換テーブルとを備える。

[007]本システムは、変換テーブルに結合され、対応するネイティブ変換ブロックを記憶するためのネイティブキャッシュと、ネイティブキャッシュに結合され、ゲスト命令ブロックと、対応するネイティブ変換ブロックとのマッピングを記憶するための変換ルックアサイドバッファとを更に備える。ゲスト命令の後続の要求時に、変換ルックアサイドバッファは、ヒットが生じたか否かを判断するようにインデックス付けされ、マッピングは、ゲスト命令がネイティブキャッシュ内に対応する変換されたネイティブ命令を有することを示し、ヒットに応答して、変換ルックアサイドバッファは、変換されたネイティブ命令を実行のために転送する。

[008]実施形態は要約であり、このため、必然的に、詳細の単純化、一般化及び省略を含む。結果として、当業者は、要約が単なる例示であり、いかなる形においても限定を意図していないことを理解するであろう。特許請求の範囲によってのみ定義されるような本発明の他の態様、発明的特徴及び利点は、以下に示される非限定的な詳細な説明において明らかとなるであろう。

[009]本発明は、添付の図面の図において限定ではなく例として説明されており、同様の参照符号は類似した要素を指す。

本発明の１つの実施形態による、アーキテクチャアグノスティックランタイムシステムの概略図を示す。 本発明の１つの実施形態による、ハードウェアアクセラレーションされた（hardware accelerated）変換／ＪＩＴレイヤを描く図を示す。 本発明の１つの実施形態による、ハードウェアアクセラレーションされたランタイム変換／ＪＩＴレイヤのより詳細な図を示す。 本発明の１つの実施形態によるシステムエミュレーション及びシステム変換を実装する構成部を描く図を示す。 本発明の１つの実施形態によるゲストフラグアーキテクチャエミュレーションを描く図を示す。 本発明の１つの実施形態による統合されたレジスタファイルの図を示す。 本発明の１つの実施形態による、投機的（speculative、スペキュラティブ）アーキテクチャ状態及び過渡的（transient、トランジェント）アーキテクチャ状態をサポートする統合されたシャドーレジスタファイル及びパイプラインアーキテクチャの図を示す。 本発明の１つの実施形態による、ランアヘッドバッチ（run ahead batch）／変換プロセスを描く図を示す。 本発明の１つの実施形態による、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがキャッシュ内に記憶される方式を示す、例示的なハードウェアアクセラレーションされた変換システムの図を示す。 本発明の１つの実施形態による、ハードウェアアクセラレーションされた変換システムのより詳細な例を示す。 本発明の１つの実施形態による、二重スコープの使用を含む第２の使用モデルの図を示す。 本発明の１つの実施形態による、トランジェントコンテキスト（transient context）から戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第３の使用モデルの図を示す。 本発明の１つの実施形態による、命令シーケンスにおける例外が、後続のコードの変換が必要とされることに起因する事例を描く図である。 本発明の１つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第４の使用モデルの図を示す。 本発明の１つの実施形態による、分岐の前の最適化されたスケジューリング命令を例示する図を示す。 本発明の１つの実施形態による、ストアの前のロードの最適化されたスケジューリングを例示する図を示す。 本発明の１つの実施形態による、ストアフィルタリングアルゴリズムの図を示す。 本発明の１つの実施形態による、インオーダでのメモリからのロードの読出しを構成するメモリ一貫性モデルにおける、アウトオブオーダのロードを用いたセマフォ（semaphore）の実施を示す。 本発明の１つの実施形態による、ＪＩＴ最適化を通じた順序変更プロセス（reordering process、リオーダリングプロセス）の図を示す。 本発明の１つの実施形態による、ＪＩＴ最適化を通じたリオーダリングプロセスの図を示す。 本発明の１つの実施形態による、ＪＩＴ最適化を通じたリオーダリングプロセスの図を示す。 本発明の１つの実施形態による、ＪＩＴ最適化を通じてストアの前に順序変更（reorder、リオーダ）されるロードを例示する図を示す。 本発明の１つの実施形態による、ロード及びストア命令分割の第１の図を示す。 本発明の１つの実施形態による、メモリ内に記憶されたネイティブ命令マッピングに対するコードキャッシュ及びゲスト命令と併せてＣＬＢがどのように機能するかを示す例示的な流れ図を示す。 本発明の１つの実施形態による、ランアヘッドランタイムゲスト命令の変換／デコード（conversion/decoding）プロセスの図を示す。 本発明の１つの実施形態による、ゲスト命令シーケンスを有する変換テーブルと、ネイティブ命令マッピングを有するネイティブマッピングテーブルとを描く図を示す。

発明の詳細な説明

[001]本発明は、１つの実施形態に関連して説明されたが、本発明は、本明細書において示される特定の形態に限定されることを意図するものではない。対照的に、添付の特許請求の範囲によって規定される本発明の範囲内に妥当に含めることができるような代替形態、変更形態及び等価物を包含することが意図される。

[002]以下の詳細な説明において、特定の方法の順序、構造、要素及び接続等の多数の特定の詳細が示された。一方、これらの特定の詳細及び他の特定の詳細は、本発明の実施形態を実施するように利用される必要がないことが理解される。他の状況では、この説明を不要に曖昧にすることを回避するために、既知の構造、要素又は接続は、省略されているか又は詳細に説明されていない。

[003]本明細書において「１つの実施形態」又は「一実施形態」に言及する場合、それは、その実施形態に関連して記載された特定の特徴、構造又は特性が、本発明の少なくとも１つの実施態様に含まれることを示すように意図される。本明細書の様々な場所における「１つの実施形態」という語句の出現は、必ずしも全てが同じ実施形態を指すとは限らず、他の実施形態に対し相互に排他的な別個の実施形態又は代替的な実施形態でもない。更に、様々な特徴が説明されるが、それらは、いくつかの実施形態に示され、他の実施形態には示されない場合がある。同様に、いくつかの実施形態の要件であるが他の実施形態の要件ではない場合がある様々な要件が説明される。

[004]以下に続く詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビットに対する動作の、プロシージャ、ステップ、論理ブロック、処理及び他の記号表現に関して記述される。これらの記述及び表現は、データ処理技術分野における当業者の研究内容をその他の当業者に最も効率的に伝達するためにそれらの当業者によって使用される手段である。プロシージャ、コンピュータ実行ステップ、論理ブロック、プロセス等は、ここでは、一般的に、所望の結果を得るためのステップ又は命令の自己矛盾のないシーケンスであると考えられる。ステップとは、物理量を物理的に操作することを必要とするもののことである。必ずしもそうではないが、通例、これらの量は、コンピュータシステムにおいて記憶され、転送され、組み合わせられ、比較され、他の形で操作されることが可能なコンピュータ可読ストレージ媒体の電気信号又は磁気信号の形態をとる。一般的に使用されるという主たる理由から、これらの信号を、ビット、値、要素、シンボル、文字、項、数値等と呼ぶことが場合によっては都合がよいことが知られている。

[005]しかしながら、これらの及び類似する用語の全ては、適切な物理量に関連付けられかつそれらの量に付された単なる都合のよいラベルであることを念頭におくべきである。以下の論考から明らかなように、特に明記しない限り、本発明の全体を通して、「処理する」又は「アクセスする」又は「書き込む」又は「記憶する」又は「複製する」等の用語を用いた論考は、コンピュータシステムのレジスタ及びメモリ並びに他のコンピュータ可読媒体内において物理的な（電子的な）量として表現されたデータを操作してコンピュータシステムのメモリ若しくはレジスタ又は他のそのような情報記憶装置、情報伝送装置又は情報表示装置内において物理量として同様に表現される他のデータに変換するコンピュータシステム又はそれに類似する電子的コンピューティング装置のアクション及び処理を指すことがわかる。

[006]本発明の実施形態は、汎用アグノスティックランタイムシステムの実施を対象とする。本明細書において用いられるとき、本発明の実施形態は、「ＶＩＳＣ ＩＳＡアグノスティックランタイムアーキテクチャ」とも呼ばれる。以下の詳細な説明の図１〜図３０は、汎用アグノスティックランタイムシステムを実施するのに用いられるメカニズムプロセス及びシステムを示す。

[007]本発明の実施形態は、ソフトウェア産業における傾向、すなわち、新たなシステムソフトウェアが、ランタイムコンパイル、最適化及び実行をますます目指す傾向を利用することを対象とする。より従来的な古いソフトウェアシステムは、静的コンパイルに適している。

[008]本発明の実施形態は、有利には、ランタイム操作に向かう傾向を有する新たなシステムソフトウェアを対象とする。例えば、初期に普及していたのはＪａｖａ仮想マシンランタイム実装である。しかし、これらの実装には、ネイティブ実行よりも４倍〜５倍低速であるという不利な点がある。最近では、実装は、Ｊａｖａ仮想マシンの実装に加えて、ネイティブコードのカプセル化（例えば、２倍〜３倍低速）を対象としている。更に最近では、実装はＣｈｒｏｍｅ及び低レベルの仮想マシンランタイム実装（例えば、ネイティブの２倍低速）を対象としている。

[009]本発明の実施形態は、拡張ランタイムサポートを有し、用いるアーキテクチャを実装する。本発明の実施形態は、ゲストコード（例えば、ランタイムゲストコードを含む）を効率的に実行する機能を有する。本発明の実施形態は、ゲスト／ランタイム命令をネイティブ命令に効率的に変換することができる。本発明の実施形態は、変換されたゲスト／ランタイムコードをネイティブコードに効率的にマッピングすることができるようになる。更に、本発明の実施形態は、ゲストコード又はネイティブコードをランタイムにおいて効率的に最適化することができるようになる。

[010]これらの能力は、本発明の実施形態が、アーキテクチャアグノスティックランタイムシステムの時代に十分適したものとなることを可能にする。本発明の実施形態は、レガシーアプリケーションコードを実行する能力を有して完全にポータブルとなり、そのようなコードは、他のアーキテクチャにおけるよりも２倍以上高速に実行されるように最適化することができる。

[011]図１は、本発明の１つの実施形態によるアーキテクチャアグノスティックのランタイムシステムの概略図を示す。図１は、仮想マシンランタイムＪＩＴ（例えば、実行時コンパイラ）を示す。仮想マシンランタイムＪＩＴは、示されるようなＪａｖａのようなバイトコード、低レベルの内部表現コード及び仮想マシンＪＩＴを含む。仮想マシンＪＩＴは、低レベルの内部表現コード及びＪａｖａのようなバイトコードの双方を処理する。仮想マシンＪＩＴの出力は、示すようなＩＳＡ固有のコードである。

[012]Ｊａｖａコードは、マシンと独立している。プログラマは１つのプログラムを書くことができ、このプログラムは多くの異なるマシン上で実行されるべきである。Ｊａｖａ仮想マシンは、ＩＳＡ固有であり、各マシンアーキテクチャは、独自のマシン固有の仮想マシンを有する。仮想マシンの出力は、ランタイムにおいて動的に生成されるＩＳＡ固有のコードである。

[013]図１は、プロセッサに密に結合されたハードウェアアクセラレーションされた変換／ＪＩＴレイヤも示す。ランタイムＪＩＴ／変換レイヤは、プロセッサが、仮想マシンＪＩＴによって処理される必要がない処理されたｊａｖａバイトコードを用いることを可能にし、以て、コード性能を大幅に加速する。ランタイムＪＩＴ／変換レイヤは、プロセッサが、仮想マシン／ＪＩＴによって処理される必要がないｊａｖａバイトコード（例えば、仮想マシンランタイムＪＩＴ内に示される）の低レベルの内部表現を用いることも可能にする。

[014]図１は、静的バイナリ実行コードを生成するオフラインコンパイラ（例えば、ｘ８６、ＡＲＭ等）によって処理されるＣ＋＋コード（例えば、その類似物）も示す。Ｃ＋＋は、マシンと独立したプログラミング言語である。コンパイラは、マシン固有である（例えば、ｘ８６、ＡＲＭ等）。プログラムは、マシン固有コンパイラを用いてオフラインでコンパイルされ、以て、マシン固有の静的バイナリコードが生成される。

[015]図１は、ＩＳＡ固有のコードが従来のプロセッサにおいて従来のオペレーティングシステムによってどのように実行されるかを示す一方で、（例えば、低レベルの内部表現からの）ポータブルコード、（例えば、仮想マシンランタイムＪＩＴからの）前処理されたＪａｖａのようなバイトコード、及び（例えば、コンパイラからの）静的バイナリ実行可能コードの双方を、全て、ハードウェアアクセラレーションされた変換／ＪＩＴレイヤ及びプロセッサを介して処理することができるかを有利に示す。

[016]ハードウェアアクセラレーションされた変換／ＪＩＴレイヤは、本発明の実施形態の利点を達成するための主要なメカニズムであることが留意されるべきである。以下の図は、ハードウェアアクセラレーションされた変換／ＪＩＴレイヤの動作方式を示す。

[017]図２は、本発明１つの実施形態による、ハードウェアアクセラレーションされた変換／ＪＩＴレイヤを描く図を示す。図２は、仮想マシン／高レベルランタイム／ロードタイムＪＩＴが、仮想マシン高レベル命令表現、低レベル仮想マシン命令表現、及びゲストコードアプリケーション命令をどのように生成するかを示す。これらの全てが、ランタイム／ロードタイムのゲスト／仮想マシン命令表現対ネイティブ命令表現のマッピングのためのプロセスに供給される。そしてこれは、示されるハードウェアアクセラレーションされた変換／ＪＩＴレイヤに渡され、このレイヤにおいて、ランタイムネイティブ命令表現対命令アセンブリ構成部によって処理され、次にコードキャッシュ割振り及びメタデータ作成のためのハードウェア／ソフトウェアによる動的シーケンスに基づくブロック構築／マッピング構成部に渡される。図２において、ハードウェアアクセラレーションされた変換／ＪＩＴレイヤは、動的に変換されたシーケンスを記憶するためのシーケンスキャッシュを有するプロセッサに結合されて示される。また、図２は、ネイティブコードがランタイムネイティブ命令シーケンス形成構成部によってどのように直接処理することができるかも示す。ランタイムネイティブ命令シーケンス形成構成部は、結果として得られた出力を、コードキャッシュ割振り及びメタデータ作成のためのハードウェア／ソフトウェアによる動的シーケンスに基づくブロック構築／マッピング構成部に送る。

[018]図３は、本発明の１つの実施形態によるハードウェアアクセラレーションされたランタイム変換／ＪＩＴレイヤのより詳細な図である。図３は、ハードウェアアクセラレーションされたランタイム変換／ＪＩＴレイヤが、システムエミュレーション及びシステム変換を容易にするハードウェア構成部をどのように含むかを示す。分散化したフラグサポート、ＣＬＢ／ＣＬＢＶ等のこれらの構成要素部は、システムエミュレーション及びシステム変換の双方をサポートして機能するカスタマイズされたハードウェアを含む。これらは、ランタイムソフトウェアを、従来のプロセッサの５倍以上の速度で実行させる。システムエミュレーション及びシステム変換が以下で論考される。

[019]図４は、本発明の１つの実施形態によるシステムエミュレーション及びシステム変換を実施するための構成部を描く図を示す。図４はまた、アプリケーションコード及びＯＳ／システム固有のコードの双方を有するイメージも示す。

[020]本発明の実施形態は、アプリケーションコード及びＯＳ／システム固有のコードを実行するためにシステムエミュレーション及びシステム変換を用いる。システムエミュレーションを用いて、マシンは、ハードウェアがサポートするアーキテクチャと異なるゲストシステムアーキテクチャ（システム及びアプリケーションコードの双方を含む）をエミュレート／仮想化している。エミュレーションは、（例えば、システムコードを扱う）システムエミュレーション／仮想化変換器、及び（例えば、アプリケーションコードを扱う）アプリケーションコード変換器によって提供される。アプリケーションコード変換器は、ベアメタル構成部と共に描かれて示されていることに留意されたい。

[021]システム変換を用いて、マシンは、ゲストアーキテクチャと、ハードウェアがサポートするアーキテクチャとの間の類似したシステムアーキテクチャ特性を有するが、アーキテクチャの非システム部分が異なるコード（すなわち、アプリケーション命令）を変換している。システム変換器は、ゲストアプリケーション変換器構成部及びベアメタル構成部を含んで示されている。システム変換器は、マルチパス最適化プロセスを潜在的に実装するものとしても示されている。システム変換及びエミュレーションという用語に言及することによって、本明細書における後続の説明は、図４に示すようなシステムエミュレーションパス又はシステム変換パスのいずれかを用いることができるプロセスを指していることに留意するべきである。

[022]以下の図５〜図２６は、汎用アグノスティックランタイムシステム／ＶＩＳＣ ＩＳＡアグノスティックランタイムアーキテクチャをサポートするためのシステムエミュレーション及びシステム変換の双方を実施するのに用いられる様々なプロセス及びシステムを示す。以下の図におけるプロセス及びシステムでは、ハードウェア／ソフトウェアアクセラレーションがランタイムコードに提供され、そしてこのランタイムコードはアーキテクチャの増大した性能を提供する。そのようなハードウェアアクセラレーションは、分散したフラグ、ＣＬＢ、ＣＬＢＶ、ハードウェアゲスト変換テーブル等のためのサポートを含む。

[023]図５は、本発明の１つの実施形態によるゲストフラグアーキテクチャエミュレーションを描く図を示す。図５の左側は、５つのフラグを有する集中型のフラグレジスタを示す。図５の右側は、レジスタ自体の間でフラグが分散した、分散型のフラグレジスタを有する分散型のフラグアーキテクチャを示す。

[024]アーキテクチャエミュレーション（例えば、システムエミュレーション又は変換）中、分散型フラグアーキテクチャが、集中型のゲストフラグアーキテクチャの挙動をエミュレートすることが必要である。分散型のフラグアーキテクチャは、データレジスタに関連付けられたフラグフィールドと対照的に複数の独立したフラグレジスタを用いることによって実施することもできる。例えば、データレジスタは、Ｒ０〜Ｒ１５として実施することができるのに対し、独立フラグレジスタは、Ｆ０〜Ｆ１５として実施することができる。これらのフラグレジスタは、この場合、必ずしもデータレジスタと直接関連付けられない。

[025]図６は、本発明の１つの実施形態による、統合されたレジスタファイル１２０１の図を示す。図５に示されるように、統合されたレジスタファイル１２０１は、２つの部分１２０２〜１２０３及びエントリセレクタ１２０５を含む。統合されたレジスタフェイス１２０１は、ハードウェア状態アップデートのためのアーキテクチャスペキュレーションのためのサポートを実施する。

[026]統合されたレジスタファイル１２０１は、最適化されたシャドーレジスタ及びコミットされたレジスタ状態管理プロセスの実装を可能にする。このプロセスは、ハードウェア状態更新のためのアーキテクチャ投機をサポートする。このプロセスの下で、本発明の実施形態は、レジスタメモリ間のクロスコピーを必要とすることなく、シャドーレジスタ機能及びコミットされたレジスタ機能をサポートすることができる。例えば、１つの実施形態では、統合されたレジスタファイル１２０１の機能は、大部分がエントリセレクタ１２０５によって提供される。図５の実施形態では、各レジスタファイルエントリは、２対のレジスタＲ及びＲ’から構成され、それらはそれぞれ、部分１及び部分２からのものである。任意の所与の時点において、各エントリから読み出されるレジスタは、部分１又は部分２からのＲ又はＲ’のいずれかである。エントリセレクタ１２０５によって各エントリについて記憶されるｘ及びｙビットの値に基づいてレジスタファイルの各エントリの４つの異なる組み合わせが存在する。

[027]図７は、本発明の１つの実施形態による、投機的アーキテクチャ状態及びトランジェントアーキテクチャ状態をサポートする統合されたシャドーレジスタファイル及びパイプラインアーキテクチャ１３００の図を示す。

[028]図７の実施形態は、アーキテクチャ投機状態を含む命令及び結果をサポートし、トランジェント状態を含む命令及び結果をサポートするアーキテクチャ１３００を含む構成部を描いている。本明細書において用いられるとき、コミットされるアーキテクチャ状態は、コンピュータ上で実行されるプログラムによってアクセス（例えば、読出し及び書込み）することができる可視レジスタ及び可視メモリを含む。対照的に、投機的アーキテクチャの状態は、コミットされないレジスタ及び／又はメモリを含み、したがって、全体的に可視でない。

[029]１つの実施形態では、アーキテクチャ１３００によって有効にされる４つの使用モデルが存在する。第１の使用モデルは、ハードウェア状態アップデートのためのアーキテクチャ投資を含む。

[030]第２の使用モデルは、二重スコープの使用を含む。この使用モデルは、プロセッサ内への２つのスレッドのフェッチに適用される。ここで、一方のスレッドは、投機的状態において実行し、他方のスレッドは、非投機的状態において実行する。この使用モデルでは、双方のスコープがマシン内にフェッチされ、同時にマシン内に存在する。

[031]第３の使用モデルは、１つの形態から別の形態への命令のＪＩＴ（実行時、just-in-time）変換又はコンパイルを含む。この使用モデルでは、アーキテクチャ状態のリオーダは、ソフトウェア、例えば、ＪＩＴにより達成される。第３の使用モデルは、例えば、ゲスト対ネイティブ命令変換、仮想マシン対ネイティブ命令変換、又はネイティブマイクロ命令の、より最適化されたネイティブマイクロ命令への再マッピング／変換に適用することができる。

[032]第４の使用モデルは、トランジェントコンテキストから返されるときに以前のコンテキストを保存及び復元する必要のない、トランジェントコンテキスト切り替えを含む。この使用モデルは、複数の理由で生じる場合があるコンテキスト切り替えに適用される。１つのそのような理由は、例えば、例外処理コンテキストによる例外の正確な処理であり得る。

[033]再び図７を参照すると、アーキテクチャ１３００は、上記で説明した４つの使用モデルを実施するための複数の構成部を含む。統合されたシャドーレジスタファイル１３０１は、第１の部分である、コミットされたレジスタファイル１３０２と、第２の部分である、シャドーレジスタファイル１３０３と、第３の部分である、最新のインジケータアレイ１３０４とを含む。投機的リタイアメントメモリバッファ１３４２及び最新のインジケータアレイ１３４０が含まれる。アーキテクチャ１３００は、アウトオブオーダアーキテクチャを含み、このため、アーキテクチャ１３００は、リオーダバッファ及びリタイアメントウィンドウ１３３２を更に含む。リオーダ及びリタイアメントウィンドウ１３３２は、マシンリタイアメントポインタ１３３１、レディビットアレイ１３３４、及びインジケータ１３３３等の命令ごとの最新インジケータを更に含む。

[034]本明細書の１つの実施形態による、第１の使用モデル、すなわち、ハードウェア状態アップデートのためのアーキテクチャ投機が詳細に更に説明される。上記で説明したように、アーキテクチャ１３００は、アウトオブオーダアーキテクチャを含む。アーキテクチャ１３００のハードウェアは、アウトオブオーダ命令結果（例えば、アウトオブオーダロード及びアウトオブオーダストア及びアウトオブオーダレジスタアップデート）をコミットすることができる。アーキテクチャ１３００は、統合されたシャドーレジスタファイルを利用して、コミットされたレジスタとシャドーレジスタとの間の投機的実行をサポートする。更に、アーキテクチャ１３００は、投機的ロードストアバッファ１３２０及び投機的リタイアメントメモリバッファ１３４２を利用して、投機的実行をサポートする。

[035]アーキテクチャ１３００は、これらの構成部を、リオーダバッファ及びリタイアメントウィンドウ１３３２と併せて使用して、マシンが統合されたシャドーレジスタファイル及びリタイアメントメモリバッファの内部にアウトオブオーダ方式でこれらをリタイアした場合であっても、その状態が、コミットされたレジスタファイル１３０２及び可視メモリ１３５０に正しくリタイアすることを可能にする。例えば、アーキテクチャは、統合されたシャドーレジスタファイル１３０１及び投機的メモリ１３４２を用いてロールバックを実施し、例外が生じるか又は生じないかに基づいてイベントをコミットする。この機能は、レジスタ状態が、統合されたシャドーレジスタファイル１３０１にアウトオブオーダでリタイアすることを可能にし、投機的リタイアメントメモリバッファ１３４２が可視メモリ１３５０にアウトオブオーダでリタイアすることを可能にする。投機的実行が進行し、アウトオブオーダ命令実行が進行するとき、分岐が予測ミスされず、かつ例外が生じない場合、マシンリタイアメントポインタ１３３１は、コミットイベントがトリガされるまで進む。コミットイベントは、統合されたシャドーレジスタファイルに、そのコミットポイントを進めることによってそのコンテンツをコミットさせ、マシンリタイアメントポインタ１３３１に従って、投機的リタイアメントメモリバッファに、そのコンテンツをメモリ１３５０に対しコミットさせる。

[036]例えば、リオーダバッファ及びリタイアメントウィンドウ１３３２内に示される命令１〜７を検討すると、レディビットアレイ１３３４は、実行の準備ができている命令の隣に「Ｘ」を示し、実行の準備ができていない命令の隣に「／」を示す。したがって、命令１、２、４及び６は、アウトオブオーダで進むことを許可される。その後、命令６の分岐が予測ミスされる等の例外が生じる場合、命令６の後に行う命令をロールバックすることができる。代替的に、例外が生じない場合、マシンリタイアメントポインタ１３３１をその都度移すことによって命令１〜７の全てをコミットすることができる。

[037]最新のインジケータアレイ１３４１、最新のインジケータアレイ１３０４及び最新のインジケータ１３３３は、アウトオブオーダ実行を可能にするために用いられる。例えば、命令２が命令５の前にレジスタＲ４をロードするにもかかわらず、命令５を行う準備ができると、命令２からのロードは無視される。最新のロードは、最新のインジケータに従って以前のロードを上書きする。

[038]リオーダバッファ及びリタイアメントウィンドウ１３３２内で分岐予測又は例外が生じる場合、ロールバックイベントがトリガされる。上記で説明したように、ロールバックの場合、統合されたシャドーレジスタファイル１３０１は、最新のコミットされたポイントまでロールバックし、投機的リタイアメントメモリバッファ１３４２がフラッシュされることになる。

[039]図８は、本発明の１つの実施形態によるランアヘッドバッチ／変換プロセスを描く図を示す。この図は、ゲストコードが変換プロセスをどのように経てネイティブコードに変換されるかを示す。そして、このネイティブコードは、ネイティブコードキャッシュをポピュレート（populate）し、このネイティブコードキャッシュが、ＣＬＢをポピュレートするのに更に用いられる。図面は、ゲストコードが、以前に変換されていないアドレス（例えば、５０００）にどのようにジャンプするかを示す。次に、変換プロセスは、このゲストコードを変更して、示すような（例えば、ゲスト分岐８０００及び推測分岐６０００を含む）対応するネイティブコードにする。推測分岐は、コードキャッシュにおけるネイティブ分岐に変換される（例えば、ネイティブ分岐ｇ８０００及びネイティブ分岐ｇ６０００）。マシンは、ネイティブ分岐のためのプログラムカウンタが、推測分岐のためのプログラムカウンタと異なることになることを認識する。これは、ネイティブコードキャッシュ（例えば、Ｘ、Ｙ及びＺ）における表記によって示される。これらの変換が完了すると、結果として得られた変換が更なる使用のためにＣＬＢに記憶される。この機能は、ネイティブコードへのゲストコードの変換を大幅に加速する。

[040]図９は、本発明の１つの実施形態による、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがキャッシュ内にどのように記憶されるかを示す例示的なハードウェアアクセラレーションされた変換システム５００の図を示す。図９に示すように、変換ルックアサイドバッファ５０６を用いて、ゲストブロックとネイティブブロックとの間のアドレスマッピングをキャッシングし、それによって、最も頻繁に遭遇するネイティブ変換ブロックが、プロセッサ５０８に低レイテンシの可用性でアクセスされるようにする。

[041]図９は、頻繁に遭遇するネイティブ変換ブロックが、高速低レイテンシキャッシュ、変換ルックアサイドバッファ５０６内でどのように維持されるかを示す。図９に示される構成部は、はるかに高レベルの性能を送達するためのハードウェアアクセラレーションされた変換処理を実施する。

[042]ゲストフェッチロジック装置部（guest fetch logic unit、ゲストフェッチロジックユニット）５０２は、システムメモリ５０１からゲスト命令をフェッチするハードウェアベースのゲスト命令フェッチユニットとして機能する。所与のアプリケーションのゲスト命令は、システムメモリ５０１内に存在している。プログラムの始動時に、ハードウェアベースのゲストフェッチロジックユニット５０２は、ゲストフェッチバッファ５０３への推測命令のプリフェッチを開始する。ゲストフェッチバッファ５０７は、ゲスト命令を蓄積し、これらをアセンブル（assemble）してゲスト命令ブロックにする。ゲスト命令ブロックは、変換テーブル５０４を用いることによって対応するネイティブ変換ブロックに変換される。変換されたネイティブ命令は、ネイティブ変換ブロックが完了するまで、ネイティブ変換バッファ５０５内で蓄積される。次に、ネイティブ変換ブロックはネイティブキャッシュ５０７に転送され、マッピングが変換ルックアサイドバッファ５０６に記憶される。次に、ネイティブキャッシュ５０７を用いて、ネイティブ命令を実行のためにプロセッサ５０８に供給する。１つの実施形態において、ゲストフェッチロジックユニット５０２によって実施される機能は、ゲストフェッチロジック状態マシンによって生成される。

[043]このプロセスが継続すると、変換ルックアサイドバッファ５０６は、ネイティブブロックへのゲストブロックのアドレスマッピングで満たされる。変換ルックアサイドバッファ５０６は、より頻繁に遭遇するブロックマッピングがバッファ内に保持されるのに対し、ほとんど遭遇しないブロックマッピングがバッファからエビクト（evict）されることを確実にするための１つ又は複数のアルゴリズム（例えば、最も長く用いられていない等）を用いる。このようにして、ホットネイティブ変換ブロックマッピング（hot native conversion blocks mapping）が、変換ルックアサイドバッファ５０６内に記憶される。更に、ネイティブブロック内の十分予測された遠くのゲスト分岐は、ＣＬＢに新たなマッピングを挿入する必要がない。なぜなら、それらのターゲットブロックが単一のマッピングされたネイティブブロック内でスティッチング（stitch）され、これによって、ＣＬＢ構造のための小さな容量効率を保持するためである。更に、１つの実施形態では、ＣＬＢは、終了ゲストのみをネイティブアドレスマッピングに記憶するように構造化される。この態様は、ＣＬＢの小さな容量効率も保持する。

[044]ゲストフェッチロジック５０２は、ゲスト命令ブロックからのアドレスが既にネイティブ変換ブロックに変換されているか否かを判断するために、変換ルックアサイドバッファ５０６を調べる。上記で説明したように、本発明の実施形態は、変換処理のためのハードウェアアクセラレーションを提供する。このため、ゲストフェッチロジック５０２は、新たな変換のためにシステムメモリ５０１からのゲストアドレスをフェッチする前に、既存のネイティブ変換ブロックマッピングのための変換ルックアサイドバッファ５０６を調べる。

[045]１つの実施形態では、変換ルックアサイドバッファは、ゲストアドレス範囲によって、又は個々のゲストアドレスによってインデックス付けされる。ゲストアドレス範囲は、ネイティブ変換ブロックに変換されたゲスト命令ブロックのアドレス範囲である。変換ルックアサイドバッファによって記憶されるネイティブ変換ブロックマッピングは、対応するゲスト命令ブロックの対応するゲストアドレス範囲を介してインデックス付けされる。このため、ゲストフェッチロジックは、ゲストアドレスを、ゲストアドレス範囲又は変換されたブロックの個々のゲストアドレスと比較することができ、そのマッピングは変換ルックアサイドバッファ５０６に保持され、既存のネイティブ変換ブロックが、ネイティブキャッシュ５０７又は図６のコードキャッシュに記憶されるものの中に存在しているか否かが判断される。既存のネイティブ変換ブロックがネイティブキャッシュ又はコードキャッシュ内にある場合、対応するネイティブ変換命令は、これらのキャッシュからプロセッサに直接転送される。

[046]このようにして、ホットゲスト命令ブロック（例えば、頻繁に実行されるゲスト命令ブロック）は、高速低レイテンシ変換ルックアサイドバッファ５０６内に維持される対応するホットネイティブ変換ブロックマッピングを有する。ブロックに達すると、適切な交換ポリシが、ホットブロックマッピングが変換ルックアサイドバッファ内に留まることを確実にする。このため、ゲストフェッチロジック５０２は、要求されたゲストアドレスが以前に変換されたか否かを迅速に特定することができ、以前に変換されたネイティブ命令を、プロセッサ５０８によって実行するためにネイティブキャッシュ５０７に直接転送することができる。これらの態様により、多数のサイクルが節約される。なぜならシステムメモリへのトリップが、４０〜５０以上のサイクルをとり得るためである。これらの属性（例えば、ＣＬＢ、ゲスト分岐シーケンス予測、ゲスト及びネイティブ分岐バッファ、以前のもの（the prior）のネイティブキャッシング）は、本発明の実施形態のハードウェアアクセラレーション機能が、比較可能なネイティブアプリケーションのアプリケーションの８０％〜１００％まで、ゲストアプリケーションのアプリケーション性能を達成することを可能にする。

[047]１つの実施形態では、ゲストフェッチロジック５０２は、プロセッサ５０８からのゲスト命令要求と独立して、変換のためのゲスト命令を連続してプリフェッチする。ネイティブ変換ブロックは、より頻繁に用いられていないブロックのために、システムメモリ５０１における変換バッファ「コードキャッシュ」内で蓄積することができる。変換ルックアサイドバッファ５０６は、最も頻繁に用いられるマッピングも保持する。このため、要求されたゲストアドレスが、変換ルックアサイドバッファ内のゲストアドレスにマッピングされない場合、ゲストフェッチロジックは、システムメモリ５０１をチェックして、ゲストアドレスが、システムメモリ５０１に記憶されているネイティブ変換ブロックに対応するか否かを判断することができる。

[048]１つの実施形態では、変換ルックアサイドバッファ５０６は、キャッシュとして実施され、キャッシュコヒーレンシプロトコルを用いて、高レベルのキャッシュ及びシステムメモリ５０１に記憶されたはるかに大きな変換バッファを用いてコヒーレンシを維持する。変換ルックアサイドバッファ５０６内に記憶されるネイティブ命令マッピングは、より高レベルのキャッシュ及びシステムメモリ５０１にも書き戻される。システムメモリへの書き戻し（write back、ライトバック）は、コヒーレンシを維持する。このため、キャッシュ管理プロトコルを用いて、ホットネイティブ変換ブロックマッピングが変換ルックアサイドバッファ５０６に記憶され、コールドネイティブ変換マッピングブロックがシステムメモリ５０１に記憶されることを確実にすることができる。このため、変換バッファ５０６のはるかに大きな形態がシステムメモリ５０１に存在する。

[049]１つの実施形態において、例示的なハードウェアアクセラレーションされた変換システム５００を用いて、多数の異なる仮想ストレージ方式を実施することができることに留意するべきである。例えば、ゲスト命令ブロック及びそれらの対応するネイティブ変換ブロックがどのようにキャッシュ内に記憶されるかを用いて、仮想ストレージ方式をサポートすることができる。同様に、ゲストブロックとネイティブブロックとの間のアドレスマッピングをキャッシングするのに用いられる変換ルックアサイドバッファ５０６を用いて、仮想ストレージ方式（例えば、仮想メモリ対物理メモリのマッピングの管理）をサポートすることができる。

[050]１つの実施形態では、図９のアーキテクチャは、入力として、複数の異なる命令アーキテクチャを受け取ることができるフレキシブルな変換プロセスを用いる仮想命令セットプロセッサ／コンピュータを実施する。そのような仮想命令セットプロセッサにおいて、プロセッサのフロントエンドは、ソフトウェア制御され得る一方で、はるかに高いレベルの性能を送達するためのハードウェアアクセラレーションされた変換処理を利用するように実施される。そのような実施態様を用いて、各々がはるかに高レベルの性能を享受するようにハードウェアアクセラレーションの利点を受けながら、様々なゲストアーキテクチャが処理及び変換され得る。例示的なゲストアーキテクチャは、Ｊａｖａ（登録商標）又はＪａｖａＳｃｒｉｐｔ（登録商標）、ｘ８６、ＭＩＰＳ、ＳＰＡＲＣ等を含む。１つの実施形態では、「ゲストアーキテクチャ」は、（例えば、ネイティブアプリケーション／マクロオペレーションからの）ネイティブ命令とすることができ、変換プロセスは、最適化されたネイティブ命令（例えば、最適化されたネイティブ命令／マイクロオペレーション）を生成する。ソフトウェアにより制御されたフロントエンドは、プロセッサ上で実行されるアプリケーションに高い度合いの柔軟性を提供することができる。上記で説明したように、ハードウェアアクセラレーションは、ゲストアプリケーションのゲスト命令の実行について、ネイティブハードウェア速度に近い速度を達成することができる。

[051]図１０は、本発明の１つの実施形態による、ハードウェアアクセラレーションされた変換システム６００のより詳細な例を示す。システム６００は、上記で説明したシステム５００と実質的に同じようにして実施される。一方、システム６００は、例示的なハードウェアアクセラレーションプロセスの機能を説明する更なる詳細を示す。

[052]システムメモリ６０１は、ゲストコード６０２、変換ルックアサイドバッファ６０３、オプティマイザコード６０４、変換器コード６０５、及びネイティブコードキャッシュ６０６を含むデータ構造を含む。システム６００は、ゲスト命令及びネイティブ命令が共にインタリーブされ共有される、共有ハードウェアキャッシュ６０７も示す。ゲストハードウェアキャッシュ６１０は、共有されたハードウェアキャッシュ６０７から最も頻繁にタッチされるゲスト命令をキャッシングする。

[053]ゲストフェッチロジック６２０は、ゲストコード６０２からゲスト命令をプリフェッチする。ゲストフェッチロジック６２０は、仮想ゲストアドレスを対応する物理ゲストアドレスに変換する変換ルックアサイドバッファとして機能するＴＬＢ６０９とインタフェースする。ＴＬＢ６０９は、ヒットをゲストハードウェアキャッシュ６１０に直接転送することができる。ゲストフェッチロジック６２０によってフェッチされるゲスト命令は、ゲストフェッチバッファ６１１に記憶される。

[054]変換テーブル６１２及び６１３は、置換フィールド及び制御フィールドを含み、ゲストフェッチバッファ６１１から受け取ったゲスト命令をネイティブ命令に変換するためのマルチレベル変換テーブルとして機能する。

[055]マルチプレクサ６１４及び６１５は、変換されたネイティブ命令をネイティブ変換バッファ６１６に転送する。ネイティブ変換バッファ６１６は変換されたネイティブ命令を蓄積してネイティブ変換ブロックにアセンブルする。これらのネイティブ変換ブロックは、次に、ネイティブハードウェアキャッシュ６００に転送され、マッピングが変換ルックアサイドバッファ６３０に保持される。

[056]変換ルックアサイドバッファ６３０は、変換されたブロックエントリポイントアドレス６３１、ネイティブアドレス６３２、変換されたアドレス範囲６３３、コードキャッシュ及び変換ルックアサイドバッファ管理ビット６３４、及び動的分岐バイアスビット６３５のためのデータ構造を含む。ゲスト分岐アドレス６３１及びネイティブアドレス６３２は、いずれの対応するネイティブ変換ブロックが変換されたロック範囲６３３内に存在するかを示すゲストアドレス範囲を含む。キャッシュ管理プロトコル及び交換ポリシは、ホットネイティブ変換ブロックマッピングが変換ルックアサイドバッファ６３０内に存在するのに対し、コールドネイティブ変換ブロックマッピングがシステムメモリ６０１内の変換ルックアサイドバッファデータ構造６０３内に存在することを確実にする。

[057]システム５００と同様に、システム６００は、ホットブロックマッピングが高速低レイテンシ変換ルックアサイドバッファ６３０内に存在することを確実にしようとする。このため、１つの実施形態において、フェッチロジック６４０又はゲストフェッチロジック６２０がゲストアドレスをフェッチするように調べるとき、フェッチロジック６４０はまず、ゲストアドレスをチェックして、対応するネイティブ変換ブロックがコードキャッシュ６０６内に存在するか否かを判断する。これによって、要求されたゲストアドレスが、コードキャッシュ６０６内に対応するネイティブ変換ブロックを有するか否かに関して判断することが可能になる。要求されたゲストアドレスが、バッファ６０３若しくは６０８又はバッファ６３０内に存在してない場合、ゲストアドレス及び複数の後続のゲスト命令がゲストコード６０２からフェッチされ、変換プロセスが変換テーブル６１２及び６１３を介して実施される。このようにして、本発明の実施形態は、ランアヘッドゲストフェッチ及びデコード、テーブルルックアップ並びに命令フィールドアセンブリを実施することができる。

[058]図１１は、本発明の１つの実施形態による、二重スコープの使用を含む第２のモデルの図１４００を示す。上記で説明したように、この使用モデルは、２つのスレッドのプロセッサへのフェッチに適用され、ここで、一方のスレッドは、投機的状態において実行され、他方のスレッドは、非投機的状態で実行される。この使用モデルでは、双方のスコープがマシン内にフェッチされ、同時にマシン内に存在する。

[059]図１４００に示すように、２つのスコープ／トレース１４０１及び１４０２がマシン内にフェッチされた。この例では、スコープ／トレース１４０１は、現在の非投機的スコープ／トレースである。スコープ／トレース１４０２は、新たな投機的スコープ／トレースである。アーキテクチャ１３００は、２つのスレッドが実行のためにこれらの状態を使用することを可能にする投機的及びスクラッチ状態を可能にする。一方のスレッド（例えば、１４０１）は、非投機的スコープにおいて実行し、他方のスレッドは（例えば１４０２）は投機的スコープを使用する。双方のスコープがマシン内にフェッチされ、同時に存在することができ、各スコープはそれぞれのモードを異なる形で設定する。第１のスコープは非投機的であり、他方は投機的である。このため、第１のスコープは、ＣＲ／ＣＭモードで実行し、他方は、ＳＲ／ＳＭモードで実行する。ＣＲ／ＣＭモードでは、コミットされたレジスタが読出し及び書込みをされ、メモリ書込みはメモリに進む。ＳＲ／ＳＭモードでは、レジスタ書込みはＳＳＳＲに進み、レジスタ読出しは最新の書込みから到来する一方で、メモリはリタイアメントメモリバッファ（ＳＭＢ）に書き込む。

[060]１つの例は、順序付けされた現在のスコープ（例えば、１４０１）及び投機的な次のスコープ（例えば、１４０２）である。次のスコープは現在のスコープの後にフェッチされるので、従属関係が守られるように、双方をマシンにおいて実行することができる。例えば、スコープ１４０１において、「ＳＳＳＲをＣＲにコミットする」において、この時点までレジスタ及びメモリはＣＲモードにある一方、コードはＣＲ／ＣＭモードで実行される。スコープ１４０２において、コードはＳＲ及びＳＭモードで実行され、例外が生じた場合、ロールバックすることができる。このようにして、双方のスコープがマシンにおいて同時に実行されるが、各々が異なるモードで実行されており、それに応じてレジスタの読み出し及び書込みを行っている。

[061]図１２は、本発明の１つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第３の使用モデルの図を示す。上記で説明されたように、この使用モデルは、複数の理由で生じ得るコンテキスト切り替えに適用される。１つのそのような理由は、例えば、例外処理コンテキストを介した例外の正確な処理であり得る。

[062]第３の使用モデルは、マシンが変換されたコードを実行しており、コンテキスト切り替え（例えば、変換されたコード内の例外、又は後続のコードのための変換が必要とされる場合）に遭遇するときに生じる。現在の範囲において（例えば、例外の前に）、ＳＳＳＲ及びＳＭＢは、ゲストアーキテクチャ状態に対するそれらの投機的状態をまだコミットしていない。現在の状態は、ＳＲ／ＳＭモードで実行されている。例外が生じるとき、マシンは、例外に正確に対処するために、例外ハンドラ（例えば、変換器）に切り替える。ロールバックが挿入され、これによって、レジスタ状態がＣＲにロールバックされ、ＳＭＢがフラッシュされる。変換器コードは、ＳＲ／ＣＭモードで実行される。変換器コードの実行中、ＳＭＢは、コミットイベントを待機することなくメモリにコンテンツをリタイアしている。レジスタは、ＣＲを更新することなくＳＳＳＲに書き込まれる。その後、変換器が終了し、変換コードの実行に戻るように切り替える前に、ＳＳＳＲをロールバックする（例えば、ＳＳＳＲがＣＲにロールバックされる）。このプロセス中、最後にコミットされたレジスタ状態はＣＲにある。

[063]これは、前のスコープ／トレース１５０１がＳＳＳＲからＣＲにコミットされた図１５００に示されている。現在のスコープ／トレース１５０２は投機的である。レジスタ及びメモリ及びこのスコープは投機的であり、実行はＳＲ／ＳＭモード下で生じる。この例では、例外はスコープ１５０２において生じ、コードは、変換前に元の順序で再度実行される必要がある。この時点において、ＳＳＳＲはロールバックされ、ＳＭＢがフラッシュされる。次に、ＪＩＴコード１５０３が実行される。ＪＩＴコードはＳＳＳＲをスコープ１５０１の末尾までロールバックし、ＳＭＢをフラッシュする。ＪＩＴの実行は、ＳＣ／ＣＭモード下で行われる。ＪＩＴが終了すると、ＳＳＳＲはＣＲにロールバックされ、次に、現在のスコープ／トレース１５０４が、ＣＲ／ＣＭモードで元の変換順序において再実行される。このようにして、厳密な現在の順序において例外が正確に処理される。

[064]図１３は、本発明の１つの実施形態による、命令シーケンスにおける例外が、後続のコードの変換が必要とされることに起因する事例を描く図である。図１６００に示すように、前のスコープ／トレース１６０１は、変換されていない宛先へのｆａｒ ｊｕｍｐで終了する。ｆａｒ ｊｕｍｐの宛先にジャンプする前に、ＳＳＳＲはＣＲにコミットされる。次に、ＪＩＴコード１６０２を実行して、ｆａｒ ｊｕｍｐの宛先において、（例えば、ネイティブ命令の新たなトレースを構築するための）推測命令を変換する。ＪＩＴの実行は、ＳＲ／ＣＭモード下で行われる。ＪＩＴの実行の終了時、レジスタ状態はＳＳＳＲからＣＲにロールバックされ、ＪＩＴによって変換された新たなスコープ／トレース１６０３が実行を開始する。新たなスコープ／トレースは、ＳＲ／ＳＭモードにおける前のスコープ／トレース１６０１の最後にコミットされた点から実行を継続する。

[065]図１４は、本発明の１つの実施形態による、トランジェントコンテキストから戻るときに以前のコンテキストを保存及び復元する必要のないトランジェントコンテキスト切り替えを含む、第４の使用モデルの図を示す。上記で説明したように、この使用モデルは、複数の理由で生じ得るコンテキスト切り替えに適用される。１つのそのような理由は、例えば、例外処理コンテキストによる処理入力又は出力であり得る。

[066]図１７００は、ＣＲ／ＣＭモード下で実行される前のスコープ／トレース１７０１が関数Ｆ１の呼び出しで終了する事例を示す。その時点までのレジスタ状態は、ＳＳＳＲからＣＲにコミットされる。関数Ｆ１のスコープ／トレース１７０２は、次に、ＳＲ／ＣＭモード下で投機的に実行を開始する。次に、関数Ｆ１は、メインのスコープ／トレース１７０３に戻って終了する。この時点において、レジスタ状態はＳＳＳＲからＣＲにロールバックされる。メインのスコープ／トレース１７０３は、ＣＲ／ＣＭモードにおける実行を再開する。

[067]図１５は、本発明の１つの実施形態による、分岐の前の最適化されたスケジューリング命令を例示する図を示す。図１５に示されるように、ハードウェア最適化された例が、従来の実行時コンパイラの例と並べて示される。図１５の左側は、不成立にバイアスがかかった分岐不成立の「Ｌ１への分岐Ｃ」を含む、元の非最適化コードを示す。図１５の中央の列は、従来の実行時コンパイラ最適化を示し、ここで、レジスタはリネームされ、命令は分岐の前に移される。この例において、実行時コンパイラは、分岐にバイアスがかかった決定が誤りである（例えば、分岐が不成立ではなく、実際に成立する）機会を考慮するように補償コードを挿入する。対照的に、図１５の右列は、ハードウェアによって展開（unroll、アンロール）された最適化を示す。この場合、レジスタはリネームされ、命令は分岐の前に移される。一方、補償コードが挿入されていないことに留意するべきである。ハードウェアは、分岐にバイアスがかかった決定が真であるか否かを追跡する。予測ミスされた分岐の場合、ハードウェアは、正しい命令シーケンスを実行するために、その状態を自動的にロールバックする。ハードウェアオプティマイザによる解決方法は、補償コードの使用を回避することができる。なぜなら、分岐が予測ミスされるこれらの事例では、ハードウェアがメモリ内の元のコードにジャンプし、そこから正しいシーケンスを実行する一方で、予測ミスされた命令シーケンスをフラッシュするためである。

[068]図１６は、本発明の１つの実施形態による、ストアの前のロードの最適化されたスケジューリングを例示する図を示す。図１６に示すように、ハードウェア最適化された例が、従来の実行時コンパイラの例と並べて描かれている。図１６の左側は、ストア「Ｒ３←ＬＤ［Ｒ５］」を含む元の非最適化コードを示す。図１６の中央列は、従来の実行時コンパイラ最適化を示し、ここで、レジスタはリネームされ、ロードはストアの前に移される。この例では、実行時コンパイラは、ロード命令のアドレスがストア命令のアドレスをエイリアス（alias）する（例えば、ストアの前にロードを移すことが適切でない）機会を考慮するように補償コードを挿入する。対照的に、図１６の右列は、ハードウェアによってアンロールされた最適化を示す。この場合、レジスタはリネームされ、ロードもストアの前に移される。一方、補償コードが挿入されていないことに留意するべきである。ロードをストアの前に移すことが誤っている場合、ハードウェアは、正しい命令シーケンスを実行するために、その状態を自動的にロールバックする。ハードウェアオプティマイザによる解決方法は、補償コードの使用を回避することができる。なぜなら、アドレスエイリアスチェック分岐が予測ミスされるこれらの事例では、ハードウェアがメモリ内の元のコードにジャンプし、そこから正しいシーケンスを実行する一方で、予測ミスされた命令シーケンスをフラッシュするためである。この場合、シーケンスはエイリアスなしを想定する。１つの実施形態では、図１６に示す機能は、命令スケジューリング及びオプティマイザ構成部によって実装することができることに留意するべきである。同様に、１つの実施形態では、図１６に示す機能は、ソフトウェアオプティマイザによって実施することができることに留意するべきである。

[069]更に、動的にアンロールされたシーケンスに関して、命令は、リネームを用いることによって、以前のパスによって予測される分岐（例えば、動的に構築された分岐）をパスすることができることに留意するべきである。非動的に予期された分岐の場合、命令の移動は、分岐の範囲を考慮するべきである。ループは、所望の範囲までアンロールすることができ、シーケンス全体にわたって最適化を適用することができる。例えば、これは分岐をまたいで移る命令の宛先レジスタをリネームすることによって実施することができる。この特徴の利点のうちの１つは、分岐の範囲の補償コードも拡張解析も必要とされないことである。このため、この特徴は最適化プロセスを大幅に加速し、簡略化する。

[070]図１７は、本発明の１つの実施形態による、ストアフィルタリングアルゴリズムの図を示す。図１７の実施形態の目的は、全てのストアが、ロードキュー内の全てのエントリに対しチェックしなくてはならないことを防ぐようにストアをフィルタリングすることである。

[071]ストアは、アドレスマッチについてキャッシュをスヌープしてコヒーレンシを維持する。スレッド／コアＸロードは、キャッシュラインから読み出す場合、データをロードしたキャッシュラインの部分をマーキングする。別のスレッド／コアＹストアがキャッシュをスヌープするとき、任意のそのようなストアがそのキャッシュライン部分に重複している場合、そのスレッド／コアＸのロードについて予測ミスが生じる。

[072]これらのスヌープをフィルタリングするための１つの解決方法は、ロードキューエントリの参照先を追跡することである。この場合、ストアは、ロードキューをスヌープする必要がない。ストアがアクセスマスクとのマッチを有する場合、参照先トラッカから得られたロードキューエントリは、ロードエントリに予測ミスをさせることになる。

[073]別の解決方法（参照先トラッカがない場合）では、ストアがアクセスマスクとのマッチを有する場合、ストアアドレスがロードキューエントリをスヌープし、マッチしたロードエントリに予測ミスをさせることになる。

[074]双方の解決方法により、ロードは、キャッシュラインから読み出しているとき、それぞれのアクセスマスクビットを設定する。そのロードは、リタイアするとき、そのビットをリセットする。

[075]図１８は、本発明の１つの実施形態による、インオーダでのメモリからのロードの読出しを構成するメモリ一貫性（memory consistency、メモリコンシステンシ）モデルにおける、アウトオブオーダロードを有するセマフォの実施を示す。本明細書において用いられるとき、セマフォという用語は、共通のリソースに対し、複数のスレッド／コアのためのアクセス制御を提供するデータ構造を指す。

[076]図１８の実施形態では、アクセスマスクは、複数のスレッド／コアによるメモリリソースへのアクセスを制御するのに用いられる。アクセスマスクは、キャッシュラインのいずれのワードが未解決のロードを有するかを追跡することによって機能する。アウトオブオーダロードは、キャッシュラインのワードにアクセスするときにマスクビットを設定し、ロードがリタイアするときにマスクビットをクリアする。マスクビットが設定されている間に、別のスレッド／コアからのストアがそのワードに書き込む場合、アクセスマスクは（例えば、トラッカを介して）そのロードに対応するロードキューエントリを、予測ミスとなる／フラッシュされるか、又はその従属命令を用いてリタイアされるようにシグナリングする。アクセスマスクは、スレッド／コアも追跡する。

[077]このようにして、アクセスマスクは、メモリコンシステンシ規則が正しく実施されることを確実にする。メモリコンシステンシ規則は、ストアがメモリをインオーダでアップデートすることを指示し、このセマフォが２つのコア／スレッドにわたって機能するために、メモリから読出しをインオーダでロードする。このため、コア１及びコア２によって実行されるコードは正しく実行されることになる。ここで、これらのコードは共に、メモリロケーション「フラグ」及び「データ」の双方にアクセスする。

[078]図１９は、本発明の１つの実施形態による、ＪＩＴ最適化を通じたリオーダリングプロセスの図を示す。図１９は、メモリコンシステンシオーダリング（memory consistency ordering、例えば、ロードの前にロードを行う順序付け）を描いている。ロードは、同じアドレスに対する他のロードの前にディスパッチ（dispatch）することはできない。例えば、ロードは、同じスレッドからの後続のロードの同じアドレスについてチェックする。

[079]１つの実施形態では、全ての後続のロードが、アドレスマッチについてチェックされる。例えば、この解決方法が機能するためには、ロードＣチェックは、元のロードＣロケーションの点（point、ポイント）まで、リタイアメント後にキュー（又は例えばその拡張部）に留まる必要がある。ロードチェック拡張サイズは、リオーダされたロード（例えば、ロードＣ）が前にジャンプすることができるロードの数に対する制約を設けることによって決定することができる。この解決方法は、パーシャルストアオーダリング（partial store ordering）メモリコンシステンシモデル（例えば、ＡＲＭコンシステンシモデル）でしか機能しないことに留意するべきである。

[080]図２０は、本発明の１つの実施形態による、ＪＩＴ最適化を通じたリオーダリングプロセスの図を示す。ロードは、同じアドレスに対する他のロードの前にディスパッチすることができない。例えば、ロードは、同じスレッドからの後続のロードの同じアドレスについてチェックする。図２０は、他のスレッドストアがロードキュー全体に対してどのようにチェックを行い、拡張を監視するかを示す。モニタは、元のロードによって設定され、元のロード位置に続いて、後続の命令によってクリアされる。この解決方法は、トータルストアオーダリング（total store ordering）メモリコンシステンシモデル及びパーシャルストアオーダリングメモリコンシステンシモデルの双方（例えば、ｘ８６及びＡＲＭコンシステンシモデル）で機能することに留意するべきである。

[081]図２１は、本発明の１つの実施形態による、ＪＩＴ最適化を通じたリオーダリングプロセスの図を示す。ロードは、同じアドレスに対する他のロードの前にディスパッチすることができない。本発明の１つの実施形態は、ロードリタイアメント拡張を実施する。この実施形態では、他のスレッドストアは、ロード／ストアキュー全体（及び例えば拡張）に対しチェックする。

[082]この解決方法を実施する際、リタイアする全てのロードは、元のロードＣロケーションのポイントまでリタイアした後にロードキュー（又は例えばその拡張）内に留まる必要がある。他のスレッドからのストアが到来するとき（スレッド０）、このストアは、ロードキュー全体（例えば、拡張を含む）にＣＡＭマッチする。拡張サイズは、リオーダされたロード（ロードＣ）が（例えば、８エントリ拡張を用いることによって）前にジャンプすることができるロード数に制限を設けることによって決定することができる。この解決方法は、トータルストアオーダリングメモリコンシステンシモデル及びパーシャルストアオーダリングメモリコンシステンシモデルの双方（例えば、ｘ８６及びＡＲＭコンシステンシモデル）で機能することに留意するべきである。

[083]図２２は、本発明の１つの実施形態による、ＪＩＴ最適化を通じてストアの前にリオーダされるロードを例示する図を示す。図２２は、同じスレッド内の、ストアからロードへの転送オーダリング（例えば、ストアからロードへのデータ依存性）を利用する。

[084]同じスレッド内のストアの同じアドレスに対するロードは、そのストアの前にＪＩＴを通じてリオーダすることができない。１つの実施形態では、リタイアする全てのロードは、元のロードＣロケーションのポイントまで、リタイアメント（retirement）後にキュー（及び／又は例えばその拡張）に留まる必要がある。各リオーダされたロードは、後続のストアに関係したマシン順序（例えば、ＩＰ）内のそのロードの初期位置を示すオフセットを含む。

[085]１つの例示的な実施態様は、オフセットインジケータに初期命令位置を含めることである。同じスレッドからストアが到来するとき、このストアは、マッチを探しているロードキュー全体（拡張を含む）にＣＡＭマッチし、これは、このストアが、マッチしたロードに転送されることを示す。ストアがロードＣの前にディスパッチされた場合、そのストアはストアキュー内のエントリを予約し、ロードが後にディスパッチされるときに、ロードはストアのアドレスに対しＣＡＭマッチし、自身のＩＰを用いてマシン順序を決定し、ストアのうちの任意のものからそのロードへのデータ転送を完結する。拡張サイズは、リオーダされたロード（ロードＣ）が（例えば、８エントリの拡張を用いることによって）前にジャンプすることができるロード数に対する制約を設けることによって決定することができる。

[086]別の解決方法は、元のロードの場所にチェックストア命令を配置することである。チェックストア命令は、ディスパッチするとき、アドレスマッチについてロードキューに対しチェックを行う。同様に、ロードは、ディスパッチするとき、チェックストア命令によって占有されるストアキューエントリに対し、アドレスマッチについてチェックする。

[087]図２３は、本発明の１つの実施形態による、ロード及びストア命令分割の第１の図を示す。本発明の１つの特徴は、ロードが２つのマクロ命令に分割されることであり、第１の命令は一時的ロケーション（ロードストアキュー）へのアドレス計算及びフェッチを行い、第２の命令はレジスタ又はＡＬＵ宛先へのメモリアドレスコンテンツ（データ）のロードである。本発明の実施形態は、ロード及びストア命令を、２つのそれぞれのマイクロ命令に分割し、それらをリオーダすることに関連して説明されているが、同じ方法及びシステムを、ロード及びストア命令を２つのそれぞれのマイクロ命令に分割し、これらをマイクロコードコンテキスト内でリオーダすることによって実施することができることに留意するべきである。

[088]機能は、ストアについて同じである。ストアも、２つのマクロ命令に分割される。第１の命令はストアアドレス及びフェッチであり、第２の命令はそのアドレスにおけるデータのストアである。ストアの分割及び２つの命令は、ロードについて後述するのと同じ規則に従う。

[089]２つの命令へのロードの分割によって、ランタイムオプティマイザが、所与の命令シーケンス内ではるかに早く、アドレス計算をスケジューリングして、命令をフェッチすることが可能になる。これによって、キャッシュ階層と別個の一時バッファにデータをプリフェッチすることによって、メモリミスからのより容易な回復が可能になる。一時的なバッファは、ＬＡ／ＳＡとＬＤ／ＳＤとの間の１対１の対応でプリフェッチデータの利用可能性を保証するために用いられる。対応するロードデータ命令は、ロードアドレスとロードデータとの間のウィンドウ内にある以前のストアとのエイリアシングが存在する場合（例えば、転送事例が前のストアから検出された場合）、又はアドレス計算に何らかの障害問題（例えば、ページ障害）が存在する場合、再発行することができる。更に、２つの命令へのロードの分割は、情報を２つの命令に複製することも含むことができる。そのような情報は、アドレス情報、ソース情報、他の追加の識別子等に対処することができる。この複製によって、ＬＡ／ＳＡがない場合に２つの命令のＬＤ／ＳＤの独立したディスパッチが可能になる。

[090]ロードアドレス及びフェッチ命令は、ロードデータが戻るのを待つことなく、実際のマシンリタイアメントウィンドウからリタイアし、以て、そのアドレス（例えば、段落の最初に参照されるロードアドレス）に対するキャッシュミスの場合であってもマシンが転送を進めることを可能にすることができる。例えば、そのアドレス（例えば、アドレスＸ）に対するキャッシュミスの場合に、マシンは、場合によっては、メモリ階層からデータがフェッチされるのを待って、数百サイクルにわたって停止することができる。ロードデータが戻るのを待つことなく実際のマシンリタイアメントウィンドウからロードアドレス及びフェッチ命令をリタイアすることによって、マシンは依然として転送を進めることができる。

[091]命令の分割によって、ＬＡ／ＳＡ命令を早期に、かつＬＤ／ＳＤ命令シーケンスから離れるようにリオーダして、ロード及びストアのより早期のディスパッチ及び実行を可能にする、本発明の実施形態の主要な利点が可能になることに留意するべきである。

[092]図２４は、本発明の１つの実施形態による、メモリ内に記憶されたネイティブ命令マッピングに対するコードキャッシュ及びゲスト命令と併せてＣＬＢがどのように機能するかを示す例示的な流れ図を示す。

[093]上記で説明したように、ＣＬＢを用いて、コードキャッシュメモリ（例えば、ゲスト対ネイティブアドレスマッピング）内に記憶された対応する変換されたネイティブアドレスを有するゲストアドレスのマッピングを記憶する。１つの実施形態では、ＣＬＢは、ゲストアドレスの一部分を用いてインデックス付けされる。ゲストアドレスは、インデックス、タグ及びオフセット（例えば、チャンクサイズ）に分割される。このゲストアドレスは、インデックスに対応するＣＬＢエントリにおけるマッチを特定するのに用いられるタグを含む。タグ上にヒットが存在する場合、対応するエントリは、コードキャッシュメモリ８０６内のどこに対応する変換されたネイティブ命令チャンク（例えば、変換されたネイティブ命令の対応するブロック）を見つけることができるかを示すポインタを記憶する。

[094]本明細書において用いられる「チャンク」という用語は、変換されたネイティブ命令ブロックの対応するメモリサイズを指すことに留意するべきである。例えば、チャンクは、変換されたネイティブ命令ブロックの異なるサイズに依拠して、サイズが異なることができる。

[095]１つの実施形態では、コードキャッシュメモリ８０６に関して、コードキャッシュは、１組の固定サイズのチャンクに（例えば、チャンクタイプごとに異なるサイズを用いて）割り当てられる。コードキャッシュは、システムメモリ及び全ての下位レベルのＨＷキャッシュ（例えば、ネイティブハードウェアキャッシュ６０８、共有ハードウェアキャッシュ６０７）内の組及び方法に論理的に分割することができる。ＣＬＢは、ゲストアドレスを用いて、コードキャッシュチャンクのための方法タグをインデックス付けし、タグ比較することができる。

[096]図２４は、方法ｘ及び方法ｙとして示される２つの方法においてゲストアドレスタグを記憶するＣＬＢハードウェアキャッシュ８０４を描く。１つの実施形態において、ＣＬＢ構造を用いたネイティブアドレスに対するゲストアドレスのマッピングは、構造化された方法においてネイティブコードチャンクへのポインタ（例えば、ゲストからネイティブへのアドレスマッピング）を記憶することにより行うことができることに留意するべきである。各方法はタグに関連付けられる。ＣＬＢは、ゲストアドレス８０２（タグを含む）を用いてインデックス付けされる。ＣＬＢにおけるヒット時に、タグに対応するポインタが返される。このポインタを用いて、コードキャッシュメモリをインデックする。これは、ライン「コードチャンクのネイティブアドレス＝Ｓｅｇ＃＋Ｆ（ｐｔ）」によって図２４に示されている。このラインは、コードチャンクのネイティブアドレスが、ポインタ及びセグメント番号の関数であることを表す。本実施形態において、セグメントは、ポインタスコープが仮想的にマッピングされるメモリ内のポイントのための基部を指す（例えば、物理メモリ内の任意の領域内にポインタアレイがマッピングされることを可能にする）。

[097]代替的に、１つの実施形態では、コードキャッシュメモリは、図２４に示されるように、ライン「コードチャンクのネイティブアドレス＝ｓｅｇ＃＋インデックス＊（チャンクのサイズ）＋ｗａｙ＃＊（チャンクサイズ）」によって第２の方法によりインデックス付けすることができる。そのような実施形態では、コードキャッシュは、その方法構造がＣＬＢ方法の構造化にマッチするように組織化され、それによって、ＣＬＢの方法と、コードキャッシュチャンクとの間に１：１のマッピングが存在するようにする。次に、特定のＣＬＢ方法におけるヒットが存在するとき、コードキャッシュの対応する方法における対応するコードチャンクがネイティブコードを有する。

[098]依然として図２４を参照すると、ＣＬＢのインデックスがミスである場合、メモリのより高い階層をヒットについてチェックすることができる（例えば、Ｌ１キャッシュ、Ｌ２キャッシュ等）。これらのより高いレベルのキャッシュにおいてヒットが存在しない場合、システムメモリ８０１におけるアドレスがチェックされる。１つの実施形態において、ゲストインデックスは、例えば、６４個のチャンクを含むエントリをポインティングする。６４個のチャンクの各々のタグは、読み出され、ゲストタグと比較され、ヒットが存在するか否かが判断される。このプロセスは、図２４において、点線のボックス８０５によって示される。システムメモリ内のタグとの比較後にヒットが存在しない場合、メモリのいかなる階層レベルにおいても変換が存在せず、ゲスト命令が変換されなくてはならない。

[099]本発明の実施形態は、キャッシュのような方式でゲスト対ネイティブ命令マッピングを記憶するメモリの階層レベルの各々を管理することに留意するべきである。これは、キャッシュベースのメモリ（例えば、ＣＬＢハードウェアキャッシュ、ネイティブキャッシュ、Ｌ１及びＬ２キャッシュ等）から固有に到来する。一方、ＣＬＢは、システムメモリ８０１内のゲスト対ネイティブ命令マッピングのための最も長く用いられていない（ＬＲＵ）交換管理ポリシを実施するのに用いられる「コードキャッシュ＋ＣＬＢ管理ビット」も含む。１つの実施形態では、ＣＬＢ管理ビット（例えば、ＬＲＵビット）は、ソフトウェア管理される。このようにして、メモリの全ての階層レベルを用いて、最も近時に用いられた、最も頻繁に遭遇するゲスト対ネイティブ命令マッピングを記憶する。これに応じて、最も頻繁に遭遇する変換されたネイティブ命令を同様に記憶するメモリの全ての階層レベルが導かれる。

[0100]図２４は、ＣＬＢ内に記憶される動的分岐バイアスビット及び／又は分岐履歴ビットも示す。これらの動的分岐ビットを用いて、ゲスト命令シーケンスをアセンブルする際に用いられる分岐予測の挙動を追跡する。これらのビットを用いて、いずれの分岐予測が最も頻繁に正確に予測されるか、及びいずれの分岐予測が最も頻繁に予測ミスされるかを追跡する。ＣＬＢは、変換されたブロック範囲のためのデータも記憶する。このデータは、プロセスが、（例えば、自己変更コードのように）対応するゲスト命令が変更されたコードキャッシュメモリ内の変換されたブロック範囲を無効にすることを可能にする。

[0101]図２５は、本発明の１つの実施形態による、ランアヘッドランタイムゲスト命令の変換／デコードプロセスの図を示す。図２５は、ゲストコードのオンデマンド変換／デコード中、目的は、メインメモリからゲストコードを持ってくること（例えば、これはコストのかかるトリップとなる）を回避することであることを示す図である。図２５は、ゲストコードが、命令シーケンスにおけるゲスト分岐のターゲットからプリフェッチされるプリフェッチプロセスを示す。例えば、命令シーケンスは、推測分岐Ｘ、Ｙ及びＺを含む。これによって、アドレスＸ、Ｙ及びＺにおけるゲストコードのプリフェッチ命令の問題が生じる。

[0102]図２６は、本発明の１つの実施形態による、ゲスト命令シーケンスを有する変換テーブルと、ネイティブ命令マッピングを有するネイティブマッピングテーブルとを描く図を示す。１つの実施形態では、メモリ構造／テーブルは、低レベル低レイテンシキャッシュと同様のキャッシュとして実施することができる。

[0103]１つの実施形態では、最も頻繁に遭遇するゲスト命令及びそれらのマッピングは、低レベルキャッシュ構造に記憶され、ランタイムがこれらの構造に迅速にアクセスして、ゲスト命令のための等価なネイティブ命令を取得することを可能にする。マッピングテーブルは、ルックアップされたゲスト命令フォーマットのための等価な命令フォーマットを提供することができる。いくつかの制御値を用いて、これらのマッピングテーブルに制御フィールドとして記憶し、ゲスト命令内のある特定のフィールドを、ネイティブ命令における等価なフィールドと置換することを迅速に可能にする。ここでの着想は、最も頻繁に遭遇するゲスト命令のみを低レベル（例えば、キャッシュ）に記憶して迅速な変換を可能にすることであり、一方で、他の頻繁でないゲスト命令は変換により時間がかかる可能性がある。

[0104]ここで、本発明の実施形態による用語ＣＬＢ／ＣＬＢＶ／ＣＬＴが論考される。１つの実施形態では、Ａ ＣＬＢは、ゲスト分岐の宛先にマッピングするコードのアドレスを取得するためのネイティブコードを実行する間、ネイティブゲスト分岐に遭遇するときにルックアップされるメモリ構造として維持される変換ルックアサイドバッファである。１つの実施形態では、ＣＬＢＶは、ＣＬＢの犠牲キャッシュイメージである。エントリがＣＬＢからエビクトされるとき、エントリは正規のＬ１／Ｌ２キャッシュ構造にキャッシュされる。ＣＬＢがミスに遭遇するとき、ＣＬＢは、ミスのターゲットを探索するために、ハードウェアアクセスによってＬ１／Ｌ２を自動的にルックアップする。１つの実施形態では、ＣＬＴはミスのターゲットがＣＬＢ又はＣＬＢＶに見つからないときに用いられ、ソフトウェアハンドラは、メインメモリ内のＣＬＴテーブル内のエントリをルックアップするようにトリガされる。

[0105]次に、本発明の実施形態によるＣＬＢカウンタが検討される。１つの実施形態では、ＣＬＢカウンタは、変換時に設定される値であり、変換される命令シーケンス／トレースに関係付けられたメタデータと共に記憶される。このカウンタは、命令シーケンス／トレースが実行される度にデクリメントされ、ホット性（hotness）のトリガとしての役割を果たす。この値は、全てのＣＬＢレベル（例えば、ＣＬＢ、ＣＬＢＶ、ＣＬＴ）において記憶される。この値は、閾値に到達すると、ＪＩＴコンパイラをトリガして命令シーケンス／トレースを最適化する。この値は、ハードウェアによって維持及び管理される。１つの実施形態では、命令シーケンス／トレースはＣＬＢカウンタ及びソフトウェアカウンタのハイブリッドを有することができる。

[0106]次に、本発明の１つの実施形態によるバックグラウンドスレッドが検討される。１つの実施形態において、ホット性がトリガされると、ソフトウェアに不可視のバックグラウンドハードウェアタスクとしての役割を果たし、独自のハードウェアリソース、通例、最小限のリソース（例えば、スモールレジスタファイル及びシステム状態）を有する、ハードウェアバックグラウンドスレッドが始動される。バックグラウンドスレッドは、低い優先度で、実行リソースが利用可能であるときに実行リソースを記憶するバックグラウンドスレッドとして実行され続ける。バックグラウンドスレッドはハードウェアスレッドＩＤを有し、ソフトウェアに対し可視でないが、低レベルハードウェア管理システムによって管理される。

[0107]本発明の１つの実施形態による、ＪＩＴプロファイリング及びランタイムモニタリング／動的チェックが検討される。ＪＩＴは、時間間隔において、命令シーケンス／トレースのプロファイリング／モニタリング／スイープを開始することができる。ＪＩＴは、分岐プロファイリングを用いること等によって、最適化に関連するある値を維持することができる。分岐プロファイリングは、コードインストルメンテーション（code instrumentation）を有する分岐プロファイリングハードウェア命令を用いて、分岐のセマンティックを有する命令を実施することによって、命令シーケンス／トレース内の分岐についての分岐予測値／バイアスを見つけ、それによって、特定のアドレスから命令のフェッチを開始し、これらの命令を、マシンフロントエンドを通じて渡し、これらの命令を実行することなくハードウェアブランチ予測器をルックアップする。次に、ＪＩＴは、これらのハードウェア分岐予測カウンタの値を蓄積して、ハードウェアが提供するよりも大きなカウンタを作成する。これによって、ＪＩＴが分岐バイアスをプロファイリングすることが可能になる。

[0108]継続的なプロファイリングは、この情報を用いてコードを変更及び最適化しない値を検出するためのプロファイリングを指す。

[0109]場合によっては、ロードとストアとの間のアドレスエイリアシングについて動的にチェックすることによって、ストア対ロード転送が生じないことをチェックすることが可能であるため、ロードストアエイリアシングのチェックが用いられる。

[0110]１つの実施形態では、ＪＩＴは、コードをインストルメントするか、又は分岐プロファイリング命令等の特殊な命令を用いるか、又はロード命令をチェックするか、又はストア命令をチェックすることができる。

[0111]説明の目的で、上記の説明は、包括的であることも、本発明を限定することも意図していない特定の実施形態を参照する。上記の教示に整合する多くの変更形態及び変形形態が可能である。実施形態は、当業者が特定の使用に適することができるような様々な変更形態を有する本発明及びその様々な実施形態を最も良好に理解することを可能にするために、本発明及びその実際の用途の原理を最も良好に説明するために選択及び説明された。

Claims (20)

1. アグノスティックランタイムアーキテクチャのためのシステムアーキテクチャであって、
   システムエミュレーション／仮想化変換器と、
   アプリケーションコード変換器と、
   システム変換器とを備え、前記システムエミュレーション／仮想化変換器及び前記アプリケーションコード変換器がシステムエミュレーションプロセスを実施し、前記システム変換器が、ゲストイメージからのコードを実行するためにシステム変換プロセスを実施し、前記システム変換器は、
   複数のゲスト命令にアクセスするためのゲストフェッチロジック構成部と、
   前記ゲストフェッチロジック構成部及び分岐予測構成部に結合され、前記複数のゲスト命令をアセンブルしてゲスト命令ブロックにするためのゲストフェッチバッファと、
   前記ゲストフェッチバッファに結合された第１のレベルの変換テーブル及び第２のレベルの変換テーブルを含み、前記ゲスト命令ブロックを対応するネイティブ変換ブロックに変換するための複数の変換テーブルと、
   前記変換テーブルに結合され、前記対応するネイティブ変換ブロックを記憶するためのネイティブキャッシュと、
   前記ネイティブキャッシュに結合され、前記ゲスト命令ブロックと、対応するネイティブ変換ブロックとのマッピングを記憶するための変換ルックアサイドバッファと、
   を更に備え、
   ゲスト命令の後続の要求時に、前記変換ルックアサイドバッファは、ヒットが生じたか否かを判断するようにインデックス付けされ、前記マッピングは、前記ゲスト命令が前記ネイティブキャッシュ内に対応する変換されたネイティブ命令を有することを示し、
   前記ヒットに応答して、前記変換ルックアサイドバッファは、前記変換されたネイティブ命令を実行のために転送する、システム。
2. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、システムメモリに記憶された変換テーブルバッファとコヒーレントに維持される高速低レイテンシキャッシュとして実施される、請求項１に記載のシステム。
3. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、ゲスト命令をネイティブ命令に置換するための置換フィールドと、前記第１のレベルの変換テーブル及び第２のレベルの変換テーブルを制御するための制御フィールドとを含む、請求項１に記載のシステム。
4. 前記第１のレベルの変換テーブルを用いて、前記ゲスト命令における第１のレベルの変換を行う、請求項１に記載のシステム。
5. 前記第１のレベルの変換テーブルは、複数のゲスト命令を認識するのに用いられるハッシュを含む、請求項４に記載のシステム。
6. 前記複数のゲスト命令は、少なくとも１つのプレフィックスゲスト命令と、前記プレフィックスゲスト命令に関連付けられた複数のオペコードとを含む、請求項５に記載のシステム。
7. プロセッサのための命令を変換するためのシステムであって、
   システムエミュレーション／仮想化変換器と、
   アプリケーションコード変換器と、
   システム変換器とを備え、前記システムエミュレーション／仮想化変換器及び前記アプリケーションコード変換器がシステムエミュレーションプロセスを実施し、前記システム変換器が、ゲストイメージからのコードを実行するためにシステム変換プロセスを実施し、前記システム変換器は、
   複数のゲスト命令にアクセスするためのゲストフェッチロジック構成部と、
   前記ゲストフェッチロジック構成部及び分岐予測構成部に結合され、前記複数のゲスト命令をアセンブルしてゲスト命令ブロックにするためのゲストフェッチバッファと、
   前記ゲストフェッチバッファに結合された第１のレベルの変換テーブル及び第２のレベルの変換テーブルを含み、前記ゲスト命令ブロックを対応するネイティブ変換ブロックに変換するための複数の変換テーブルと、
   前記変換テーブルに結合され、前記対応するネイティブ変換ブロックを記憶するためのネイティブキャッシュと、
   前記ネイティブキャッシュに結合され、前記ゲスト命令ブロックと、対応するネイティブ変換ブロックとのマッピングを記憶するための変換ルックアサイドバッファと、
   を更に備え、
   ゲスト命令の後続の要求時に、前記変換ルックアサイドバッファは、ヒットが生じたか否かを判断するようにインデックス付けされ、前記マッピングは、前記ゲスト命令が前記ネイティブキャッシュ内に対応する変換されたネイティブ命令を有することを示し、
   前記ヒットに応答して、前記変換ルックアサイドバッファは、前記変換されたネイティブ命令を実行のために転送する、システム。
8. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、システムメモリに記憶された変換テーブルバッファとコヒーレントに維持される高速低レイテンシキャッシュとして実施される、請求項７に記載のシステム。
9. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、ゲスト命令をネイティブ命令に置換するための置換フィールドと、前記第１のレベルの変換テーブル及び第２のレベルの変換テーブルを制御するための制御フィールドとを含む、請求項７に記載のシステム。
10. 前記第１のレベルの変換テーブルを用いて、前記ゲスト命令における第１のレベルの変換を行う、請求項７に記載のシステム。
11. 前記第１のレベルの変換テーブルは、複数のゲスト命令を認識するのに用いられるハッシュを含む、請求項１０に記載のシステム。
12. 前記複数のゲスト命令は、少なくとも１つのプレフィックスゲスト命令と、前記プレフィックスゲスト命令に関連付けられた複数のオペコードとを含む、請求項１１に記載のシステム。
13. 命令を変換する方法を実施するマイクロプロセッサであって、
    マイクロプロセッサパイプラインと、
    システムエミュレーション／仮想化変換器と、
    アプリケーションコード変換器と、
    システム変換器とを備え、前記システムエミュレーション／仮想化変換器及び前記アプリケーションコード変換器がシステムエミュレーションプロセスを実施し、前記システム変換器が、ゲストイメージからのコードを実行するためにシステム変換プロセスを実施し、前記システム変換器は、
    複数のゲスト命令にアクセスするためのゲストフェッチロジック構成部と、
    前記ゲストフェッチロジック構成部及び分岐予測構成部に結合され、前記複数のゲスト命令をアセンブルしてゲスト命令ブロックにするためのゲストフェッチバッファと、
    前記ゲストフェッチバッファに結合された第１のレベルの変換テーブル及び第２のレベルの変換テーブルを含み、前記ゲスト命令ブロックを対応するネイティブ変換ブロックに変換するための複数の変換テーブルと、
    前記変換テーブルに結合され、前記対応するネイティブ変換ブロックを記憶するためのネイティブキャッシュと、
    前記ネイティブキャッシュに結合され、前記ゲスト命令ブロックと、対応するネイティブ変換ブロックとのマッピングを記憶するための変換ルックアサイドバッファと、
    を更に備え、
    ゲスト命令の後続の要求時に、前記変換ルックアサイドバッファは、ヒットが生じたか否かを判断するようにインデックス付けされ、前記マッピングは、前記ゲスト命令が前記ネイティブキャッシュ内に対応する変換されたネイティブ命令を有することを示し、
    前記ヒットに応答して、前記変換ルックアサイドバッファは、前記変換されたネイティブ命令を実行のために転送する、マイクロプロセッサ。
14. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、システムメモリに記憶された変換テーブルバッファとコヒーレントに維持される高速低レイテンシキャッシュとして実施される、請求項１３に記載のマイクロプロセッサ。
15. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、ゲスト命令をネイティブ命令に置換するための置換フィールドと、前記第１のレベルの変換テーブル及び第２のレベルの変換テーブルを制御するための制御フィールドとを含む、請求項１３に記載のマイクロプロセッサ。
16. 前記第１のレベルの変換テーブルを用いて、前記ゲスト命令における第１のレベルの変換を行う、請求項１３に記載のマイクロプロセッサ。
17. 前記第１のレベルの変換テーブルは、複数のゲスト命令を認識するのに用いられるハッシュを含む、請求項１６に記載のマイクロプロセッサ。
18. 前記複数のゲスト命令は、少なくとも１つのプレフィックスゲスト命令と、前記プレフィックスゲスト命令に関連付けられた複数のオペレーションコードとを含む、請求項１７に記載のマイクロプロセッサ。
19. 前記第１のレベルの変換テーブル及び前記第２のレベルの変換テーブルは、複数のマスク及び複数のタグを含み、前記タグはパターンマッチを決定し、前記マスクは、パターンの非関連ビットを隠す、請求項１３に記載のマイクロプロセッサ。
20. 前記複数のマスク及び前記複数のタグは設定可能なデコードを可能にするようにロード可能なソフトウェアである、請求項１９に記載のマイクロプロセッサ。

Images