(57)【要約】  ＪＩＴバイナリトランスレータは、命令コードレベルというよりもむしろ関数レベルにおいてコードを変換する。本発明のＪＩＴバイナリトランスレータは、命令ではなく、ソースストリームからｘ８６関数全体を取り込み、関数全体をターゲットプロセッサの同等の関数に変換し、ソースストリームに戻す前に一度にその関数全てを実行し、そうすることによって文脈切り替えを削減する。また、ＪＩＴバイナリトランスレータは、ソースコード関数文脈全体を一度に参照するので、ソフトウェアエミュレータは、コード変換を最適化することができる。例えば、ＪＩＴバイナリトランスレータは、ｘ８６命令のシーケンスを、効率的なＰＰＣ同等のシーケンスに変換することを決定することができる。多くのそのような最適化は、よりタイト（tighter）なエミュレートされたバイナリをもたらす。
2008545179.tif 000002
【特許請求の範囲】
【請求項１】
第１のＣＰＵタイプのコンピュータ実行可能コードを、第２のＣＰＵタイプのコンピュータ実行可能コードへ変換する方法であって、
前記第１のＣＰＵタイプの前記コンピュータ実行可能コードのストリームを解析して、前記第１のＣＰＵタイプの前記コンピュータ実行可能コード内の関数に対応する、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内のＣＰＵコード命令のシーケンスを識別するステップと、
前記関数に対応する前記ストリーム内のＣＰＵコード命令の前記シーケンスから、第２のＣＰＵタイプの前記実行可能コードのシーケンスを生成するステップと
を備えることを特徴とする方法。
【請求項２】
前記第１のＣＰＵタイプはｘ８６であり、前記第２のＣＰＵタイプはパワーＰＣであることを特徴とする請求項１に記載の方法。
【請求項３】
前記解析するステップは、コンパイラに、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内の関数の最初に始まる、前記第１のＣＰＵタイプの命令のリストを作成するように指示するステップと、関数命令の最後に到達し、前記第１のＣＰＵタイプの命令の前記リスト内に未解決の条件分岐がない場合に、前記第１のＣＰＵタイプの前記コンピュータ実行可能命令の前記ストリーム内のある地点で、前記第１のＣＰＵタイプの命令の前記リストを終了させるステップとを備えることを特徴とする請求項１に記載の方法。
【請求項４】
命令の前記リストを分析して、最適化を見いだすステップと、前記生成するステップの前に、前記最適化を実行するステップとをさらに備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記第２のＣＰＵタイプの実行可能コードの前記生成されたシーケンスを分析して、最適化を見いだすステップと、前記最適化を実行するステップとをさらに備えることを特徴とする請求項４に記載の方法。
【請求項６】
前記第２のＣＰＵタイプの前記実行可能コードの前記シーケンスをコンパイルし、格納するステップと、前記コンパイルされたシーケンスが格納されるメモリアドレスを、前記第１のＣＰＵタイプの前記関数の前記最初のメモリアドレスに関連付けるステップとをさらに備えることを特徴とする請求項３に記載の方法。
【請求項７】
第１のＣＰＵタイプのコンピュータ実行可能コードを、第２のＣＰＵタイプのコンピュータ実行可能コードに変換するバイナリ変換システムであって、
前記第１のＣＰＵタイプの前記コンピュータ実行可能コードのストリームを解析して、前記第１のＣＰＵタイプの前記コンピュータ実行可能コード内の関数に対応する、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内のＣＰＵコード命令のシーケンスを識別するパーサと、
前記関数に対応する前記ストリーム内のＣＰＵコード命令の前記シーケンスから、前記第２のＣＰＵタイプの前記実行可能コードのシーケンスを生成するコードジェネレータと
を備えることを特徴とするバイナリ変換システム。
【請求項８】
前記第１のＣＰＵタイプはｘ８６であり、前記第２のＣＰＵタイプはパワーＰＣであることを特徴とする請求項７に記載のバイナリ変換システム。
【請求項９】
前記パーサは、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内の関数の最初に始まる、前記第１のＣＰＵタイプの命令のリストを作成し、関数命令の最後に到達し、前記第１のＣＰＵタイプの命令の前記リスト内に未解決の条件分岐がない場合に、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内のある地点で、前記第１のＣＰＵタイプの命令の前記リストを終了させることを特徴とする請求項７に記載のバイナリ変換システム。
【請求項１０】
命令の前記リストを分析して、最適化を見いだし、前記コードジェネレータに命令の前記リストを提供する前に、前記最適化を実行するオプティマイザをさらに備えることを特徴とする請求項９に記載のバイナリ変換システム。
【請求項１１】
前記第２のＣＰＵタイプの実行可能コードの前記生成されたシーケンスを分析して、最適化を見いだし、前記最適化を実行する第２のオプティマイザをさらに備えることを特徴とする請求項１０に記載のバイナリ変換システム。
【請求項１２】
前記第２のＣＰＵタイプの前記実行可能コードの前記シーケンスをコンパイルし、格納するコンパイラをさらに備えることを特徴とする請求項９に記載のバイナリ変換システム。
【請求項１３】
前記コンパイルされたシーケンスが格納されるメモリアドレスと、前記第１のＣＰＵタイプの前記関数の前記最初のメモリアドレスとを格納するテーブルをさらに備え、該テーブルは、前記メモリアドレスを互いに関連付けることを特徴とする請求項１２に記載のバイナリ変換システム。
【請求項１４】
ホストコンピュータシステムに挿入されると、第１のＣＰＵタイプのコンピュータ実行可能コードを第２のＣＰＵタイプのコンピュータ実行可能コードに変換するバイナリ変換システムを作り出すコンピュータ読取り可能媒体であって、
前記第１のＣＰＵタイプの前記コンピュータ実行可能コードのストリームを解析して、前記第１のＣＰＵタイプの前記コンピュータ実行可能コード内の関数に対応する、前記第１のＣＰＵタイプの前記コンピュータ実行可能コード前記ストリーム内のＣＰＵコード命令のシーケンスを識別するパーサソフトウェアと、
前記関数に対応する前記ストリーム内のＣＰＵコード命令の前記シーケンスから、前記第２のＣＰＵタイプの前記実行可能コードのシーケンスを生成するコードジェネレータソフトウェアと
を備えることを特徴とするコンピュータ読取り可能媒体。
【請求項１５】
前記第１のＣＰＵタイプはｘ８６であり、前記第２のＣＰＵタイプはパワーＰＣであることを特徴とする請求項１４に記載のコンピュータ読取り可能媒体。
【請求項１６】
前記パーサソフトウェアは、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内の関数の最初に始まる、前記第１のＣＰＵタイプの命令のリストを作成し、関数命令の最後に到達し、前記第１のＣＰＵタイプの命令の前記リスト内に未解決の条件分岐がない場合に、前記第１のＣＰＵタイプの前記コンピュータ実行可能コードの前記ストリーム内のある地点で、前記第１のＣＰＵタイプの命令の前記リストを終了させることを特徴とする請求項１４に記載のコンピュータ読取り可能媒体。
【請求項１７】
命令の前記リストを分析して、最適化を見いだし、前記コードジェネレータソフトウェアに命令の前記リストを提供する前に、前記最適化を実行するオプティマイザソフトウェアをさらに備えることを特徴とする請求項１６に記載のコンピュータ読取り可能媒体。
【請求項１８】
前記第２のＣＰＵタイプの実行可能コードの前記生成されたシーケンスを分析して、最適化を見いだし、前記最適化を実行することを特徴とする請求項１７に記載のコンピュータ読取り可能媒体。
【請求項１９】
前記第２のＣＰＵタイプの前記実行可能コードの前記シーケンスをコンパイルし、格納するコンパイラをさらに備えることを特徴とする請求項１６に記載のコンピュータ読取り可能媒体。
【請求項２０】
前記コンパイルされたシーケンスが格納されるメモリアドレスと、前記第１のＣＰＵタイプの前記関数の前記最初のメモリアドレスとを格納するテーブルをさらに備え、該テーブルは、前記メモリアドレスを互いに関連付けることを特徴とする請求項１９に記載のコンピュータ読取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、レガシーコンピュータシステムによって使用されるコードをホストコンピュータシステムによって実行されるコードへ変換することによって、ホストハードウェア環境においてレガシーハードウェア環境を仮想化するシステム及び方法に関し、より詳細には、命令レベルというよりもむしろ関数レベルにおいてコード変換を実施し、一連のレガシーコード命令を、対応する一連のホストコード命令に変換することによって、結果として生じるコードを最適化するジャストインタイム変換エンジンに関する。
【背景技術】
【０００２】
ゲームコンソールのようなコンピュータシステムのハードウェアアーキテクチャを最新のものにして、より速く、より機能が豊富なハードウェアを実装する場合、開発者は、レガシーコンピュータシステムプラットフォーム用に開発されたアプリケーションプログラムまたはゲームについて、レガシーコンピュータシステムに対する互換性の問題に直面する。特に、最新のハードウェアアーキテクチャは、レガシーハードウェアアーキテクチャ用に開発されたアプリケーションプログラムまたはゲームをサポートすることが商業的に望ましい。しかしながら、最新のハードウェアアーキテクチャは、基本的に、または根本的に、レガシーハードウェアアーキテクチャとは異なり、２つのシステム間のアーキテクチャの違いは、レガシーアプリケーションプログラムまたはゲームを、十分なハードウェア修正および／またはソフトウェアパッチなしで新しいハードウェアアーキテクチャ上で動作させることを、たとえ可能であったとしても、非常に困難にする。ユーザは一般的に、そのような互換性の問題を予想するので、これらの問題を解決することは、最新のハードウェアアーキテクチャの成功にとってとても重要である。
【０００３】
ＰＣアーキテクチャおよびソフトウェアエミュレーションの近年の進歩は、コンピュータやゲームコンソールに対して、ハードウェアというよりもむしろソフトウェアにおいてレガシーアプリケーションプログラムまたはゲームのエミュレーションを可能にするために十分にパワーのあるハードウェアアーキテクチャを提供している。そのようなソフトウェアエミュレータは、アプリケーションプログラムまたはゲームのタイトル命令（title instructions）をオンザフライ（on the fly）で、新しいハードウェアアーキテクチャが理解可能なデバイス命令に変換する。このソフトウェアエミュレーションによるアプローチは、ゲームコンソールの開発者がハードウェアとソフトウェアの両方のプラットフォームに対する制御を維持することができ、レガシーゲームに極めて精通しているので、コンピュータゲームコンソールの互換性の問題に対して特に有用である。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
そのようなソフトウェアエミュレータのほとんどが、コードワンＣＰＵ命令（code one CPU instructions）を一度に変換する。例えば、ソフトウェアエミュレータは、シングルｘ８６命令をソースストリームから引き出し、それをターゲットプロセッサ（例えば、パワーＰＣ（ＰＰＣ））の命令セットからオンザフライで１つまたは複数の事前定義された同等物に変換し、ターゲットプロセッサ上でそれらのＰＰＣ命令を実行し、次いでそれらを次の命令のためにソースストリームに戻すことができる。このアプローチは、概念的にシンプルであるが、欠点がある。例えば、このアプローチは、多くの遅い文脈切り替え（slow context switches back）、およびソフトウェアエミュレータとｘ８６命令セットを使用して書かれたレガシーアプリケーションまたはゲームシステムを実装する仮想マシン（ＶＭ）との間のフォース（forth）を必要とする。また、このアプローチは、命令を変換する際に任意の文脈のソフトウェアエミュレータを奪い、ソフトウェアエミュレータをシンプルな命令−マッピングテーブルに依存するように強制する。これは、性能の大きなデメリットである。すなわち、ソフトウェアエミュレータが文脈において命令を考慮することができた場合、次いでソフトウェアエミュレータは、命令よりもむしろコードブロックを命令によって変換することができ、そうすることによって大いに変換性能（performance）を向上させることができるからである。
【０００５】
したがって、文脈において考慮されるように変換されるべき命令に対するメカニズムを提供することによって、命令変換の性能を向上させる技術が望まれている。
【課題を解決するための手段】
【０００６】
本発明は、命令コードレベルというよりもむしろ、ソースコードの関数レベルにおいてコードを変換することによって、上述した技術の必要性に対処する。本発明のソフトウェアエミュレータは、ソースストリームからｘ８６命令全体を取り込み、関数全体をターゲットプロセッサの等価な関数に変換し、ソースストリームに戻す前に一度にその関数全てを実行する。この技術は文脈切り替えを低減するだけでなく、一度にｘ８６関数の文脈全てを参照することによって、ソフトウェアエミュレータがコード変換を最適化することができる。例えば、ソフトウェアエミュレータは、一連のｘ８６命令を効率的なＰＰＣ透過物に変換することを決定することができる。そのような最適化の多くは、ソフトウェアエミュレータ、特に、コードを素早く実行しなければならないゲームエミュレータにとって望ましい、より堅固な（tighter）エミュレートされたバイナリをもたらす。
【０００７】
本発明の例示的な実施形態は、本件特許出願人から入手可能なＸボックスコンピュータゲームシステム、コンピュータゲームコンソール、またはその他のコード変換が使用されるコンピュータシステムにおいて実装され、本発明の関数レベルコード変換技術から利益を得ることができることを、当業者は理解するだろう。本発明の他の特徴は、以下の説明に基づいて、当業者に明らかになるだろう。
【発明を実施するための最良の形態】
【０００８】
（概要）
本発明は、命令コードレベルというよりもむしろソースコードの関数レベルにおいてコードを変換するシステム及び方法を提供する。本発明のソフトウェアエミュレータは、命令というよりもむしろ、ソースストリームからｘ８６関数全体を取り込み、関数全体をターゲットプロセッサの等価な関数に変換し、ソースストリームに戻す前に一度にその関数全体を実行し、そうすることによって文脈切り替えを低減させる。また、ソフトウェアエミュレータが一度にソースコード関数文脈全体を参照するので、ソフトウェアエミュレータは、コード変換を最適化することができる。例えば、ソフトウェアエミュレータは、一連のｘ８６命令を効率的なＰＰＣ等価物に変換することを決定することができる。そのような最適化の多くは、より堅固なエミュレートされたバイナリをもたらす。
【０００９】
本発明のその他のより詳細な側面を以下に説明するが、まず最初に、オペレーティングシステムおよびホストプロセッサ（ＣＰＵ）仮想化技術に関する用語が理解されるように、仮想マシン、エミュレータ、および関連する用語について概要を説明する。そうすることで、当業者が、本発明の技術によるソースコードの関数レベルにおいてコードを変換する装置、システム、及び方法についての説明に利点を見つけられるように、一組の用語が説明される。
【００１０】
（仮想マシンの概要）
コンピュータは、汎用中央処理装置（ＣＰＵ）、または特定のシステム命令を実行するように設計された「プロセッサ」を含む。同様のアーキテクチャまたは設計仕様を有する一群のプロセッサは、同じプロセッサファミリの１つとみなすことができる。プロセッサファミリの例には、アリゾナ州フェニックス在のモトローラ社によって製造されているモトローラ６８０Ｘ０プロセッサファミリ、カリフォルニア州サニーベール在のインテル社によって製造されているインテル８０Ｘ８６プロセッサファミリ、並びにＩＢＭ社およびモトローラ社によって製造され、カリフォルニア州クパチーノ在のアップル社によって製造されたコンピュータで使用されているパワーＰＣプロセッサファミリが含まれる。一群のプロセッサは、同様のアーキテクチャおよび設計仕様により、同じファミリ内にあるとすることができ、プロセッサは、クロック速度やその他の性能パラメータにより、ファミリ内で大きく異なる。
【００１１】
マイクロプロセッサのそれぞれのファミリは、そのプロセッサファミリ独自の命令を実行する。プロセッサまたはプロセッサファミリが実行できる命令は、プロセッサの命令セットとして知られている。例えば、インテル８０Ｘ８６プロセッサファミリによって使用されている命令セットは、パワーＰＣプロセッサファミリによって使用されている命令セットと互換性がある。インテル８０Ｘ８６命令セットは、ＣＩＳＣ形式に基づき、モトローラパワーＰＣ命令セットは、ＲＩＳＣ形式に基づく。ＣＩＳＣプロセッサは、大量の命令を使用し、その一部は、より複雑な関数を処理することができるが、一般的に、実行するためには多くのクロックサイクルを必要とする。一方、ＲＩＳＣプロセッサは、より少ない数の命令を使用し、より高速に実行される比較的シンプルな関数を処理する。
【００１２】
コンピュータシステム間のプロセッサファミリの独自性は、一般的に、コンピュータシステムのハードウェアアーキテクチャのその他の要素間で非互換性をもたらす。インテル８０Ｘ８６プロセッサファミリのプロセッサで製造されたコンピュータシステムは、パワーＰＣプロセッサファミリのプロセッサで製造されたコンピュータシステムのハードウェアアーキテクチャとは異なるハードウェアアーキテクチャを有するだろう。プロセッサ命令セットとコンピュータシステムのハードウェアアーキテクチャの独自性のために、アプリケーションソフトウェアプログラムは一般的に、特定のオペレーティングシステムを実行する特定のコンピュータシステム上で実行されるように作成される。
【００１３】
一般的に言えば、コンピュータの製造者は、自社の製造ラインに関連するマイクロプロセッサファミリ上で実行される、少ないアプリケーションよりも多くのアプリケーションを持つことによって、市場占有率を最大化しようとする。コンピュータシステム上で実行することができるオペレーティングシステム及びアプリケーションプログラムの数を増やすために、ホストと呼ばれるあるタイプのＣＰＵを有する所与のコンピュータが、ホストコンピュータに、ゲストと呼ばれる関連のないＣＰＵの命令をエミュレートさせることができるバーチャライザプログラム（virtualizer program）を含むように開発されている。したがって、ホストコンピュータは、所与のゲスト命令に応答して呼び出されるべき１つまたは複数のホスト命令を生じさせるアプリケーションを実行するだろう。このようにして、ホストコンピュータは自身のハードウェアアーキテクチャ用に設計されたソフトウェアと、関連のないハードウェアアーキテクチャを有するコンピュータ用に作成されたソフトウェアとの双方を実行する。
【００１４】
より具体的な例として、例えば、アップルコンピュータによって製造されたコンピュータシステムは、ＰＣベースのコンピュータシステム用に作成されたオペレーティングシステム及びプログラムを実行することができる。バーチャライザプログラムを使用して、１つのＣＰＵ上で同時に、互換性のない複数のオペレーティングシステムを実行することも可能である。後者において、それぞれのオペレーティングシステムはその他のものと互換性がないのにも関わらず、バーチャライザプログラムは、いくつかのオペレーティングシステムをホストすることができ、そうすることによって、互換性のないオペレーティングシステムを同時に同一のホストコンピュータシステム上で実行することができる。
【００１５】
ゲストコンピュータシステムがホストコンピュータシステム上でエミュレートされると、ゲストコンピュータシステムは、ある特定のハードウェアアーキテクチャの動作の純粋なソフトウェア表現としてホストコンピュータシステム内にだけ存在するゲストコンピュータシステムとして、「仮想マシン」であると言われる。したがって、本件特許出願人によるバーチャルＰＣのような、仮想マシンソフトウェア内で稼動しているオペレーティングシステムは、「ゲスト」および／または「仮想マシン」と呼ぶことができ、一方、仮想マシンソフトウェアを実行しているオペレーティングシステムは、「ホスト」と呼ぶことができる。同様に、仮想マシン内で稼動しているレガシーゲームシステムにおけるオペレーティングシステムや、新しいゲームシステム内のエミュレーションソフトウェアは、「ゲスト」と呼ばれ、仮想マシンを実行している新しいゲームシステムのオペレーティングシステムや、エミュレーションソフトウェアは、「ホスト」と呼ばれる。用語「バーチャライザ(virtualizer)」、「エミュレータ」、「ダイレクト−エグゼキュータ（direct-executor）」、「仮想マシン」、及び「プロセッサエミュレーション」はしばしば、当業者によって知られており、理解されている１つまたはいくつかのアプローチを使用した、コンピュータシステム全体のハードウェアアーキテクチャを模倣し、エミュレートする能力を示すために交互に用いられる。さらに、任意の形式における用語「エミュレーション」の全ての使用は、広い意味を伝えることを意図するものであり、エミュレーションの命令実行概念と仮想マシンにおけるオペレーティングシステム命令の直接実行とを区別することを意図しない。したがって、例えば、本件特許出願人より入手可能な仮想ＰＣソフトウェアは、インテル８０Ｘ８６ペンティアム（登録商標）プロセッサ並びに様々なマザーボードコンポーネントおよびカードを含むコンピュータ全体を、（命令実行エミュレーションおよび／または直接実行によって）「エミュレート」し、これらのコンポーネントの動作は、ホストマシン上で実行される仮想マシン内で「エミュレート」される。パワーＰＣプロセッサを有するコンピュータシステムのようなホストコンピュータのオペレーティングシステムソフトウェア及びハードウェアアーキテクチャ上で稼動しているバーチャライザプログラムは、ゲストコンピュータシステム全体の動作を模倣する。
【００１６】
仮想化の一般的なケースは、１つのプロセッサアーキテクチャに、その他のプロセッサアーキテクチャ（例えば、ｘ８６Ｗｉｎｄｏｗｓ（登録商標）上のパワーＰＣＭａｃプログラム）からのＯＳやプログラムを実行することを可能にさせるが、特別なケースは、基礎をなすプロセッサアーキテクチャが同じ（ｘ８６上でｘ８６Ｌｉｎｕｘの様々なバージョンまたはｘ８６Ｗｉｎｄｏｗｓ（登録商標）の異なるバージョンを実行する）場合である。後者のケースでは、基礎をなす命令セットが同一であるため、ゲストＯＳおよびそのアプリケーションをより効果的に実行する可能性がある。そのような場合、制御を失わないで、またはシステムを攻撃に対してオープンのままにしないで（すなわち、ゲストＯＳはサンドボックスである）、ゲスト命令をプロセッサ上で直接実行することが可能になる。これは、特権を持つか持たないかの分離であり、メモリに対するアクセスを制御する技術が作用する。アーキテクチャのミスマッチ（パワーＰＣ＜−＞ｘ８６）がある場合の仮想化では、２つのアプローチが従来使用されている。あるアプローチでは、命令による命令（instruction-by-instruction）エミュレーション（比較的遅い）またはゲスト命令からの変換が元の命令セットにセットされる（より効果的には、変換ステップを使用する）。命令エミュレーションが使用される場合、環境の堅牢さを作り出すことは比較的容易である。もう一方のアプローチでは、変換が使用される場合、プロセッサが同じであるという特別なケースに合致する。
【００１７】
本発明によると、ゲストオペレーティングシステムが仮想化され、次いで本発明による例示的なシナリオが、本件特許出願人により入手可能な仮想サーバ上のＷｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ（登録商標）３．１、またはＷｉｎｄｏｗｓ（登録商標）ＮＴ４．０オペレーティングシステム、若しくは、Ｘボックスゲームコンソール上のＸボックスオペレーティングシステムのエミュレーションとなる。様々な実施形態において、本発明は、一部または全てのホストコンピュータの、基礎をなす物理リソースに対するゲストアクセスを制御するシステム及び方法を表す。
【００１８】
バーチャライザプログラムは、ホストマシンのハードウェアアーキテクチャと、エミュレートされた環境内で稼動しているソフトウェア（例えば、オペレーティングシステム、アプリケーションなど）によって転送された命令との間のインターチェンジとしての機能を果たす。このバーチャライザプログラムは、物理コンピュータハードウェア上で直接実行されているオペレーティングシステムである（ハイパーバイザ（hypervisor）を備えることができる）、ホストオペレーティングシステム（ＨＯＳ）とすることができる。あるいは、エミュレートされた環境は、仮想マシンモニタ（ＶＭＭ）であることもできる。仮想マシンモニタは、隣り合って実行され、ホストオペレーティングシステムに関連して動作している、ハードウェア上で直接実行されるソフトウェアレイヤであり、ＶＭＭが仮想化しているハードウェアと同じインターフェースを公開することによって、ホストマシン（および、ある仮想リソース）の全てのリソースを仮想化することができる。この仮想化は、バーチャライザ（および、ホストコンピュータシステム自身）が、その上で実行されているオペレーティングシステムレイヤによって気づかれずに済むようにすることができる。
【００１９】
よって、プロセッサエミュレーションは、ゲストオペレーティングシステムが、物理ハードウェアとホストオペレーティングシステムとを両方とも備えるホストコンピュータシステム上で実行されているバーチャライザによって作成された仮想マシン上で実行されることを可能にする。概念からは、コンピュータシステムは一般的に、ハードウェアの基礎的なレイヤ上で実行されているソフトウェアの、１つまたは複数のレイヤを備える。このレイヤ構造は、抽象理由（reason of abstraction）のためになされる。ソフトウェアの所与のレイヤに対するインターフェースを定義することによって、そのレイヤは、その上の他のレイヤによって異なって実装されることができる。上手く設計されたコンピュータシステムでは、それぞれのレイヤだけが、その下にある隣接するレイヤについて知っている（また、それだけに依存している）。このことは、レイヤまたは「スタック」（隣接している複数のレイヤ）が、レイヤまたはスタック上のレイヤにネガティブな影響を及ぼさずに置き換えられることを可能にする。例えば、ソフトウェアアプリケーション（上側のレイヤ）は一般的に、オペレーティングシステム（下側のレイヤ）のより低いレベルに依存して、ある形態の永久記録媒体にファイルを書込み、これらのアプリケーションは、フロッピー（登録商標）ディスク、ハードドライブ、またはネットワークフォルダにデータを書込むことの違いを理解する必要はない。この下側のレイヤがファイルを書込む新しいオペレーティングシステムコンポーネントに置き換えられた場合、上側のレイヤのソフトウェアアプリケーションの動作は、影響を受けないままである。
【００２０】
レイヤ構造のソフトウェアの柔軟性は、仮想マシン（ＶＭＭ）が、実際はもう１つのソフトウェアレイヤである仮想ハードウェアレイヤを提供することを可能にする。このように、ＶＭは、その上にあるソフトウェアレイヤに対して、ソフトウェアレイヤが自身のプライベートコンピュータシステム上で実行されているという幻想を作り出すことができ、ＶＭは、複数の「ゲストシステム」が、１つの「ホストシステム」上で同時に実行されることを可能にすることができる。この抽象レベルは、図１Ａによって示される。
【００２１】
図１Ａは、コンピュータシステムにおけるエミュレートされたオペレーティング環境について、ハードウェアおよびソフトウェアアーキテクチャの論理レイヤ構造を示す図である。図１Ａでは、エミュレーションプログラム５４は、物理ハードウェアアーキテクチャ５２上で、直接または間接的に実行される。エミュレーションプログラム５４は、（ａ）ホストオペレーティングシステムと同時に実行される仮想マシンモニタ、（ｂ）ネイティブなエミュレーション機能を有する専門の（specialized）ホストオペレーティングシステム、または、（ｃ）エミュレーションを実施するハイパーバイザコンポーネントを有するホストオペレーティングシステムとすることができる。エミュレーションプログラム５４は、ゲストハードウェアアーキテクチャ５６（このコンポーネントは「仮想マシン」、すなわち、実際には存在しないが、その代わりにエミュレーションプログラム５４によってエミュレートされるハードウェアであるということが、破線で示されている）をエミュレートする。ゲストオペレーティングシステム５８は、ゲストハードウェアアーキテクチャ５６上で実行され、ソフトウェアアプリケーション６０は、ゲストオペレーティングシステム５８上で実行される。図１Ａのエミュレートされたオペレーティング環境では、エミュレーションプログラム５４の動作のために、ソフトウェアアプリケーション６０が、一般的にホストオペレーティングシステム及びハードウェアアーキテクチャ５２と互換性のないオペレーティングシステム上で実行されるように設計されたとしても、ソフトウェアアプリケーション６０はコンピュータシステム５０において実行されることができる。
【００２２】
図１Ｂは、物理コンピュータハードウェア６２上で直接実行されているホストオペレーティングシステムソフトウェアレイヤ６４を備える仮想化されたコンピュータシステムを示す。ホストオペレーティングシステム（ホストＯＳ）６４は、ホストＯＳ６４が、その上で実行されているオペレーティングシステムレイヤによって気づかれずに済ますことができる、ホストＯＳがエミュレートされている（または、「仮想化されている」）ハードウェアと同じインターフェースを示すことによって、物理コンピュータハードウェア６２のリソースに対するアクセスを提供する。また、エミュレーションを実施するために、ホストＯＳ６４は、ネイティブなエミュレーション機能を有する、特別に設計されたオペレーティングシステムとすることができ、あるいは、エミュレーションを実施する組み込まれたハイパーバイザコンポーネント（図示せず）とすることができる。
【００２３】
図１Ｂに示されるように、ホストＯＳ６４の上には、２つの仮想マシン（ＶＭ）実装、例えば、仮想化されたインテル３８６プロセッサとすることができるＶＭ  Ａ６６、および、例えば、モトローラ６８０Ｘ０ファミリのプロセッサのうちの１つの仮想化されたバージョンとすることができるＶＭ  Ｂ６８がある。ＶＭ６６および６８の上には、それぞれゲストオペレーティングシステム（ゲストＯＳ）Ａ７０およびＢ７２がある。ゲストＯＳ  Ａ７０上で実行されているのは、２つのアプリケーション、アプリケーションＡ１  ７４およびアプリケーションＡ２  ７６であり、ゲストＯＳ  Ｂ７２上で実行されているのは、アプリケーションＢ１  ７８である。
【００２４】
図１Ｂに関して、（破線で示されている）ＶＭ  Ａ６６およびＶＭ  Ｂ６８は、ソフトウェア構成として存在するだけであり、ＶＭ  Ａ６６およびＶＭ  Ｂ６８をそれぞれゲストＯＳ  Ａ７０およびゲストＯＳ  Ｂ７２に提供するだけでなく、ゲストＯＳ  Ａ７０およびゲストＯＳ  Ｂ７２が実際の物理コンピュータハードウェア６２と間接的にやりとりするために必要な全てのソフトウェアステップを実施する特別なエミュレーションソフトウェアの実行により可能となった、仮想化されたコンピュータハードウェア表現であることに気づくことが重要である。
【００２５】
図１Ｃは、ホストオペレーティングシステム６４’’と同時に実行されている仮想マシンモニタ（ＶＭＭ）６４’によってエミュレーションが実施される、代替の仮想化されたコンピューティングシステムを示す。一実施形態では、ＶＭＭ６４’は、ホストオペレーティングシステム６４’’上で実行され、ホストオペレーティングシステム６４’’だけを介して物理コンピュータハードウェア６２とやりとりしているアプリケーションとすることができる。その他の実施形態では、図１Ｃに示されるように、ＶＭＭ６４’は、あるレベルではホストオペレーティングシステム６４’’を介してコンピュータハードウェア６２と間接的にやりとりし、その他のレベルでは（ホストオペレーティングシステムがコンピュータハードウェアと直接的にやりとりする方法と同様に）ＶＭＭ６４’がコンピュータハードウェア６２と直接的にやりとりする、部分的に独立したソフトウェアシステムを代わりに備えることができる。
【００２６】
仮想マシンを実装するこれらのバリエーションの全てが、本明細書で説明されるように本発明のその他の実施形態を形成するように期待され、本発明を特定のエミュレーション形態に限定するように解釈されるべきではない。また、（おそらくはハードウェアエミュレーションシナリオにおける）ＶＭ  Ａ６６および／またはＶＭ  Ｂ６８それぞれを介したアプリケーション７４、７６、および７８の間のやりとりへの言及は、実際は、アプリケーション７４、７６、および７８と、仮想化を作り出しているバーチャライザとの間のやりとりであると解釈されるべきである。同様に、（おそらくはコンピュータハードウェア６２上で直接的にまたは間接的にコンピュータ命令を実行するための）ホストオペレーティングシステム６４および／またはコンピュータハードウェア６２との、アプリケーションＶＭ  Ａ６６およびＶＭ  Ｂ６８の間のやりとりへの言及は、実際は、仮想化を作り出しているバーチャライザと、ホストオペレーティングシステム６４および／またはコンピュータハードウェア６２との間のやりとりであると解釈されるべきである。
【００２７】
（複数の経路最適化を備える関数レベルジャストインタイム変換エンジン）
本発明は、レガシーゲームシステムプラットフォーム（legacy game system platform）の最新版であるホストゲームシステムプラットフォーム上で、Ｘボックスのようなレガシーゲームシステムプラットフォームを仮想化するためのソフトウェアエミュレータを使用するシステムの機能に関する。ソフトウェアエミュレータは、ホストゲームシステムプラットフォームが、シームレスな方法でレガシーゲームを実行することを可能にする。上述したように、本発明は、関数レベルでコードを変換し、変換を仮想化して、コード変換効率を向上させるジャストインタイム変換エンジンを有するソフトウェアエミュレータを提供する。本発明の技術を、図２〜４を参照して以下に説明する。
【００２８】
本発明によると、ホストゲームシステムコンソールのメディアローダ（media loader）がレガシーコンピュータゲームを含むメディアを受け取り、ホストゲームシステムのオペレーティングシステムにレガシーコンピュータゲームを起動するように要求されると、メディアローダはその代わりに、レガシーコンピュータゲームの動作のための互換性を提供する、本発明に係るソフトウェアエミュレータを起動する。ソフトウェアエミュレータは、ホストゲームシステムのネイティブなコンピュータゲームと同じ権利（right）および同じ制約（restriction）を有する標準的なゲームのように、レガシーコンピュータゲームをロード（load）し、実行する。起動時に、ソフトウェアエミュレータは、２つの物理メモリチャンク、すなわち、仮想化されたレガシーコンピュータゲームをホストするための６４ＭＢセグメント、および、レガシーコンピュータゲームを実装する仮想マシンとホストコンピュータゲームシステムとの間のルート（conduit）を提供するための６４ＭＢセグメントを要求する。
【００２９】
図２は、仮想マシン内に実装されたレガシーゲームシステムの仮想メモリとホストゲームシステムの仮想メモリとの間の関係を示す。この例では、レガシーゲームシステムは、本件特許出願人より入手可能なＸボックスである。図示されるように、レガシーＸボックスゲームシステムは、仮想マシン環境内に実装され、４ＧＢの仮想アドレス空間８０が利用可能であるとする。図示されるように、レガシー４ＧＢ仮想アドレス空間は、レガシーＸボックスゲームシステムが、挿入されたレガシーゲームの仮想タイトル専用のメモリ８２、仮想レガシーＸボックスカーネル専用のメモリ８４、ホストゲームシステムの物理ＲＡＭ８８内の６４ＭＢ共有メモリに直接マップ（map）する６４ＭＢ共有メモリ８６、および、４ＧＢ仮想アドレス空間の上側の領域内の仮想ＭＭＩＯアドレス空間９０というセクションを有する。レガシーＸボックスゲームシステム内のＭＭＩＯアドレス空間９０は、Ｘボックスゲームシステムコンソールのオペレーティングシステムのドライバによって呼び出される実際のハードウェアデバイスへのポインタを備えることが、当業者には理解されるだろう。仮想マシン環境内に実装されるようなレガシーＸボックスゲームによってアクセスされる仮想アドレス空間は、ネイティブなレガシーＸボックスゲームシステム環境内の仮想アドレス空間と同様に構成され、レガシーＸボックスゲームシステムがネイティブなレガシーＸボックスゲームシステム環境内で動作していると勘違いさせる。
【００３０】
一方、ネイティブなホストＸボックスゲームシステムの仮想アドレス空間９２は、エミュレータバイナリメモリ９４、ネイティブなホストＸボックスカーネル９６、レガシーＸボックス仮想マシンをホストする６４ＭＢ物理メモリセグメント９８によって特徴付けられる。６４ＭＢ共有メモリ１００は、ネイティブなホストＸボックスゲームシステムの物理ＲＡＭ８８内の６４ＭＢ共有メモリ直接マップするように提供される。図３を参照して以下に詳細に説明されるように、ｘ８６Ｘボックスカーネル８４の再作成されたコピーとゲームローダに渡されたｘ８６タイトルバイナリは、仮想Ｘボックスゲームシステム用意された６４ＭＢ空間９８内にロードされる。一方、６４ＭＢ共有メモリ空間１００において、ネイティブなホストＸボックスゲームシステムは、そのディスパッチャ（dispatcher）プログラムをロードし、最適化された（hand-optimized）「ｇｌｕｅ」関数（function）をロードし、仮想マシン（ＶＭ）状態および変換されたコードキャッシュのための構造を作成する（図３）。これらの機能は、実際は、レガシーＸボックスを実装している仮想マシンとネイティブなホストＸボックスオペレーティングシステムとの両方にアクセス可能なＲＡＭの物理共有セクションである共有メモリ８８を介して、仮想マシン上で実行されているレガシーＸボックスゲームと共有される。
【００３１】
図３は、本発明の技術を使用して、仮想マシン内に実装されたレガシーゲームシステムのｘ８６コードを、ホストゲームシステムのＰＰＣコードに変換するソフトウェアエミュレーションシステムを示す。図示されるように、本発明のソフトウェアエミュレーションシステムは、４つの主要なコンポーネントを含む。  
・レガシーＸボックスゲームシステムのｘ８６コードの、ＰＰＣコードまたはネイティブなホストＸボックスゲームシステムのその他のプロセッサコードへのジャストインタイムバイナリ変換を提供するジャストインタイム（ＪＩＴ）バイナリトランスレータ（translator）１０２
・複製されたｘ８６Ｘボックスカーネル１０６および変換されていないタイトルコードストア１０８内のほとんどのレガシーＸボックス環境、並びに格納されたタイトルリソースおよび状態ストア内のレガシータイトル環境を再作成するレガシーＸボックス仮想マシン（ＶＭ）１０４
・ネイティブなホストＸボックスゲームシステムのオペレーティングシステムとＶＭ１０４との間のやりとり（communication）を可能にし、ディスパッチャ１１２および変換されたコードキャッシュ１１４をホストし、ＶＭ状態１１６を追跡（track）する共有メモリ８８
・ＸボックスＶＭ１０４で使用するために、ネイティブなＸボックスカーネル１２２上で、デバイスエミュレーション１２０を使用して、レガシーＸボックスゲームを実行しているネイティブなホストＸボックスシステムのハードウェアデバイスをエミュレートするＸボックス例外ハンドラ１１８
【００３２】
レガシーＸボックス仮想マシン１０４内のレガシーＸボックスゲームを初期化した後、ネイティブなホストＸボックスゲームシステムのオペレーティングシステムは、共有メモリ８８内にあるディスパッチャ１１２に制御を渡す。基本的に、ディスパッチャ１１２は、仮想化されたレガシーＸボックスゲームについてのコード実行を指示する。ディスパッチャ１１２は、ハッシュテーブル（hash table）における、ｘ８６空間内で参照された全てのｘ８６関数と、対応する、変換されたコードキャッシュ１１４内の変換されたＰＰＣ（またはその他のホストプロセッサ）関数との間のマッピング（mapping）を維持する。ディスパッチャ１１２のジョブは、仮想化されたｘ８６レガシーＸボックスタイトルに期待されるシーケンスにおいて、変換されたＰＰＣ（またはその他のホストプロセッサ）関数を共に繋ぐ（chain）ことである。ディスパッチャ１１２の第１のタスクは、レガシーｘ８６Ｘボックスカーネル１０６およびタイトルメモリ１１０内のレガシーｘ８６タイトルの起動をシミュレートすることである。ネイティブなホストＸボックスゲームシステムのホストＯＳが、エミュレートされたバイナリのかなりの（significant）事前変換を実施しない場合、ディスパッチャ１１２は、要求されたｘ８６関数に対してキャッシュされたＰＰＣ（またはその他のホストプロセッサ）同等物（equivalent）を有さない。これらのギャップ（gap）を満たすために、ディスパッチャ１１２は、ジャストインタイム関数変換のためにＪＩＴバイナリトランスレータ１０２にコール（call）する。
【００３３】
例えば、ｘ８６コードをＰＰＣコードへ変換することは、ある意味では問題である（problematic）ことが当業者には理解されるだろう。一つには、ｘ８６ＩＳＡは、シンプルなＰＰＣ  ＩＳＡ同等物を有さない、いくつかの複雑な関数を含む。さらに、ネイティブなホストＸボックスゲームシステムのＰＰＣプロセッサは、レガシーＸボックスタイトルがリトルエンディアン（Little-Endian）解釈を期待するのに対して、データをビッグエンディアン（Big-Endian）として解釈するように構成されることができる。また、レガシーＸボックスｘ８６コードの単純（naive）な変換は、ネイティブなホストＸボックスシステムハードウェア上で、命令の非常に大きな拡大（huge magnification）およびキャッシュミス（cash miss）をもたらすことになる。本発明のＪＩＴバイナリトランスレータは、以下に説明されるように、この「変換膨張（translation bloat）」を軽減させるステップを有する。
【００３４】
図３に示されるように、本発明のＪＩＴバイナリトランスレータは、５つのステップ（１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ）で実装される。それぞれのステップを順番に説明する。
【００３５】
ステップ１：ｘ８６フェッチ（fetch）およびパース（parse）。ステップ１０２ａにおいて、ＪＩＴバイナリトランスレータ１０２は、ディスパッチャ１１２に呼び出され、仮想マシン１０４の４ＧＢアドレス空間８０内のｘ８６コードを参照している拡張命令ポインタ（ＥＩＰ）１１２ｂを渡される。バイナリ変換のこの第１段階において、アドレス変換が実施され、ソフトウェアエミュレータの４ＧＢ仮想アドレス空間９２内の、対応するメモリアドレスを決める。次いで、ソフトウェアエミュレータは、４ＧＢアドレス空間８０からｘ８６コード関数に対応する構造（structure）にｘ８６関数命令コードを解析（parse）する。関数が、仮想アドレス空間９２内の事前割り当てされた構造空間よりも大きいことが分かった場合、ＪＩＴバイナリトランスレータ１０２は、実行を中止（halt）する。
【００３６】
ステップ２：ｘ８６コード最適化。ＪＩＴバイナリトランスレータ１０２がターゲットｘ８６関数をロードすると、ステップ１０２ｂにおいて、最初の最適化が実施される。ＰＰＣの効率の悪さを生み出すことで知られている一連のｘ８６コードは、後で参照するためにフラッグされる（flagged）。例えば、オプティマイザ（optimizer）は、エンディアンバイト反転（endian byte reversal）を要求しない、不揮発性のストア／ロード動作を記憶する。
【００３７】
ステップ３：ＰＰＣデスクリプタ生成（descriptor generation）。１０２ｃにおいて、オプティマイザはその生成物を、対応する一群のＰＰＣ命令への、最適化されたｘ８６命令の単純な変換を実施するＪＩＴ中間階層（middle tier）に渡す。一般的に、１つのｘ８６命令は、複数のＰＰＣ命令に対応する。ｆｓｉｎのようなとても複雑なｘ８６命令は、共有メモリ８８に格納された、コード化した（hand-coded）ＰＰＣ「ｇｌｕｅ」関数によって置き換えられる。
【００３８】
ステップ４：ＰＰＣバイナリ実行可能最適化（binary executable optimization）。ステップ１０２ｄにおいて、ＰＰＣバイナリ実行可能（ＢＥ）オプティマイザは、ステップ１０２ｃにおいて生成された一連のＰＰＣ命令を受け取り、命令数、サイクル数、およびキャッシュミスレート（cash miss rate）をできる限り減らそうとする。この段階の後にＰＰＣコード内に残存する「変換膨張」は、ホストコンピュータシステムのＣＰＵ速度によってのみ補償することができる。
【００３９】
ステップ５：ＰＰＣコンパイル（compilation）および格納（store）。最後に、ステップ１０２ｅにおいて、ＪＩＴバイナリトランスレータ１０２は、ＰＰＣデスクリプション（description）を３２ビットＰＰＣマシン命令にマップする。変換された関数の全ては、共有メモリ８８内の変換されたコードキャッシュ１１４内に格納され、関数の開始アドレスは、ディスパッチャ１１２のハッシュテーブル内の元のＥＩＰ１１２ｂの隣の命令アドレスレジスタ（ＩＡＲ）１１２ａとして格納される。これは、ソフトウェアエミュレータが、変換されたコードブロックへの入力コードブロックのマッピングを記憶することができるようにして、ＪＩＴバイナリトランスレータ１０２を呼び出す前にディスパッチャ１１２のハッシュテーブルをチェックすることによって、同じコードブロックのリコンパイルを避けることができるようにする。次いで、ソフトウェアエミュレータは制御を譲り、スレッドは仮想マシン１０４に戻される。
【００４０】
仮想マシン１０４が再開すると、ディスパッチャ１１２は再び、所望のＥＩＰをＩＡＲにマップしようとする。今回は、ルックアップが成功し、ディスパッチャ１１２は、コード実行を、指名されたＩＡＲにジャンプさせる。レガシーＸボックスコマンドシーケンスにおいて、１つまたは複数のｘ８６命令に対応する所望のＰＰＣ関数は実行され、レガシーＸボックス仮想マシン１０４の４ＧＢメモリ空間内のリソース上で動作する。レガシーＸボックス仮想マシンが所望のＰＰＣ関数の処理を完了すると、次のｘ８６関数に対するリクエストを有する割込みによって、制御はディスパッチャ１１２に戻り（jump back）、全体のＪＩＴバイナリ変換サイクルが再び始まる。コンピュータゲームは一般的に膨大なループ（enormous loop）としてコード化されるので、実行の数秒後には、ほとんどのｘ８６関数が変換されて、最適化されたＰＰＣコード（または、ネイティブなホストＸボックスゲームシステムが異なるプロセッサを使う場合は、その他のプロセッサコード）として変換されたコードキャッシュ１１４内に存在する。
【００４１】
ＪＩＴバイナリトランスレータ１０２は、ジャストインタイムコンパイラ（just-in-time compiler）であり、それらの関数が必要とされるまで、ｘ８６関数をＰＰＣコードに変換しないことが、当業者には理解されるだろう。本発明の技術は、ＪＩＴバイナリトランスレータ１０２が初めて多くの関数に出くわした場合に、認識された（perceived）遅れを避けるように設計される。一組のオプションが、この問題に対処すると考えることができる。
【００４２】
・バイナリ内で多くの関数を事前コンパイル（pre-compile）する。アプリケーションプログラムまたはゲームを起動して、問題のある関数を認識する前に、ソフトウェアエミュレータには時間があり、ゲームが始まる前にそれらをコンパイルすることができる。これは、認識されたジッタ（jitter）を除去することができるが、より長い起動の遅れを意味する。
【００４３】
・一部の関数の２段階コンパイルを実施する。ＪＩＴバイナリトランスレータ１０２は、一部の関数についてパフォーマンスの最適化をスキップして、それらをすばやく実行することができる。第２のＣＰＵ上で実行されているスレッドが、ちょうどよいときにそのコードを最適化し、コードキャッシュ内の命令コードを置き換えることができる。
【００４４】
仮想化されたレガシーＸボックスゲームがレガシーＸボックスハードウェアとの対話を望むが、ネイティブなホストＸボックスゲームシステムのプラットフォーム上でそれが動作していることに気づかない場合、レガシーＸボックスゲームによるデバイスリクエストおよびシステム呼び出しは、例外を作成する。多くのオペレーティングシステムと同様に、レガシーＸボックスオペレーティングシステムでは、ゲームは、周知のメモリマップドＩ／Ｏ（ＭＭＩＯ）領域に対する書込みによって、ほとんどのデバイスと対話（communicate）する。図２に示されるように、Ｘボックスオペレーティングシステムの場合、これらのＭＭＩＯ領域は、４ＧＢ仮想メモリ空間の上側の領域９０内にあった。アクセスコントロールリスト（ＡＣＬ）は、ページ許可（page permission）（すなわち、読むだけ、または読み書き不可）を制限し、および／または、削減するために使用することができ、レガシーＸボックスゲームを実装している仮想マシン１０４が、メモリ９０内のこれらのＭＭＩＯアドレスに対する読み書き権限を欠くようにする（米国特許出願（本件特許出願人整理番号第３１２６３４．０１号）参照）。その結果、仮想マシン１０４内で実行されているレガシーＸボックスゲームが、その期待されたデバイスメモリ９０にアクセスしようとすると、ホストＸボックスオペレーティングシステムは、１２６において無効なＸボックスＭＭＩＯデバイスアドレスを検出し、そのスレッドを中止する。メモリアクセス違反メッセージは、ＶＭ状態情報をＸボックス例外ハンドラ１１８に順次渡して、メモリアクセス違反を解決するハイパーバイザ１２８に送信される。
【００４５】
ハイパーバイザ１２８によってＸボックス例外ハンドラ１１８に送信されたメモリアクセス違反および意図的なシステム呼び出しは、レガシーＸボックスゲームから、ＭＭＩＯ書込み（write）内に提供されたＭＭＩＯアドレスを使用する所望のターゲットデバイスを判定するために処理される。メモリアクセス違反はしばしば仮想デバイスリクエストを示すので、Ｘボックス例外ハンドラ１１８は、（ＶＭ状態レジスタ１１６からの）ハイパーバイザ１２８によって提供される仮想マシン状態を簡単にチェックし、所望のターゲットデバイスを判定する。次いで制御は、Ｘボックス例外ハンドラ１１８内の適切なＸボックスデバイスエミュレータ１２０に与えられる。Ｘボックスデバイスエミュレータは、仮想マシン１０４のリクエストを変換し、Ｘボックスカーネル１２２の適切な関数、またはネイティブなホストＸボックスライブラリに中継する。ネイティブなホストＸボックスシステムは、レガシーＸボックスシステムとハードウェアを共有すると考えることはできないので、シンプルな命令転送（simple instruction forwarding）はオプションである。もちろん、ハードウェアが共有される場合は、命令転送を使用することができる。
【００４６】
図３に示されるように、ハードドライブＩ／Ｏのような、Ｘボックス物理デバイス１２４に対する一部のネイティブなハードウェアリクエストは、デバイス割込み１３０の形式で非同期コールバックを生成する。ネイティブなホストＸボックスカーネル１２２が割込みなどを受信すると、ＪＩＴバイナリトランスレータ１０２を中止し、順次応答を変換し、それを共有メモリ空間８８内に格納するＸボックス例外ハンドラ１１８内の適切なＸボックスデバイスエミュレータ１２０に対する、割込みデータを供給する。次いで、制御は、レガシーＸボックス割込みをシミュレートすることによって仮想マシン１０４に戻され、仮想マシン１０４が新しいデータを処理することができるようにする。
【００４７】
図４は、本発明のＪＩＴバイナリトランスレータ１０２の動作を示す。図示されるように、ＪＩＴバイナリトランスレータ１０２は、与えられたアドレスにおいて開始することによって、ステップ１３２において、入力ソースコードのコンパイルを開始する。ＪＩＴバイナリトランスレータ１０２は、実行のために、マシン実行可能コードの流れ（stream）のビルドを開始する。一方、本発明によると、ＪＩＴバイナリトランスレータ１０２のパーサ１０２ａは、コードパターンを認識し、それに応じて動作することによって、ステップ１３４において、マシンコード内の関数を識別する。例えば、ソース関数は、タスクを処理し、処理された変数（variables）を戻す、プロローグ、ボディ、およびエピローグを有するものとして定義することができる。プロローグは、関数を導入し、変数を定義し、エピローグは、関数を終了させて、適切な制御フローを戻し、変数値（variable value）を戻す。一般的に、エピローグは、ＲＥＴまたはＩＲＥＴ関数である。一方、ボディは、条件分岐を含む、ネストされるかどうかはわからないその他の記述（statement）を実行するために、コード文およびコードコンディション（code statements and conditions）を含む。
【００４８】
パーサ１０２ａが、シンプルな関数を解析する方法の例をコードリストから以下に示す。
Ａ．整数の加算
int   add(int i, intj)              : prolog
{                                   : mov eax, i
return (i+j);                 : add eax,j
}                                   : epilog
Ｂ．整数の乗算
int   multiply(int i, intj)         : prolog
{                                   : mov eax, i
return (i*j);                 : imul eax,j
}                                   : epilog
Ｃ．整数 i,j についてのj+(i*j)の計算
int   multiplyadd(int i, intj)      : prolog 
{                                   : pushj
: push i
return add(multiply(i j), j); : call multiply
: push eax
: pushj
: call add
}                                   : epilog
【００４９】
Ｄ．条件付き分岐を有する例
以下の例は、関数が完了したとみなされる前に決定（resolution）を必要とする未解決の（outstanding）条件分岐を示す。
【００５０】
int arithmetic (int i, int j, int operation)
{                                    : prolog
if (operation == ADD)            : cmp operation,ADD
{                               : jnz NotAdd
return (i+j);             : mov eax,i
: add eax,j
: ret
}                               : NotAdd:
else if (operation == SUBTRACT)  : cmp operation,SUBTRACT
{                               : jnz NotSubtract
return (i-j);          : mov eax,i
: sub eaxj
: ret
}                               : NotSubtract:
else if (operation == MULTIPLY) : cmp operation,MULTIPLY
{                               : jnz NotMultiply
return (i*j);         : mov eax,i
: imul eax,j
: ret
}                               : NotMultiply:
else if (operation == DIVIDE)   : cmp operation,DIVIDE
{                               : jnz NotDivide
return (i/j);         : mov eax,i 
: idiv eax j
: ret
}                               : NotDivide:
}                                    : epilog
【００５１】
上述した例で示されるように、パーサ１０２ａは、プロローグ、ボディ、およびエピローグを、１つの機能ブロックとして処理する。ブロックは、コードを分析することによって識別され、プロローブおよびエピローグを識別し、分岐操作を識別する。ステップ１３４において示されるように、関数は、エピローグに到達して、未解決の条件分岐がない場合に、終了されることがわかる。言い換えると、ＲＥＴまたはＩＲＥＴがパーサ１０２ａに出くわして、未解決の条件分岐がない場合に、ＪＩＴバイナリトランスレータ１０２は、マシンコード関数の最後に到達したことがわかる。
【００５２】
パーサ１０２ａによって提供されるコードの、結果として生じる機能ブロックは、ステップ１３６においてＪＩＴバイナリトランスレータ１０２のオプティマイザ１０２ｂによって最適することができ、処理効率を向上させることができる。例えば、パワーＰＣプロセッサは元々（natively）ビッグエンディアンであり、ビッグエンディアン形式でロードされるデータは、１つ（または最高２つ）のパワーＰＣ命令を必要とするのに対して、ｘ８６は元々リトルエンディアンであり、リトルエンディアン形式でロードされるデータは、１つまたは複数（最大７）のパワーＰＣ命令を必要とする。したがって、オプティマイザ１０２ｂによって実施されることができる１つの明らかな最適化は、できる限りビッグエンディアン形式でデータを格納し、データをリトルエンディアン形式に変換することは避けることである。この最適化は、実行時に処理されなければならない命令をより少なくする。
【００５３】
その他のシンプルな例として、ソースコードのブロックのサポートは、ｉの値を計算するように記述される。ここで、ｉ＝ｊ＊ｋである。コードは、以下のように書くことができる。
【００５４】
k=0
jump to routine to calculate value of j
return value of j
i=j*k
【００５５】
この例では、ｋ＝０なので、結果は、たとえ計算された値がｊのためであっても、ゼロとなる。したがって、このコードは、ｉ＝０に最適化することができる。それぞれの命令が別々に変換される従来のシステムでは、命令の文脈がわからないので、ジャンプルーチン（jump routine）は解決されなければならないだろう。
【００５６】
関数が識別され、コードが最適化されると、ステップ１３８において、入力マシンコード内で関数を作り出すプロセッサ命令が、ターゲットプロセッサのマシンコードに変換される（例えば、ｘ８６からパワーＰＣ）。次いで、ステップ１４０において、生成されたマシンコードが、例えば、命令数、サイクル数、およびキャッシュミスレートをできる限り削減することによって最適化される。結果として生じる、ターゲットプロセッサについて最適化されたマシンコードは、ステップ１４２における実行のために、変換されたコードキャッシュ１１４内に格納される。最後に、ステップ１４４において、エントリ（entry）が、最適化されたコードブロックを識別するディスパッチャハッシュテーブル内に置かれ、入力コードストリーム内で機能ブロックに出くわす次のときに、同じ機能ブロックをリコンパイルすることが避けられるようにする。
【００５７】
このように、本発明は、ＪＩＴバイナリトランスレータがより効率的に、第１のプロセッサ用に書かれた命令を、受信した命令の文脈に基づいて、第２のプロセッサ用の命令に変換することができるメカニズムを提供する。特に、バイナリトランスレータは、コードの機能ブロックに対して実施され、バイナリ変換動作をスピードアップできるように最適化する。本発明によるＪＩＴバイナリトランスレータは、高速な変換が円滑な動作にとって重要である仮想マシン環境内で実行されているプログラムまたはゲームに用いられる場合に、特に有利である。このような技術は、単にゲームシステムだけではなく、あらゆるアプリケーションに拡大適用できることが、当業者には理解されるだろう。さらに、本発明の技術を使用して、ソフトウェアエミュレーション技術を実装しているその他のコンピュータシステムにバイナリ変換を提供することができる。
【００５８】
（ネットワーク化され、分散された例示的環境）
本発明の例示的実施形態は、Ｘボックスゲームシステムアーキテクチャに関連して実装することができるが、本発明は、コンピュータネットワークの一部として、または分散コンピューティング環境内で使用することができる、任意の適切なホストコンピュータ、若しくはその他のクライアントまたはサーバデバイスに関連して実装することができることは、当業者には理解できるだろう。この点において、本発明は、本発明によるゲストＯＳを仮想化することに関連して使用することができる、複数のメモリまたは記憶装置、並びに複数のアプリケーションおよび複数の記憶装置またはボリュームにわたって生じるプロセスを有するコンピュータシステムまたはコンピュータ環境にも適している。本発明は、リモートまたはローカルストレージを有する、ネットワーク化された環境または分散コンピューティング環境で使用することができるサーバコンピュータおよびクライアントコンピュータを有する環境に適用することができる。本発明は、プログラミング言語機能、ならびに、リモートまたはローカルサービスに関連する情報を生成し、受信し、送信する割込み及び実行機能を有する、スタンドアロンコンピューティングデバイスにも適用することができる。
【００５９】
分散コンピューティングは、コンピューティングデバイスとシステムとの間の交換（exchange）によって、コンピュータリソースとサービスを共有することを提供する。これらのリソースおよびサービスは、情報の交換、キャッシュストレージ（cache storage）、およびファイル用のディスクストレージを含む。分散されたコンピューティングは、クライアントが、それらの集合したパワーを利用することができるようにして、全体の活動（entire enterprise）のためになるネットワーク接続をうまく利用することができる。
【００６０】
図５Ａは、ネットワーク化された、または分散された例示的コンピューティング環境の概念図を示す。分散コンピューティング環境は、コンピューティングオブジェクト１４５ａ、１４５ｂなど、並びに、コンピューティングオブジェクトまたはデバイス１４６ａ、１４６ｂ、１４６ｃなどを備える。これらのオブジェクトは、プログラム、方法、データストア、プログラム可能ロジックなどを備えることができる。オブジェクトは、ＰＤＡ、オーディオ／ビデオデバイス、ＭＰ３プレーヤ、パーソナルコンピュータなどのような、同一または異なるデバイスの部分を備えることができる。オブジェクトはそれぞれ、コミュニケーションネットワーク１４７を介して、その他のオブジェクトと通信することができる。このネットワークは、図５Ａのシステムにサービスを提供するその他のコンピューティングオブジェクトおよびコンピューティングデバイスを備えることができ、複数の相互接続したネットワークを表わすことができる。本発明の一側面によると、オブジェクト１４５ａ、１４５ｂなど、または１４６ａ、１４６ｂ、１４６ｃなどのそれぞれは、ＡＰＩ、その他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを利用するアプリケーションを含み、本発明の仮想化プロセスの使用を要求することができる。
【００６１】
１４６ｃのようなオブジェクトは、その他のコンピューティングデバイス１４５ａ、１４５ｂなど、または１４６ａ、１４６ｂなどで、ホストされることができることは理解されるだろう。したがって、図示された物理環境は、接続されたデバイスをコンピュータとして表わすことができるが、そのような描写は単なる例示であり、物理環境はその代わりに、ＰＤＡ、テレビジョン、ＭＰ３プレーヤなどの様々なデジタルデバイス、並びに、インターフェース、ＣＯＭオブジェクトなどのようなソフトウェアオブジェクトを備えるものとして描写し、説明することができる。
【００６２】
分散コンピューティング環境をサポートする様々なシステム、コンポーネント、およびネットワーク構成がある。例えば、コンピューティングシステムは、有線または無線システムによって、若しくは、ローカルネットワークまたは広く分散されたネットワークによって、相互に接続することができる。現在、多くのネットワークが、広く分散されたコンピューティングのために通信インフラ（infrastructure）を提供し、多くの様々なネットワーク含むインターネットとつながっている。通信インフラは、本発明の仮想化プロセスから生じる例示的な相互通信のために使用することができる。
【００６３】
ホームネットワーキング環境では、電力線（power line）、データ（無線および有線の両方）、音声（例えば電話）、娯楽メディアなどのような、それぞれ独自のプロトコルをサポートすることができる少なくとも４つの異なるネットワーク転送媒体がある。光スイッチおよび電気器具などのようなほとんどのホームコントロールデバイス（home control device）は、接続のために電力線を使用することができる。データサービスは、ブロードバンド（例えば、ＤＳＬまたはケーブルモデム）として家に入ることができ、無線（例えば、ホームＲＦまたは８０２．１１Ｂ）または有線（例えば、ホームＰＮＡ、Ｃａｔ５、イーサネット（登録商標）、電力線）接続を使用する家の中でアクセス可能である。音声トラフィックは、有線（例えばＣａｔ３）または無線（例えば携帯電話）として家に入ることができ、Ｃａｔ３配線を使用する家の中に分配することができる。娯楽メディアまたはその他のグラフィカルデータは、衛星またはケーブルを介して家に入ることができ、一般的に同軸ケーブルを使用する家の中に分配することができる。ＩＥＥＥ１３９４およびＤＶＩも、メディアデバイスのクラスタ用のデジタル相互接続である。これら全てのネットワーク環境、および、プロトコル標準として現れることができるその他のものは、インターネットによって外の世界に接続されることができるイントラネットなどのようなネットワークを形成するために相互接続されることができる。要するに、多様なソースが、データの記憶および転送のために存在し、コンピューティングデバイスは、本発明による仮想化されたサービスを利用するプログラムオブジェクトから生じ、アクセスされ、利用されるデータなどのようなデータを共有する方法を必要とする。
【００６４】
インターネットは一般に、コンピュータネットワーキングの分野ではよく知られているＴＣＰ／ＩＰプロトコルを利用するネットワークおよびゲートウェイの集合に言及する。ＴＣＰ／ＩＰは、「Transmission Control Protocol/Internet Protocol」の頭文字である。インターネットは、ユーザが、ネットワークを介して情報を相互通信し、共有することができるようにするネットワーキングプロトコルを実行するコンピュータによって相互接続された、地理的に分散されたリモートコンピュータネットワークのシステムとして説明することができる。そのような幅広い情報共有のために、インターネットなどのリモートネットワークは一般的に、開発者が、特別な動作またはサービスを実施するためのソフトウェアアプリケーションを、基本的には制限なしで設計することができるオープンシステムに進化している。
【００６５】
したがって、ネットワークインフラは、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャなどのようなネットワークトポロジーのホストを可能にする。「クライアント」は、それに関連しないその他のクラスまたはグループのサービスを使用するクラスまたはグループの一員である。したがって、コンピューティングにおいて、クライアントはプロセス、すなわち、大まかには、その他のプログラムによって提供されるサービスを要求する一組の命令またはタスクである。クライアントプロセスは、その他のプログラムまたはサービス自身についての詳細を知ることなしに、要求されたサービスを利用することができる。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムでは、クライアントは通常、例えばサーバなどのその他のコンピュータによって提供される共有ネットワークリソースにアクセスするコンピュータである。図５Ａの例では、任意のコンピュータは、状況次第でクライアント、サーバ、またはその双方とみなすことができるが、コンピュータ１４６ａ、１４６ｂなどは、クライアントとして考えることができ、コンピュータ１４５ａ、１４５ｂなどは、クライアントコンピュータ１４６ａ、１４６ｂなどで複製されるデータを保持するサーバとして考えることができる。これらのコンピューティングデバイスは、データを処理し、または、本発明の仮想化プロセスの実装に関係させることができるサービスまたはタスクを要求することができる。
【００６６】
サーバは一般的に、インターネットなどのリモートまたはローカルネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは、第１のコンピュータシステム内でアクティブであり、サーバプロセスは、第２のコンピュータシステム内でアクティブである。コンピュータシステムは通信媒体を介して互いに通信し、分散機能を提供し、複数のクライアントがサーバの情報収集能力を活用できるようにする。本発明の仮想化アーキテクチャを使用することによって利用されるソフトウェアオブジェクトは、複数のコンピューティングデバイスまたはオブジェクトにわたって分散することができる。
【００６７】
クライアントおよびサーバは、プロトコルレイヤによって提供される機能を利用して、互いに通信する。例えば、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）または「ウェブ」に関連して使用される共通プロトコルである。一般的に、インターネットプロトコル（ＩＰ）アドレスまたはユニバーサルリソースロケータ（ＵＲＬ）などのコンピュータネットワークアドレスを使用して、サーバまたはクライアントコンピュータを識別する。ネットワークアドレスは、ＵＲＬアドレスとして呼ばれることができる。通信は、通信媒体を介して提供することができ、例えば、クライアントまたはサーバは、高容量通信用のＴＣＰ／ＩＰ接続を介して互いにつながることができる。
【００６８】
図５Ａは、本発明を使用することができる、ネットワーク／バスを介してクライアントコンピュータと接続されるサーバを有する、ネットワーク化された、または分散された例示的環境を示す。より詳細には、複数のサーバ１４５ａ、１４５ｂなどは、通信ネットワーク／バス１４７を介して、複数のクライアントまたはリモートコンピューティングデバイス１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどと相互接続される。通信ネットワーク／バス１４７は、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどとすることができる。クライアントまたはリモートコンピューティングデバイス１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどは、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化された家電製品、または、ＶＣＲ、ＴＭ、オーブン、ライト、ヒータなどのようなその他のデバイスとすることができる。したがって、本発明は、本発明によるゲストインターフェースおよびオペレーティングシステムを実装することが望まれる、任意のコンピューティングデバイスに適用することができる。通信ネットワーク／バス１４７がインターネットであるネットワーク化された環境では、例えば、サーバ１４５ａ、１４５ｂなどは、クライアント１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどがＨＴＴＰのような複数の周知のプロトコルを介して通信する、Ｗｅｂサーバとすることができる。サーバ１４５ａ、１４５ｂなどは、クライアント１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどとしての機能を果たすこともできる。これは、分散コンピューティング環境の特徴ということができる。
【００６９】
通信は、無線でも有線でもよい。クライアントデバイス１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどは、通信ネットワーク／バス１４７を介して、通信してもしなくてもよく、それに関連する独自の通信を有してもよい。例えば、ＴＶまたはＶＣＲの場合、それらの制御は、ネットワーク化されてもされなくてもよい。クライアントコンピュータ１４６ａ、１４６ｂ、１４６ｃ、１４６ｄ、１４６ｅなどのそれぞれは、様々なアプリケーションプログラムモジュールまたはオブジェクト１４８を備えることができ、様々なタイプのストレージ要素またはオブジェクトに対する接続またはアクセスを備えることができる。それらには、ファイルまたはデータストリームを格納することができ、ファイルまたはデータストリームの一部をダウンロードし、転送し、移動させることができる。１つまたは複数のコンピュータ１４５ａ、１４５ｂ、１４６ａ、１４６ｂなどは、データベース１４９、または本発明により処理されたデータを格納するデータベースまたはメモリ１４９のようなその他のストレージ要素の維持および更新に関与する。したがって、本発明は、コンピュータネットワーク／バス１４７を介してアクセスし、相互通信することができるクライアントコンピュータ１４６ａ、１４６ｂなど、並びに、クライアントコンピュータ１４６ａ、１４６ｂなど、およびデータベース１４９と相互通信することができるサーバコンピュータ１４５ａ、１４５ｂなどを有するコンピュータネットワーク環境で利用することができる。
【００７０】
（例示的コンピューティングデバイス）
図５Ｂおよび以下の説明は、本発明を実装することができる適切なホストコンピューティング環境の簡単な概要説明を提供することを目的とする。一方、ハンドヘルド、ポータブルおよびその他のコンピューティングデバイス、ポータブルおよび固定ゲームデバイス、並びに全ての種類のコンピューティングオブジェクトが、本発明に関連する使用を意図されていることが理解されるべきである。汎用コンピュータが以下に説明されるが、これは一例に過ぎず、本発明は、ネットワーク／バス相互運用および相互通信を有するシンクライアントに実装することもできる。したがって、本発明は、とても小さいまたは最小限のクライアントリソースに実装されるネットワーク化ホストサービス（networked hosted service）の環境内に実装することができる。それは例えば、家電製品内に配置されたオブジェクトのような、クライアントデバイスが、単にネットワーク／バスに対するインターフェースとしての役割を果たすに過ぎないネットワーク化環境である。基本的には、本発明による仮想化技術の動作には、データが格納される、若しくは、データが抽出され、他のコンピュータに転送されるところが、望ましいまたは適切な環境である。
【００７１】
必要とされるわけではないが、本発明は、デバイスまたはオブジェクトに対するサービスの開発者が使用するために、オペレーティングシステムを介してその全体または一部が実装され、および／または、本発明の仮想化ＯＳに関連して動作するアプリケーションソフトウェア内に含めることができる。ソフトウェアは、クライアントワークステーション、サーバ、またはその他のデバイスのような１つまたは複数のコンピュータによって実行されるプログラムモジュールのような、コンピュータ実行可能命令の一般的な文脈において説明することができる。一般的に、プログラムモジュールは、特定のタスクを処理し、特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。一般的に、プログラムモジュールの機能は、様々な形態で組み合わせられ、または分散される。さらに、本発明は、その他のコンピュータシステム設定およびプロトコルで実装することもできることが、当業者には理解されるだろう。その他の周知のコンピューティングシステム、環境、および／または、本発明の使用に適切なその他の構成は、限定するわけではないが、パーソナルコンピュータ（ＰＣ）、ＡＴＭ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラム可能電化製品（consumer）、ネットワークＰＣ、家電製品（appliance）、ライト、環境制御要素、ミニコンピュータ、メインフレームコンピュータなどを含む。上述したように、本発明は、通信ネットワーク／バスまたはその他のデータ伝送媒体を介してリンクされるリモートプロセッシングデバイスによってタスクが処理される分散コンピューティング環境に実装することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含むローカルまたはリモートコンピュータストレージ媒体に配置することができ、クライアントノードは、順次サーバノードとして動作する。
【００７２】
図５Ｂは、本発明を実装することができる適切なホストコンピューティングシステム環境１５０の例を示す。ホストコンピューティングシステム環境１５０は適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲を限定するものではない。コンピューティング環境１５０は、例示的動作環境１５０に示されたコンポーネントの１つまたは組み合わせに関して依存するとも、必要とするとも解釈されるべきではない。
【００７３】
図５Ｂを参照すると、本発明を実装する例示的システムは、コンピュータ１６０の形式の汎用コンピューティングデバイスを含む。コンピュータ１６０のコンポーネントは、限定するわけではないが、処理装置１６２、システムメモリ１６４、および、処理装置１６２に対するシステムメモリを含む様々なシステムコンポーネントにつながるシステムバス１６６を含む。システムバス１６６は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および様々なバスアーキテクチャを使用するローカルバスを含む、任意のタイプのバス構造とすることができる。一例として、限定するわけではないが、そのようなアーキテクチャは、ＩＳＡバス、ＭＣＡバス、ＥＩＳＡバス、ＶＥＳＡローカルバス、（メザニンバスとも呼ばれる）ＰＣＩバス、およびＰＣＩｅを含む。
【００７４】
コンピュータ１６０は一般的に、様々なタイプのコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１６０によってアクセス可能とすることができ、揮発性および不揮発性の双方、取外し可能および取外し不可能な媒体を含む。一例として、限定ではないが、コンピュータ読取り可能媒体は、コンピュータストレージ媒体および通信媒体を含む。コンピュータストレージ媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、またはその他のデータなどの情報の記憶のための方法または技術で実装された、揮発性および不揮発性、取外し可能および取外し不可能な媒体を含む。コンピュータストレージ媒体は、限定ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤＲＯＭ、ＤＶＤまたはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気ストレージデバイス、若しくは、コンピュータ１６０によってアクセスすることができ、所望の情報を格納するために使用することができるその他の媒体を含む。通信媒体は一般的に、コンピュータ読取り可能命令、データ構造、プログラムモジュール、若しくは、搬送波またはその他の移送機構などの符号化されたデータ信号内のその他のデータを具現し、任意の情報伝達媒体を含む。用語「被変調データ信号」は、信号内で情報を符号化するような方式で設定され、変更された１つまたは複数の特徴を有する信号を意味する。一例として、限定ではないが、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。上述したものの任意の組み合わせも、コンピュータ読取り可能媒体の範囲内に含まれるべきである。
【００７５】
システムメモリ１６４は、ＲＯＭ１６８およびＲＡＭ１７０などの、揮発性または不揮発性メモリの形式のコンピュータストレージ媒体を含む。起動時などに、コンピュータ１６０内の要素間での情報の転送を助ける基本ルーチンを含むＢＩＯＳ１７２は、一般的に、ＲＯＭ１６８に格納される。ＲＡＭ１７０は一般的に、処理装置１６２によって即座にアクセス可能な、および／または、現在動作しているデータおよび／またはプログラムモジュールを含む。一例として、限定ではないが、図５Ｂは、オペレーティングシステム１７４、アプリケーションプログラム１７６、その他のプログラムモジュール１７８、およびプログラムデータ１８０を示す。
【００７６】
コンピュータ１６０は、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータストレージ媒体も含むことができる。一例として、図５Ｂは、取外し不可能不揮発性磁気媒体に読み書きするハードディスクドライブ１８２、取外し可能不揮発性磁気ディスク１８６に読み書きする磁気ディスクドライブ１８４、および、ＣＤ−ＲＯＭまたはその他の光学媒体などの取外し可能不揮発性光ディスク１９０に読み書きする光ディスクドライブ１８８を示す。例示的動作環境で使用することができるその他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータストレージ媒体は、限定ではないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどを含む。ハードディスクドライブ１８２は一般的に、インターフェース１９２などの取外し不可能メモリインターフェースを介してシステムバス１６６に接続され、磁気ディスクドライブ１８４および光ディスクドライブ１８８は一般的に、インターフェース１９４などの取外し可能メモリインターフェースによってシステムバス１６６に接続される。
【００７７】
上述され、図５Ｂに示されたドライブおよびそれに関連するコンピュータストレージは、コンピュータ１６０に対して、コンピュータ読取り可能命令、データ構造、プログラムモジュール、およびその他のデータのストレージを提供する。図５Ｂにおいて、例えば、ハードディスクドライブ１８２は、オペレーティングシステム１９６、アプリケーションプログラム１９８、その他のプログラムモジュール２００、およびプログラムデータ２０２を格納するように示される。これらのコンポーネントは、オペレーティングシステム１７４、アプリケーションプログラム１７６、その他のプログラムモジュール１７８、およびプログラムデータ１８０と同じでも異なってもよいことに留意されたい。オペレーティングシステム１９６、アプリケーションプログラム１９８、その他のプログラムモジュール２００、およびプログラムデータ２００は、それらが異なるコピーであることが示されるように、異なって与えられている。ユーザは、キーボード２０４、マウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス２０６などの入力デバイスを介して、コンピュータ１６０にコマンドおよび情報を入力することができる。その他の入力デバイス（不図示）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナなどが含まれる。これらおよびその他の入力デバイスはしばしば、システムバス１６６に接続されるユーザ入力インターフェース２０８を介して、処理装置１６２に接続されるが、パラレルポート、ゲームポート、またはＵＳＢなどのその他のインターフェースおよびバス構造によって接続することもできる。これらは、本発明のアーキテクチャによって仮想化される種類の構造である。ノースブリッジによって実装されるインターフェースなどのグラフィックインターフェース２１０も、システムバス１６６に接続することができる。ノースブリッジは、ＣＰＵまたはホスト処理装置１６２と通信するチップセットであり、ＰＣＩ、ＰＣＩｅ、およびＡＧＰ通信などの通信に関与するとみなされる。１つまたは複数のグラフィック処理装置（ＧＰＵ）２１２は、グラフィックインターフェース２１０と通信することができる。この点において、ＧＰＵ２１２は一般的に、ビデオメモリ２１４と通信するレジスタストレージおよびＧＰＵ２１２などのオンチップメモリストレージを含む。一方、ＧＰＵ２１２はコプロセッサの一例であり、したがって、様々なコプロセスデバイスをコンピュータ１６０に含めることができ、ピクセルおよびバーテックスシェイダ（pixel and vertex shader）などの様々な手続シェイダ（procedural shader）を含むことができる。モニタ２１６またはその他のタイプのディスプレイデバイスも、ビデオメモリ２１４と順次通信することができるビデオインターフェース２１８などのインターフェースを介して、システムバス１６６に接続される。モニタ２１６に加えて、コンピュータは、出力周辺インターフェース２２４を介して接続することができる、スピーカ２２０およびプリンタ２２２などのその他の出力周辺デバイスも含むことができる。
【００７８】
コンピュータ１６０は、リモートコンピュータ２２６などの、１つまたは複数のリモートコンピュータに対する論理接続を使用して、ネットワーク化または分散環境内で動作することができる。リモートコンピュータ２２６は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードとすることができ、図５Ｂにはメモリストレージデバイス２２８しか示されていないが、一般的には、コンピュータ１６０に関連して上述された多くのまたは全ての要素を含むことができる。図５Ｂに示された論理接続は、ＬＡＮ２３０およびＷＡＮ２３２を含むが、その他のネットワーク／バスを含むこともできる。このようなネットワーク環境は、住宅、オフィス、企業規模のネットワーク、イントラネット、およびインターネットでは一般的である。
【００７９】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１６０は、ネットワークインターフェースまたはアダプタ２３４を介してＬＡＮ２３０に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１６０は一般的に、モデム２３６またはインターネットなどのＷＡＮ２３２を介して通信を確立するその他の手段を含む。外部または内部にあるモデム２３６は、ユーザ入力インターフェース２０８またはその他の適切な機構を介して、システムバス１６６に接続することができる。ネットワーク化環境では、コンピュータ１６０またはその部分に関連して示されるプログラムモジュールは、リモートメモリストレージデバイスに格納することができる。一例として、限定ではないが、図５Ｂは、メモリデバイス２２８上にあるようにリモートアプリケーションプログラム２３８を示している。示されたネットワーク接続は例であり、コンピュータ間で通信リンクを確立するその他の手段を使用することができることも理解されるだろう。
【００８０】
本発明を実装する複数の方法があり、それらは、アプリケーションおよびサービスが、本発明の仮想化アーキテクチャ、システム、および方法使用することを可能にする適切なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、制御、スタンドアロンまたはダウロード可能オブジェクトなどである。本発明は、ＡＰＩ（またはその他のソフトウェアオブジェクト）の観点から、並びに、本発明による上述した技術を受け取るソフトウェアまたはハードウェアから、本発明の使用を考えることができる。したがって、本明細書で説明される本発明の様々な実装は、ハードウェア全体、ハードウェアの部分とソフトウェアの部分、ならびにソフトウェアであるという側面を有する。
【００８１】
上述したように、本発明の例示的実施形態を、様々なコンピューティングデバイスおよびネットワークアーキテクチャに関連して説明したが、基礎をなすコンセプトは、ゲストソフトウェアをエミュレートすることが望まれる任意のコンピューティングデバイスまたはシステムに適用することができる。例えば、本発明の様々なアルゴリズムおよびハードウェア実装は、デバイス上の別々のオブジェクトとして、その他のオブジェクトの部分として、再利用可能な制御として、サーバからダウンロード可能なオブジェクトとして、ハードウェアとして、メモリ内では、上述したものの組み合わせとして提供される、コンピューティングデバイスのオペレーティングシステムに適用することができる。オブジェクトコードを提供する方法、および、本発明の様々な実施形態によって達成される同一、類似、または同等の機能を達成する方法が多数あることが、当業者には理解されるだろう。
【００８２】
上述したように、本明細書で説明された様々な技術は、ハードウェアまたはソフトウェエア、若しくはそれらの組み合わせに関連して実装することができる。したがって、本発明の方法および装置、ある側面またはその部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ，ハードドライブ、またはその他の機械読取り可能ストレージ媒体などの有形媒体に具現されるプログラムコード（例えば、命令）の形態をとることができる。プログラムコードは、コンピュータなどのマシンにロードされ、マシンによって実行され、マシンは本発明を実施する装置となる。プログラム可能なコンピュータ上でのプログラムコード実行の場合、コンピューティングデバイスは一般的に、プロセッサ、（揮発性および不揮発性メモリおよび／またはストレージ要素を含む）プロセッサによって読取り可能なストレージ媒体、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。例えば、データプロセシングＡＰＩ、再利用可能な制御などを介して、本発明の仮想化技術を実装し、利用することができる１つまたは複数のプログラムは、好ましくは、高レベル手続き型またはオブジェクト指向型プログラミング言語で実装され、コンピュータシステムと通信する。しかしながら、プログラムは、望むのであればアセンブリまたは機械言語で実装することもできる。いずれにしても、言語は、コンパイルされ、または解釈された言語となり、ハードウェア実装に組み込まれる。
【００８３】
本発明の方法および装置は、転送媒体を介して転送されるプログラムコードの形態に具現される通信を介して実施されることもできる。通信媒体は、例えば、電気配線またはケーブル、光ファイバ、転送のその他の形態である。プログラムコードは、ＥＰＲＯＭ、ゲートアレイ、プログラム可能な論理デバイス（ＰＬＤ）、クライアントコンピュータなどのマシンにロードされ、マシンによって実行され、そのマシンは、本発明を実施する装置となる。汎用プロセッサ上で実装される場合、プログラムコードは、プロセッサと組み合わせて、本発明の機能を呼び出すように動作する独自の装置を提供する。また、本発明に関連して使用される任意のストレージ技術は常に、ハードウェアとソフトウェアの組み合わせである。
【００８４】
望ましい実施形態に関連して本発明を説明したが、本発明の趣旨を逸脱せずに、その他の類似の実施形態を使用することができ、修正および追加が、説明された実施形態になされることができることが理解されるべきである。例えば、本発明の例示的ネットワーク環境が、ピアツーピアネットワーク化環境などのネットワーク化環境の文脈において説明されたが、本発明はそれらに限定されず、本出願で説明されたような方法は、ゲームコンソール、ハンドヘルドコンピュータ、ポータブルコンピュータなどのコンピューティングデバイスまたは環境に適用することができ、通信ネットワークを介して接続され、ネットワークを介して相互通信する、複数のコンピューティングデバイスに適用することができることが、当業者には理解されるだろう。さらに、ハンドヘルドデバイスオペレーティングシステムおよびその他のアプリケーションに特化したオペレーティングシステムを含む様々なコンピュータプラットフォームを考慮することができ、特に複数の無線ネットワークデバイスが増え続けていることは強調されるべきである。
【００８５】
例示的実施形態が、ホストＯＳ上で仮想化されたゲストＯＳの文脈において本発明を利用することに言及したが、本発明はそれに限定されず、メインプロセッサと共に動作する第２のプロセッサを仮想化するように実装することもできる。さらに、本発明は、ＯＳの同一のバージョンまたはリリースの複数のインスタンスが、本発明による別個の仮想マシンにおいて動作しているシナリオを考慮する。本発明の仮想化は、ゲストＯＳを使用するための動作とは独立していることが理解できるだろう。本発明は、Ｗｉｎｄｏｗｓ（登録商標）またはＸボックスアーキテクチャだけでなく、全てのコンピュータアーキテクチャに適用することも意図されている。さらに、本発明は、複数のプロセシングチップまたはデバイス内に、またはそれらにわたって実装することができ、ストレージは同様に、複数のデバイスにわたって有効である。したがって、本発明は、いかなる単一の実施形態にも限定されるべきではなく、添付の特許請求の範囲による広さおよび範囲で解釈されるべきである。
【図面の簡単な説明】
【００８６】
【図１Ａ】コンピュータシステム内のエミュレートされた動作環境についての、ハードウェアおよびソフトウェアアーキテクチャの論理階層化を示すブロック図である。
【図１Ｂ】エミュレーションが、（直接的にまたはハイパーバイザを介して）ホストオペレーティングシステムによって実施される仮想化コンピューティングシステムを示すブロック図である。
【図１Ｃ】エミュレーションが、ホストオペレーティングシステムと隣り合って実行されている仮想マシンモニタによって実施される、別の仮想化されたコンピューティングシステムを示すブロック図である。
【図２】仮想マシン内に実装されたレガシーゲームシステムの仮想メモリと、ホストゲームシステムの仮想メモリとの間の関係を示す図である。
【図３】本発明の技術を使用して、仮想マシン内に実装されたレガシーゲームシステムのｘ８６コードを、ホストゲームシステムのＰＰＣコードに変換するシステムを示す図である。
【図４】本発明のＪＩＴバイナリトランスレータの動作を示す流れ図である。
【図５Ａ】本発明を実装することができる様々なコンピューティングデバイスを有する例示的なネットワーク化環境を示すブロック図である。
【図５Ｂ】本発明を実装することができる例示的な限定しないホストコンピューティングデバイスを示すブロック図である。
【図１Ａ】
2008545179.tif 000003
【図１Ｂ】
2008545179.tif 000004
【図１Ｃ】
2008545179.tif 000005
【図２】
2008545179.tif 000006
【図３】
2008545179.tif 000007
【図４】
2008545179.tif 000008
【図５Ａ】
2008545179.tif 000009
【図５Ｂ】
2008545179.tif 000010