JP3776132B2 - Microprocessor improvements - Google Patents

Description

表記：[...]は、メモリ・オペランドに対するアドレス表現を示す。先の例では、メモリ・オペランドに対するアドレスは、レジスタの内容を、Ｏｘプレフィクスが示す１６進定数に加算することによって形成される。ターゲット・レジスタは、%プレフィクスで示される。例えば、%ecxは、excレジスタを示す。動作の宛先は左側である。

このサンプルの第１部分では、Ｃ言語の命令文によって定義される動作の実行を行うための個々のＸ８６アセンブリ言語の命令は各々、当該動作に対するアセンブリ言語のニモニックによって表に纏められており、特定の原始動作に含まれるパラメータがこれに続く。動作の説明も、各命令毎のコメントにおいて与えることにする。実行の順序は、ターゲット・プロセッサでは、図示のものとは異なる場合もあるが、これらのアセンブリ言語命令の各々は、ターゲットＣ言語命令を実行する際に、ループを実行する毎に実行しなければならない。したがって、ループを１００回行われる場合、以上に示した各命令は１００回実行されなければならない。

次のサンプルは、Ｃ言語命令を実行する、同じターゲット原始命令を示す。しかしながら、各原始ターゲット命令の次に、本発明のマイクロプロセッサの一特定実施形態において同じ動作を行うために必要な原始ホスト命令を纏めてある。このマイクロプロセッサでは、モーフ・ホストはここに記載したように設計されたＶＬＩＷプロセッサである。オフィシャル・ターゲット・レジスタによってシャドウされたホスト・レジスタは、「Ｒ」で示し、その後ろにＸ８６レジスタ名称が続くので、例えば、Ｒｅａｘは、ＥＡＸオフィシャル・ターゲット・レジスタと連動するワーキング・レジスタであることを注記しておく。

次のサンプルは、原始ターゲット命令の各々について、ホスト原始命令の追加を示し、これによって、ターゲット動作に必要なアドレスを、コード・モーフィング・ソフトウエアによって発生することができるものである。ホスト・アドレス発生命令は、アドレス発生ハードウエアの代わりに、コード・モーフィング・ソフトウエアをアドレス発生に用いるマイクロプロセッサの実施形態においてのみ必要となることを注記しておく。Ｘ８６マイクロプロセッサのようなターゲット・プロセッサでは、アドレス発生ハードウエアを用いてこれらのアドレスを発生する。このような本発明の実施例においてアドレスが発生したときはいつでも、計算が行われ、また、ホスト原始命令が追加され、アドレス値をチェックすることによって、算出されたアドレスが適切なＸ８６セグメントの限度内にあることを判定する。

このサンプルは、原始ホスト命令の各組に２ステップを追加することによって、ゲート格納バッファ内のアンコミット値をメモリにコミットするために必要なホスト命令の実行後に、各原始ターゲット命令を実行し、オフィシャル・ターゲット・レジスタを更新することを例示する。サンプルに見られるように、各場合において、ターゲット命令の長さを、ワーキング命令ポインタ・レジスタ（Ｒｅｉｐ）内の値に加算する。次に、コミット命令を実行する。一実施形態では、コミット命令は、連動するオフィシャル・ターゲット・レジスタにシャドウされている各ワーキング・レジスタの現在値をコピーし、ゲート格納バッファのゲートの位置を指定するポインタ値を、アンコミットの格納の直前から、それらの格納の直後に移動させ、それらをメモリ内に置くようにする。
上記の最後に示した命令のリストは、元のターゲット・アセンブリ言語命令のホスト変換を形成するために必要な命令の全てであることは認められよう。変換がこの時点で停止した場合、原始ホスト命令の数は、ターゲット命令の数よりもはるかに多くなり（恐らく、６倍多い命令）、その実行は、ターゲット・プロセッサ上での実行よりも長くかかる可能性がある。しかしながら、この時点では、並び替えや、最適化や、再スケジューリングは未だ行われていない。
命令を１度だけ走らせる場合、更に並び替えやその他の最適化も行うために要する時間は、この時点で存在する変換を実行するための時間よりも長くなるということになり得る。その場合、本発明の一実施形態では、この時点で変換を中止し、変換を格納し、次いでそれを実行して例外またはエラーが発生するか否かについて判定を行う。この実施形態では、並び替えおよびその他の最適化のステップが行われるのは、特定の変換をある回数走らせることまたは最適化すべきことを決定した場合のみである。これは、例えば、ホスト命令を各変換に置き、変換を実行した回数を数え、ある値に達したときに例外（または分岐）を発生することによって行われる。例外（または分岐）は、動作をコード・モーフィング・ソフトウエアに転送し、次いでコード・モーフィング・ソフトウエアは、以下の最適化の一部または全部、および当該変換に有用と判定されたあらゆる追加の最適化を実現する。変換を走らせた回数を判定し、最適化を要求する第２の方法は、ある頻度でまたはある統計的基準に基づいて、変換の実行を中断し、その時点で走っているいずれの変換も最適化することである。これは、究極的に、最も頻繁に走らせる命令を最適化しようとするものである。別の解決策として、ループを形成するものや、その他に最も頻繁に走らせる可能性があるもののような、ある特定の形式のホスト命令の各々を最適化することも挙げられよう。

このサンプルは、本発明を利用して実施可能な最適化の第１段を例示する。この最適化段は、コード・モーフィング・ソフトウエアの他の動作の多くと同様、最適な結果を想定する。特定の最適化は、Ｘ８６プロセッサ・ファミリによって与えられるフラット・メモリ・モデルに対して書かれた３２ビット・プログラムとして開始したターゲット・アプリケーション・プログラムが、そのようなプログラムとして継続することを想定する。このような想定は、Ｘ８６ファミリに特定なものであり、エミュレート対象の他のプロセッサ・ファミリでは必ずしも適用される訳ではないことを注記しておく。
この想定を行った場合、Ｘ８６用アプリケーションでは、全てのセグメントが同一アドレス空間にマップされる。これによって、Ｘ８６セグメンテーション・プロセスが要求する原始ホスト命令を除去することが可能となる。サンプルに見られるように、最初にセグメント値をゼロにセットする。次に、データのベースをゼロにセットし、限度を最大使用可能メモリにセットする。すると、ターゲット原始命令を実行するための各組の原始ホスト命令において、セグメンテーションに必要なセグメント・ベース値のチェック、およびセグメント・ベース・アドレスの計算双方が不要となる。これによって、アドレシング機能を必要とする各ターゲット原始命令に対して、２つのホスト原始命令が実行すべきループを減少する。この時点では、メモリ上限に対するホスト命令チェックは未だ存在する。
この最適化には、アプリケーションが３２ビット・フラット・メモリ・モデルを利用することを記した推測を必要とすることを注記すべきであろう。これが真ではない場合、主ループが制御転送の宛先を解明し、転送元の想定が宛先の想定と一致しないことを検出する際に、エラーが発見される。すると、新たな変換が必要となる。この技法は非常に一般的であり、種々のセグメンテーションおよびその他の「モード化」の場合において、デバッグ、システム管理モード、または「リアル」モードのように、「モード」が頻繁に変化する場合に適用可能である。

このサンプルは、最適化の次の段階を例示する。この場合、推測的な変換(speculative translation)によって、メモリ・アドレス空間の上端においてメモリ参照と交差する整合されていないページに対してのみ必要な、上側のメモリ境界チェックを不要にする。この想定の失敗は、ハードウエアまたはソフトウエアの整合解決(fix up)によって検出される。これによって、アドレシングを必要とする各ターゲット原始命令毎に、ホスト原始命令１つだけ変換が減少する。この最適化は、アプリケーションが３２ビット・フラット・メモリ・モデルを利用するという先に記した想定、および命令が整合されているという推測の双方を必要とする。これらが真でない場合、変換を実行した際に失敗に終わり、新たな変換が必要となる。

このサンプルは、次の最適化を例示する。この場合、共通のホスト表現を除去する。即ち、２番目のターゲット原始命令を変換する際、ワーキング・レジスタＲｅｂｐ（Ｘ８６プロセッサのスタック・ペース・ポイント・レジスタを表すワーキング・レジスタ）内の値を、オフセット値0x8に加算し、ホスト・ワーキング・レジスタＲ２に置く。直前のサンプルにおいてターゲット原始命令５を変換する際に同じ動作を行ったが、加算の結果はワーキング・レジスタＲ５に置かれたことを注記しておく。その結果、ワーキング・レジスタＲ５に置かれる値は、ホスト原始命令５が生じようとするときには、既にワーキング・レジスタＲ２に存在する。したがって、ホストの加算命令を、ターゲット原始命令５の変換から除去することができ、ワーキング・レジスタＲ２内の値をワーキング・レジスタＲ５にコピーすればよい。同様に、ワーキング・レジスタＲｅｂｐ内の値をオフセット値0x10と加算するホスト命令も、ターゲット原始命令８の変換では除去することができる。何故なら、このステップは既にターゲット原始命令６の変換において行われており、結果はレジスタＲ７にあるからである。この最適化は思索に依存せず、そのため失敗や再変換がないことを注記しておく。

この例は、変換全体を構成する原始ターゲット命令の変換が、例外を発生することなく行うことができると推測する最適化を例示する。これが真であれば、オフィシャル・ターゲット・レジスタを更新したり、個々のターゲット原始命令を実行するホスト原始命令の各シーケンス毎に、その終了時に格納バッファにおけるアンコミットの格納をコミットする必要がなくなる。推測が真であれば、ターゲット原始命令のシーケンスの終了時に、オフィシャル・ターゲット・レジスタだけを更新すればよく、格納をコミットするのは一度だけでよい。これによって、各原始ターゲット命令を実行するための原始ホスト命令を２つ除去することが可能となる。これらは、オフィシャル・ターゲット・レジスタをアンコミットの格納をメモリにコミットする単一のホスト原始命令と置換する。
これは、別の推測的動作であり、これも正しい推測を含む可能性が非常に高いことは理解されよう。このステップは、推測が真であれば、従来技術のエミュレーション技術全てに対して、非常に大きな利点を提供することになる。これは、ターゲット原始命令のシーケンス全体を実行する原始ホスト命令の全てを、１つのシーケンスに集合化し、その中で個々のホスト原始命令の全てを一緒に最適化することができる。これには、超長命令ワード技術を利用したモーフ・ホスト上で多数の動作を並列に走らせることができるという利点がある。また、これによって、より多数のその他の最適化も可能となる。何故なら、このような最適化に対する選択肢が広がるからである。更にまた、しかしながら、推測が真でないことが判明し、ループの実行時に例外が発生した場合、オフィシャル・ターゲット・レジスタおよびメモリは、ターゲット原始命令のシーケンスの開始時に存在したオフィシャル・ターゲットの状態を保持している。何故なら、ホスト命令のシーケンスが実際に実行されるまで、コミットは生じないからである。例外から復元するために必要な全ては、アンコミットの格納を消去し、オフィシャル・レジスタをワーキング・レジスタにロールバックし、シーケンスの開始時にターゲット原始命令の変換を再度開始することである。この再変換は、１度に１ターゲット命令ずつの変換を行い、各ターゲット原始命令を表すホスト・シーケンスを変換した後に、オフィシャル状態を更新する。次に、この変換を実行する。この再変換において例外が発生した場合、この例外を実行するために、オフィシャル・ターゲット・レジスタおよびメモリにおいて、正しいターゲット状態を直ちに得ることができる。

この要約は、最適化プロセスのこの時点において残っているホスト原始命令のシーケンスを例示する。この例は、ターゲット命令ポインタ（ＥＩＰ）インラインの維持を示すが、変換時に分岐のためのポインタＥＩＰをライン外に維持することが可能である。この場合、ポインタＥＩＰ更新シーケンスをこのステップおよび本例の後続のステップから除去することができる。

このサンプルは、通常レジスタ名称変更と呼ばれる、最適化の次のステップを示す。ここでは、ホスト原始命令のシーケンスにおいて１回以上の動作に用いられるワーキング・レジスタを必要とする動作は、異なる不使用のワーキング・レジスタを利用するように変更され、２つのホスト命令が同じハードウエアを必要とするという可能性をなくす。したがって、例えば、先の２つのサンプルにおいて、２番目のホスト原始命令は、オフィシャル・ターゲット・レジスタＥＣＸを表すワーキング・レジスタＲｅｃｘを使用する。１０番目のホスト原始命令も、ワーキング・レジスタＲｅｃｘを使用する。２番目のホスト原始命令における動作を変更し、Ｒ０内のアドレスによって示される値を、レジスタＲｅｃｘではなく、ワーキング・レジスタＲ１に格納することにより、先の２つのホスト命令が双方とも同じレジスタを使用する事態は避けられる。同様に、４番目、５番目、および６番目の原始命令も、先のサンプルでは、全てワーキング・レジスタＲｅａｘを利用する。４番目のホスト原始命令を変更し、ワーキング・レジスタＲｅａｘの代わりに、それまで不使用のワーキング・レジスタＲ３を利用するようにし、更に６番目のホスト原始命令を変更して、レジスタＲｅａｘの代わりに、それまで不使用のワーキング・レジスタＲ４を利用することによって、これらのハードウエア依存性がなくなる。

このサンプルは、モーフ・ホスト上で実行するためのホスト原始命令のスケジューリングを示す。この例では、モーフ・ホストをＶＬＩＷプロセッサと仮定し、コード・モーフィング・ソフトウエアと協同するために備えられたハードウエア機能強化に加えて、処理ユニットの中でもとりわけ、２つの算術および論理（ＡＬＵ）ユニットが含まれている。最初の行は、モーフ・ホスト上で一緒に走るようにスケジュールされた２つの個別の加算命令を示す。サンプルに見られるように、これらは、先の要約の直前のサンプルにおける３番目および８番目の原始ホスト命令である。２番目の行は、ＮＯＰ（無動作であるが、次の命令に進む）命令および別の加算命令を含む。ＮＯＰ命令は、何らかのスケジューリング最適化を行った後でも、一緒に走らせることができる命令が常に２つあるとは限らないことを示す。いずれにしても、このサンプルは、この時点では９組の原始ホスト命令のみが、元の１０個のターゲット命令を実行するために残されていることを示す。

このサンプルは、本質的に、ホスト原始命令の同じ組を例示するが、命令はこの時点では、変換バッファに格納され、１回以上実行されている点で異なる。何故なら、最後のジャンプ（ｊｐ）命令が、ここでは、変換された命令の別のシーケンスに連鎖することによって与えられたジャンプ・アドレスを示すからである。連鎖プロセスは、シーケンスの変換が完了していれば、変換部のメイン・ループから命令のシーケンスを取り出す。

この例は、大抵は多数回繰り返されるシーケンスでのみ利用される進んだ最適化ステップを例示する。このプロセスは、最初に、ループを形成する変換を検出し、個々の原始ホスト命令を調べて、ループ本体内で一定の結果を生成する命令を判定する。これらの命令をループ本体から除去し、１回だけ実行して、レジスタ内に値を置く。その時点以降、このレジスタに格納した値を用い、命令を再度走らせることはしない。

これら繰り返しのない命令をループから除去し、シーケンスを実行のためにスケジューリングすると、スケジューリングされた命令は、この最後のサンプルのようになる。最初の命令は実行されるが、ループの最初の繰り返しの間に１度だけであり、その後は、図示の７つのクロック・インタバルに残っているホスト原始命令のみが、ループの間に実行されることがわかる。したがって、実行時間は、原始ターゲット命令を実行するために必要な１０命令から、７命令インタバルに短縮した。
サンプルからわかるように、ループから除去したステップは、アドレス発生ステップである。したがって、アドレス発生は、本発明では、ループ呼び出し毎に１回だけ行えばよい。即ち、アドレス発生は１回だけ行えばよい。一方、Ｘ８６ターゲット・プロセッサのアドレス発生ハードウエアは、これらのアドレスを、ループを実行する毎に発生しなければならない。ループを１００回実行する場合、本発明は１回だけアドレスを発生するのに対して、ターゲット・プロセッサは、各アドレスを１００回発生することになる。

これは、変数を安全にメモリからレジスタに移動させることができる。モーフ・ホストのレジスタ・エイリアス検出ハードウエアの使用を示す。開始点は、「逆方向コード移動」の後のコードである。これは、ロードを除去することができる最適化を示す。
最初にロードを実行する。エイリアス・ハードウエアによってアドレスは保護されており、このアドレスに対する格納が行われると、「エイリアス」例外が発生する。次に、ループ本体内のロードをコピーと置換する。ループの本体の後、エイリアス・ハードウエアを解放する。

このサンプルは、更に進んだ最適化を例示し、本発明のマイクロプロセッサによって実施することができる。このサンプルより２つ前のサンプルを再度参照すると、最初の３つの加算命令が、スタック上のアドレスの計算を伴っていたことに気が付くであろう。これらのアドレスは、ホスト動作のシーケンスの実行中変化しない。つまり、これらのアドレスに格納されている値は、メモリから検索し、実行のために直ちに得ることができるレジスタにロードしておけばよい。サンプルに見られるように、これはホスト原始命令６，８，および１０において行われる。命令７，９および１１では、メモリ・アドレスの各々に、特殊なホスト・エイリアス・ハードウエアによって保護されているという印が付けられており、レジスタは、これらのメモリ・アドレスのエイリアスとして示されているので、そのデータを変更しようとするいずれの試みも、例外の原因となる。この点において、これらのスタック・メモリ・アドレスからのデータ移動を伴うロード動作の各々は、単純なレジスタ間コピー動作となり、これは、メモリ・アドレスからのロードよりも格段に速く進展する。ｎ＝０まで一旦ループを実行し終えたなら、エイリアス・レジスタを他のために利用できるように、メモリ・アドレスの各々から保護を除去しなければならないことを注記しておく。

このサンプルは、最適化の次の段階を示す。ここでは、最後のサンプルで示した最適化においてロード命令を置換したコピー命令の殆どが不要であり、除外してもよいことを認識する。即ち、レジスタ間コピー動作が行われると、データをコピーした元のレジスタ内に、その動作前のデータが存在する。この場合、データは、それがコピーされたレジスタではなく、最初のレジスタにアクセスすることができ、コピー動作を除去することができる。これからわかるように、最後のサンプルのループ内に示す、先頭、２番目、５番目および９番目の原始ホスト命令が除去される。加えて、ホスト原始命令の他のものに用いられているレジスタも変更され、当該データに対する正しいレジスタを反映する。したがって、例えば、最初と２番目のコピー命令を除去した場合、３番目の格納命令は、データが存在するワーキング・レジスタＲｃ（レジスタＲ１ではなく）からデータをコピーし、ワーキング・レジスタＲｓ（レジスタＲ３ではなく）内に示されるアドレスにそのデータを置かなければならない。ワーキング・レジスタＲｓには、そのアドレスが存在する。

上のサンプルにスケジューリング後のホスト命令を示す。このシーケンスは、ソース・コードから当初デコードされた原始ターゲット命令を実行するよりも、ループを実行するのに必要なクロックが少なくて済むことを注記しておく。したがって、行われた他の加速化の全てとは別に、結合された動作を走らせる総回数は、元のターゲット・コードを実行するために必要な動作よりも、単純に少なくなる。

このサンプルに示す最終的な最適化は、エイリアス・ハードウエアの使用による格納の除去である。これは、ループ本体内から格納を除去し、それらをループの結びにおいてのみ実行する。これによって、ループ本体内のホスト命令数が、元の１０個のターゲット命令と比較して、３つに減少する。
以上、好適な実施形態に関して本発明の説明を行ったが、本発明の精神および範囲から逸脱することなく、当業者には種々の変更や変形も可能であることは認められよう。例えば、本発明は、Ｘ８６プロセッサのエミュレーションに関して説明したが、本発明は、同様に、他のプロセッサ・アーキテクチャに設計されたプログラム、およびＰコード、Postscript、またはＪａｖａプログラムのような仮想マシン上で実行するプログラムにも適用されることは理解されよう。したがって、本発明は、以下の請求範囲に沿って解釈すべきものとする。Background of the Invention
Field of Invention
The present invention relates to computer systems, and more particularly to methods and apparatus for improving microprocessors.
History of conventional technology
There are thousands of application programs running on computers designed around a particular microprocessor family. Existing programs include the development of the “X86” family of microprocessors (Intel 8088, Intel 8086, Intel 80186, Intel 80286, i386, i486, and various Pentium microprocessors, designed and manufactured by Intel Corporation of Santa Clara, California. Including molds: Intel and Pentium are registered trademarks, the most being designed to run on computers (commonly referred to as IBM compatible personal computers). There are many examples of other programs designed to run on computers using other processor families. Because there are many application programs that run on these computers, the market for microprocessors that can be used in such computers, particularly programs designed to process X86 programs, is enormous. Not only is the microprocessor market large, it is very profitable.
Although the market for microprocessors capable of running many application programs is large and profitable, it is very difficult to design new competitive microprocessors. For example, the X86 processor family has existed for many years and these processors are included in most of the computers sold and used, but few successful processors can run X86 programs. There are many reasons for this.
To succeed, all the programs designed for this processor family (including the operating system and legacy programs) must be microprocessors that can run as fast as existing processors, Furthermore, the cost must be kept lower than existing processors. In addition, in order to be economically successful, a new microprocessor must be replaced with an existing recognized processor by surpassing an existing processor in at least one of these conditions. The purchaser must be given a reason for choosing a processor.
Running a microprocessor as fast as a modern microprocessor is difficult and expensive. The processor executes instructions with primitive operations such as load, shift, add, store, and similar low-level operations, and when executing any instruction provided by an application program, Responds only to commands. For example, a processor designed to run a complex instruction set computer (CISC) instruction, such as X86, that can specify a process whose instructions are to be executed at a relatively high level. Conventionally, a read-only memory (ROM) is included, and so-called microinstructions are stored therein. Each microinstruction contains a series of primitive instructions, and running them in sequence yields the results commanded by the high level CISC instructions. Typically, when the CISC instruction “add A to B” (adding A to B) is decoded, the microinstructions that perform the function of this “add A to B” instruction are stored in the ROM. Refer to the address. This microinstruction is loaded and the "add A to B" instruction is executed by running the primitive instructions sequentially. In such a CISC computer, the primitive operations within the microinstructions can never be changed during program execution. Each CISC instruction can only be run by decoding the instruction, addressing and fetching the microinstruction, and running a series of primitive operations in the order given within the microinstruction. Each time a microinstruction is run, the same sequence must occur.
Advanced processors for running X86 applications utilize a number of technologies and are trying to process as fast and economically as possible. Any new processor that implements known hardware techniques to accelerate the speed at which the processor can run must increase the sophistication of the processing hardware. This requires increased hardware costs.
For example, a superscalar microprocessor that uses multiple processing channels to perform more than one operation at a time has a number of additional requirements. At the most basic level, a simple superscalar microprocessor can decode each application instruction into microinstructions and perform the functions of that application instruction. Thus, a simple superscalar microprocessor requires that two microinstructions do not require the same hardware resources and if the execution of one microinstruction does not depend on the processing result of the other microinstruction, Schedule the instructions to run together.
Advanced superscalar microprocessors typically can decode each application instruction into a series of primitive instructions, change the order of these primitive instructions, and schedule them in the most efficient execution order There is something to do. This requires addressing and capturing each individual primitive action. To perform the reordering, the processor must be able to guarantee that a primitive instruction that requires data originating from another primitive instruction is executed after the other primitive instruction has generated the necessary data. Such a superscalar microprocessor must ensure that two primitive instructions that run together do not require the same hardware resources. Such a processor must also be able to resolve a conditional branch and then complete the effect of the branch operation.
Thus, a superscalar microprocessor requires extensive hardware to compare the relationships of multiple primitive instructions with each other, rearrange the sequence of these primitive instructions, and schedule and execute every instruction. . As the number of processing channels increases, the amount and cost of hardware to achieve these superscalar acceleration techniques increases almost fourfold. All of these hardware requirements lead to associated circuit complexity and cost. As with microinstructions, each time an application instruction is executed, a superscalar microprocessor captures each of these primitive instructions using its relatively complex addressing hardware and capture hardware. They must be reordered and rescheduled based on other primitive instructions and hardware usage, and all the rescheduled primitive instructions must be executed. Since each application instruction must be run through the entire hardware sequence, the speed at which the superscalar processor can execute the instruction is limited.
Furthermore, even though these various hardware technologies increase processing speed, the complexity associated with providing such hardware will result in a significant increase in the cost of such a microprocessor. For example, the Intel i486DX4 processor uses about 1.5 million transistors. In a basic superscalar microprocessor such as Intel Pentium, 3 million to add the necessary hardware to perform the dependency and scheduling checks needed to process instructions by two channels The use of the above transistors is necessary. Sorting between primitive instructions derived from different target instructions, performing speculative execution, enabling register renaming, adding hardware to perform branch prediction, the number of transistors is Intel With Pentium Pro (registered trademark), the number increases to 6 million or more. Therefore, it can be seen that the number of transistors in the latest microprocessor has increased dramatically each time hardware is added to increase the operation speed.
Even using these known techniques, it may not be possible to produce a microprocessor that is faster than existing microprocessors. This is because the manufacturer uses a known technology that accelerates the operation of existing microprocessors, which is economically feasible. As a result, designing a faster processor is a very difficult and expensive task.
Processor cost reduction is also very difficult. As illustrated above, hardware acceleration techniques that produce fully capable processors are very expensive. Anyone trying to design a new processor must have the equipment to produce the hardware. Obtaining such equipment is very difficult. This is because chip manufacturers typically do not spend their assets on a small amount of devices. The capital investment required to produce chip manufacturing equipment is very large and beyond what most companies can do.
Even if someone can design a new processor that will run all of the application programs designed for a processor family at least as fast as the competing processor, the price of the competing processor will include sufficient benefits. It is certain that both competitors will face significant price cuts.
Although it is very difficult to design a competitive processor by increasing the complexity of hardware, application programs (target application programs) designed for a specific microprocessor family (target microprocessor) Another way to run the program) has been to emulate the target microprocessor in software on another faster microprocessor (host microprocessor). This is a method of running these programs at each stage at low cost. This is because it is only necessary to add some form of emulation software that runs application programs on faster microprocessors. The emulation software changes the target instruction of the application program written in the target processor family to a host instruction that can be executed by the host processor. These modified instructions are run under the control of the operating system on a faster host microprocessor.
There are a wide variety of designs that allow a target application to run on a host computer that has a faster processor than the target computer's processor. In general, a host computer that executes a target program using emulation software utilizes a reduced instruction set (RISC) microprocessor. This is because RISC processors are theoretically simpler than other types of processors and as a result can run faster.
However, RISC computer systems that run emulator software can often run X86 (or other) programs, but the rate at which they do this is usually the state of the art X86 computer system. Is much slower than the rate at which the same program runs. Furthermore, these emulator programs cannot run all or the majority of the available target programs.
The reason why the emulator program cannot run the target program as fast as the target microprocessor is very complex and requires some understanding of different emulation operations. FIG. 1 includes a series of diagrams representing different ways in which a plurality of different types of microprocessors execute a target application program.
FIG. 1 (a) shows the case where a typical CISC microprocessor, such as the Intel X86 microprocessor, runs a target application program designed to run on the target processor. As seen in the figure, the CISC operating system (MS DOS ™, Windows 3.1 ™, used with X86 computers) designed to provide an interface for gaining access to computer hardware. Applications such as WindowsNT ™ and OS / 2 ™ are used to run the application on the CISC processor. Typically, application program instructions are selected to utilize a computer device only through access provided by the operating system. Thus, the operating system handles operations that allow applications to access the computer's memory and various input / output devices. The target computer includes memory and hardware that is recognized by the operating system, and by a call from the target application to the operating system, the operating system device driver uses the defined target computer device. Let the expected behavior occur. Application instructions execute on the processor, but in this case they are changed to operations that the processor can perform (microcode or microcode is assembled and materialized with primitive operations). As described above, each time a complex target instruction is executed, the instruction calls the same subroutine stored as microcode (or as the same primitive action set). The same subroutine is always executed. If the processor is a superscalar, these primitive operations to execute the target instruction are often reordered and rescheduled by the processor and can be performed using various processing channels as before. It becomes. However, the subroutine is still fetched and executed.
FIG. 1 (b) is typical of a PowerPC microprocessor used in an Apple Macintosh computer that runs the same target application program designed to run on the CISC processor of FIG. 1 (a). Represents a typical RISC microprocessor. As can be seen, the target application is executed on the host processor using at least a partial target operating system that responds to some of the calls that the target application generates. These are typically calls to the application-like portion of the target operating system and generally a short application-like utility program that is used to provide a graphical interface on the display. These portions of the target application and target operating system are converted by a software emulator such as SoftPC®. The software emulator decomposes instructions provided by the target application program and the application-like target operating system program into instructions that can be executed by the host processor and its host operating system. The host operating system provides an interface that provides access to the memory and input / output hardware of the RISC computer.
However, the host RISC processor in the host RISC computer and the hardware devices that work with it are usually very different from the devices that work with the processor for which the target application was designed. Further, the various instructions provided by the target application program are designed to cooperate with the target operating system device driver in accessing various parts of the target computer. As a result, the emulation program that translates the instructions of the target application program into primitive host instructions that can be used by the host operating system in some way causes the hardware device in the target computer to operate. The designed operation must be linked to an operation that the host system hardware device can achieve. In many cases, this requires the emulator software to create a virtual device that responds to the instructions of the target application and execute instructions that the host system cannot execute. This is because the target device does not belong to the host computer. Sometimes an emulator must create a link from these virtual devices through the host operating system to a host hardware device that exists but is addressed differently by the host operating system. .
Running the target program in this way will run relatively slowly for a number of reasons. First, each target instruction from the target application program and target operating system must be converted by the emulator into a host primitive used by the host processor. If the target application is designed for a CISC machine such as X86, the length of the target instructions varies and is very complex, so converting them into host primitive instructions is a lot of confusion Accompanied by. The original target instruction is first decoded to determine the sequence of primitive host instructions that make up the target instruction. Then, determine the address (or addresses) of each sequence of primitive host instructions, capture each sequence of primitive host instructions, and execute these primitive host instructions in sequence or out of order. Each time an instruction is executed, the enormous additional steps required by the emulator must be performed to change the target application and operating system instructions into host instructions understood by the host processor. The process is slow.
Second, many target instructions include references to operations performed by a particular hardware device that functions in a particular manner in the target computer's hardware that is not available on the host computer. To perform this operation, the emulation software must either make a software connection to the host computer hardware device through the existing host operating system, or the emulation software must You must have a hardware device. It is very difficult to emulate other computer hardware in software. The emulation software must create a virtual device for each target application call to the host operating system, and each of these virtual devices must give a call to the actual host device. I must. To emulate a hardware device, when the target instruction wants to use the device, it must fetch the code representing the virtual device required by the instruction from memory and run it to implement the device . Any of these methods that solve the aforementioned problems add an additional set of operations to the execution of the sequence of instructions.
To complicate the emulation problem, the target computer hardware and target operating system must do this for the target application to throw various exceptions and the computer system to work Because. If a target exception occurs while the target computer is operating, the state of the computer at the time of the exception must be saved. Usually this is done by calling a microcode sequence to accomplish this operation. In addition, the correct exception handler must be retrieved, the exception must be handled, and the correct point in the program must be found to continue the program. Occasionally, this requires the program to revert to the state of the target computer at the time that the exception occurred and at some other time when the branch provided by the exception handler was taken. In any case, the target computer hardware and software necessary to perform these operations must be provided in some way within the emulation process. For proper execution, the correct target state must be obtained at any point in such an exception, so the emulator will always accurately state this state so that it can respond correctly to these exceptions. Forced to track. In the prior art, for this purpose, it is necessary to execute each instruction in the order given by the target application. This is because there was no other way to maintain the correct target state.
Furthermore, the prior art emulator has always had to maintain the execution order of the target applications for other reasons. Target instructions can be of two types: memory affecting and memory mapped input / output (I / O) devices. There is no other way to know if an operation affects memory or memory mapped I / O devices by not trying to execute the instruction. When instructions operate on memory, optimization and reordering are possible, which is very useful for speeding up system operations. However, operations that affect I / O devices must be performed in the order in which the operations are programmed, without removing any steps. Otherwise, the operation of the I / O device may be adversely affected. For example, certain I / O operations may result in clearing I / O registers. If the operations are not performed in order and the required value is still cleared from the register, the result of the operation may be different from the operation commanded by the target instruction. Without a means to distinguish memory from memory mapped I / O, all instructions need to be treated as if they affect memory mapped I / O. This severely limits the optimization that can be achieved. Prior art emulators lack both a means of detecting the nature of the addressed memory and a means of recovering from such failures, so that each operation affects memory mapped I / O. As such, it is necessary to proceed sequentially throughout the entire target instruction. This significantly hinders the possibility of optimizing host instructions.
Another problem that hinders the ability of prior art emulators to optimize host code is caused by self-modifying code. If the target instruction is converted to a sequence of host instructions and then written back to change the original target instruction, the host instruction is no longer valid. As a result, the emulator must always check to determine whether the store is for the target code area. Because of all these problems, this type of emulation is significantly slower than running the target application on the target processor.
Another example of emulation software of the type shown in FIG. 1 (b) is “Talisman: Fast and Accurate Multicomputer Simulation” (RC Bedichek, Laboratory for Computer Sciences, It is described in a paper entitled Massachusetts Institute of Technology (RC Beddy Check, Computer Science Institute, Massachusetts Institute of Technology), which is an example of a more complex transformation that emulates a complete development system. You can run and run a development target operating system, Talisman uses the host UNIX operating system.
FIG. 1C shows an example of another emulation. In this case, a PowerPC microprocessor used in an Apple Macintosh computer running a target application program designed to run on a Motorola 68000 family CISC processor used in the original Macintosh computer is shown. This type of configuration was necessary to run Apple's legacy program on a Macintosh computer with a RISC processor. As seen in the figure, the target application is run on the host processor at least partially using the target operating system and responds to the application-like portion of the target operating system. Some software emulators break down instructions given by a target application program or an application-like target operating system program into instructions that can be executed by the host processor or its host operating system. The host operating system provides an interface through which access to the host computer's memory and input / output hardware is obtained.
Again, the host RISC processor and associated devices in the host RISC computer are quite different from the devices associated with Motorola's CISC processor, and different target instructions are used to access different parts of the target computer. Designed to work with the target CISC operating system. As a result, the emulation program must link the operation designed to operate the hardware device in the target computer to the operation that can be realized by the hardware device of the host system. To this end, the emulator creates software virtual devices that respond to the instructions of the target application and addresses them from these virtual devices through the host operating system, but in different ways depending on the host operating system. Link to the host hardware device to be created.
The target software running in this way is relatively slow to run for the same reason that the emulation of FIG. 1 (b) is slow to run. First, each target instruction from the target application and target operating system must be converted by capturing the instruction, and each time the instruction is executed, a host primitive function that is derived from the instruction All of these must be run sequentially. Second, the emulation software must create a virtual device for each call of the target application to the host operating system. In addition, each of these virtual devices must provide a call to the actual host device. Third, the emulator must process all instructions conservatively to handle the danger of generating instructions directed to memory mapped I / O devices, or exceptions that it cannot restore. Don't be. Finally, the emulator always maintains the correct target state and the store operation must always be checked to determine beforehand whether the store is for the target code area. All of these requirements take away the ability to perform significant optimizations on the code running on the emulator's host processor, making this type of emulator much slower than running the target application on the target processor. Let
An emulation rate of less than a quarter of the state of the art processor is considered very good. In general, this has forced this type of emulation software to be useful but not the primary use of the ability to run applications designed on other processors.
FIG. 1 (d) shows a specific method for emulating a target application program on a host processor and providing relatively good performance for a very limited set of target applications. Show. The target application provides instructions to the emulator, which changes these instructions to instructions for the host processor and host operating system. The host processor is an Alpha RISC processor from Digital Equipment Corporation, and the host operating system is Microsoft NT. The only target application that can be run by this system is a 32-bit application designed to be executed by a target X86 processor with an operating system compliant with Windows WIN32s. Since the host and target operating systems are almost identical and designed to handle these same instructions, the emulator software can convert the instructions very easily. Furthermore, since the host operating system is already designed to respond to the same call that the target application originates, virtual device creation is greatly reduced.
This is technically an emulation system that runs a target application on a host processor, but it is a very special case. Here, the emulation software is running on a host operating system that is already designed to run a similar application. This makes it easier to direct calls from the target application to the correction mechanism of the host and host operating system. More importantly, the system only runs 32 bit Windows applications, perhaps less than 1% of all X86 applications. Furthermore, the system runs applications only on one operating system, namely Windows NT, while the X86 processor runs applications designed for multiple operating systems. Accordingly, such systems cannot be considered interchangeable within the meaning originally presented in this specification. Therefore, a processor that runs such an emulator cannot be considered a competing X86 processor.
FIG. 1 (e) shows another emulation method that allows a portion of an application written for the first instruction set to be run using software on a computer that recognizes a different instruction set. This form of emulation software is typically used by programmers trying to port an application from one computer system to another. Typically, the target application is designed for any target computer other than the host machine that runs the emulator. The emulator software analyzes the target instructions, converts these instructions into instructions that can be run on the host machine, caches these host instructions, and makes them reusable. This dynamic conversion and caching makes it possible to run parts of the application very fast. This form of emulator is typically used with a software trace tool to provide detailed information about the behavior of the target program being executed. On the other hand, the output of the trace tool can be used to drive an analyzer program that analyzes the trace information.
In order to determine how the code actually works, among other things, this type of emulator is run by the host operating system on the host machine and uses virtual hardware that the host operating system does not have. Otherwise, it maps the operation of the computer that is the application design object to the hardware resources of the host machine and executes the operation of the running program. The hardware virtualization and mapping to the host computer by this software can be very slow and incomplete.
In addition, because multiple host instructions are often required to execute one of the target instructions, exceptions including faults and traps that require an exception handler in the target operation system may occur. In some cases, the host may stop processing the host command at a point unrelated to the target command boundary. If this happens, it may not be possible to handle the exception correctly. This is because the state of the host processor and memory is incorrect. In such a case, you must stop the emulator and run it again to track the operation that caused the exception. Thus, although such an emulator can run the target code sequence very quickly, there is no way to recover from these exceptions, and thus no important part of the application can be run quickly.
This is not a unique problem with this form of emulator. Because the functions performed by emulators, tracers, and moving analyzers can generate new programs or port old programs to another machine so that the speed at which the emulator software runs is of little concern. It is because it aims to do. That is, programmers are not always interested in how fast the code generated by the emulator will run on the host machine, and whether the code generated by the emulator can be executed on the machine designed for it, and I'm interested in whether to run quickly on the machine. As a result, this type of emulation software does not provide a way to run application programs written in the first instruction set to run on different types of microprocessors for purposes other than programming. . An example of this type of emulation software is Cmelik and Keppel, which are titled "Shade: A First Instruction-Set Simulator for Execution Profiling". ).
Any operating system available to these microprocessors that is faster and cheaper than state-of-the-art microprocessors, yet is fully compatible with the target application programs designed for the state-of-the-art microprocessors It is desirable to provide a competitive microprocessor that can run the system.
Summary of the Invention
Therefore, the object of the present invention is cheaper than conventional state-of-the-art microprocessors, yet compatible with application programs and operating systems designed for other microprocessors. It is to provide a microprocessor capable of running these at a faster rate.
This and other objects of the present invention are realized by a microprocessor for a host computer designed to execute a target program for a target computer having a target instruction set. And a modified host processing hardware designed to execute instructions of the host instruction set, and the combination of software and modified host processing hardware combines a set of target instructions with instructions of the host instruction set. Means for converting to
In a preferred embodiment, the combination of software and improved host processing hardware comprises a means for inferring the occurrence of certain conditions and optimizing instructions in the host instruction set translated from the target program; Means for determining the official state of the target computer under the control of software, which existed at the start of conversion of a set of target instructions during execution of the target program; Means for updating the state of the target computer from the state of the host computer when executing the instructions, means for detecting that the executing condition of the set of host instructions has not been satisfied, and a set of host instructions If execution fails according to guesses, the status of the host computer is changed to the target computer. Means for updating the state, if a pair of hosts instruction fails to run according to speculation, without a guess, and means for converting the new set of host instructions.
In a preferred embodiment, the morph host refinement processing hardware was designed to allow conversion, optimization, reordering, and rescheduling of the target instruction set to a very long instruction word. Includes a very long instruction word (VLIW) processor. Very long instruction words can be cached for later reuse, thereby increasing execution speed by eliminating the need for each of these steps each time a target instruction is discovered. It is possible to execute advanced superscalar processing and other time-saving processing by rearranging and scheduling together multiple host instruction sets generated from a large number of instructions in the target instruction set. Remove unnecessary hardware operations and accelerate the entire process.
These and other objects of the invention will be better understood by reference to the following detailed description in conjunction with the drawings. In the drawings, like elements are referred to by like numerals throughout the various drawings.
[Brief description of the drawings]
FIG. 1A to FIG. 1E are diagrams showing an operation mode of a microprocessor designed according to the prior art.
FIG. 2 is a block diagram of a microprocessor according to the present invention running applications designed on different microprocessors.
FIG. 3 shows a part of the microprocessor shown in FIG.
FIG. 4 is a block diagram showing a register file used in the microprocessor according to the present invention.
FIG. 5 is a block diagram illustrating a gate storage buffer designed in accordance with the present invention.
FIGS. 6 (a) to 6 (c) show instructions used in various prior art microprocessors and microprocessors according to the present invention.
FIG. 7 shows the method implemented by the software part of the microprocessor according to the invention.
FIG. 8 illustrates another method implemented by the software portion of the microprocessor according to the present invention.
FIG. 9 is a block diagram illustrating an improved computer system according to the present invention.
FIG. 10 is a block diagram showing a part of the microprocessor shown in FIG.
Notation and name
In the detailed description that follows, there are portions that present symbolic representations of operations on data bits within a computer memory. These descriptions and representations are used by those skilled in the data processing arts and are the means to most effectively convey the nature of their operation to others skilled in the art. The operation is one that requires physical manipulation of physical quantities. Usually, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated, but this is not necessarily the case. It is sometimes recognized that it is convenient to refer to these signals as bits, values, elements, symbols, characters, words, numbers, etc. mainly for reasons of common use. However, it should be borne in mind that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient names applied to these quantities.
Furthermore, the operations performed are often referred to in terms such as addition or comparison, which are generally related to the mental actions performed by a human operator. Such a capability of a human operator is in most cases not necessary or desirable for any of the operations described herein that form part of the present invention. An operation is a mechanical operation. Useful machines for performing the operations of the present invention include general purpose digital computers or other similar devices. In all cases, a distinction should be borne in mind between the method operation that operates the computer and the method of computation itself. The present invention relates to methods and apparatus for operating a computer to process electrical or other (eg, mechanical, chemical) physical signals and generate other desired physical signals.
During the following description, in some cases, in order to give a detailed example of operation, a target program shall mean a program designed to run on an X86 microprocessor. This is because most emulators run X86 applications. However, the target program may be designed to run on any target computer family. This includes a target virtual computer, such as a Pcode machine, a Postscript machine, or a Java virtual machine.
Detailed description
The present invention overcomes the problems of the prior art and brings all of the software to all of the operating systems that can be run by multiple families of microprocessors of the prior art faster than prior art microprocessors. A microprocessor is provided that can be run and is less expensive than prior art microprocessors.
Instead of using a microprocessor that accelerates its operation with more complex hardware, the present invention provides an improved hardware processor (in this specification, “morph host”) that is simpler than each state-of-the-art microprocessor. ) And an emulated software section (referred to as “code morphing software” in this specification), and these two parts work together as a microprocessor, It has higher performance than any competing microprocessor. More specifically, a morph host is a processor that includes hardware enhancements that assist in obtaining the state of the target computer immediately after an exception or error occurs, while code morphing software Means that the instructions in the target program are converted to morph host instructions for the morph host, and in response to exceptions and errors, the working state is replaced with the correct target state as necessary, so that Software that allows conversion to occur. The code morphing software can also include various processes to increase processing speed. Prior art ultrafast microprocessors all have hardware to increase processing speed, but instead, the present invention is in a stage where a number of accelerated reinforcement techniques can be selected by code morphing software. Make it executable. By providing speed enhancement technology in the code morphing software, it is possible to implement a morph host using hardware with much lower complexity. This is faster and significantly less expensive than prior art microprocessor hardware. By way of comparison, one embodiment of the present invention designed to run all available X86 applications is implemented by a morph host containing about 1/4 of the number of gates of a Pentium Pro microprocessor, and the Pentium Pro microprocessor. Or run any of these applications significantly faster than any other known microprocessor capable of handling X86 applications.
Code morphing software utilizes certain techniques that were previously used only by programs that design new software or emulate new hardware. The morph host includes a plurality of hardware enhancements specifically configured to efficiently utilize the acceleration technology provided by the code morphing software. These hardware enhancements allow code morphing software to implement acceleration technology for a wider range of instructions. In addition, these hardware enhancements cannot be obtained with hardware processors, but with code morphing software, additional acceleration technologies that can only be realized with processors that are prohibitively expensive. Can be implemented. These techniques significantly increase the speed of the microprocessor of the present invention compared to the speed of prior art microprocessors that execute native instruction sets.
For example, code morphing software combined with an improved morph host allows the use of techniques that allow the reordering and rescheduling of the source instructions generated by the target instruction sequence without the need for additional circuitry Can be. By enabling reordering and rescheduling of a large number of target instructions, other optimization techniques can be used to run the target application for the number of processor steps required to execute the target instructions. This can be reduced more than any microprocessor requires.
Code morphing software in combination with an improved morph host converts target instructions into morph host instructions during execution, and converts these host instructions into a memory data structure (in this specification, a “translation buffer”). "). By holding the instructions converted using the conversion buffer, it is determined which primitive instructions are necessary to realize each target instruction, each primitive instruction is addressed, each primitive instruction is taken in, and the sequence of the primitive instructions is determined. Optimize, assign assets to each source instruction, reorder the source instructions, and run each step of each sequence of required source instructions each time you execute each target instruction, without having to run the long process again It becomes possible to call the instruction. Once the target instruction has been translated, it can be called and executed from the translation buffer without requiring these infinite steps.
The first problem with prior art emulation techniques is that they cannot handle exceptions that occur during execution of the target program with good performance. This is especially true for exceptions that occur when running a target application that targets the target operating system. In this case, for proper execution of the exception and subsequent instructions, the correct target state must be able to be obtained at any point of such exception. As a result, the emulator is always forced to track the target state with high accuracy and must always check to determine if the storage is for the target code area. Other exceptions cause similar problems. For example, an exception may occur when an emulator detects a specific target action that has been replaced by a specific host function. That is, various hardware operations of the target processor can be replaced with software operations provided by the emulator software. In addition, a host processor that executes a host instruction derived from the target instruction may also generate an exception. All of these exceptions can occur either while the emulator is trying to convert the target instruction to a host instruction or when the host conversion is performed on the host processor. For efficient emulation, it is necessary to have some way to efficiently recover from these exceptions while handling them correctly. There is nothing in the prior art that does this for all software that can be emulated.
To overcome these limitations of the prior art, the present invention incorporates numerous hardware improvements in its improved morph host. These improvements include a gated store buffer and a number of additional processor registers. Some of the additional registers can use register renaming to alleviate the problem of instructions that require the same hardware resources. The additional registers maintain a set of host or working registers that process host instructions, and a set of target registers, and the official state of the target processor that created the target application. Can be held. Target (or shadow) registers are connected to their working register equivalents via a dedicated interface. The dedicated interface allows the contents of all working registers to be quickly transferred to the official target register by an action called “commit” and all official registers by an action called “rollback”. Allows the contents of target registers to be quickly transferred back to their working register equivalents. The gate storage buffer stores the state change of the working memory on the “uncommit” side of the hardware “gate”, and further stores the state change of the official memory on the “commit” side of the hardware gate. To do. In this case, the committed store “spills” out to main memory. The commit operation transfers the storage from the uncommitted side of the gate to the commit side of the gate. Once one or a group of target instructions have been converted and ran without error, additional official registers and gate store buffers allow the memory state and target register state to be updated together.
These updates are selected by the code morphing software to occur on an integral target instruction boundary. Thus, if the primitive host instructions that make up a series of target instruction transformations are run by the host processor without raising an exception, the working memory storage and working register states generated by these instructions are: It is transferred to the official memory and then to the official target register. Thus, in the target register at the last update (or commit) if an exception occurs when processing a host instruction at a point that is not on the boundary of one or a set of target instructions to be converted The original state of can be called into the working register and the uncommitted memory store in the gate store buffer can be dumped. Then, if the exception that occurred is a target exception, re-convert the target instructions that caused this target exception one at a time and execute them in a sequence so that they are executed by the target microprocessor can do. Since each target instruction is executed correctly without error, the state of the target register can be updated and the data in the storage buffer can be passed to memory. Second, if the exception occurs again while running the host instruction, the correct state of the target computer is retained in the morph host's target register and memory, allowing the operation to be handled correctly without delay . Each new conversion resulting from this correct conversion should be cached for future use and used to convert it, erase it once, or in rare events such as page faults. can do. This allows a microprocessor created by a combination of code morphing software and a morph host to execute instructions faster than the processor that originally wrote the software.
It should be noted that when executing a target program using the microprocessor of the present invention, many different types of exceptions can occur and these are handled differently. For example, some exceptions are caused by the target software that generates the exception, which uses the target operating system's exception handler. The use of such exception handlers requires that the code morphing software include routines that emulate the entire exception handling process, including any hardware provided by the target computer, for processing the process. is there. This requires that the code morphing software has the ability to save the state of the target processor so that it can migrate correctly after handling the exception. For exceptions that need to populate a new page of memory before performing the converted process, such as a page fault, you must return to the beginning of the process to be converted after handling the exception. is there. Another exception is that certain actions are implemented in software if the action is not given by hardware. These require the exception handler to return to the next step in the transformation after it has handled the exception. Each of these different types of exceptions can be handled efficiently by the present invention.
In addition, exceptions include those in which host hardware occurs and detects various host and target conditions. Some exceptions behave like exceptions on traditional microprocessors, while others are used by code morphing software to detect various speculation failures. . In these cases, the code morphing software uses the state save and restore mechanism described above to restore the target state to its most recent official version and generate and save a new transformation that avoids the failed guess. (Alternatively, use a safe conversion done earlier). Next, this conversion is performed.
The morph host includes an additional hardware exception detection mechanism, allowing further optimization along with the rollback and reconversion methods described above. Examples include means for distinguishing the memory from memory mapped I / O and means for protecting the address or address range so that no memory reference is required and the target variable can be held in a register.
If an exception is used to detect other speculative failures, such as whether the operation affects memory or memory-mapped I / O, restoration is achieved by generating a new transformation, but the memory operation Is different and optimization is different.
FIG. 2 is a diagram representing morph host hardware designed in accordance with the present invention for running the same application program running on the CIS processor of FIG. As seen in the figure, the microprocessor includes the code morphing software portion described above and an improved hardware morph host portion. The target application provides the target instruction to the code morphing software for conversion into a host instruction that can be executed by the morph host. Meanwhile, the target operating system receives calls from the target application program and forwards them to the code morphing software. In the preferred embodiment of the present invention, the morph host is a very long instruction word (VLIW) microprocessor and is designed with multiple processing channels. The overall operation of such a processor is further illustrated in FIG.
FIGS. 6 (a) -6 (c) illustrate instructions configured for use with each of the CISC processor, the RISC processor, and the VLIW processor. As can be seen, the CISC instruction is variable length and can include a plurality of more primitive operations (eg, load and add). On the other hand, RISC instructions are equal in length and are essentially primitive operations. The single very long instruction for the illustrated VLIW processor includes each of the more primitive operations (ie, load, store, integer add, compare, floating point multiply, branch) of the CISC and RISC instructions. As seen in FIG. 6 (c), each of the primitive instructions that together make up a single very long instruction word is connected to one of the multiple separate processing channels of the VLIW processor in parallel with the other primitive instructions. Or memory and are handled in parallel by the processing channel and memory. All the results of these parallel operations are transferred to the multiport register file.
The VLIW processor that is the basis of the morph host is a much simpler processor than the other processors mentioned above. This does not include circuitry that detects issue dependency, nor circuitry that reorders, optimizes, and reschedules the source instructions. For this purpose, a clock rate higher than the clock rate possible by either the target processor that originally designed the target application program or any other processor that uses the emulation program to run the target application program. Fast processing is possible at the rate. However, the present invention is not limited to VLIW processors and can function in the same manner with any type of processor such as a RISC processor.
The code morphing software of the microprocessor shown in FIG. 2 includes a conversion unit. It decodes the target application instructions, converts these target instructions into source host instructions that can be executed by the morph host, optimizes the operations required by the target instructions, and schedules the source instructions for reordering. The morph host VLIW instruction (conversion) is executed, and the host VLIW instruction is executed. The operation of the conversion unit is shown in FIG. FIG. 7 shows the operation of the main loop of the code morphing software.
In order to accelerate the operation of a microprocessor including code morphing software and improved morph host hardware, the code morphing software includes a conversion buffer as shown in FIG. The conversion buffer of one embodiment is a software data structure that can be stored in memory. In certain embodiments, a hardware cache may also be utilized. The translation buffer is used to store host instructions that materialize each completed translation of the target instruction. As seen in the figure, once individual target instructions are converted and the obtained host instructions are optimized, rearranged, and rescheduled, the obtained host conversion is stored in a conversion buffer. The host instructions that make up the transformation are then executed by the morph host. If the host instruction is executed and no exception occurs, the transformation can be invoked whenever the target instruction or group of operations is required thereafter.
Thus, as shown in FIG. 7, when a target instruction address is given by an application program, the typical operation of the microprocessor's code morphing software is to first start with the target instruction at the target address. Is to determine whether or not is converted. If the target instruction has not been converted, the conversion unit captures it and subsequent target instructions, decodes, converts, then optimizes (possibly), reorders, reschedules to a new host conversion, and into the conversion buffer Store. As will be seen later, there are various degrees of optimization that are possible. In this specification, the term “optimization” is often used generically to refer to techniques for accelerating processing. For example, rearrangement is a form of optimization that enables high-speed processing, and is included in this term. Many of the possible optimizations are described in the prior art of compiler optimization, such as some "super-blocks" that were difficult to execute within the prior art. Optimization was revealed from VLIW studies. Control is then transferred to the transformation, executed by the modified morph host hardware, and resumed.
When the application is running, the next time a specific target instruction sequence is found, there is a host translation in the translation buffer that executes immediately without the need for translation, optimization, reordering or rescheduling. By using the advanced techniques described below, it is speculated that the translation for the target instruction (once fully translated) is found in the translation buffer approximately once every 1 million conversions are performed. . As a result, after the first conversion, all of the steps necessary for the conversion, such as decoding, fetching the source instruction, optimizing the source instruction, rescheduling to host conversion, and storing in the conversion buffer, are all necessary. Can be excluded. This is the work required to execute the target instruction because the target processor that wrote the target instruction must decode, fetch, reorder, and reschedule each instruction every time it executes the instruction. Drastically reduce the speed of the microprocessor of the present invention.
In order to eliminate all these steps necessary for the execution of the target application by the prior art processor, the microprocessor of the present invention has the problem of making the operation of the present invention impossible at any reasonable speed in the prior art. Overcome. For example, some of the techniques of the present invention have been used in the aforementioned emulators that are used to port applications to other systems. However, some of these emulators have no way to run other than a short part of the application. This is because when processing translated instructions, exceptions that cause calls to various system exception handlers are not related to the state of the target processor that is processing the same host processor state. This is because it occurs at the time. For this reason, the state of the target processor at the time when such an exception occurs was not known. Therefore, the correct state of the target machine cannot be determined, operation must be stopped, restarted, and the correct state must be known before the exception can be handled (service) and execution can continue. There wasn't. For this reason, it was impossible to run the application program at the host speed.
The morph host hardware of the present invention includes a number of enhancements that overcome this problem. These enhancements are shown in FIGS. 3, 4 and 5, respectively. To determine the correct state of the registers at the time of the error, a set of official target registers is provided by the modified hardware to keep the state of the registers of the target processor for which the original application was designed . These target registers can be included in each of the floating point unit, any integer unit, and any other execution unit. By adding these official registers to the morph host of the present invention and increasing the number of normal working registers, a number of optimizations including register renaming can be implemented. One embodiment of the improved hardware includes 64 working registers in the integer unit and 32 working registers in the floating point unit. This embodiment also includes a reinforced set of target registers. It contains all the frequently changing registers of that processor that are needed to give the state of the target processor. These include condition control registers and other registers necessary for controlling the simulation target system.
Note that, depending on the type of improved processing hardware used by the morph host, the converted instruction sequence may contain primitive operations that make up multiple target instructions from the original application. For example, the VLIW microprocessor may be able to run multiple CISC or RISC instructions simultaneously, as shown in FIGS. 6 (a) through 6 (c). Whatever the morph host type, the target register state of the morph host hardware of the present invention does not change except for the integer target instruction boundary, and then all target registers are updated. Is done. Thus, if the microprocessor of the present invention is executing a target instruction or group of instructions that have been reordered and rescheduled for host translation, the target instruction or group of instructions is translated into the sequence of instructions When the first target instruction is addressed, the official target register holds the value held by the register of the target processor for which the application was designed. After the morph host begins executing the converted instruction, however, the working register holds a value determined by the original operation of the converted instruction executed up to that point. Thus, some of these working registers may hold the same value as in the official target register, while other working registers hold values that are meaningless to the target processor. . This is especially true for embodiments that provide much more registers than a particular target machine and that allow advanced acceleration technologies. Once converted host instructions have started, these converted host instructions determine the state of the working registers, and the values in these registers are one of the values determined by the converted host instructions. . When a set of converted host instructions is executed without causing an exception, the new working register value determined at the end of the set of instructions is transferred to the official target register together ( Possibly including the target instruction pointer register). In this embodiment of the present invention, this transfer is performed in an additional pipeline stage other than the execution of the host instruction, so it does not delay the operation of the morph host.
Similarly, a gate storage buffer such as the embodiment shown in FIG. 5 is utilized in the present invention to control the transfer of data to memory. The gate storage buffer includes a number of elements, each of which can act as a storage location for holding addresses and data for memory storage operations. These elements can be implemented in any of a number of different hardware configurations (eg, first-in first-out buffers), and the illustrated embodiment can be implemented using random access memory and three dedicated working registers. Each of the three registers stores a pointer to the head of the memory storage queue, a pointer to the gate, and a pointer to the end of the memory storage queue. The memory store at the storage location between the head and gate of the queue has already been committed to memory, while the memory store at the storage location between the gate and tail of the queue has not yet been committed to memory. Memory stores that occur during execution of host translation are placed in the storage buffer by the integer unit in the order in which they occurred during execution of the host instruction by the morph host, but until the commit operation is found in the host instruction, Writing is not allowed. Thus, when a conversion is performed, the store operation is placed in a queue. Assuming these are the first stores and no other stores are in the gate store buffer, the head pointer and the gate pointer indicate the same location. As each store is performed, it is placed at the next location in the queue and the tail pointer is incremented to the next location (upward in the figure). This continues until a commit command is executed. The commit command is typically executed when the conversion of a set of target instructions is completed without causing an exception or an error termination condition. If the conversion is performed by the morph host without error, the memory storage in the storage buffer that occurred during the execution will pass through the gate of the storage buffer (committed) together and subsequently written to the memory. In the illustrated embodiment, this is done by copying the value in the register holding the tail pointer to the register holding the gate pointer.
Thus, both the transfer of the register state from the working register to the official target register and the transfer of the working memory store to the official memory are performed together and in response to an explicit commit operation. It can be seen that this is done only on the boundary between integer target instructions.
This allows the microprocessor to recover from target exceptions that occurred during execution by the modified morph host without any significant delay. If a target exception occurs during the execution of either the translated instruction or group of instructions, this exception is detected by the morph host hardware or software. In response to detecting the target exception, the code morphing software returns the value held in the official register to the working register and erases all uncommitted memory storage in the gate store buffer. (Operation called "rollback"). The memory storage in the gate storage buffer in FIG. 5 can be erased by copying the value in the register holding the gate pointer to the register holding the tail pointer.
By moving the value from the target register to the working register, the address of the first of the target instructions that were running when the exception occurred can be placed in the working instruction pointer register.
Starting from this official state of the target processor in the working register, the target instructions that were running when the exception occurred are reconverted in sequential order, but without any reordering or other optimization. When each target instruction is newly decoded and converted into a new host conversion, when the converted host instruction representing the target instruction is executed by the morph host, an exception may or may not occur. (If the morph host is other than a VLIW processor, each of the host conversion primitive operations is executed sequentially. If no exception occurs when running host transformation, the next primitive function is run.) This continues until an exception occurs again or a single target instruction is translated and executed. In one embodiment, if the target instruction conversion is performed without an exception, the working register state is transferred to the target register, and any data in the gate storage buffer is committed, so the memory Can be transferred. However, if an exception occurs again during the execution of the conversion, the state of the target register and memory does not change and is identical to the state that occurred in the target computer when the exception occurred. As a result, if a target exception occurs, this exception is handled correctly by the target operating system.
Similarly, if the first target instruction in the series of instructions in which an exception has occurred due to conversion is executed once and no exception has occurred, the target instruction pointer indicates the next target instruction. As in the first case, the second target instruction is decoded and reconverted without optimization or rearrangement. As each single target instruction host translation is processed by the morph host, an exception occurs if the state of the target register and memory is the same as that occurring in the target computer. As a result, exceptions can be handled immediately and correctly. These new translations are stored in the translation buffer as the correct translations for the sequence of instructions in the target application and can be invoked whenever the instructions are run again.
Another embodiment of the present invention that achieves the same result as the gate store buffer of FIG. 5 is that the target is transferred when an exception or error occurs that requires a rollback as a result of a conversion exception while transferring the storage directly to memory. It could include a configuration that records sufficient data to restore the state of the computer. In such a case, any memory storage that occurred during the conversion and execution must be reversed and the memory state that existed at the start of the conversion must be restored. On the other hand, the working register must receive the data held in the official target register, as discussed above. One embodiment for doing this maintains a separate target memory to preserve the original memory state and uses this to replace the overwritten memory if a rollback occurs. Other embodiments that perform memory rollback record each storage, replace it as memory data occurs, and then reverse the storage process if a rollback is required.
The code morphing software of the present invention has additional operations that greatly increase the speed with which the program being converted is processed. Simply translate, optimize, reorder, reschedule, cache, and execute each transformation so that you can run it again whenever you need to execute a set of instructions In addition, the conversion unit links the different conversions and in most cases eliminates the need to return to the main loop of the conversion process. FIG. 8 shows the steps performed by the code morphing software converter in performing this linking process. Those skilled in the art will appreciate that this linking operation essentially eliminates the need for a return to the main loop and eliminates this overhead for most instruction conversions.
For illustrative purposes, assume that the target program to be run consists of X86 instructions. If the target instruction sequence is converted and the source host instructions are rearranged and rescheduled, two primitive instructions may occur at the end of each host conversion. The first is a primitive instruction that updates the value of the instruction pointer for the target processor (or equivalent). This instruction is used to place the correct address of the next target instruction in the target instruction pointer register. Following this primitive instruction is a branch instruction, which contains the address of each of the two possible targets for that branch. The method in which the original instruction prior to the branch instruction updates the value of the instruction pointer for the target processor is to test the condition code for the branch in the condition code register and to determine if one of the two branch addresses indicated by the condition controlling the branch is It is to determine whether or not the data is stored in the conversion buffer. When initially converting a sequence of target instructions, the two branch targets of the host instruction both have the same host processor address for the main loop of the converter software.
When the host translation is complete, stored in the translation buffer, and executed for the first time, the instruction pointer is updated in the target instruction pointer register (similar to the rest of the target register), and the operation branches to the main loop Return. In the main loop, the conversion software refers to the instruction pointer to the next target instruction in the target instruction pointer register. The next target instruction sequence is then addressed. Assuming that this sequence of target instructions has not yet been converted, and therefore the conversion is not in the conversion buffer, the next set of target instructions is taken from memory, decoded, converted, optimized, reordered, reordered. Schedule, cache in translation buffer and execute. Since the second set of target instructions follows the first set of target instructions, the last primitive branch instruction of the host translation of the first set of target instructions is automatically updated and the host translation address of the second set of target instructions Is replaced as a branch address for a specific condition that controls the branch.
Then, if the second translated host instruction loops back to the first translated host instruction, the branch operation at the end of the second translation is the address of the main loop and X86 of the first translation. The address is included as two possible targets for the branch. The update-instruction-pointer primitive operation prior to the branch tests the condition, decides to loop back to the first translation, and updates the target instruction pointer to the X86 address of the first translation. This causes the translation unit to check the translation buffer to see if the X86 address being searched is there. If the address of the first translation is found, replace its value in the host memory space with the X86 address in the last branch of the second host translation instruction. Next, the second host conversion instruction is cached and executed. As a result, this loop is run until the condition for branching from the first transformation to the second transformation is not satisfied, and a branch is taken that takes a path back to the main loop. If this is done, the first translated host instruction branches back to the main loop, searches the translation buffer for the next set of target instructions specified by the target instruction pointer, and translates the host from the cache. Capture. Alternatively, if the search in the conversion buffer fails, the target instruction is fetched from the memory and converted. When this translated host instruction is cached in the translation buffer, its address replaces the main loop address in the branch instruction that terminated the loop.
Thus, since the various translated host instructions are chained together, it is only necessary to follow a long path through the translation main loop when there is no link. Finally, the main loop reference in the host instruction branch instruction is almost completely useless. When this condition is reached, even before any host instruction is run, the target instruction is fetched, the target instruction is decoded, the primitive instructions that make up the target instruction are fetched, and these primitive operations are optimized, The time required to rearrange the primitive actions and reschedule these primitive actions is not required. Therefore, in contrast to all prior art microprocessors that must execute each of these steps each time the instruction sequence of any application is run, the present invention allows the first conversion to be performed. After doing so, the work required to run any set of target instructions is drastically reduced. This work is further reduced by linking each set of translated host instructions to another set of translated host instructions. In fact, while the application is running, it is estimated that it will need to be exchanged less than once during 1 million instruction executions.
Those skilled in the art will recognize that this implementation of the present invention requires a large translation buffer so that each set of instructions to translate is cached in turn and eliminates the need to translate again. The need for converter support buffer memory designed to work with applications programmed for different systems varies. However, one embodiment of the present invention designed to run X86 programs utilizes 2 megabytes of random access memory as a translation buffer.
Two additional hardware enhancements help increase the speed at which the macroprocessor of the present invention can process applications. The first of these is an anomaly / normal (A / N) protection bit, each of which is in the translation look-aside buffer (TLB) (see FIG. 3) that first referenced the physical address of the target instruction. Stored with address translation. There are two types of operation of the target memory inside the conversion, one operating on the memory (normal) and the other operating on the memory mapped I / O device (abnormal).
A normal access that affects the memory completes normally. When instructions operate on memory, it is appropriate to optimize and reorder these instructions, which is very helpful in increasing the speed of any system using the microprocessor of the present invention. On the other hand, abnormal access operations that affect I / O devices often have to be performed in the exact programmed order without removing any steps. Otherwise, there may be some adverse effects on the I / O device. For example, certain I / O operations may result in clearing I / O registers, and if the original operation is performed out of order, the result of the operation is different from the operation commanded by the target instruction There is a case. Without a means of distinguishing memory from memory mapped I / O, all memory must be handled using the traditional assumptions used in translating instructions that affect memory mapped I / O. This significantly limits the achievable optimality. Since prior art emulators lacked both a means of detecting a guess failure for the characteristics of the addressed memory and a means of recovering from such a failure, its processing power was limited.
In one embodiment of the present invention, the A / N bit is initially set in the conversion look-aside buffer to indicate a memory page. Converting an operation that affects the memory as if it were a memory operation is actually a speculation that this operation affects the memory. After the conversion is done and executed, the target memory reference is checked by comparing the access type (normal or abnormal) with the LTB A / N protection bit. An exception occurs if the access type does not match A / N protection. If the operation actually affects the memory, then the optimization, reordering, and rescheduling techniques described above have been correctly applied. However, if the comparison of the A / N bit in the TLB indicates that the operation affects the I / O device, an exception will occur due to execution, and the conversion unit will do any kind of optimization, reordering, There is no scheduling, and a new conversion is performed one target instruction at a time. Similarly, if a conversion incorrectly assumes an I / O operation that actually affects the memory, an exception will be generated by the execution and the optimization, reordering and rescheduling techniques can be used to Reconvert the instruction. Thus, the present invention can provide improvements over previously possible performance.
One of the guesses that the present invention makes most often relates to the absence of target exceptions during conversion. Thereby, each stage can be optimized with respect to the prior art. First, the target state does not need to be updated for each target instruction boundary, but only needs to be updated on the target instruction boundary that occurs on the conversion boundary. This eliminates the need for instructions required to save the target state for each target instruction boundary. Optimization that was not possible in the past to eliminate scheduling and redundant operations is also possible.
Surprisingly, the present invention is configured to select an appropriate conversion process. According to the conversion method described above, a set of instructions can first be converted as if it affected the memory. Next, when host instruction optimization, reordering, and rescheduling are performed, an address that refers to the I / O device is obtained according to the state of the A / N bit provided in the conversion look-aside buffer. Can do. A comparison of the A / N bit with the translated instruction address indicating that an operation is an I / O operation results in an error exception, which causes a software-initiated rollback procedure to be performed. The memory store is erased and the value in the target register is returned in the working register. Next, conversion is started one target instruction at a time, and no optimization, reordering, or rescheduling is performed. This reconversion is a host conversion suitable for an I / O device.
Similarly, the memory operation may be erroneously converted as an I / O operation. Using the error that occurs, let it do the correct retransformation, optimize, reorder, and reschedule to give faster operation.
Prior art emulators have also struggled with what is commonly referred to as self modifying code. When the target program writes to the memory that contains the target instructions, the translations that exist for those target instructions become “stale” and are no longer valid. As these stores occur, they need to be detected dynamically. In the prior art, such detection must be performed using an extra instruction for each store. This problem is broader than a program changing itself. Any agent that can write to memory, such as a second processor or DMA device, can also cause this problem.
The present invention addresses this problem with another enhancement to the morph host. Similarly, a conversion bit (T bit) that can be stored in the conversion look-aside buffer is used to indicate the target memory page that is causing the conversion to exist. Thus, the T bit can indicate that a particular page of target memory contains a target instruction that is responsible for the presence of a host translation. If these target instructions are overwritten, the conversion will become stale. If you try to write to a page protected in memory, an exception will be generated due to the presence of the conversion bit, and when this is processed by the code morphing software, the corresponding conversion (multiple conversions) will be invalidated, It can be removed from the conversion buffer. The T bit can also be used to mark a target page that has not been written and can be converted based on this.
This can be understood by referring to FIG. 3, which shows in block diagram form the overall functional elements of the microprocessor of the present invention. When the morph host executes the target program, it actually runs the conversion part of the code morphing software that contains only the original host instructions that have not been converted. The original host instruction that has not been translated effectively runs on the morph host. On the right side of the figure, the memory is shown divided into a host portion that essentially includes a translator and a translation buffer, and a target portion that includes a target operating system and includes target instructions and data. When the morph host hardware starts executing the converter, it takes host instructions from memory and places these instructions in the instruction cache. The instruction of the conversion unit generates a fetch of the first target instruction stored in the target portion of the memory. By performing the target fetch, the integer unit looks up the official target instruction pointer register for the first address of the target instruction. It then accesses the first address in the translation lookaside buffer of the memory management unit. The memory management unit includes paging hardware and provides memory mapping facilities to the TLB. Assuming the TLB is correctly mapped and holds reference data for the correct page in the target memory, the target instruction pointer value is translated to the physical address of the target instruction. At this point, the state of a bit (T bit) indicating whether or not conversion has been performed on the target instruction is detected, but the access is a read operation and no T bit exception occurs. The state of the A / N bit that indicates whether the access is for memory or memory mapped I / O is also detected. Assuming that the last mentioned bit indicates a memory location, since there is no translation, the target instruction in the target memory is accessed. This target instruction and subsequent target instructions are transferred as data to the morph host computer unit and converted under the control of conversion instructions stored in the instruction cache. The conversion instruction uses a reordering technique, an optimization technique, and a rescheduling technique as if the target instruction affects the memory. Next, a translation containing a sequence of host instructions is obtained and stored in a translation buffer in the host memory. The conversion is transferred directly to the conversion buffer in the host memory via the gate storage buffer. Once the conversion is stored in the host memory, the conversion unit branches to the conversion and then executes it. This execution (and subsequent executions) makes a determination as to whether the conversion has made the correct assumptions regarding exceptions and memory. Prior to performing the conversion, set the T bit for the target page (s) containing the converted target instructions. This indication warns that the instruction has been translated and that this attempt will cause an exception if the write to the target address is attempted and that the translation may be invalidated or removed.
One additional hardware enhancement to the morph host is to replicate (ie, “alias”) data that is normally stored in memory but frequently used in performing operations into execution unit registers. This circuit is used to eliminate the time required for retrieving the data from the memory for each use. To do this in one embodiment, working within the execution unit 110 shown in FIG. Designed to respond to a “load and protect” command that copies memory data to register 111 and places its memory address in register 112 in that unit. It is the comparator 113 that works in conjunction with the address register. The comparator receives the load and store addresses to the gate store buffer that are directed to the memory being translated. An exception can occur if the memory address for either load or store is compared to the address in register 112 (or additional register in some embodiments). Code morphing software responds to this exception by verifying that the memory address and register hold the same correct data. In one embodiment, this is done by rolling back the translation and re-executing with no "alias" data in the execution register. Other possible ways to correct this problem include updating the registers with the latest memory data or updating the memory with the latest load data.
Those skilled in the art will appreciate that the host processor of the present invention can form a computer as shown in FIG. 9 when connected to circuitry having typical computer elements. As can be seen, when used in a modern X86 computer, the host processor is coupled to the memory and bus control circuitry via the processor bus. The memory and bus control circuitry is configured to provide access to main memory and cache memory available with the microprocessor. The memory and bus control circuitry also provides access to a bus, such as a PCI or other local bus, through which I / O devices can be accessed. The individual computer system relies on circuitry used with the microprocessor of the present invention that is replaced by the processor of the present invention.
To illustrate the operation of the processor of the present invention and the manner in which execution is accelerated, the conversion of a small sample of X86 target code into host source instructions is presented here. This sample demonstrates the conversion of X86 target instructions to morph host instructions and includes various examples of optimization, reordering, and rescheduling steps by the microprocessor of the present invention. By following the illustrated process, there is a significant difference between the operations required to execute the original instruction using the target processor and the operations required to perform the conversion on the host processor. Will be apparent to those skilled in the art.
The original instruction illustrated in C language source code describes a very short loop process. Essentially, while the variable “n” decremented after each loop is greater than “0”, the value “c” is stored at the address indicated by the pointer “* s”. The pointer “* s” is incremented after each loop.

Notation: [...] indicates the address expression for the memory operand. In the previous example, the address for the memory operand is formed by adding the contents of the register to the hexadecimal constant indicated by the Ox prefix. The target register is indicated with a% prefix. For example,% ecx indicates an exc register. The destination of the operation is the left side.

In the first part of this sample, each X86 assembly language instruction to perform an action defined by a C language statement is tabulated by an assembly language mnemonic for that action. This is followed by the parameters that are included in the primitive action. An explanation of the operation is also given in the comment for each instruction. The order of execution may differ from that shown in the target processor, but each of these assembly language instructions must be executed each time a loop is executed when executing the target C language instruction. Don't be. Therefore, if the loop is performed 100 times, each instruction shown above must be executed 100 times.

The next sample shows the same target primitive instruction executing a C language instruction. However, after each primitive target instruction, the primitive host instructions necessary to perform the same operation in one particular embodiment of the microprocessor of the present invention are summarized. In this microprocessor, the morph host is a VLIW processor designed as described herein. The host register shadowed by the official target register is indicated by “R” followed by the X86 register name. For example, Reax is a working register that works with the EAX official target register. Note that.

The next sample shows the addition of a host source instruction for each of the source target instructions so that the address required for the target operation can be generated by the code morphing software. Note that host address generation instructions are only required in microprocessor embodiments that use code morphing software for address generation instead of address generation hardware. In a target processor such as an X86 microprocessor, these addresses are generated using address generation hardware. Whenever an address occurs in such an embodiment of the present invention, a calculation is performed and a host source instruction is added to check the address value so that the calculated address is the appropriate X86 segment limit. Is determined to be within.

This sample adds two steps to each set of primitive host instructions to execute each primitive target instruction after executing the host instructions necessary to commit the uncommitted value in the gate storage buffer to memory, Illustrates updating the official target register. As seen in the sample, in each case, the length of the target instruction is added to the value in the working instruction pointer register (Reip). Next, a commit instruction is executed. In one embodiment, the commit instruction copies the current value of each working register shadowed to the associated official target register, stores a pointer value that specifies the gate location of the gate storage buffer, and stores the uncommitted Move them from immediately before and immediately after storing them, placing them in memory.
It will be appreciated that the list of instructions given at the end above is all of the instructions necessary to form a host translation of the original target assembly language instruction. If the conversion stops at this point, the number of primitive host instructions will be much more than the number of target instructions (perhaps six times more), and its execution will take longer than execution on the target processor there is a possibility. However, at this point, rearrangement, optimization, and rescheduling have not yet been performed.
If an instruction is run only once, the time required to perform further reordering and other optimizations may be longer than the time required to perform the conversion that exists at this point. In that case, in one embodiment of the present invention, the conversion is stopped at this point, the conversion is stored, and then it is executed to determine whether an exception or error occurs. In this embodiment, reordering and other optimization steps are performed only if it is determined that a particular transformation should be run or optimized a certain number of times. This is done, for example, by placing a host instruction in each conversion, counting the number of times the conversion has been performed, and generating an exception (or branch) when a certain value is reached. The exception (or branch) transfers the action to the code morphing software, which then performs some or all of the following optimizations and any additional that has been determined to be useful for the conversion Realize optimization. The second way to determine the number of times a transformation has been run and request optimization is to suspend the execution of the transformation at a certain frequency or based on certain statistical criteria, and any transformation running at that point is optimal It is to become. This ultimately seeks to optimize the most frequently run instructions. Another solution would be to optimize each particular type of host instruction, such as those that form loops and others that might run most frequently.

This sample illustrates the first stage of optimization that can be performed using the present invention. This optimization stage assumes optimal results, as do many other operations of the code morphing software. A particular optimization assumes that a target application program started as a 32-bit program written against the flat memory model provided by the X86 processor family will continue as such a program. Note that such assumptions are specific to the X86 family and do not necessarily apply to other processor families being emulated.
When this assumption is made, in the X86 application, all segments are mapped to the same address space. This makes it possible to remove the primitive host instructions required by the X86 segmentation process. As seen in the sample, first set the segment value to zero. Next, the base of the data is set to zero and the limit is set to the maximum available memory. Then, in each set of primitive host instructions for executing the target primitive instruction, both the segment base value check and the segment base address calculation necessary for segmentation become unnecessary. This reduces the loop that two host source instructions should execute for each target source instruction that requires an addressing function. At this point, there is still a host instruction check for the memory limit.
It should be noted that this optimization requires an inference that states that the application utilizes the 32-bit flat memory model. If this is not true, an error is found when the main loop resolves the control transfer destination and detects that the source assumption does not match the destination assumption. Then, a new conversion is required. This technique is very general and applies when the "mode" changes frequently, such as debug, system management mode, or "real" mode, in the case of various segmentation and other "moderation" Is possible.

This sample illustrates the next stage of optimization. In this case, speculative translation eliminates the upper memory boundary check, which is only required for unaligned pages that intersect the memory reference at the top of the memory address space. This assumption failure is detected by a hardware or software fix up. This reduces the translation by one host source instruction for each target source instruction that requires addressing. This optimization requires both the assumptions made above that the application utilizes the 32-bit flat memory model and the assumption that the instructions are consistent. If these are not true, the conversion will fail and a new conversion will be required.

This sample illustrates the following optimization. In this case, the common host representation is removed. That is, when converting the second target source instruction, the value in the working register Rebp (the working register representing the stack pace point register of the X86 processor) is added to the offset value 0x8, and the host working Place in register R2. Note that the same operation was performed when converting the target source instruction 5 in the previous sample, but the result of the addition was placed in the working register R5. As a result, the value placed in working register R5 already exists in working register R2 when host source instruction 5 is about to occur. Thus, the host add instruction can be removed from the conversion of the target source instruction 5 and the value in the working register R2 need only be copied to the working register R5. Similarly, the host instruction that adds the value in the working register Rebp to the offset value 0x10 can also be removed in the conversion of the target source instruction 8. This is because this step has already been done in the conversion of the target source instruction 6 and the result is in register R7. Note that this optimization does not depend on thought and therefore does not fail or retransform.

This example illustrates an optimization that assumes that the conversion of the primitive target instructions that make up the entire conversion can be done without generating an exception. If true, there is no need to update the official target register or commit the uncommitted storage in the storage buffer at the end of each sequence of host primitive instructions that execute individual target primitive instructions. If the guess is true, only the official target register needs to be updated at the end of the sequence of target source instructions, and the store need only be committed once. This makes it possible to remove two primitive host instructions for executing each primitive target instruction. They replace the official target register with a single host primitive instruction that commits the uncommitted store to memory.
It will be appreciated that this is another speculative action, which is also very likely to include a correct guess. This step provides a tremendous advantage over all prior art emulation techniques if the guess is true. This allows all of the primitive host instructions that execute the entire sequence of target primitive instructions to be aggregated into a single sequence in which all of the individual host primitive instructions can be optimized together. This has the advantage that many operations can be run in parallel on a morph host using ultra-long instruction word technology. This also allows for a larger number of other optimizations. This is because there are more options for such optimization. Furthermore, however, if the guess is found to be not true and an exception occurs during the execution of the loop, the official target register and memory retain the state of the official target that existed at the beginning of the sequence of target source instructions. is doing. This is because no commit occurs until the host instruction sequence is actually executed. All that is needed to recover from the exception is to clear the uncommitted store, roll back the official register to the working register, and start the conversion of the target source instruction again at the start of the sequence. In this reconversion, the conversion is performed one target instruction at a time, the host sequence representing each target source instruction is converted, and then the official state is updated. Next, this conversion is performed. If an exception occurs during this reconversion, the correct target state can be immediately obtained in the official target register and memory to execute the exception.

This summary illustrates the sequence of host primitive instructions remaining at this point in the optimization process. Although this example shows maintaining the target instruction pointer (EIP) inline, it is possible to keep the pointer EIP for branching off-line during translation. In this case, the pointer EIP update sequence can be removed from this step and the subsequent steps of this example.

This sample shows the next step of optimization, usually called register renaming. Here, operations that require a working register that is used for one or more operations in a sequence of host primitive instructions have been modified to use different unused working registers, and two host instructions can use the same hardware Eliminate the possibility of needing Thus, for example, in the previous two samples, the second host primitive instruction uses a working register Recx that represents the official target register ECX. The tenth host primitive instruction also uses the working register Recx. By changing the operation in the second host source instruction and storing the value indicated by the address in R0 in the working register R1, not in the register Recx, the previous two host instructions both use the same register The situation to do is avoided. Similarly, the fourth, fifth, and sixth primitive instructions all use the working register Reax in the previous sample. Change the fourth host source instruction to use the previously unused working register R3 instead of the working register Reax, and change the sixth host source instruction to replace the register Reax. By utilizing the previously unused working register R4, these hardware dependencies are eliminated.

This sample demonstrates host primitive instruction scheduling for execution on a morph host. In this example, the morph host is assumed to be a VLIW processor and, in addition to the hardware enhancements provided for cooperating with the code morphing software, among other processing units, two arithmetic and logic (ALU) The unit is included. The first line shows two separate add instructions scheduled to run together on the morph host. As seen in the sample, these are the 3rd and 8th primitive host instructions in the sample just before the previous summary. The second row contains a NOP (no action but proceed to next instruction) instruction and another add instruction. The NOP instruction indicates that there are not always two instructions that can be run together even after some scheduling optimization. In any case, this sample shows that at this point, only 9 sets of primitive host instructions are left to execute the original 10 target instructions.

This sample essentially illustrates the same set of host primitive instructions, except that the instructions are now stored in the translation buffer and executed one or more times. This is because the last jump (jp) instruction here shows the jump address given by chaining to another sequence of translated instructions. If the sequence conversion has been completed, the chain process takes out a sequence of instructions from the main loop of the conversion unit.

This example illustrates an advanced optimization step that is mostly used only in sequences that are repeated many times. This process first detects the transformations that form the loop and examines each original host instruction to determine the instructions that produce a constant result within the loop body. These instructions are removed from the loop body and executed only once to place a value in the register. From that point on, the value stored in this register is used and the instruction is not run again.

When these non-repeating instructions are removed from the loop and the sequence is scheduled for execution, the scheduled instruction looks like this last sample. The first instruction is executed, but only once during the first iteration of the loop, after which only the host primitive instructions remaining in the seven clock intervals shown are executed during the loop. I understand that. Therefore, the execution time has been reduced from 10 instructions required to execute the primitive target instruction to 7 instruction intervals.
As can be seen from the sample, the step removed from the loop is the address generation step. Therefore, in the present invention, address generation need only be performed once per loop call. That is, the address generation needs to be performed only once. On the other hand, the address generation hardware of the X86 target processor must generate these addresses each time the loop is executed. If the loop is executed 100 times, the present invention generates an address only once, whereas the target processor will generate each address 100 times.

This allows variables to be safely moved from memory to registers. Demonstrates the use of morph host register alias detection hardware. The starting point is the code after “reverse code movement”. This represents an optimization that can remove the load.
Perform a load first. The address is protected by the alias hardware, and an "alias" exception occurs when a store is made to this address. Next, the load in the loop body is replaced with a copy. Release the alias hardware after the body of the loop.

This sample illustrates further optimization and can be performed by the microprocessor of the present invention. Referring back to the sample two samples prior to this sample, you will notice that the first three add instructions involved the calculation of addresses on the stack. These addresses do not change during the sequence of host operations. That is, the values stored at these addresses may be loaded into registers that can be retrieved from memory and obtained immediately for execution. As seen in the sample, this is done in host primitive instructions 6, 8, and 10. In instructions 7, 9 and 11, each of the memory addresses is marked as protected by special host alias hardware, and the registers are shown as aliases for these memory addresses. Any attempt to modify that data will cause an exception. In this regard, each of the load operations involving data movement from these stack memory addresses results in a simple register-to-register copy operation that progresses much faster than a load from a memory address. Note that once the loop has been executed until n = 0, the protection must be removed from each of the memory addresses so that the alias register is available for others.

This sample shows the next stage of optimization. Here, it is recognized that most of the copy instructions replacing the load instructions in the optimization shown in the last sample are unnecessary and may be excluded. That is, when an inter-register copy operation is performed, data before the operation exists in the original register from which data was copied. In this case, the data can access the first register, not the register to which it was copied, and the copy operation can be eliminated. As can be seen, the first, second, fifth and ninth primitive host instructions shown in the last sample loop are removed. In addition, the registers used for other host source instructions are also changed to reflect the correct registers for the data. Thus, for example, if the first and second copy instructions are removed, the third store instruction copies the data from the working register Rc (not register R1) where the data is present, and the working register Rs (register R3). The data must be placed at the address indicated in The working register Rs has its address.

The upper sample shows the host instruction after scheduling. Note that this sequence requires fewer clocks to execute the loop than to execute the original target instruction originally decoded from the source code. Thus, apart from all the other accelerations that have taken place, the total number of times that the combined operation is run is simply less than that required to execute the original target code.

The final optimization shown in this sample is the removal of storage by using alias hardware. This removes the storage from within the loop body and performs them only at the loop knot. This reduces the number of host instructions in the loop body to 3 compared to the original 10 target instructions.
Although the present invention has been described with reference to preferred embodiments, it will be appreciated by those skilled in the art that various changes and modifications can be made without departing from the spirit and scope of the invention. For example, although the present invention has been described with reference to emulation of an X86 processor, the present invention is similarly implemented on programs designed for other processor architectures and virtual machines such as P-code, Postscript, or Java programs. It will be understood that this also applies to programs that Accordingly, the present invention should be construed in accordance with the following claims.

Claims (26)

A host Hadoue A or Ranaru microprocessor for executing the conversion software directly,
The host hardware is morph host hardware;
The conversion software is
A procedure for converting a plurality of target instructions of a program written for a processor having a first instruction set into a plurality of primitive instructions executable on the morph host hardware;
Storing the plurality of primitive instructions in a conversion buffer as a plurality of host conversions;
A procedure that is called from the conversion buffer by the morph host hardware and can be executed any number of times.
A microprocessor characterized by being code morphing software including: 2. The microprocessor according to claim 1 , wherein the code morphing software further includes a processing procedure for reordering, rescheduling and optimizing the plurality of primitive instructions. The microprocessor of claim 1 , wherein the morph host hardware is
A storage buffer for data transferred to memory,
Means for committing data stored in the storage buffer to memory in response to execution without exception of the host conversion;
Means for dumping data in the storage buffer without committing to memory in response to the occurrence of an exception or error during execution of the host translation;
A storage buffer containing
An execution unit,
A set of work registers in the execution unit that are larger than the set of registers required by the target processor in the execution unit of the target processor;
A set of target registers that hold the target processor's official register state that is generated when processing the target program;
An execution unit comprising
The code morphing software
Transferring status from the set of work registers to the set of target registers in response to executing the host conversion without exceptions or errors during execution of the host conversion;
Transferring a state from the set of target registers to the set of work registers in response to the occurrence of an exception or error during execution of the host translation;
A microprocessor comprising: The microprocessor of claim 3 , wherein
During the execution of the host conversion, the step of transferring state from the set of work registers to the set of target registers in response to execution of the host conversion without exceptions or errors comprises a commit instruction;
In response to the occurrence of an exception or error during execution of the host translation, the step of transferring state from the set of target registers to the set of work registers comprises a rollback instruction;
In response to execution without exception of the host conversion, the means for committing data stored in the storage buffer to memory is responsive to the commit instruction and to the occurrence of an exception or error during execution of the host conversion. And the means for dumping data in the storage buffer functions in response to the rollback instruction without committing to memory.
A microprocessor characterized by that. 4. The microprocessor of claim 3 , wherein said morph host hardware comprises means for indicating that the target instruction has been translated. 4. A microprocessor according to claim 3, wherein said means for indicating completion of conversion of the target instruction includes an address conversion cache for storing an instruction indicating that conversion of the target instruction has been completed. 4. A microprocessor according to claim 3 , wherein the morph host hardware comprises means for indicating whether the instruction is normal or abnormal. 7. The microprocessor according to claim 6, wherein said means for indicating whether the instruction is normal or abnormal includes an address translation cache for storing an instruction indicating that the target instruction has been translated. 4. The microprocessor of claim 3 , comprising means for indicating that the morph host hardware has moved data at a memory address to a register. 10. The microprocessor of claim 9 , wherein said means for indicating that data at a memory address has been moved to a register includes means for storing an indication that data at said address has been moved to a register, and an address to execute A microprocessor comprising means for comparing the address with the address of the data moved to the register. The microprocessor of claim 1 , wherein the morph host hardware comprises a very long instruction word microprocessor. A microprocessor for a host computer designed to execute a target application program for a target computer having a target instruction set ,
Is designed to execute the instructions of the Hajime Hara instruction set, made morph host processing Hadoue A or et al. To run the code-morphing software directly,
The code morphing software and the morph host processing hardware are:
Means for inferring the occurrence of a condition and converting a set of target instructions into a plurality of instructions in a source instruction set;
Means for determining, under the control of the code morphing software, an official state of the target computer that was present at the start of conversion of a set of target instructions during execution of the target program by the microprocessor; ,
Means for updating the state of the target computer from the state of the host computer when executing a set of primitive instructions in response to the guess;
Means for detecting that the condition was not satisfied during execution of the set of primitive instructions;
Means for updating the state of the host computer from the state of the target computer if a set of primitive instructions fails to execute in response to the guess;
Means for converting a new set of primitive instructions without using the guess if a set of primitive instructions fails to execute in response to the guess;
A microprocessor comprising: 13. The microprocessor for a host computer according to claim 12 , further comprising means for inferring occurrence of a certain condition and optimizing a plurality of instructions of the source instruction set converted from the target program. A microprocessor for host computers. 13. The microprocessor for a host computer according to claim 12 , wherein said means for inferring occurrence of a condition and converting a set of target instructions into a plurality of instructions of a source instruction set converts the set of instructions. A microprocessor for a host computer that is presumed that no exceptions or errors will occur in it. 13. The microprocessor for a host computer according to claim 12 , wherein said means for determining an official state of said target computer existing under the start of conversion of a set of target instructions under the control of said code morphing software. A host computer microprocessor comprising: means for storing an official state of the target computer that existed at the start of conversion of a set of target instructions. 16. The microprocessor for a host computer according to claim 15 , wherein said means for storing an official state of said target computer that existed at the start of conversion of a set of target instructions comprises a set of target registers. A microprocessor for a host computer. 16. The microprocessor for a host computer according to claim 15 , wherein means for updating the state of the target computer from the state of the host computer when executing a set of primitive instructions in response to the guess. A host computer microprocessor comprising: means for transferring a host state to said means for storing an official state of said target computer when a primitive instruction is executed without error or exception. 13. The microprocessor for a host computer according to claim 12 , wherein said means for detecting that said condition is not satisfied during execution of said set of primitive instructions comprises means for generating an exception. Microprocessor for host computer. 19. A microprocessor for a host computer according to claim 18 , wherein said means for generating an exception is a hardware means. 19. A microprocessor for a host computer according to claim 18 , wherein said means for generating an exception is a software means. A microprocessor for a host computer according to claim 12 ,
The means for updating the state of the host computer from the state of the target computer if a set of primitive instructions failed to execute according to the guess was present at the start of conversion of the set of target instructions A microprocessor for a host computer, comprising means for transferring an official state of a target computer and updating the host state. A microprocessor for a host computer according to claim 12 ,
If a set of primitive instructions fails to execute according to the guess, the means for converting a new set of primitive instructions without the guess is present at the start of conversion of the failed set of target instructions A microprocessor for a host computer, comprising means for converting each target instruction in order starting from the target instruction that has been executed and saving the host state as the official state of the target computer. A target program designed to be executed by a target computer having the target instruction set is executed on a host computer having a host processor capable of executing instructions from a source instruction set different from the target instruction set A method,
Storing the state of the target computer as existing at the start of conversion of the target instruction;
Converting a plurality of target instructions that command an operation into a set of primitive instructions for executing the operation commanded by the target instruction on the host processor;
Storing the plurality of primitive instructions in a conversion buffer as host conversion;
Performing the host conversion on the host processor;
Updating the stored state for the target computer from the state of the host computer if execution of the host conversion does not cause an exception or error; and
Updating the state of the host computer from the stored state of the target computer if execution of the host conversion generates an exception or error; and
A target program execution method comprising: 24. The target application program execution method according to claim 23 , comprising the additional step of optimizing and rescheduling the plurality of primitive instructions before storing the set of primitive instructions as a host translation. A method for executing a target application program. A target application program execution method according to claim 23 , comprising:
Without reordering, optimizing, or rescheduling the primitive instructions to generate a primitive instruction, each target instruction that commands a certain action is replaced by each target instruction of the action that is commanded by the target instruction. An additional step of converting to a set of primitive instructions for execution on the host processor;
An additional step of storing each set of primitive instructions as a host conversion in the conversion buffer upon completion of conversion of each set of primitive instructions;
An additional step of storing and updating the state of the host computer after converting each target instruction into a set of primitive instructions;
Executing each primitive instruction on the host processor;
An additional step of updating the state stored for the target computer from the state of the host computer if execution of the host conversion does not cause an exception or error;
If an exception or error occurs due to execution of the primitive instruction, an additional step of capturing any exception or error that occurred,
A method for executing a target application program, comprising: 24. The target application program execution method according to claim 23 , wherein when the set of primitive instructions is to be re-executed frequently, a plurality of primitives are stored after storing the set of primitive instructions as host translation. A method of executing a target application program comprising the additional steps of optimizing and rescheduling instructions.

Images