(57)【要約】ソフトウェアコードを最適化するためのシステム及び方法について提供する。ユーザ入力に基づいて、所望のセグメント化モデルを決定する。結果としてのコードは、実現可能であるとき、ソースコードにおけるより大きいポインタをより小さいＮビットポインタで置き換えるために生成される一方、好ましいセグメント化モデルは維持される。
2006510118.tif 000002
【特許請求の範囲】
【請求項１】
選択されたセグメント化モデルを確認する段階；
Ｎビットポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングする段階であって、ここで、Ｎは演算装置のアーキテクチャ限界より小さい整数値である、段階；及び
１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコードを生成する段階；
を有することを特徴とする方法。
【請求項２】
請求項１に記載の方法であって：
デフォルト長ポインタとして前記ソースプログラムに関連する１つ又はそれ以上のポインタをマーキングする段階；
を更に有する、ことを特徴とする方法。
【請求項３】
請求項２に記載の方法であって、前記デフォルト長ポインタは前記演算装置のアーキテクチャ限界に対応する長さを有する、ことを特徴とする方法。
【請求項４】
請求項２に記載の方法であって、デフォルト長ポインタとして前記ソースプログラムに関連する１つ又はそれ以上のポインタをマーキングする段階は：
デフォルト長ポインタとしてグローバルポインタをマーキングする手順；
を更に有する、ことを特徴とする方法。
【請求項５】
請求項２に記載の方法であって、デフォルト長ポインタとして前記ソースプログラムに関連する１つ又はそれ以上のポインタをマーキングする段階は：
デフォルト長ポインタとしてソースプログラムの現在の複雑性範囲を回避するポインタをマーキングする手順；
を更に有する、ことを特徴とする方法。
【請求項６】
請求項２に記載の方法であって、デフォルト長ポインタとして前記ソースプログラムに関連する１つ又はそれ以上のポインタをマーキングする段階は：
デフォルト長ポインタとしてソースプログラムの現在の複雑性範囲を回避する構造タイプに関連するフィールドポインタをマーキングする手順；
を更に有する、ことを特徴とする方法。
【請求項７】
請求項１に記載の方法であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコードを生成する段階は：
最下位Ｎビットポインタアドレスにベースポインタを初期化するために１つ又はそれ以上の命令を生成する手順；
を更に有する、ことを特徴とする方法。
【請求項８】
請求項１に記載の方法であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコードを生成する段階は：
非ゼロアドレスにベースポインタを初期化するために１つ又はそれ以上の命令を生成する手順；
を更に有する、ことを特徴とする方法。
【請求項９】
請求項１に記載の方法であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコードを生成する段階は：
複数のベースポインタを初期化するために１つ又はそれ以上の命令を生成する手順であって、前記ベースポインタの各々はタイプ属性値に関連している、手順；
を更に有する、ことを特徴とする方法。
【請求項１０】
請求項１に記載の方法であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコードを生成する段階は：
複数のベースポインタを初期化するために１つ又はそれ以上の命令を生成する手順であって、前記ベースポインタの各々はタイプ／クラス属性の対の値に関連している、手順；
を更に有する、ことを特徴とする方法。
【請求項１１】
複数の機械アクセス可能命令を有する機械読み取り可能記憶媒体；
を有する物品であって：
前記命令がプロセッサにより実行されるとき、前記命令は：
選択されたセグメント化モデルを初期化すること；
Ｎビットポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングすることであって、ここで、Ｎは演算装置のアーキテクチャ限界より小さい整数値であり、Ｎは２の累乗の整数に累乗される、マーキングすること；並びに
前記の１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するように結果としてのコード命令を生成すること；
を与える、ことを特徴とする物品。
【請求項１２】
請求項１１に記載の物品であって、前記命令は：
デフォルト長ポインタとして前記ソースプログラムに関連する１つ又はそれ以上のポインタをマーキングすること；
を更に与える、ことを特徴とする物品。
【請求項１３】
請求項１２に記載の物品であって、デフォルト長ポインタをマーキングすることを与える前記命令は、演算装置のアーキテクチャ限界に対応する長さを有するように前記デフォルト長ポインタをマーキングすることを更に与える、ことを特徴とする物品。
【請求項１４】
請求項１２に記載の物品であって、デフォルト長ポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングすることを与える前記命令は：
デフォルト長ポインタとしてグローバルポインタをマーキングするための命令；
を更に有する、ことを特徴とする物品。
【請求項１５】
請求項１２に記載の物品であって、デフォルト長ポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングすることを与える前記命令は：
デフォルト長ポインタとして、前記ソースプログラムの前記現在の複雑性範囲を回避するポインタをマーキングするための命令；
を更に有する、ことを特徴とする物品。
【請求項１６】
請求項１２に記載の物品であって、デフォルト長ポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングすることを与える前記命令は：
デフォルト長ポインタとして、前記ソースプログラムの前記現在の複雑性範囲を回避する構造タイプに関連するフィールドポインタをマーキングするための命令；
を更に有する、ことを特徴とする物品。
【請求項１７】
請求項１１に記載の物品であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成することを与える前記命令は：
最下位Ｎビットポインタアドレスにベースポインタを初期化するための１つ又はそれ以上の命令を生成するための命令；
から更に構成される、ことを特徴とする物品。
【請求項１８】
請求項１１に記載の物品であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成することを与える前記命令は：
非ゼロアドレスにベースポインタを初期化するための１つ又はそれ以上の命令を生成するための命令；
から更に構成される、ことを特徴とする物品。
【請求項１９】
請求項１１に記載の物品であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成することを与える前記命令は：
複数のベースポインタを初期化するための１つ又はそれ以上の命令を生成するための命令であって、前記ベースポインタの各々はタイプ属性値に関連する、命令；
から更に構成される、ことを特徴とする物品。
【請求項２０】
請求項１１に記載の物品であって、１つ又はそれ以上のＮビットポインタに対して前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成することを与える前記命令は：
複数のベースポインタを初期化するための１つ又はそれ以上の命令を生成するための命令であって、前記ベースポインタの各々はタイプ／クラス属性の対の値に関連する、命令；
から更に構成される、ことを特徴とする物品。
【請求項２１】
Ｎビットポインタとしてソースプログラムに関連する１つ又はそれ以上のポインタをマーキングするための一般アナライザ；
対応するクラスを有するＮビットポインタを関連付けるためのクラスアナライザ；
対応するタイプ／クラスの対を有するＮビットポインタを関連付けるためのタイプアナライザ；並びに
Ｎビットポインタに対して選択されたセグメント化モデルを維持するための結果としてのコード命令を生成するためのコード修正器；
から構成されることを特徴とするコンパイラ。
【請求項２２】
請求項２１に記載のコンパイラであって：
Ｎビットポインタとして前記ソースプログラムに関連するポインタ全てを初期化することと；
一般変数であるＮビットポインタをデフォルト長ポインタとしてマーキングするためにＮビット命令を無効にすることと；
に少なくともよって、前記一般アナライザはＮビットポインタとして１つ又はそれ以上のポインタをマーキングする、ことを特徴とするコンパイラ。
【請求項２３】
請求項２１に記載のコンパイラであって：
ベースポインタを初期化すること；
に少なくともよって、前記コード修正器は、前記の選択された前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成する、ことを特徴とするコンパイラ。
【請求項２４】
請求項２３に記載のコンパイラであって：
ソースプログラムにおけるアドレス取り込み動作に対してＮビットポインタ値からベースポインタの値を減算するために１つ又はそれ以上の命令を生成すること；
に少なくともよって、前記コード修正器は、前記の選択された前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成する、ことを特徴とするコンパイラ。
【請求項２５】
請求項２３に記載のコンパイラであって：
ソースプログラムにおける非参照動作に対してＮビットポインタ値にベースポインタの値を加算するために１つ又はそれ以上の命令を生成すること；
に少なくともよって、前記コード修正器は、前記の選択された前記の選択されたセグメント化モデルを維持するために結果としてのコード命令を生成する、ことを特徴とするコンパイラ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、情報処理システムに関し、特に、少なくとも２つのポインタ長を支援するプロセッサにおける性能を最適化するためのコンパイル／アセンブルソフトウェアコードに関する。
【背景技術】
【０００２】
マイクロプロセッサのデザインの進展において、３２ビットアーキテクチャ及び６４ビットアーキテクチャの両方が浮上してきた。この進展においては、勿論、ソフトウェアが
３２ビットプロセッサにおいて使用するために作成される。一部においては、６４ビットプロセッサにおいて３２ビットソフトウェアを実行することが望まれるようになった。多くのそのような３２ビットソフトウェアプログラムはポインタを多用する。例えば、３２ビットプロセッサにおいて実行するように最初にデザインされた、多くの整数処理及びトランザクション処理のアプリケーションは、ポインタ及びポインタベースの動的データ構造を益々利用するようになっている。ポインタベースのデータ構造は、順に、多数のポインタ要素を含むことが可能である。しばしば、それらのポインタ要素は、大部分のデータ構造のサイズを構成している。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
それ故、典型的には、キャッシュ汚染、並びに高いキャッシュ及び変換索引バッファ（ＴＬＢ）ミス率に対する大きい原因となる。ここで開示する方法および装置の実施形態においては、６４ビットプロセッサにおける３２ビットソフトウェアアプリケーションの性能に関連する、上記の及び他の関心事に対処する。
【０００４】
本発明については、類似する要素が類似する参照番号で示される添付図面を参照して理解することが可能である。それらの図面は、制限的なものではなく、ソフトウェアコードを最適化するための方法及び装置についての選択された実施形態を例示するために提供されている。
【発明を実施するための最良の形態】
【０００５】
図１及び２は、Ｎビットポインタを利用するようにソフトウェアソースコードを最適化するための方法１００の実施形態を示す、フロー図である。図１は一般的概念を示しており、図２は、最適化方法１００の実施形態の更に詳細な概念を示している。そのような最適化は、コンパイラにより、少なくとも１つの実施形態に対して実行される。しかしながら、最適化方法１００は、それ程、限定的ではなく、マニュアルによる又はアセンブラによるような、他の既知の方法において又、実行されることができる。ここで用いるように、方法１００を実行する“コンパイラ”を参照するとき、その方法を実行するいずれの他の既知の方式がそのような命令文により表されることが理解できるであろう。
【０００６】
方法１００は、結果のコードにおいて、実現可能である場合には、Ｎビットポインタを利用することにより最適化コードを生成するために提供される。ここで用いるように、用語“結果の”コードは、コンパイラにより生成されるバイナリコード、ハンド生成バイナリコード、アセンブラにより生成されるアセンブルコード、ハンドアセンブルコード等を包含する。
【０００７】
Ｎビットポインタは、ビット長Ｎを有するポインタであり、ここで、Ｎは結果のコードが実行されるように意図されているプロセッサのアーキテクチャのビット長より短く、Ｎは又、２の累乗である。例として、以下の説明は、ときどき、Ｎは３２であり、最適化コードは６４ビットプロセッサにおいて実行されるように意図されている。しかしながら、図１及び２に示している方法１００の実施形態は、いずれのプロセッサ（３２ビット、６４ビット、１２８ビット等）における性能をエンハンスするように用いられることが可能であること、及び、Ｎが、意図されるプロセッサのアーキテクチャの限界より小さい、いずれの２の累乗の数であることが可能であることに留意する必要がある。
【０００８】
大きい（６４ビットのような）ポインタは大きいアドレス領域を与えるが、それにも拘らず、エンティティのアドレスを表すためにＮビットポインタを用いることは好ましい。例えば、６４ビットポインタを用いるデータ構造が、３２ビットポインタを用いる類似するデータ構造のサイズの２倍に成長することが可能であることを考える。６４ビットデータ構造のサイズにおける増加は、キャッシュミス及びＴＬＢミスにおける対応する増加をもたらし、性能の劣化をもたらし得る。いずれの所定のアプリケーションに対して、値Ｎは、前提とされるアドレス領域の限界に依存する。ここで選択した実施形態の説明においては、６４ビットデフォルトポインタ及びＮビットポインタ（Ｎ＝３２）を、例示目的のために用いることにする。
【０００９】
図１は、実行可能である場合、結果のコードにおいて、Ｎビットポインタを用いるための方法について示している。方法１００は、手動で実行されることが可能であり、又、コンパイラ、アセンブラ等により自動的に実行されることが可能である。処理はブロック１０２において開始される。ブロック１０３において、前処理が実行され、結果のコードの生成に関連する種々のオプションに対するユーザ選択を決定するようにされる。少なくとも１つのそのようなオプションは、結果のコードに対して用いられるメモリセグメント化モデルである。他のそのようなオプションは、Ｎビットポインタが結果のコードにおいて生成される必要があるかどうかである。例えば、ソースコードが、大きいポインタにより表現することができる付加アドレス領域において利用されるように書き込まれる場合、ユーザはＮビットポインタを用いることを選択しないことが可能である。残りのブロック１１０、１１１、１１７、１２３は、ユーザがＮビットポインタを選択した場合に、実行される。そうでない場合、処理はブロック１３４において終了する。
【００１０】
Ｎビットポインタが好ましい場合、ソースコードの一般分析が実行される１１０．一般分析１１０中、Ｎビットポインタに関する情報が記録される。
【００１１】
コンパイラにより実行される方法１００の実施形態に対して、Ｎビットポインタ情報は、ソースコードのコンパイラの表現における一般分析１１０中、記録される。少なくとも１つの実施形態に対して、ソフトウェアプログラムのコンパイラの表現は、シンボルテーブル及び命令リストを含む。シンボルテーブルは、ソースコードにおける各々のポインタ及び構造タイプについての表現を更に含むことが可能である。ポインタに関して、ポインタに対する各々のシンボルテーブルエントリは、次のような属性であって、即ち、ビット長、クラス及びタイプに関連する値についてのフィールドを更に含むことが可能である。ビット長属性に対する許容値は、少なくとも２つの値であって、意図されたプロセッサ（例えば、６４ビット）のアーキテクチャの限界と、少なくとも１つのＮビット値（例えば、３２ビット）と、を含むことが可能である。一般分析処理１１０中にポインタに対してポインタ長がマーキングされることがこの属性フィールドにおいてある。他の属性値は、クラス及びタイプの属性フィールドに対して許容される値を有する。少なくとも一実施形態に対して、“クラス”属性についての許容値は、“テキスト”、“データ”、“スタック”、“ヒープ”及び“どれでも”を含むことが可能である。構造タイプに関しては、構造タイプが現在のコンパイル領域を抜け出したかどうかを示すフィールドを、構造タイプについての各々のシンボルテーブルエントリが含むことが可能である、ブロック１１０において実行される一般分析に加えて、特定のメモリセグメント化モデルに対して、付加分析を実行することが可能である。ブロック１１１において、クラス分析を実行する必要があるかどうかの判定がなされ、それが肯定される場合、そのような分析は実行される。それが否定される場合、処理はブロック１２３に進められる。
【００１２】
同様に、ブロック１１７において、タイプ分析を実行する必要があるかどうかの判定がなされ、それが肯定される場合、そのような分析は実行される。それが否定される場合、処理はブロック１２３に進められる。
【００１３】
ブロック１１７が実行された後、Ｎビット表現を用いることが実現可能であるポインタ全てが、シンボルテーブルにおいてマーキングされたことが仮定される。処理は、結果のコードが生成される、ブロック１２３に進められる。そのような生成中、結果のコードの命令は、シンボルテーブル属性により表されるようなＮビットポインタを用いるために生成される。
【００１４】
図１及び２は、図１のブロック１０３、１１０、１１１、１１７、１２３に関連する処理の更に詳細な説明に関連付けて、共に参照される。ブロック１０３に関連して、図２は、ブロック１０３（図１）の前処理に関連する詳細な処理１０４、１０６、１０８を示している。ブロック１０４においては、コンパイル又はアセンブル中、生成されるべき結果のコードに対して、ユーザはどのセグメント化モデルを所望するかが判定される。選択されたセグメント化モデルは、実行中に結果のコードに対して割り付けられた論理アドレス
空間においてポインタがどのようにグループ化されるかについての選択を促進させることが可能である。次いで、ブロック１０６において受けるユーザ入力に基づいて、Ｎビットポインタを用いて最適化される結果のコードをユーザが望むかどうかについての判定がなされる１０８。その判定が否定的である場合、処理はブロック１３４において終了する。
【００１５】
Ｎビットポインタを用いるように結果のコードに対してユーザが所望することが判定された１０８場合、処理はブロック１１０において継続される。ブロック１１０においては、ソースコードの命令が、変数、オブジェクト等のようなどのソフトウェアエンティティが結果のコードにおいてＮビットポインタにより表されることが可能であるかについて、一般に判定するように分析される。ブロック１１０の少なくとも１つの実施形態に関連する更に詳細な処理については、図３乃至６に関連して、下で更に詳細に説明する。
【００１６】
図１及び２は、一般分析がブロック１１０において実行された後に、更に具体的な分析ブロック１１１、１１７が実行されることを示している。図１に示しているクラス分析処理１１１は、少なくとも１つの実施形態に対して、図２に示すようなブロック１１２及び１４を更に含む。図１に示すタイプ分析処理１１７は、少なくとも１つの実施形態に対して、図２に示すようなブロック１１８、１２０及び１２２を更に含む。
【００１７】
クラス分析処理１１１に関しては、図２は、ユーザが複数の又はタイプ化された複数のセグメント化モデルを選択した１０４ことが判定される場合、処理はブロック１１４において継続されることを示している。否定的な場合、一般に、処理は、コード生成ブロック１２３（図１）に進められる。更に具体的には、処理は、図２に示すブロック１２４に進められる。
【００１８】
ブロック１１４において、クラス分析が、ソースコードにおける割り付けの集合に関して実行される。ユーザが複数のセグメント化モデルを選択した１０４場合、ユーザは、各々の許容されたポインタクラスが実行可能コードにおいて異なるベースポインタに関連付けられることを、実質的に要求する。少なくとも１つの実施形態に対して、許容されたポインタクラスは、スタック、ヒープ、静的データを含む。ユーザが選択したセグメント化モデルを実行するために、特定のクラスのエンティティに対するポインタは論理メモリのアドレスの特定セグメントにおけるアドレスのみを指し示すことを、方法１００は条件とする。セグメントは、ポインタクラスに割り付けられた論理アドレスの領域である。ブロック１１４において、次の処理が行われる。命令ストリームにおけるオブジェクトのみを指し示すことができるソースコードにおける各々のポインタに対して、そのようなポインタに対するシンボルデーブルエンティティは、ポインタがストレージクラス“ｔｅｘｔ”を有することを表すように修正される。スタックにおけるオブジェクトのみを指し示すことができる各々のポインタに対して、そのようなポインタに対するシンボルデーブルエンティティは、ポインタがストレージクラス“スタック”を有することを表すように修正される。同様に、静的データ領域におけるオブジェクトのみを指し示すことができる各々のポインタに対するシンボルテーブルエントリは、ストレージクラス“データ”を反映するように修正される一方、ヒープセグメントにおけるオブジェクトのみを指し示すことができる各々のポインタに対するシンボルテーブルエントリは、ストレージクラス“ヒープ”を反映するように修正される。ストレージクラスがポインタに対して決定されることができない場合、そのポインタに対するストレージクラスはシンボルテーブルにおいて“不明”として記録される。従って、少なくとも１つの実施形態に対して、ポインタの各々は、可能な場合、許容されたストレージクラスの１つに属するとして表され、それ故、特定のセグメントに属するとして表される。上記のように、各々のストレージクラスはメモリの特定のセグメントに関連付けられ、各々のメモリセグメントは異なるベースポインタに関連付けられる。当業者は、０ベース又は単一のセグメント化モデルが選択された１０４場合、そのような処理１１４は実行される必要がないことを、認識するであろう。
【００１９】
タイプ分析処理１１７（図１）に関して、図２は、ユーザがタイプ化された複数のセグメント化モデルを選択した場合、付加モデル特定分析１２０、１２２が実行されることを示している。タイプ化された複数のセグメント化モデルに対して、ストレージクラスの各々が複数のポインタタイプと関連付けられることが可能である。例えば、ヒープセグメントに記憶された複数のポインタタイプ及び／又はスタックセグメントに記憶された複数のポインタタイプ及び／又はデータセグメントに記憶された複数のポインタタイプが存在し得る。１つのセグメントに記憶された複数のポインタタイプは、他のセグメントに記憶された複数のポインタタイプと一致する又は一致しないことが可能である。ブロック１１８において、ユーザがタイプ化された複数のセグメント化モデルを選択したかどうかが判定される。否定的である場合、一般に、処理は、コード生成部ロック１２３（図１）に進められる。更に具体的には、処理は、図２に示しているブロック１２４に進められる。ユーザがタイプ化された複数のセグメント化モデルを選択したことが判定される１１８場合、処理はブロック１２０に進められる。
【００２０】
ブロック１２０において、タイプ分析が、ソースコードにおける各々のセグメント化に対して実行される。所定のソースタイプｘのオブジェクトのみを指し示すことができる各々のポインタに対して、ポインタのシンボルテーブルエントリはタイプ＝“ｘ”を反映するように修正される。ポインタのタイプが正確に決定されることができない場合、そのシンボルテーブルエントリは、タイプ＝“不明”を反映するように修正される。チェックが実行され１２２、ソースコードにおける各々の割り付けに対するタイプを処理するように、ループを効果的に生成する１２０、１２２。
【００２１】
図１のコード生成処理１２３は、少なくとも１つの実施形態に対して、図２に示すようなブロック１２４、１２６、１２８、１３０及び１３２を有する。ブロック１０４においてユーザにより選択されたセグメント化モデルに基づいて、ブロック１２４において、ケース選択が実行される。即ち、０ベースのセグメント化モデルが選択された１０４場合、ブロック１２６が実行される。他方、単一のセグメント化モデルが選択された１０４場合、ブロック１２８が実行される。同様に、複数のセグメント化モデルが選択された１０４場合、ブロック１３０が実行され、タイプ化された複数のセグメント化モデルが選択された１０４場合、ブロック１３２が実行される。
【００２２】
図２及び９は、ブロック１２６において、０ベースのセグメント化モデルに対するコード生成処理が実行されることを示している。背景情報として、０ベースのセグメント化モデルに対して、ポインタ全てが単一のセグメントに位置付けられていることに留意する必要がある。従って、ブロック１２６における処理の間、結果のコードは、結果としてのプログラムコードにおける最上位アドレスが２Ｎ−１より大きくならないようなメモリに割り付けられるようにマーキングされる９０２。即ち、結果としてのコードにおける最上位アドレスは、Ｎビットを用いて表されることができる最上位アドレスを上回ることはない。方法１００がコンパイラにより実行される実施形態に対しては、リンカ（図示せず）及びローダ（図示せず）サポートが、そのようなアドレス制限を実行するように用いられることが可能である。
【００２３】
ベースポインタセグメント化モデルの全てに対して、結果としてのプログラムのための始動コードは、必要に応じて、モデルに対してベースポインタを初期化する。コード生成処理１２６、１２８、１３０、１３２の間、それ故、始動コードがそのようなポインタを適切に初期化するように、命令が生成される。例えば、ブロック１２６において、コードは、ポインタとして最下位アドレスに単一のポインタを初期化するように生成される９０４。
セグメント化モデルは“０ベース”モデルと呼ばれるが、ベースアドレスは、通常、０ではない。
【００２４】
最小ロードアドレスを示すように結果としてのコードに対して命令９０２を生成すること及び単一のセグメントにベースポインタを初期化するように命令９０４を生成することに加えて、結果としてのコード命令が、ソースプログラムにおける命令に対して生成される９０６。方法１００がコンパレータにより実行される実施形態に対して、命令が、コンパレータにより維持されるソースコード命令のリストにおける命令のために生成される９０６。結果としてのコード命令が生成される９０６とき、シンボルテーブルエントリが“Ｎビット”としてマーキングされるポインタ全ては、サイズの減少を有するとして処理され、０ベースセグメントにおいて位置付けられる。
【００２５】
図２を参照するに、ブロック１２８、１３０及び１３２は、それぞれ、単一のコード生成処理、複数のコード生成処理及びタイプ化された複数のコード生成処理を表す。それら１２８、１３０及び１３２の各々は、一般に、ベースポインタを初期化することと、アドレス取り込み動作及び非参照動作に対する特定処理を含むソースコードにおける命令のための結果としてのコード命令を生成することとに関連する。
【００２６】
具体的には、図２及び１０は、ブロック１２８が単一のセグメント化モデルに対するコード生成処理を表すことを示している。他のモデル全てと同様に、結果としてのコード命令は、ソースプログラムにおける命令に対して生成される１００２。そのような命令が生成される１００２とき、シンボルテーブルエントリが“Ｎビット”としてマーキングされるそれらのポインタは、サイズの減少を有するとして処理され、単一のセグメントに位置付けられる。更に、アドレス取り込み命令及び非参照命令が結果としてのコードの命令に付加される。アドレス取り込みのために、ここで、“ベース”と呼ばれる変数が修正されたポインタ値を生成するようにポインタ値から減算されるような、Ｎビットポインタを含むアドレス取り込み動作全てに対して、コードが生成される１００４。修正されたポインタ値は、結果としてのコードにおけるアドレス取り込み動作に対して用いられる。同様に、コードは、Ｎビットポインタを含む非参照動作全てに対して生成される１００６。即ち、コードは、修正されたポインタ値を生成するためにＮビットポインタの値に“ベース”値を加算するように生成される。修正されたポインタ値は、結果としてのコードにおける非参照動作のために用いられる。更に、単一のセグメント化モデルのためのベースポインタを初期化するための命令が生成される１００８。従って、コードは、プログラムのメモリにおける最下位アドレスを指し示すプログラムのエントリからの全ての経路における可変ベースポインタを初期化するように、ブロック１００８において生成される。
【００２７】
図２及び１１を、複数モデルに対するコード生成処理１３０についての更なる説明のために参照する。ブロック１１０２において、結果としてのコード命令は、ソースプログラムにおける命令に対して生成される。そのような命令が生成される１１０２とき、シンボルテーブルエントリが“Ｎビット”としてマーキングされるそれらのポインタは、サイズの減少を有するとして処理される。そのようなポインタは、シンボルテーブルのポインタに対して維持される属性リストにおけるポインタのストレージクラスインジケータに関連するセグメントに置かれる。更に、Ｎビットポインタを用いるソースコードにおける各々のアドレス取り込み動作のための結果としてのコードにおいて、命令が生成される。具体的には、修正されたポインタ値を生成するようにポインタ値から適切なベースポインタ変数を減算するためにＮビットポインタを含むアドレス取り込み動作全てに対して、コードが生成される。シンボルテーブルエントリがタイプ“テキスト”のストレージクラスを表すＮビットポインタに対して、修正されたポインタ値を生成するようにポインタ値からテキストセグメントに関連するベース値を減算するために、結果としてのコードが生成される１１０４。同様に、シンボルテーブルエントリがタイプ“データ”のストレージクラスを表すＮビットポインタに対して、修正されたポインタ値を生成するようにポインタ値からデータセグメントに関連するベース値を減算するために、結果としてのコードが生成される１１０４。同様に、シンボルテーブルエントリがタイプ“スタック”のストレージクラスを表すＮビットポインタに対してポインタ値からスタックセグメントに関連するベース値を減算するための命令が生成される１１０４。又、シンボルテーブルエントリがタイプ“ヒープ”のストレージクラスを表すＮビットポインタの値からヒープセグメントに関連するベース値を減算するための命令が生成される１１０４。勿論、シンボルテーブルが、特定のタイプのエントリが存在しないことを反映する場合、そのようなタイプのベースポインタに対するアドレス取り込み命令は生成されない１１０４。生成された１１０４命令により生成された、それらの修正されたポインタ値は、それぞれのＮビットポインタに対するアドレス取り込みを実行するように、結果としてのコードにおいて用いられる。
【００２８】
ブロック１１０６において、コードは又、Ｎビットポインタを用いるソースコードにおける各々の非参照動作に対する結果としてのコードにおいて生成される。各々のそのような非参照動作に対して、命令が、修正されたポインタ値を生成するようにポインタ値に適切なベース値を加算するために生成される１１０６。修正されたポインタ値は、結果としてのコードにおける非参照動作に対して用いられる。Ｎビットポインタ値に加算されたベースポインタは、下記の段落において説明するように、Ｎビットポインタストレージクラスに対応するベース値である。
【００２９】
コードは、プログラムのエントリからの全てのパスにおけるベース変数を初期化するために生成される１１０８。コードは、命令を記憶するために用いられる最下位アドレスに対してテクストレージセグメントのためのベースアドレスを初期化するために生成される１１０８。コードは、静的データを記憶するために用いられる最下位アドレスに対してデータセグメントのためのベースアドレスを初期化するために生成される１１０８。コードは、スタックの開始アドレスにスタックセグメントのベースアドレスを初期化するために生成される。そして、コードは、ヒープ割り付け機能により戻される最下位アドレスに対してヒープセグメントのためのベースアドレスを初期化するために生成される１１０８。
【００３０】
図２及び１２は、ブロック１３２において、タイプ化された複数のセグメント化モデルに対するコード生成処理が実行されることを示している。ここでの説明は、タイプ化された複数のセグメント化モデルに対するコード生成処理１３２が各々のストレージクラスに対して複数のポインタタイプを考慮するという点で更に詳細であることを除いて、タイプ化された複数のコード生成処理１３２は、上記の複数のベースコード生成処理１３０に類似していることを表している。従って、ソースコードにおいて命令から結果としてのコードを生成する１２０１一方、ブロック１３２の処理は、ストレージタイプ“スタック”又は“どれでも”を有するとしてマーキングされたポインタが減少したサイズ有するとして処理されないことを除いて、Ｎビットポインタであることをシンボルテーブルエントリが示すポインタ全てを、減少したサイズを有するとして処理される。
【００３１】
命令は、同じポインタタイプの変数及びテキスト全てがメモリに連続して割り付けられるような結果としてのコードに対して生成される。この処理に基づいて、ストレージクラス／ポインタタイプ属性の対各々に対するベースポインタが、そのような連続的なメモリ領域の範囲内の位置を指し示すように初期化される。下の表１は、そのような連続割り付け及び関連するベースポインタの例を示している。
【００３２】
【表１】
2006510118.tif 000003
【００３３】
更に、Ｎビットポインタを含む各々のソースコードアドレス取り込み動作に対して、結果としてのコードに対して、命令が生成される１２０４。各々のそのようなアドレス取り込む動作に対して、コードが、結果としてのコードにおいて用いられる修正されたポインタ値を生成するために適切な値を減算するように結果としてのコードにおいて生成される１２０４。例えば、例示として表１の例を用いて、シンボルテーブルエントリがストレージクラス“ｔｅｘｔ”及びタイプｓを有することを表すＮビットポインタに対して、結果としてのコードにおけるアドレス取り込みのために用いられる修正されたポインタ値を生成するためにポインタ値から値ｔｅｘｔ＿ｂａｓｅ＿ｓが減算させるように、命令が生成される１２０４。同様に、シンボルテーブルエントリがストレージクラス“ｄａｔａ”及びタイプｓを有することを表す例示としてのＮビットポインタに対して、結果としてのコードに対する修正されたポインタ値を生成するためにポインタ値から値ｄａｔａ＿ｂａｓｅ＿ｓが減算させるように、命令が生成される１２０４。同様に、異なる値、即ち、ｄａｔａ＿ｂａｓｅ＿ｔをポインタ値から減算するための命令が、タイプｔ及びデータストレージクラスのＮビットポインタに対して生成される。又、結果としてのコードにおいて用いられる修正されたポインタ値を生成するためにポインタ値から各々のタイプに対する適切なベースアドレス値が減算されるようなストレージクラス“ｈｅａｐ”のＮビットポインタを含むアドレス取り込み動作全てに対して、コードが生成される。例えば、シンボルテーブルエントリがタイプｓ及び“ｈｅａｐ”のストレージクラスを表すＮビットポインタに対して、ｈｅａｐ＿ｂａｓｅ＿ｓのような変数を減算する命令は、結果としてのコードにおけるアドレス取り込み動作に対するポインタ値から減算されることが可能である。要するに、ベースアドレス値は、ストレージクラスにおけるティーチングタイプの第１アドレスに対して初期化される１２０３。ポインタ値からそのベースアドレス値を減算するための命令は、アドレス取り込み動作に対する結果としてのコードにおいて生成される１２０４。
【００３４】
コード生成処理１３２は、ヒープに関連するとき、所望のセグメント化を容易にするように結果としてのコードに対する命令を更に生成する１２０５。値がＮビットポインタに割り付けられるソースコードヒープ割り付け機能全てに対して、割り付けはセグメント化される。即ち、タイプｘのＮビットポインタに割り付けられる各々のヒープ割り付けに対して、タイプｘのオブジェクトに対して割り付け機能を結果としてのコードが用いるように、命令が生成される。従って、結果としてのコードは、ヒープストレージクラスにおけるＮビットポインタの各々のタイプに対して特定のヒープアロケータを用いる。
【００３５】
ブロック１３２において、結果としてのコード命令は又、Ｎビットポインタに対するソースコード非参照動作に対して生成される１２０６。Ｎｂｉｔｔｏ  ｐｏｉｎｎｔａ  ｗｏ含むソースコード非参照動作全てに対する結果としてのコードは、メモリ参照を実行する前に、Ｎビットポインタ値に適切なベースアドレス変数を加算するために生成される。前段落に説明したように、ストレージクラスにおける各々のタイプは異なるベースアドレス変数に関連付けられる。
【００３６】
ブロック１３２は又、プログラムのエントリからの全てのパスに沿って特定のアロケータ機能を初期化するための結果としてのコード命令の生成１２０８を含む。初期化は、各々のタイプがポインタの減少されたアドレスを完全に用いるように十分な空間を有することを条件とするようにする。結果としてのコード命令は又、プログラムのエントリからの全てのパスにおいて各々のクラスの各々のタイプに対してベースアドレス変数を初期化するために生成される。例えば、ｔｅｘｔ＿ｂａｓｅ＿ｓは、タイプｓの機能に対する命令を記憶するために用いられる最下位アドレスに初期化される。同様に、ｄａｔａ＿ｂａｓｅ＿ｓは、タイプｓの静的データオブジェクトを記憶するために用いられる最下位アドレスに初期化され、ｈｅａｐ＿ｂａｓｅ＿ｓは、タイプｓのポインタに対する特定のヒープ割り付けにより戻される最下位アドレスに初期化される。
【００３７】
図３、４、５及び６を参照するに、図１に関連して、上で間単位説明した一般分析の少なくとも１つの実施形態について考察する。そのような一般分析処理１１０中、変数、オブジェクト等のような、どのソフトウェアエントリが、ここで説明する４つのセグメント化モデルのいずれに対して結果としてのコードにおいてＮビットポインタにより表されることが可能であるかを、一般に判定する。（図に関連して説明しているように、付加分析処理１１２、１１４、１１８、１２０、１２２が又、特定のセグメント化モデルとの関連において実行されることが可能である。）
図３は、一般分析処理１１０に対する処理がブロック３０２において開始することを示している。処理は、ソースプログラムにおける各々のポインタに対するシンボルテーブルが、ポインタがＮビットポインタであることを反映するように楽観的に修正されるブロック３０４に進められる。一般分析処理１１０の残りは、その代わりに、そのような楽観主義が保証されておらず、ポインタが“デフォルト”のより大きいポインタ（６４ビットポインタのような）として再マーキングされる必要があるそれらの例を決定する。このように、楽観的なＮビット初期化は、楽観主義が保証されている場合、無効にされる。そのような初期化３０４中、各々のポインタテーブルに対するシンボルテーブルにおいて維持される他の属性は又、初期化されることが可能である。例えば、各々のポインタに対するポインタタイプ及びストレージクラスはデフォルト値に初期化されることが可能である。
【００３８】
一般に、ソースアプリケーションに対する複雑性範囲を回避するポインタはＮビットポインタとしてマーキングされる候補ではない。異なる状態は、ポインタが現在の複雑性範囲を回避するようにすることができる。ブロック３０６においては、例えば、全てのグローバルポインタは、Ｎビットポインタとしてマーキングされたままではなく、シンボルテーブルにおいてデフォルトポインタとしてマーキングされる。同様に、ブロック３０７において、現在の複雑性範囲の外側から呼び出されることができる機能全てに対して、仮パラメータ及び戻り値の全ては、デフォルトポインタとしてシンボルテーブルにおいてマーキングされる。同様に、ブロック３０８において、現在の複雑性範囲の外側に規定された機能に対する呼び出しの戻り値は又、デフォルトポイントとしてシンボルテーブルにおいてマーキングされる。
【００３９】
更に、構造タイプは又、現在の複雑性範囲を回避することができる。回避された構造タイプは、Ｎビットポインタになるように無効であるフィールドポインタ全てをレンダリングする。回避リストは、ルールの集合に従って、複雑性範囲を回避する構造タイプを識別するために維持される。図３は、回避リストが“空”に初期化され３０９、構造タイプ全てに対するシンボルテーブルエントリが“回避しなかった”に初期化されることを示している。ブロック３１１において、ソースプログラムにおける割り付けが識別される。少なくとも１つの実施形態に対して、ステートメントは、Ｃ又はＣ＋＋のような高水準のプログラミング言語で書かれたプログラムにおける割り付けは次のような集合からの一連の割り付けに正規化されることができるため、ステートメントが次のステートメントタイプの集合に入る場合、そのステートメントは割り付けステートメントとして識別される３１１。表記法の簡単化のために、ｐがタイプＴに対するポインタである場合に、フォーム＊ｐの参照は、オフセット０が割り付けられたｆｉｅｌｄＴが添えられて、（＊ｐ）．ｆｉｅｌｄＴと表される。この表現を用いることにより、それに対するポインタを有するタイプは、複数レベルのポインタタイプを含む構造タイプとなる。割り付けとして識別されたステートメントタイプの集合は次のようなものを含む。
１．ｐ＝ｑ
２．ｐ＝（ｔｙｐｅｃａｓｔ）ｑ
３．ｐ＝＆ｑ
４．ｐ＝＆（（＊ｐ）．ｆｉｅｌｄ＝ｑ）
５．（＊ｐ）．ｆｉｅｌｄ＝ｑ
６．（＊ｐ）．ｆｉｅｌｄ＝ｑ
７．ｐ＝ｑ  ｏｐ  ｙ
更に、基本呼び出しｐ＝ｆｏｏ（ａ＿１，ａ＿２，．．．，ａ＿ｎ）は、次のような、実引数（ａ＿１，ａ＿２，．．．，ａ＿ｎ）と対応する仮パラメータ（ｆ＿１，ｆ＿２，．．．，ｆ＿ｎ）との間の割り付けの集合を生成する。付加割り付けが又、次のような割り付けの集合に示すように、戻り値に対して生成される。
１．ｆ＿１＝ａ＿１
２．ｆ＿２＝ａ＿２
．．．
ｎ．ｆ＿ｎ＝ａ＿ｎ
ｐ＝ｒｅｔｕｒｎ＿ｆｏｏ
更に、関数ｆｏｏからのフォーム｛ｒｅｔｕｒｎ  ｐ；｝の戻りステートメントは次のような割り付けを生成する。
ｒｅｔｕｒｎ＿ｆｏｏ＝ｐ
ブロック３１１において識別された割り付けステートメントは、それらがＮビットポインタになるように無効である１つ又はそれ以上のポインタをレンダリングする。処理はインタラクティブであり、各々の割り付けステートメントが処理される。
【００４０】
処理１１０による第１パス（ｐａｓｓ）に対して、第１割り付けが現在の割り付けとして識別される。ブロック３１３において、現在の割り付けステートメントにより構造タイプが現在の複雑性範囲を回避するようにされるかどうかの判定がされる。幾つかの状態は、構造タイプが現在の複雑性範囲を回避するようにすることができる。それらの状態はブロック３１３においてチェックされる。ブロック３１３については、図７に更に詳細に示している。
【００４１】
図７を参照するに、図３のブロック３１３において実行される条件チェックを更に詳細に示している。構造タイプは、いずれの次の条件がポインタに適用される場合、現在の複雑性範囲を回避したとみなされ、ここでは、例示目的のために、所定の構造タイプに対して“ｐｔｒ”と表される。それらの条件は次のようなものである。
１）ｐｔｒはグローバル変数に割り付けられる（即ち、ｇｌｏｂａｌ＝ｐｔｒ）。
２）ｐｔｒは、現在の複雑性範囲の外側に定義される機能を用いて、機能呼び出しに対する引数としてパス（ｐａｓｓ）される（即ち、ｆｏｏ（ｐｔｒ）又は３）。
３）アドレス動作がｐｔｒによりフィールドアクセスにおいて適用される（即ち、（＆（ｐｔｒ→ｆｉｅｌｄ））。
【００４２】
図７は、条件１が動作７０２においてチェックされることを示している。構造タイプへのポインタがグローバル変数に割り付けられる場合、処理はブロック３１４に進められる（図４）。そうでない場合、構造タイプへのポインタが機能呼び出しに引数としてパスされるかどうかの判定がなされ７０４、ここで、その機能は現在の複雑性範囲の外側であると定義されている。その判定が肯定的である場合、処理はブロック３１４に進められる（図４）。そうでない場合、構造タイプへのポインタにより割り付けられたフィールドにアドレス動作が適用されるかどうかの判定がなされる７０８。その判定が肯定的である場合、構造タイプは、現在の複雑性範囲を回避し、処理はブロック３１４に進められる（図４）。条件チェック７０２、７０４、７０８のいずれもが肯定的に評価されない場合、いずれの構造タイプは現在の複雑性範囲を回避しなかったとして、処理はブロック５２０に進められる（図５）。
【００４３】
図４は、ブロック３１３において、現在の割り付けステートメントにより構造タイプが現在の複雑性範囲を回避するようにされることが決定される場合であって、構造タイプが“回避しなかった”として、現在、マーキングされる場合、構造タイプに対するシンボルテーブルエントリは“回避した”としてマーキングされ、その構造タイプは回避リストに入力される。処理は、次いで、ブロック５２０に進められる（図５）。
【００４４】
図５を参照するに、図５の処理５２０乃至５３４は、ソースコードからの割り付けにおいて実行される付加的一般分析処理１１０について示している。第１構造タイプが、割り付けステートメントの反対側において第２構造タイプを有する割り付けにおいて用いられることが決定される場合、そのような割り付けが第１構造タイプの割り付け動作であることが判定される。割り付け動作が確認された場合５２０であって、どちらかの構造タイプが、現在、“回避しなかった”としてマーキングされた場合、それはシンボルテーブルにおいて“回避した”とマーキングされ、ブロック５２２において、回避リストに入れられる。しかしながら、割り付け動作がブロック５２０において確認されない場合、処理はブロック５２４に進められる。
【００４５】
ブロック５２４において、現在の割り付けがＮビットの及びデフォルトポインタ混合割り付けをもたらしているかどうかの判定がなされる。その判定が肯定的である場合、処理は、割り付けにおいてＮビットポインタに対するシンボルテーブルエントリがデフォルトポインタサイズであるとしてマーキングされるブロック５２６に進められる。そうでない場合、処理はブロック５２８に進められる。
【００４６】
ブロック５２８において、ソースコードの命令のリストが、シンボルテーブルエントリがＮビットフィールドポインタを表すようにマーキングされたフィールドポインタがデフォルトサイズポインタにより参照されるようにされるかどうか、判定するために分析される。肯定的である場合、シンボルテーブルにおけるＮビットポインタのエントリはデフォルトポインタサイズを反映するように修正される５３０。そうでない場合、処理はブロック５３２に進められる。
【００４７】
ブロック５３２において、ブロック３１１（図３）において確認された割り付けの付加割り付けが尚も処理されていないかどうかが判定される。その判定が肯定的である場合、次の割り付けステートメントが、現在の割り付けになるように取り出され５３４、処理は、図３に示すブロック３１３に戻される。このように、一般分析１１０は、尚も処理されていない更なる割り付けがなくなるまで、反復して実行される。
【００４８】
図６は、尚も処理されていない更なる割り付けがない場合、処理がブロック６０２に進められることを示している。ブロック６０２において、回避リストの反復処理が開始される。構造タイプＴが、回避リストにおける構造タイプから選択される６０２。（回避リストが空である場合、処理はブロック６０８に進められる。）構造タイプＴは、必要に応じて、デフォルト（即ち、Ｎビットではない）として適切なシンボルテーブルエントリをマーキングするように処理され６０４、回避リストにおいて更なるエントリを実行する。ブロック６０４において、タイプＡの構造が現在の複雑性範囲を回避する場合、及び、構造タイプＡが構造タイプＢのフィールドポインタを含む場合、構造タイプＢは又、現在の複雑性範囲を回避したとみなされる。回避リストにおいて付加構造タイプが存在することが判定されると６０６、処理はブロック６０２に戻され、回避リストのエントリすべては、それ故、反復して処理される。
【００４９】
ブロック６０８において、一般分析処理中、Ｎビットサイズではなくデフォルトサイズを反映するように、シンボルテーブルにおけるいずれのポインタのエントリが変化されたかどうかの判定がなされる。その判定が肯定的である場合、何れのポインタが楽観的なＮビット指定からデフォルトサイズ指定まで戻るように変化される必要があるかどうか、反復して判定されるように、処理はブロック３１２（図３）に戻される。
【００５０】
ブロック６０８において、Ｎビットサイズではなくデフォルトポインタサイズの属性値を反映するように現在のパス中、変化されたポインタのシンボルテーブルエントリが存在しないと判定される場合、一般分析１１０の処理は終了する６１０。
【００５１】
上記において、実現可能である場合、Ｎビットポインタが用いられるようなソースコードから結果としてのコードを生成する種々の特徴について説明した。説明のために、特定の数、例、システム及び構成について、一貫した理解ができるように説明した。しかしながら、当業者は、特定の詳細を用いないで、上記の方法を実行することが可能であることを理解しているであろう。他の例においては、本発明の方法を不明瞭にしないように、周知の特徴についての説明は省略し、又は簡略化した。
【００５２】
方法１００の実施形態については、ハードウェア、ソフトウェア、ファームウェア又はそのような実施方法の組み合わせにおいて実施することが可能である。方法１００のソフトウェアの実施形態は、少なくとも１つのプロセッサ、データ記憶システム（揮発性及び不揮発性メモリ及び／又は記憶素子）、少なくとも１つの入力装置並びに少なくとも１つの出力装置から構成されるプログラム可能システムにおいて実行されるコンピュータプログラムとして実施されることが可能である。プログラムコードは、上記のように説明した機能を実行するために入力データに適用されること及び出力情報を生成することが可能である。出力情報は、既知の方式で、１つ又はそれ以上の出力装置に供給されることが可能である。この供給のために、処理システムは、例えば、ディジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）又はマイクロプロセッサ等のプロセッサを有するいずれのシステムを含む。
【００５３】
プログラムは、処理システムと通信するために高水準の手続き型言語又はオブジェクト指向プログラミング言語において実行されることが可能である。プログラムは又、所望であれば、アセンブリ言語又は機会号において実行されることが可能である。実際には、上記において説明した動的方法は、いずれの特定のプログラミング言語に限定されるものではない。いずれにしても、その言語はコンパイラ型言語又はインタープリタ型言語であることが可能である。
【００５４】
プログラムは、汎用プログラム可能処理システム又は特定用途向けプログラム可能処理システムにより読み出し可能である記憶媒体又は装置（例えば、ハードディスク、フロッピー（登録商標）ディスクドライブ、読み出し専用メモリ（ＲＯＭ）、ＣＤ−ＲＯＭ装置、フラッシュメモリ装置、ＤＶＤ（Ｃｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）又は他の記憶装置）において記憶されることが可能である。処理システムにおいてプロセッサにアクセス可能な命令は、上記の方法を実行するために処理システムにより記憶媒体又は装置が読み出されるときに、処理システムを構成し及び動作させるために備えられている。本発明の実施形態は又、構成される記憶媒体により処理システムが上記の機能を実行するように特定の及び所定の方式で動作するようにされる場合、処理システムと共に構成される機械読み出し可能媒体として実行されるとみなされることが可能である。
【００５５】
１つのそのようなタイプの処理システムの実施例について、図８に示している。上記の実施形態のように、例えば、Ｎビットポインタを使用するようにソフトウェアコードを最適化する方法のための処理を実行するために、サンプルシステム８００を用いることが可能である。サンプルシステム８００は、Ｉｎｔｅｌ社製のＰｅｎｔｉｕｍ（登録商標）Ｐｒｏ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩ、Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ、Ｐｅｎｔｉｕｍ（登録商標）４、Ｉｔａｎｉｕｍ（登録商標）及びＩｔａｎｉｕｍ（登録商標）ＩＩマイクロプロセッサに基づく処理システムを表すが、他のシステム（他のマイクロプロセッサを有するパーソナルコンピュータ（ＰＣ）、携帯情報端末、他の携帯型装置、エンジニアリングワークステーション、セットトップボックス等）を又用いることが可能である。一実施形態において、サンプルシステム８００は、Ｍｉｃｒｏｓｏｆｔ社製のＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムのバージョンを実行することが可能であるが、例えば、他のオペレーティングシステム及びグラフィックユーザインタフェースを又、用いることが可能である。
【００５６】
図８を参照するに、サンプル処理システム８００はメモリシステム８２２とプロセッサ８１４とを含む。メモリシステム８２２は、メモリの一般的表現として意図されており、例えば、ハードドライブ、ＣＤ−ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）及び関連回路等の種々のメモリを有することが可能である。
【００５７】
メモリシステム８２２は、プロセッサ８１４により実行されることが可能であるデータ信号により表される命令８１０及び／又はデータ８１２を記憶することが可能である。命令８１０及び／又はデータ８１２は、上記の技術のいずれ又は全てを実行するためのコードを有することが可能である。方法１００がコンパイラにより実行される実施形態に対して、命令８１０はコンパイラプログラム８０８を含むことが可能である。
【００５８】
図８は、上記の方法の実施形態１００を実行する命令が種々の機能モジュールに局部的にグループ化されることが可能であることを示している。コンパイラ８０８により実行される実施形態に対して、コンパイラ８０８は、一般アナライザ８２０、タイプアナライザ、クラスアナライザ８２４及びコードアナライザ８２６を含むことが可能である。フロントエンド８３０、最適化８３５及びバックエンド８４０として知られている命令の機能的グループ化を含むコンパイラ８０８に対して、方法１００は、命令８３５の最適なグループ化を用いて実行されることが可能である。
【００５９】
プロセッサ８１４により実行されるとき、一般アナライザ８２０は、図３、４、５及び６に関連して上で説明したような４つのセグメント化モデル全てに適切な一般分析１１０を実行する。クラスアナライザ８２１は、プロセッサ８１４により実行されるとき、図１及び２に関連して上で説明したように、クラス分析処理１１１を実行する。
【００６０】
タイプアナライザモジュール８２６は、プロセッサ８１４により実行されるとき、図１及び２に関連して上で更に詳細に説明したように、タイプ分析処理１１１を実行する。
【００６１】
プロセッサ８１４により実行されるとき、コード修正器モジュール８２６は、選択されたセグメント化モデルに従って結果としてのコード命令を生成する。そのような処理１２３については、図１、２、９、１０、１１及び１２に関連して上で更に詳細に説明している。
【００６２】
本発明の特定な実施形態について、図を参照しながら詳述したが、広範な特徴を有する本発明から逸脱することなく、変形及び修正を実行することができることを当業者が理解できることは明らかである。同時提出の特許請求の範囲は、本発明の真の範囲に網羅されるそのような変形及び修正すべてを包含することが意図されている。
【図面の簡単な説明】
【００６３】
【図１】実現可能である場合に結果としてのコードはＮビットポインタを用いるようなソースプログラムに対して結果としてのコードを生成するための方法の少なくとも１つの実施形態を示すフロー図である。
【図２】図１に示す方法の実施形態のための処理の更に詳細に示すフロー図である。
【図３】Ｎビットポインタとして適切なポインタをマーキングするためにコードを分析するための方法の少なくとも１つの実施形態を示すフロー図である。
【図４】Ｎビットポインタとして適切なポインタをマーキングするためにコードを分析するための方法の少なくとも１つの実施形態を示すフロー図である。
【図５】Ｎビットポインタとして適切なポインタをマーキングするためにコードを分析するための方法の少なくとも１つの実施形態を示すフロー図である。
【図６】Ｎビットポインタとして適切なポインタをマーキングするためにコードを分析するための方法の少なくとも１つの実施形態を示すフロー図である。
【図７】割り付けステートメントにより構造タイプが現在の複雑性範囲を回避するようにするかどうかを決定するための方法の少なくとも１つの実施形態を示すフロー図である。
【図８】Ｎビットポインタを用いるためにソフトウェアプログラムをコンパイルすることができるコンピュータシステムの少なくとも１つの実施形態を示すブロック図である。
【図９】０ベースセグメント化モデルに対するコード生成処理の実施形態を示すフロー図である。
【図１０】単一セグメント化モデルのためのコード生成処理の実施形態を示すフロー図である。
【図１１】複数セグメント化モデルのためのコード生成処理の実施形態を示すフロー図である。
【図１２】複数セグメント化モデルのためのタイプ化されたコード生成処理の実施形態を示すフロー図である。
【図１】
2006510118.tif 000004
【図２】
2006510118.tif 000005
【図３】
2006510118.tif 000006
【図４】
2006510118.tif 000007
【図５】
2006510118.tif 000008
【図６】
2006510118.tif 000009
【図７】
2006510118.tif 000010
【図８】
2006510118.tif 000011
【図９】
2006510118.tif 000012
【図１０】
2006510118.tif 000013
【図１１】
2006510118.tif 000014
【図１２】
2006510118.tif 000015
【国際調査報告】
2006510118.tif 000016
2006510118.tif 000017
2006510118.tif 000018