JP2014531680A - デコード時間命令最適化を用いた、強化されたアプリケーション・バイナリ・インターフェース（ａｂｉ）のためのコードのコンパイル - Google Patents

Abstract

【課題】 デコード時間命令の最適化を用いて、強化されたアプリケーション・バイナリ・インターフェース（ＡＢＩ）のためにコードをコンパイルするためのコンピュータ・プログラム、システム、及び方法を提供する。【解決手段】 コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することを含む、強化されたアプリケーション・バイナリ・インターフェース（ＡＢＩ）のためにコードをコンパイルすることである。コード・シーケンスは、第１の命令の内部表現（ＩＲ）及び第２の命令のＩＲを含む。第２の命令は、第１の命令に依存する。第１の命令のＩＲ及び第２の命令のＩＲの少なくとも一方と関連したスケジューラ・コスト関数を修正する。修正することは、第１の命令を第２の命令に隣接して配置するように構成された修正されたスケジューラ・コスト関数を生成することを含む。修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成する。オブジェクト・ファイルは、第２の命令に隣接して配置された第１の命令を含む。オブジェクト・ファイルを発行する。【選択図】 図３

Description

本発明は、コンピュータ・システムに関し、より具体的には、デコード時間命令最適化（decodetime instruction optimization）を用いて、強化されたアプリケーション・バイナリ・インターフェース（ＡＢＩ）のためにコードをコンパイルすることに関する。

コンピュータ・ソフトウェアにおいて、アプリケーション・バイナリ・インターフェース（ＡＢＩ）とは、アプリケーション・プログラムとオペレーティング・システムの間、又は、アプリケーション・プログラムと別のアプリケーションの間の低レベルのインターフェースを言う。ＡＢＩは、データ型、サイズ、及びアラインメント、関数の引数がどのように渡され、リターン値がどのように取り出されるかを制御する呼出規約、システム・コール番号及びアプリケーションがオペレーティング・システムに対してどのようにシステム・コールを行う必要があるか、並びに完全なオペレーティング・システムのＡＢＩの場合に、オブジェクト・ファイルのバイナリ形式、プログラム・ライブラリ等のような詳細をカバーする。幾つかのＡＢＩ（例えば、Ｉｎｔｅｌ ｘ８６アーキテクチャにおいて、幅広いプログラムが種々のＵｎｉｘ及びＬｉｎｕｘバリアント（variant）上で実行されることを可能にするＩｎｔｅｒａｃｔｉｖｅ Ｕｎｉｘ ＡＢＩ）は、必要な共有ライブラリが存在し、類似の前提条件が満たされるという条件で、そのＡＢＩをサポートする１つのオペレーティング・システム（ＯＳ）からのアプリケーション・プログラムが、他のいずれかのそうしたシステム上で修正なしに実行されることを可能にする。

典型的なアプリケーション・プログラムのプログラム開発サイクルには、ソース・コードを書くこと、ソース・コードをオブジェクト・ファイルにコンパイルすること、共有ライブラリを構築すること、及びオブジェクト・ファイルを主実行可能プログラムにリンクすることが含まれる。主実行可能プログラムのロード、及びアプリケーションの起動のための共有ライブラリのロードを含む付加的な準備は、アプリケーションが特定のハードウェア・プラットフォーム上で実行される前に行われる。

コンパイラは、オブジェクト・ファイルを生成するために、一度に単一のソース・ファイル（コンパイル・ユニット）を処理する。コンパイラは、コード／データの最終アドレス又は変位を知らずに、オブジェクト・コードを生成する。具体的には、コンパイラは、ＴＯＣの最終サイズ又は種々のデータ・セクションのオフセット／アドレスを知らずに、変数値を求めてＴＯＣにアクセスするオブジェクト・コードを生成する。この情報のためのプレースホルダが、オブジェクト・コード内に残され、リンカ（linker）により更新される。ＴＯＣとは、共有ライブラリをサポートし、データ位置に依存しない方法でプログラム変数にアクセスするために、例えばＡＩＸ環境などにおいて使用される変数アドレス参照テーブルである。ＬＩＮＵＸ環境においては、グローバル・オフセット・テーブル（ＧＯＴ）と呼ばれる類似の構造が、類似の機能（例えば、変数へのアクセス）を果たす。ＴＯＣとＧＯＴの１つの違いは、ＴＯＣは実際のデータを含むことができるが、ＧＯＴはデータへのアドレス（ポインタ）しか含まないことである。

リンカは、オブジェクト・ファイルを実行可能プログラム／共有オブジェクトにまとめ、オフセットをコード／データに割り当てる。リンカは、プログラム開発中に内部参照を解決し、外部参照は、ロード時に解決される。リンカは、オブジェクト・ファイルからＴＯＣエントリを収集し、ＴＯＣオフセットを割り当て、ＴＯＣセクションを生成する。リンカは、ＴＯＣの最終サイズを知っているが、コンパイラにより生成されるＴＯＣアクセス・コード・シーケンスに対する大きな編集を行わない。リンカは、特定の内部参照エントリについてのオフセットを知っているが、大部分の外部参照ＴＯＣエントリについての最終解決値を知らない。外部参照ＴＯＣエントリは、ローダ／動的リンカにより解決される。

非特許文献１は、例示的な縮小命令セット・コンピュータ（reduced instructionset computer、ＲＩＳＣ）命令セット・アーキテクチャ（instruction setarchitecture、ＩＳＡ）を教示する。Ｐｏｗｅｒ ＩＳＡは、本明細書では、例示的な実施形態を実証するために用いられるが、本発明は、Ｐｏｗｅｒ ＩＳＡ又はＲＩＳＣアーキテクチャに限定されるものではない。当業者であれば、種々のアーキテクチャにおける本発明の使用を容易に認識するであろう。

非特許文献２は、例示的なＣＩＳＣ（complex instruction set computer、複合命令セット・コンピュータ）命令セット・アーキテクチャを教示する。

非特許文献３は、ＰｏｗｅｒＰＣ（登録商標） Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋｉｎｇ Ｆｏｒｍａｔ（ＥＬＦ）ＡＢＩに対する６４ビットの補足を記載している。

非特許文献４及び非特許文献５は、３２ビットのＡＢＩを記載している。

「Ｐｏｗｅｒ ＩＳＡ（商標）Ｖｅｒｓｉｏｎ ２．０６ Ｒｅｖｉｓｉｏｎ Ｂ」、ＩＢＭ（登録商標）発行、２０１０年７月２３日 「ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ Ｐｒｉｎｃｉｐｌｅｓ ｏｆ Ｏｐｅｒａｔｉｏｎ」、ＩＢＭ（登録商標）、ＳＡ２２−７８３２−０８、第９版、２０１０年８月 「６４−ｂｉｔ ＰｏｗｅｒＰＣ ＥＬＦ Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ Ｓｕｐｐｌｅｍｅｎｔ １．９」、ＩＢＭ、２００４年 「Ｐｏｗｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標） ３２−ｂｉｔ Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ Ｓｕｐｐｌｅｍｅｎｔ １．０ Ｌｉｎｕｘ（登録商標）」、ｐｏｗｅｒ．ｏｒｇ、２０１１年４月１９日 「Ｐｏｗｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標） ３２−ｂｉｔ Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ Ｓｕｐｐｌｅｍｅｎｔ １．０−Ｅｍｂｅｄｄｅｄ」、ｐｏｗｅｒ．ｏｒｇ、２０１１年４月１９日

デコード時間命令最適化を用いて、強化されたアプリケーション・バイナリ・インターフェース（ＡＢＩ）のためにコードをコンパイルするためのコンピュータ・プログラム製品、システム、及び方法を提供する。

例示的な実施形態によると、コンピュータ・プログラム製品、システム、及び方法が、コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することを含む。コード・シーケンスは、第１の命令の内部表現（ＩＲ）及び第２の命令のＩＲを含む。第２の命令は、第１の命令に依存する。第１の命令のＩＲ及び第２の命令のＩＲの少なくとも一方と関連したスケジューラ・コスト関数を修正する。修正することは、第１の命令を第２の命令に隣接して配置するように構成された修正されたスケジューラ・コスト関数を生成することを含む。修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成する。オブジェクト・ファイルは、第２の命令に隣接して配置された第１の命令を含む。オブジェクト・ファイルを発行する。

付加的な例示的な実施形態によると、コンピュータ・プログラム製品、システム、及び方法が、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することを含む。コード・シーケンスは、待ち時間により特徴付けられる命令の内部表現（ＩＲ）を含む。第１の命令と関連したスケジューラ・コスト関数を修正する。修正することは、命令が互いに隣接した複数の命令に拡張することを認識するように構成された修正されたスケジューラ・コスト関数を生成することを含み、複数の命令は、命令のＩＲの待ち時間により特徴付けられる。修正されたスケジューラ・コスト関数に基づいて、オブジェクト・ファイルを生成する。オブジェクト・ファイルは、互いに隣接した複数の命令を含む。オブジェクト・ファイルを発行する。

本発明の技術により、付加的な特徴及び利点が実現される。本発明の他の実施形態及び態様は、本明細書で詳細に説明され、特許請求される本発明の一部であると見なされる。利点及び特徴を有する本発明をより良く理解するに、説明及び図面を参照されたい。

本発明とみなされる主題は、本明細書の最後にある特許請求の範囲において具体的に示され、明確に請求されている。本発明の前述及び他の特徴及び利点は、添付図面と併用される以下の詳細な説明から明らかである。

本発明の一実施形態によるクラウド・コンピューティング・ノードを示す。 本発明の一実施形態によるクラウド・コンピューティング環境を示す。 本発明の一実施形態による抽象化モデル層を示す。 本発明の一実施形態による、テーブル・オブ・コンテンツ（ＴＯＣ）及びデータ要素を示す。 本発明の一実施形態による、ＴＯＣ参照を生成するために、コンパイラにより実施されるプロセスのフロー図を示す。 本発明の一実施形態による、ＴＯＣ参照を生成するために、コンパイラにより実施されるプロセスのフロー図を示す。 本発明の一実施形態による、リンクされたオブジェクト・ファイルを作成するために、リンカにより実施されるプロセスのフロー図を示す。 本発明の一実施形態による、ＴＯＣ参照シーケンス・プルーニング（pruning）の最適化を実施するために、リンカにより実施される参照コード最適化プロセスのフロー図を示す。 本発明の一実施形態による、ＴＯＣアドレス指定スキームのブロック図を示す。 本発明の一実施形態による、参照頻度ベースのＴＯＣ参照パッキング（packing）を実施するために、リンカにより実施される参照コード最適化プロセスのフロー図を示す。 本発明の一実施形態による、ＧＯＴロードからＴＯＣ計算への拡張を実施するために、リンカにより実施される参照コード最適化プロセスのフロー図を示す。

本発明の実施形態は、コンピューティング・システムにおける性能及びスループットに対する、テーブル・オブ・コンテンツ（ＴＯＣ）のオーバーフローの影響を最小限にすることに向けられる。実施形態は、指定された命令シーケンス（例えば、ＴＯＣのオーバーフローを補償するためにコードに挿入されたシーケンス）を含ませるようにオブジェクト・コードを生成するように調整されたコンパイラを含む。マイクロプロセッが内部実行のためにシーケンスを最適化できるように、命令シーケンスは、ハードウェアにより認識されるように適合される。指定された命令シーケンスの１つが見つかると、マイクロプロセッサは、シーケンス内の命令をより効率的に実行される内部命令に置き換えるか、又は、シーケンス内の命令を単一の内部命令に置き換える。マイクロプロセッサにより実行されるこのプロセスは、本明細書では、デコード時間命令の最適化（decode time instruction optimization、ＤＴＩＯ）と呼ばれる。

ＤＴＩＯプロセスは、ハードウェア・プロセスである。本明細書で説明されるコンパイラ及びリンカは、ハードウェアによる最適化のためのコード・シーケンスを準備する。これらのコードは、例えば、命令が互いに隣接する、変位範囲が制限される場合に適切な変位範囲を有する、ＤＴＩＯをイネーブルにするために破壊的コード形式に関する要件を有する場合に破壊的であり、ＤＴＩＯをイネーブルにするための命令のアラインメントに関する要件を有する場合に適切にアラインされるなどの適切な特性と、ＤＴＩＯ対応ハードウェアにより必要とされ得るような他のいずれかのこうした特性とを有するといった、ＤＴＩＯ対応ハードウェアにより検出されるような方法で、コンパイラ及び／又はリンカによりコード化される。ＤＴＩＯ対応ハードウェアは、その全体を引用によりここに組み入れられる、本出願と共に２０１１年１０月３日に出願された「Ｓｃａｌａｂｌｅ Ｄｅｃｏｄｅ Ｔｉｍｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｑｕｅｎｃｅ Ｏｐｔｉｍｉｚａｔｉｏｎ ｏｆ Ｄｅｐｅｎｄｅｎｔ Ｉｎｓｔｒｕｃｔｉｏｎｓ」という名称の米国特許出願第１３／２５１，４０９号においてさらに説明される。

実施形態はまた、ＤＴＩＯ対応のもの及びＤＴＩＯ対応でないものの両方の、全てのプロセッサにわたるＴＯＣ参照の性能を向上させるように調整されたリンカも含む。リンカは、参照頻度及び変位値のような特徴に基づいて、幾つかのＴＯＣ参照コードの最適化を実施する。最適化されたコードは、オリジナルのＴＯＣ参照コードと同じ機能を果たす。ＴＯＣ及びＧＯＴは、参照テーブルの例である。ＴＯＣ及びＧＯＴのどちらも、変数のアドレスを格納する変数アドレス参照テーブルとすることができる。さらに、ＴＯＣは、データを格納することもできる。特に断りのない限り、ＴＯＣ及びＧＯＴという用語は、本明細書では、プログラム変数を見つけるためにアクセスされるテーブルを指すのに交換可能に用いられる。

ＤＴＩＯプロセスは、クラウド・コンピューティング環境において実施することができる。本開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書で述べられる教示の実装は、クラウド・コンピューティング環境に限定されるものではないことが予め理解される。むしろ、本発明の実施形態は、現在知られている又は後で開発される他のいずれかのタイプのコンピューティング環境と併せて実装することができる。

クラウド・コンピューティングは、最小限の管理労力又はサービス・プロバイダとの対話で迅速にプロビジョニング及びリリースすることができる構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、及びサービス）の共有プールへの、便利なオンデマンドのネットワーク・アクセスを可能にするサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、及び少なくとも４つの配備モデルを含むことができる。

特徴は、以下の通りである。
オンデマンド・セルフサービス：クラウド・コンシューマは、必要に応じて、サーバ時間及びネットワーク・ストレージ等のコンピューティング機能を、人間がサービスのプロバイダと対話する必要なく自動的に、一方的にプロビジョニングすることができる。
広範なネットワーク・アクセス：機能は、ネットワーク上で利用可能であり、異種のシン又はシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、及びＰＤＡ）による使用を促進する標準的な機構を通じてアクセスされる。
リソースのプール化：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを用いて、異なる物理及び仮想リソースを要求に応じて動的に割り当て及び再割り当てすることにより、複数のコンシューマにサービスを提供するためにプールされる。コンシューマは、一般に、提供されるリソースの正確な位置についての制御又は知識を持たないが、より高レベルの抽象化では位置（例えば、国、州、又はデータセンタ）を特定できる場合があるという点で、位置とは独立しているといえる。
迅速な弾力性：機能は、迅速かつ弾力的に、幾つかの場合自動的に、プロビジョニングして素早くスケール・アウトし、迅速にリリースして素早くスケール・インさせることができる。コンシューマにとって、プロビジョニングに利用可能なこれらの機能は、多くの場合、無制限であり、いつでもどんな量でも購入できるように見える。
サービスの測定：クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、及びアクティブなユーザ・アカウント）に適した何らかの抽象化レベルでの計量機能を用いることによって、リソース使用を自動的に制御及び最適化する。リソース使用を監視し、制御し、報告し、利用されるサービスのプロバイダとコンシューマの両方に対して透明性をもたらすことができる。

サービス・モデルは以下の通りである。
Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）：クラウド・インフラストラクチャ上で動作しているプロバイダのアプリケーションを使用するために、コンシューマに提供される機能である。これらのアプリケーションは、ウェブ・ブラウザ（例えば、ウェブ・ベースの電子メール）などのシン・クライアント・インターフェースを通じて、種々のクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定の考え得る例外として、ネットワーク、サーバ、オペレーティング・システム、ストレージ、又は個々のアプリケーション機能をも含めて、基礎をなすクラウド・インフラストラクチャを管理又は制御しない。
Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（ＰａａＳ）：プロバイダによってサポートされるプログラミング言語及びツールを用いて生成された、コンシューマが生成した又は取得したアプリケーションを、クラウド・インフラストラクチャ上に配備するために、コンシューマに提供される機能である。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、又はストレージなどの基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、配備されたアプリケーション、及び場合によってはアプリケーション・ホスティング環境構成に対して制御を有する。
Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）：コンシューマが、オペレーティング・システム及びアプリケーションを含み得る任意のソフトウェアを配備及び動作させることができる、処理、ストレージ、ネットワーク、及び他の基本的なコンピューティング・リソースをプロビジョニンングするために、コンシューマに提供される機能である。コンシューマは、基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、オペレーティング・システム、ストレージ、配備されたアプリケーションに対する制御、及び場合によってはネットワーク・コンポーネント（例えば、ホストのファイアウォール）選択の限定された制御を有する。

配備モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは、ある組織のためだけに運営される。このクラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
コミュニティ・クラウド：クラウド・インフラストラクチャは、幾つかの組織によって共有され、共通の関心事項（例えば、任務、セキュリティ要件、ポリシー、及びコンプライアンス上の考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般公衆又は大規模な業界グループに利用可能であり、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データ及びアプリケーションの移行性を可能にする標準化された又は専用の技術（例えば、クラウド間の負荷分散のためのクラウド・バースティング）によって結び付けられる２つ又はそれより多いクラウド（プライベート、コミュニティ、又はパブリック）の混成物である。

クラウド・コンピューティング環境は、無国籍性、低結合性、モジュール性、及びセマンティック相互運用性に焦点を置くことを指向するサービスである。クラウド・コンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで図１を参照すると、クラウド・コンピューティング・ノードの一例の概略図が示される。クラウド・コンピューティング・ノード１０は、好適なクラウド・コンピューティング・ノードの単なる一例であり、本明細書で説明される本発明の実施形態の使用又は機能の範囲に対するいずれかの制限を示唆することを意図するものではない。上記に関係なく、クラウド・コンピューティング・ノード１０は、本明細書で上述された機能のいずれかを実装及び／又は実施することができる。

クラウド・コンピューティング・ノード１０には、他の多数の汎用又は専用コンピューティング・システム環境又は構成で動作可能な、コンピュータ・システム／サーバ１２が存在する。コンピュータ・システム／サーバ１２と共に用いるのに好適な周知のコンピューティング・システム、環境、及び／又は構成の例としては、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び、上述のシステム又はデバイス等のいずれかを含む分散型クラウド・コンピューティング環境が含まれる。

コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバ１２は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体に配置することができる。

図１に示されるように、クラウド・コンピューティング・ノード１０のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ１２のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ又は処理ユニット１６、システム・メモリ２８、及びシステム・メモリ２８を含む種々のシステム・コンポーネントをプロセッサ１６に結合するバス１８を含むことができる。

バス１８は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。

コンピュータ・システム／サーバ１２は、典型的には、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ・システム／サーバ１２がアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。

システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０及び／又はキャッシュ・メモリ３２など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、ストレージ・システム３４を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピィ・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによってバス１８に接続することができる。以下でさらに示され説明されるように、メモリ２８は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールの組（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

限定ではなく例として、メモリ２８内に、プログラム・モジュール４２の組（少なくとも１つ）を有するプログラム／ユーティリティ４０、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール４２は、一般に、本明細書で説明される本発明の実施形態の機能及び／又は方法を実行する。

コンピュータ・システム／サーバ１２は、キーボード、ポインティング・デバイス、ディスプレイ２４等のような１つ又は複数の外部デバイス１４；ユーザがコンピュータ・システム／サーバ１２と対話することを可能にする１つ又は複数のデバイス；及び／又はコンピュータ・システム／サーバ１２が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）と通信することもできる。このような通信は、入力／出力（Ｉ／Ｏ）インターフェース２２を経由して行うことができる。さらにまた、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、及び／又はパブリック・ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ２０は、バス１８を介して、コンピュータ・システム／サーバ１２の他のコンポーネントと通信する。図示されないが、コンピュータ・システム／サーバ１２と共に他のハードウェア及び／又はソフトウェア・コンポーネントを使用できることを理解されたい。例としては、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システムなどが含まれる。

ここで図２を参照すると、例示的なクラウド・コンピューティング環境５０が示される。示されるように、クラウド・コンピューティング環境５０は、例えば携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、及び／又は自動車コンピュータ・システム５４Ｎなどといった、クラウド・コンシューマによって用いられるローカル・コンピューティング・デバイスと通信することができる、１つ又は複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。これらのノードは、上述のようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、若しくはハイブリッド・クラウド、又はこれらの組み合わせなど、１つ又は複数のネットワークにおいて物理的又は仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを保持する必要のないサービスとして、インフラストラクチャ、プラットフォーム、及び／又はソフトウェアを提供することが可能になる。図２に示されるコンピューティング・デバイス５４Ａ−Ｎのタイプは単に例示であることを意図し、コンピューティング・ノード１０及びクラウド・コンピューティング環境５０は、いずれのタイプのネットワーク及び／又はネットワーク・アドレス指定可能な接続上でも（例えば、ウェブ・ブラウザを用いて）、いずれのタイプのコンピュータ化された装置とも通信できることを理解されたい。

ここで図３を参照すると、クラウド・コンピューティング環境５０（図２）によって提供される機能抽象化層の組が示される。図３に示されるコンポーネント、層、及び機能は単に例示であることを意図し、本発明の実施形態はそれらに限定されないことを予め理解されたい。図示されるように、以下の層及び対応する機能が提供される。

ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例として、ＩＢＭ（登録商標）ｚＳｅｒｉｅｓ（登録商標）システムを一例とするメインフレームと、ＩＢＭ ｐＳｅｒｉｅｓ（登録商標）システムを一例とするＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ（縮小命令セット・コンピュータ））アーキテクチャ・ベースのサーバと、ＩＢＭ ｘＳｅｒｉｅｓ（登録商標）システムと、ＩＢＭ ＢｌａｄｅＣｅｎｔｅｒ（登録商標）システムと、ストレージ・デバイスと、ネットワーク及びネットワーク・コンポーネントとが含まれる。ソフトウェア・コンポーネントの例として、ＩＢＭ ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ・ソフトウェアを一例とするネットワーク・アプリケーション・サーバ・ソフトウェアと、ＩＢＭ ＤＢ２（登録商標）データベース・ソフトウェアを一例とするデータベース・ソフトウェアとが含まれる。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅ、及びＤＢ２は、世界中の多数の管轄区域において登録されているインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。）

仮想化層６２は、抽象化層を提供し、この層により、仮想エンティティの以下の例、すなわち、仮想サーバ、仮想ストレージ、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーション及びオペレーティング・システム、並びに仮想クライアントを提供することができる。

一例においては、管理層６４は、以下で説明される機能を提供することができる。リソース・プロビジョニングは、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格決定は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡と、リソースの消費に対する課金又は請求とを提供する。１つの例においては、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド・コンシューマ及びタスクに対する識別情報の検証と、データ及び他のリソースに対する保護とを提供する。ユーザ・ポータルは、コンシューマ及びシステム管理者のために、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理は、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソースの割り当て及び管理を提供する。サービス・レベル・アグリーメント（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ、ＳＬＡ）の計画及び履行は、ＳＬＡに従って将来の要件が予測されるクラウド・コンピューティング・リソースの事前配置及び調達を提供する。

ワークロード層６６は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロード及び機能の例には、マッピング及びナビゲーション、ソフトウェア開発及びライフサイクル管理、仮想教室教育配信、データ分析処理、トランザクション処理、及びデータ統合ワークフロー処理が含まれる。

例示的な実施形態においては、ワークロード層６６内のＤＴＩＯにより強化された（DTIO enhanced）コンパイラ７０が、本明細書で説明されるＤＴＩＯシーケンスを生成するが、強化されたコンパイラ７０は、いずれの層内にも実装することができ、かつ、ハードウェア及びソフトウェア層６０内の種々のハードウェア・プラットフォーム上で実行されるコードを生成するために用いることができることが理解されるであろう。

例示的な実施形態においては、ワークロード層６６内のＤＴＩＯにより強化されたリンカ８０が、本明細書で説明されるＤＴＩＯシーケンスを生成し、ＴＯＣ参照を最適化するが、強化されたリンカ８０は、いずれの層内にも実装することができ、かつ、ハードウェア及びソフトウェア層６０内の種々のハードウェア・プラットフォーム上で実行されるコードを生成するために用いることができることが理解されるであろう。

１つの実施形態において、ＤＴＩＯシーケンスを生成するように最適化された強化されたコンパイラ７０は、クラウド環境５０において実行されるコンピュータ・システム／サーバ１２の処理ユニット１６上、又は、クラウド環境５０用のアプリケーションを開発するように適合されたシステム５４Ａ、５４Ｂ若しくは５４Ｃ上で実行される。１つの実施形態において、アプリケーションにおけるテーブル参照をリンクし、最適化するように最適化された強化されたリンカ８０が、クラウド環境５０の同じサーバ１２の処理ユニット１６、又はシステム５４Ａ、５４Ｂ、若しくは５４Ｃの１つにおいて実行される。別の実施形態において、強化されたコンパイラ７０及び強化されたリンカ８０は、クラウド環境５０に対応する少なくとも１つのサーバ若しくはコンピュータ・システムの異なる処理ユニット１６、又はシステム５４Ａ、５４Ｂ及び５４Ｃ上で実行される。

強化されたコンパイラ７０及び強化されたリンカ８０は協働して、処理ユニット１６上での実行に向けられたアプリケーションを生成し、生成されたアプリケーションが、クラウド環境５０のサーバ１２内、又はシステム５４Ａ、５４Ｂ、５４Ｃ及び５４Ｎのうちの少なくとも１つの内部で実行される際にＤＴＩＯを実施する。生成されたアプリケーションは、仮想ストレージ６２、外部デバイス１４、又は、内部にインストールされたシステム・フラッシュ・メモリなどの別のソリューションのようなストレージ媒体内に格納される。

ここで図４を参照すると、一実施形態によるＴＯＣ４０２及びデータ・オブジェクト４０４（データ「Ａ」と表記される）が、一般的に示される。ＴＯＣ４０２は、変数にアクセスするために用いられ、かつ、アプリケーション・コードがデータにアクセスするための位置に依存しない方法を提供することにより、共有ライブラリをサポートする。ＴＯＣは、共有ライブラリへの外部参照を解決するために用いられ、ここで、ＴＯＣ内の各アドレス・エントリは、変数のアドレスを収容する。アプリケーション・コード及びデータは互いに固定されていないので、ＴＯＣは、同一のアプリケーション・コードが異なるデータを参照することを可能にする。図４に示されるＴＯＣ４０２は、レジスタ「Ｒ２」内に収容されるアドレスから開始し、オフセット「Ｄ１」におけるエントリを含む複数のエントリ（各々が変数のアドレスを含む）を有する。オフセット「Ｄ１」におけるエントリのアドレスは、データ・オブジェクト４０４の開始アドレスである。図４に示されるデータ・オブジェクト４０４は、データ・オブジェクト４０４の開始アドレスからオフセット「Ｄ２」において格納されたデータを有する。

以下のオブジェクト・コード・シーケンスは、データ・オブジェクト４０４におけるオフセット「Ｄ２」において格納されたデータを、レジスタ「Ｒ４」にロードする。
ld R3=R2+D1
ld R4=R3+D2

第１のロード命令は、データ・オブジェクト４０４のアドレスを、ＴＯＣ４０２のオフセット「Ｄ１」からレジスタ「Ｒ３」にロードし、第２のロード命令は、データを、データ・オブジェクト４０４のオフセット「Ｄ２」からロードする。

前述のように、他のアプリケーション・バイナリ・インターフェース（ＡＢＩ）定義において、ＴＯＣに類似したテーブルは、ＧＯＴと呼ばれる。ＴＯＣ４０２に言及する本明細書での説明は、ＧＯＴにも同様に適用することができる。

強化されたコンパイラ７０のようなコンパイラ及び強化されたリンカ８０のようなリンカは協働して、ＴＯＣを介して変数を参照するコードを生成する。コンパイラは、オブジェクト・コードを生成し、ＴＯＣロード命令とシンボル・テーブル・エントリ（例えば、グローバル変数）との間のリンクを作成する。リンカは、シンボルの定義及び参照を解決し、データの全てをマッピングし（ＴＯＣを構築し）、次いで、コンパイラにより生成されたＴＯＣロード命令上の変位フィールドに値を入力する。

コンパイラが、データ・オブジェクト４０４のアドレスのＴＯＣ４０２におけるオフセット位置を知らない場合、コンパイラにより、データ・オブジェクト４０４のオフセット「Ｄ２」において格納されたデータをレジスタ「Ｒ４」にロードするための以下のオブジェクト・コード・シーケンスが生成される。
ld R3=R2+0 [Ref: Symbol “A”]
ld R4=R3+D2
Symbol = “A”
Length = 24
Alignment =8
等

リンカは、アプリケーションを互いにリンクする際、オフセットをＴＯＣに挿入する。上記コードのシンボル、長さ、及びアライメント部分は、リンカにデータ・オブジェクトについて伝え、それを第１のロード・ステートメントに結び付ける。リンカは、シンボル「Ａ」を解決し、データをマッピングし、Ｄ１におけるＴＯＣエントリを割り当て、次いで、関連したＴＯＣロード命令内の変位フィールドに上書きする。

メモリ・アクセス命令内の即値変位フィールドのアドレス指定範囲は、何がコンピュータ・アーキテクチャによりサポートされるかによって制限される。例えば、ＩＢＭ Ｐｏｗｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標）において、変位は、１６ビットに制限され、これはベース・レジスタからの６４キロバイト（ＫＢ）以内のデータをアドレス指定するための能力を提供する。他のＡＢＩは、３２ビット又は６４ビットに制限される。変数の数が、ＴＯＣによりサポートされるエントリの数より大きい場合、これらの制限が問題を引き起こすことがある。

ＴＯＣ参照を生成するために用いられる命令セット（例えば、Ｄ−ｆｏｒｍ、ＤＳ−ｆｏｒｍ）及び規則は、事実上、ＴＯＣのサイズを制限する。Ｄ−ｆｏｒｍ命令は、ＰｏｗｅｒＰＣ（登録商標）プロセッサに対する一次メモリ・アクセス命令形式の１つであり、これは、ロード、ストア、及び即値モード計算を実施するために用いられ、１６ビット・アドレス・フィールドに制限される。Ｄ−ｆｏｒｍ命令のフォーマットは、ビット０−５におけるオペコード、ビット６−１０におけるソース／ターゲット・レジスタ、ビット１１−１６におけるアドレス／指標レジスタ／オペランド、及びビット１６−３１における数値アドレス／オフセット／即値モード値である。従って、アドレス・フィールドは、１６ビットのみであり、６４ＫＢのアドレス範囲に変換される。リンカは、レジスタを有することにより、符号付き１６ビット変位（＋／−３２ＫＢ）を用いてＴＯＣをマッピングする（例えば、レジスタ「Ｒ２」はＴＯＣの中央を指し示す）。ＤＳ−ｆｏｒｍ命令は、Ｄ−ｆｏｒｍ命令と同じアドレス範囲を有するが、３２ビットのアラインされたメモリに制限される。

ＴＯＣのスペースがなくなる（例えば、６４０００すなわち６４Ｋを上回る変数が存在する）、リンカはエラー・メッセージを有した状態で機能しなくなることがある。代替的に、リンカは、複数のＴＯＣを作成し、「トランポリン（trampoline）」コードを用いて、複数のＴＯＣ間で切り替えることができる。従って、要求された変数が現在のＴＯＣ内に存在しない場合、要求される変数にアクセスするために、代替的なＴＯＣのアドレスがロードされる。例えば、参照シンボル「Ａ」のオフセットが命令の変位オフセットに適合しない場合のオブジェクト・コードが、以下に示される。：
ldR3=R2+0 [Ref: Symbol “A”]
ld R4=R3+D2
リンカにより、オブジェクト・コードに変換される。
b L1
L2: ld R4=R3+D2
........
L1:addis R3=R2,1
ld R3=R3+D1
b L2

上に示されるように、リンカにより、分岐命令が付加される。この例では、メモリ内に互いに隣接して配置された２つの６４ＫＢのＴＯＣが存在する。第１のＴＯＣのベースは、レジスタ「Ｒ２」内に収容されるメモリのアドレス内に配置され、第２のＴＯＣのベースは、レジスタ「Ｒ２」内に収容されるアドレス＋６４ＫＢに配置される。第２のＴＯＣのベースは、レジスタ「Ｒ２」のコンテンツを左に１６位置だけシフトさせて第２のＴＯＣの位置を得る「ａｄｄｉｓ」命令を用いて、上に示されるように計算される。次いで、第２のＴＯＣのベースに関して、オフセット「Ｄ１」が計算され、コードは再び「Ｌ２」に分岐して処理を続行する。

従って、上に示されるように、より多数の変数に適応させるために、リンカは、付加的な命令をオブジェクト・コードに導入し、コード拡張及び低速実行の両方をもたらす。上に示されるような、ＴＯＣオーバーフロー・トランポリンの使用は、付加的なトランポリン・コードに起因する過度のコード拡張をもたらし、参照ごとに２つの付加的な制御フローを導入する。このことは、参照のローカル性の損失に起因するキャッシュ性能の低下、並びに、トランポリンへの分岐により導入される不連続のコードに起因する命令フェッチ性能の低下をもたらし得る。

ＴＯＣのサイズは、実行ファイル又は共有ライブラリのサイズに概ね比例する。一般に、何百ものソース・ファイル及び何万行ものコードが存在する。あらゆる固有の参照される外部シンボル（データ又はコード）は、ＴＯＣエントリを有する。上述のように、ＴＯＣの容量は、３２ビット・モードにおいて１６Ｋエントリであり、６４ビット・モードにおいては８Ｋエントリである。データがＴＯＣ内に格納される場合、付加的なＴＯＣのスペースが消費される（例えば、間接（indirection）レベルを除去することにより経路長を短くするために）。

ＴＯＣオーバーフローの問題を解決する別の現代の手法は、より大きい変位を有する新しい命令を導入することである。この手法は、より大きい変位値をサポートするコンピュータ・プラットフォームには有効であるが、新しい命令を用いるコードは、より大きい変位値をサポートしていない旧式のコンピュータ・システム又は他のコンピュータ・プラットフォーム・システム（例えば、ＩＢＭ ＲＩＳＣアーキテクチャ）上では実行可能でない。ほとんどの場合、アプリケーション・コードは、可能な限り多くの環境において実行可能であることが望ましく、開発者は、旧式のプラットフォーム上でコードを実行する能力を制限する新しい命令フォーマットの使用をためらう。

本明細書で説明される実施形態は、命令セット内の直接指定された変位により決定されるＴＯＣサイズに対するＴＯＣオーバーフローにより特徴付けられる環境において、グローバル・データにアクセスする際、プロセッサ（例えば、マイクロプロセッサ）により実行しなければならない内部操作の数を減らす。複数の命令を最適化し、組み合わせて、命令シーケンスにおいて、第２の命令を、第１の命令とは独立して実行できる内部操作（内部命令）に置き換えるためのハードウェア・プロセスは、本明細書では、デコード時間命令最適化（ＤＴＩＯ）と呼ばれる。第１の命令の実行において、第２の命令を実行する前に第１の命令を実行する必要がなく、又は、第１の命令を内部実行から排除することができる。ＤＴＩＯは、プロセッサが、最適化された命令シーケンスに基づいて改善された命令シーケンスを生成することを可能にする技術である。本明細書で説明される実施形態によると、コンパイラは、プロセッサにおけるＤＴＩＯ機能を利用するように適合されたＡＢＩシーケンスを生成する。大容量のＴＯＣ／ＧＯＴを有するプログラムの効率的な実行をサポートするために、プロセッサは、ＤＴＩＯをキー・シーケンスで実行するように適合される。

ＤＴＩＯを、コンパイラにより生成された以下のコード・シーケンスに適用し、このコード・シーケンスを組み合わせてより効率的に動作する２つの命令にする。以下に示されるオブジェクト・コードは、オフセット値（リンク・プロセスの際にリンカにより入力される）の上位１６ビットを、ＴＯＣの開始アドレス（アドレスは、レジスタ「Ｒ２」に格納される）に加算し、結果をレジスタ「Ｒ５」に格納する（Ｒ２＋０×１２３４００００）。第２の命令は、メモリ・コンテンツのアドレスを、レジスタ「Ｒ５」に格納されているアドレスと、オフセット値の下位１６ビットの和としてロードする（Ｒ２＋０×１２３４００００＋０×００００５６７８）。その結果、レジスタ「Ｒ３」が、データ・オブジェクトのアドレスを収容する。レジスタ「Ｒ５」の値が決定されるまで第２の命令を実行できないという点で、第２の命令は第１の命令に依存している。
addis R5, R2, 0x1234
ld R3=R5+0x5678

１つの例示的な実施形態において、ＤＴＩＯを実施するようにイネーブルにされたプロセッサ・ユニット１６が、上記のコード・パターンを識別し、これを、互いに依存していない以下の２つの内部命令（又は、内部操作）に置き換える。

別のコード命令がレジスタ「Ｒ５」に格納された値を使用する場合、第１の命令の結果を計算する。ＤＴＩＯにより生成された第２の内部命令、すなわちロード命令が１つの計算を実行し、この計算は、上記の隣接した２つの命令シーケンスにより既に実行されている。内部ロード命令（Ｐｏｗｅｒ ＩＳＡによりサポートされるよりも広範囲のオフセット値を処理することができるロード命令）は、上記の命令からの組み合わせられたオフセットの値を、レジスタ「Ｒ２」に格納されたアドレスに加算する。
addis R5, R2, 0x1234
ld R3=R2+0x12345678

後の命令がレジスタ「Ｒ５」内の値を読み出す場合、レジスタ「Ｒ５」内の中間結果を保存する必要があるため、上記のコード・シーケンスは、非破壊的（non-destructive）オペランド・シーケンスと呼ばれる。有利なことに、第２の命令を、第１の命令に対してアウト・オブ・オーダー方式で実行し、ロード命令の完了を加速することができる。

上に示される第１のコード・シーケンスは、以下のようにＧＯＴアクセス・シーケンスとして書くことができる。
addis R5, R2, label@got@h
ldreg, label@got@l(R5)

このコード・シーケンスは、プロセッサ・ユニット１６により、ＤＴＩＯを用いて、以下のシーケンスに対応する内部操作（ＩＯＰ）シーケンスに最適化される。
addis R5, R2,label@got@h
ldreg, label@got(R2)

第１の命令は、ａｄｄ ｓｈｉｆｔ ｉｍｍｅｄｉａｔｅ ＩＯＰであり、第２の命令は、ｌｏａｄ ＩＯＰである。この非破壊的コード・シーケンスにおいて、ＤＴＩＯシーケンスが実行を完了した後、レジスタ「Ｒ５」はアーキテクチャ化された状態の一部であるので、第１の命令を排除することはできない。有利なことに、第２の命令を、第１の命令に対してアウト・オブ・オーダー方式で実行し、ロード命令の完了を加速することができる。当業者であれば、１つの実施形態において、＠ｈは、文脈依存（context-sensitive）とすることができ、ａｄｄｉｓ命令と共に用いられる場合、ｄｅｆｉｎｉｔｉｏｎ ａｄｄｉｓ命令に対応して計算された上位ビットを指すために用いることができ、かつ、従来技術と関連したｏｒｉｓ命令と共に用いられる場合、ｄｅｆｉｎｉｔｉｏｎ ｏｒｉｓ命令に対応して計算された上位ビットを指すために用いることができることを理解するであろう。当業者であれば、別の実施形態において、２つの異なる指定子＠ｈａ及び＠ｈが文脈非依存（context insensitive）方式で用いられ、＠ｈａは、ａｄｄｉｓ命令と共に用いられる場合、ｄｅｆｉｎｉｔｉｏｎ ａｄｄｉｓ命令に対応して計算された上位のビットを指すために用いられ、＠ｈは、従来技術と関連したｏｒｉｓ命令と共に用いられる場合、ｄｅｆｉｎｉｔｉｏｎ ｏｒｉｓ命令に対応して計算された上位のビットを指すために用いられることを理解するであろう。

少なくとも１つの実施形態において、ＤＴＩＯを実装するマイクロプロセッサ・ユニット１６により修正される第２のコード・シーケンスは、次の通りである。レジスタ「Ｒ３」は第２の命令により上書きされるので、このコード・シーケンスは、破壊的オペランド・シーケンスと呼ぶことができる。
addis R3, R2, 0x1234
ld R3=R3+0x5678

これらの２つの命令は、以下のように単一のｌｏａｄ ＩＯＰに併合される。
ld R3=R2+0x12345678
有利なことに、２つの依存する操作のシーケンスの代わりに、１つのＩＯＰしか実行する必要がない。

上に示される第２の破壊的オペランド・コード・シーケンスは、以下のようにＧＯＴアクセス・シーケンスとして書くことができる。
addis reg, R2,label@got@h
ld reg,label@got@l(reg)

このコード・シーケンスは、ＤＴＩＯを実装するプロセッサ・ユニット１６により、単一のロード命令を含む以下のシーケンスに対応する単一のＩＯＰに最適化される。
ld reg,label@got(R2)

本明細書で説明される実施形態は、大容量のＴＯＣ（すなわち、命令指定の変位によって与えられるアドレス指定能力に関してオーバーフローするＴＯＣ）にアクセスするように適合された命令シーケンスを含むプログラムに向けられる。ＴＯＣにアクセスするための命令シーケンスは、ＤＴＩＯプロセスによってさらに最適化することができる一連の計算命令を含む。最適化は、クリティカル依存チェーン（critical dependence chain）における、ＴＯＣにアクセスするための内部操作の数を低減させる。ＤＴＩＯに従う破壊的形式のＴＯＣアドレス指定を用いる最適化された環境において、ＴＯＣにアクセスするための内部操作の実際の数が低減される。

ＤＴＩＯ最適化を用いる利点は、コード・シーケンスが、ＤＴＩＯに対するハードウェア・サポートを有するプロセッサと、従来のプロセッサ（又は、非ＤＴＩＯサポート型ハードウェア）の間で完全に移植可能であることである。１つの実施形態において、ＤＴＩＯにより最適化されたシーケンスは、既存のＩＳＡに従った命令シーケンスに対応する。コンパイラ及びリンカは協働して、ＤＴＩＯをサポートするマイクロプロセッサにおいてＤＴＩＯの最適化をもたらす方法で、シーケンスをアセンブルする。ＤＴＩＯをサポートしないマイクロプロセッサにおいては、従来技術の命令からなるシーケンスは、既存のＩＳＡに従ったあらゆる他の命令シーケンスのように、直接かつ矛盾なく実行される。

図５は、本発明の一実施形態による、ＴＯＣ参照を生成するために、コンパイラにより実施されるプロセスのフロー図を示す。一実施形態において、プロセスは、図３に示される強化されたコンパイラ７０により実施される。ブロック５０２において、ＴＯＣ参照に関する複数命令に対応する内部表現が生成される。これらの命令は、前述のようにＤＴＩＯプロセスにより最適化される。

ブロック５０４において、ＤＴＩＯをもたらす方法で複数命令が発行されることを保証するように、コンパイラ内のスケジューラ・コスト関数が修正される。本明細書で用いられる「スケジューラ」という用語は、「命令スケジュール」の生成、すなわち、命令がプログラム内で現れる順序の割り当てを担当するコンパイラの部分を指す。スケジューラの目的の１つは、典型的には、依存命令を互いからできるだけ離れるように移動させ、第１の命令に完了のための時間を与えてから、第２の依存命令がその結果を消費するようにすることである。多くの場合、これは、命令が互いの特定の範囲内にある、又は互いに隣接しているなど、ＤＴＩＯ実装命令に対する特定の要件を有し得るＤＴＩＯ実装プロセッサと競合する。従って、典型的なスケジューラは、ＤＴＩＯ対応プロセッサにおいてＤＴＩＯをサポートする方法では命令を順序付けない。コンパイラ内のコスト関数を修正できる１つの方法は、第１の命令がＴＯＣアクセス・シーケンスの一部として生成される際に、第１の命令（例えば、ａｄｄｉｓ）に関するコスト関数をゼロに設定することによるものである。これは、ａｄｄｉｓ命令がＴＯＣシーケンスと関連付けられたときに、ａｄｄｉｓ命令に対して新しい命令レジスタ（ＩＲ）を割り当てることにより行うことができる。次いで、スケジューラは、第１のａｄｄｉｓ命令及び第２の命令を互いに隣接してスケジューリングする傾向を有する。ゼロのコスト・メトリックを有する命令がコンシューマに隣接してスケジューリングされることを保証するように、スケジューラをさらに修正することができる。ＤＴＩＯをもたらす方法で複数命令が発行されることを保証する別の方法は、ＴＯＣシーケンスの第１の命令を、そのＴＯＣシーケンスの第２の命令に隣接してスケジューリングするように、スケジューラを修正することである。これは、ＴＯＣシーケンスと関連付けられたａｄｄｉｓに対して新しいＩＲを割り当てることによって行うことができ、ＴＯＣ参照のために第１の命令をスケジューリングするときに、第２の命令をスケジューリングする。ＤＴＩＯをもたらす方法で複数命令が発行されることを保証する更に別の方法は、ＤＴＩＯを適用できるａｄｄｉｓ命令及び依存命令の対形成を認識し、次いで、スケジューラにそれらの命令を互いに隣接してスケジューリングさせるように、スケジューラを修正することである。

図５を参照すると、ブロック５０６において、コンパイラは、例えば、再配置情報の形でリンカへの命令を生成して、ＧＯＴ／ＴＯＣの一部であることを必要とするＴＯＣ（又はＧＯＴ）参照内のいずれかのエントリ、並びに、どの命令が、命令に挿入される完了したＴＯＣ内のオフセットに対応するオフセットの少なくとも一部を有する必要があるかを示す。１つの実施形態によると、複数命令シーケンスを示すように、再配置情報が生成される。別の実施形態によると、従来技術に従って、参照に関するオフセットの第１の部分及び参照に関するオフセットの第２の部分を示す別個の関係情報が生成される。

図６は、本発明の代替的な一実施形態による、ＴＯＣ参照を生成するために、コンパイラにより実施されるプロセスのフロー図を示す。図６に示される実施形態は、コンパイラがＴＯＣ参照ＩＲ機能を有する場合に用いることができる。このことは、コンパイラが、ＴＯＣ参照のために、コード内にシーケンスとして発行される単一の内部表現を使用すること、及び、命令のスケジューリングに対してこのシーケンスの実行をより正確にモデル化することを可能にし、ＩＲにおいて「ゼロ・コスト」ａｄｄｉｓ型命令を可能にするための修正を必要としない。単一のＩＲ参照のようなＴＯＣ参照のＩＲ表現によると、命令カウントを認識する必要があるコンパイラの部分が、ＯＣ相対分岐に関する変位を追跡するため、命令グループ形成をモデル化するため、分岐ターゲットを所望の境界にアラインさせるなどのために、複数のＩＳＡ命令のようなＴＯＣ参照ＩＲ機能が発行されるという事実を認識するように修正される。

ブロック６０２において、ＴＯＣ参照に対応するＩＲ表現を生成し、このＩＲ表現がＴＯＣ参照であることをプロセッサに知らせる。ブロック６０４において、ＴＯＣ参照に対応するＩＲ表現が複数命令に拡張されるが（例えば、コード・オフセット及び命令のグループ化に関する判断に関して）、ＤＴＩＯ実装のＩＯＰシーケンスの待ち時間が低減することを理解するように、コンパイラ内のスケジューラ及びコード生成装置を修正する。従って、命令のフォーマットのために、ＴＯＣ ＩＲ参照シーケンスは、コンパイラによりオブジェクト・ファイル内に発行されるときに複数命令として扱われるが、ＩＲ参照のタイミング挙動をモデル化するために、実行時にハードウェアにおいてＤＴＩＯ機能により生成された内部操作シーケンスを用いて、スケジューリングを決定する。

ブロック６０６において、ＴＯＣ ＩＲを複数機械命令として拡張することにより、コードが生成される。ブロック６０８において、リンク・エディタによりリンクするために、オブジェクト・ファイルが発行される。図６に示される実施形態において、コンパイラは、ＴＯＣロードがバイナリで１つより多いロード命令を使用するが、ＤＴＩＯ実装のシーケンスに対応する低減した数のサイクルで実行され得ることを反映する、ＴＯＣ参照についての新しいＩＲコードをサポートするように拡張される。

別の実施形態において、プログラマは、ＤＴＩＯ実装できる、ＴＯＣ参照を含むアセンブリ・コードを生成し、アセンブラはオブジェクト・ファイルを生成する。プログラマは、ＤＴＩＯ実装のシーケンスに対応する複数のアセンブリ命令の生成を担当することができる。代替的に、複数のＤＴＩＯ命令を含むＴＯＣロード・シーケンスを生成する、アセンブラ固有の拡張されたニーモニック（mnemonic）又はマクロが提供される。

例えば、強化されたアセンブラは、強化された構文＠ｇｏｔ３２を受け入れ、破壊的形式の２つの命令シーケンスａｄｄｉｓ／ｌｄを生成する。この例において、単一のアセンブラ操作：
ld reg,lable@got32(R2)
は、
addis reg,lable@got@ha(R2)
ld reg,lable@got@l(reg)
と同等であるバイナリ命令及び再配置を生成する。

これは現在のＰｏｗｅｒＩＳＡと一致し、ＤＴＩＯ機能なしのＰｏｗｅｒＩＳＡプロセッサ上で正確に実行されるが、この操作がＤＴＩＯ対応プロセッサ上で最適に実行されるというプログラマの意図を反映する。

ハードウェアの制約が、ＤＴＩＯプロセスに影響を与えることがある。例えば、一部のハードウェア・システムが、破壊的ＤＴＩＯシーケンスしかサポートしないことがある。他のハードウェア・システムにおいて、ＤＴＩＯプロセスを施すことができる変位サイズに制限が存在する（例えば、２１ビット又はそれより少ないオフセットに制限される）。これらの制限をコンパイラ及び／又はプログラマに伝えるので、コンパイラ及び／又はプログラマは、どのシーケンスがターゲット・ハードウェアのＤＴＩＯ機能にマッピングされるかを認識することができる。

例えばＬｉｎｕｘシステムのためにコンパイルする場合などの幾つかの実施形態において、コンパイラは、変位をＴＯＣベースに加算することにより、メイン・モジュールがアドレスを計算する（アドレスをＧＯＴからロードするのではなく）際に、ＴＯＣ内のデータ・アドレスを導出することによりデータ・アドレスを生成するように最適化される。例示的なコード・シーケンスは、以下の通りである。
addis reg,R2,label@got@h
ld reg,label@got@l(reg)

本発明の１つの態様において、このコードは、コード生成の際にコンパイラによって、又は、リンクの際にリンカによって、以下のコード・シーケンスに置き換えることができる。
addis reg,R2,label@toc@ha
addi reg,reg,label@toc@l

コンパイラにおけるコード生成によりハードウェア・ベースのＤＴＩＯをイネーブルにする一態様によると、次に、ＤＴＩＯを実装するマイクロプロセッサ１６は、置換コード・シーケンスを以下のコード・シーケンスに最適化する。
addireg,reg,label@toc

ａｄｄｉｓ／ａｄｄｉを用いたＴＯＣ参照の生成をターゲットとする最適化を適用することもできる。これは、図６に示されるプロセスに従ったＴＯＣ／ＧＯＴ−ロード参照ＩＲポイントに加えて、ＴＯＣ−計算ＩＲを割り当てること、及び図５に示されるプロセスに従ったａｄｄｉｓ／ａｄｄｉの組み合わせに関するメトリックを修正することを含むことができる。

コンパイラはまた、ＧＯＴロードの性能を改善し、その後ＴＯＣデータ参照を続けることもできる。例示的なコード・シーケンスは以下の通りである。
addis reg,R2,label@got@h
ld reg,label@got@l(reg)
ld reg,structure_offset(reg)

このコード・シーケンスは、以下のコード・シーケンスに置き換えることができる。
addisreg,R2,(label+structure_offset)@toc@h
ldreg,reg,(label+structure_offset)@toc@l

次に、ＤＴＩＯにより、置換コード・シーケンスが以下の単一のＩＯＰとして最適化される。
ld reg,reg,(label+structure_offset)@toc //iop

ｓｔｒｕｃｔｕｒｅ＿ｏｆｆｓｅｔは、多くの場合、ゼロであることに留意されたい。この手法はまた、非整数データをロードするための非整数ロードに用いることもできるが、形式は破壊的ではなく、従って、非破壊的ＤＴＩＯに対するサポートを必要とする。

ＤＴＩＯにより強化されたリンカ８０のようなリンカの実施形態が、図７−図１１を参照して以下に説明される。本明細書で説明されるリンカは、ＤＴＩＯ機能を提供するプロセッサ及びＤＴＩＯ機能を提供しないプロセッサの両方に対して、ＴＯＣ及び／又はＧＯＴ参照に関連したコンパイラ生成コードの性能を最適化する。当業者であれば、これらの最適化は、プログラムのコンパイル全体が完全にリンクされたオブジェクト・コードを生成することを含む場合に、コンパイルの一部としても実施し得ることを認識するであろう。

図７は、本発明の一実施形態による、リンクされたオブジェクト・ファイルを作成するために、リンカにより実施されるプロセスのフロー図を示す。一実施形態において、リンカ・プロセスは、強化されたリンカ８０により実施される。ブロック７０２において、リンカはオブジェクト・ファイルを読み出し、指定子：＠ｔｏｃ＠ｌ、＠ｔｏｃ＠ｈ、＠ｇｏｔ＠ｌ、及び＠ｇｏｔ＠ｈのうちの１つ又は複数を見つける。リンカは、ＴＯＣ及び／又はＧＯＴを構築した後、これらの指定子を、ＴＯＣ及び／又はＧＯＴ内の指定されたデータ及び／又はデータ参照の実際の上位及び下位アドレス・オフセットに置き換える。一般に、強化されたコンパイラ７０により生成されたコードは、ＴＯＣ及び／又はＧＯＴにおけるデータ・レイアウト及びＤＴＩＯ実装コード（すなわち、ＤＴＩＯハードウェア機能により最適化されたコード）におけるアドレス指定範囲の使用；実現可能であれば、ＧＯＴロードの代わりのＴＯＣアドレス計算の使用；及びＤＴＩＯハードウェア・サポートを有さないプロセッサにおける改善された実行のための不必要なａｄｄｉｓ命令の排除のうちの１つ又は複数に関して、リンカによりさらに最適化され得る。

ブロック７０４において、リンカは、ＴＯＣの中点を動的に判断する。ＴＯＣは、符号付き変位を用いるので、ＴＯＣの中点を見つけることにより、データ構造にわたり最も良好な範囲の低コストのアドレス指定が与えられる。性能上の理由で、アドレスの約半分が中点の上にあり、アドレスの約半分が中点の下にあることが望ましい。現代のリンカにおいて、このステップの前にＴＯＣのサイズが固定される（例えば、１６Ｋエントリに）ため、中点は静的に判断される。本明細書で説明される実施形態において、ＴＯＣは、固定されたサイズではなく、リンカによりリンクされるオブジェクト・コード・セグメント内の変数の数に基づいて拡張可能である。ＴＯＣのサイズが固定されていないので、ＴＯＣの中点は、リンク・プロセスの一部として、全ＧＯＴ及びデータ・サイズに基づいて判断する必要がある。ブロック７０４は、ＴＯＣに関して説明されたが、同じプロセスを、ＧＯＴに関してリンカにより実施することができる。

ブロック７０６において、これらに限定されるものではないが、参照シーケンス・プルーニング、参照頻度ベースのＴＯＣ及び／又はＧＯＴパッキング、並びに、ＧＯＴロードからＴＯＣ計算への拡張を含む、参照コードの最適化が実施される。これらの参照コード最適化の各々の実施形態が、本明細書で以下に説明される。ブロック７０８において、リンカは、リンケージ・ステップ（例えば、リンク時間において解決されるシンボルへの全ての参照を実際の値に置き換え、リンクされた複数のオブジェクト・ファイルを組み合わせて単一のオブジェクト・ファイルにし、随意的に、ｇｌｉｎｋ又はＰＬＴスタブのような呼び出しスタブを付加する）を実施し、＠ｌ及び＠ｈの定義に従って、リンクされた実行ファイルを生成し、ここで、シンボル値の上位及び下位部分がリンクされた実行ファイルに挿入される。ブロック７１０において、プログラムのロード及び実行のために、リンクされたオブジェクト・ファイルが発行される。

一実施形態において、強化されたリンカ８０のようなリンカを用いて、メモリ参照シーケンス・プルーニングなどのメモリ参照コードの最適化プロセスを実施する。一実施形態において、メモリ参照シーケンス・プルーニングは、複数の命令を含み、かつ、ベース・アドレスからのオフセットを指定する、オブジェクト・ファイル内のコード・シーケンスを識別することを含む。ベース・アドレスからのオフセットは、変数のアドレス及びデータの一方を格納するように構成されたメモリ内のオフセット位置に対応する。識別されたコード・シーケンスは、メモリ参照関数及びメモリ・アドレス計算関数の一方を実施するように構成される。メモリ参照シーケンス・プルーニングを安全に適用するために、オフセット位置は、ベース・アドレスの指定範囲内になければならず、かつ、置換コード・シーケンスへの識別されたコード・シーケンスの置換が、プログラム意味論を変更することはできない（すなわち、プログラムの挙動を変えない）。プルーニングが「安全」である場合、オブジェクト・ファイルにおいて、識別されたコード・シーケンスが置換コード・シーケンスに置き換えられ、置換コード・シーケンスは、無動作（no-operation、ＮＯＰ）命令又は識別されたコード・シーケンスよりも少ない命令を含む。本明細書で用いられる「メモリ参照関数」という用語は、アドレスを計算し、読み出し操作又は書き込み操作を用いて、計算されたアドレスによって識別されたメモリ位置にアクセスする動作を指す。ｌｄ、ｌｗｚ ｓｔｄ、又はｓｔｗ、並びにｌｆｄ ｓｔｆｄなどの命令は、メモリ参照関数を実行するＰｏｗｅｒ ＰＣ命令の例である。メモリ参照関数の例は、ＴＯＣ参照関数である。本明細書で用いられる「メモリ・アドレス計算関数」という用語は、（例えば、変位をベース・アドレスに加算することにより）メモリ・アドレスを計算する動作を指す。ｌｄ、ｌｗｚ ｓｔｄ、又はｓｔｗ、並びに、ｌｆｄ ｓｔｆｄのような命令は、メモリ参照関数を実施するＰｏｗｅｒ ＰＣの命令の例である。メモリ参照関数の例は、ＴＯＣ参照関数である。本明細書で用いられる「メモリ・アドレス計算関数」という用語は、メモリ・アドレスを計算する（例えば、変位をベース・アドレスに加算することによって）動作を指す。メモリ・アドレス計算の例は、要素のアドレスを計算することである。例えば、データ項目のベース・アドレスがレジスタＲ５内に存在し、コンパイラがＲ７内のｓｔｒｕｃ＿ｏｆｆｓｅｔにおける構造フィールドのアドレスを導出する必要があると考える。コンパイラは、構造フィールドのメモリ・アドレスを計算するために、以下のシーケンス：addis R7,R5, struc_offset@ha ; addi R7,R7,struc_offset@l
を発行することができる。

図８は、一実施形態に従って、メモリ参照シーケンス・プルーニングの最適化を実施するための、リンカにより実施されるメモリ参照コード最適化プロセスのフロー図を示す。一実施形態において、図８に示されるプロセスは、強化されたリンカ８０により実施される。前述のように、強化されたコンパイラ７０は、大きな変位を必要とするメモリ参照のために、単一の命令ではなく複数命令シーケンスを生成することができる。一例は、ＴＯＣ参照アクセスである。本発明の別の態様によると、大きな変位を有した状態でデータ参照にアクセスし、例えば、Ｃアレイ参照において：
char x[BIG_SIZE], y;
y = x[BIG_OFFSET]
は、アレイ・ベースｘがレジスタ５に割り当てられるとき、以下のように変換することができ、値ｙは、レジスタＲ２０にロードされるはずである。
addis R20, R5 (array base),(LARGE_OFFSET*4)@ha
ld R20, R20, (LARGE_OFFSET*4)@l

ＤＴＩＯハードウェア・サポートを有するマイクロプロセッサにおいて、複数命令シーケンスが、ハードウェアにより以下のように（依存チェーンにおける）単一のＩＯＰ操作に置き換えられる。
ld R20, R5, (LARGE_OFFSET*4)

この置換は、ＤＴＩＯハードウェア・サポートを有さないプロセッサでは行われず、図８に示されるプロセスは、プルーニングすることができる複数命令シーケンスを識別するために用いられる、リンカにおけるプロセスを提供する。

ブロック８０２において、複数命令メモリ参照シーケンスと関連した命令を識別する。複数命令ＴＯＣ参照シーケンスは、複数命令メモリ参照シーケンスのフォーマットと一致する依存命令を探すことによって、識別することができる。代替的に、シーケンスは、こうしたシーケンスを明確に識別するオブジェクト・コード・フォーマットを有することにより、識別することができる。ブロック８０４において、識別された参照が、プルーニングされたシーケンスにロードすることができるオフセットを有する参照に対応するかどうかを判断し、ブロック８０６において、コード・シーケンスに対してプルーニングを実行できるかどうか（プルーニングが「安全」かどうか）を判断する。オフセットをプルーニングされたシーケンスにロードすることができ、かつ、プルーニングは安全であると判断された場合、処理は、ブロック８０８からブロック８１０に流れる。ブロック８１０において、完全なコード・シーケンスをプルーニングされたシーケンスに置き換え、ブロック８１２において、コード・シーケンス内の排除された命令をＮＯＰに置き換える。ＮＯＰをコード・シーケンスに付加することへの代替案は、完全な再配置情報が利用可能である場合に不必要なコード・スペースを排除することである。識別された参照が、プルーニングされたシーケンスにロードすることができるオフセットを有する参照に対応していない、及び／又は、プルーニングが安全ではないと判断された場合、処理は、ブロック８０８からブロック８１４に流れる。ブロック８１４において、完全な複数命令参照シーケンスが、コード・シーケンス内に残される。

例えば、ブロック８０２において、リンカは、以下の命令シーケンスを複数命令ＧＯＴ参照として識別する。
addis reg, R5, label@ha
ld reg, reg, label@l

この例においては、アクセスされるデータと関連した変位値は、Ｒ５に格納された３２ＫＢのアドレスの範囲内である。変位の上位ビットは必要とされないので、図８のブロック８０４は、コード・シーケンスが、プルーニングされたシーケンスにロードすることができるオフセットを有すると判断する。変位値は、Ｒ５内の３２ＫＢのベース・アドレスの範囲内であり、従って、下位ビットのみにより指定することができるので、上位ビットは必要とされない。

ブロック８０６において、プルーニングが安全であると判断されたと仮定すると、処理は、ブロック８０８からブロック８１０及び８１２に流れ、そこで、リンカが上のコード・シーケンスを以下のコード・シーケンスに置き換える。
NOP
ld reg, R2, label@got@l

レジスタの依存性が取り除かれ、プロセッサはＮＯＰの場合を最適化し、その結果、１つの命令だけがもたらされたので、置換コード・シーケンスは、オリジナルのコード・シーケンスよりも効率的である。

プルーニングのための候補として識別することができる別のコード・シーケンスは、以下の通りである。
addis reg, R5, offset@ha
addi reg, reg, offset@l

上記のコード・シーケンスにおいて、変位値がベース・レジスタにおける３２ＫＢのアドレスの範囲内にある場合、変位の上位ビットは必要とされない。

変位値が、オフセットが付加される、３２ＫＢのベース・アドレスの範囲内である場合、リンカは、上記のコード・シーケンスを以下のコード・シーケンスに置き換える。
NOP
addi reg, R5, offset@l

複数命令メモリ参照シーケンスの一部として図８のブロック８０２において識別することができ、かつ、ブロック８０４において、変位の上位ビットが必要とされないため、プルーニングされたシーケンスにロードすることができるオフセットを有するものとして識別することができるコード・シーケンスの例は、以下の通りである。以下のコード・シーケンスでは、ブロック８０６において、リンカは、プルーニングが安全でないと判断する。
addis reg,R5,offset@ha
Li r5, 0
ld reg,reg,offset@l

これは、以下のプルーニングされたコード・シーケンスと同等ではない。
NOP
Li R5,0
ld reg,R5,offset@l
プルーニングされたコード・シーケンスがオリジナルのコード・シーケンスと等しくないため、上記のコード・シーケンスに対するプルーニングは、安全でない。

リンカは、プルーニングを実行できるかどうかを判断するために、１組の規則を有することができる。例えば、１つの規則は、複数命令メモリ参照シーケンスにおける命令が互いに隣接していなければならないこととすることができる。別の規則は、シーケンスの最初の命令とシーケンスの最後の命令との間で命令の分析を実施し、最初のａｄｄｉｓにおいて用いられ、かつ、後続の命令にいて新しいベース・レジスタとして用いられるベース・レジスタに対して書き込みが行われないことを保証するものにすることができ、そこで、プルーニングされたａｄｄｉｓの結果は、ａｄｄｉｓ命令のベースにと置き換えられる。代替的に又は付加的に、コンパイラは、プルーニングを安全に実行できるコード・シーケンスを示すことができる。

有利なことに、安全確認と組み合わせたメモリ参照識別方法は、コンパイル時に解決されていないオフセットが１６ビットの変位に適合すると判断できる場合に、それらを用いてシーケンスを改善するための機会をリンカに提供する。従来技術においては、意味論変更最適化の導入に関する問題を回避するために、ＴＯＣベースなどの、関数内で定数であることが分かっているレジスタを用いる参照のみが使用された。本発明によれば、別の規則は、本発明に従って本明細書で教示された最適化の機会に加えて、強化された方法において付加的な従来技術のコードの改善の機会を得るために、アプリケーション・プログラムにより変更されないようにＡＢＩにより定められたＴＯＣベース・レジスタを用いて、参照を行わなければならないというものにすることができる。

リンカにより実施することができる別の参照コード最適化は、参照頻度ベースのＴＯＣ参照パッキング（packing）である。プロセッサに応じて、ＴＯＣ（又はＧＯＴ）ベースからの距離が異なると、コストが異なり得る。ここで図９を参照すると、本発明の一実施形態によるＴＯＣアドレス指定スキームのブロック図が、一般的に示される。図９は、ある範囲のメモリ・アドレスを有するＴＯＣ９０４と、ＴＯＣ９０４のベースを指し示すＴＯＣアドレス・レジスタ９１２（例えば、上の例のレジスタ「Ｒ２」）とを示す。図９に示されるように、ＴＯＣアドレス・レジスタ９１２は、リンカにより動的に計算されたＴＯＣ９０４の中点を指し示す。

図９は、ＤＴＩＯハードウェア・サポートを有さないマイクロプロセッサ（ＭＰ）と関連し、参照シーケンスのプルーニングがリンカにより実施される、アクセス・コスト９０６を示す。図９に示されるようなアクセス・コスト９０６は、ＴＯＣアドレス・レジスタ９１２における値から＋／−３２ＫＢより多く離れている全ての参照に関する２つの命令、及びＴＯＣアドレス・レジスタ９１２における値から＋／−３２ＫＢの範囲内の全ての参照に関する１つの命令である（図８を参照して上述されたようなＴＯＣシーケンス・プルーニング最適化が、リンカにより実行される場合）。

図９はまた、ＤＴＩＯハードウェア・サポートを有するマイクロプロセッサ（ＭＰ）及び変位値を指定するための２１ビットと関連したアクセス・コスト９０８も示す。図９に示されるアクセス・コスト９０８は、ＴＯＣアドレス・レジスタ９１２における値から＋−１ＭＢより多く離れている全ての参照に関する２つの命令、及びＴＯＣアドレス・レジスタ９１２における値から＋／−１ＭＢの範囲内にある全ての参照に関する１つの命令である。従って、変位が２１ビットの範囲内に適合する場合、ハードウェアにおけるＤＴＩＯによる命令の併合が生じ、２１ビットを超える変位値を有する命令は、ＤＴＩＯにより改善されたシーケンスなしで実行を続ける。

図９は、ＤＴＩＯハードウェア・サポートを有するＭＰ及び変位値を指定するための２６ビットと関連したアクセス・コスト９１０をさらに示す。図９に示されるアクセス・コスト９１０は、ＴＯＣアドレス・レジスタ９１２における値から＋／−３２ＭＢより多く離れている全ての参照に関する２つの命令、及びＴＯＣアドレス・レジスタ９１２における値から＋／−３２ＭＢの範囲内にある全ての参照に関する１つの命令である。従って、変位が２６ビットの範囲内に適合する場合、ハードウェアにおけるＤＴＩＯによる命令の併合が生じ、２６ビットを超える変位値を有する命令は、ＤＴＩＯにより改善されたシーケンスなしで実行を続ける。

図９に示される異なる変位値と関連したアクセス・コストは例示であり、システム環境に応じて、他のアクセス・コストを用いることができる。例えば、正の方向の指定範囲外の変位値に関するアクセス・コストは、負の方向の指定範囲外の変位値に関するアクセス・コストよりも低くすることができる。付加的に、変位値がＴＯＣアドレス・レジスタ９１２における値から遠ざかるにつれて、アクセス・コストは増大し得る（例えば、１命令から２命令、３命令へ等のステップ関数として）。さらに、図９に示される例は、符号付き変位が用いられると仮定する。ＴＯＣベース・アドレスへの近接性などの要因に応じて、符号なし変位を異なるアクセス・コストと共に用いることも可能である。

図１０は、本発明の一実施形態による、参照頻度ベースのＴＯＣ（又はＧＯＴ）参照パッキングを実施するために、リンカにより実施される参照コード最適化プロセスのフロー図を示す。一実施形態において、図１０に示されるプロセスは、強化されたリンカ８０により実施される。図１０に示されるように、リンカは、項目（例えば、アドレス又はデータ）と関連した参照頻度情報を使用して、最も頻繁に使用される参照を、最も低いコストを有する（例えば、ＴＯＣアドレス・レジスタ９１２の値に最も近い）領域に配置する。ブロック１００２において、リンカは、アクセス頻度情報を読み出す。読み出された頻度情報は、プロファイル情報に基づくものであってもよく、又は、例えば、ループ・ネスティングに基づいて合成により生成されてもよい。別の代替案は、読み出された頻度情報をユーザ指定のものにすることである。図１０のブロック１００４において、最も高い参照頻度を有する項目を選択し、ブロック１００６において、この項目を、最も安価な利用可能コストを有するＴＯＣ内の位置に配置する。ブロック１００８において、さらにデータ項目（例えば、変数）が配置されるかどうかを判断する。さらにデータ項目が配置される場合、次いで、ブロック１００４において処理が続行する。さらにデータ項目が配置されない場合、次に、処理はブロック１０１０において終了する。

当業者であれば、この実施形態の教示と共に、頻度以外のコスト・メトリック（例えば、オブジェクト・サイズ及び参照頻度のトレードオフなど）を用い得ることを理解するであろう。

図１１は、本発明の一実施形態による、ＧＯＴロードからＴＯＣ計算への拡張を実施するために、リンカにより実施される参照コード最適化プロセスのフロー図を示す。一実施形態において、図１１に示されるプロセスは、強化されたリンカ８０により実施される。図１１に示されるように、リンカは、非ローカル（すなわち、共有）である変数への参照を発見したものの、その変数がローカル・モジュール（例えば、メイン・モジュール）において作成されることが分かった場合、リンカは、コードを最適化する。

図１１のブロック１１０２において、リンカは、複数命令ＧＯＴロード・シーケンスと関連した命令を識別する。識別することは、複数命令ＴＯＣ参照と一致する依存命令を探すことにより、又は、こうしたシーケンスを明確に識別するオブジェクト・コード・フォーマットを有することにより、実施することができる。ブロック１１０４において、リンカは、参照が、ＴＯＣ計算に置き換えることができるＧＯＴロード参照に対応するかどうかを判断する。これは、メイン・モジュールをメイン・モジュール内のローカル変数への参照とリンクするリンカによって判断することができる。ブロック１１０６において、リンカは、例えば、ＴＯＣ参照が所定範囲のアドレス参照テーブル・ベースの範囲内にあるかどうかを試験することにより、変換が「安全」であるかどうかを判断する。この範囲は、例えば、ＴＯＣデータ・アドレス計算を実施するのに用いることができる多数の変位ビットの１つに、又は、ＴＯＣデータ・アドレス計算を実施するのに用いることができる命令の数に対応することができる。例示的なシナリオは、ＧＯＴをロードするための命令シーケンスを、同様の長さ（又はより短い長さ、その場合、シーケンス長は、ＮＯＰ命令の挿入による同じ長さの置換と等しくすることができる）のＴＯＣエントリを計算するシーケンスにしか置換できない場合である。一般的に用いられる現代のリンカは、必要とする、コードへの大きな修正を行うことができないので、このシナリオは非常に一般的である。参照が、ＴＯＣ計算と置き換えることができるＧＯＴロード参照に対応し、かつ、変換が安全である場合、処理はブロック１１０８からブロック１１１０に流れ、拡張が実施される。ブロック１１１２において、コード・シーケンス内の排除された命令をＮＯＰに置き換える。ＮＯＰをコード・シーケンスに付加することへの代替案は、完全な再配置情報が利用可能である場合に不必要なコード・スペースを排除することである。

ブロック１１０４において、ＴＯＣ計算と置き換えることができるＧＯＴロード参照に対応することが判断される、このタイプのコード・シーケンスの例は、以下の通りである。
addis reg,R2,label@got@h
ld reg,label@got@l(reg)
図１１のブロック１１１０において、リンカは、上記のコード・シーケンスを以下のコード・シーケンスに置き換える。
addisreg,R2,label@toc@h
addi reg,reg,label@toc@l

上に示されるように、ＧＯＴロード命令は、ＴＯＣ計算命令に変換される。さらに、ブロック１１１２において、リンカは、変数が３２ＫＢのＴＯＣの範囲内にあると発見した場合には、上述のようなプルーニングを実施し、以下のようにａｄｄｉｓ命令をＮＯＰ命令に最適化する。
NOP
addi reg,r2,label@toc@l

変数への参照は非ローカルであるが、変数はローカル・モジュール（例えば、メイン・モジュール）において作成されることが分かった場合にリンカがコードを最適化する別の例は、以下の通りである。
addisreg,R2,label@got@h
ld reg,label@got@l(reg)
ld reg, struc_offset(reg)

ブロック１１１０において、リンカは、上記のコード・シーケンスを以下のコード・シーケンスに置き換える。
NOP
addis reg,R2,(label+struc_offset)@toc@h
ld reg,reg,(label+struc_offset)@ toc@l

さらに、ブロック１１１２において、リンカは、変数が３２ＫＢのＴＯＣの範囲内にあることを発見した場合には、上述のようなプルーニングを実行し、以下のように、ａｄｄｉｓ命令をＮＯＰ命令に最適化する。
NOP
NOP
ld reg, R2, (label+struc_offsete)@tol@l

本明細書で説明される実施形態は、ＤＴＩＯ機能をもたない従来のハードウェア・プラットフォーム及びＤＴＩＯ対応のハードウェア・プラットフォームの両方に対して、性能の改善をもたらす。本明細書で説明される新しいコードは、従来のハードウェア・プラットフォーム及びＤＴＩＯ対応のハードウェア・プラットフォームの両方で実行され得る。新しいオブジェクトを、古いオブジェクトと共に散在させることができる（オブジェクトのミックス・アンド・マッチ（異質なものを組み合わせる）、ＡＢＩの連続性を中断しない）。例えば、新しい参照形式が使用されない場合にトランポリンの構築を継続しながら、古いＴＯＣアクセス・シーケンスを有する従来のオブジェクトを新しいオブジェクトとリンクさせることができる。

一実施形態において、新しいライブラリを有するオブジェクトを構築するために、古いリンカ／古い環境を使用する。これは、新しい参照の上位ビットの参照マーカーを無視し、新しい下位参照ビット・マーカーが従来の参照マーカーと両立する場合にうまくいく。この実施形態において、下位ビットに対して従来の参照マーカーが使用され、上位ビットに対して擬似許可が使用される。オーバーフローの場合、トランポリンと組み合わせた新しく生成されたコードは、（現代のソリューションと比べて）わずかに遅くなるが、正確な実行をもたらす。新しいライブラリを従来の環境に供給することができる。

本明細書で説明されるプロセスは、スケジュールの高さを、従来のコードにおける短い（単一命令の）変位シーケンスに類似した高さまで低減させる。

一実施形態において、ＰｏｗｅｒＰＣ６４拡張可能リンク形式（extensible linking format、ＥＬＦ）ＡＢＩは、用語ＴＯＣ及びＧＯＴを使用する。本明細書で定義されるＴＯＣは、６４ビットのＰｏｗｅｒＯｐｅｎ ＡＢＩにより定義されるものと類似のものであることが意図される。本明細書で用いられるとき、ＴＯＣは、ＥＬＦ ＧＯＴ＋スモール・データとなるように定義される。ＧＯＴセクションは、従来のＥＬＦ ＧＯＴを含み、随意的に、スモール・データ領域（浮動小数点定数など）を含むことができる。ベース（ＴＯＣ）は、ＧＯＴ＋０×８０００のアドレスであり、専用のＴＯＣポインタ・レジスタ「Ｒ２」により参照される。ＧＯＴ及びスモール・データ領域を、ＧＯＴセクション内に混ぜることができる。ＧＯＴに隣接するセクション（手続き型言語テーブル（procedure language table、ＰＬＴ）及びスモール・データ）にも、専用のＴＯＣポインタを介してアクセスされる。

本明細書で用いられる構文ＳＹＭＢＯＬ＠ｔｏｃは、値（ＳＹＭＢＯＬ−ｂａｓｅ（ＴＯＣ））を指す。これにより、その名称がＳＹＭＢＯＬである変数のアドレスが、ＴＯＣベースからのオフセットとして提供される。構文ＳＹＭＢＯＬ＠ｔｏｃ＠ｈａ、ＳＹＭＢＯＬ＠ｔｏｃ＠ｈ、及びＳＹＭＢＯＬ＠ｔｏｃ＠ｌは、ＴＯＣオフセットの高度に調整された上位及び下位部分を指す。

構文ＳＹＭＢＯＬ＠ｇｏｔは、値（ＳＹＭＢＯＬ＠ｇｏｔ−ｂａｓｅ（ＴＯＣ））を指す。これにより、その名称がＳＹＭＢＯＬである（６４ビットの）アドレス変数を含む、．ｇｏｔエントリのアドレスが、ＴＯＣベースからのオフセットとして提供される。構文ＳＹＭＢＯＬ＠ｇｏｔ＠ｈａ、ＳＹＭＢＯＬ＠ｇｏｔ＠ｈ、及びＳＹＭＢＯＬ＠ｇｏｔ＠ｌは、ＧＯＴオフセットの高度に調整された上位及び下位部分を指す。

強化されたコンパイラ７０、強化されたリンカ８０、及びＤＴＩＯハードウェアにより実施することができる種々の最適化を示すために、本明細書において特定のコード例が使用された。これらの例は、本発明の実施形態を制限することを意図するものではなく、当業者であれば、本明細書で説明される処理を実施するために、他のコード・シーケンスを用い得ることを認識するであろう。

当業者により認識されるように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又はソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形をとることができ、これらは全て本明細書において一般的に「回路」、「モジュール」又は「システム」と呼ぶことができる。さらに、本発明の態様は、具体化されたコンピュータ可読プログラム・コードを内部に有する１つ又は複数のコンピュータ可読媒体内に具体化されたコンピュータ・プログラム製品の形をとることができる。

１つ又は複数のコンピュータ可読媒体のあらゆる組み合わせを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体であってもよく、又はコンピュータ可読ストレージ媒体であってもよい。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子的、磁気的、光学的、電磁的、赤外線若しくは半導体のシステム、装置若しくはデバイス、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例（非網羅的なリスト）は、以下もの、すなわち、１つ又は複数のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク型読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又は上記のいずれかの適切な組み合わせを含む。本文書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置若しくはデバイスによって用いられる又はそれらに関連して用いられるプログラムを収容又は格納することができる、いずれかの有形媒体とすることができる。

コンピュータ可読信号媒体は、具体化されたコンピュータ可読プログラム・コードを、例えばベースバンド内に又は搬送波の一部としてその中に有する、伝搬データ信号を含むことができる。このような伝搬信号は、これらに限定されるものではないが、電磁的形態、光学的形態又はこれらのいずれかの適切な組み合わせを含む種々の形態のうちのいずれかをとることもできる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ、命令実行システム、装置若しくはデバイスによって用いられる又はそれらに関連して用いられるプログラムを伝達、伝搬又伝送することができる、いずれかのコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に具体化されたプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦ等、又は上記のいずれかの適切な組み合わせを含む、いずれかの適切な媒体を用いて伝送することができる。

本発明の態様に関する動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語のような従来の手続き型プログラミング言語、又は同様のプログラミング言語、１つ又は複数のプログラミング言語のいずれかの組み合わせで記述することができる。プログラム・コードは、全体がユーザのコンピュータ上で実行される場合もあり、独立型ソフトウェア・パッケージとして、一部がユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は全体が遠隔コンピュータ若しくはサーバ上で実行される場合もある。後者のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの（例えば、インターネット・サービス・プロバイダを用いるインターネットを通じた）接続がなされる場合もある。

本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して以下で説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ・プログラム命令によって実装することができることが理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサにより実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するための手段を生成するようにすることができる。

これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスに特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装する命令を含む製品を製造するようにすることもできる。

コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で、コンピュータ実装プロセスを生成するための一連の動作ステップを実施させて、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。

図中のフローチャート及びブロック図は、本発明の種々の実施形態によるシステム、方法及びコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能性、及び動作を示す。これに関して、フローチャート又はブロック図中の各ブロックは、指定された論理機能を実施するための１つ又は複数の実行可能命令を含むコードの、モジュール、セグメント、又は部分を表すことができる。さらに、幾つかの代替的実施形態において、ブロック内に記述された機能は、図中に示したのとは別の順序で実行することができることに留意されたい。例えば、連続して示した２つのブロックは、実際には、実質的に並列に実行することができ、又はブロックは場合により、関与する機能性に応じて逆の順序で実行することができる。さらに、ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図中のブロックの組み合わせは、指定された機能又は動作を実行する専用ハードウェアをベースとするシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実施できることにも留意されたい。

本明細書で用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を限定することを意図したものではない。ここで用いられる単数形の「１つの（a）」、「１つの（an）」及び「その（the）」という用語は、文脈が明確に他の場合を指示していない限り、複数形も含む。「含む（comprise）」及び／又は「含んでいる（comprising）」という用語は、本明細書で用いられるとき、記述された特徴、整数、ステップ、操作、要素、及び／又はコンポーネントの存在を指定するが、１つ又は複数の他の特徴、整数、ステップ、操作、要素、コンポーネント、及び／又はその群の存在又は付加を除外するものではないことが、さらに理解されるであろう。

下記の特許請求の範囲におけるすべての機能付き手段（ミーンズ・プラス・ファンクション）又は機能付き工程（ステップ・プラス・ファンクション）の対応する構造、材料、動作、及び均等物は、該当する場合には、具体的に請求される他の請求要素と組み合わせて本機能を実施するためのいずれかの構造、材料、又は動作を含むことを意図している。本発明の記載は、例示及び説明目的で提示されたが、網羅的であることを意図するものでも、開示された形態の発明に限定されることを意図するものでものでもない。当業者であれば、本発明の範囲及び精神から逸脱することなく、多くの修正及び変形が明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明し、その他の当業者が企図される特定の使用に適した種々の修正を伴う種々の実施形態について本発明を理解できるように、選択され、説明された。

本明細書で示されるフロー図は、単に一例である。本発明の趣旨から逸脱することなく、この図及びその中に記載されたステップ（又は動作）に対して多くの変形が存在し得る。例えば、ステップを異なる順序で実行することもでき、又はステップを追加し、削除し又は修正することもできる。これらの変形のすべては、特許請求される発明の一部と見なされる。

本発明の好適な実施形態を説明してきたが、現在及び将来の両方において、当業者が、以下の特許請求の範囲内に入る種々の改善及び強化を行い得ることが理解されるであろう。これらの特許請求の範囲は、最初に記載される発明の適正な保護を維持するよう解釈されるべきである。

１０：クラウド・コンピューティング・ノード
１２：コンピュータ・システム／サーバ
１４：外部デバイス
１６：処理ユニット（プロセッサ）
１８：バス
２０：ネットワーク・アダプタ
２２：Ｉ／Ｏインターフェース
２４：ディスプレイ
２８：システム・メモリ
３０：ランダム・アクセス・メモリ（ＲＡＭ）
３２：キャッシュ・メモリ
３４：ストレージ・システム
４０：プログラム／ユーティリティ
４２：プログラム・モジュール
５０：クラウド・コンピューティング環境
５４Ａ：携帯情報端末（ＰＤＡ）又は携帯電話
５４Ｂ：デスクトップ・コンピュータ
５４Ｃ：ラップトップ・コンピュータ
５４Ｎ：自動車コンピュータ・システム
６０：ハードウェア及びソフトウェア層
６２：仮想化層
６４：管理層
６６：ワークロード層
７０：強化されたコンパイラ
８０：強化されたリンカ
４０２、９０４：ＴＯＣ
４０４：データ・オブジェクト
９０６、９０８、９１０：アクセス・コスト
９１２：アドレス・レジスタ

Claims (22)

1. 処理回路により読み出し可能であり、かつ、方法を実施するために前記処理回路により実行するための命令を格納する有形ストレージ媒体を含むコンピュータ・プログラム製品であって、前記方法は、
   コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは、第１の命令の内部表現（ＩＲ）及び第２の命令のＩＲを含み、前記第２の命令は前記第１の命令に依存する、識別することと、
   前記第１の命令の前記ＩＲ及び前記第２の命令の前記ＩＲの少なくとも一方と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記第１の命令を前記第２の命令に隣接して配置するように構成された修正されたスケジューラ・コスト関数を生成することを含む、修正することと、
   前記修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは前記第２の命令に隣接して配置された前記第１の命令を含む、生成することと、
   前記オブジェクト・ファイルを発行することと、
   を含むコンピュータ・プログラム製品。
2. 前記コード・シーケンスは、破壊的コード・シーケンスである、請求項１に記載のコンピュータ・プログラム製品。
3. 前記コード・シーケンスは、非破壊的コード・シーケンスである、請求項１に記載のコンピュータ・プログラム製品。
4. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）である、請求項１〜請求項３のいずれか１項に記載のコンピュータ・プログラム製品。
5. 前記変数アドレス参照テーブルは、グローバル・オフセット・テーブル（ＧＯＴ）である、請求項１〜請求項３のいずれか１項に記載のコンピュータ・プログラム製品。
6. 方法を実施するように構成されたプロセッサを含むシステムであって、前記方法は、
   変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは第１の命令の内部表現（ＩＲ）及び第２の命令のＩＲを含み、前記第２の命令は前記第１の命令に依存する、識別することと、
   前記第１の命令の前記ＩＲ及び前記第２の命令の前記ＩＲの少なくとも一方と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記第１の命令を前記第２の命令に隣接して配置するように構成された修正されたスケジューラ・コスト関数を生成することを含む、修正することと、
   前記修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは前記第２の命令に隣接して配置された前記第１の命令を含む、生成することと、
   前記オブジェクト・ファイルを発行することと、
   を含む、システム。
7. 前記コード・シーケンスは、破壊的コード・シーケンスである、請求項６に記載のシステム。
8. 前記コード・シーケンスは、非破壊的コード・シーケンスである、請求項６に記載のシステム。
9. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）である、請求項６〜請求項８のいずれか１項に記載のシステム。
10. 前記変数アドレス参照テーブルは、グローバル・オフセット・テーブル（ＧＯＴ）である、請求項６〜請求項８のいずれか１項に記載のシステム。
11. コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは第１の命令の内部表現（ＩＲ）及び第２の命令のＩＲを含み、前記第２の命令は前記第１の命令に依存する、識別することと、
    前記第１の命令の前記ＩＲ及び前記第２の命令の前記ＩＲの少なくとも一方と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記第１の命令を前記第２の命令に隣接して配置するように構成された修正されたスケジューラ・コスト関数を生成することを含む、修正することと、
    前記修正されたスケジューラ・コスト関数に応じて、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは、前記第２の命令に隣接して配置された前記第１の命令を含む、生成することと、
    前記オブジェクト・ファイルを発行することと、
    を含む方法。
12. 前記コード・シーケンスは、破壊的コード・シーケンスである、請求項１１に記載の方法。
13. 前記コード・シーケンスは、非破壊的コード・シーケンスである、請求項１１に記載の方法。
14. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）である、請求項１１〜請求項１３のいずれか１項に記載の方法。
15. 前記変数アドレス参照テーブルは、グローバル・オフセット・テーブル（ＧＯＴ）である、請求項１１〜請求項１３のいずれか１項に記載の方法。
16. 処理回路により読み出し可能であり、かつ、方法を実施するために前記処理回路により実行するための命令を格納する有形ストレージ媒体を含むコンピュータ・プログラム製品であって、前記方法は、
    コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは、待ち時間により特徴付けられる命令の内部表現（ＩＲ）を含む、識別することと、
    前記命令と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記命令が互いに隣接する複数の命令に拡張することを認識するように構成された修正されたスケジューラ・コスト関数を生成することを含み、前記複数の命令は、前記命令の前記ＩＲの前記待ち時間により特徴付けられる、修正することと、
    前記修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは、互いに隣接する前記複数の命令を含む、生成することと、
    前記オブジェクト・ファイルを発行することと、
    を含む、コンピュータ・プログラム製品。
17. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）である、請求項１６に記載のコンピュータ・プログラム製品。
18. 前記変数アドレス参照テーブルは、グローバル・オフセット・テーブル（ＧＯＴ）である、請求項１６に記載のコンピュータ・プログラム製品。
19. 方法を実施するように構成されたプロセッサを含むシステムであって、前記方法は、
    変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは、待ち時間により特徴付けられる命令の内部表現（ＩＲ）を含む、識別することと、
    前記命令と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記命令が互いに隣接する複数の命令に拡張することを認識するように構成された修正されたスケジューラ・コスト関数を生成することを含み、前記複数の命令は、前記命令の前記ＩＲの前記待ち時間により特徴付けられる、修正することと、
    前記修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは、互いに隣接する前記複数の命令を含む、生成することと、
    前記オブジェクト・ファイルを発行することと、
    を含む、システム。
20. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）及びグローバル・オフセット・テーブル（ＧＯＴ）のうちの一方である、請求項１９に記載のシステム。
21. コンピュータにより、変数アドレス参照テーブル内の位置から離れたオフセットにおける変数へのアクセスを含む変数アドレス参照テーブル関数を実施するように構成されたコード・シーケンスを識別することであって、前記コード・シーケンスは、待ち時間により特徴付けられる命令の内部表現（ＩＲ）を含む、識別することと、
    前記命令と関連したスケジューラ・コスト関数を修正することであって、前記修正することは、前記命令が互いに隣接する複数の命令に拡張することを認識するように構成された修正されたスケジューラ・コスト関数を生成することを含み、前記複数の命令は、前記命令の前記ＩＲの前記待ち時間により特徴付けられる、修正することと、
    前記修正されたスケジューラ・コスト関数に応答して、オブジェクト・ファイルを生成することであって、前記オブジェクト・ファイルは、互いに隣接する前記複数の命令を含む、生成することと、
    前記オブジェクト・ファイルを発行することと、
    を含む方法。
22. 前記変数アドレス参照テーブルは、テーブル・オブ・コンテンツ（ＴＯＣ）及びグローバル・オフセット・テーブル（ＧＯＴ）のうちの一方である、請求項２１に記載の方法。

Images