(57)【特許請求の範囲】
【請求項１】
コンピュータにより、複数のソース・オペランドを含む内部表現からオブジェクト・コードを生成することを含み、前記生成することは、
前記内部表現内の各ソース・オペランドについて、
前記ソース・オペランドに関して最終使用が発生したかどうかを判断することであって、前記判断することは、データ・フロー・グラフにアクセスして、ある生存区間の全ての使用が発行されたかどうかを判断することを含む、判断することと、
前記ソース・オペランドに関して最終使用が発生したと判断することに応答して、最終使用の表示のために前記ソース・オペランドと関連したアーキテクテッド・リソースにマーク付けすることと、
前記マーク付けすること及びコスト・メトリックがコスト閾値を上回ることに応答して、前記アーキテクテッド・リソースに関する最終使用の表示を生成することとを含み、
さらに、命令及び前記最終使用の表示を前記オブジェクト・コード内に発行することを含む、
方法。
【請求項２】
前記アーキテクテッド・リソースはレジスタである、請求項１に記載の方法。
【請求項３】
前記ソース・オペランドの前記最終使用と関連した命令は、前記最終使用の表示を含むように修正される、請求項１に記載の方法。
【請求項４】
前記ソース・オペランドの前記最終使用と関連した命令は、前記命令内で指定された修正された命令のオペコード、フラグ、及びマスクのうちの少なくとも１つを、プリフィックス命令、命令プリフィックス、ポストフィックス命令、又は命令ポストフィックスとして含むように修正される、請求項３に記載の方法。
【請求項５】
前記アーキテクテッド・リソースについての前記最終使用の表示は、別個の命令である、請求項１に記載の方法。
【請求項６】
前記コスト・メトリックは複数のアーキテクテッド・リソースについての累積コスト・メトリックであり、前記累積コスト・メトリックは複数の最終使用の表示に対応する、請求項１に記載の方法。
【請求項７】
請求項１〜請求項６のいずれかに記載の前記方法の全てのステップを実行するように適合された手段を含むシステム。
【請求項８】
コンピュータ・プログラムがコンピュータ・システム上で実行されたとき、請求項１〜請求項６のいずれかに記載の方法の全てのステップを実行するための命令を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・システムに関し、より具体的には、レジスタの生存（liveness）を示すコンパイルされたコードを生成することに関する。
【背景技術】
【０００２】
コンピュータ・アーキテクチャにおいて、プロセッサ・レジスタは、中央演算処理ユニット（ＣＰＵ）又は他のデジタル・プロセッサの一部として利用可能な小容量のストレージである。こうしたレジスタは、メイン・メモリ以外の機構によりアドレス指定され、典型的には、メイン・メモリよりも迅速にアクセスすることができる。ほとんど全てのコンピュータは、より大容量のメモリからレジスタにデータをロードし、そこでデータは、何らかの機械命令により、算術計算のために使用され、操作され、又は試験される。次に、操作されたデータは、同じ命令又はその後の命令により、再びメイン・メモリに格納されることが多い。現代のプロセッサは、スタティック・ランダム・アクセス・メモリ（ＲＡＭ）又はダイナミックＲＡＭをメイン・メモリとして使用し、後者は、１つ又は複数のキャッシュ・レベルを介して暗黙的にアクセスされることが多い。コンピュータ・プログラムの共通特性は、参照のローカル性であり、同じ値に繰り返しアクセスすることが多く、頻繁に使用される値をレジスタに保持することにより性能が改善する。プロセッサ・レジスタは、通常、メモリ階層の最上部にあり、データにアクセスする最速の方法を提供する。プロセッサ・レジスタという用語は、命令セットにより定義されるような、命令の一部として直接符号化されるレジスタ群を指す。頻繁に使用される変数をレジスタに割り当てることは、プログラムの性能に重要であり得る。
【０００３】
コンピュータ・ソフトウェアにおいて、アプリケーション・バイナリ・インターフェース（ＡＢＩ）とは、アプリケーション・プログラムとオペレーティング・システムの間、又は、アプリケーション・プログラムと別のアプリケーションの間の低レベルのインターフェースを言う。ＡＢＩは、データ型、サイズ、及びアラインメント、関数の引数がどのように渡され、リターン値がどのように取り出されるかを制御する呼出規約、システム・コール番号及びアプリケーションがオペレーティング・システムに対してどのようにシステム・コールを行う必要があるか、並びに完全なオペレーティング・システムのＡＢＩの場合に、オブジェクト・ファイルのバイナリ形式、プログラム・ライブラリ等のような詳細をカバーする。幾つかのＡＢＩ（例えば、Ｉｎｔｅｌ（登録商標）  ｘ８６アーキテクチャにおいて、幅広いプログラムが種々のＵｎｉｘ（登録商標）及びＬｉｎｕｘ（登録商標）バリアント（variant）上で実行されることを可能にするＩｎｔｅｒａｃｔｉｖｅ  Ｕｎｉｘ（登録商標）  ＡＢＩ）は、必要な共有ライブラリが存在し、類似の前提条件が満たされるという条件で、そのＡＢＩをサポートする１つのオペレーティング・システム（ＯＳ）からのアプリケーション・プログラムが、他のいずれかのそうしたシステム上で修正なしに実行されることを可能にする。
【０００４】
典型的なアプリケーション・プログラムのプログラム開発サイクルには、ソース・コードを書くこと、ソース・コードをオブジェクト・ファイルにコンパイルすること、共有ライブラリを構築すること、及びオブジェクト・ファイルを主実行可能プログラムにリンクさせることが含まれる。主実行可能プログラムのロード、及びアプリケーションの起動のための共有ライブラリのロードを含む付加的な準備は、アプリケーションが特定のハードウェア・プラットフォーム上で実行される前に行われる。
【０００５】
その全体が引用により本明細書に組み入れられる非特許文献１は、例示的な縮小命令セット・コンピュータ（reduced instruction set computer、ＲＩＳＣ）命令セット・アーキテクチャ（instruction set architecture、ＩＳＡ）を教示する。Ｐｏｗｅｒ  ＩＳＡは、本明細書では、例示的な実施形態を実証するのに用いられるが、本発明は、Ｐｏｗｅｒ  ＩＳＡ又はＲＩＳＣアーキテクチャに限定されるものではない。当業者であれば、種々のアーキテクチャにおける本発明の使用を容易に認識するであろう。
【０００６】
その全体が引用により本明細書に組み入れられる非特許文献２は、例示的なＣＩＳＣ（complexinstruction set computer、複合命令セット・コンピュータ）命令セット・アーキテクチャを教示する。
【０００７】
その全体を引用によりここに組み入れる非特許文献３は、ＰｏｗｅｒＰＣ（登録商標）  Ｅｘｅｃｕｔａｂｌｅ  ａｎｄ  Ｌｉｎｋｉｎｇ  Ｆｏｒｍａｔ（ＥＬＦ）ＡＢＩに対する６４ビットの補足を記載している。
【０００８】
その全体を引用によりここに組み入れる非特許文献４及び非特許文献５は、３２ビットＡＢＩを記載している。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】「Ｐｏｗｅｒ  ＩＳＡ  Ｖｅｒｓｉｏｎ  ２．０６  Ｒｅｖｉｓｉｏｎ  Ｂ」、ＩＢＭ発行、２０１０年７月２３日
【非特許文献２】「ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｐｒｉｎｃｉｐｌｅｓ  ｏｆ  Ｏｐｅｒａｔｉｏｎ」、ＩＢＭ、ＳＡ２２−７８３２−０８、第９版、２０１０年８月
【非特許文献３】「６４−ｂｉｔ  ＰｏｗｅｒＰＣ  ＥＬＦ  Ａｐｐｌｉｃａｔｉｏｎ  Ｂｉｎａｒｙ  Ｉｎｔｅｒｆａｃｅ  Ｓｕｐｐｌｅｍｅｎｔ  １．９」、ＩＢＭ、２００４年
【非特許文献４】「Ｐｏｗｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標）  ３２−ｂｉｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｂｉｎａｒｙ  Ｉｎｔｅｒｆａｃｅ  Ｓｕｐｐｌｅｍｅｎｔ  １．０  Ｌｉｎｕｘ（登録商標）」、ｐｏｗｅｒ．ｏｒｇ、２０１１年４月１９日
【非特許文献５】「Ｐｏｗｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標）  ３２−ｂｉｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｂｉｎａｒｙ  Ｉｎｔｅｒｆａｃｅ  Ｓｕｐｐｌｅｍｅｎｔ  １．０−Ｅｍｂｅｄｄｅｄ」、ｐｏｗｅｒ．ｏｒｇ、２０１１年４月１９日
【非特許文献６】Ｓａｌａｐｕｒａ他による「Ｄｅｓｉｇｎ  ａｎｄ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｏｆ  ｔｈｅ  Ｂｌｕｅ  Ｇｅｎｅ（登録商標）／Ｐ  Ｓｎｏｏｐ  Ｆｉｌｔｅｒ」、Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ  Ｃｏｍｐｕｔｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ、２００８年
【発明の概要】
【発明が解決しようとする課題】
【００１０】
レジスタの生存を示すコンパイルされたコードを生成する方法、システム及びコンピュータ・プログラムを提供する。
【課題を解決するための手段】
【００１１】
例示的な実施形態によれば、コンピュータ・プログラム製品、システム、及び方法が、コンピュータにより、複数のソース・オペランドを含む内部表現からオブジェクト・コードを生成することを含む。生成することは、内部表現内の各ソース・オペランドについて、ソース・オペランドに関して最終使用が発生したかどうかを判断することを含む。判断することは、データ・フロー・グラフにアクセスして、ある生存区間（live range）の全ての使用が発行されたかどうかを判断することを含む。ソース・オペランドに関して最終使用が発生したと判断された場合、最終使用の表示のために前記ソース・オペランドと関連したアーキテクテッド・リソース（architected resource）にマーク付けする。次いで、アーキテクテッド・リソースに対して、最終使用の表示を生成する。命令及び最終使用の表示をオブジェクト・コード内に発行する。
【００１２】
付加的な例示的な実施形態によれば、コンピュータ・プログラム製品及びシステムが、呼び出し関数から呼び出されるように構成されたプロローグを、呼び出された関数に挿入することを含む。プロローグは、呼び出された関数に入る際に実行されるように構成され、レジスタの生存状態（liveness status）を格納するための命令を含む。さらに、呼び出された関数にエピローグを挿入する。エピローグは、呼び出された関数を出る際に実行されるように構成され、かつ、プロローグにより格納されたレジスタの生存状態を回復させるように構成された命令を含む。
【００１３】
本発明の技術により、付加的な特徴及び利点が実現される。本発明の他の実施形態及び態様は、本明細書で詳細に説明され、特許請求される本発明の一部であると見なされる。利点及び特徴を有する本発明をより良く理解するに、説明及び図面を参照されたい。
【００１４】
本発明とみなされる主題は、本明細書の最後にある特許請求の範囲において具体的に示され、明確に請求されている。本発明の前述及び他の特徴及び利点は、添付図面と併用される以下の詳細な説明から明らかである。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態によるクラウド・コンピューティング・ノードを示す。
【図２】本発明の一実施形態によるクラウド・コンピューティング環境を示す。
【図３】本発明の一実施形態による抽象化モデル層を示す。
【図４】本発明の一実施形態による、レジスタ生存インジケータを含むオブジェクト・コードを生成するために、コンパイラにより実施されるプロセスのフロー図を示す。
【図５】本発明の一実施形態による、レジスタ生存インジケータ命令を含むオブジェクト・コードを生成するために、コンパイラにより実施されるプロセスのフロー図を示す。
【図６】本発明の一実施形態による、最終使用インジケータ（last-use indicator）を含むオブジェクト・コードを生成するために、コンパイラにより実施されるプロセスのフロー図を示す。
【図７】本発明の一実施形態による、複数命令についての最終使用インジケータをいつ挿入するかを判断するためのリストを用いる、コンパイラにより実施されるプロセスのフロー図を示す。
【図８】本発明の一実施形態による、プロローグ内にコンパイラにより挿入される例示的な命令のフロー図を示す。
【図９】本発明の一実施形態による、エピローグ内にコンパイラにより挿入される例示的な命令のフロー図を示す。
【発明を実施するための形態】
【００１６】
現代のコンピューティング・システムにおいて、レジスタは、比較的十分でないリソースとなっている。使用されていない（不使用）レジスタを実行中のプログラムから検出し、解放する能力を有することは、必要なレジスタだけをプログラムに割り当てることを保証するのに役立つ。これは、レジスタ、及び／又は（迅速なアクセス速度を利用するために）レジスタに格納される付加的なデータ項目に関する競合量の軽減につながり得る。さらに、使用されていないとしてマーク付けされたレジスタをバックアップ及び回復操作から外すことができるので、これらの操作と関連したあらゆる不必要なオーバーヘッドを排除することができる。
【００１７】
本発明の一実施形態は、レジスタの生存状態を示すオブジェクト・コードの生成に向けられる。本明細書で用いられる「生存状態」という用語は、アーキテクテッド・レジスタが、実行中プログラムによりソース・オペランドとして再び使用されるかどうかを言う。「生存している（live）」すなわち「使用されている」の生存状態とは、プログラム内の将来の命令が、レジスタが「生存している」すなわち「使用されている」時点から開始する少なくとも１つのプログラム実行パスに沿って、レジスタ内に格納された値を取り出そうとすることができることを意味する。「使用されていない」すなわち「死んでいる（dead）」の生存状態は、プログラム内のいずれの命令も、レジスタが「使用されていない」すなわち「死んでいる」時点から開始するプログラム実行パスのいずれかに沿って、レジスタ内に格納された値を取り出す必要はないことを意味する。
【００１８】
本明細書で説明される一実施形態において、コンパイラは生存解析（liveness analysis）を行って、ひとたび命令が完了すると、もはやレジスタが使用中でない（すなわち、レジスタが使用されない）ことを示すために、最終使用インジケータをいつオブジェクト・コードに挿入するかを判断する。さらに、オブジェクト・コード命令を呼び出される関数のプロローグ内に挿入して、呼び出される関数により更新される不揮発性レジスタの呼び出しプログラムの生存状態を把握し、かつ、対応するオブジェクト・コード命令を呼び出される関数のエピローグ内に挿入して、呼び出しプログラムに戻る際に呼び出しプログラムの生存状態を回復させることができる。関数に入る際、エピローグ内に更なるオブジェクト・コード命令を挿入して、揮発性の非パラメータ・レジスタを使用されていないものとしてマーク付けすることもできる。さらに、関数を出る際、更に別のオブジェクト・コード命令を挿入して、揮発性レジスタ（結果レジスタを除く）を使用されていないものとしてマーク付けすることもできる。
【００１９】
コンパイルされたコード内への最終使用インジケータの挿入を、短いコード区間に関する不使用を示すのを低減させるように調整することができる。例えば、短い期間内に新しい値がレジスタに書き込まれた場合、コンパイラは、レジスタについての最終使用インジケータを生成しないことを判断することができる。コンパイラは、オブジェクト・コード・プログラム内に最終使用インジケータを挿入するかどうかを判断する際、レジスタの短期間の割り当て解除の収穫逓減（diminishing return）（例えば、性能及び信頼性に関する）と、コード肥大化（例えば、付加的な命令によりもたらされる）のバランスを取ることができる。
【００２０】
１つは生存ベクトルをメモリに格納するための、もう一方はメモリから生存ベクトルをロードするための２つの新しいオブジェクト・コード命令が、本明細書で説明される。これらの新しい命令は、呼び出される関数に入る際にレジスタの生存状態を格納するため、及び、呼び出される関数から出る際にレジスタの生存状態を回復させるために用いられる。
【００２１】
アーキテクテッド・リソースの生存状態を示すための命令の生成は、クラウド・コンピューティング環境において実施することができる。本開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書で述べられる教示の実装は、クラウド・コンピューティング環境に限定されるものではないことが予め理解される。むしろ、本発明の実施形態は、現在知られている又は後に開発される他のいずれかのタイプのコンピューティング環境と併せて実装することができる。
【００２２】
クラウド・コンピューティングは、最小限の管理労力又はサービス・プロバイダとの対話で迅速にプロビジョニング及び解放することができる構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、及びサービス）の共有プールへの、便利なオンデマンドのネットワーク・アクセスを可能にするサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、及び少なくとも４つの配備モデルを含むことができる。
【００２３】
特徴は、以下の通りである。
オンデマンド・セルフサービス：クラウド・コンシューマは、必要に応じて、サーバ時間及びネットワーク・ストレージ等のコンピューティング機能を、人間がサービスのプロバイダと対話する必要なく自動的に、一方的にプロビジョニングすることができる。
広範なネットワーク・アクセス：機能は、ネットワーク上で利用可能であり、異種のシン又はシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、及びＰＤＡ）による使用を促進する標準的な機構を通じてアクセスされる。
リソースのプール化：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを用いて、異なる物理及び仮想リソースを要求に応じて動的に割り当て及び再割り当てすることにより、複数のコンシューマにサービスを提供するためにプールされる。コンシューマは、一般に、提供されるリソースの正確な位置についての制御又は知識を持たないが、より高レベルの抽象化では位置（例えば、国、州、又はデータセンタ）を特定できる場合があるという点で、位置とは独立しているといえる。
迅速な弾力性：機能は、迅速かつ弾力的に、幾つかの場合自動的に、プロビジョニングして素早くスケール・アウトし、迅速にリリースして素早くスケール・インさせることができる。コンシューマにとって、プロビジョニングに利用可能なこれらの機能は、多くの場合、無制限であり、いつでもどんな量でも購入できるように見える。
サービスの測定：クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、及びアクティブなユーザ・アカウント）に適した何らかの抽象化レベルでの計量機能を用いることによって、リソースの使用を自動的に制御及び最適化する。リソース使用を監視し、制御し、報告し、利用されるサービスのプロバイダとコンシューマの両方に対して透明性をもたらすことができる。
【００２４】
サービス・モデルは以下の通りである。
Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＳａａＳ）：クラウド・インフラストラクチャ上で動作しているプロバイダのアプリケーションを使用するために、コンシューマに提供される機能である。これらのアプリケーションは、ウェブ・ブラウザ（例えば、ウェブ・ベースの電子メール）などのシン・クライアント・インターフェースを通じて、種々のクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定の考え得る例外として、ネットワーク、サーバ、オペレーティング・システム、ストレージ、又は個々のアプリケーション機能をも含めて、基礎をなすクラウド・インフラストラクチャを管理又は制御しない。
Ｐｌａｔｆｏｒｍ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＰａａＳ）：プロバイダによってサポートされるプログラミング言語及びツールを用いて生成された、コンシューマが生成した又は取得したアプリケーションを、クラウド・インフラストラクチャ上に配備するために、コンシューマに提供される機能である。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、又はストレージなどの基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、配備されたアプリケーション、及び場合によってはアプリケーション・ホスティング環境構成に対して制御を有する。
Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＩａａＳ）：コンシューマが、オペレーティング・システム及びアプリケーションを含み得る任意のソフトウェアを配備及び動作させることができる、処理、ストレージ、ネットワーク、及び他の基本的なコンピューティング・リソースをプロビジョニンングするために、コンシューマに提供される機能である。コンシューマは、基礎をなすクラウド・インフラストラクチャを管理又は制御しないが、オペレーティング・システム、ストレージ、配備されたアプリケーションに対する制御、及び場合によってはネットワーク・コンポーネント（例えば、ホストのファイアウォール）選択の限定された制御を有する。
【００２５】
配備モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは、ある組織のためだけに運営される。このクラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
コミュニティ・クラウド：クラウド・インフラストラクチャは、幾つかの組織によって共有され、共通の関心事項（例えば、任務、セキュリティ要件、ポリシー、及びコンプライアンス上の考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般公衆又は大規模な業界グループに利用可能であり、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データ及びアプリケーションの移行性を可能にする標準化された又は専用の技術（例えば、クラウド間の負荷分散のためのクラウド・バースティング）によって結び付けられる２つ又はそれより多いクラウド（プライベート、コミュニティ、又はパブリック）の混成物である。
【００２６】
クラウド・コンピューティング環境は、無国籍性、低結合性、モジュール性、及びセマンティック相互運用性に焦点を置くことを指向するサービスである。クラウド・コンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。
【００２７】
ここで図１を参照すると、クラウド・コンピューティング・ノードの一例の概略図が示される。クラウド・コンピューティング・ノード１０は、好適なクラウド・コンピューティング・ノードの単なる一例であり、本明細書で説明される本発明の実施形態の使用又は機能の範囲に対するいずれかの制限を示唆することを意図するものではない。上記に関係なく、クラウド・コンピューティング・ノード１０は、本明細書で上述された機能のいずれかを実装及び／又は実施することができる。
【００２８】
クラウド・コンピューティング・ノード１０には、他の多数の汎用又は専用コンピューティング・システム環境又は構成で動作可能な、コンピュータ・システム／サーバ１２が存在する。コンピュータ・システム／サーバ１２と共に用いるのに好適な周知のコンピューティング・システム、環境、及び／又は構成の例としては、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び、上述のシステム又はデバイス等のいずれかを含む分散型クラウド・コンピューティング環境が含まれる。
【００２９】
コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバ１２は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体に配置することができる。
【００３０】
図１に示されるように、クラウド・コンピューティング・ノード１０のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ１２のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ又は処理ユニット１６、システム・メモリ２８、及びシステム・メモリ２８を含む種々のシステム・コンポーネントをプロセッサ１６に結合するバス１８を含むことができる。
【００３１】
バス１８は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。
【００３２】
コンピュータ・システム／サーバ１２は、典型的には、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ・システム／サーバ１２がアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。
【００３３】
システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ）３０及び／又はキャッシュ・メモリ３２など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、ストレージ・システム３４を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フレキシブル・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによってバス１８に接続することができる。以下でさらに示され説明されるように、メモリ２８は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールの組（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。
【００３４】
限定ではなく例として、メモリ２８内に、プログラム・モジュール４２の組（少なくとも１つ）を有するプログラム／ユーティリティ４０、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール４２は、一般に、本明細書で説明される本発明の実施形態の機能及び／又は方法を実行する。
【００３５】
コンピュータ・システム／サーバ１２は、キーボード、ポインティング・デバイス、ディスプレイ２４等のような１つ又は複数の外部デバイス１４；ユーザがコンピュータ・システム／サーバ１２と対話することを可能にする１つ又は複数のデバイス；及び／又はコンピュータ・システム／サーバ１２が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）と通信することもできる。このような通信は、入力／出力（Ｉ／Ｏ）インターフェース２２を経由して行うことができる。さらにまた、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、及び／又はパブリック・ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ２０は、バス１８を介して、コンピュータ・システム／サーバ１２の他のコンポーネントと通信する。図示されないが、コンピュータ・システム／サーバ１２と共に他のハードウェア及び／又はソフトウェア・コンポーネントを使用できることを理解されたい。例としては、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システムなどが含まれる。
【００３６】
ここで図２を参照すると、例示的なクラウド・コンピューティング環境５０が示される。示されるように、クラウド・コンピューティング環境５０は、例えば携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、及び／又は自動車コンピュータ・システム５４Ｎなどといった、クラウド・コンシューマによって用いられるローカル・コンピューティング・デバイスと通信することができる、１つ又は複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。これらのノードは、上述のようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、若しくはハイブリッド・クラウド、又はこれらの組み合わせなど、１つ又は複数のネットワークにおいて物理的又は仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを保持する必要のないサービスとして、インフラストラクチャ、プラットフォーム、及び／又はソフトウェアを提供することが可能になる。図２に示されるコンピューティング・デバイス５４Ａ−Ｎのタイプは単に例示であることを意図し、コンピューティング・ノード１０及びクラウド・コンピューティング環境５０は、いずれのタイプのネットワーク及び／又はネットワーク・アドレス指定可能な接続上でも（例えば、ウェブ・ブラウザを用いて）、いずれのタイプのコンピュータ化された装置とも通信できることを理解されたい。
【００３７】
ここで図３を参照すると、クラウド・コンピューティング環境５０（図２）によって提供される機能抽象化層の組が示される。図３に示されるコンポーネント、層、及び機能は単に例示であることを意図し、本発明の実施形態はそれらに限定されないことを予め理解されたい。図示されるように、以下の層及び対応する機能が提供される。
【００３８】
ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例として、ＩＢＭ（登録商標）ｚＳｅｒｉｅｓシステムを一例とするメインフレームと、ＩＢＭ（登録商標）  ｐＳｅｒｉｅｓシステムを一例とするＲＩＳＣ（Ｒｅｄｕｃｅｄ  Ｉｎｓｔｒｕｃｔｉｏｎ  Ｓｅｔ  Ｃｏｍｐｕｔｅｒ（縮小命令セット・コンピュータ））アーキテクチャ・ベースのサーバと、ＩＢＭ（登録商標）  ｘＳｅｒｉｅｓ（登録商標）システムと、ＩＢＭ（登録商標）  ＢｌａｄｅＣｅｎｔｅｒ（登録商標）システムと、ストレージ・デバイスと、ネットワーク及びネットワーク・コンポーネントとが含まれる。ソフトウェア・コンポーネントの例として、ＩＢＭ（登録商標）  ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ・ソフトウェアを一例とするネットワーク・アプリケーション・サーバ・ソフトウェアと、ＩＢＭ（登録商標）  ＤＢ２（登録商標）データベース・ソフトウェアを一例とするデータベース・ソフトウェアとが含まれる。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅ、及びＤＢ２は、世界中の多数の管轄区域において登録されているインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。）
【００３９】
仮想化層６２は、抽象化層を提供し、この層により、仮想エンティティの以下の例、すなわち、仮想サーバ、仮想ストレージ、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーション及びオペレーティング・システム、並びに仮想クライアントを提供することができる。
【００４０】
一例においては、管理層６４は、以下で説明される機能を提供することができる。リソース・プロビジョニングは、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格決定は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡と、リソースの消費に対する課金又は請求とを提供する。１つの例においては、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド・コンシューマ及びタスクに対する識別情報の検証と、データ及び他のリソースに対する保護とを提供する。ユーザ・ポータルは、コンシューマ及びシステム管理者のために、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理は、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソースの割り当て及び管理を提供する。サービス・レベル・アグリーメント（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ、ＳＬＡ）の計画及び履行は、ＳＬＡに従って将来の要件が予測されるクラウド・コンピューティング・リソースの事前配置及び調達を提供する。
【００４１】
ワークロード層６６は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロード及び機能の例には、マッピング及びナビゲーション、ソフトウェア開発及びライフサイクル管理、仮想教室教育配信、データ分析処理、トランザクション処理、及びデータ統合ワークフロー処理が含まれる。
【００４２】
例示的な実施形態においては、ワークロード層６６内の強化されたコンパイラ７０が、本明細書で説明される処理を行うが、強化されたコンパイラ７０は、いずれの層内に実装してもよく、ハードウェア及びソフトウェア層６０内の種々のハードウェア・プラットフォーム上で実行されるコードを生成するために用いてもよいことが理解されるであろう。
【００４３】
１つの実施形態において、強化されたコンパイラ７０は、クラウド環境５０において実行されているコンピュータ／サーバ１２の処理ユニット１６上、又は、クラウド環境５０のためのアプリケーションを開発するように適合されたシステム５４Ａ、５４Ｂ、若しくは５４Ｃ上で実行するためのコードを生成する。生成されたコードは、仮想ストレージ６２、外部デバイス１４、又は、内部にインストールされたシステム・フラッシュ・メモリなどの別のソリューションのようなストレージ媒体に格納される。
【００４４】
ここで図４を参照すると、一実施形態による、レジスタ生存インジケータを含むオブジェクト・コードを生成するために、強化されたコンパイラ７０により実施されるプロセスのフロー図が、一般的に示される。図４に示されるプロセスは、既存の命令の一部としてレジスタの最終使用を示す。この実施形態によれば、コンパイラは、命令の後に、命令の少なくとも１つのオペランドが使用されていないことを表すインジケータを含むように増強された命令セットのためのコードを生成する。この表示は、対応するレジスタの各々についての最終使用を示す目的で、命令の操作コード（オペコード）の一部として、レジスタと関連したフラグとして、又は、別個のマスク・ビットが複数のレジスタの各々に対応する場合のマスクとして符号化されるように実施することができる。１つの実施形態において、操作コード、フラグ、又はマスクは、命令内で直接指定される。別の実施形態において、オペコード、フラグ、又はマスクは、プリフィックス（prefix）命令（すなわち、命令に先行する別個の命令）、命令プリフィックス（すなわち、命令に先行するインジケータ）、ポストフィックス（postfix）命令（すなわち、命令に後続する別個の命令）、又は命令ポストフィックス（すなわち、命令に後続するインジケータ）として指定される。
【００４５】
図４を参照すると、プロセスはブロック４０２において開始し、ブロック４０４において、コンパイラ内の命令スケジューラに従って、オブジェクト・コードに書き込まれる次の命令を選択する。次の命令は、１つ又は複数の命令の内部表現（ＩＲ）から選択される。ブロック４０６において、データ・フロー・グラフ（data flow graph、ＤＦＧ）において、次の命令内のソース・オペランドが生存区間（すなわち、従来技術による、コンパイラによって行われる生存区間のレジスタ割り当てに従ったレジスタ値）の最終使用を表すかどうかを判断する。本明細書で用いられる「ＤＦＧ」という用語は、レジスタ（又は他のアーキテクテッド・リソース）への値の割り当てを把握するためのいずれかの種類の構造を指す。コンパイラはＤＦＧに照会し、命令のソース・オペランドの各々について、それが最終使用に対応するかどうかを判断する（すなわち、アーキテクテッド・レジスタに割り当てられた特定のシンボル値（すなわち、生存区間）の他の全ての使用に対して命令が発行されたかどうかを判断することによって）。レジスタの最終使用を判断するこのプロセスは、命令スケジューリングと共に、又は、図４に示されるように、命令スケジューリング後のステップにおいて実施することができる。
【００４６】
ブロック４０６において、ソース・オペランドがレジスタの最終使用を表すと判断された場合、次に、処理は、命令をオブジェクト・コードに発行する（付加する）前に、最終使用インジケータを命令に付加する、ブロック４０８に続く。図４に示される実施形態においては、ソース・オペランドを含むレジスタの最終使用を示すために、１つ又は複数のビットを既存の命令に付加する。次いで、処理は、ブロック４１２に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック４１４で完了する。付加的な命令が存在する場合、次に、処理はブロック４０４に続き、そこで次の命令を選択する。
【００４７】
ブロック４０６において、ソース・オペランドがレジスタの最終使用を表さないと判断された場合、次に、処理は、選択された命令をオブジェクト・コードに発行するブロック４１０に続く。次いで、処理は、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断するためのブロック４１２に続く。付加的な命令が存在しない場合、次に、処理はブロック４１４で完了する。付加的な命令が存在する場合、次に、処理はブロック４０４に続き、そこで次の命令を選択する。
【００４８】
ここで図５を参照すると、一実施形態による、レジスタ生存インジケータ命令を含むオブジェクト・コードを生成するために、強化されたコンパイラ７０により実施されるプロセスのフロー図が、一般的に示される。図５に示されるプロセスは、レジスタの最終使用を示すために別個の命令を挿入し、このため、実行されるとき、オブジェクト・コードは、付加的な命令の処理と関連した付加的なコスト（例えば、キャッシュ、サイクル時間等）を被る。この手法は、付加的なインジケータを有する多数の命令セットを拡張するために、又は、命令を増強するのに使用しなければならない命令プリフィックス、プリフィックス命令、命令ポストフィックス、及びポストフィックス命令の実装と関連したアーキテクチャ又はマイクロアーキテクチャの複雑化を回避するために、好ましいものである。有利なことに、この表示方法によると、１又は複数の命令の最終使用を示すための単一の命令又は少数の命令セットだけが、命令セットに付加される。
【００４９】
図５を参照すると、プロセスがブロック５０２で開始し、ブロック５０４において、コンパイラ内の命令スケジューラに従って、オブジェクト・コードに書き込まれる次の命令を選択する。次の命令は、１つ又は複数の命令のＩＲから選択される。ブロック５０６において、次の命令が発行される。ブロック５０８において、発行されたブロック５０６の次の命令内のソース・オペランドがＤＦＧにおける生存区間（すなわち、レジスタ値）の最終使用を表すかどうかを判断する。付加的な命令の発行はスケジュールに影響を与えるので、レジスタの最終使用を判断するプロセスは、命令スケジューリングと共に実施されることが好ましい。
【００５０】
ブロック５０８において、ソース・オペランドがレジスタの最終使用を表すと判断された場合、次に、処理は、レジスタの最終使用を示す命令をオブジェクト・コードに発行する（付加する）ブロック５１０に続く。次に、処理は、ブロック５１２に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック５１４で完了する。付加的な命令が存在する場合、次に、処理はブロック５０４に続き、そこで次の命令を選択する。
【００５１】
ブロック５０６において、ソース・オペランドが最終使用を表さないと判断された場合、次に、処理は、ブロック５１２に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック５１４で完了する。付加的な命令が存在する場合、次に、処理はブロック５０４に続き、そこで次の命令を選択する。
【００５２】
ここで図６を参照すると、一実施形態による、最終使用インジケータを挿入するオブジェクト・コードを生成するために、コンパイラにより実施されるプロセスのフロー図が、一般的に示される。図６に示されるプロセスは、強化されたコンパイラ７０により実施することができる。図６のプロセスに示されるように、最終使用インジケータ命令をオブジェクト・コードに付加する前に、最終使用インジケータ命令を発行することが、魅力的なトレードオフを提示することを検証するために、試験を実施する。考慮されるトレードオフは、レジスタの解放（レジスタの割り当て解除）により達成される性能上の利点に対する、付加的な命令を発するコスト、及び／又は解放されたレジスタを再び使用するときの再割り当てコストを含むことができる。トレードオフはまた、有用な値を保持しないレジスタにおける一時的障害の回復コストを減らすことに起因する信頼性及び可用性の改善を含むこともできる。トレードオフの確認は、予想されるメトリック（性能、信頼性）を閾値に対して比較することにより、コンパイラにより実施することができる。メトリックは、ブロック６０８において最終使用を有するものとして識別されたアーキテクテッド・リソース（例えば、レジスタ）に対して次の書き込みが行われるまでの命令の数とすることができる。代替的に又は付加的に、メトリックは、これらに限定されるものではないが、レジスタ・キャッシュ管理、リネーミング効率、及び／又はデコード時間命令最適化のような態様から得られる性能の改善の推定値とすることができる。閾値は、ターゲット・プロセッサ若しくは複数の異なるターゲット・プロセッサ、又はコンパイラ・ユーザにより選択されるターゲット・プロセッサのマイクロアーキテクチャに基づいた定数とすることができ、ここで定数は、付加的な命令を発するコストを表す。閾値及びメトリックは、プログラム可能であり、強化されたコンパイラ７０がオブジェクト・コードを生成する前に固定することができ、ＩＲの特徴に基づいて、強化されたコンパイラ７０により調整することができ、及び／又は生成されるオブジェクト・コードの特定の予想される動作環境に合わせて調整することができる。
【００５３】
当業者であれば、代替的な実施形態において、スケジューリングが完了した後に、最終使用インジケータの発行を実施できることを理解するであろう。この場合、メトリックは、値に割り当てられたアーキテクテッド・リソースに対して次の書き込みが行われ、予め生成されたスケジュールに基づき最終使用を認識するまでのサイクル数の関数として求められる。閾値は、スケジュールの関数として（例えば、命令の挿入が、スケジュールに付加的な待ち時間を導入するかどうか）求められる。
【００５４】
図６を参照すると、処理はブロック６０２で開始し、ブロック６０４において、コンパイラ内の命令スケジューラに従って、オブジェクト・コードに書き込まれる次の命令を選択する。次の命令は、１つ又は複数の命令のＩＲから選択される。ブロック６０６において、次の命令が発行される。ブロック６０８において、次の命令内のソース・オペランドがＤＦＧにおける生存区間（すなわち、レジスタ値）の最終使用を表すかどうかを判断する。
【００５５】
ブロック６０８において、ソース・オペランドがレジスタの最終使用を表すと判断された場合、次に、処理は、アーキテクテッド・リソース（例えば、レジスタ）の使用に対応するコスト・メトリック（例えば、このアーキテクテッド・リソースへの次の書き込みまでの距離）がコスト閾値を上回るかどうかを判断するブロック６１０に続く。１つの実施形態において、コスト・メトリックは、アーキテクテッド・レジスタへの次の書き込みが行われるまでの命令又はＩＲの数をカウントすることによって得られる。例えば、ＩＲシーケンス：すなわち、
(1) add r2, r4, r5
(2) mul r2, r2, r2
(3) add r2, r2, r5
(4) addi r2, r2, 128
(5) li r4, 0
において、コスト・メトリックがアーキテクテッド・リソースの最終使用とこれに対するその後の書き込みとの間の距離に対応するコンパイラの１つの実施形態によると、ＩＲ（ｌ）におけるレジスタｒ４についてのコスト・メトリックは３である。
【００５６】
ブロック６１０において、アーキテクテッド・リソースの使用に対応するコスト・メトリックがコスト閾値を上回る場合、次に、処理は、レジスタの最終使用を示す命令をオブジェクト・コードに発行する（付加する）フロック６１２に続く。次に、処理は、ブロック６１４に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック６１６で完了する。付加的な命令が存在する場合、次に、処理はブロック６０４に続き、そこで次の命令を選択する。ブロック６１０において、アーキテクテッド・リソース使用までの距離（この例においては、メトリック）がコスト閾値を上回らない場合、次に、処理はブロック６１４に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック６１６で完了する。付加的な命令が存在する場合、次に、処理はブロック６０４に続き、そこで次の命令を選択する。
【００５７】
ブロック６０８において、ソース・オペランドがレジスタの最終使用を表さないと判断された場合、次に、処理はブロック６１４に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうか判断する。付加的な命令が存在しない場合、次に、処理はブロック６１６で完了する。付加的な命令が存在する場合、次に、処理はブロック６０４に続き、そこで次の命令を選択する。
【００５８】
上記の例示的なＩＲシーケンスにおいて、コスト・メトリックが所定の閾値を満たす場合、そのＩＲに対応するが、最終使用表示命令ｌｕ＜ｒｅｇｉｓｔｅｒ−ｎｕｍｂｅｒ＞で増強された命令シーケンスが、以下のように発行される。
add r2, r4, r5
lu r4
mul r2, r2, r2
add r2, r2, r5
addi r2, r2, 128
li r4, 0
【００５９】
ここで図７を参照すると、一実施形態による、複数のレジスタについての最終使用インジケータをいつ挿入するかを判断するための保留中リストを用いる、コンパイラにより実施されるプロセスのフロー図が、一般的に示される。図７に示されるプロセスは、強化されたコンパイラ７０により実施することができる。図７に示される実施形態は、各レジスタについて別個の最終使用インジケータ命令が生成される、図６を参照して説明されるプロセスと比べると、最終使用インジケータ命令の挿入と関連したオーバーヘッドが低減する。図７に示されるプロセスにおいて、最終使用が認識されたレジスタのリストが保持される。このリストは、「保留中最終使用レジスタ・リスト」と呼ばれる。最終使用インジケータ命令をオブジェクト・コードに付加する前に、試験を実施して、保留中最終使用レジスタ・リスト上のレジスタについての最終使用を示す最終使用インジケータ命令を発行することが、魅力的なトレードオフを提示するかどうかを判断する。コンパイラにより考慮されるトレードオフは、レジスタの解放により達成される性能上の利点に対する、付加的な命令を発するコスト、及び／又は解放されたレジスタを再び使用するときの再割り当てコストを含むことができる。トレードオフはまた、有用な値を保持しないレジスタにおける一時的障害の回復コストを減らすことに起因する信頼性及び可用性の改善を含むこともできる。トレードオフの確認は、予想されるメトリック（性能、信頼性）を閾値に対して比較することにより実施することができる。メトリックは、保留中最終使用レジスタ・リスト上の各レジスタについてのメトリックを加算して、メトリックの総計を生成することにより、求めることができる。個々のレジスタについてのメトリックは、アーキテクテッド・リソース（例えば、レジスタ）への次の書き込みが行われ、最終使用を認識するまでの命令の数を判断することにより、求めることができる。メトリックは、これらに限定されるものではないが、レジスタ・キャッシュ管理、リネーミング効率、及び／又はデコード時間命令最適化のような態様から得られる性能の改善の推定値とすることができる。さらに、閾値は、ターゲット・プロセッサのマイクロアーキテクチャに基づいた定数とすることができ、ここで定数は、付加的な命令を発するコストを表す。閾値及びメトリックはプログラム可能であり、強化されたコンパイラ７０がオブジェクト・コードを生成する前に固定することができ、ＩＲの特徴に基づいて、強化されたコンパイラ７０により調整することができ、及び／又は生成されるオブジェクト・コードの特定の予想される動作環境に合わせて調整することができる。
【００６０】
当業者であれば、代替的な実施形態において、スケジューリングが完了した後、最終使用インジケータの発行を実施できることを理解するであろう。この場合、メトリックは、値に割り当てられたアーキテクテッド・リソースに対する次の書き込みが行われ、予め生成されたスケジュールに基づき最終使用を認識するまでのサイクル数の関数として求められる。閾値は、スケジュールの関数として（例えば、命令の挿入が、スケジュールに付加的な待ち時間を導入するかどうか）求められる。
【００６１】
図７を参照すると、処理はブロック７０２で開始し、ブロック７０４において、コンパイラ内の命令スケジューラに従って、オブジェクト・コードに書き込まれる次の命令を選択する。次の命令は、１つ又は複数の命令のＩＲから選択される。ブロック７０６において、次の命令が発行される。ブロック７０８において、ブロック７０６の発行された次の命令において指定されたターゲット・レジスタを、保留中最終使用レジスタ・リストから除去する。これは、発行された次の命令のターゲット・レジスタのアーキテクテッド・レジスタが、もはや使用されなくなった（又は死んでいる）以前の生存区間に対応しておらず、むしろ発行された命令のターゲット・レジスタへの書き込みで開始した新しい生存区間に対応しているという事実に対応する。ブロック７１０において、次の命令内のソース・オペランドはＤＦＧにおける生存区間（すなわち、レジスタ値）（発行された次の命令の全てのターゲット・レジスタを除く）の最終使用を表すかどうかを判断する。ブロック７１０において、ソース・オペランドがレジスタの最終使用を表すと判断された場合、次に、処理はブロック７１２に続き、そこでレジスタを保留中最終使用レジスタ・リストに付加する。ブロック７１４において、「保留中最終使用レジスタ」リスト上の全てのレジスタについての累積コスト・メトリック（例えば、保留中最終使用レジスタ・リスト上のレジスタの全てについての、例えばレジスタなどのアーキテクテッド・リソース使用までの距離の和）が、コスト閾値を上回るかどうかを判断する。
【００６２】
ブロック７１４において、累積コスト・メトリック（例えば、保留中最終使用レジスタ・リスト上の全てのレジスタについてのアーキテクテッド・リソースの使用までの距離の和）がコスト閾値を上回ると判断された場合、次に、処理は、保留中最終使用レジスタ・リスト上のレジスタの最終使用を示す命令をオブジェクト・コードに発行するブロック７１６に続く。ブロック７１８を実施して、そのレジスタを保留中最終使用レジスタ・リストから除去する。次に、処理はブロック７２０に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック７２２で完了する。付加的な命令が存在する場合、次に、処理はブロック７０４に続き、そこで次の命令を選択する。ブロック７１４において、累積コスト・メトリック（例えば、保留中最終使用レジスタ・リスト上の全てのレジスタについてのアーキテクテッド・リソースの使用までの距離の和）がコスト閾値を上回らないと判断された場合、次に、処理はブロック７２０に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック７２２で完了する。付加的な命令が存在する場合、次に、処理はブロック７０４に続き、そこで次の命令を選択する。
【００６３】
ブロック７１０において、ソース・オペランドがレジスタの最終使用を表さないと判断された場合、次に、処理はブロック７２０に続き、オブジェクト・コード内に含ませるための命令がＩＲ内にさらに存在するかどうかを判断する。付加的な命令が存在しない場合、次に、処理はブロック７２２で完了する。付加的な命令が存在する場合、次に、処理はブロック７０４に続き、そこで次の命令を選択する。
【００６４】
当業者であれば、最終使用を示すために追加の命令を発行することとそこから得られる利点の間のトレードオフを説明するように記述された方法を用いて、レジスタの最終使用を既存の命令の一部として示す、実施形態と関連したオーバーヘッドをモデル化できることも理解するであろう。例えば最終使用インジケータが命令プリフィックスを介して指定される命令セットを用いてこの方法を実施する場合、これらに限定されるものではないが、フェッチ帯域幅の増大及びデコード帯域幅の可能な低減のようなオーバーヘッドをモデル化することができる。
【００６５】
当業者であれば、本明細書において実施形態がレジスタに関して説明されたが、本明細書に含まれる教示と併せて、他のアーキテクテッド・リソース（例えば、ライトバック（write back）用キャッシュ若しくは最終使用が発生したキャッシュ・ラインにおいてライトバックから除外することができ、かつ、キャッシュ・コヒーレンス・プロトコル・スヌープから除外することができ、又は、例えば非特許文献６により教示されるように、スヌープ・フィルタを用いてこうしたプロトコルからフィルタリング除去することができる、キャッシュ内のストレージ・アドレス）を用い得ることも理解するであろう。
【００６６】
強化されたコンパイラ７０のようなコンパイラはまた、オブジェクト・コード・モジュールのプロローグ及びエピローグを修正して、関数呼び出しにわたって生存状態の完全性を保持することができる。修正により、コンパイラが、ＡＢＩ規約に基づいて、生存状態を有するリンケージ・コードを生成することが可能になる。ＰｏｗｅｒＰＣ（登録商標）に関するＡＢＩ規約は、レジスタを、不揮発性（例えば、ＧＰＲ１４−ＧＰＲ３１）、揮発性（例えば、ＧＰＲ３−ＧＰＲ１２）、専用（例えば、ＧＰＲ１−ＧＰＲ２）、及び予約済み（例えば、ＧＰＲ  １３）に分類する。Ｓｙｓｔｅｍ  ｚに関する浮動小数点ＡＢＩ規約は、ｆ０−ｆ７を揮発性として、及びｆ８−ｆ１５を呼び出し先退避（callee-saved）として指定する。
【００６７】
ＡＢＩ規約によれば、幾つかのレジスタは、関数の戻り値にわたって揮発性であるように定められ（すなわち、呼び出される関数は、これらのレジスタにおける値に上書きすることができる）、呼び出し関数は、関数呼び出しを実行する前に、いずれかのデータをこれらの揮発性レジスタに保存する必要がある。揮発性レジスタの一部は、関数の入口上に所定の値を含む（対応するパラメータが存在する場合）。同じくＡＢＩ規約によれば、他のレジスタは、関数の戻り値にわたって不揮発性であり、関数呼び出しを実行する前に、不揮発性レジスタのデータ・コンテンツを保存する必要はない。不揮発性レジスタは、呼び出し先（callee）（すなわち、呼び出される関数又は呼び出されるコード）により使用できるが、これらを、使用の前に保存し、呼び出し元（caller）（すなわち、呼び出し関数又は呼び出しコード）に戻る前に復元させる必要がある。不揮発性レジスタが呼び出し元において使用されない場合、これらは呼び出し先により使用されない限り及び呼び出し先により使用されるまで、使用されないままである。不揮発性レジスタが呼び出し元により使用され、かつ呼び出し先により使用される場合、レジスタは、呼び出し先により最初に使用されるまで、プロローグ内に値を保存した後使用されない。当業者であれば、スケジューリングされたプロローグの場合、値は、それが格納された時点で使用されなくなることを理解するであろう。不揮発性レジスタが呼び出し先により使用される（しかし、呼び出し元によっては使用されない）場合、エピローグにより古い値を復元させることによって、値が生存しているように見える。
【００６８】
以下の例は、別個にコンパイルされた関数Ｆ及びＧを含む。関数Ｆ（呼び出し元）は、関数Ｇ（呼び出し先）を呼び出すためのコードを含む。ＡＢＩ規約に従うと、関数Ｆは、関数Ｇを呼び出す前に、関数Ｆにより現在使用されているいずれかの揮発性レジスタの値を保存する。関数Ｇのプロローグ（すなわち、関数の入口における）は、関数Ｇにより更新されたあらゆる不揮発性レジスタを保存するための命令を含む。関数Ｇが処理を完了すると、エピローグ・コードを実行して、不揮発性レジスタの値を復元し、これらが関数Ｇに入るときに有していたのと同じ値を有するようにする。プロローグが処理を完了した後、関数Ｇは、制御を関数Ｆに戻す。関数Ｆは、関数Ｇから制御を取り戻すと直ちに、揮発性レジスタの値を復元し、関数Ｇを呼び出す前にこれが有していたのと同じ値を有するようになる。不揮発性レジスタＸは、関数Ｇにより使用されるが、関数Ｆによっては使用されないと仮定する。関数Ｇは、関数Ｆが不揮発性レジスタＸを使用するかどうかを知らず、関数Ｇは、入口においてレジスタＸのコンテンツを保存し、出口においてレジスタＸの値を復元させる。関数Ｆに戻ると、関数Ｇのプロローグにおいて復元が実行されたため、レジスタＸは使用されているように見える。従って、レジスタＸは、関数Ｇに入る際に使用されず、関数Ｇから出る際に使用されるため、矛盾が生じる。この矛盾のために、使用されていないレジスタが使用されているように見え、従って、リソースを消耗する。この矛盾を除去することにより、付加的な使用されていないレジスタの割り当てを解除する（又は、割り当ての解除を考慮する）能力がもたらされる。
【００６９】
ここで、関数呼び出しにわたるレジスタ生存情報の生成を参照すると、コード生成は、少なくとも２つの一般的な方法を用いて、コンパイラにより実施され得る。第１の方法は、（上述のように）ＡＢＩ規約に従って、ＤＦＧにおいて生存を表示し、次いで、最終使用インジケータを発行することである。この第１の方法は、呼び出し先により保存及び復元される（そして復元後、復元された値は、それが呼び出し元において使用されていなくても「生存している」ように見える）呼び出し先退避レジスタを処理する例外により、全てのシナリオに対処する。関数の戻りの際、使用されないレジスタが使用されるレジスタのように見えることに関するこの問題を回避するために、本明細書で説明される第２の方法は、ＡＢＩ規約に従って使用されていないレジスタをマーク付けするために、呼び出しサイト（call site）及び／又はプロローグ及びエピローグの一部としてコードを生成する。
【００７０】
第１の方法の一実施形態は、ＡＢＩ規約に従って、全てのＡＢＩレジスタが、プロローグの始め及びエピローグの終わりに、生存している又は揮発性として適切に示されることを保証することを含む。プロローグ及びエピローグは、コンパイラによりＩＲに挿入される。コードをコンパイラにより付加して、呼び出し元において使用されていなかった呼び出し先退避レジスタに関する生存状態を保存するための特別な処理を行うことができる（例えば、以下に説明されるテンプレート・ベースの方法の一態様に従って）。当業者であれば、この手法と共に上記で概説された方法をどのように用いるかを理解するであろう。ＩＲベースの関数呼び出し、エピローグ及びプロローグ生成と併せたＡＢＩ処理の例示的な実施形態においては、関数の始めに、前述された保留中最終使用レジスタ・リストを揮発性の使用されていない（非パラメータ）レジスタのリストに初期化し、関数の入口において即時に最終使用インジケータ命令を発行するかどうかの試験を実施する。
【００７１】
同様に、当業者であれば、図７に関して上述された保留中リスト方法と併せて、呼び出し元において使用されなかった呼び出し先退避レジスタについての生存状態を保存するための特別な処理を実施するために、コードをどのように生成するかを理解するであろう。１つの方法は、既知の呼び出し元についての付加的な情報を（例えば、グローバル・プログラム最適化と共に）作成し、コンパイラが、全ての呼び出し元のレジスタの生存と一致する付加的な最終使用インジケータを生成するようにすることである。一実施形態においては、実行時に使用されていないレジスタのリストを格納するために、プロローグが、命令シーケンスにより拡張される。さらに、実行時に使用されていないレジスタのリストを復元するために、エピローグが命令シーケンスにより拡張される。この実施形態によれば、命令セットは、２つの付加的な命令：すなわち、ストア（store）命令（例えば、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ  Ｄ，Ｂ）及びロード（load）命令（例えば、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  Ｄ，Ｂ）をサポートする。一実施形態においてストア命令は、生存ベクトルをメモリに格納（ストア）し、ロード命令は、メモリから生存ベクトルをロードし、生存ベクトルは、レジスタに対応するビットを含む。
【００７２】
例示的なＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ命令は、複数のアーキテクテッド・リソースに対応する生存データを格納する。１つの実施形態によれば、単一のビットが、各々のアーキテクテッド・リソースの使用／不使用を示すために用いられる。１つの実施形態において、生存ベクトルは、変位Ｄ及びベース・レジスタＢの和に対応するアドレス「Ｄ，Ｂ」又は「Ｄ（Ｂ）」により指定されるメモリ位置（Ｐｏｗｅｒ  ＩＳＡにおけるＤ−Ｆｏｒｍとしても知られる）に格納される。当業者であれば、Ｐｏｗｅｒ  ＩＳＡのＸ  ｆｏｒｍ、又は、変位、ベース及び指標レジスタを指定する「Ｄ（Ｂ，Ｘ）」のようなＳｙｓｔｅｍ  ｚ  ＩＳＡに従ったメモリ形式、又はいずれかの他の周知のアドレス指定形式といった他のアドレス指定形式を用い得ることを理解するであろう。
【００７３】
例示的なＬＯＡＤ  ＬＩＶＥＮＥＳＳ命令は、複数のアーキテクテッド・リソースに対応する生存データをロードする。１つの実施形態によれば、単一のビットが、各々のアーキテクテッド・リソースの使用／不使用を示すために用いられる。１つの実施形態において、生存ベクトルは、変位Ｄ及びベース・レジスタＢの和に対応するアドレス「Ｄ，Ｂ」又は「Ｄ（Ｂ）」により指定されるメモリ位置（Ｐｏｗｅｒ  ＩＳＡにおけるＤ−Ｆｏｒｍとしても知られる）からロードされる。当業者であれば、Ｐｏｗｅｒ  ＩＳＡのＸ  ｆｏｒｍ、又は、変位、ベース及び指標レジスタを指定する「Ｄ（Ｂ，Ｘ）」のようなＳｙｓｔｅｍ  ｚ  ＩＳＡに従ったメモリ形式、又はいずれかの他の周知のアドレス指定形式といった他のアドレス指定形式を用いることができることを理解するであろう。以前生存していたアーキテクテッド・レジスタに対応して、レジスタが非生存である（すなわち、死んでいる又は使用されていない）という表示がロードされた場合、そのアーキテクテッド・リソースと関連した物理リソースの割り当てを解除することができる。以前に生存していなかった（死んでいた又は使用されていなかった）アーキテクテッド・レジスタに対応して、レジスタが生存している（すなわち、使用されている）という表示がロードされた場合、仕様エラーを作成し、リソースを使用されていないものとして維持し、対応する生存表示を無視して更新せず、又は、リソースに所定の値又は未定義の値を割り当て、ロードすることができる。
【００７４】
全てのレジスタについての生存状態を復元することが望ましくないことがある。例えば、レジスタが、関数に入る際に使用されず、関数の出口上に計算された関数結果を支持することがある。単に生存ベクトル全体を復元することにより、計算された関数結果が失われることがある（例えば、計算された結果の値を保持している物理レジスタの割り当てを解除することにより）。一実施形態によれば、コンパイラは、プロローグ及びエピローグ内に付加的なコードを生成して、生存ベクトルを更新する。関数プロローグにおいて、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）；ＯＩ  ４０（ＳＰ），１２８のような命令シーケンスを生成して、生存を位置４０＋ＳＰ（すなわち、スタック・ポインタから４０バイト）に格納し、次に、指定されたアドレス４０＋ＳＰにおける格納された値に１２８をＯＲ−Ｉｍｍｅｄｉａｔｅし、アーキテクテッド・リソースに対応する最左端（最上位）ビットを、「１」はリソースが使用されていることを示す場合の生存ベクトルの１つの定義に従ってそれが使用されていることを示す「１」に設定することにより、生存ベクトルがその後のＬＯＡＤ  ＬＩＶＥＮＥＳＳ命令により再ロードされるとき、第１のアーキテクテッド・リソースに、「生存している」の生存状態がロードされるようにする。関数エピローグにおいて、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）のような命令シーケンスを生成し、プロローグにおける命令によって格納された生存状態を復元する。プロローグにおける命令シーケンスは、レジスタ０についての生存状態を修正し、保存する前にこれが生存している（例えば、これが結果値を支持できるので）ことを示すことに留意されたい。この例は、生存しているレジスタを示すために、ベクトル設定ビットが使用されると仮定する。
【００７５】
当業者であれば、呼び出し元の状態に関係なく、他のレジスタを同様に未定義にできること、及び、これを、ｌｏａｄ  ｌｉｖｅｎｅｓｓ命令の後に別個の最終使用インジケータを発行すること又はレジスタが非生存であることを強制するように生存ベクトルを修正することによって達成できることを理解するであろう。例えば、以下のコード・シーケンスは、呼び出し元から生存状態を格納し、レジスタ２が非生存であることを示す。関数プロローグにおいて、コンパイラにより、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）；ＮＩ  ４０（ＳＰ），（２５５−６４）を生成して、生存を位置４０＋ＳＰ（すなわち、スタック・ポインタから４０バイト）に格納し、次に、指定されたアドレス４０＋ＳＰにおける格納された値に１９１でＡＮＤ−Ｉｍｍｅｄｉａｔｅし、アーキテクテッド・リソースに対応する最上位ビットから２番目のビットを、「１」はリソースが使用されていることを示し、かつ、「０」はリソースが使用されていないことを示す場合の生存ベクトルの１つの定義に従ってそれが使用されていないことを示す「０」に設定することにより、生存ベクトルがその後のＬＯＡＤ  ＬＩＶＥＮＥＳＳ命令により再ロードされるとき、第２のアーキテクテッド・リソースに、「生存していない」の生存状態がロードされるようにする。関数エピローグにおいて、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）のような命令シーケンスを生成し、プロローグにおける命令により保存された生存ベクトルを復元する。
【００７６】
別の例において、レジスタをベクトルに付加し、かつ、ベクトルから除去する。関数プロローグにおいて、コンパイラにより、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）；ＯＩ  ４０（ＳＰ），１２８；ＮＩ  ４０（ＳＰ），（２５５−６４）を生成し、「ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ」によって格納された生存ベクトルを修正して、生存ベクトル内の最上位ビットに対応する第１のリソースを再ロード時に使用されるものとして示し、生存ベクトル内の２番目の上位ビットに対応する第２のリソースを再ロード時に使用されないものとして示すよう強制する。関数エピローグにおいて、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ４０（ＳＰ）のような命令シーケンスを生成し、プロローグにおける命令によって保存された生存ベクトルを復元する。
【００７７】
更に別の実施形態において、コンパイラは、コードの生成中、１つ又は複数のレジスタを生存している又は死んでいるものとして自動的にオーバーライドするためのマスク・ビットをさらに含む命令セットについてのコードを生成する。１つの命令符号化は、２つのマスク・フィールド：ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  Ｄ（Ｂ），Ｍ１，Ｍ２を有し、ここで、生存ベクトルは、値ＬＩＶＥＮＥＳＳ＝（（ＭＥＭ［Ｄ＋Ｂ］）  ＯＲ  Ｍ１）ＡＮＤ  Ｍ２に設定される。
【００７８】
別の態様において、メモリは値：ＭＥＭ［Ｂ＋Ｄ］＝ＬＩＶＥＮＥＳＳ  ＯＲ  Ｍ，ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  Ｄ（Ｂ），Ｍに設定され、生存ベクトルが値：ＬＩＶＥＮＥＳＳ＝ＭＥＭ［Ｄ＋Ｂ］  ＡＮＤ  Ｍに設定される場合、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ  Ｄ（Ｂ），Ｍ１のように、ロード及びストアの各々が１つのマスク・フィールドを有し、ストア命令は、メモリに格納する前にマスクとＬＩＶＥＮＥＳＳレジスタ値とのＯＲ（論理和）演算を行い、ロード命令は、生存を更新する前に、ロードされたメモリ値とマスクとのＡＮＤ（論理積）演算を行う。当業者であれば、逆に、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳと共にＡＮＤ演算を行い、ＬＯＡＤ  ＬＩＶＥＮＥＳＳと共にＯＲ演算を行い得ることを理解するであろう。ＲＩＳＣアーキテクチャにおいては、ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ及びＬＯＡＤ  ＬＩＶＥＮＥＳＳを、ｍｏｖｅ  ｆｒｏｍ  ＳＰＲ及びｍｏｖｅ  ｔｏ  ＳＰＲに置き換えることができる（ここで、示されるＳＰＲは、生存を示す専用レジスタ（special purpose register）を指す）。少なくとも１つの実施形態において、生存レジスタがターゲットである場合のｍｏｖｅ  ｔｏ  ＳＰＲは、汎用レジスタの最終使用を示している。
【００７９】
ＡＢＩに従って死んでいるレジスタにマーク付けするように、呼び出しサイト及び／又はプロローグ及びエピローグの一部としてコードを生成する第２の方法の実施形態を次に説明する。この第２の方法は、ＡＢＩの挙動を反映するコード生成の代替的な方法である。１つの実施形態において、この第２の方法は、コードについての生存状態を生成するために他の方法では更新されなかったコード生成と併せて使用される。別の実施形態で、この第２の方法は、テンプレートに基づいてプロローグ及びエピローグを生成するコード生成方法と併せて命令を示す、生存の生成を可能にするためのテンプレートを生成するために使用される。関数呼び出し境界は、多数の無効レジスタを把握し、コード生成におけるレジスタ生存能力を利用するための魅力的な点である。
【００８０】
図８は、例示的な実施形態による、コンパイラによりプロローグに挿入される例示的な命令のフロー図を示す。一実施形態において、強化されたコンパイラ７０が、命令をプロローグに挿入する。ブロック８０２において、コード・モジュールに入るとき、スタック・フレームを割り当てるための命令を挿入する。ブロック８０４において、不揮発性レジスタのどれが、呼び出し元プログラムにより現在生存しているとしてマーク付けされ、使用されていないとしてマーク付けされたかを示すためにレジスタ生存状態を格納する命令が、プロローグに挿入される。少なくとも１つの実施形態において、生存ベクトルは、本明細書で説明されるＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ命令と共に、スタック・フレーム内に格納される。
【００８１】
ブロック８０６において、呼び出し先プログラムにより更新される不揮発性レジスタを格納するための命令をプロローグ内に挿入する。一実施形態において、非生存レジスタへのアクセスにより、エラー通知イベントが生成される。ストアが必要な場合には一部のユーザから及びストアが不必要である場合には他のユーザからコードを呼び出すことができるので、コンパイラは、ストア命令を使用して、スピル・コードについての通知を抑制する。ストアが不必要である場合にエラー通知を回避し、プログラミング・エラーを典型的に反映するシナリオを反映するために、コンパイラは、エラーを抑制する新しいストアを使用し、非生存レジスタをいつ格納するかを示す。
【００８２】
ブロック８０８において、全ての揮発性の非パラメータ・レジスタを使用されないとしてマーク付けするための命令を挿入する。一実施形態において、この形成をロードするために、コンパイラにより単一のインジケータ命令が生成される。例えば、「ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ＩＭＭＥＤＩＡＴＥ」又は「ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ｆｒｏｍ  ａ  ｃｏｎｓｔａｎｔ  ｐｏｏｌ」などの命令をプロローグに挿入することができる。
【００８３】
ブロック８１０において、全ての格納された呼び出し先退避レジスタを使用されないとしてマーク付けするための命令を挿入する。これは、呼び出し先退避レジスタの各ストアにおける最終使用を表示すること、又は代替的にマスクをロードすること（例えば、ＬＯＡＤ  ＬＩＶＥＮＥＳＳと併せて、又は、例えば同じく呼び出し先退避レジスタを格納するＣＡＬＬ命令などの別の命令の一部として）によって、実施することができる。一実施形態において、ＡＢＩに従った揮発性及び保存されている呼び出し先退避レジスタに関する揮発性の両方に基づいた生存を更新するために、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ＩＭＭＥＤＩＡＴＥ又はＬＯＡＤ  ＬＩＶＥＮＥＳＳ命令が挿入される。
【００８４】
呼び出し先退避レジスタについての生存性を格納するように適合された実施形態において、生存レジスタは、プロローグの一部として（及び、呼び出し先により保存された呼び出し先退避レジスタの不使用を示す前に）格納される。これは、前述のように実施することができる。
【００８５】
図９は、例示的な実施形態による、コンパイラによりエピローグに挿入される例示的な命令のフロー図を示す。一実施形態において、命令が、強化されたコンパイラ７０によりエピローグに挿入される。ブロック９０２において、呼び出し先によりプロローグ内に保存された不揮発性レジスタを復元するための命令を挿入する。ブロック９０４において、コンパイラは、命令をエピローグに挿入し、プロローグ内に保存された、保存された不揮発性レジスタと関連した生存状態を復元するための命令をエピローグ内に挿入する。従って、この命令は、呼び出し先退避レジスタについての呼び出し元の生存状態を復元する。１つの実施形態において、ＣＡＬＬ命令が、生存状態をスタック上に保存するために用いられた場合、スタックから自動的に復元するために、ＲＥＴ命令が用いられる。ブロック９０６において、戻り値を含まない、使用されていない揮発性レジスタとしてマーク付けするための命令が挿入される。ブロック９０８において、コンパイラは、フレーム・スタックの割り当てを解除するための命令を挿入する。
【００８６】
１つの実施形態において、全ての揮発性レジスタ（関数戻りレジスタを除く）を更新するための命令（例えば、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ、ＬＯＡＤ  ＬＩＶＥＮＥＳＳ  ＩＭＭＥＤＩＡＴＥ、若しくはサブルーチン呼び出しを実施し、呼び出し挿入の一部として関数プロローグと一般的に関連付けられた操作を実施するＣＡＬＬ命令、又は、最初に生存ベクトルをＧＰＲ内にロードし、次いでＬＩＶＥＮＥＳＳ  ＳＰＲ内に移動する、本発明の少なくとも１つのＲＩＳＣ実施形態に従ったＭＴＳＰＲ「ｍｏｖｅ  ｔｏ  ＳＰＲ（ｓｐｅｃｉａｌ  ｐｕｒｐｏｓｅ  ｒｅｇｉｓｔｅｒ）」命令）が挿入される。１つの実施形態において、命令は、関数が戻り値を有さない場合、戻りレジスタが非生存（又は使用されていない）として示されると指定する。別の実施形態において、戻りレジスタは、決して不使用としては示されない。
【００８７】
オブジェクト・コードの実際の実行の際、少なくとも１つのシナリオにおいて、生存していないレジスタにアクセスする条件は、プログラミング・エラーに対応し得る。従って、可能な通知イベント（例えば、デバッガ、オペレーティング・システム、ハイパーバイザ、又は別の監督プログラムの１つへの例外）を作成して、可能なプログラミング・エラーを示すように、マイクロプロセッサの実装を適合させることができる。
【００８８】
しかしながら、空きレジスタへの全ての参照がプログラミング・エラーではない。プログラムは、レジスタが使用中であるかどうかを知らない場合、レジスタを保存することを必要とする。従って、プログラムは続行し、（例えば、コンテキスト・スイッチ又は関数呼び出し／戻りの際に）これらのレジスタをメモリに保存（スピル）し、後で再ロード（フィル）することができる。一実施形態の一態様において、可能な例外をオーバーライドし、デフォルトの戻りを強制するために、構成レジスタ及びモード・スイッチが提供される。本発明の別の態様においては、アプリケーションによる挙動を選択するために、（例えば、ＰＳＷ、ＣＲ、又はＭＳＲ状態レジスタ又は実装制御型ＨＩＤビットにおける）制御ビットが設定される。別の態様において、プリフィックスは、使用されていない参照が生じ得ることを示す能力を提供する。更に別の態様において、明確に定義されたオペコードを有する命令は、このように解放され、割り当てが解除されたレジスタにアクセスする能力を有する。
【００８９】
この管理の別の態様においては、非生存のディスエーブルにされたオペランドに対応する通知を作成又は抑制する、通知作成命令及び非通知生成命令が提供される。コンパイラは、コンテキスト・スイッチ又は呼び出し先退避レジスタのスピル／フィル・シーケンスが実施された際に、プログラミング・エラー・インジケータ・イベント（例えば、上記の例外）を作成しないが、むしろデフォルト値を戻す命令を生成する。本発明の一態様によれば、コンパイラは、説明された手段（制御の設定、プリフィックスの使用、又は特別なオペコードの使用）の１つを用いて、使用されていないレジスタを参照することができる重要な操作を実施する。例として、ｍａｋｅｃｏｎｔｅｘｔ／ｇｅｔｃｏｎｔｅｘｔ操作又はｓｅｔｊｕｍｐ／ｌｏｎｇｊｕｍｐ操作の際の、関数プロローグ及びエピローグにおける呼び出し先退避（不揮発性）レジスタに対するレジスタの保存及び復元が挙げられる。これらの操作の別の態様において、コンパイラ・ライブラリ又は関数は、レジスタ生存状態の要約を保存するため（「ＳＴＯＲＥ  ＬＩＶＥＮＥＳＳ」）及びレジスタが再ロードされる場合にこのような情報を復元するため（「ＬＯＡＤ  ＬＩＶＥＮＥＳＳ」）、コードを発行及び／又は使用及び／又は実行するようにも随意的に適合される。
【００９０】
他の態様において、オペレーティング・システム及びハイパーバイザは、類似の命令シーケンスを用いて、コンテキストをコンテキスト・スイッチ内に保存し、復元する。このような使用の一態様において、オペレーティング・システム及びハイパーバイザは、プログラミング・エラーがなく、かつ、決してプログラミング・エラー通知を作成しないが、むしろ常にデフォルト値に置き換わると予想される。このことは、ｚ／ＯＳ（登録商標）及びＡＩＸ（登録商標）のような既知の非常に信頼性が高いオペレーティング・システムにとって望ましい。オペレーティング・システム（ＯＳ）が、ＯＳ内に多数のプログラミング・エラーが存在すると予想する別の態様においては、アプリケーション・プログラムに類似した方法が用いられ、ＯＳ及びハイパーバイザは、（例えば、通知方法を用いて）プログラミング・エラーを表示するように適合され、かつ、使用されていない／空き／割り当て解除されたレジスタを参照することが知られている、コンテキスト・スイッチのような操作についてのプログラミング・エラー通知を作成しないように適合された命令を使用する。これらの方法は、比較的不安定なＯＳにとって望ましいものである。さらに、ｚ／ＯＳ（登録商標）及びＡＩＸ（登録商標）のような非常に安定したＯＳの製造業者は、デバッグを助け、ｚ／ＯＳ（登録商標）及びＡＩＸ（登録商標）オペレーティング・システムにおける周知の業界トップの安定性を保持するために、それらの長期にわたる品質保証サイクルの間、通知をイネーブルにするよう選択することができる。別の態様において、モードを切り換えることができる。例えば、より安定したベースのＬｉｎｕｘ（登録商標）オペレーティング・システムがＯＳ環境において実行される外部モジュール及びドライバを呼び出すことができるＬｉｎｕｘ（登録商標）オペレーティング・システムにおいて、オペレーティング・システムは、ドライバ又はモジュールの実行中、プログラミング・エラー通知がイネーブルにされるモードに切り換わることができる。
【００９１】
強化されたコンパイラ７０により実施することができる種々の最適化を示すために、本明細書において特定のコード例が使用された。これらの例は、本発明の実施形態を制限することを意図するものではなく、当業者であれば、本明細書で説明される処理を実施するために、他のコード・シーケンスを用い得ることを認識するであろう。
【００９２】
当業者により認識されるように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又はソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形をとることができ、これらは全て本明細書において一般的に「回路」、「モジュール」又は「システム」と呼ぶことができる。さらに、本発明の態様は、具体化されたコンピュータ可読プログラム・コードを内部に有する１つ又は複数のコンピュータ可読媒体内に具体化されたコンピュータ・プログラム製品の形をとることができる。
【００９３】
１つ又は複数のコンピュータ可読媒体のあらゆる組み合わせを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体であってもよく、又はコンピュータ可読ストレージ媒体であってもよい。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子的、磁気的、光学的、電磁的、赤外線若しくは半導体のシステム、装置若しくはデバイス、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例（非網羅的なリスト）は、以下もの、すなわち、１つ又は複数のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク型読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又は上記のいずれかの適切な組み合わせを含む。本文書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置若しくはデバイスによって用いられる又はそれらに関連して用いられるプログラムを収容又は格納することができる、いずれかの有形媒体とすることができる。
【００９４】
コンピュータ可読信号媒体は、具体化されたコンピュータ可読プログラム・コードを、例えばベースバンド内に又は搬送波の一部としてその中に有する、伝搬データ信号を含むことができる。このような伝搬信号は、これらに限定されるものではないが、電磁的形態、光学的形態又はこれらのいずれかの適切な組み合わせを含む種々の形態のうちのいずれかをとることもできる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ、命令実行システム、装置若しくはデバイスによって用いられる又はそれらに関連して用いられるプログラムを伝達、伝搬又伝送することができる、いずれかのコンピュータ可読媒体とすることができる。
【００９５】
コンピュータ可読媒体上に具体化されたプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦ等、又は上記のいずれかの適切な組み合わせを含む、いずれかの適切な媒体を用いて伝送することができる。
【００９６】
本発明の態様に関する動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語のような従来の手続き型プログラミング言語、又は同様のプログラミング言語、１つ又は複数のプログラミング言語のいずれかの組み合わせで記述することができる。プログラム・コードは、全体がユーザのコンピュータ上で実行される場合もあり、独立型ソフトウェア・パッケージとして、一部がユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は全体が遠隔コンピュータ若しくはサーバ上で実行される場合もある。後者のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの（例えば、インターネット・サービス・プロバイダを用いるインターネットを通じた）接続がなされる場合もある。
【００９７】
本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して以下で説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ・プログラム命令によって実装することができることが理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサにより実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するための手段を生成するようにすることができる。
【００９８】
これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスに特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装する命令を含む製品を製造するようにすることもできる。
【００９９】
コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で、コンピュータ実装プロセスを生成するための一連の動作ステップを実施させて、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。
【０１００】
図中のフローチャート及びブロック図は、本発明の種々の実施形態によるシステム、方法及びコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能性、及び動作を示す。これに関して、フローチャート又はブロック図中の各ブロックは、指定された論理機能を実施するための１つ又は複数の実行可能命令を含むコードの、モジュール、セグメント、又は部分を表すことができる。さらに、幾つかの代替的実施形態において、ブロック内に記述された機能は、図中に示したのとは別の順序で実行することができることに留意されたい。例えば、連続して示した２つのブロックは、実際には、実質的に並列に実行することができ、又はブロックは場合により、関与する機能性に応じて逆の順序で実行することができる。さらに、ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図中のブロックの組み合わせは、指定された機能又は動作を実行する専用ハードウェアをベースとするシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実施できることにも留意されたい。
【０１０１】
本明細書で用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を限定することを意図したものではない。ここで用いられる単数形の「１つの（a）」、「１つの（an）」及び「その（the）」という用語は、文脈が明確に他の場合を指示していない限り、複数形も含む。「含む（comprise）」及び／又は「含んでいる（comprising）」という用語は、本明細書で用いられるとき、記述された特徴、整数、ステップ、操作、要素、及び／又はコンポーネントの存在を指定するが、１つ又は複数の他の特徴、整数、ステップ、操作、要素、コンポーネント、及び／又はその群の存在又は付加を除外するものではないことが、さらに理解されるであろう。
【０１０２】
下記の特許請求の範囲におけるすべての機能付き手段（ミーンズ・プラス・ファンクション）又は機能付き工程（ステップ・プラス・ファンクション）の対応する構造、材料、動作、及び均等物は、該当する場合には、具体的に請求される他の請求要素と組み合わせて本機能を実施するためのいずれかの構造、材料、又は動作を含むことを意図している。本発明の記載は、例示及び説明目的で提示されたが、網羅的であることを意図するものでも、開示された形態の発明に限定されることを意図するものでものでもない。当業者であれば、本発明の範囲及び精神から逸脱することなく、多くの修正及び変形が明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明し、その他の当業者が企図される特定の使用に適した種々の修正を伴う種々の実施形態について本発明を理解できるように、選択され、説明された。
【０１０３】
本明細書で示されるフロー図は、単に一例である。本発明の趣旨から逸脱することなく、この図及びその中に記載されたステップ（又は動作）に対して多くの変形が存在し得る。例えば、ステップを異なる順序で実行することもでき、又はステップを追加し、削除し又は修正することもできる。これらの変形の全ては、特許請求される発明の一部と見なされる。
【０１０４】
本発明の好適な実施形態を説明してきたが、現在及び将来の両方において、当業者が、以下の特許請求の範囲内に入る種々の改善及び強化を行い得ることが理解されるであろう。これらの特許請求の範囲は、最初に記載される発明の適正な保護を維持するよう解釈されるべきである。
【符号の説明】
【０１０５】
１０：クラウド・コンピューティング・ノード
１２：コンピュータ・システム／サーバ
１４：外部デバイス
１６：処理ユニット（プロセッサ）
１８：バス
２０：ネットワーク・アダプタ
２２：Ｉ／Ｏインターフェース
２４：ディスプレイ
２８：システム・メモリ
３０：ランダム・アクセス・メモリ（ＲＡＭ）
３２：キャッシュ・メモリ
３４：ストレージ・システム
４０：プログラム／ユーティリティ
４２：プログラム・モジュール
５０：クラウド・コンピューティング環境
５４Ａ：携帯情報端末（ＰＤＡ）又は携帯電話
５４Ｂ：デスクトップ・コンピュータ
５４Ｃ：ラップトップ・コンピュータ
５４Ｎ：自動車コンピュータ・システム
６０：ハードウェア及びソフトウェア層
６２：仮想化層
６４：管理層
６６：ワークロード層
７０：強化されたコンパイラ
【図１】
0005957084.tif 000002
【図２】
0005957084.tif 000003
【図３】
0005957084.tif 000004
【図４】
0005957084.tif 000005
【図５】
0005957084.tif 000006
【図６】
0005957084.tif 000007
【図７】
0005957084.tif 000008
【図８】
0005957084.tif 000009
【図９】
0005957084.tif 000010