JP2000347876A - スタック・スロット割当て方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 スタックスペースを割当てて使用する方法お
よび装置が開示される。 【解決手段】 本発明の一つの側面によれば、オブジェ
クトベースのシステムにおいてスタックスペースを割当
てるコンピュータによって実行する方法は、変数に関連
する定義を含むとともにコンパイルに適したソース・コ
ードを取得する工程を含む。レジスタ割当ての間、スタ
ック・スロットおよびマシン・レジスタはほとんど同よ
うに取扱われる。これは、干渉グラフを構築する工程、
複写を合体する工程、干渉グラフの彩色を試行する工
程、干渉グラフの彩色の試行が成功であるかどうかを決
定する工程を含む。彩色試行が成功でなければ、通常の
スピル・コードが挿入される代わりに、たとえば「reg-
reg」複写などのレジスタ間複写がソース・コードに挿
入される。「reg-reg」複写は、スタック・スロットお
よびマシン・レジスタの両者に関連する複写を含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般に、ソフトウェ
ア・アプリケーションの性能を改良する方法および装置
に関するものである。本発明は特に、レジスタを割当て
るのとほぼ同様なやり方によりスタック・スロットを割
当てる方法および装置に関するものである。

【０００２】

【従来の技術】コンピュータ・プログラムの実行に伴う
効率を高めるために、コンピュータ・プログラムの多く
は「最適化」される。コンピュータ・プログラムを最適
化すると一般的には、ほとんど使用されないコンピュー
タ・コードの部分が除去される。これに加え、コンピュ
ータ・プログラムを最適化するとコンピュータ演算は再
構築され、全体的計算はさらに効率的に行われてコンピ
ュータ資源の消費が少なくなる。

【０００３】C++、FORTRAN、Javaバイトコードなどのプ
ログラミング言語などで記述されたコンピュータ・プロ
グラムをさらに高速のプログラムへと効率的に変換する
ために、オプティマイザが配置される。さらに高速化さ
れたもしくは最適化されたプログラムは、オリジナルの
もしくは事前変換されたコンピュータ・プログラムと同
一の観測可能な動作をほとんどすべて含んでいる。より
厳密には、最適化されたプログラムはそのプログラムと
関連するオリジナル・プログラムと同一の数学的動作を
行う。しかしながら、最適化されたプログラムはさらに
少ない回数の計算により同一の数学的動作を再現するの
が一般的である。

【０００４】その技術に熟練した当業者であれば理解さ
れるように、オプティマイザは一般的に、最適化、さも
なければコンパイルされたプログラムの内部表現におけ
るレジスタの使用を制御するために配置されたレジスタ
・アロケータを含んでいる。レジスタ・アロケータと
は、プログラムに関連するデータが保存され得るレジス
タスペースを割当てるものである。レジスタとはコンピ
ュータのプロセッサに関連する位置であり、コンピュー
タに関連する、たとえばスタックスペースもしくはヒー
プスペースなどの「通常の」メモリスペースにアクセス
する速回と比較して比較的高速にアクセスされ得るもの
である。

【０００５】プロセッサにおけるレジスタの数は固定さ
れている。その結果、データ保存に使用され得るレジス
タスペースが十分でないと、「スピル・コード」が識別
される。このスピル・コードとは、全てのレジスタが満
杯であるときにスタック・スロットとレジスタとの間で
データを移動するコードである。スタック・スロットと
は全てのレジスタが満杯であるときに情報を保持するた
めにアロケータが使用する一つのスタック・フレームで
ある。オプティマイザは典型的には、必要に応じてスピ
ル・コードに対してスタック・スロットを割当てるため
に配置された専用のスタック・スロット・アロケータを
含んでいる。スタック・スロットはまた、レジスタに適
合する以上の引数を渡すときにも必要とされる。図１a
は、ソース・コードのセグメントの概略図である。ソー
ス・コードのセグメント104は、変数の回々の使用を含
んでいる。たとえば、命令108は、レジスタR1などに保
存された変数Aの一回の使用を含んでいる。命令108は、
変数Bを変数Aと整数「１」の和に等しくなるように配置
する。変数BはレジスタR2内に保存され得る。命令108で
使用されることに加え、変数Aは命令112でも使用され
る。示された如く、変数Bは命令114で使用される。

【０００６】変数Bの有効範囲すなわち「有効範囲B」12
0は、セグメント104内で変数Bが有効に維持されるべき
範囲として定義される。すなわち、有効範囲B 120は、
変数Bに対する値がたとえばレジスタR2などに維持され
る必要がある「距離」である。変数Aがレジスタ内に維
持されねばならない「有効範囲A」122、すなわち変数A
がレジスタ内に維持されねばならない距離は、有効範囲
B 120と重複している。有効範囲120、122が重複すると
いうことは、変数Aおよび変数Bの両者が一定距離に亙り
それぞれのレジスタ内に同時に留まるべきことを示して
いる。示された如く、第1の「有効範囲C」124は、変数D
が設定されるまでに限りレジスタ内で有効であることを
示している。従って、変数Cおよび変数Dは、場合によっ
ては同一のレジスタに割当てられることもある。

【０００７】セグメント104に関連する干渉グラフは、
たとえば干渉などの矛盾なしでセグメント104に対して
レジスタを割当てる目的から彩色され得る。彩色および
それに続くレジスタの割当ては、Chaitin彩色ヒューリ
スティックおよびBriggs-Chaitin彩色アルゴリズムに限
定されるわけではないが、これらを含む、各種の異なる
処理を使用して実施され得るが、前者はニューヨーク、
ヨークタウン・ハイツのIBM社により開発されたもので
ある。図１bは、図１aのセグメント104に関連する干渉
グラフの概略図である。干渉グラフ132は、変数A、B、
C、Dと関連するノード134を含んでいる。

【０００８】同時に有効となる必要がある２つのノード
の間には、エッジ138が含まれる。示された如く、エッ
ジ138aはノードA 134aとノードD 134dとの間に存在する
ことにより、変数AおよびDが同時に有効となることを示
している。同ように、ノードB 134bとノードC 134cとの
間のエッジは変数BおよびCもまた同時に有効となる必要
があることを示している。

【０００９】干渉グラフ132は、干渉グラフ132がうまく
彩色されたときにレジスタが矛盾なしに関連ノード134
に割当てられるように配置される。従って、干渉グラフ
132を彩色することは一般的に、様々な色彩、たとえば
レジスタ番号を干渉グラフ132のノード134に割当てるこ
とを含む。干渉グラフ132は、図１aに示されたソース・
コードのセグメント104に対して３個のレジスタが必要
なことを示している。ノードA 134aおよびノードB 134b
はそれぞれが個別のレジスタを必要とする一方、ノード
C 134cおよびノードD 134dは一つのレジスタを共有し得
る。

【００１０】一般的には、干渉グラフはレジスタを有す
るCPUと同じくらい少ない色彩で彩色され得るとは限ら
ないことから、一定のデータがスタック・スロットへと
スピルされるスピルが生ずる。たとえば、任意の特定の
時点で二つの変数もしくは値が単一レジスタの占有を試
みたときにスピル状態は生ずる。二つの値がほとんど同
時に単一レジスタの占有を試みたとき、レジスタ・アロ
ケータは値に対して値自体のレジスタを保証し得ない工
程に達することから、これらの値の一方はスタック・ス
ロットへとスピルされねばならない。スタック・スロッ
トへスピルされ得るスピルの値の識別は、スピル候補の
識別と考えられる。

【００１１】レジスタ・アロケータは、一つのエッジに
より結合された二つのノードが同一の色を有さないよう
に、干渉グラフに対する色の割当てを試行する。さら
に、レジスタ・アロケータは僅かｋ種類の色の使用を試
行するが、ｋは中央処理ユニット(CPU)のレジスタの数
であり、即ち、Intelの80x86CPUでは8、殆どのRISC CPU
では32である。このような色の割当てが出来ないとき、
または、干渉グラフを彩色するために使用されるアルゴ
リズムがｋ種類の彩色を見出さないとき、一部の有効範
囲はスピルされねばならない。

【００１２】仮想的に二つのレジスタを有するマシンに
対しては、図１bの干渉グラフ132は彩色され得ない。た
とえば、変数AおよびBに関連する有効範囲がスピル候補
として識別されたとする。レジスタ・アロケータは図１
cに示された如く、定義および使用の前後に保存および
ロードを挿入する。同時に、スピル・コードの保存に使
用されるようにスタック・スロットが割当てられねばな
らない。この例においては、有効範囲Aおよび有効範囲B
をスピルするために別々のスタック・スロットが使用さ
れるが、この別々のスタック・スロットが使用されると
同時にこれらの２つの有効範囲の一方しか常に有効とな
らない。スピルされたプログラム104'に対する干渉グラ
フは図１dに示される。図１dの干渉グラフ180は、たと
えばマシン・レジスタのように2色のみを使用して彩色
され得る。

【００１３】その技術に熟練した当業者であれば理解さ
れるように、保存およびロード命令を使用すれば値の保
存および引出しが可能となる。さらに、保存およびロー
ド命令の使用は、スタックスペース、より厳密には、ス
タック・スロットの割当てに関連する。図２は、干渉グ
ラフの彩色に応じたスタックスペースの割当てに関連す
る工程を示すプロセスフローチャートである。ソース・
コードのセグメントに関連するメモリを割当てるプロセ
スは工程202で開始するが、この工程ではたとえば図１b
の干渉グラフ132がソース・コードのセグメントに対し
て構築される。

【００１４】干渉グラフが構築された後、工程206では
干渉グラフの彩色が試行される。先に論じた如く、干渉
グラフを彩色しようとするには種々の方法が適用され得
る。工程206にて干渉グラフの彩色試行が行われたな
ら、工程210では干渉グラフの彩色試行が成功であった
かどうかが決定される。言い換えると、干渉グラフに関
連する変数のそれぞれが矛盾なしにレジスタにうまく割
当てられたかどうかが決定される。

【００１５】もし彩色試行が不成功と決定されれば、干
渉なしに一つのレジスタが割当てられるべきソース・コ
ード・セグメントの変数に対して十分な数のレジスタが
使用可能でない、ということを意味する。従って、プロ
セスフローは工程210から工程214に進み、有効範囲のリ
ストがスピル候補として取得される。即ち、スタック・
スロットにスピルされ得る変数が識別される。

【００１６】スピル候補が識別されたなら、工程218で
はソース・コード・セグメントにおける定義および使用
の前後にロード命令および保存命令が割当てられる。よ
り厳密には、ソース・コード・セグメントで変数を使用
する前に変数をロードするロード命令が挿入される一
方、ソース・コード・セグメントで変数が定義された後
でその変数を保存する保存命令が挿入される。ロード命
令および保存命令、すなわち指示としてのロードおよび
保存が割当てられた後、工程222では有効範囲に対して
スタック・スロットが割当てられる。一般的には、スタ
ック・スロットを割当てる上ではレジスタ・アロケータ
とは別のスタック・スロット・アロケータが使用され
る。スタック・スロット・アロケータはレジスタ・アロ
ケータと別であるが、両方のアロケータが一つのオプテ
ィマイザもしくはコンパイラに含まれるものとする、と
いうことを理解すべきである。スタック・スロットを割
当てると、スピル候補はスタック・スロットにスピルさ
れ得る。工程22から、プロセスフローは工程202に戻
り、新たな干渉グラフが構築される。

【００１７】工程210に戻るが、干渉グラフの彩色試行
が成功と決定されたなら、変数はレジスタもしくはスタ
ック・スロットのいずれかに対してうまく関連すること
を意味する。従って、プロセスフローは工程226に進
み、スタック・スロッを含むスタックがクリアされる。
その技術に熟練した当業者であれば理解されるように、
スタック・スロットをクリアする工程は比較的単純な一
連の工程である。そのような工程は典型的には、スタッ
ク・スロット内での参照内容を実際のオフセットに変換
する工程と、これらのオフセットを関連スピル命令に据
える工程を含む。

【００１８】もしレジスタ・アロケータがスピル候補毎
に単一のスタック・スロットを割当てれば、手軽に使用
されるスタック・フレームを生成する。稠密でない大き
なフレームは大きな利得なしでメモリおよびデータ・キ
ャッシュを消費する。大きなフレームにはまた、スタッ
ク・ポインタから大きなオフセットを直接的にアクセス
し得ないというマシン上の問題が伴う。たとえば、Spar
cコンピュータでは、4096バイト以上離間して配置され
たスタック・スロットへのアクセスには第2の命令が必
要となる。典型的には、アロケータはフレーム・サイズ
を最小化するためにスタック・スロットの再使用を試行
する。その技術に熟練した当業者であれば理解されるよ
うに、スタック・スロットを再使用するために実行され
ることの多いヒューリスティックは一般的には予測し得
ないやり方で動作することにより、バグが充満している
などの信頼できないコードに至る。

【００１９】また、スタック・スロット・アロケータの
実行は非効率的なことが多く、プログラムの大きな部分
に亙り使用されないスタック・スロットにより満たされ
たスタック・フレームに至る。これによりスタック・フ
レームは不必要に大きくなり、大量のメモリを必要とす
る結果、プログラムの実行が遅くなる。さらに、スタッ
ク・スロット・アロケータの実行に関連するヒューリス
ティックはたとえば、スタック・スロットを再使用する
とともにその場しのぎなやり方での作動を試みる。

【００２０】従って、望まれるものは、スタック・スロ
ットに保存される値を効率的に取り扱う方法である。よ
り厳密には、必要とされるものは、スタックスペースの
割当ておよび使用がレジスタスペースの割当ておよび使
用とほとんど同一であるように、スタックスペースを割
当てて使用する効率的な方法および装置である。

【００２１】

【課題を解決するための手段】本発明は、スタックスペ
ースの割当ておよび使用に関するものである。本発明の
一つの側面によれば、オブジェクトベースのシステムに
おいてスタックスペースを割当てるコンピュータによっ
て実行する方法は、コンパイルに適したソース・コード
の取得と、変数に関連する定義を含む。ソース・コード
が取得されたなら、変数に関連する定義の後で連続して
ソース・コードに第1の複写命令が挿入される。次に、
第1の複写命令に対して第1スタック・スロットが割当て
られるとともに、第1スタック・スロットにはスタック
・フレームが関連付けられてこのスタック・フレームの
サイズが決定される。一実施形態においては、この方法
はさらに、ソース・コードに関連する干渉グラフを生成
する工程と、干渉グラフの彩色を試行する工程と、干渉
グラフの彩色の試行が成功かどうかを決定する工程を含
む。もし彩色試行が成功でなければ、第1の複写命令は
ソース・コード内に挿入される。

【００２２】変数の定義および使用の前後においてロー
ド、保存、レジスタ間複写に関連付けられ得る複写命令
を挿入することにより、レジスタを割当てるために使用
されるのと同一の機構を使用してスタック・スロットが
割当てられ得る。同一の機構を使用してレジスタおよび
スタック・スロットを割当てると、一般的に複雑で別々
の機構を使用してスタック・スロット値を割当てる場合
の複雑さは回避され得る。従って、レジスタを割当てる
ために使用される同一機構を使用して実施されるスタッ
ク・スロット割当てを用いるソース・コードは、一般的
にはさらに効率的に且つさらに信頼を得て実行され得
る。

【００２３】本発明のこれらのおよび他の利点は、以下
の詳細な説明を読むとともに添付図面を考察することで
さらに明らかとなろう。本発明は、添付の図面と関連し
た以下の記載事項を参照することによって最もよく理解
され得る。

【００２４】

【発明の実施の形態】オプティマイザもしくはコンパイ
ラは多くの場合、プロセッサに関連するレジスタの数が
有限であるということのために、レジスタに保存され得
ない変数を保持するためのスタック・スロットを割当て
るために使用されるスタック・スロット・アロケータを
含んでいる。スタック・スロット・アロケータは、レジ
スタに対し矛盾なしでは変数の全ては割当てられないこ
とが干渉グラフ彩色アルゴリズムにより決定されたと
き、レジスタ割当てプロセスの間に起動されるのが典型
的である。たとえば、未使用スタック・スロットに関連
するメモリスペースの解放を試行する際、スタック式変
数の処理に関連するヒューリスティックにより、ソース
・コードの実行においてバグが生ずることが多い。さら
に、スタック・スロットの使用は非効率的であることが
多い、と言うのも、スタック・フレーム内における多く
のスタック・スロットはプログラムの小部分に対しての
み使用されるからである。

【００２５】スタック式の値もしくは変数をマシン・レ
ジスタと同一様式で取扱えば、専用のスタック・スロッ
ト・アロケータは必要とされない。そのようなスタック
・スロット・アロケータをレジスタ割当てプロセスから
排除すると、レジスタ使用を減らすために用いられるレ
ジスタ・アロケータの安定性は高まる。また、レジスタ
・アロケータを使用してスタック・スロットを割当てる
と、スタック・スロット使用は少なくなり、且つ、より
小さく、より稠密なスタック・フレーム、少ないキャッ
シュ痕跡、改良されたランタイムが許容される。これに
加え、スタック・スロットを割当てるためにレジスタ・
アロケータを使用するとスタック・スロットはレジスタ
と同一様式で取扱われ得ることから、スタック・スロッ
トに保存された値を取扱うために一般的に使用されるヒ
ューリスティックに関連するバグは排除される。

【００２６】スタック・スロットをレジスタとして有効
なものとして実行するために、レジスタ・アロケータは
レジスタ・アロケータが最早スピル・コードの前後に保
存命令およびロード命令を挿入しないように配置され得
る。そうした命令を挿入しない代わりに、レジスタ・ア
ロケータは、複写命令のソースおよび宛先が真のマシン
・レジスタもしくはスタック・スロットのいずれかであ
り得るときに、複写命令を挿入する。割当てが成功した
後、引き続くクリーンアップ・パスはスタック・スロッ
トおよびレジスタへの／からの複写を必要に応じて保存
もしくはロードに変換する。

【００２７】その技術に熟練した当業者であれば理解さ
れるように、レジスタ・アロケータは複写の排除を行う
ために複写合体を行うことがある。従って、スタック・
スロットに保存されるべき変数の複写を生成することに
より、レジスタ・アロケータは究極的には、使用されな
い複写をスタック・スロットから排除することでスタッ
ク・スロットの使用を減少するために使用され得る。次
に図３aを参照して、複写命令を含むコード・セグメン
トを本発明の実施形態に従って記述する。コード・セグ
メント304は、変数Cの定義において変数AおよびBを使用
するコマンド308即ち命令を含んでいる。上述した実施
形態においては、複写命令は変数の定義および変数の使
用の前後に割当てられる。従って、コマンド308は変数A
およびBを使用することから、変数AおよびBの複写がそ
れぞれコマンド310および312により示されたものとして
行われる。変数Cの複写を生成するために、コマンド308
の後には複写コマンド314が配置される。

【００２８】スタック・スロットおよびレジスタは典型
的には、ネームスペースの一部である。一般的には、ネ
ームスペースのサイズはネームスペースに関連するスタ
ック・スロットの数によって変化し得る。プロセッサに
関連するレジスタの数、従って、ネームスペースに関連
するレジスタの数、は典型的には固定されることから、
ネームスペースのサイズは本質的には、ネームスペース
に含まれるスタック・スロットの数、または、スタック
・スロットから生成されたスタック・フレームのサイズ
によることを理解すべきである。

【００２９】図３bは一般的には、本発明の実施形態に
係るネームスペースの概略図である。ネームスペース35
2は任意のビット数を含み得る。一般的には、ビット数
は特定のコンピューティング・システムの要件によって
幅広く変化し得る。たとえばビット数は、約50ビットか
ら100ビット以上までに亙り得る。理論上は、ネームス
ペース352に関連するビット数は本質的に無限であるこ
とが理解されるべきである。上述した実施形態において
は、ネームスペース352は96ビットのネームスペースで
ある。

【００３０】ネームスペース352の最初の8ビット360に
は、整数を保持するレジスタが関連する。即ち、最初の
8ビット360は８個の整数レジスタを有効なものとして構
成する。一般的には、その技術に熟練した当業者であれ
ば理解されるように、レジスタに関連するビット数は、
ネームスペース352が関連するコンピューティング・プ
ラットフォームによって変化し得る。たとえば、Intel
の80x86中央処理ユニット(CPU)に対しては8ビットが、R
ISC CPUに対しては32ビットがレジスタに関連する。ビ
ットセット364すなわちビット9〜25は、浮動小数点値を
保存するレジスタと関連する。

【００３１】上述した実施形態においては、ビット位置
26で始まるビットは、スタック上で渡される入力引数に
関連するスタック・スロットのことである。入力引数に
割当てられるビット数は、コンパイルされつつあるサブ
ルーチンと、使用される呼び出し規約とによる。一部の
入力引数はレジスタで渡される。入力引数ビットが割当
てられた後、出力引数ビットが割当てられる。出力引数
ビットは典型的には、現在のサブルーチンから呼び出さ
れているサブルーチンに渡される引数のために確保され
る。出力引数ビットが割当てられた後、全ての残存ビッ
トはスピル表示用に割当てられる。

【００３２】ネームスペース352に関連するスタック・
スロット内へのコードのスピルを企図するレジスタ・ア
ロケータは典型的には、第1に使用可能なスタック・ス
ロットを選択し、そのスタック・スロット内に値をスピ
ルする。

【００３３】スタック・スロット内に連続してコードを
有効なものとしてスピルすることにより、スタック・ス
ロットから構成されたスタック・フレームは十分に稠密
となり得る、と言うのも、使用されたスタック・スロッ
トの間には一般的には空のスタック・スロットが存在し
ないからである。さらに、使用されたスタック・スロッ
トの間には空のスロットが無いので、スタック・フレー
ムのサイズは必要なだけの大きさとされ得る。より厳密
には、スタック・フレームのサイズは、使用される最高
位のスタック・スロットに対応する。たとえば、満たさ
れるべきネームスペース352において最後のビットが第3
0ビットである場合、ネームスペース352に関連するスタ
ック・フレームのサイズは４ワード即ち16バイトであ
る。

【００３４】スタック・スロットは種々の理由で割当て
られるが、上述した実施形態においては、ほとんど使用
可能なレジスタが無いときにレジスタ割当てプロセスの
間にスタック・スロットが割当てられる。レジスタ割当
てプロセスは多くの場合、干渉グラフ彩色プロセスと関
連する。図４を参照して、本発明の実施形態に従いソー
ス・コードに対して干渉グラフ彩色を実施することに関
連する工程を記述する。プロセスは工程404にて開始さ
れ、特定のソース・コード・セグメントに対して干渉グ
ラフが生成もしくは「構築」される。ソース・コード・
セグメントは一般的には、たとえばCプログラミング言
語などの任意の適切なプログラミング言語により記述さ
れたソフトウェア・アプリケーションの一部であり得
る。一般的には、干渉グラフの生成は前述の如く、ソー
ス・コードにおける変数もしくは値に関連する有効範囲
を表す工程と、有効範囲間の干渉を表す工程を含む。

【００３５】干渉グラフが構築されたなら、工程408で
は干渉グラフの彩色が試行される。干渉グラフの彩色
は、矛盾もしくは干渉なしにそれぞれの変数に対してレ
ジスタを割当てる工程を含んでいる。理解される如く、
レジスタ割当てを実施する目的から干渉グラフを彩色す
るために使用される方法は、幅広く変化し得る。そのよ
うな方法としては、Briggs-Chaitinレジスタ割当て方
法、Chow式割当て方法、線形スキャン割当て方法が含ま
れるが、これらに限定されるわけではない。

【００３６】工程412では、干渉グラフの彩色試行が成
功したかどうかに関する決定が行われる。言い換える
と、何らの矛盾なしに干渉グラフに関連して全ての変数
が割当てられ得るかどうかに関する決定が行われる。干
渉グラフの彩色の試行が不成功であったと決定されたと
きは、干渉グラフに関連する全ての変数が矛盾なしで割
当てられ得るほどに十分なレジスタは無いことが示され
る。従って、プロセスフローは工程412から工程416へと
進み、干渉グラフに関連する有効範囲のリストがスピル
候補として取得される。即ち、スタック・スロット内に
スピルされ得る値が識別される。

【００３７】スピル候補が識別された後、工程420で
は、スピル候補に関連する定義および使用の前後におい
て複写命令が有効なものとして割当てられもしくは挿入
される。上述した実施形態において、複写命令は、スピ
ル候補に関連する定義の後と、たとえば使用のようなス
ピル候補に関連する命令の前において割当てられる。定
義もしくは使用命令の前後に割当てられた複写命令は典
型的には、レジスタ間命令すなわち「reg-reg」複写命
令の外観を呈する。但し、本発明で示されている如く、
複写により使用される「レジスタ」は実際のマシン・レ
ジスタであってもよいし、スタック・スロットであって
もよい。その技術に熟練した当業者であれば理解される
ように、複写命令は値をスタック上に据える工程を含む
ことはあるが、値をスタック上に据えることは一般的に
は要しない。

【００３８】工程420においてスピル候補に関連する定
義および使用の前後にて複写命令が割当てられたなら、
プロセスフローは工程404に戻り、新たな干渉グラフが
構築される。構築された新たな干渉グラフは、スタック
・スロット・レジスタに彩色を行うことが許される有効
範囲を含む。

【００３９】工程412および彩色の試行が成功したかど
うかの決定に戻るが、その試行が成功したと決定される
と、それ以上のスピルは不要であることが示される。言
い換えると、彩色が成功したと決定されたとき、変数を
保存する付加的なスタック・スロットは必要とされな
い。従って、プロセスフローは工程428へと進み、定義
および使用の前後に割当てられた複写命令に関連する複
写は、それが保存命令、ロード命令、レジスタ間複写命
令に対応するかどうかを決定するために評価される。そ
のような決定は、複写命令を存在する実際のCPUハード
ウェアに対応するものへと変換する上で必要とされる。

【００４０】工程428からプロセスフローは工程432に進
み、工程424で割当てられたスタック・スロッを含むス
タック・フレームのサイズが決定される。スタック・フ
レームのサイズは種々の要因に依存し得るが、上述した
実施形態においてスタック・フレームのサイズは、関連
するネームスペース、たとえば、図３bに関して前述の9
6ビットのネームスペースにおける最大スタック・スロ
ットによる。スタック・フレームのサイズが決定された
なら、スタックは工程436にてクリアされる。スタック
のクリアは一般的には、複写をロードおよび保存に適切
に変換する工程を含む。スタックがクリアされた後、ソ
ース・コード上の割当てを行うプロセスは完了される。

【００４１】図５は、本発明を実施するに適した典型的
な汎用コンピュータ・システムを示している。コンピュ
ータ・システム1030は、(典型的にはランダム・アクセ
ス・メモリすなわちRAMである)主記憶装置1034および
(典型的には読出専用メモリすなわちROMである)主記憶
装置1036などのメモリ・デバイスに結合された(中央処
理ユニットすなわちCPUとも称される)任意の数のプロセ
ッサ1032を含んでいる。

【００４２】コンピュータ・システム1030、すなわちよ
り厳密にはCPU 1032は、その技術に熟練した当業者であ
れば理解されるように、仮想マシンをサポートするため
に配置される。コンピュータ・システム1030上でサポー
トされる仮想マシンの一例は、下記に図６を参照して記
述される。この技術においてよく知られているように、
ROMはCPU 1032に対して単一方向的にデータおよび命令
を転送するように作用する一方、RAMは典型的には双方
向的にデータおよび命令を転送するために使用される。
CPU 1032は一般的には、任意の数のプロセッサを含み得
る。主記憶装置1034、1036の両者は、任意の適切なコン
ピュータ可読媒体を含み得る。典型的には、大容量記憶
装置である補助記憶媒体1038もまたCPU 1032に双方向的
に連結されて付加的なデータ記憶容量を提供する。補助
記憶媒体1038は、コンピュータ・コード、データなどの
プログラムを保存するために使用され得るコンピュータ
可読媒体である。典型的には、大容量記憶装置1038は、
主記憶装置1034、1036よりも一般的には低速であるハー
ドディスクもしくはテープなどの記憶媒体である。大容
量記憶装置1038は、磁気もしくは紙のテープリーダまた
は他のよく知られたデバイスの形態を取り得る。適切な
場合には、大容量記憶装置1038内に保持された情報は、
標準的な様式で仮想メモリとしてのRAM 1036の一部とし
て組み込まれ得る。CD-ROMなどの特定の主記憶装置1034
もまた、CPU 1032に対して単一方向的にデータを渡す。

【００４３】CPU 1032はまた、一つ以上のI/O装置1040
にも連結されるが、I/O装置1040は、ビデオモニタ、ト
ラックボール、マウス、キーボード、マイクロフォン、
接触ディスプレイ、変換器カードリーダ、磁気もしくは
紙のテープリーダ、タブレット、スタイラス、音声もし
くは手書き文字認識器、または、もちろん他のコンピュ
ータなどのよく知られた入力デバイスが含まれるが、こ
れらに限定されるわけではない。最後に、CPU 1032はオ
プションとして、1012で一般的には示されたようなネッ
トワーク接続を使用して、ローカル・エリア・ネットワ
ーク、インターネット・ネットワーク、イントラネット
・ネットワークなどのコンピュータ・ネットワークもし
くは通信ネットワークに連結され得る。そのようなネッ
トワーク接続により、前述の方法の工程を実施する上で
CPU 1032はネットワークから情報を受信するか、情報を
ネットワークに出力し得る。CPU 1032を使用して実行さ
れるべき一連の命令として表現されることの多いそのよ
うな情報は、たとえば、搬送波で具体化されたコンピュ
ータ・データ信号の形態でネットワークとの間で受信、
出力が行われ得る。前述のデバイスおよび情報は、コン
ピュータのハードウェア・ソフトウェア技術に熟練した
当業者は熟知していよう。

【００４４】前述の如く、仮想マシンはコンピュータ・
システム1030上で実行され得る。図６は、図５のコンピ
ュータ・システム1030によりサポートされており、本発
明を実施するのに適した仮想マシンの概略図である。た
とえば、カリフォルニア州、Palo AltoのSun Microsyst
ems社により開発されたJava（登録商標）プログラミン
グ言語などで記述されたコンピュータ・プログラムが実
行されるとき、ソース・コード1110はコンパイル時環境
1105内でコンパイラ1120に与えられる。コンパイラ1120
はソース・コード1110をバイトコード1130へと翻訳す
る。一般的には、ソース・コード1110はソース・コード
1110がソフトウェア開発業者により生成される時点でバ
イトコード1130へと翻訳される。

【００４５】バイトコード1130は一般的には、たとえば
図５のネットワーク1012などを介して再生されるか、ダ
ウンロードされるか、さもなければ配布されるか、図５
の主記憶装置1034などに保存され得る。上述した実施形
態においては、バイトコード1130はプラットフォーム独
立型である。すなわちバイトコード1130は、適切な仮想
マシン1140を実現するほとんど任意のコンピュータ・シ
ステム上で実行され得る。たとえば、Java環境において
バイトコード1130は、Java仮想マシンを実行するコンピ
ュータ・システム上で実行され得る。

【００４６】バイトコード1130は、仮想マシン1140を含
むランタイム環境1135に対して与えられる。ランタイム
環境1135は一般的には、図５のCPU 1032などのプロセッ
サを使用して実行され得る。仮想マシン1140は、コンパ
イラ1142、インタプリタ1144、ランタイム・システム11
46を含んでいる。バイトコード1130は一般的には、コン
パイラ1142またはインタプリタ1144のいずれかに対して
与えられ得る。

【００４７】バイトコード1130がコンパイラ1142に提供
されると、バイトコード1130に含まれた方法が、前述の
如くマシン命令へコンパイルされる。一方、バイトコー
ド1130がインタプリタ1144に対する提供されると、バイ
トコード1130が、１回に１バイトコードずつインタプリ
タ1144へ読み込まれる。各バイトコードがインタプリタ
1144内に読み込まれると、インタプリタ1144がバイトコ
ードにより定義された動作を実行する。一般的には、イ
ンタプリタ1144は、ほとんど連続的にバイトコード1130
を処理するとともにバイトコード1130と関連する動作を
実行する。

【００４８】オペレーティング・システム1160からある
方法が呼び出されると、その方法が解釈された方法とし
て呼び出されることが決定されたのであれば、ランタイ
ム・システム1146はインタプリタ1144からその方法を取
得し得る。他方、もしその方法がコンパイルされた方法
として呼び出されることが決定されたのであれば、ラン
タイム・システム1146はコンパイラ1142を起動する。そ
れから、コンパイラ1142がバイトコード1130からマシン
命令を生成し、マシン語命令を実行する。一般的には、
マシン語命令は仮想マシン1140が終了するときに廃棄さ
れる。

【００４９】本発明の僅かな実施形態のみが記載された
が、本発明が、その精神もしく範囲から逸脱せずに他の
多くの特定形態で具体化され得ることを理解すべきであ
る。たとえば、スタックスペースの割り当ておよび干渉
グラフの彩色に関連する諸々の工程が、再整理され、削
除され、付加され得る。一般的には、本発明の方法に関
するものである諸々の工程は、本発明の精神もしくは範
囲から逸脱することなく再整理され、削除され、付加さ
れ得る。

【００５０】本発明は一般的には、スピルされたデータ
を保持するためのスタック・スロットの割当てに関して
記述されたが、スタック・スロットは種々の異なる理由
から割当てられ得ることを理解すべきである。たとえ
ば、グラフィック・アプリケーションにおいて整数値を
浮動小数点値に変換する演算などは、本質的にスタック
・スロットの割当てを必要とする。あるいはまた、スタ
ック・スロットは、スタック上で引数を渡すことを可能
とするために割当てられ得る。従って、本発明は限定的
でなく例示的なものと解釈されるべきであり、また本発
明は、本明細書中に与えられた詳細内容に限定されるも
のでなく、添付の請求の範囲の範囲内において変更され
得るものである。

【図面の簡単な説明】

【図１】（ａ）は、変数に対する有効範囲を含むソース
・コードの概略図である。（ｂ）は、（ａ）のソース・
コード104に関連する干渉グラフの概略図である。
（ｃ）は保存命令およびロード命令により増強されたソ
ース・コードの概略図である。（ｄ）は（ｃ）のコード
104'に関連する干渉グラフの概略図である。

【図２】干渉グラフの彩色に応じたスタックスペースの
割当てに関連する工程を示すプロセスフローチャートで
ある。

【図３】（ａ）は本発明の実施形態に従った複写命令に
より増強されたソース・コードの概略図である。（ｂ）
は本発明の実施形態に従ったネームスペースの概略図で
ある。

【図４】本発明の実施形態に従った、干渉グラフの彩色
に応じたスタックスペースの割当てに関連する工程を示
すプロセスフローチャートである。

【図５】本発明を実施するのに適した汎用コンピュータ
・システムの概略図である。

【図６】図５のコンピュータ・システムによりサポート
され、本発明を実施するのに適した仮想マシンの概略図
である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 クリフォード エヌ． クリック， ジュ ニア アメリカ合衆国， カリフォルニア州， サン ノゼ， ウォーレイス ドライヴ 955 (72)発明者 クリストファー エー． ヴィック アメリカ合衆国， カリフォルニア州， サン ノゼ， リオ グランデ ドライヴ 5290 (72)発明者 マイケル エイチ． パレッツィニィ アメリカ合衆国， カリフォルニア州， サニーヴェイル， アリバ ドライヴ 241 ナンバー 10

Claims (15)

【特許請求の範囲】
1. 【請求項１】 オブジェクトベースのシステムにおいて
   スタックスペースを割当てる、コンピュータによって実
   行する方法であって、 a)変数に関連する定義を含む、コンパイルに適したソー
   ス・コードを取得し、 b)ソース・コード内における、変数に関連する定義の後
   の連続した第1の複写命令を挿入し、 c)第1の複写命令に対する第1スタック・スロットを割当
   て、 d)スタック・フレームのサイズを決定することを含め
   た、第1スタック・スロットをスタック・フレームへ関
   連付けることを含む、コンピュータによって実行する方
   法。
2. 【請求項２】 e)第1スタック・スロットの第1の複写命
   令に対する割当てを含む、ソース・コードに関連する干
   渉グラフを生成し、 f)干渉グラフの彩色を試行し、 g)干渉グラフの彩色の試行が成功となる時点を決定し、
   干渉グラフの彩色の試行が成功でないことが決定された
   ときにおけるソース・コードへの第1の複写命令を挿入
   することをさらに含む、請求項１に記載のコンピュータ
   によって実行する方法。
3. 【請求項３】 干渉グラフの彩色の試行が成功でないこ
   とが決定されたときにおける、第1スタック・スロット
   に関連するスピル候補を取得することをさらに含む、請
   求項２に記載のコンピュータによって実行する方法。
4. 【請求項４】 干渉グラフの彩色の試行が成功であるこ
   とが決定されるまで、工程b)、c)、e)、f)を反復するこ
   とをさらに含む、請求項２および３のいずれかに記載の
   コンピュータによって実行する方法。
5. 【請求項５】 ソース・コードは変数の少なくとも一回
   の使用を含み、且つ、ソース・コードの取得は変数の少
   なくとも一回の使用の取得を含む、前記請求項のいずれ
   かに記載のコンピュータによって実行する方法。
6. 【請求項６】 変数の少なくとも一回の使用の後に連続
   して配置される第2の複写命令をソース・コードに対し
   て割当て、第2の複写命令に対する第2スタック・スロッ
   トを割当てることをさらに含む、請求項５記載のコンピ
   ュータによって実行する方法。
7. 【請求項７】 第1の複写命令が、ロード命令、保存命
   令、レジスタ間複写命令のいずれかと関連する、前記請
   求項のいずれかに記載のコンピュータによって実行する
   方法。
8. 【請求項８】 第1の複写命令が、ロード命令であるか
   どうかの決定をさらに含む、前記請求項のいずれかに記
   載のコンピュータによって実行する方法。
9. 【請求項９】 第1の複写命令が、ロード命令であるか
   どうかの決定をさらに含む、請求項７に記載のコンピュ
   ータによって実行する方法。
10. 【請求項１０】 関連するオブジェクトベースのシステ
    ムにおいてスタックスペースを割当てるコンピュータ・
    システムであって、 プロセッサと、 変数に関連する定義を含む、コンパイルに適したソース
    ・コードを取得する受信機構と、 ソース・コード内で変数に関連する定義の後に連続して
    第1の複写命令を挿入するコンパイラ機構と、 第1の複写命令に対して第1スタック・スロットを割当て
    るとともにマシン・レジスタを割当てるために配置され
    たレジスタ割当て機構と、 スタック・フレームのサイズの決定を含む、第1スタッ
    ク・スロットのスタック・フレームへの関連付けのため
    のスタック・フレーム生成機構とを含む、コンピュータ
    ・システム。
11. 【請求項１１】 ソース・コードに関連する干渉グラフ
    を生成するグラフ作成器と、 干渉グラフの彩色を試行するグラフ彩色機構と、 干渉グラフの彩色の試行が成功となる時点を決定し、干
    渉グラフの彩色の試行が成功でないことが決定されたと
    きにソース・コードに第1の複写命令が挿入される決定
    器とをさらに含む、請求項１０記載のコンピュータ・シ
    ステム。
12. 【請求項１２】 ソース・コードは変数の少なくとも一
    回の使用を含み、且つ、当コンピュータ・システムはさ
    らに、変数の少なくとも一回の使用の後に連続して配置
    される第2の複写命令をソース・コードに対して割当て
    る割当て器をさらに含み、レジスタ割当て機構は第2の
    複写命令に対して第2スタック・スロットを割当てるた
    めにさらに配置される、請求項１０および１１のいずれ
    かに記載のコンピュータ・システム。
13. 【請求項１３】 オブジェクトベースのシステムにおい
    てスタックスペースを割当てるコンピュータ・プログラ
    ム製品であって、 変数に関連する定義を含むとともにコンパイルに適した
    ソース・コードを取得するために配置されたコンピュー
    タ・コードと、 ソース・コード内で変数に関連する定義の後に連続して
    第1の複写命令を挿入するために配置されたコンピュー
    タ・コードと、 第1の複写命令に対して第1スタック・スロットを割当て
    るために配置されたコンピュータ・コードと、 スタック・フレームのサイズを決定するために配置され
    たコンピュータ・コードを含むスタック・フレームに第
    1スタック・スロットを関連させるために配置されたコ
    ンピュータ・コードと、 コンピュータ・コードを保存するコンピュータ可読媒体
    とを含む、コンピュータ・プログラム製品。
14. 【請求項１４】 コンピュータ可読媒体は、搬送波で具
    体化されたデータ信号、フロッピー（登録商標）・ディ
    スク、CD-ROM、テープ・ドライブ、フラッシュ・メモ
    リ、ハードディスク・ドライブからなる群から選ばれた
    １種である、請求項１３に記載のコンピュータ・プログ
    ラム製品。
15. 【請求項１５】 ソース・コードに関連する干渉グラフ
    を生成するコンピュータ・コードと、 干渉グラフの彩色を試行するために配置されたコンピュ
    ータ・コードと、 干渉グラフの彩色の試行が成功となる時点を決定し、干
    渉グラフの彩色の試行が成功でないことが決定されたと
    きにソース・コードに第1の複写命令を挿入するために
    配置されたコンピュータ・コードとをさらに含む、請求
    項１３および１４のいずれかに記載のコンピュータ・プ
    ログラム製品。