JP2004280795A - エクストリームパイプライン及び最適化再配列技術 - Google Patents

Abstract

【課題】 レガシープロセッサのバイナリコードをネイティブプロセッサに対して実行可能なバイナリコードに直接変換するバイナリ変換プログラムを提供する。
【解決手段】 レガシープロセッサ用に書かれたバイナリ命令をネイティブプロセッサ用の実行可能バイナリ命令に直接変換するためのバイナリ変換プログラム。本バイナリ変換プログラムは、バイナリ変換プログラムを異なるレガシープロセッサ及び／又はオペレーティングシステム、及びネイティブプロセッサと共に使用することを可能にする再設定可能な変換プログラムとして構成される。バイナリ変換プログラムはまた、より効率的なネイティブプロセッサの命令を利用するように最適化され、レガシーバイナリコードの一部分を使用不可にし、及び／又はレガシーバイナリコードを変更することなく新しいネイティブ命令をアプリケーションプログラムに追加することを可能にする。
【選択図】 図２

Description

本発明は、レガシープロセッサのバイナリコードをネイティブプロセッサに対して実行可能なバイナリコードに直接変換するバイナリ変換プログラムに関し、より詳細には、異なるレガシープロセッサ及び／又はオペレーティングシステムと共に使用するのに適し、また、レガシーコードを静的、動的、又はジャストインタイムに変換することができ、レガシーコードが新しいコードを挿入するか、又はレガシーバイナリコードを変更することなくレガシーコードの一部分を使用不可にすることを可能にする、異なるネイティブプロセッサと共に使用するのに適する再設定可能変換プログラムとして形成されたバイナリ変換プログラムに関する。

マイクロプロセッサは、異なる命令セットアーキテクチャ（ＩＳＡ）から構成されることが公知である。「ＩＳＡ」は、特定のマイクロプロセッサの命令セットを判断する。マイクロプロセッサにより実行されるアプリケーションプログラムは、通常、ソースコードとして公知の例えば「Ｃ」又は「Ｃ＋＋」のような比較的高水準の言語で書かれ、特定マイクロプロセッサの命令セットと互換性のあるマシンインストラクションにコンパイルされる。マシンインストラクションは、バイナリコード、オブジェクトコード、及び実行可能コードとして公知である。

現存する多くのマイクロプロセッサの寿命や旧式化及びそれ相応の低速度のために、本明細書において以後「レガシーマイクロプロセッサ」及び「レガシープロセッサ」と呼ぶ現存する時代遅れのマイクロプロセッサを本明細書において以後「ネイティブマイクロプロセッサ」及び「ネイティブプロセッサ」と呼ぶ新しくより高速のマイクロプロセッサと交換することが必要な場合が多い。残念なことに、アップグレードによっては、多くの場合、ネイティブプロセッサの命令セットは、レガシープロセッサの命令セットと互換性がない。従って、レガシープロセッサ用に書かれたアプリケーションプログラムをより新しいネイティブプロセッサ上で利用することを可能にする様々な技術が開発されてきた。例えば、ソフトウエアエミュレータが公知である。そのようなソフトウエアエミュレータは、アプリケーションプログラムで使用されるレガシープロセッサの様々なマシンコード命令のエミュレーションに基づいている。そのようなエミュレータは、エミュレートされているレガシー命令と同じ機能を達成するために、１つ又はそれ以上のネイティブ命令から形成されたソフトウエアハンドラを含むことが公知である。そのような命令エミュレータシステムの例は、本出願人所有の米国特許第６，０４１，４０２号、第６，２１２，６１４号、及び第６，２７２，４５３号、及び、２００３年３月６日出願（ドケット番号第２０−０１６９号）の「直接命令レンダリングエミュレーションコンピュータ技術」という名称の本出願人所有の米国特許出願一連番号第（未定）号に開示されている。

バイナリ変換プログラムが必要なことがある理由はいくつかある。第１に、現代のコンピュータアーキテクチャに対してソフトウエアポートを容易にするのにレガシーソースコードが利用可能ではない場合がある。第２に、従来のエミュレーションシステムに付随するソフトウエアオーバーヘッドは、処理速度を大幅に遅くする。従って、バイナリ変換は、より新しく互換性のないハードウエアプラットフォーム上でのレガシーコードの再使用のための唯一の実現可能な選択肢である。

そのようなバイナリ変換プログラムは、レガシープロセッサのバイナリコードをネイティブプロセッサのバイナリ命令に直接変換する。そのようなバイナリ変換プログラムの例は、米国特許第６，２２３，３３９号、第６，３１４，５６０号、及び第６，５０２，２３７号に開示されている。バイナリ変換プログラムはまた、米国カリフォルニア州サンホセにおいて１９９７年２月２３〜２６日に開催された米国電気電子学会（ＩＥＥＥ）のコンピュータ代表者会義９７会報３７〜４２ページに掲載のデジタル・エキップメント・コーポレーションのＲ・フックウェイ著「Ａｌｐｈａ ＮＴ上の３２ビットｘ８６アプリケーション上で作動するデジタルＦＸ！３２」、２００１年１１月のＩＥＥＥ会報第８９巻１１号１７１０〜１７２２ページに掲載のアルトマン他著「バイナリ変換及び最適化における進歩と将来の課題」、デジタル技術学会誌１９９７年第９巻１号１〜１２ページに掲載のフックウェイ他著「デジタルＦＸ！３２：エミュレーション及びバイナリ変換の結合」、及び、コンピュータマガジン２０００年３月第３３巻４７〜５２ページに掲載のチエン他著「ＩＡ−６４に対するＰＡ−ＲＩＳＣ：再コンパイルのない透過性実行」に開示されている。

公知のバイナリ変換プログラムは、レガシーバイナリコードを変更することなくレガシーバイナリコードをネイティブバイナリコードに実質的に変換することが可能であるが、そのような公知のバイナリ変換プログラムに付随する問題が存在する。例えば、大抵の公知のバイナリ変換プログラムは、単一のレガシー／ネイティブプロセッサとオペレーティングシステムとの組合せ用に開発されたものである。従って、異なるレガシープロセッサ及び／又はネイティブプロセッサ上で実行されるアプリケーションプログラムには、別の変換プログラムが必要になることになる。それに加えて、そのような公知の変換プログラムは、本来のソースコードへのアクセスを必要とすると考えられる、レガシーコードの一部分を使用不可にするか又はプログラムを再コンパイルする必要なくそれを強化する目的による現代のプログラム言語で書かれた新しいネイティブコードの追加を考慮しない。すなわち、複数のレガシープロセッサ及びネイティブプロセッサ、及び／又はオペレーティングシステムと共に使用するのに適しており、レガシー及びネイティブの両方の命令レベルでモジュール式に最適化することができ、かつレガシープログラムを再コンパイルする必要なく新しいネイティブコードの追加を考慮した、レガシーバイナリ命令をネイティブ命令に変換するバイナリ変換プログラムの必要性が存在する。

本発明は、レガシープロセッサ用に書かれたバイナリ命令をネイティブプロセッサ用の実行可能バイナリ命令に直接変換するためのバイナリ変換プログラムに関する。本発明の重要な態様によると、このバイナリ変換プログラムは、バイナリ変換プログラムをレガシープロセッサ及び／又はオペレーティングシステムとネイティブプロセッサとの異なる組合せで使用することを可能にする再設定可能な変換プログラムである。バイナリ変換プログラムはまた、より効率的なネイティブプロセッサの命令及び機能をそれらが利用可能な場合は利用するように最適化され、レガシーバイナリコードの一部分を使用不可にし、及び／又はレガシーバイナリコードを変更することなく新しいネイティブ命令をアプリケーションプログラムに追加することを可能にする。
本発明の上記及び他の利点は、以下の詳細と添付図面を参照することにより容易に理解することができるであろう。

本発明は、レガシーマイクロプロセッサのバイナリ命令をネイティブプロセッサのバイナリ命令に直接変換することができる再設定可能変換プログラムとして形成されるバイナリ変換プログラムに関する。レガシーマイクロプロセッサのバイナリ命令の直接変換により、一般にエミュレートされたレガシー命令よりも相当に高速で実行されるネイティブのバイナリ命令がもたらされる。それに加えて、本発明の重要な態様によると、システムは、複数のネイティブプロセッサ、複数のレガシープロセッサ、及びオペレーティングシステムと共に使用するために再設定することができる。変換されたネイティブプログラムの柔軟性を更に強化するためにサンク（ｔｈｕｎｋ）オブジェクトが使用され、レガシーバイナリ命令の一部分を使用不可にし、及び／又は、本来のレガシーバイナリコードを変更することなく新しいネイティブ命令が挿入される。以下に更に詳細に説明するように、本発明によるバイナリ変換プログラムは、第１に、連続して実行するコード区分にレガシー命令をグループ分けしてアルゴリズム的最適化を適用し、次に、バイナリ命令を命令毎にネイティブ命令のセットに変換することにより、レガシーバイナリ命令をネイティブバイナリ命令に変換する。命令変換が終了すると、必要に応じてネイティブオプティマイザーを実行することもできる。ネイティブプロセッサに依存して、ネイティブバイナリ命令を再配列、及び／又はグループ分けすることができ、プロセッサリソースの全ての可能な利点を利用することができる。従って、得られるネイティブバイナリは、ネイティブプラットフォーム上で単独で実行することができる。

本発明によるバイナリ変換プログラムは、３つの異なる作動モード、すなわち、変換がオフラインで実行されてネイティブ命令の新しい実行可能バイナリを生成する静的変換モード、レガシーバイナリがネイティブプロセッサのメモリに配置される間に変換が実行される動的変換モード、及び、レガシー命令が最初に実行される時に必要な場合及びその時に限って変換されるジャストイン変換モードで作動する。

本発明によるバイナリ変換プログラムは、再設定可能な変換プログラムとして様々なレガシー及びネイティブプロセッサと共に使用するために形成されるが、本発明の例示的実施形態は、「Ｔｒｕ６４ Ｕｎｉｘ」オペレーティングシステムを備えた「Ａｌｐｈａ ２１２６４」マイクロプロセッサ、及び「Ｌｉｎｕｘ」オペレーティングシステムを備えた「Ｉｎｔｅｌ ＩＡ−６４」ネイティブプロセッサである。「Ａｌｐｈａ ２１２６４」及び「ＩＡ−６４」マイクロプロセッサは、両方とも６４ビットのプラットフォームである。「Ａｌｐｈａ ２１２６４」マイクロプロセッサは、縮小命令セットコンピュータ（ＲＩＳＣ）である。「ＲＩＳＣ」アーキテクチャから成るマイクロプロセッサは、一般にレジスタ内の全ての演算を実行する。読込み及び記憶の命令が使用され、データをレジスタ内に取出し、その結果をメモリに返して記憶する。そういうわけで、「ＲＩＳＣ」アーキテクチャは、「読込み／記憶」アーキテクチャとして公知である。「ＲＩＳＣ」アーキテクチャはまた、複雑な命令を除去してハードウエアが複雑になることを軽減する。現代のソフトウエアの設計パラダイムは、高次オーダー言語の使用を促進し、コンパイラは、通常は複雑な命令を使用しない。

「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサは、明示的並列命令コンピュータ（ＥＰＩＣ）と呼ばれる比較的新しい設計パラダイムを使用する。「ＥＰＩＣ」アーキテクチャは、最適な機能のためのスケジューリング命令はコンパイラ（すなわち、アセンブリ言語プログラマー）により実行されるべきであり、マイクロプロセッサハードウエアにより実行されるべきではないと命令する。「ＩＡ−６４」プロセッサは、プロセッサ性能の問題の範囲を除去又は緩和するための機能を使用する。例えば、そのような「ＩＡ−６４」プロセッサは、比較的大きなレジスタのセット、短い前方分岐を解消する能力、及び並列コードの実行を促進するために比較的多数の実行ユニットを含む。「ＩＡ−６４」マイクロプロセッサは、成長するマイクロプロセッサ族を含む。以下の説明は、「Ｉｔａｎｉｕｍ ２」として公知のタイプ「ＩＡ−６４」プロセッサに関する。

アプリケーションソフトウエアモデル
図１を参照すると、現代のソフトウエアアプリケーション用の階層型モデルが示されている。このモデルは、アプリケーションソフトウエア層２０、システムライブラリ層２２、オペレーティングシステム層２４、及びハードウエア層２６を含む。現代のソフトウエアアプリケーションプログラム２０は、通常、特定マイクロプロセッサのアーキテクチャ及びオペレーティングシステム上で実行されるように書かれている。図示のように、アプリケーションソフトウエア２０は、マイクロプロセッサのオペレーティングシステム２４、及び一組のシステムライブラリ２２のサービスを使用して共通の作業を実行する。特に、アプリケーションソフトウエアは、矢印２８で示されるように、オペレーティングシステムコールを直接呼び出すことができるが、より一般的には、矢印３０で示されるように、システムライブラリコールを通じてシステムライブラリ層２２とインタフェースを取る。次に、矢印３２で示されるように、システムライブラリ２２は、通常、システムコールをオペレーティングシステム層２４に呼び出す。例えば、標準の「Ｃ／Ｃ＋＋」システムライブラリ層２２は、「Ｃ」機能を使用してディスクファイルを演算する能力を有する。これらの機能は、次に、システムコールを通じてオペレーティングシステムと対話する。以下に更に詳細に説明するように、本発明によるバイナリ変換プログラムは、根底をなすオペレーティングシステムとインタフェースを取るが、レガシー及びネイティブのオペレーティングシステムが同じであることを必要としない。

バイナリ変換プログラムのサブシステム
図３を参照すると、本発明によるバイナリ変換プログラムは、４つのモジュール式の再設定可能サブシステム、すなわち、ローダーサブシステム３４、レガシー命令プロセッササブシステム３６、命令変換プログラムサブシステム３８、及びネイティブ命令プロセッササブシステム４０で形成される。それぞれのサブシステム３４、３６、３８、及び４０は、例えば「Ｃ＋＋」で書かれたモジュラーオブジェクトである。従って、サブシステム３４、３６、３８、及び４０のいずれも、特定ネイティブプロセッサのアーキテクチャ、又はレガシープロセッサのアーキテクチャ、又はその両方のいずれかに関して設計することができる。従って、本発明によるバイナリ変換プログラムは、特定のレガシー／ネイティブプロセッサの組合せ用に構成された公知のバイナリ変換プログラムと違って、任意のレガシー又はネイティブプロセッサ用に構成されるように再設定することができる。

それぞれのサブシステムの詳細は以下に説明される。ただし、一般的に、ローダーサブシステム３４は、レガシーコード及びデータ部分をレガシーバイナリファイルから読み込む。レガシー命令プロセッササブシステム３６は、レガシー命令を分類してレガシープログラムをレガシー手順に細分する。それに加えて、全ての事前変換された最適化モジュールは、それらが存在してアクティブな場合は呼び出される。命令変換プログラムサブシステム３８は、レガシー命令をネイティブ命令に変換する。ネイティブ命令プロセッササブシステム４０は、事後変換最適化モジュールがあればそれらを呼び出し、結果的に完全に変換されたプログラムを後で実行するために、ネイティブプロセッサのメモリ又はディスクファイルに書き込む。

本発明によるバイナリ変換プログラムにより、更に、コード最適化モジュールは、サブシステム３６又は４０のいずれかにプラグ接続され、システムの性能を更に向上させることができる。図９を参照すると、これらのモジュールは、参照番号６４及び６６で識別されている。事前変換されたレガシーコード、又は事後変換されたネイティブコード、又はその何らかの組合せのいずれかで作動可能な任意数の最適化モジュールが存在してもよい。必要であれば、最適化モジュールは無効にすることができる。

本発明によるバイナリ変換プログラムにより、変換されたレガシーコードストリームに新しいネイティブコードを挿入することもできる。これらの新しいネイティブコードセグメントは、「サンク（ｔｈｕｎｋ）」と呼ばれる。図２にサンク４２が示されている。これらのサンク４２は、例えば、新しい機能を追加するか又は本来のレガシーコードの一部分を使用不可にするような様々な目的の現存するレガシーバイナリコードを変更することなく、機能を追加するために使用することができる。図２のように、ネイティブ命令グループ４４、４６、及び４８の３つのブロックが示されている。サンクコードは、ネイティブ命令コード４４からベクトルを通じてサンクオブジェクト４２に挿入される。サンクオブジェクト４２内のサンクコードが実行され、サンクコードの実行が終了すると、図２に示すように、システムは、ネイティブ命令グループにベクトルで戻る。

ローダーサブシステム
上述の通り、ローダーサブシステム３４は、レガシーバイナリファイルを読み込み、レガシーコード及びデータ部分を抽出する。ローダーサブシステム３４は、プラグ接続が可能なシステムであり、多くのファイルフォーマットに適合することができる。上述した例示的レガシープロセッサ及びオペレーティングシステムに対して、例示的ローダーは、「Ｌｉｎｕｘ」実行可能なリンク可能フォーマット（ＥＬＦ）と「Ｔｒｕ６４ Ｕｎｉｘ」共通オブジェクトファイルフォーマット（ＣＯＦＦ）とを含む。

ローダーサブシステム３４は、僅かに数個のインタフェースを通じてバイナリ変換プログラムの残りとインタフェースを取る。図４は、「Ｌｉｎｕｘ」オペレーティングシステムを装備した「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサへの「Ｔｒｕ６４」オペレーティングシステムを装備した「Ａｌｐｈａ」レガシーマイクロプロセッサの命令の変換に使用する例示的な統合モデル化言語（ＵＭＬ）のシーケンス図を示す。

レガシー命令プロセッササブシステム
レガシー命令プロセッササブシステム３６は、レガシー命令を解析し、それらを一般的な機能に従って入力し、命令をレガシーコードの機能ブロックに細分化する。レガシー命令プロセッササブシステム３６は、制御を解除する前に、利用可能でありアクティブにされた任意の目標とするレガシーオプティマイザーを呼び出すことができる。レガシー命令プロセッササブシステム３６は、システムが実行されているネイティブプロセッサに左右されない。

レガシー命令プロセッササブシステム３６は、レガシープログラムを、呼び出されたレガシー手順のセグメントに細分化する。レガシー手順は、分岐命令のようなレガシーフロー制御命令で終了するレガシー命令のセグメントである。各レガシー命令は、「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」と名付けられたコンテナーオブジェクト内に配置される。「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」オブジェクトは、「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトに記憶される。以下に詳細に説明するように、後の段階で「ＮａｔｉｖｅＩｎｓｔｒｕｃｔｉｏｎｓ」が「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトに追加される。

各レガシー命令オブジェクトは、レガシーバイナリ命令、及び、全体的なタイプとそれをネイティブプロセッサ命令に変換する方法とを含む命令に関する情報を含む。コンテナーオブジェクトは、次に、変換及び最適化のための別のサブシステムに使用することができる。レガシー手順オブジェクトは、全て、レガシープログラムオブジェクト内に包含される。
レガシー命令プロセッサ３６は、モジュラーサブシステムであり、別のレガシープロセッサと互換性があるように再設定することができる。これは、「Ｃ＋＋」オブジェクト指向の技術により実行することができる。

レガシー命令を分類して入力した後に、レガシープロセッササブシステム３６は、現存するいくつかの最適化モジュールが実行のために選択される前に任意の目標とする事前変換最適化モジュールを呼び出す。事前変換最適化モジュールは、レガシー命令と共に機能し、それらを使用不可にし、増強し、又は事後変換オプティマイザーと共に機能してより高性能なコードを生成することができる。

命令変換プログラムのサブシステム
命令変換プログラムサブシステム３８は、レガシープロセッサ命令をネイティブプロセッサ命令に変換する。このサブシステム３８は、レガシー及びネイティブプロセッサアーキテクチャに左右されない。このサブシステム３８は、他のサブシステムから呼び出され、次の２つの主要な機能を実行する命令変換オブジェクトを包含する。
・命令の入力：レガシー命令プロセッサ３６は、レガシー命令を入力するための命令入力を使用する。この機構は、それがレガシーフロー制御命令に遭遇した時にレガシー命令プロセッサに対して指示し、事前変換オプティマイザーにより必要とされることがある入力情報を提供する。
・命令の変換：ネイティブ命令プロセッササブシステム３６は、このサービスを使用して、レガシー命令により要求される演算を実行するネイティブプロセッサ命令を生成する。
命令変換プログラムサブシステム３８は、最終的に全てのレガシー命令をネイティブ命令に変換する役割を担う。

「Ａｌｐｈａ」レガシーマイクロプロセッサのバイナリ命令が「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサに対して適切なバイナリ命令に変換される本発明の例示的実施形態において、命令変換プログラムサブシステム３８は、必要な「ＩＡ−６４」ネイティブプロセッサ命令を生成するために各「Ａｌｐｈａ」レガシー命令に１つの一連の「Ｃ」機能で実行される。これらの「Ｃ」機能は、以下においてレガシー命令変換プログラムと呼ばれる。それに加えて、必要な「ＩＡ−６４」レガシーネイティブプロセッサ命令の各々に１つの一連の「Ｃ」機能は、レガシー命令変換プログラム内から使用することができる。これらの「Ｃ」機能は、以下においてネイティブ命令生成プログラムと呼ばれる。

ネイティブ命令プロセッサのサブシステム
ネイティブ命令プロセッササブシステム４０は、レガシー命令をネイティブ命令に変換することを要求し、任意の目標とするネイティブ命令最適化モジュールを呼び出し、変換バイナリコードをネイティブプロセッサのメモリ又は後で実行されるファイルに書き込む。
ネイティブ命令オブジェクトが使用されて、レガシー手順の挙動を複製するために必要なネイティブ命令を保持する。レガシー手順のために必要なネイティブ命令オブジェクトの数は、レガシー手順の挙動を複製するために必要なネイティブ命令の数が変動するので、レガシー命令オブジェクトの数と一致する場合もあり一致しない場合もある。ネイティブ命令オブジェクトの全ては、集合的に、変換されたバイナリプログラムの命令部分である。
ネイティブ命令プロセッササブシステム４０は、完全に再設定可能であり、様々な異なるネイティブプロセッサ上でレガシーバイナリを実行することを可能にする。このサブシステム４０は、使用されているレガシープロセッサに左右されない。

上述の通り、命令変換プログラムサブシステム３８を通じた命令変換は、ネイティブ命令プロセッササブシステム４０により呼び出される。この処理は、既に作り出されたレガシー手順オブジェクトを、変換されたホストプロセッサ命令を含むある数のネイティブ命令オブジェクトで埋める段階を伴う。事後変換オプティマイザーがネイティブ命令混合を変更する可能性があるので、ネイティブ命令は、この時点ではメモリ又はファイルに記憶されない。
各レガシー命令が１つ又はそれ以上のプロセッサ命令に変換された後に、存在する任意の事後変換オプティマイザーが呼び出される。これらのプラグ接続可能モジュールは、アクティブにするか又は非アクティブにすることができる。

変換処理
上述のように、レガシープログラムは、レガシーフロー制御命令で終了するレガシー手順に細分化される。これにより、より良好な最適化コードのための複数の命令の同時処理が考慮される。例えば、「Ｉｎｔｅｌ ＩＡ−６４」アーキテクチャでは、クロックサイクル当たり最大６つの命令の実行が準備されている。複数の命令を一度に処理すると、データの依存性に基づいて並列に実行するのにどの命令が安全であるかを判断することができる。結果として、レガシー命令のセグメント又は手順のために生成されたネイティブ命令は、レガシープロセッサと正確に同じ順番で演算を実行することができない。しかし、データの依存性が尊重される限りこれは問題にならない。しかし、インテルのタイプ「ＩＡ−６４」命令を１つずつ実行すると、プロセッサの実行リソースの十分な効果が得られない。

本発明によるバイナリ変換プログラムは、各レガシー命令のために６４ビット値を含むベクトル表又は空間を使用する。６４ビット値は、ネイティブ命令ハンドラがその命令のために存在する場所の完全なアドレスである。しかし、レガシープログラムは、レガシーフロー制御命令で終了するレガシーコードのセグメントに細分化されるので、全ての命令が有効なベクトルエントリを含むわけではない。本発明によるバイナリ変換プログラムは、連続して実行されるレガシーコードのブロック又はセグメントと共に機能するので、ベクトルは、各々の対応するレガシーコードセグメント（すなわち、レガシー手順）の始めの間に要求されるだけである。ベクトルは、そのレガシー手順のためのネイティブ命令ハンドラのアドレスである。例えば、図５は、参照番号５０及び５２、及びそれらのアドレスで特定される２つのグループのレガシー命令を示す。命令の各グループ５０及び５２は、レガシーコードセグメント（すなわち、レガシー手順）を形成する分岐命令ＢＥＱで終了する。各レガシーアドレスは、ベクトル空間内に対応する場所を有する。ベクトル空間の各占有されたエントリは、次に、マイクロコード空間のネイティブ命令ハンドラを指す。本発明の一態様により、バイナリ変換プログラムは、分岐命令を処理する時は２パス変換システムを使用する。より詳細には、多くのレガシー分岐命令に関して、分岐の宛先をレガシーコードから直接判断することが可能である。他の時は、宛先のコードは直接判断することができない。本発明によるバイナリ変換プログラムは、両方の状況を処理することができる。

変換の第１のパスは、ジャンプ又は分岐（すなわち、フロー制御命令）を除く全てのレガシー命令のためのネイティブ命令を生成する。第１のパスが完成した状態で、残りのコードのためのベクトルが生成されているので、関連の分岐変換を実行することができる。第２のパスは、変換時に宛先を判断することができる分岐に対する分岐命令を埋める。

分岐の宛先が変換時に判断されることが可能であって、しかもその分岐が有効ベクトルが存在しない位置を向く場合、「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトが生成され、その点から前方にレガシーフロー制御命令が発見されるまでレガシー命令で埋められる。例えば、図５を参照すると、分岐が最後に位置１０２０に行く場合、「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトが生成されることになり、アドレス１０２０、１０２４、及び１０２８における命令に対して変換される。この処理は、第２のパスの間に発生する。従って、第２のパスは、読込み時に分っている宛先に対する全ての分岐命令を完成させ、有効ベクトルをまだ持っていない宛先に対する新しいハンドラを構築する。

２パス変換は多くの分岐命令を処理することができるが、読込み時に全ての分岐の宛先が分っているわけではない。実行時に予測された宛先アドレスに依存する分岐命令もある。これらの場合、これらの分岐命令は、そのネイティブ命令ハンドラのアドレスをベクトル空間からプルして、その場所にジャンプする。宛先に対する有効ベクトルがない場合は、ネイティブ命令ハンドラが動的に作り出され、そのアドレスがベクトル空間に入力される。この処理は、レガシーコードの実行時変換を実行し、分岐の宛先アドレスで始まりレガシーフロー制御命令が発見されるまで続くダイナミッククラッキングにより実行される。ダイナミッククラッキングオブジェクトは、新しい「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトを作り出し、次のフロー制御命令を通じて、それをレガシー命令に対する「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」オブジェクトで埋める。次に、それは、レガシー命令の変換を要求し、得られるネイティブ命令をメモリに記憶する。このシステムは、全ての分岐命令を処理することができるが、最後の手段として使用され、その理由は、分岐宛先の事前計算が、それが可能な場合はより良好な性能を可能にするからである。

オペレーティングシステムの呼び出し
上述の通り、アプリケーションプログラムは、直接的に、又はシステムライブラリ機能を通じて間接的に、オペレーティングシステムの呼び出しをすることが公知である。例えば、「Ａｌｐｈａ ２１２６４」マイクロプロセッサアーキテクチャは、システムの呼び出しを特定の命令として形成する。命令の実行により、オペレーティングシステムの割り込みが発生する。システムの呼び出し命令の前に、コンパイラ及び／又はプログラマーは、システム呼び出し番号を、「Ａｌｐｈａ ２１２６４」マイクロプロセッサの場合に＄ｖ０である既知のレジスタに挿入すべきである。システム呼び出し番号は、＄ｖ０から抽出され、次にシステム機能呼び出し慣例により規定されるように、他のレジスタから追加の引数を抽出することができる。バイナリ変換プログラムに対して、システムの呼び出しは単なる別の命令である。しかし、システム呼び出し番号は、オペレーティングシステム毎に異なるはずであり、実際に異なっている。一例として、「ＯｐｅｎＶＭＳ」オペレーティングシステムは、「Ｔｒｕ６４ Ｕｎｉｘ」とは異なるシステムの呼び出し番号を使用する。「Ａｌｐｈａ」用の「Ｗｉｎｄｏｗｓ ＮＴ」オペレーティングシステムも、同じく「ＯｐｅｎＶＭＳ」や「Ｔｒｕ６４」とは異なっている。従って、バイナリ変換プログラムシステム呼び出しは、レガシーオペレーティングシステムに特異であるべきである。

直接適合システム呼び出し
バイナリ変換プログラムは、各システム呼び出しを、緊密に適合するホストプロセッサシステムの呼び出しか、又は、ネイティブオペレーティングシステムの支援の有無によらずレガシーシステム呼び出しの挙動をエミュレートするコードかにマップすることを可能にする。例えば、ディスクディレクトリ削除（ｒｍｄｉｒ）「Ａｌｐｈａ Ｔｒｕ６４ Ｕｎｉｘ」システム呼び出しを、同等の「Ｉｎｔｅｌ ＩＡ−６４ Ｌｉｎｕｘ」システム呼び出しに変換するための「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサアーキテクチャに対する例示的アセンブリ言語プログラムを以下に示す。

このスタブのアドレスは表に記憶され、「Ａｌｐｈａ ２１２６４」システムの呼び出し命令が実行される時に、「Ａｌｐｈａ」レジスタ＄ｖ０に配置されたシステム呼び出し番号が表に入るインデックスとして使用される。その表位置のアドレスは、このスタブに分岐するために使用される。スタブは、要求されたパラメータ（ディレクトリ名を含むストリングに対するポインタ）だけを「Ｉｎｔｅｌ」のタイプ「ＩＡ−６４」プロセッサ上の正しいレジスタ内に動かし、「ＩＡ−６４」システム呼び出し番号（「Ａｌｐｈａ」マイクロプロセッサ用の１３７ではなく１０５６）を「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサ用のレジスタ１５に配置する。システム呼び出しは、成功の場合にインジケータ値０を、失敗の場合に−１を返し、その値は、「Ａｌｐｈａ」マイクロプロセッサの正しいレジスタに配置される。別の値「ｅｒｒｎｏ」（エラー番号）は、失敗の原因を示す。その値は、「Ａｌｐｈａ」／Ｔｒｕ６４」システム及び「ＩＡ−６４／Ｌｉｎｕｘ」システム間で異なり、従って変換されるべきである。「ＡｄｊｕｓｔＲｅｓｕｌｔｓ」マクロが、別のデータ表を通じてこれを行う。変換された状態で、この「ｅｒｒｎｏ」値は、正しい「Ａｌｐｈａ」レジスタに配置され、スタブは、通常のコード実行へ戻ることができる。引数０ｘ１０００００を有する「ＩＡ−６４」中断命令により、システム呼び出しが発生する。

非直接適合システム呼び出し
以上の例は、現存のホストプロセッサのシステム呼び出しに対して正確に適合する状態を示している。しかし、これは常に該当するわけではない。例えば、「Ａｌｐｈａ／Ｔｒｕ６４ Ｕｎｉｘ」の「ｕｎａｍｅ」システム呼び出しは、いくつかのテキストストリームの形式でマシンに関する情報を返す。以下の例は、このシステム呼び出しに対するアセンブリ言語スタブの例である。

このシステム呼び出しを直接マップする場合の問題は、レガシープログラムが、本来設計されたプロセッサ上で作動していないということである。従って、このスタブは、「Ｉｎｔｅｌ ＩＡ−６４ Ｌｉｎｕｘ」の「ｕｎａｍｅ」システム呼び出しを直接使用するよりも「Ｃ」機能を呼び出し、得られるストリングを調節する。
以下の例は、「Ｌｉｎｕｘ」の「ｕｎａｍｅ」システム呼び出しの挙動を再定義するために使用される「Ｃ」機能を示す。尚、この機能は、上述のスタブの「ｂｒ．ｃａｌｌ．ｓｐｔｋ．ｆｅｗ」命令により呼び出される。

「Ｌｉｎｕｘ」の「ｕｎａｍｅ」システム呼び出しが使用されるが、「ｎｏｄｅｎａｍｅ」要素だけがネイティブ結果に転送されることは注目される。他の全てのフィールドは、プログラムが「Ｔｒｕ６４ Ｕｎｉｘ」オペレーティングシステムの例えば「バージョン５．１、ビルド７３２」上で実行されていることをプログラムに信じさせるために作られる。
これらと同様の技術を通して、レガシーオペレーティングシステムの全体システム呼び出しセットを再び作成することが可能である。この作業の複雑性は、レガシー及びネイティブのオペレーティングシステムの差に依存する。「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサの「Ｌｉｎｕｘ」オペレーティングシステムに対して「Ｔｒｕ６４」オペレーティングシステム上で作動する「Ａｌｐｈａ」マイクロプロセッサの場合、そこに多くの類似点がある。

システムライブラリの交換
上述の通り、システム呼び出しは、ホストオペレーティングシステムにマップすることができる。上述の通り、レガシーアプリケーションプログラムはまた、システムライブラリとインタフェースを取る。レガシーアプリケーション次第で、レガシーライブラリではなくネイティブマイクロプロセッサからのシステムライブラリを使用することが可能であろう。この手法は、ネイティブライブラリがネイティブシステム上で実行するのにより良く最適化されやすいという点で有利である。これが不可能な場合は、１つ形式か別の形式のレガシーシステムライブラリが使用されるべきである。

静的リンク対動的リンク
システムライブラリを使用するソフトウエアアプリケーションは、静的にリンクされるか、又は動的にリンクすることができる。静的リンクでは、アプリケーションがライブラリから要求するコードは、得られるアプリケーションバイナリロードモジュールに入れられる。これにより、必要に応じてライブラリコードを読込む、独立型であるが動的リンクよりも大きいロードモジュールが作り出される。動的にリンクされたアプリケーションでは、プログラムが実行されている時に共有ライブラリが利用可能であるべきである。

静的にリンクされたアプリケーション
レガシーアプリケーションが静的にリンクされる場合、静的にリンクされたレガシーライブラリコードをネイティブライブラリコードと簡単に交換することが恐らくできないであろう。従って、レガシーライブラリコードは、レガシーアプリケーションの残りと共に変換することができる。本発明によるバイナリ変換プログラムは、レガシーライブラリコードの存在を知らないことになる。このアプリケーションでは、完全に変換されたネイティブバイナリを生成するのに追加のレガシーコンポーネントを必要としない。

動的にリンクされたアプリケーション
動的ライブラリリンクを使用するアプリケーションでは、ロードモジュールには、どのライブラリが必要であるかという情報が含まれるべきである。何の機能が未解決であるかという情報も存在することになる。この時点で、多くの場合、レガシーライブラリの代わりにネイティブライブラリを使用することができる。これができるかできないかは、ネイティブシステム上に同じ機能が存在するか否かによる。存在する場合は、レガシー及びホストプロセッサ間の機能の呼び出し規定が恐らく異なることになるので、簡単な変換スタブが使用されて引数を正しいレジスタに移動させる。以下に示すコード例は、レガシーライブラリ機能の代わりにネイティブ「ａｔａｎ」（アークタンジェント）ライブラリ機能の使用を考慮する「Ｉｎｔｅｌ ＩＡ−６４」アセンブリ言語スタブの例である。

示されているように、「Ｉｎｔｅｌ ＩＡ−６４」の「ａｔａｎ」ライブラリ機能を「Ａｌｐｈａ」バージョンにマップするのに非常に僅かなコードしか必要とせず、それを実行することにより得られる性能の向上は、比較的十分なものである。しかし、この手法は、レガシーライブラリ機能を認識することができ、それがどの引数を要求するかが分っていることを必要とする。従って、共通に使用されるライブラリ機能用にだけ適しており、未知のレガシーライブラリ用には使用することはできない。

ネイティブ機能へのレガシー機能のマッピングの代替としては、単にレガシーライブラリを変換することである。これには、明らかにレガシーライブラリが変換のために利用可能である必要がある。この処理により静的リンクアプリケーションと同じ性能がもたらされるが、内容の機能が既知又は未知に関係なく任意の利用可能なレガシーライブラリを使用することができるので、ネイティブライブラリの使用よりも更に柔軟性がある。

メモリレイアウト
図６は、本発明によるバイナリ変換プログラムに使用されるメモリ領域のグラフ表示である。参照番号５４及び５６で特定される最初の２つのメモリ領域は、上述の通り第１のパス及び第２のパスのマイクロコード領域に関連する。これらのメモリ領域は、変換レガシーアプリケーションを構成する変換ネイティブ命令を含む。参照番号５８で特定される次の領域は、それぞれのレガシー命令ハンドラのためのマイクロコードアドレスを含むベクトル空間に関する。上述の通り、ベクトル空間の全ての位置が有効なエントリを含むわけではない。ベクトル空間５８は、レガシーコード命令の数と同じ数のエントリを含む。最後の領域は、データ空間６０である。これらは、レガシーアプリケーションのロードモジュールで規定されたデータ部分である。データ空間６０は、静的データ、又はロードモジュール内で明示的に規定されたデータに専用である。レガシープログラムは、必要に応じてヒープ又は自由ストアから追加メモリを割り当てることができる。

必要に応じて、変換レガシーアプリケーションに他のメモリ領域が提供される。これらは、ネイティブプロセッサのメモリプールから割り当てられたスタックと、ホストプロセッサのヒープ又は自由ストアから動的に要求されたメモリとを含む。
ホストプロセッサのメモリに物理的に配置される場合もあり配置されない場合もある別の可能な領域は、レガシーコードである。変換が完了した状態では、上述の通り、この情報は、ダイナミッククラッキング作動のため以外は必要とされない。このような場合、情報は、メモリを節約するためにディスクファイルから読み込むことができる。

レジスタレイアウト
本発明によるバイナリ変換プログラムの性能における主要な要素は、ネイティブプロセッサレジスタの利用に対する手法である。本発明によるバイナリ変換プログラムがそのレガシーバイナリの実行に関してネイティブプロセッサレジスタをいかに使用するかに関する情報を以下に説明する。この情報は、ネイティブプロセッサ毎に異なる。以下の情報は、「Ｉｎｔｅｌ ＩＡ−６４」ネイティブプロセッサと「Ａｌｐｈａ ２１２６４」レガシープロセッサとに関する。
レガシープロセッサのレジスタは、性能上の理由のためにネイティブプロセッサのレジスタにマップされる。現代の多くのマイクロプロセッサのアーキテクチャは、それらの演算のほとんど全てをレジスタ内に限定して実行し、強制的にメモリから値を読み込んで次に再び結果を無用に記憶し、実質的な性能のペナルティをもたらす。

「Ａｌｐｈａ ２１２６４」プロセッサは、３２個の６４ビット汎用レジスタと３２個の６４ビット浮動小数点レジスタとを有する。「Ｉｎｔｅｌ ＩＡ−６４」プロセッサは、１２８個の６４ビット汎用レジスタと１２８個の８０ビット浮動小数点レジスタとを有する。「Ａｌｐｈａ／Ｔｒｕ６４」レガシーシステムと「ＩＡ−６４」ネイティブシステムとに対するレジスタ割り当てを以下に示す。
・汎用レジスタ０−３０は、「ＩＡ−６４」汎用レジスタ３２−６２に記憶される。
・「Ａｌｐｈａ」汎用レジスタ３１は、常にゼロとして読み取り、書き込むことができるが、その値は常にゼロを読み取る。「ＩＡ−６４」汎用レジスタ０は、ほとんど同じ特性を有し、従って、「Ａｌｐｈａ」レジスタ３１は、「ＩＡ−６４」汎用レジスタ０にマップされる。
・「Ａｌｐｈａ」浮動小数点レジスタ０−３０は、「Ｉｎｔｅｌ ＩＡ−６４」浮動小数点レジスタ３２−６２に記憶される。
・「Ａｌｐｈａ」浮動小数点レジスタ３１は、常にゼロを読み取り、書き込むことができるが、その値は常にゼロを読み取ることになる。「ＩＡ−６４」浮動小数点レジスタ０は、ほとんど同じ性能を有するので、「Ａｌｐｈａ」浮動点レジスタ３１は、「ＩＡ−６４」浮動小数点レジスタ０にマップされる。
・１６個の「ＩＡ−６４」汎用レジスタは、スクラッチパッド又は一時レジスタｒ６３−ｒ７８として指定される。
・１６個の「ＩＡ−６４」浮動点レジスタは、スクラッチパッド又は一時レジスタｆ６３−ｆ７８として指定される。
・１６個の「ＩＡ−６４」述部レジスタは、スクラッチパッド又は一時レジスタｐ１−ｐ１６として指定される。述部レジスタは、比較演算からの単一ビットの真／偽結果を記憶するために使用される。これらのレジスタは、ほとんど全ての「ＩＡ−６４」命令の実行に対して使用することができ、「ＩＡ−６４」の命令を条件付きで実行させることができる。「Ａｌｐｈａ ２１２６４」均等物はない。
・２個の「ＩＡ−６４」分岐レジスタは、スクラッチパッド又は一時レジスタｂ４−ｂ５として指定される。分岐レジスタは、分岐命令の宛先アドレスを保持するために使用される。「Ａｌｐｈａ ２１２６４」は、この機能のために汎用レジスタを使用する。

バイナリ変換プログラムシステムの分類図
バイナリ変換プログラムのための「ＵＭＬ」分類図を図７及び図８に示す。概略説明と共に主要な機能的要素が含まれている。図７は、バイナリ変換プログラムの機能ユニットに沿って編成されており、主要なシステムが強調されている。全ての部類が示されているわけではない。図からは明白ではないが、一組の「Ｃ＋＋」ベースの部類がバイナリ変換プログラムの基礎を形成している。この部類の組は、いかなる特定のレガシー又はホストプロセッサを対象にするものでもない。別の層は、ネイティブプロセッサの特定情報とレガシープロセッサの特定情報とを統合するために使用される。
図８は、階層的に編成されており、全ての部類をトップダウン編成で表示している。バイナリ変換プログラムの部類が全て表示されているわけではない。

変換処理ダイアグラム
図９は、変換処理ダイアグラムである。バイナリ変換プログラムセッションのマネージャオブジェクト６２は、変換処理のトップレベルにある。それは、次に、レガシープロセッササブシステム３６とネイティブプロセッササブシステム４０とを呼び出す。６つの全体的段階は、以下のように示す。
１．ローダーサブシステム３４は、レガシープログラムを読み込むために使用される。レガシーデータセグメントは、変更されずにメモリに記憶される。レガシー命令は、変換のためにシステムの残りに送られる。
２．次に、レガシー命令が入力され、フロー制御命令で終了するレガシー命令グループに分類される。この段階の出力は、各々が「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」オブジェクトの総数を含む一連の「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトである。これらのオブジェクトの集合は、レガシープログラムの命令部分である。
３．事前変換最適化モジュール６４は、それが存在してアクティブな場合は呼び出される。これらのモジュールは、段階２で作り出された「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」及び「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」オブジェクト上で作動する。
４．「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」は、ネイティブプロセッサの命令に変換される。この段階の出力は、各「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」オブジェクトに追加される「ＮａｔｉｖｅＩｎｓｔｒｕｃｔｉｏｎｓ」オブジェクトである。全てのネイティブ命令オブジェクトの集合は、変換されたプログラムの命令部分である。
５．事後変換最適化モジュール６６は、それが存在してアクティブな場合は呼び出される。これらのモジュールは、段階４で作り出された「ＬｅｇａｃｙＰｒｏｃｅｄｕｒｅ」及び／又は「ＬｅｇａｃｙＩｎｓｔｒｕｃｔｉｏｎ」オブジェクトを恐らくは使用して「ＮａｔｉｖｅＩｎｓｔｒｕｃｔｉｏｎｓ」オブジェクト上で作動する。
６．最終段階は、変換されたプログラムを、実行準備のためにネイティブプロセッサメモリか、又は「出力プログラム」と名付けられたブロック６８により示されるように後で使用するためにディスクファイルのいずれかに記憶することである。

命令変換の例
いくつかの代表的「Ａｌｐｈａ ２１２６４」命令を「ＩＡ−６４」命令に変換するために使用されるコードの例を以下に示す。「Ａｌｐｈａ／ＩＡ−６４」プロトタイプは、各レガシー「Ａｌｐｈａ」命令に対して「レガシー命令変換プログラム」と呼ばれる「Ｃ」機能を提供し、各「ＩＡ−６４」命令に対して「ネイティブ命令生成プログラム」と呼ばれる「Ｃ」機能を提供する命令変換機構を使用する。「Ｃ」機能は、効率的なアクセスのためにそれらのアドレスを表に記憶することができるという理由で使用される。命令変換プログラムは、レガシー命令を検査し、演算コードを抽出し、その「Ａｌｐｈａ」命令に対する「レガシー命令変換プログラム」機能のアドレスをプルする。「レガシー命令変換プログラム」機能は、次に、必要に応じて「ネイティブ命令生成プログラム」を使用して「ＩＡ−６４」命令を生成する。２つの例示的「Ａｌｐｈａ」命令を検討する。

「Ａｌｐｈａ Ｓ４ＡＤＤＱ」、リテラル形式
この命令は、整数追加命令であり、既にレジスタ内にある値にリテラル値を追加するために使用される。以下の第１の例は、この「Ａｌｐｈａ」命令に対する「レガシー命令変換プログラム」を示す。この機能は、２つの異なる「ＩＡ−６４命令生成プログラム」機能である「ｓｈｌａｄｄ」及び「ａｄｄｓ＿ｉ１４」を呼び出す。これらの「Ｃ」機能は、「Ａｌｐｈａ Ｓ４ＡＤＤＱ」命令の挙動を再現するために必要な「ＩＡ−６４」バイナリ命令を生成する。各「ＩＡ−６４」命令生成プログラム機能を呼び出した後で、「ＩＡ−６４」命令は、変換プログラムサブシステムに追加され、ネイティブプロセッサのメモリ及び／又はディスクファイルに記憶される前に更に別の処理を待つ。

レガシー命令変換プログラム機能は、「Ａｌｐｈａ」から「ＩＡ−６４」への変換プログラムにより使用され、「Ａｌｐｈａ ２１２６４」命令を「ＩＡ−６４」均等物に変換する。この場合、２つの「ＩＡ−６４」命令が必要である。他のレガシー命令に対しては、それよりも多いか又は少ない数が必要であろう。以下の第２の例は、「ＩＡ−６４」の「ｓｈｌａｄｄ」命令を生成するために必要な「ＩＡ−６４」命令生成プログラム機能を示す。

「Ａｌｐｈａ Ｓ４ＡＤＤＱ」リテラル形式命令変換機能

「ｓｈｌａｄｄ」命令に対する「ＩＡ−６４」命令生成プログラム機能

レジスタ再マッピング機能が、同様にレガシー命令変換プログラム機能により取り扱われることにも注意すべきである。別の重要な注意点は、「ＩＡ−６４」上のこの「Ａｌｐｈａ」命令の実行に対して単一のスクラッチレジスタが必要であるということである。

「Ａｌｐｈａ ＣＭＯＶＥＱ」
「Ａｌｐｈａ ＣＭＯＶＥＱ」命令は、条件付きで「Ａｌｐｈａ」汎用レジスタ内に値を移動する。この命令のためのレガシー命令変換プログラムは、以下の例で見出すことができる。この「Ａｌｐｈａ」命令は、２つの「ＩＡ−６４」命令である「ｃｍｐ．ｅｑ」（８ビット即値形式）及び「ａｄｄ」（レジスタ形式）を再度要求する。

「Ａｌｐｈａ ＣＭＯＶＥＱ」レガシー命令変換プログラム機能

オプティマイザーの例：「ＩＡ−６４」コードスケジューラーオプティマイザー
以下のオプティマイザーの例は、変換された命令を最大命令並列処理に関して最適にスケジュールに入れるように試みることにより、「ＩＡ−６４」の「ＥＰＩＣ」アーキテクチャを利用する。「Ｉｔａｎｉｕｍ ２」プロセッサは、クロックサイクル当たり最大６つの命令まで実行することができる。これらの命令は、命令を実行するためにどのプロセッサリソースが必要であるかを指示する５ビット「テンプレート」フィールドと共に、３つの４１ビット命令の「命令バンドル」に形成されるべきである。オプティマイザーは、ネイティブ命令を解析し、データの依存性に基づいてどちらが安全に並列で実行することができるかを判断し、次に、それらの「命令グループ」に適合する命令バンドルを選択する。全体の処理が図１０に示されている。本発明によるバイナリ変換プログラムは、レガシープログラムをレガシー命令グループ７０に細分化する。「ＩＡ−６４」スケジュールオプティマイザーは、次に、変換されたネイティブ同等命令を「ＩＡ−６４」命令グループ７２、７４、及び７６に細分化する。「ＩＡ−６４」命令グループ内の全ての命令は、安全に同時に実行することができ、従って、相互のデータ依存性を含まない。オプティマイザーは、次に、「ＩＡ−６４」命令グループ７２、７４、及び７６を、各々３つの命令の「ＩＡ−６４」命令バンドル７８、８０、８２、８４、８６、及び８８に細分化する。
このスケジュールアルゴリズムは、「Ｉｔａｎｉｕｍ ２」だけに適用され、後で「ＩＡ−６４」プロセッサに適用される。しかし、各ネイティブプロセッサは、そのアーキテクチャに適する調節された命令スケジュールアルゴリズムの恩恵を恐らく受けることになる。

「ＩＡ−６４」アーキテクチャは、制限された数のバンドルのタイプを規定する。「ＩＡ−６４」命令の全ての組合せが同じバンドル内で有効なわけではない。例えば、共通バンドルのタイプは、２つのメモリ命令と１つの整数命令とがそのバンドルに含まれることを示す「ＭＭＩ」として識別される。バンドルタイプは、バンドルの５ビットテンプレートフィールド内で符号化される。プロセッサの機能停止を避けるために、バンドルタイプを注意深く選択することは大切である。このために、「ＩＡ−６４」スケジューラーオプティマイザーは、命令グループ内の「ＩＡ−６４」命令に対するバンドルタイプを選択するために、注意深く設計されたアルゴリズムを使用する。例示的なアルゴリズムを図１１に示す。

変換処理の例
以下の例は、「Ａｌｐｈａ」レガシープロセッサ及び「ＩＡ−６４」ネイティブプロセッサのためのものである。４つのレガシー「Ａｌｐｈａ」命令のグループが「ＩＡ−６４」命令に変換されて、このネイティブプロセッサ用に適正に編成される。
図１２は、「Ａｌｐｈａ」命令とそれらの命令を「ＩＡ−６４」命令に変換する処理の小さなブロックの図式的表示である。この図は、変換段階だけを示し、最適化を示していない。レガシーコードブロックは、通常はジャンプ又は分岐である「レガシー手順」と呼ばれる（しかし、それらは、本来のソースコードに関して完全なレガシー手順を実際に表すことはできない）何らかの種類のフロー制御命令で「いつも」終了する。「レガシー手順」内の全ての命令は、連続的に実行される。この例は、レガシープログラムが既にレガシー手順に細分化されて、単一手順の変換が発生していると仮定している。

変換処理は、単一のレガシー命令を取り、それを演算コード（ｏｐｃｏｄｅ）に基づくルックアップテーブルを使用して復号化し、必要に応じてネイティブプロセッサ命令を次に作成する適正な「レガシー命令変換プログラム」機能を呼び出すことを伴う。この処理は、一般的に以下の段階を伴う。
１．１つ又はそれ以上の一時（スクラッチ）レジスタが必要な場合がある。その場合には、それらは、レジスタマッピングを担う「Ｘ−ｐｏｒｔ」オブジェクトから要求される。循環する一時レジスタのセットが使用される。「ＩＡ−６４」ネイティブプロセッサについては、「ＩＡ−６４」の１２８個の汎用レジスタのいくつかは、一時レジスタとして専用に使用される。
２．レガシー命令により使用される全てのレガシーレジスタは、その対応するホストプロセッサレジスタにマップされる。ここでもまた、「Ｘ−ｐｏｒｔ」のレジスタマッピング構成要素がこのサービスを実行する。
３．レジスタがマップされて一時レジスタが割り当てられたので、必要に応じて、レガシー変換プログラム機能は、「ネイティブ命令生成プログラム」機能を呼び出し、生のバイナリ形式でホストプロセッサ命令を生成する。この例では、７つの異なる「ＩＡ−６４」命令が要求され（「ｓｘｔ４」が３度使用される）、従って、７つの異なるネイティブ命令生成プログラム機能が使用される。

この処理の出力は、最終的にレガシー命令と同じ機能を実行する直接的な連続するネイティブプロセッサ命令セットである。図１２において、得られる各「ＩＡ−６４」ホストプロセッサ命令は、更なる参照のために番号が付けられる。図示の「Ａｌｐｈａ」命令に関して見られるように、適正なエミュレーションのために９つの「ＩＡ−６４」命令が必要である。その数は、レガシー命令混合に依存してそれよりも多いか又は少ない可能性がある。

この命令セットは、パッケージ化してそのまま実行することができるが、これは、「ＩＡ−６４」ホストプロセッサ上で性能の劣化をもたらすであろう。このプロセッサの性能を向上させるために命令パッケージ化を実行すべき方法を以下に簡単に説明する。この情報は「ＩＡ−６４」に特異であるが、最大の性能を達成するために、他のホストプロセッサは、同様のコード再編成を要求することができ、また要求するであろう。

「ＩＡ−６４」アーキテクチャは、命令が命令バンドルに分類されることを要求する。命令バンドルのレイアウトは、図１３に見ることができる。各バンドルは、それぞれの長さが４１ビットの３つの「ＩＡ−６４」命令から成る。バンドルはまた、この３つの命令のセットにより要求されたプロセッサリソースを説明するために使用される５ビットのテンプレートフィールドを含む。これらのリソースは、プロセッサ実行ユニットである。

図１４は、「Ｉｔａｎｉｕｍ ２」プロセッサにおいて利用可能な実行ユニットを示す。これらには、４つのメモリユニット（多くの簡単な整数及び論理命令を実行することもできる）、２つの整数ユニット、２つの浮動小数点ユニット（長い又は拡張命令も実行する）、及び３つの分岐ユニットが含まれる。図はまた、これらのリソースを一組の２つの命令バンドルに対して使用することができる方法を示す。これについて以下に更に説明する。適切なプロセッサリソースが利用可能な場合には、「ＩＡ−６４」プロセッサが２つの完全な命令バンドル（６つの命令）を一度に実行することができる点に注意すべきである。

バンドルのテンプレートフィールドは、バンドル内の命令により実行ユニットのどの組合せが必要とされるかを指定する。例えば、テンプレートフィールド値１６は、メモリユニット、整数ユニット、及び分岐ユニットが必要であることを意味するコード「ＭＩＢ」を表す。テンプレートフィールドはまた、任意の新しい命令がプロセッサにより受け入れられる前に、現在実行されている全ての命令を完了すべきであることを意味する「停止」条件を指定することができる。停止は、データ依存性違反を防ぐために使用される。テンプレートタイプ１７もまた「ＭＩＢ」タイプであるが、バンドルの終りにおける停止も指定する。それは、表記「ＭＩＢ＿」により示される。

用語「ＩＡ−６４命令グループ」は、並列実行に対して全て適格である「ＩＡ−６４」命令のグループを意味する。「ＩＡ−６４」命令グループは、最終的に、最後に停止を含むべきである１つ又はそれ以上の命令バンドルに編成される。
「ＩＡ−６４」ホストアーキテクチャに関するこの情報を使用して、変換処理の次の段階を検査することができる。図１５は、「ＩＡ−６４」ホストプロセッサのための次の段階を示す。
図１５は、互いのデータ依存性を全く含まない図１２からの命令セットを示す。これは、単一の「ＩＡ−６４」命令グループである。

「ＩＡ−６４」ホストプロセッサの良好な性能のための要件は、最大の並列処理に対してデータ依存性違反が許されない順番に命令を適切にスケジュールに入れるということである。従って、「Ｘ−ｐｏｒｔ」の「ＩＡ−６４」特異部分は、図１２で出された命令ストリームを解析し、どの命令を同時に安全に実行することができるかを判断する。図１５において、命令１、２、５、６、及び８には、それらの間にレジスタ依存性がなく、従って並列に安全に実行することができることが分る。しかし、これは、５つの命令のリストである。「ＩＡ−６４」命令バンドルは、これらの命令を含むように選択されるべきである。得られる命令バンドルは、次に、実行可能「ＩＡ−６４」コードとしてメモリに記憶される。「ＩＡ−６４」の「ｍｏｖｌ」命令は、２つのバンドルスロットを要求することに注意すべきである。

図１６は、単に３つの命令（３、７、及び９）を有する第２の「ＩＡ−６４」命令グループを示す。この「ＩＡ−６４」命令グループは、タイプ「ＭＩＢ」の単一バンドルに適合することになる。この例では発生しないが、全ての命令バンドルを満たすことはできない可能性がある。このような場合には、どのバンドルスロットにも演算コードを挿入してバンドルを完成させることはできない。「ＩＡ−６４」命令バンドルの作成は、処理の終了を表す。この形式になった状態で、「ＩＡ−６４」命令は、ホストプロセッサにより直接に実行可能である。

事後変換最適化の例
以下は、変換が発生した後に呼び出すことができるオプティマイザーの例である。この例では、「Ａｌｐｈａ」レガシープロセッサと「ＩＡ−６４」ネイティブプロセッサとを仮定する。その目的は、「叙述」と呼ばれる「ＩＡ−６４」ホストプロセッサの機能を使用して短い前方分岐を除外することである。叙述は、１つ又はそれ以上の命令を条件付きで実行することを考慮する。
以下の例は、「ＩＡ−６４」叙述機能を使用する理由を示すために、簡単な「Ｃ」言語「ｉｆ−ｔｈｅｎ」構成を示す。（レジスタｒ５は「ａ」、ｒ６は「ｂ」、及びｒ７は「ｃ」と仮定される。）そこから分るように、ａがｂよりも大きい時は、変数ｃは値０を取ることになる。それ以外は、ｃは１に等しく設定されることになる。この種の説明は、図に見られるようなアセンブリ言語で表すことができる。

アセンブリ均等物を有する「Ｃ」の簡単な「ｉｆ−ｔｈｅｎ」文

最も現代的なマイクロプロセッサアーキテクチャは、ｃの値を条件付きで設定するために使用される１つ又はそれ以上の分岐を必要とすることになる。しかし、「ＩＡ−６４」の実行は、叙述によるものではない。「ＩＡ−６４」の「ｃｍｐ．ｇｔ」命令は、ｒ５とｒ６を比較し、真又は偽（１又は０）の値を述部レジスタｐ１及びｐ２に記憶する。それらのレジスタ内の結果は、次の２つの命令を条件付きで実行するために使用される。第１の「ｍｏｖ」は、ｐ１＝１の時にのみ実行される。第２の「ｍｏｖ」は、ｐ２＝１の時にのみ実行される。所定の比較命令は、比較の真又は偽の結果をｐ１に、その結果の補完をｐ２内に戻すので、「ｍｏｖ」命令の一方だけが有効である。他方は実行されない。
この概念は、短い前方条件付き分岐を解消するために使用することができる。図１７は、短い前方条件付き分岐命令（ＢＥＱ）を含む「Ａｌｐｈａ」コードの小さな断片を示す。分岐がアドレス１００Ｃで行われる場合、１０１０と１０１４での命令は実行されないことになる。分岐条件が満足されない場合、分岐は中止され、それらは実行されることになる。

図に示す通り、「ＢＥＱ」命令は、結果を「ＩＡ−６４」述部レジスタに記憶する「ＩＡ−６４」比較命令で置換することができる。これらの述部レジスタは、次に、「Ａｌｐｈａ」の「ＯＲＮＯＴ」及び「ＡＤＤＱ」命令に対する「ＩＡ−６４」同等コードを条件付きで実行するために使用することができ、不要な条件付き分岐を解消する。これは有益であり、その理由は、現代のマイクロプロセッサがそれらが正しい命令パスであると信じるものに沿って命令を予めフェッチしようとするからである。条件付き分岐が取られるか否かに関してプロセッサが予測を間違えた場合、既にプロセッサのパイプラインに存在する間違って予測された命令はフラッシュされるべきであり、かつ代替パスに沿った命令が実行のためにフェッチされるべきであるから、性能ペナルティが課せられる。これらの理由のために、条件付き分岐をできる限り解消することが通常は望ましい。

このオプティマイザーの例は、レガシープロセッサには存在しないネイティブプロセッサの特徴を利用することができるものである。
最適化モジュールは、変換レガシーコード（得られる「ＩＡ−６４」コード）を検索して短い前方条件付き分岐を探す。それらを発見すると、それは分岐を解消し、比較のために「ＩＡ−６４」バイナリコードを生成し、叙述される命令を修正する。この処理は、変換の後であるが、ネイティブ命令が実行のためにメモリに記憶される前に起きる。すなわち、それらの挙動を修正することは依然として可能である。

事前変換最適化の例
以下は、事前変換最適化の例である。それは、関数のインライン化の実行を可能にする。インライン化は、関数自体にジャンプするように設定するのではなく、関数の内容を「インライン」で拡張するコンパイラ技術である。インライン化に適する関数は一般に小さく、他の関数を頻繁に呼び出さない。関数インライン化の欠点は、その関数のためのコードが、それが呼び出されるどの場所でも複製されることである。これは、プログラムのメモリ要件を増加させる。しかし、「ＩＡ−６４」のような現代のネイティブプロセッサは、数ギガバイトのランダムアクセスメモリを含むことができる。そのようなプロセッサに対しては、関数インライン化のメモリペナルティは、目立つほどでもない。
以下の例は、小さな「Ｃ」言語コード例を示す。ここでは、「ｆｕｎｃＸ」は、非常に簡単な演算を実行する「ｆｕｎｃＹ」を呼び出す。最適化コンパイラは、プログラマーにより選択された最適化に基づいて、「ｆｕｎｃＹ」をインライン化するように選択することができる。

「Ｃ」関数が小さな「Ｃ」関数を呼び出す

他方では、本発明によるバイナリ変換プログラムは、インライン化に対して遥かに広い範囲の関数を選択することができてもよく、速度のためにメモリ使用量を犠牲にする。それぞれのインライン化された関数に対して、レガシーコードの以下の部分を省略することができる。
１．設定コード：通常は、関数呼び出しを実行するために必要なある量の設定が存在する。これは、恐らく最大６つのレガシー命令までの領域内であるが、プラットフォーム毎に変動する可能性がある。
２．無条件分岐：「ジャンプ」命令は、呼び出されている関数へコード実行をベクトル処理する。
３．関数プリアンブル：一般に、関数は、通常はいくつかの命令から成るある種のプリアンブルを含む。プリアンブル内で実行される演算は、データ領域に対するグローバルポインタの設定を含む。
４．関数復帰：関数からの復帰は、一般にいくつかのクリーンアップ命令を伴う。
５．無条件分岐：「復帰」命令は、コード実行を呼び出し関数へベクトル処理して戻す。

関数のインライン化は、多くの場合、解消することができるレガシーコード量のために性能の向上をもたらすことができる。
このオプティマイザーは、レガシーコードが変換される前であって、かつグループ分けされた後にレガシーコードに対して機能する。それは、関数呼び出しを検索し、それがインライン化に対する有効な関数を見つけた時、バイナリ変換システムに対するヒントを挿入する。

この最適化は、本来のレガシーシステムよりもインライン化をより実現可能にするための豊富なメモリを有すること以外、「ＩＡ−６４」ホストプロセッサの機能に特異のものではない。
以上の教示に鑑みて、明らかに本発明の多くの修正及び変形が可能である。すなわち、特許請求の範囲内で、本発明は上記で特に説明されたもの以外によって実施できることが理解されるものとする。
「Ｕｎｉｘ」、「Ｉｎｔｅｌ」、「Ｉｔａｎｉｕｍ」、「Ｌｉｎｕｘ」及び「Ｗｉｎｄｏｗｓ」は登録商標である。

アプリケーションプログラムがシステムのオペレーティングシステム及びプロセッサと対話する方法を示す例示的なソフトウエアモデルのブロック図である。 本発明の１つの態様によりバイナリ命令をネイティブ命令グループに挿入するためのサンク処理を示すブロック図である。 様々なサブシステムを示す本発明によるバイナリ変換プログラムのブロック図である。 「Ｌｉｎｕｘ」オペレーティングシステムを実行するネイティブ「Ｉｎｔｅｌ ＩＡ−６４」プロセッサ上で使用するための「Ｔｒｕ６４ Ｕｎｉｘ」オペレーティングシステム用に書かれた例示的レガシー「Ａｌｐｈａ ２１２６４」マイクロプロセッサアプリケーションを変換するための例示的ローダーのシーケンス図である。 例示的レガシーコードセグメントとベクトル空間との間の関係を示す例示的メモリマップの図である。 本発明によるバイナリ変換プログラムのためのメモリレイアウトを示す例示的な図である。 本発明によるバイナリ変換プログラムに対する分類図である。 本発明によるバイナリ変換プログラムに対する階層的分類図である。 本発明によるバイナリ変換プログラムのための処理ダイアグラムである。 本発明による「Ｉｎｔｅｌ ＩＡ−６４」マイクロプロセッサ用のスケジューリングオプティマイザーのブロック図である。 本発明による例示的な命令スケジューリングオプティマイザーアルゴリズムの流れ図である。 「Ａｌｐｈａ」レガシーバイナリ命令の「Ｉｎｔｅｌ ＩＡ−６４」ネイティブプロセッサバイナリ命令への例示的な命令変換を示すブロック図である。 「Ｉｎｔｅｌ ＩＡ−６４」ネイティブプロセッサ用の命令バンドルフォーマットを示す図である。 タイプ「Ｉｔａｎｉｕｍ ２」プロセッサの実行ユニットフォーマットを示す図である。 変換された「ＩＡ−６４」ネイティブプロセッサ命令が２つの「ＩＡ−６４」命令グループの最初のものに対する「ＩＡ−６４」命令バンドルに編成される方法を示す図である。 ２つの「ＩＡ−６４」命令グループの第２のものに対する処理を示す、図１５と類似の図である。 本発明による分岐予測最適化例を示す図である。

符号の説明

４２ サンクオブジェクト
４４、４８ ネイティブ命令グループ
４６ サンクを有するネイティブ命令グループ

Claims (1)

1. レガシーバイナリ命令を読み込んでファイルにロードするためのローダーサブシステムと、
   前記レガシーバイナリ命令をネイティブバイナリ命令に直接変換するための、異なるレガシー及びネイティブプロセッサと共に使用するように再設定可能な変換プログラムと、
   を含むことを特徴とするバイナリ変換プログラム。

Images