(57)【特許請求の範囲】
【請求項１】
装置であって、
複数のエントリを有するブレークポイントキャッシュであって、前記複数のエントリの各エントリは、当該エントリに対応する命令格納装置に格納されている命令セット内の少なくとも１つの命令が変換キャッシュに格納されている変換済みコードと関連付けられているか否かを示すエミュレーションインジケータを格納する、ブレークポイントキャッシュと、
複数のエントリを有するマップキャッシュであって、前記複数のエントリの各々は、ソース命令セットアーキテクチャ（ＩＳＡ）命令の位置と、前記ソースＩＳＡ命令の前記変換キャッシュに格納されている変換済みコードの位置との間のマッピングを格納する、マップキャッシュと、
前記ブレークポイントキャッシュと前記マップキャッシュとに連結されて、前記ブレークポイントキャッシュの対応するエミュレーションインジケータおよび前記マップキャッシュのマッピングのうち少なくとも１つに基づいて、直接実行モードからエミュレーション実行モードへと前記装置の制御をジャンプさせるか否かを判断するロジックと、
前記ブレークポイントキャッシュに連結された命令キャッシュと、
を備え、
制御移譲命令が前記ブレークポイントキャッシュのエントリを含まない場合に、前記命令格納装置に格納されている前記命令セット用のエミュレーションインジケータを格納するブレークポイントテーブルにアクセスし、
前記命令キャッシュに命令が書き込まれるとき、前記ブレークポイントキャッシュから前記命令キャッシュの対応するエントリへとエミュレーションインジケータを格納する、
装置。
【請求項２】
前記制御移譲命令が前記マップキャッシュの対応するエントリを含まない場合、エミュレーションエンジンは、隠されたメモリに格納されているマップテーブルにアクセスして前記マッピングを取得し、前記マッピングを前記マップキャッシュのエントリに格納する請求項１に記載の装置。
【請求項３】
前記命令キャッシュと実行ユニットとの間に連結された命令復号器と、前記命令キャッシュと前記実行ユニットとの間に連結されたバイパス経路とをさらに備え、前記エミュレーション実行モードにおいて命令を前記実行ユニットに直接提供する請求項２に記載の装置。
【請求項４】
前記装置はプロセッサを備え、前記ロジックはジャンプ命令に従って前記ブレークポイントキャッシュにアクセスする請求項１に記載の装置。
【請求項５】
前記プロセッサは、前記エミュレーション実行モードにより、対応するマイクロアーキテクチャハードウェアが前記プロセッサに存在しないＩＳＡの命令を実行する請求項４に記載の装置。
【請求項６】
前記プロセッサの前記マイクロアーキテクチャハードウェアは、前記ＩＳＡとは異なる第２のＩＳＡのものである請求項５に記載の装置。
【請求項７】
前記プロセッサは、部分的なエミュレーションモデルに従って動作するハードウェア／ソフトウェア協調設計プロセッサである請求項４に記載の装置。
【請求項８】
前記プロセッサは、ＩＳＡの第１の命令セットを実行する第１のマイクロアーキテクチャハードウェアを含むが、前記ＩＳＡの拡張に対応する少なくとも１つの第２の命令を実行するマイクロアーキテクチャハードウェアは含まない請求項４に記載の装置。
【請求項９】
前記変換キャッシュは、前記少なくとも１つの第２の命令を実行するコードを含む請求項８に記載の装置。
【請求項１０】
プロセッサの第１の格納装置のエントリにアクセスして、命令ポインタに関連付けられたメモリセグメントがエミュレーションエンジンにより制御されるコードを含むか否かを判断する段階と、
前記判断の結果が肯定的であった場合、前記命令ポインタから取得した値を利用して、第１のテーブル内のエントリにアクセスする段階であって、前記第１のテーブル内の複数のエントリの各々は変換済みコードの少なくとも一部分を格納する段階と、
制御移譲命令が前記第１の格納装置のエントリを含まない場合に、エミュレーションインジケータを格納するブレークポイントテーブルにアクセスする段階と、
前記第１の格納装置に連結された命令キャッシュに命令を書き込むとき、前記第１の格納装置から、前記命令キャッシュの対応するエントリへとエミュレーションインジケータを格納する段階と、
前記第１のテーブル内のエントリが前記命令ポインタに対応する場合、前記プロセッサの実行ユニットの当該エントリに格納されている前記変換済みコードを実行する段階と、
を備える方法。
【請求項１１】
前記第１のテーブル内のエントリの情報を用いてインラインチェックを行い、前記エントリが前記命令ポインタに対応するか否かを判断する段階をさらに備える請求項１０に記載の方法。
【請求項１２】
前記第１のテーブル内のエントリが前記命令ポインタに対応していない場合、
前記エミュレーションエンジンに制御を移譲して、前記命令ポインタに関連付けられている変換済みコードの位置を判断させる段階と、
変換キャッシュ内の前記変換済みコードのアドレスを取得して、前記プロセッサの前記実行ユニットで前記変換済みコードを実行する段階とをさらに備える請求項１１に記載の方法。
【請求項１３】
前記プロセッサは、部分的なエミュレーションモデルに従って動作するハードウェア／ソフトウェア協調設計プロセッサである請求項１０に記載の方法。
【請求項１４】
前記メモリセグメントに関連付けられているベクトルにアクセスして、前記命令ポインタに対応する前記メモリセグメントの一部分が前記エミュレーションエンジンの制御下にあるコードを含むか否かを判断する段階をさらに備える請求項１０に記載の方法。
【請求項１５】
前記命令ポインタに対応する前記メモリセグメントの前記一部分が前記エミュレーションエンジンの制御下にあるコードを含まない場合、システムメモリのユーザから可視である部分にアクセスして、前記命令ポインタについて実行可能なコードを取得する段階をさらに備える請求項１４に記載の方法。
【請求項１６】
前記エミュレーションエンジンの制御下にあるコードが変換キャッシュに格納されている場合、前記一部分に関連付けられている前記ベクトルの第１のインジケータを設定して、前記エミュレーションエンジンの制御下にあるコードの存在を示す段階をさらに備える請求項１４に記載の方法。
【請求項１７】
前記第１の格納装置にアクセスする前に変換テーブルにアクセスして、前記命令ポインタが前記変換テーブルのいずれかのエントリに関連付けられているか否かを判断する段階をさらに備え、
前記変換テーブル内の複数のエントリの各々は、命令ポインタの値と、変換キャッシュにおける前記命令ポインタの値の変換済みコードの開始アドレスとを格納する請求項１０に記載の方法。
【請求項１８】
前記命令ポインタの値が前記変換テーブルのエントリのいずれにも格納されていない場合に限って前記第１の格納装置にアクセスする段階をさらに備える請求項１７に記載の方法。
【請求項１９】
直接実行モードで第１の命令を実行し、エミュレーション実行モードで第２の命令についてエミュレーションエンジンにより生成される変換済みコードを実行する少なくとも１つの実行ユニットを有するプロセッサと、
前記プロセッサに連結されたＤＲＡＭとを備えるシステムであって、
前記プロセッサは、
複数のエントリを有するブレークポイントキャッシュであって、前記複数のエントリの各エントリは、当該エントリに対応する命令格納装置に格納されている命令セット内の少なくとも１つの命令が変換キャッシュに格納されている変換済みコードと関連付けられているか否かを示すエミュレーションインジケータを格納する、ブレークポイントキャッシュと、
複数のエントリを有するマップキャッシュであって、前記複数のエントリの各々は、ソース命令セットアーキテクチャ（ＩＳＡ）命令の位置と、前記ソースＩＳＡ命令の前記変換キャッシュに格納されている変換済みコードの位置との間のマッピングを格納する、マップキャッシュと、
前記ブレークポイントキャッシュと前記マップキャッシュとに連結されて、前記ブレークポイントキャッシュの対応するエミュレーションインジケータおよび前記マップキャッシュのマッピングのうち少なくとも１つに基づいて、直接実行モードからエミュレーション実行モードへと前記システムの制御をジャンプさせるか否かを判断するロジックと、
前記ブレークポイントキャッシュに連結された命令キャッシュとを有し、
前記プロセッサは、制御移譲命令が前記ブレークポイントキャッシュのエントリを含まない場合に、前記命令格納装置に格納されている前記命令セット用のエミュレーションインジケータを格納するブレークポイントテーブルにアクセスし、
前記プロセッサは、前記命令キャッシュに命令が書き込まれるとき、前記ブレークポイントキャッシュから前記命令キャッシュの対応するエントリへとエミュレーションインジケータを格納し、
前記プロセッサは前記第１の命令についてのハードウェアサポートを含むが、前記第２の命令の少なくとも一部についてのハードウェアサポートは含まず、
前記第１の命令および前記第２の命令は前記ＤＲＡＭに未修正のまま残存するシステム。
【請求項２０】
前記プロセッサは第３のキャッシュをさらに有し、前記第３のキャッシュが含む複数のエントリの各々は、メモリブロックの対応するサブセットが前記変換済みコードに関連付けられているか否かを示すビットを複数含むベクトルを格納する請求項１９に記載のシステム。
【請求項２１】
前記プロセッサは、前記ブレークポイントキャッシュと、前記マップキャッシュと、前記第３のキャッシュとに連結されたロジックをさらに有し、前記ロジックは、前記マップキャッシュからの変換キャッシュアドレス、前記ブレークポイントキャッシュからの対応するブレークポイントインジケータ、および、前記第３のキャッシュからの対応するビットのうち少なくとも１つに基づいて、前記直接実行モードから前記エミュレーション実行モードへとプロセッサ制御をジャンプさせるか否かを判断する請求項２０に記載のシステム。
【請求項２２】
前記プロセッサはアドレスハッシュ生成器をさらに有し、前記アドレスハッシュ生成器は、前記ブレークポイントキャッシュへのアクセスに利用されるアドレスのハッシュを生成し、前記ハッシュに基づいてハッシュテーブルのエントリにアクセスして前記ハッシュテーブルのエントリに格納されている変換済みコードの実行を開始する請求項２０に記載のシステム。
【請求項２３】
前記プロセッサは、前記エミュレーション実行モードにより前記プロセッサのＩＳＡとは別のＩＳＡの命令を実行する請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
現代のマイクロプロセッサは殆どのコンピュータシステムの要である。概してこれらプロセッサは、命令を受信して命令に応じた動作を行って動作する。アプリケーションプログラムおよびオペレーティングシステム（ＯＳ）の動作には、命令がプロセッサで受信され、これら命令を、プロセッサハードウェア上での実行に適した１以上のより小さい動作（マイクロ命令（ｕｏｐｓ）と称されることも多い）に復号されることがある。プロセッサのなかには、ある種の命令セットアーキテクチャ（ＩＳＡ）命令を直接実行するハードウェアフィーチャを有さないものがある。この理由から、命令を直接ハードウェア上で実行可能なｕｏｐｓに復号化するのである。
【０００２】
これとは別の実装例として、プロセッサハードウェアと協調設計されたエミュレーションソフトウェア層が設けられるような、仮想マシン（ＶＭ）を協調設計する方法がある。協調設計されるＶＭは、ソースＩＳＡと称される標準ＩＳＡ（一例としてはｘ８６  ＩＳＡ）を実装している。ＯＳおよびアプリケーションプログラム両方を含む従来のソフトウェアを、ソースＩＳＡにコンパイルする。そして、協調設計されるＶＭのハードウェアは、特別な性能および／またはエネルギー効率特性を持つフィーチャを有する、そのハードウェア実装専用に設計された対象ＩＳＡを実装する。対象ＩＳＡは、ｕｏｐｓと同レベルにあり、これら一式のｕｏｐｓと同一であってもよい。
【０００３】
協調設計されるＶＭに属するエミュレーションソフトウェアは、アプリケーション／ＯＳのソースＩＳＡソフトウェアを解釈したり、最適化された対象命令列に直接変換したりすることにより、実行する。これらの変換は、パフォーマンス上の利得および／またはエネルギー効率の向上を前提としている。
【０００４】
エミュレーションプロセスは典型的に以下のように行われる。最初に遭遇したコード（ソースＩＳＡ命令）に対して解釈を行う。そして動的プロファイリングその他の手段を利用して、頻繁に実行されるコード領域（ホットスポット）が発見されると、これを対象ＩＳＡに変換する。最適化は変換プロセスの一貫として行われることが多く、多用されるコードを後でさらに最適化することができる。変換済みコード領域は、後の再利用のために変換キャッシュに保持しておく。変換キャッシュはエミュレーションソフトウェアにより管理され、全てのアプリケーション／ＯＳソフトウェアから隠されているメモリのあるセクションに保持される。アプリケーション／ＯＳソフトウェアは従来の（可視の）メモリに保持される。
【０００５】
協調設計されるＶＭを利用する前述したプロセッサ実装では、エミュレーションソフトウェアが全アプリケーション／ＯＳソフトウェアをエミュレートするような、全エミュレーションが行われている。全エミュレーションを行うときの不利益な点は、実行前に全てのコードを解釈および／または変換する必要があり、最初に遭遇したソフトウェア領域でのパフォーマンスが低くなる虞があることである。
【図面の簡単な説明】
【０００６】
【図１】本発明の一実施形態における、プロセッサおよびメモリを含む協調設計環境のブロック図である。
【図２】本発明の一実施形態における、エミュレーションエンジンのコンポーネントのブロック図である。
【図３】本発明の一実施形態における方法のフロー図である。
【図４Ａ】本発明の一実施形態におけるＴＬＢ（変換索引バッファ）エントリを示す。
【図４Ｂ】本発明の別の実施形態における別のＴＬＢエントリを示す。
【図５】本発明の一実施形態におけるビットベクトル構造およびＴＬＢのブロック図である。
【図６】本発明の一実施形態における、直接ハッシュテーブルにアクセスする直接ハッシュ演算のブロック図である。
【図７】本発明の一実施形態におけるプロセッサのブロック図である。
【図８】本発明の一実施形態における動作を示すブロック図である。
【図９】本発明の別の実施形態におけるプロセッサのブロック図である。
【図１０】本発明の一実施形態における、エミュレーションエンジンの動作のフロー図である。
【図１１】本発明の一実施形態におけるシステムのブロック図である。
【発明を実施するための形態】
【０００７】
様々な実施形態において、協調設計されるマイクロプロセッサ等のプロセッサに部分的なエミュレーションを実装する場合がある。部分的なエミュレーションを実行するべく、プロセッサは２つのモードを有することができ、第１のモードではソースＩＳＡの命令（これは一実施形態ではソースＩＳＡコード）を直接実行し、このソースＩＳＡコードは、例えばインテルアーキテクチャ（ＩＡ）（登録商標）プロセッサ用のＩＳＡのｘ８６コードであってよく、第２のモードでは対象ＩＳＡの命令を実行し、この対象ＩＳＡはコードキャッシュ等の変換キャッシュに格納されている、変換され最適化されたコードであってよい。ここで言う第１のモードとは、「直接モード」または「直接実行モード」のことであってよく、ここで言う第２のモードとは、「エミュレーションモード」または「エミュレーション実行モード」のことであってよい。
【０００８】
アプリケーション／ＯＳソフトウェアは、その一部が、通常の方法でｕｏｐｓから直接フェッチおよび実行されてよく、他の部分が、対象命令セットに変換されることでエミュレートされてよい。このプロセスを部分的なエミュレーションと称する。部分的なエミュレーションにおいては、ソフトウェアは先ず良好なパフォーマンスで実行された後で、プロファイリング情報に基づいて選択される頻繁に実行される領域を変換して変換キャッシュに格納する。この方法における利点は、ソフトウェアに最初に遭遇したときのパフォーマンス損失を下げつつ、頻繁に実行されるソフトウェアについてパフォーマンスおよび／または電力効率上の利得を提供することができる点である。
【０００９】
部分的なエミュレーションを実現するために、従来のメモリに保持されている命令の直接実行および隠されたメモリに保持されている変換済み命令によるエミュレーションの間の制御を移譲するメカニズムを提供することができる。エミュレーションソフトウェアから従来のアプリケーション／ＯＳソフトウェアへの制御の移譲はエミュレーションソフトウェアにより実行される分岐およびジャンプ命令により実行される。従来のソフトウェアから変換済みコードへの制御の移譲は、従来のソフトウェアを「パッチング」で修正することにより、または、従来のソフトウェアに分岐またはジャンプを配置することにより行うことができる。しかしこれら従来のメモリへの修正は、ソースＩＳＡの正確なエミュレーションを大幅に複雑化させる。
【００１０】
実施形態は、従来のアプリケーション／ＯＳソフトウェアをパッチしたり修正したりせずに、従来のソフトウェアからエミュレーションソフトウェアへの移譲を行う。この実施形態では、エミュレーションへの移譲が必要となりうる従来のソフトウェアの領域をハードウェアが自動検出するブレークポイントメカニズムを利用する。そして、ハードウェアおよびソフトウェアの何らかの組み合わせにより、エミュレーションプロセスにより、変換キャッシュに保持されているエミュレーションコードへの移譲を行う。
【００１１】
直接モードにおいて、変換の存在する点に命令ポインタ（ＩＰまたはＥＩＰ）が到達すると、プロセッサはエミュレーション実行モードにスイッチするか、あるいは、変換キャッシュに格納されている変換へ直接ジャンプする、あるいは、エミュレーションエンジンへ高速トラップする場合もある。そして、エミュレーションエンジンは、１以上のテーブル、バッファ、またはキャッシュ（例えばハッシュテーブル）を介して変換エントリアドレスを探して遷移を行う。
【００１２】
これとは異なるハードウェアの実装も可能である。一実施形態では、オリジナルからエミュレーションの実行遷移を高速に行わせるハードウェア技術で、「ソースＩＰ」から「変換済みＩＰ」へのテーブルを利用することができる。エミュレーションエンジンは、これら構造に、ソースＩＳＡコードアドレスおよび対応する変換アドレス（対象アドレス）の変換キャッシュ内の位置を格納する。様々な実施形態では、これらテーブル（および／またはその一部分）を異なる位置に格納することもできる。そしてプロセッサは、ソースＩＰがテーブルエントリに整合すると、変換にジャンプすることができる。しかし、このように完全な関連付けハードウェア構造は、サイズ的に小さすぎて、未変換のコードを変換済みコードにする数千の経路を処理することができない場合が多い。従ってこのテーブルは、パフォーマンス最適化として利用され、完全な解決法としては利用されない。
【００１３】
このように変換には数千のエントリポイントがあるので、実施形態は、制御がこれらエントリポイントのいずれかに達するとこれら変換への高速な遷移を可能とさせることができる。このような遷移は、制御フローが通常は長い範囲にわたり予測不可能であって次に到達するエントリポイントを予測することが難しいという理由から複雑になりうる。従って実施形態では、現在のＥＩＰについて利用可能な変換があるか否かを判断し、且つ、ある場合にはこの変換用のエントリアドレスを見つける方法を判断する。
【００１４】
一実施形態では、エミュレーションエンジンが管理するハードウェアおよびブレークポイントテーブルにブレークポイントキャッシュを実装することができる。エミュレーションエンジンは、適宜、テーブルからキャッシュにエントリをコピーする。さらなる実施形態では、命令ＴＬＢ（変換索引バッファ）エントリと関連付けられたブレークポイントビットを含み、エミュレーションエンジンがブレークポイントテーブルのエントリを、命令ＴＬＢエントリを作成するときに命令ＴＬＢにコピーしてよい。最適化として、ブレークポイントビットは、実行のみのビットに組み合わせることができる。またさらに、ブレークポイントビットは、命令キャッシュラインと関連付けることができ、ハードウェアが、新たなラインを命令キャッシュに入力するときに、ブレークポイントキャッシュからエントリをコピーすることができる。
【００１５】
様々な実施形態の動作のさらなる理解を促すべく、本発明の一実施形態における協調設計される仮想マシンとして実装されるプロセッサのコンポーネントを表すと有益であろう。図１に示すように、協調設計される環境１０は、プロセッサ５とメモリ２０とを含み、メモリ２０は、一実施形態ではＤＲＡＭ等のシステムメモリであってよい。示されているように、プロセッサ５は任意のマイクロアーキテクチャであってよく、例えばポイントツーポイントインターコネクト、バスその他の様式によりメモリ２０に連結されてよい。メモリ２０の可視部分、つまり第１の部分３０では、１以上のオペレーティングシステムおよびアプリケーションプログラム３８を格納することができる。この部分は、ユーザレベルコード（つまりアプリケーションプログラム３８）から、および、ＯＳ（ＯＳ３５およびプログラム３８）から見えることから、「可視」であると称する。これらプログラムで実行される命令の種類に応じて、通信を直接プロセッサ５との間で、例えばこれら命令を処理するプロセッサに存在する命令復号器を利用することにより、行うことができる。
【００１６】
また、変換済みコードを利用して最適化することのできる様々なコード列について、または、マイクロアーキテクチャのサポートが提供されない列について、実施形態では、メモリの隠された部分（つまり第２の部分４０）を利用して、変換済みコードをプロセッサ５に提供することができる。特に示されているように、ＯＳ３５およびアプリケーションプログラム３８の両方がエミュレーションエンジン４５と通信してよく、これには、解釈、変換、および最適化メカニズムを含むランタイム実行ユニットが含まれてよい。隠されたメモリ４０は、ＯＳまたはアプリケーションプログラムから不可視でありアクセス不可能である。従ってエミュレーションエンジン４５は、変換キャッシュ４８にコードおよびアドレス情報を提供し、これにはプロセッサ５に実行用に提供されうる変換済みコードが含まれてよい。一実施形態では、変換キャッシュ４８に格納されるコードを暗号化することができる。この変換済みコードは、プロセッサの基礎マイクロアーキテクチャについて書き込みおよび最適化することができる（例えば対象ＩＳＡコード）。
【００１７】
示されているように、協調設計プロセッサであってよいプロセッサ５は、ＯＳまたはアプリケーションプログラムから命令を直接受信することのできる命令フェッチャ６等のフロントエンドユニットを含む。これらの命令はマクロ命令（例えばアプリケーションプログラムのユーザレベルの命令に対応して）であってよいが、復号器７を利用して復号することができ、この復号器７は、命令を復号して、対応するｕｏｐｓ（例えばプロセッサ５のマイクロコード格納装置に提示される）にアクセスすることができる。そして復号器７はｕｏｐｓを１以上の実行ユニット８に提供することができ、この実行ユニット８が様々なＡＬＵ（arithmetic logic unit）、専用ハードウェア、その他の種類の計算ユニットを含むことができる。これら命令からの結果は、退避ユニット９に提供されてよく、退避ユニット９は命令を退避させて、誤りまたは例外が生じなければ、結果をプロセッサのアーキテクチャ状態にプログラム順に格納する。インオーダの機械として記載したが、実施形態は、アウトオブオーダの機械として実装されてもよい。
【００１８】
ソースＩＳＡコードをプロセッサ５の基礎ハードウェア上で直接実行することのできる図１に示すような部分的なエミュレーションモデルを利用して、限られた量のコードのみに（例えば所謂「ホットな」コードに）エミュレーションサポートを提供することで、実施形態では、効率的な動作を提供することができる。つまり命令を基礎ハードウェアで直接実行することができるので、エミュレーションはクリティカルな経路に存在しなくなり、アプリケーション始動レイテンシーを増すことがない。このようにして、解釈（非常に大きなオーバヘッドを生じうる）および変換に纏わるオーバヘッドを回避することができる。変換は、頻繁に実行されるコードに対してのみ実行され、一部の実施形態では、バックグランドにて比較的低い優先度で行われる。対象ＩＳＡに対するコード変換が完了して変換キャッシュ（例えば図１の変換キャッシュ４８）に格納した後に、対象ＩＳＡコードの実行を、基礎ハードウェア上に直接行うことができる。
【００１９】
また場合によっては、エミュレーションエンジンをバックオフさせて、変換を行わないようにすることができる。例えば、連続する自己修正ホットコード等の異なる場合においては、エミュレーションエンジンがこれらコードを変換しない選択を行い、これらの変換に伴う複雑性を回避することができる。コードを変換しない同様の決定は、他の複雑な特徴（例えばレガシーリアルモードまたはリング０コード）でも行うことができる。様々な実施形態では、パフォーマンスが重要なユーザモードコード（つまり、ホットコードとして決定されたようなコード）用に、コードの頻繁な実行を示すプロファイリング情報等により、変換を取っておくことができる。
【００２０】
様々な実施形態では、任意のコードセグメントの実行頻度が閾値レベルに合致した場合にエミュレーションエンジンが変換を行ってもよい。一例としては、閾値を設定してバイナリ変換を開始して、一定の期間に少なくとも閾値の回数だけコードを実行する。こうすることにより、さらに、変換キャッシュスペースの要件が比較的少なくて済むようになる。本発明の一実施形態における部分的なエミュレーションを利用することで、基礎プロセッサハードウェアを再設計することなく命令セット拡張を効率的に実装することができる。例えばＩＳＡに拡張として追加されるグラフィックス命令について考える。命令の頻繁な実行は、動的に変換して完全にトランスペアレントな形で最適化することができる。あるアプリケーションがこれら命令を含まない場合には、オーバヘッドなしに基礎ハードウェア上での実行を続けることができる。またさらに、本発明の一実施形態におけるエミュレーションを利用することで、基礎となるマイクロアーキテクチャがサポートしていない新たな命令のエミュレーションを高速に行うことができる。
【００２１】
従来のメモリのソースコードから、変換キャッシュの変換済みコードへと制御を移譲するときの基本的な仮定は、エミュレーションプロセスにより、従来のメモリにおける命令が、パッチ等によって決して修正されないということである。リソース命令スペースが修正されないので、ハードウェア実装されるブレークポイントを提供して、変換キャッシュに変換が存在するソース命令領域を示すのに利用する。そして直接実行する間に、変換されていないソース命令のフローが変換済みコードの領域を通過する場合、ブレークポイントは、制御をエミュレーションエンジンに強制的に移譲して、後に、変換キャッシュの適切な対象命令に制御を移譲させることができる。
【００２２】
ブレークポイントインジケータまたはビットはこのようにして、ソースＩＳＡ命令を保持する従来のメモリのアドレスに関連付けられる。ブレークポイントビットは、特定のバイトアドレスに割り当てられてよい、または、例えば１２８バイトといったより大きな領域のアドレスに割り当てられてよい。つまり、命令メモリの１２８バイトのチャンクごとについてシングルブレークポイントビットが設けられてよい。一実施形態ではチャンクのサイズは、命令キャッシュラインのサイズと同じであってよい。
【００２３】
ブレークポイントビットは、隠されたメモリに格納されているブレークポイントテーブルに保持され、エミューレションエンジンソフトウェアにより維持される。このようにブレークポイントテーブルは、複数の方法で実装可能なソフトウェアデータ構造である。例えばハッシュテーブルであってよい。任意のソース命令のＩＰ値が変換キャッシュの変換済みコードの領域のエントリポイントに対応する場合、ソース命令のメモリのチャンクに対応するブレークポイントビットを１に設定する。
【００２４】
直接実行する間に、ＩＰアドレスがブレークポイントビットの設定されたメモリのチャンクに含まれる命令への命令フェッチ分岐またはジャンプが設定されている場合には、即座に制御の移譲またはブレークポイントトラップがエミュレーションエンジンへ行われるということである。
【００２５】
エミュレーションエンジンへのトラップが生じると、エミュレーションエンジンは、もしあれば、ソースＩＳＡ命令位置と対応する変換済みコードとの間のマッピングを格納しているマップテーブルを利用することができる。マップテーブルマップテーブルは、ソース命令のＩＰ値が、エントリポイントが変換キャッシュに存在するコード領域に対応するか否かを判断するのに利用することができる。判断結果が肯定的である場合、エミュレーションエンジンは、変換キャッシュのエントリポイントに分岐する。マップテーブルにこのエントリがない場合には、エミュレーションエンジンはＩＰ値のソースＩＳＡコードに戻り、ハードウェアが直接実行を再開する。変換がマップテーブルに存在しない理由は、ブレークポイントビットがチャンクの粒度であり、任意のチャンクのＩＰ値が複数の変換キャッシュエントリポイントアドレスに対応していることがあるからである。変換済みコード領域のエントリポイントに実際に対応するこれらＩＰアドレスのみについてマップテーブルエントリが存在する。
【００２６】
様々な実施形態では、プロセッサは、最も最近利用されたブレークポイントテーブルエントリを格納するハードウェアブレークポイントキャッシュを含むことができる。前述したように、ブレークポイントテーブルのエントリは、コード領域が変換され、変換キャッシュに配置される時点で、エミュレーションエンジンにより作成される。エミュレーションエンジンは、ブレークポイントキャッシュにミスがあったときに（そしてエミュレーションエンジンにマイクロトラップがあったときに）ブレークポイントテーブルからブレークポイントキャッシュにブレークポイントをコピーすることで、ブレークキャッシュの内容を管理することができる。
【００２７】
これとは別の実装例も可能であり、これについては様々な図面を参照して後述する。図２を参照すると、エミューションエンジン１０は、ユーザレベルアプリケーションからもシステムソフトウェアからもアクセスされないよう隠されたシステムメモリの隠された部分等の隠されたメモリに格納することができ、これは様々なコンポーネントを含むことができる。特に、図２に示すように、エミュレーションエンジン１０は、任意のプロセッサタイプ（ｘ８６プロセッサ等）の入力されたソースＩＳＡ命令を受信するよう構成されてよいインタープリタ／トランスレータ／オプティマイザ（一般的にはトランスレータである）２０を含むことができる。トランスレータ２０は、先ず、新たに遭遇したソースＩＳＡ命令について解釈された命令を生成することができる。そしてこれら命令が頻繁に実行されていると判断されると、トランスレータ２０はこれら命令を、変換済みコード（つまり対象ＩＳＡ命令）に変換するが、これは、プロセッサの様々なマイクロアーキテクチャフィーチャ用に最適化されてよいので、変換済みコードを再生する構築モードで動作する。もちろん命令に加えて、様々な情報がトランスレータ２０に提供されてよく、これには、例えば、ＩＳＡ命令の最適化および変換を助けるプロファイリング情報、閾値およびその他の制御情報等が含まれる。このようにトランスレータ２０の出力は、対象ＩＳＡ命令（例えば最適化されたｕｏｐｓの形態の）であってよい変換済みコードである。このコードはコードキャッシュ（変換キャッシュとも称される）に提供され格納され、一実施形態ではこれはシステムメモリの隠された部分に存在していてよい。
【００２８】
エミュレーションエンジン１０は、コード実行中に情報を受信することができる。アクセスするアドレス（例えばコードアドレス）がエミュレーションエンジンに制御される必要があると判断すると、そのアドレスをアドレスハッシュオペレータ４０に提供して、アドレスハッシュオペレータ４０は、このアドレスにハッシュを行い、ハッシュ値を直接ハッシュテーブル５０に出力することができ、直接ハッシュテーブル５０は、隠されたメモリに格納されているハッシュテーブルであってよい。アドレスハッシュオペラレータから直接ハッシュテーブルへのこのジャンプは、プロセッサ制御フローの、変換済みコードへのジャンプを表してよい。直接ハッシュテーブル５０の任意のエントリには、ハッシュ値を利用してアクセスが行われ、対応するアドレスに対して有効な情報がエントリに存在する場合には、直接ハッシュテーブル５０に格納されたコードを利用して、変換済みコードの実行を即座に開始することができる。エントリ完了時に、さらに変換済みコードへのジャンプは、コードキャッシュに制御を送り、さらに変換済みコードにアクセスすることができる。
【００２９】
また、任意のアドレスの有効な変換済みコードが直接ハッシュテーブル５０に存在しない場合もある。従ってプロセッサ制御フローへジャンプさせる信号をランタイム実行ユニット３０に送ってこの状況を示し、ユニットが、ハッシュテーブル６０に格納されている情報を利用して、対応する変換済みコードの位置を知ることができるようにしてよく、ハッシュテーブル６０は、全ての変換済みコードエントリポイントについて完成されたハッシュテーブルであってよい。このハッシュテーブルは、隠されたメモリの別の部分に格納されていてよい。このメモリにヒットすると、アドレスをコードキャッシュに送って、変換済みコードの実行を開始してよい。図２の実施形態にはこの特定の実装例が示されているが、本発明の範囲はこの点に限定されない。例えば、ハッシュテーブルの代わりに、ハッシュを利用せずにアクセスされる他の構造を実装することもでき、これに関してこれから説明する。
【００３０】
別の実施形態では、ブレークポイントキャッシュをｉＴＬＢ（命令変換索引バッファ）に統合することができる。本発明の一実施形態におけるエミュレーションエンジンを利用することで、元のコードから、変換済みコードの実行へのスムーズな遷移を行うことができる。図３は、本発明の一実施形態における方法のフロー図である。図３に示すように、方法２００を利用して、任意のアドレスに変換が存在するか否かを判断して、判断結果が肯定的な場合には、変換の位置を判断することができる。図示されている方法２００は、ＴＬＢ（例えばｉＴＬＢ）等のメモリ管理ユニット構造でアドレスを受信することで開始される（ブロック２１０）。次に、このアドレスのエントリが存在するか否かを判断してよい（ダイアモンド２１５）。存在しない場合には、ページウォークを行って、アドレスを含む対応するページのエントリを取得する（ブロック２２０）。
【００３１】
そしてｉＴＬＢにエントリが存在するときには、対応するエントリが、アドレスを含むページ内に、変換済みコードの存在を示すか否かを判断することができる（ダイアモンド２３０）。後述するように、この決定は様々な方法で行うことができる。変換済みコードが示されていない場合には、通常のメモリアクセスを行って、例えばシステムメモリの要求されているページにアクセスして、要求されたアドレスの情報を取得することができる（ブロック２３５）。
【００３２】
ダイアモンド２３０で、変換済みコードがページ内のある位置について存在すると判断された場合には、制御はダイアモンド２４０に渡される。ダイアモンド２４０の決定は、エミュレーションエンジンが制御する指示のより細粒度の分析を行うのに利用することができる。特に、ダイアモンド２４０でアドレスに関連付けられているビットベクトルエントリが設定されているか否かが判断されてよい。設定されていない場合には、従来のメモリアクセスに関して前述したように、制御をブロック２３５に戻す。設定されている場合には、ビットベクトルエントリは、対応するアドレスを含むチャンク（例えば１２８バイトのチャンク））が変換済みコードを含むことを示していることになる。従って制御をブロック２４５に渡す。
【００３３】
ブロック２４５で、アドレスのハッシュを利用して、直接ハッシュテーブルのエントリにジャンプすることができる。さらに後述するように、この直接ハッシュテーブルは、隠れたメモリに存在してよい。より具体的には、アドレスハッシュに対応する直接ハッシュテーブルの任意のエントリにアクセスすることができる。直接ハッシュテーブルのサイズに対する制限により、複数のアドレスをこのテーブルのシングルエントリに関連付けて、このアドレスのコードがエントリに存在しないようにすることができる。従って、実施形態は、アクセスされたエントリに存在する情報を用いてアドレスのインラインチェックを行うことができる（ブロック２５０）。このチェックから、アドレスがエントリに関連付けられているか否かを判断することができる（ブロック２５５）。関連付けられていない場合には、制御をエミュレーションエンジンハンドラに渡し（ブロック２６５）、エミュレーションエンジンハンドラが、変換キャッシュに存在する全ての変換のマッピングを格納する完全なハッシュテーブルであるソフトウェアハッシュテーブルにアクセスする。従ってブロック２７０で、アドレスに基づいてソフトウェアハッシュテーブルのエントリにアクセスすることができる。
【００３４】
図３を参照すると、直接ハッシュテーブルの対応するエントリがアドレスハッシュに関連付けられている場合、制御はダイアモンド２５５からブロック２６０に渡され、変換済みコードの実行がエントリで継続され、これには少なくとも一部の量の変換済みコードが含まれる。エントリの最後に、変換キャッシュのアドレスにジャンプを行い、コードの実行を続ける（ブロック２８０）。ブロック２８０には、ブロック２７０から入ることもでき、完全なソフトウェアハッシュテーブルから取得する変換キャッシュのアドレスを利用して、変換済みコードの実行を開始することもできる。図３の実施形態にはこの特定の実装例が示されているが、本発明の範囲はこの点に限定されない。
【００３５】
実施形態では、エミュレーションエンジンがページの粒度制御を得ることができるように、既存のメモリ保護メカニズムを利用することができる。一実施形態では、さらなるインジケータ（例えばシングルビット）を、命令キャッシュまたはｉＴＬＢ等のプロセッサ構造の各エントリとともに格納することで、ページがエミュレーションエンジンの制御下にあるか否かを（例えば、変換コードの対応する変換コードを有するコードが含まれるか否かを）示すことができる。このビットは、エミュレーションエンジンにより管理されるが、外部から可視であるシステムアーキテクチャの一部ではない。一部の実施形態では、エミュレーションエンジンの制御下にあるビットは、ハードウェアの実行ディセーブル（ＸＤ）ビットと組み合わせられてよい。つまりこれらの実装においては、ＴＬＢエントリに存在するシングルビットを利用して、変換済みコードおよび実行ディセーブルページの両方の存在を示すことができる。この場合、エミュレーションエンジンは、生じた全ての誤りを傍受して、それらがリアルであるか（非常に稀な例外）そうではないかを判断し、前者の場合においてのみ、対応する誤りを、対象ＩＳＡコードの適切な誤りハンドラに対して報告することができる。拡張により、さらに、ビットベクトルを下記のように利用することで、より細粒度の実行制御を提供することができる。
【００３６】
図４Ａは、本発明の一実施形態におけるＴＬＢ（変換索引バッファ）エントリを示す。図４Ａに示すように、エントリ３０５は、ＶＡを格納する仮想アドレス（ＶＡ）フィールド３１０、ＰＡを格納する物理アドレス（ＰＡ）フィールド３１５、例えばシングルビット等を格納して、ＰＡフィールド３１５に格納されているアドレスが識別する対応するページが、変換キャッシュに格納されている変換済みコードを有するいずれかのコードを含むか否かを示すことのできるエミュレーションインジケータフィールド３２０等の様々なフィールドを含む。加えて図４Ａに示すように、ＸＤフィールド３２５は、対応するページが実行ディセーブル情報を含むか否かを示すシングルビット等を格納することができる。加えて、状態フィールド３３０は、属性情報等の様々な状態情報を含むことができる。図４Ｂは、エミュレーションインジケータがＸＤインジケータと組み合わされており、スペース要件を低減させることができる別の実装による別のＴＬＢエントリを示す。
【００３７】
プロセッサが直接モードのエミュレーションエンジン制御下にあるページからの命令をフェッチすると、エミュレーションエンジンに高速トラップがあり、その後利用可能な変換を取得してそれにジャンプすることができる。効率化目的からは、このリステアリング機能のエミュレーションエンジントラップハンドラへの入力は素早く行うことができ、例えば従来の例外よりも速いことがあり、処理にかかる時間が数百サイクルであってよい。こういうわけで、プロセッサは早期にプロセッサパイプラインのフロントエンドで、例えばｉＴＬＢアクセスを介して、アクセスされたコードページにエミュレーションエンジン制御下のビットが設定されているか否かを判断することができる。エミュレーションエンジントラップハンドラへのリステアリング機能は、このようにして、パイプラインのバックエンドなしに、且つ、コードの退避からトラップをトリガした分岐まで待つことなく、早期に生じさせることができる。理想的にはリステアリング機能は、数パイプラインバブル分だけのコストがかかることが好ましく、分岐予測に従って行われることが好ましい。
【００３８】
部分的な変換実装においては、エミュレーションエンジンは、最もホットなコードページからのみ変換して（例えば最もホットな上位５パーセントまたは１０パーセントのコードページ）、実行プロフィールが非常にフラットでない限りホットスポットの殆どをカバーする。ページレベルのエミュレーションエンジン制御の粒度が低いと、非効率になりうる可能性もありうる。ホットコードの局所性（locality）が低い場合、繰り返し率の低いコードが、単にそれがホットコードの同じページにあるという理由のみから変換される場合が生じうるが、これらコードは直接モードで単に実行するほうが効率的である。このオーバヘッドを減らす方法は２つ考えられる。第１の方法は、エミュレーションエンジンでエミュレーションエンジンの制御下にあるが繰り返し率の低いページであるコードの超軽量変換を生成するというものである。例えば、エミュレーションエンジンは、元のコード１：１を、対応するｕｏｐ列で、高いコストをかけてデータフロー解析または最適化を行うことなく、迅速に置き換えるといった方法が考えられる。さらに、ホットスポットプロファイリング装置をオンザフライで追加してもよい。
【００３９】
第２の方法では、エミュレーションエンジンがさらなるハードウェアサポートを利用して、さらに細粒度のエミュレーション制御を行う。一実施形態では、各コードページについては、エミュレーションエンジンは、ビットベクトル等の格納ユニットを維持して、エミュレーションエンジンコードを含むとして示されるページの副領域についてエミュレーションエンジン制御を特定することができる。例えば、４キロバイト（Ｋ）コードページごとの３２ビットベクトルがあってよく、これにより、ページの１２８バイト（Ｂ）チャンクごとにエミュレーション制御が望ましいか否かが示される。ベクトルのビットは、変換が存在するチャンクすべてについて設定されてよく、そうでなければクリアされてよい。直接モードでは、プロセッサは、ＩＰが、ビットが設定されているチャンクに達するとエミュレーションエンジンにトラップされる。このハードウェアフィーチャは、コードページの数チャンクのみがホットな変換済みコードを含み、残りが比較的コールドである場合に特に有用であると考えられる。そしてこれらチャンクのみがエミュレーション制御およびエミュレーションの実行をトリガして、残りのチャンクは、オーバヘッドをこれ以上生じることなく直接モードでの実行を続ける。
【００４０】
一実施形態では、ビットベクトルをｉＴＬＢエントリの一部として、例えば図４Ａおよび図４Ｂに示す状態フィールドに追加することができる。従って一例としては、ＴＬＢの各エントリを、対応するページのビットベクトルで拡張することができる。この代わりに、小さな直接マッピングされたキャッシュ構造を利用することもできる。ｉＴＬＢの次にこのキャッシュにアクセスを行い、これには、ページごとのシングル「エミュレーションエンジン制御下の」ビットが含まれる（図４Ａおよび図４Ｂを参照のこと）。「エミュレーションエンジン制御下の」ビットが設定されている１ページのＴＬＢエントリが直接モードにおいてアクセスされ、同時に、キャッシュに、アクセスされたチャンクに対応するビットが設定されていないビットベクトルエントリが存在する場合には、エミュレーションエンジンへのトラップを抑制することができる。
【００４１】
図５は、ビットベクトル構造がＴＬＢとは別である実装例のブロック図である。図５に示すように、入力されるアドレス４１０（例えばＩＰ値）は、さまざまな部分を含み、これには、最上位部分４１２、インデックス部分４１４、および最下位部分４１６が含まれてよい。図示されているように、最上位部分４１２は、これら仮想アドレスを対応する物理アドレスに関連付ける様々なエントリを含むｉＴＬＢ４２０に提供される仮想アドレスに対応していてよい。図５の実施形態では、ｉＴＬＢ４２０の各キャッシュエントリ４２５がＶＡフィールド４２６、ＰＡフィールド４２７、およびエミュレーションインジケータフィールド４２８を含む。もちろん、実施形態によっては状態フィールド等の他のフィールドが存在していてもよい。図示されているように、インジケータフィールド４２８からの対応するエミュレーションインジケータが制御ロジック４４０に提供されてよい。図５にさらに示すように、アドレス４１０のインデックス部分４１４がキャッシュメモリ４５０に提供され、これは、ｉＴＬＢ４２０と並列にアクセスされる小さな別個のキャッシュであってよい。図示されているように、キャッシュ４５０の各エントリ４５５は、インデックス部分４１４が対応するエントリに整合しているか否かを判断するのに利用されるタグ部分４５６を含むことができる。各エントリ４５５はさらにベクトル部分４５８を含み、これは、Ｎビットを含むことができ、このなかで各ビットがメモリページの一部に対応している。例えば３２ビットのベクトルは、１２８Ｂのチャンクをそれぞれ対応するビットに関連付けることができる。 設定されている場合は、ビットは、ページの対応するチャンクが変換済みコードを含むことを示し、クリアされている場合は、変換済みコードを含まないことを示す。提供されているインデックスを利用して、対応するエントリにアクセスして、ベクトル４５８の所与のビットをロジック４４０に出力するが、これは、ｉＴＬＢ４２０からのエミュレーションインジケータおよびベクトル４５８の出力を利用してロジック処理を行うことができる。一実施形態においては、ロジック４４０は以下のテーブル１のように動作して、対応するチャンクに対してエミュレーションエンジン制御を与えるべきか否かを判断することができる。
【表１】
0005506049.tif 000002
【００４２】
制御ロジック４４０からの出力によって、異なるアクションが行われてもよい。一実施形態では、制御ロジック４４０からのアクティブ制御信号が、変換済みコードの存在を示しており、これによりＩＰにハッシュを行い、直接ハッシュテーブルに提供させて、対応するエントリが存在する場合に実行を開始させる。あるいは、プロセッサ制御フローが、エミュレーションエンジン（例えばエミュレーションエンジンハンドラ）に直接ジャンプしてもよい。
【００４３】
様々な実施形態では、キャッシュ４５０は、コストの高いハードウェア管理を必要とせず、エミュレーションエンジンにより満たすことができる。エミュレーションエンジンへのトラップがあり、エミュレーション制御下にあるページの現在のチャンクについて利用可能な変換がない場合には、トラップハンドラは、このチャンクのビットベクトルエントリ４５５をキャッシュ４５０に挿入して、それ以上の不要なトラップを回避することができる。一実施形態では実装面でのトレードオフに応じて、共有ハードウェア構造を、「実行保護」および「書き込み保護」両方について読み出すことができ（これは、ビットベクトルフィールドとエイリアス（aliase）されてもよく、あるいは、別個のフィールドに含められてもよい）、あるいは、類似した設計の別個の構造を実装することもできる。
【００４４】
現在のＥＩＰに利用可能な変換があるか否かを判断した後に、高速のハードウェア技術を利用して、この変換のエントリアドレスを見つける。上述したように、エミュレーションエンジンにトラップがある場合があり、この場合、エミュレーションエンジンはソフトウェアハッシュテーブル内の変換エントリアドレスを探すことができる。このプロセスは当然ながら、数十から数百サイクルの時間がかかる。
【００４５】
より速く変換を行うために一部の実施形態では、ｉＴＬＢが直接モードからのエミュレーション実行遷移をトリガしたとき、プロセッサはエミュレーションエンジンではなくて変換キャッシュにジャンプしてもよい。対象アドレスは、直接ハッシュによって現在のＩＰを利用することでハードウェアにより生成されてよい。一実施形態では、アドレス（例えば、ＥＩＰ値に対応するもの）にハッシュを行って、直接ハッシュテーブルへのインデックスを得ることができる。図６に示すように、アドレス５１０の最下位部分（例えば下位の６つのビット）がクリアされ、上位のＮビットが直接ハッシュテーブル５３０のベースアドレスで置き換えられており、これは一実施形態では、エミュレーションエンジンのプライベートメモリ５２０に格納されてよい。そしてアドレスの中間部分（たとえばビット６（６３−Ｎ））がハッシュ部分であり、残りが不変であるので、ハッシュ値５２５が生成されている。このようにして、各６４ビットのＥＩＰが、２６４−Ｎのサイズであるハッシュテーブルにマッピングされる。一実施形態では、各エントリは、一定のキャッシュライン幅を有してよい（例えば６４Ｂ）。図６に示すように、直接ハッシュテーブル５３０は、最上位ビットに対応するベースアドレス５３２から開始されてよい（つまり、アドレスハッシュ値５２５にハッシュテーブルベースが存在する）。
【００４６】
このハッシュテーブルの各有効なエントリは、変換の開始部分を含む（つまり、プロセッサは、テーブルにジャンプするとエミュレーション実行モードにスイッチして、直後に変換コードの実行を開始する）。しかし、複数のＥＩＰが各ハッシュテーブルエントリにマッピングされてよく、格納されている変換が最終の元のＥＩＰと整合しない場合もある。従って一実施形態では、インラインチェックをエントリに行い、最終の元のＥＩＰおよび任意の他の関連する元のコンテキストをアサートして、それを、この変換が生成されたものに整合させることができる。このアサートに失敗すると、エミュレーションエンジンにトラップが存在し、これがその後、正確な変換エントリポイントを完全なハッシュテーブルから探すことができる。図６に示すように、各エントリ５３５がチェック部分５３６および変換部分５３８を含むことができ、これは、対応するアドレスの変換済みコードの開始に相当してよい。変換部分５３８の最後には、変換キャッシュに存在するさらなる変換済みコードへのジャンプがある場合がある。
【００４７】
つまり変換は、殆ど常に、キャッシュラインよりも大きいので、ハッシュテーブルエントリにその完全が含まれていない場合がある。一実施形態では、無条件分岐を各エントリの最後に提供して、ハッシュテーブルの外の変換の残りにジャンプさせることができる（つまり、変換キャッシュに格納することができる）。上述したように、ハッシュテーブル５３０は、エミュレーションエンジンの変換キャッシュ管理コンポーネントにより維持することができる。ハッシュテーブルの空のエントリは、エミュレーションエンジンに直接ジャンプする命令を含むことができる。直接ハッシュにより、直接モードからエミュレーションモードへの、ハッシュテーブルに含まれる変換の遷移オーバヘッドが略ゼロに低減される（残りのものに関しては、図２から図３で上述したソフトハッシュテーブルがある）。
【００４８】
元のモードからエミュレーション実行への遷移は、通常は「ホットからホット」ではなくて、「コールドからホット」の方向である。「ホットからホットコード」の遷移については、チェーン処理（遷移間の直接分岐）を利用することができる。しかし、コードのロット（a lot of code）が変換閾値に近い実行頻度を有するフラットなプロフィールを有するアプリケーションでは、元のモードからエミュレーション実行への遷移は比較的頻繁に行われてよい。直接ハッシュにより、部分的な変換モデルのこのワークロードにおけるパフォーマンスが良好となる。
【００４９】
一部の実装例では、直接ハッシュを利用して、エミュレーション実行モードの間接的な分岐の実行速度を上げることができる。このようにして、間接分岐の元の対象アドレスに対応する変換アドレスを探すソフトウェアハンドラをなくすことができる。これは、これらの検索が、ランタイムオーバヘッドの最上位のカテゴリの１つを表すからである。このオーバヘッドを大幅に低減させるべく、実施形態では、ハッシュテーブルへの間接分岐の頻繁な対象である変換基礎ブロックを格納することができる。対応する間接分岐については、特殊な分岐命令を利用して、元の対象アドレスに対応するハッシュテーブルエントリに直接ジャンプすることができる。一部の実施形態では、別個のハッシュテーブルを別の間接分岐グループに利用することができ、エントリサイズ等のパラメータを変えることができる。
【００５０】
図７は、本発明の一実施形態におけるプロセッサのブロック図である。図７に示すように、プロセッサ６００は多段パイプラインのアウトオブオーダのプロセッサであってよい。プロセッサ６００は、図７の比較的簡略された図で、本発明の一実施形態における元の実行モードと、変換実行モードとの間の遷移に利用される様々なフィーチャを示している。
【００５１】
図７に示すように、プロセッサ６００はフロントエンドユニット６１０を含み、これを利用して、マクロ命令をフェッチして、後のプロセッサでの利用のために準備しておく。例えば、フロントエンドユニット６１０は、フェッチユニット６０１、命令キャッシュ６０３、および命令復号器６０５を含んでよい。一部の実施形態では、フロントエンドユニット６１０はさらに、マイクロコード格納装置およびマイクロオペレーション格納装置とともに、トレースキャッシュを含むことができる。フェッチユニット６０１は、例えばメモリまたは命令キャッシュ６０４からマクロ命令をフェッチして、命令復号器６０５にフィードして、プリミティブ（つまり、プロセッサによる実行用のマイクロオペレーション）に復号することができる。
【００５２】
フロントエンドユニット６１０はさらに、要求されたアドレスに関連付けられている変換済みコードが存在するか否かを判断する際に利用する変換情報を格納するのに利用可能なキャッシュメモリまたはバッファ等の様々な構造を含む。特にこれら構造は、細粒度のキャッシュ６０６、ＴＬＢ６０７、および変換マッピングバッファ６０８を含むことができる。一実施形態では、キャッシュ６０６は、図５のキャッシュメモリ４５０等に構成されてよい比較的小さなキャッシュメモリであってよい。従ってこのキャッシュメモリは複数のエントリを格納することができ、その各々が、任意のメモリページのサブセットのインジケータによりマッピングを提供して、対応するサブセットに関連付けられた変換済みコードが存在するか否かを示す少なくとも１つのビットベクトルを格納する。ＴＬＢ６０７は、対応するメモリページが変換済みコードを含むか否かを示す少なくとも１つのインジケータに加えて、ＶＡとＰＡとの間に変換を格納するエントリを有することができる。変換マッピングバッファ６０８は複数のエントリを含むことができる。このバッファは比較的小さくてよく、例えば仮想アドレスと変換キャッシュの対応するアドレスとの間の直接マッピングを含んでよい。このバッファは、変換済みコードへ最も速く到達するルートを提供することができる。しかしサイズが小さいせいで、バッファが所望の変換を含まないことがある。本発明の範囲はこの点に限定されないが、マッピングバッファ６０８のエントリは、最長時間未利用の（ＬＲＵ）アルゴリズムによって排除されてよく、これにより最も最近に利用された（および／または最も頻繁に利用されている）変換をバッファに格納することができる。
【００５３】
一実施形態では、キャッシュ６０６、ＴＬＢ６０７、およびマッピングバッファ６０８の各々が、仮想アドレスの少なくとも一部分を利用して並列にアクセスされてよい。しかし一部の実施形態では、マッピングバッファ６０８がまずアクセスされて、変換が存在する場合には、ＴＬＢ６０７およびキャッシュ６０６へのアクセスのオーバヘッドを回避することができる。これら格納構造の対応する出力は、ヒットした情報またはミスを示す情報に対応してよく、制御ロジック６０９に提供されてよい。制御ロジック６０９に提供されるこれら格納装置の出力の１以上に基づいて、対応するアドレスが変換済みコードを含むか否かの判断を行うことができる。判断結果が肯定的である場合には、さらにロジックが、変換済みコードの位置を判断することもできる（マッピングバッファ６０８にヒットがある場合）。従って制御ロジック６０９は、元のモードからｔｒｅｘモードへの高速な遷移を行うことができる。
【００５４】
図７を参照すると、フロントエンドユニット６１０と実行ユニット６２０との間に、アウトオブオーダ（ＯＯＯ）エンジン６１５が存在しており、これは、マイクロ命令を受信して実行用に準備するのに利用することができる。より具体的には、ＯＯＯエンジン６１５は、マイクロ命令フローをリオーダして実行に必要な様々なリソースを割り当て、且つ、レジスタファイル６３０および拡張レジスタファイル６３５等の様々なレジスタファイル内の格納位置への論理レジスタを改名する様々なバッファを含むことができる。レジスタファイル６３０は、整数および浮動小数点演算それぞれに別個のレジスタファイルを含むことができる。拡張レジスタファイル６３５は、ベクトルサイズ単位（vector-sized unit）の格納装置を提供することができる（１レジスタについて２５６または５１２ビット）。
【００５５】
実行ユニット６２０には、他の専用ハードウェアのうち、様々な整数、浮動小数点、およびシムド（ＳＩＭＤ）論理ユニットを含む様々なリソースが存在していてよい。結果は退避ロジック（つまりリオーダバッファ（ＲＯＢ）６４０）に提供してよい。より具体的にはＲＯＢ６４０は、実行される命令に関連付けられた情報を受信する様々なアレイおよびロジックを含むことができる。その後で、この情報はＲＯＢ６４０により検査されて、命令が有効に退避可能か、結果データがプロセッサのアーキテクチャ状態に関係しているか否か、あるいは、１以上の例外が生じて命令の適切な退避を妨げたか否か、を判断する。もちろんＲＯＢ６４０は退避に関する他の処理を処理することもできる。
【００５６】
図７に示すように、ＲＯＢ６４０がキャッシュ６５０に連結され、これは一実施形態では、低レベルキャッシュ（例えばＬ１キャッシュ）であってよいが、本発明の範囲はこの点に限定はされない。さらに、実行ユニット６２０がキャッシュ６５０に直接連結されてよい。キャッシュ６５０から、データ通信はこれよりも高いレベルのキャッシュ、システムメモリ等から生じてよい。図７の実施形態では高レベルとして示されているが、本発明の範囲はこの点に限定はされない。
【００５７】
従って実施形態では、元のコードのパッチングを行うことなく部分的なエミュレーションを行うことができ、これはさらに複雑になり、大きなパフォーマンスオーバヘッドを生じる可能性がある。さらに、既存のメモリ保護メカニズムを利用して、ページおよび／またはより細粒度の（例えば１２８Ｂ）のチャンクレベルの実行制御機能をもったエミュレーションエンジンを得ることができる。さらに、制御遷移のレイテンシーを低減させるべく、直接ハッシュを利用することができる。またさらには、「ＩＡ−ＩＰから変換済みＩＰ」ハードウェア構造を追加で、または代替的に利用して、直接ハッシュを行い、遷移の小さなサブセットについて非常に低いレイテンシーを可能とすることができる。
【００５８】
また別の実装例では、異なるハードウェア構成を利用して、エミュレーション実行モード移譲に対して効率的な直接モードを実現することができる。部分的なエミュレーションでは、ソースＩＳＡコードを従来のメモリから直接実行することができる。未修正のソースＩＳＡコードを直接実行するということは、エミュレーションエンジンがエミュレーション前の全てのソースＩＳＡ命令を調べる機会が与えられないということである。さらに実行エンジンは、自身の実行制御フローを直接（解釈における場合のように）、または間接的に（変換済みコードに配置されるリンクを介して）追跡することができない。このように、変換および／または最適化が必要となるソースＩＳＡ命令（およびコード領域）を、変換前に特定することができる。さらに、命令の変換後に命令を実行しながら、従来のメモリのソースＩＳＡ命令と、コードキャッシュの対象ＩＳＡ命令との間で制御を移譲するメカニズムを提供することができる。
【００５９】
これは、各命令の解釈中に行うことができ、および／または、命令の変換時に行うことができる。調査中に、ある種のオペコードを特定のソフトウェアエミュレーションについて特定したり、プロファイリングデータを収集してホットスポットを特定したりすることができる。一実施形態では、マイクロトラップが、エミュレーション前に、エミュレーションエンジンに、全てのソースＩＳＡコードを調べさせるメカニズムを提供することができる。制御をエミュレーションエンジンに直接移譲する軽量トラップが存在する。これらオーバヘッドを最小限に抑えるべく、自動的にはレジスタの保存を行わず、トラップの原因に応じて特定の位置にベクタする。マイクロトラップは、実施形態によって、選択されたオペコードにより、またはマイクロタイマによりトリガすることができる。
【００６０】
未実装のオペコードを選択してマイクロトラップをトリガすることで、エミュレーションエンジンは、オペコードのいずれかに遭遇した際に、制御を直接得る。そして、命令を解釈する、あるいは、命令が多く実行されるコード領域に属している場合には、より高いパフォーマンスでエミュレーションを行うためにそのコード領域を変換およびキャッシュすることができる。未実装の命令は、概して互いにクラスタする傾向があるので（例えばグラフィックス）、変換済みの一領域が複数の未実装の領域を含む場合がある。
【００６１】
未実装のオペコードを含むホット領域を検出するには、エミュレーションエンジンは、単に特定の命令がマイクロトラップをトリガする回数をカウントすることができる。これらカウントをプロフィールテーブルに維持して、累積プロフィール情報を利用して変換および最適化に関する決定の助けとすることができる。
【００６２】
未実装の命令が含まれているかに関わらず、部分的なエミュレーションがホットスポットコード領域の最適化にも利用されている場合には、マイクロタイマおよび関連するマイクロトラップを利用してプロファイリングによりホットスポット検出を助けることができる。一実施形態では、エミュレーションエンジンによりマイクロタイマを設定して、クロックサイクルごとにデクリメントを行う。マイクロタイマのカウントがゼロに達したら、次の分岐／ジャンプ命令を待ち、エミュレーションエンジンの予め定められた位置に即座にトラップする（つまりマイクロトラップのことである）。その時点でエミュレーションエンジンはプロフィールデータを収集する機会を耐えられる。ここで、トラップの位置での分岐／ジャンプ先について新たなプロフィールエントリを作成することもできる。同じ分岐／ジャンプに前に遭遇していた場合には、プロフィールエントリを更新することもできる。殆どのバイナリトランスレータが変換領域を基本ブロック境界から始めることが多いので、分岐およびジャンプが選ばれる（singled out）。
【００６３】
従来のメモリから、コードキャッシュ内の変換済みコード領域への制御の移譲は、クロックサイクル面でかなり高いオーバヘッドが出る場合がある。オーバヘッドを減らすべく、一部の実施形態では、最近利用したマップテーブルエントリを含み、キャッシュに似た構造である、いわゆるジャンプＴＬＢが提供されている。ジャンプＴＬＢは命令パイプラインからアクセス可能であり、その内容はエミュレーションエンジンにより管理されている。ソース命令を従来のメモリから直接実行するときの時間間隔中に、全ての分岐およびジャンプの宛先アドレスは、ジャンプＴＬＢにインデックスされる（index into）。ジャンプＴＬＢのエントリにヒットした場合には、そのエントリがコードキャッシュに宛先アドレスを提供し、命令フェッチハードウェアが即座にそのアドレスに制御を移譲する。一実施形態では、エミュレーションソフトウェアは、マップテーブルエントリをジャンプＴＬＢに適宜コピーして、あまり最近利用されていないエントリを置き換えることで、ジャンプＴＬＢを管理する。
【００６４】
一実施形態では、ブレークポイントメカニズムおよびジャンプＴＬＢを協働させることができる。コードのブロックがエミュレーションエンジンによる変換後に、エミュレーションエンジンは、変換済みソース命令の第１のラインに対応するブレークポイントテーブルにブレークポイントビットを設定する。さらにマップテーブルにエントリを生成する。ソースコードの直接実行中には、分岐またはジャンプに遭遇した際に生じうる複数の場合がありうる。第１に、宛先アドレスにブレークポイントビットが設定されているが、ジャンプＴＬＢにミスがある場合がある。この場合には、エミュレーションエンジンにトラップがあり、マップテーブルをチェックする。マップテーブルにエントリがある場合、エミュレーションエンジンはそれをジャンプＴＬＢに配置する（例えば、少なくとも最長時間未利用のエントリを置き換える）。そして制御をコードキャッシュに移譲する。
【００６５】
第２の場合では、ジャンプＴＬＢにヒットがあり、ブレークポイントビットが設定されている。この場合には、移譲は、ブレークポイントマイクロトラップなしにジャンプＴＬＢエントリの内容に従って即座に生じる。この機能を促すべく、ジャンプＴＬＢエントリは、ブレークポイントオーバーライドフラグを含んで、ブレークポイントビットの状態に関わらず、分岐／ジャンプを継続させる。
【００６６】
第３の場合は、ブレークポイントビットがゼロにクリアされたときジャンプＴＬＢにミスがある場合である。この場合、マイクロトラップが生じず、従来のメモリからの直接実行が妨害を受けない状態が続く。最後の場合には、ジャンプＴＬＢにヒットがあり、ブレークポイントビットがゼロである場合である。この場合は、ジャンプＴＬＢおよびブレークポイントビットを上述した通りに利用している限り、直接実行中には生じない。しかし、ジャンプＴＬＢが、コードキャッシュの１つの変換領域から別のコードキャッシュに制御を移譲するのに利用される場合には生じうる。
【００６７】
図８は、本発明の一実施形態における動作を示すブロック図である。ジャンプＴＬＢの動作とブレークポイントキャッシュとの組み合わせを図８に示す。図示されているシステム７００は、１以上のコアを含みうるプロセッサ７１０を含む。プロセッサに関しては、直接実行コードと変換済み実行コードとの間のジャンプまたは遷移を処理するのに利用されうる様々な格納装置以外の詳細は示さない。図示されているように、これら構造は、様々な実施形態では命令キャッシュその他の命令格納装置のラインごとにシングルビットを有するエントリを含みうるブレークポイントキャッシュ７１０を含むことができる。加えて、ソースプログラムカウンタ（ＳＰＣ）および対象プログラムカウンタ（ＴＰＣ）間の最近アクセスされた変換を格納することのできるマッピングキャッシュ（つまりジャンプＴＬＢ７１５）を提供することができる。もちろん追加のロジックをプロセッサ７１０内に提供することもできる。動作中に、プロセッサ７１０はメモリ７２０と通信することができ、一実施形態では、メモリ７２０は従来のメモリ部分７３０と隠されたメモリ部分７５０とを含むシステムメモリであってよい。図示されているように、従来のメモリ部分７３０は、様々なソースＩＳＡコードブロック（つまりブロックＡ−Ｃ）を含むことができる。変換済みコードブロックは、コードキャッシュ７６０のこれらブロックの少なくとも一部において存在してよい。有効な変換済みコードがあるか否かを判断するべく、エミュレーションエンジン７７５から様々な構造（ソースプログラムカウンタおよび対象プログラムカウンタの間の変換を含むフルテーブルであってよいマップテーブル７８０を含む）に対してアクセスを行うことができる。加えて、ブレークポイントテーブル７９０は、ブレークポイントビットのフルセットを含むことができる。
【００６８】
説明における例として、ブロックＢの命令が従来のメモリ７３０から直接実行されていると仮定する。ブロックの最後に、ブロックＣのソースコード宛先Ｃ０への分岐が存在している。ブロックＣが変換され、隠されたメモリ７５０のコードキャッシュ７６０に格納されているが、マッピングは現在ジャンプＴＬＢ７１５にはない。これにより、ブレークポイントキャッシュ７１０にブレークポイントビットが設定されているので、エミュレーションエンジン７７５へのブレークポイントトラップ（図８のアクション（１））が生じる。エミュレーションエンジン７７５はマップテーブル７８０にアクセスして、マッピングを見つけ、ジャンプＴＬＢ７１５にインストールする（図８のアクション（２））。そしてエミュレーションエンジン７７５はブロックＣで、変換済みコードにジャンプする（アクション３）。次にソースブロックＢからＣへの分岐が生じたとき、ジャンプＴＬＢヒットが生じ、ソフトウェアの介入なしに（ジャンプＴＬＢエントリが置き換えられていないという前提で）即座に移譲が行われる。
【００６９】
この例の説明を続けると、変換済みＣ、Ｄ、およびＥがコードキャッシュ７６０から実行された後で、コードブロックＡに直接関連はしていないジャンプが存在する。この場合、宛先はソースコードアドレスであり、ジャンプＴＬＢ７１５により傍受され、制御が即座に変換済みブロックＡに移譲される。ジャンプＴＬＢを利用する場合、変換済みコードへの制御の移譲が、どの発信元である分岐またはジャンプがＴＬＢにヒットするかに関わらず生じることがある。これは、全てのジャンプが同じ変換済みコードに向けられる複数の異なる命令が存在する場合、変換済み宛先ブロックのレジスタの割り当ておよびその他の設計された状態が、全ての「そこから来る（come-from）」ブロックに対して矛盾しない必要がある。これを処理する目的から、ジャンプＴＬＢは、発信元の分岐／ジャンプを選択する追加フィールドを含むことができる。
【００７０】
図９は、本発明の別の実施形態におけるプロセッサのブロック図である。図９に示すように、プロセッサ８１０は、部分的な変換を行う様々なコンポーネントを含みうる。図示されているように、本発明の一実施形態において、プログラムカウンタ８４５は、様々な位置から入力を受け取り、対応するプログラムカウンタ値を、ブレークポイントビット８２５を含みうる命令キャッシュ８２０に提供してよい。他の実施形態では、ブレークポイントビットは命令キャッシュに格納されていなくてもよい。存在する場合には、アクセスされる命令は、直接モードにある場合、ソースＩＳＡ復号器８５０に提供することができる。示されている実施形態では、復号器８５０をバイパスする経路は、対象ＩＳＡ命令がｕｏｐレベルにある復号を回避するよう提供することができる。従って、いずれの場合にも、ｕｏｐ命令がプロセッサパイプライン８６０に提供され、プロセッサパイプライン８６０は、要求された命令を実行する実行ユニット等を含む様々な段階を含むことができる。
【００７１】
図９にさらに示すように、宛先プレディクタ８３５は、ジャンプＴＬＢ８４０に予測を提供することができる。同様に、命令キャッシュミスがある際には、ブレークポイントキャッシュ８３０にアクセスを行い、新たに挿入されたラインについてのブレークポイントビットをインストールすることができる。プログラムカウンタ８４５にはマイクロタイマ８７０も連結されてよい。さらに図示するように、入力される命令は、実行が直接モードまたはエミュレーション実行モードのいずれにあるかに応じて、直接従来のメモリ部分から提供されるか、システムメモリ８８０の隠されたメモリ部分から提供されてよい。マイクロタイマ８７０は、汎用ソースＩＳＡコード（ＩＳＡ拡張だけではなくて）に動的な最適化を実装するためのホットスポット領域を特定する目的に利用することができる。ジャンプＴＬＢ８４０はブレークポイントビットと協働して、従来のメモリから隠されたメモリへの流線型の命令移譲を行うことができる。別の実施形態では、ジャンプＴＬＢ８４０を分岐宛先アドレス（パイプラインから）またはジャンプ間接アドレス（レジスタから）で示す（indexed with）ことができる。分岐からの、または、分岐からではないアドレスを利用することができる。ブレークポイントキャッシュ８３０は、エミュレーションエンジンを介してブレークポイントテーブルから満たすことができる。この代わりにブレークポイントビット８２５は、一対一で命令キャッシュラインとマッピングすることができる。これらビットは、対応するラインが命令キャッシュ８２０に配置されるとき、ハードウェアによりインストールされる。そして、命令フェッチ時にアクセスされて、適宜ブレークポイントマイクロトラップをトリガする。ブレークポイントビットが命令キャッシュにインストールされない実装例では、ブレークポイントトラップはブレークポイントキャッシュ８３０から発せられてよい。一実施形態では、マイクロタイマ８７０がエミュレーションエンジンによりロードされ、サイクルごとにデクリメントされる。
【００７２】
図１０は、本発明の一実施形態におけるエミュレーションエンジンの動作のフロー図である。本実施形態では、エミュレーションエンジンは拡張ＩＳＡを処理することができるので、ブレークポイントビットおよびジャンプＴＬＢの両方を管理する。エミュレーションマネージャはまず起動時に制御されて、様々なテーブルおよび必要な他の構造を構築して、起動コードへジャンプする。起動コードは、直接実行（図１０の「開始」）から開始される。直接実行は、従来のメモリ９１０から、未実装の命令に遭遇するまで（おそらくはＩＳＡ拡張によって）継続される。この時点で、ブロック９１５でエミュレーションエンジンへのマイクロトラップが存在する。
【００７３】
エミュレーションエンジンは、特定の未実装の命令の頻度を追跡するソフトウェアテーブルを保持する。命令が頻繁に生じるということが分かったら、その命令（および同じ領域にある他の命令）を変換して最適化する（ブロック９１８）。変換済みブロックはその後、スペースに空きがあればコードキャッシュにインストールされ（ブロック９１９および９７０）、マップテーブルおよびブレークポイントテーブルを更新して新たな変換（１または複数）のブロックを反映させる。そしてエミュレーションエンジンは、コードキャッシュの変換済みブロックにジャンプして、実行は、変換済みコードを再開する（ブロック９２５）。
【００７４】
コードキャッシュから実行される場合、分岐またはジャンプは、従来のメモリまたはコードキャッシュに存在する宛先アドレスを有することができる。コードキャッシュに存在している場合には、単に制御移譲を行う。宛先アドレスが従来のメモリに存在している場合には、ジャンプＴＬＢにアクセスする（ブロック９３０）。ヒットがある場合には、制御をコードキャッシュに移譲して戻し、ヒットがなければ、制御を従来のメモリの宛先アドレスに移譲する（ブロック９１０へ戻る）。
【００７５】
従来のメモリから実行される間、ジャンプＴＬＢに宛先アドレスヒットがあるジャンプまたは分岐がある場合には、制御の移譲は、コードキャッシュの適切な位置へ移される。エミュレーションエンジンにブレークポイントマイクロトラップが存在する場合には（つまり、ブレークポイントビットを設定してラインをフェッチして、ジャンプＴＬＢミスがある場合（ブロック９３５））、エミュレーションエンジンはもしあればマップテーブルからジャンプＴＬＢエントリをインストールして（ブロック９４０）、対象コードアドレスで継続実行する（ブロック９３５）。他方でマップテーブルエントリがない場合には、制御を従来のメモリに移譲して戻す（ブロック９１０）。このような場合は、キャッシュラインに対して２以上の分岐／ジャンプがある場合に生じうるが、その全てが変換に対応するエントリポイントを有するわけではない。
【００７６】
最後に、命令キャッシュミスがある場合、ミスしたラインについてブレークポイントキャッシュにアクセスして（ブロック９５０）、ヒットがある場合には、ブレークポイントビットを新たにインストールされたキャッシュラインに「アタッチ」する（ブロック９５５）。一部の実装例では、ブレークポイントビットは、このキャッシュラインでインストールされなくてもよい。ミスがあるということは、エミュレーションエンジンにマイクロトラップがあるということである。この場合、エミュレーションエンジンは、ブレークポイントテーブルにエントリがある場合、ブレークポイントテーブルからブレークポイントキャッシュを更新する（ブロック９６０）。さもなくば、ブレークポイントテーブルエントリを作成して、それをゼロに設定する（実際は、ビットの全セクタを全てゼロに設定する）。この時点で、ジャンプＴＬＢは、ブレークポイントビットが設定されている場合にも更新されてよい。この代わりに、図示はしていないが、従来のメモリに戻り、最初のキャッシュミスをトリガした命令フェッチを再試行することもでき、この時点でジャンプＴＬＢミスがある場合にはブレークポイントマイクロトラップがあり、この時点でジャンプＴＬＢを更新する。図１０の実施形態にはこの特定の実装例が示されているが、本発明の範囲はこの点に限定されない。
【００７７】
実施形態は他の多くの種類のシステムで実装可能である。図１１は、本発明の一実施形態におけるシステムのブロック図である。図１１に示すように、マイクロプロセッサシステム１０００ はポイントツーポイントシステムであり、ここでは第１のプロセッサ１０７０と第２のプロセッサ１０８０とがポイントツーポイントインターコネクト１０５０により連結されている。図１１に示す各プロセッサ１０７０および１０８０はマルチコアプロセッサであってよく、第１および第２のプロセッサコアを含むが（つまり、プロセッサコア１０７４ａおよび１０７４ｂ、並びに、プロセッサコア１０８４ａおよび１０８４ｂ）、これ以外にも多くのコアが本プロセッサ内に存在している可能性が高い。プロセッサコアは、少なくとも一部の変換済みコードを実行してパフォーマンスを向上させる、および／または、コアのマイクロアーキテクチャがサポートしない命令を処理することができるよう、部分的なエミュレーションモデルを実装することができる。
【００７８】
さらに図１１を参照すると、第１のプロセッサ１０７０はさらにメモリコントローラハブ（ＭＣＨ）１０７２と、ポイントツポイント（Ｐ−Ｐ）インタフェース１０７６および１０７８とを含む。同様に、第２のプロセッサ１０８０は、ＭＣＨ１０８２と、Ｐ−Ｐインタフェース１０８６および１０８８とを含む。図１１に示すように、ＭＣＨ１０７２および１０８２は、プロセッサをメモリそれぞれ（つまり、メモリ１０３２およびメモリ１０３４）に連結し、これらはメインメモリ（例えばプロセッサそれぞれにローカルにアタッチされるＤＲＡＭ）の一部であってよい。第１のプロセッサ１０７０および第２のプロセッサ１０８０は、Ｐ−Ｐインターコネクト１０５２および１０５４をそれぞれ介してチップセット１０９０に連結されてよい。図１１に示すように、チップセット１０９０はＰ−Ｐインタフェース１０９４および１０９８を含む。
【００７９】
さらにチップセット１０９０は、チップセット１０９０と高性能グラフィックスエンジン１０３８とを、Ｐ−Ｐインターコネクト１０３９により連結するインタフェース１０９２を含む。そしてチップセット１０９０は、インタフェース１０９６を介して第１のバス１０１６に連結されてよい。図１１に示すように、第１のバス１０１６を第２のバス１０２０に連結するバスブリッジ１０１８とともに、様々な入出力（Ｉ／Ｏ）デバイス１０１４が第１のバス１０１６に連結されてよい。例えば一実施形態では、キーボード／マウス１０２２、通信デバイス１０２６、および、コード１０３０を含みうるデータ格納ユニット１０２８（例えば、ディスクドライブその他の大容量記憶デバイス）を含む様々なデバイスが第２のバス１０２０に連結されてよい。さらにオーディオＩ／Ｏ１０２４が第２のバス１０２０に連結されてよい。
【００８０】
実施形態は、コードで実装されて、システムをプログラムして命令を行わせるのに利用されうる命令を格納する記憶媒体上に格納されてよい。記憶媒体には、これらに限定はされないが、フロッピー（登録商標）ディスク、光ディスク、固体ドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、および光磁気ディスク、半導体デバイス（ＲＯＭ、ＤＲＡＭ等のＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ（登録商標）、磁気カードまたは光学カード等）、および、電子命令を格納するのに適した他の種類の媒体が含まれてよい。
【００８１】
本発明を限られた数の実施形態を参照して記載してきたが、当業者には数多くの変形例および変更例が可能であることが明らかである。添付請求項はこれら全ての変形例および変更例を本発明の真の精神および範囲に含むことを意図している。
【図１】
0005506049.tif 000003
【図２】
0005506049.tif 000004
【図３】
0005506049.tif 000005
【図４Ａ】
0005506049.tif 000006
【図４Ｂ】
0005506049.tif 000007
【図５】
0005506049.tif 000008
【図６】
0005506049.tif 000009
【図７】
0005506049.tif 000010
【図８】
0005506049.tif 000011
【図９】
0005506049.tif 000012
【図１０】
0005506049.tif 000013
【図１１】
0005506049.tif 000014