Ｎベースタイプの演算式の最適化
【課題】意味論的に同等な数学的表現をより少ない計算スタック空間を使用して実行することができるように、プログラム表現を変える。
【解決手段】演算式最適化の方法は、第１のベースを有する第１のプロセッサのために形成された、演算子と少なくとも１つのオペランドとを含む第１の命令（８０）を受け取る段階、全てのオペランドが潜在的な桁あふれ（８２）を伴っていないか、又は、演算子が桁あふれに対して敏感でない場合、第１のベースよりも小さい第２のベースを有する第２のプロセッサのために最適化された第２の命令（８８）に第１の命令（８０）を変換する段階、及び、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合、桁あふれの源である第３の命令（８６）をより広いベースに変換する段階を含む。
【解決手段】演算式最適化の方法は、第１のベースを有する第１のプロセッサのために形成された、演算子と少なくとも１つのオペランドとを含む第１の命令（８０）を受け取る段階、全てのオペランドが潜在的な桁あふれ（８２）を伴っていないか、又は、演算子が桁あふれに対して敏感でない場合、第１のベースよりも小さい第２のベースを有する第２のプロセッサのために最適化された第２の命令（８８）に第１の命令（８０）を変換する段階、及び、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合、桁あふれの源である第３の命令（８６）をより広いベースに変換する段階を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本出願は、以下の特許に関連する：
スッサー及びシュウェーブによる「リソース限定型装置のためのオブジェクト志向命令セット」という名称の１９９９年２月２日出願の米国特許出願、及び
レビ及びシュウェーブによる「確実に配分されたバイトコード照合を有する仮想計算機」という名称の１９９７年４月１５日出願の米国特許出願。
本発明は、コンピュータシステムに関する。より具体的には、本発明は、ｎベースタイプの演算式の最適化に関する。
【背景技術】
【０００２】
コンピュータプログラムの準備が図１に示されている。ユーザは、プログラムを高級プログラム言語１０で書く。高級プログラム言語１０で書かれたプログラムは、目標とする計算機によって実行することができる低級機械言語１２にコンパイルされる。例えば、高級Ｊａｖａ（登録商標）プログラム言語で書かれたプログラムは、低級バイトコード命令にコンパイルされる。バイトコード命令とは、「Ｊａｖａ（登録商標）仮想計算機」のための機械言語である。「Ｊａｖａ（登録商標）機械言語仕様」は、アジソン・ウェスレーから１９９９年に出版のリンドホルム他著「Ｊａｖａ（登録商標）機械言語仕様」第２版に説明されている。
【０００３】
一般的な高級プログラム言語は、演算式をサポートする。演算式は、１つ又はそれ以上のオペランドに作用する算術演算子によって形成される。一般的にサポートされる演算子は、加算、引き算、乗算、割り算、剰余、ネゲート、桁送り、ビット式論理和、ビット式論理積、及び、ビット式排他的論理和を含む。中間的な値は、１つ又はそれ以上の算術演算の結果である。高級言語はまた、一般的に多重又はｎベースの整数タイプをサポートし、算術演算がオーバ・ロードされる。オーバ・ロードは、演算子が混合タイプを有するオペランドを受け入れることを可能にする。例えば、Ｊａｖａ（登録商標）プログラム言語は、４つのベースの整数タイプ、すなわち、ｂｙｔｅ、ｓｈｏｒｔ、ｉｎｔ、及び、ｌｏｎｇをサポートする。これらのタイプは、各々、８、１６、３２、及び、６４ビット値をサポートする。「＋」演算子のような演算子は、これらの整数タイプのいずれのオペランドも受け入れるであろう。以下の３つの例は、混合ベースタイプを有するオペランドの演算のための「＋」演算子のオーバ・ロードを示している。
ｉｎｔ ａ、ｂ；
ａ＋ｂ；
ｓｈｏｒｔ ａ、ｂ；
ａ＋ｂ；
ｂｙｔｅ ａ、ｂ；
ａ＋ｂ；
【０００４】
このオーバ・ロードは、一般的に、値をより広いベースタイプに広げ、次に、算術演算を実行することによって行われる。例えば、「Ｃ」及びＪａｖａ（登録商標）コンパイラは、通常、タイプｂｙｔｅ及びｓｈｏｒｔの値をタイプｉｎｔに広げる。Ｊａｖａ（登録商標）言語において、タイプｉｎｔは、いつも３２ビットである。すなわち、タイプｓｈｏｒｔの１６ビット値とタイプｂｙｔｅの８ビット値とは、算術演算を実行する前に、３２ビットのタイプｉｎｔまで広げられる。Ｊａｖａ（登録商標）言語においては、上記で列挙した３つの例の各々に対して、以下のバイトコードが発生される。
ｉｌｏａｄ ａ
ｉｌｏａｄ ｂ
ｉａｄｄ
【０００５】
ｉｌｏａｄ命令は、８、１６、又は、３２ビット変数のいずれかをロードし、そのスタック上に３２ビットオペランドを置く。ｉａｄｄ命令は、スタックから２つの３２ビットオペランドを取り出し、それらを加え合わせ、３２ビットの結果をスタック上に戻して置く。
Ｊａｖａ（登録商標）と違って、いくつかの高級言語は、整数タイプ間の関係のみを規定し、各タイプのサイズは規定しない。例えば、「Ｃ」コンパイラの販売業者の１つは、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔのタイプのビットサイズを、各々、８、１６、及び、３２ビットであると規定してもよい。しかし、別の「Ｃ」コンパイラの販売業者は、同じタイプのサイズを、各々、１６、３２、及び、６４ビットであると規定するであろう。更に別のコンパイラは、そのビットサイズを、各々、１６、３２、及び、３２ビットであると規定してもよい。全ての場合において、各タイプのサイズ間の関係は維持されるが（タイプｂｙｔｅで表される値の数＜タイプｓｈｏｒｔで表される値の数、タイプｓｈｏｒｔで表される値の数＜タイプｉｎｔで表される値の数）、各タイプを表すのに使用される実際のビット数は異なってもよい。しかし、Ｊａｖａ（登録商標）のように、「Ｃ」は、特定の各コンパイラによって規定されるｉｎｔタイプのサイズで算術演算を実行する。これには、より小さいベースタイプを有する値をタイプｉｎｔまで広げることが必要である。
【０００６】
このタイプ拡大手法は、機械命令の数を減らし、従って、目標とする計算機の複雑さを低減する。しかし、このタイプ拡大は、一般的により大きな計算スタック空間を必要とする。例えば、タイプｓｈｏｒｔの２つの１６ビット値をそれらが３２ビットタイプに拡大された後で加え合わせることは、図２Ａ及び図２Ｂに示す通り、タイプｉｎｔの２つの３２ビット値を加え合わせるスタック空間と同じ量を使用する。
【０００７】
ここで図２Ａを参照すると、Ｊａｖａ（登録商標）言語のタイプｓｈｏｒｔの２つの１６ビット値を加え合わせる時のスタック使用法を示す流れ図が示されている。参照番号２０において、第１の１６ビットオペランドがロードされ、オペランドスタック上に押し付けられる。この時点のオペランドスタックは、参照番号３０で示されている。参照番号２２において、第１の１６ビットオペランドは、３２ビットに拡大される。参照番号２４において、第２の１６ビットオペランドがロードされ、オペランドスタック上に押し付けられる。参照番号２６において、第２の１６ビットオペランドが３２ビットに拡大される。この時点で、オペランドスタックは、４ｘ１６＝６４ビットを占有する。参照番号２８において、この２つの３２ビットオペランドは、３２ビットａｄｄ演算子を使用して加え合わされる。
【０００８】
ここで図３Ａを参照すると、タイプｉｎｔの２つの３２ビット値を加え合わせる時のスタック使用法を示す流れ図が表されている。参照番号４０において、第１の３２ビットオペランドがロードされ、オペランドスタック上に押し付けられる。このオペランドスタックは、図３Ｂで示されている。参照番号４２において、第２の３２ビットオペランドがロードされ、オペランドスタック上に押し付けられる。参照番号４４において、この２つの３２ビットオペランドは、３２ビットａｄｄ演算子を使用して加え合わされる。すなわち、上述の１６ビット加算及び３２ビット加算例の両方において、２つの３２ビットオペランドは、スタックから取り出されて３２ビットの加算演算を使用して加え合わされる前に、スタック上に押し付けられる。
【０００９】
プログラム実行が進行する間、スタックの大きさは、入れ子プロシージャの呼び出しのレベル、計算された式の複雑さ、及び、局所的に表された変数の数などの要素のためにサイズが変動する場合がある。スマートカードなどのリソース限定型装置においては、一般的に、タイプ拡大が行われるような計算を実行するのに利用できるメモリが不十分である。
リソース限定型装置は、一般的なデスクトップコンピュータなどと比べた場合、一般的に、メモリ、及び／又は、計算能力又は速度が比較的制限されているものであると考えられている。一例として、他のリソース限定型装置には、セルラー電話機、境界用走査装置、野外用プログラム可能装置、携帯情報端末（ＰＤＡ）、及び、ポケットベルや他の小型又は小さな衛星電波使用装置が含まれる。
【００１０】
賢い携帯用データ携行カードとしても知られるスマートカードは、一般的に、プラスチック又は金属から作られ、プログラムを実行するための内蔵マイクロプロセッサ又はマイクロコントローラとプログラム及びデータを記憶するメモリとを含む電子集積回路を有する。ほぼクレジットカードのサイズが可能なその様な装置は、８ビット又は１６ビットのアーキテクチャを備えたコンピュータ集積回路を有する。更に、これらの装置は、一般的に制限された記憶容量を有する。例えば、スマートカードのいくつかは、１キロバイト（１Ｋ）未満のランダムアクセスメモリ（ＲＡＭ）のほか、限られたロム（ＲＯＭ）、及び／又は、電気的消去可能ロム（ＥＥＰＲＯＭ）のような不揮発性メモリを有する。
【００１１】
更に、８ビット又は１６ビットアーキテクチャを有するスマートカードは、一般的に、内蔵８ビット又は１６ビット算術演算を各々有する。従って、スマートカードは、通常、３２ビット演算よりも効率的に８ビット又は１６ビット演算を実行することができる。３２ビットに拡大されたデータに対して３２ビット演算を実行することは、特に非効率的である。すなわち、スマートカードなどのリソース限定型装置の限られたアーキテクチャ及びメモリは、値がより大きな整数タイプに拡大されたプログラムを実行することを非実用的又は不可能にする。
【００１２】
「Ｊａｖａ（登録商標）機械言語」命令セットは、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔの整数タイプの値を処理するための算術命令セットを形成する。タイプｂｙｔｅ及びｓｈｏｒｔの変数は、編集中に整数タイプｉｎｔまで拡大される。反対に、「Ｊａｖａ Ｃａｒｄ（登録商標）（Ｊａｖａ（登録商標）プログラム言語をサポートするスマートカード）仮想計算機」は、整数タイプｉｎｔの変数を処理する命令セットに加えて、タイプｂｙｔｅ及びｓｈｏｒｔの変数を処理する別の命令セットを形成する。ほとんどの「Ｊａｖａ Ｃａｒｄ（登録商標）」アプリケーションは、タイプｓｈｏｒｔ又はｂｙｔｅのデータ値に対して演算する。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
コンピュータ産業においては、同じプログラムをリソース限定型装置で実行することができ、従って縦のプラットフォームに亘る相互運用性が達成されるように、比較的メモリが豊富なデスクトップコンピュータ上で実行するように意図された高級コンピュータ言語をサポートする傾向が増加している。この縦のプラットフォームに亘る相互運用性には、高級プログラム言語で書かれたプログラムがリソース限定型装置で実行された時、それらが仮に比較的メモリが豊富な装置で実行された場合にもたらすであろう同じ結果を示すことが必要である。例えば、Ｊａｖａ（登録商標）プログラム言語で書かれたプログラムの実行を、スマートカードプラットフォーム、手持式装置、消費者電気器具、デスクトップコンピュータ、及び、スーパーコンピュータを含む、様々なプラットフォーム上でサポートすることが必要である。
従って、意味論的に同等な数学的表現をより少ない計算スタック空間を使用して実行することができるように、プログラム表現を変える必要性が存在する。更に、実行速度が増加するようにそのような変形を行う必要性が従来技術において存在する。
【課題を解決するための手段】
【００１４】
演算式最適化の方法は、第１のベースを有する第１のプロセッサのために形成された、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階、全てのオペランドが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに対して敏感でない場合、第１のベースよりも小さい第２のベースを有する第２のプロセッサのために最適化された第２の命令に第１の命令を変換する段階、及び、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合、桁あふれの源である第３の命令をより広いベースに変換する段階を含む。演算式最適化の装置は、プログラム命令を有する少なくとも１つのメモリ、及び、第１のベースを有する第１のプロセッサに対して形成された第１の命令を受信し、少なくとも１つのオペランドのいずれもが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに敏感でない場合には、その第１の命令を第１のベースよりも小さい第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換し、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合には、桁あふれの源である第３の命令をより広いベースに変換するために、プログラム命令を使用するように形成された少なくとも１つのプロセッサを含む。
【図面の簡単な説明】
【００１５】
【図１】高級言語で書かれたプログラムをコンパイルする方法を示すブロック図である。
【図２】３２ビットに拡大された２つの１６ビットオペランドを加え合わせるためのスタックの使用法を示す流れ図である。
【図３】２つの３２ビットオペランドを加え合わせるためのスタックの使用法を示す流れ図である。
【図４Ａ】本発明の一実施形態に従って、リソース限定型計算機上での実行のために演算式を変換する方法を示すブロック図である。
【図４Ｂ】本発明の一実施形態に従って、Ｊａｖａ（登録商標）の部類に属するファイルを変換する段階を示すブロック図である。
【図５Ａ】デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本を示す図である。
【図５Ｂ】リソース限定型コンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本を示す図である。
【図６Ａ】２つのタイプｓｈｏｒｔの値の加算、及び、その結果を直ちにデスクトップコンピュータ上で型に入れることを説明するコード見本を示す図である。
【図６Ｂ】リソース限定型コンピュータ上に桁あふれを持ち込む可能性のある、演算の結果の直ぐの型入れを説明するコード見本を示す図である。
【図７Ａ】３つのタイプｓｈｏｒｔの値の加算、及び、その結果を直ちにデスクトップコンピュータ上で型に入れることを説明するコード見本を示す図である。
【図７Ｂ】リソース限定型コンピュータ上に桁あふれをもたらす可能性がある演算によるオペランド上の桁あふれによって影響されない演算の実行を説明するコード見本を示す図である。
【図８Ａ】２つのタイプｓｈｏｒｔの値の加算、及び、その結果をデスクトップコンピュータ上のタイプｓｈｏｒｔの値で割り算することを説明するコード見本を示す図である。
【図８Ｂ】リソース限定型コンピュータ上に桁あふれをもたらす可能性がある演算によって作り出されたオペランド上の桁あふれによって影響された演算の実行を説明するコード見本を示す図である。
【図９】本発明の一実施形態によるｎベースタイプの演算式最適化の方法を示す流れ図である。
【図１０】本発明の一実施形態によるｎベースタイプの演算式最適化の方法を示す詳細な流れ図である。
【図１１】本発明の一実施形態による命令を変換する段階を示す流れ図である。
【図１２Ａ】本発明の一実施形態によるターゲット命令を変換する方法を示す流れ図である。
【図１２Ｂ】本発明の一実施形態による初期値命令を変換する方法を示す流れ図である。
【図１３】本発明の一実施形態によるタイプ変換命令を変換する方法を示す流れ図である。
【図１４】本発明の一実施形態によるスタック操作命令を変換する方法を示す流れ図である。
【図１５】本発明の一実施形態による演算式を変換する方法を示す流れ図である。
【図１６】本発明の一実施形態による最適化された命令のタイプを判断する方法を示す流れ図である。
【図１７】本発明の一実施形態による、結果のタイプ及び結果の桁あふれを判断する方法を示す流れ図である。
【図１８】本発明の一実施形態によるロールバックポイントを記録する方法を示す流れ図である。
【図１９】本発明の一実施形態による変換処理をロールバックする方法を示す流れ図である。
【図２０】本発明の一実施形態による命令最適化の結果を伝達する段階を示す流れ図である。
【図２１】本発明の一実施形態による異なる制御経路からの変換情報を結合する段階を示す流れ図である。
【図２２Ａ】本発明の一実施形態による命令変換を示すブロック図である。
【図２２Ｂ】本発明の一実施形態による命令変換を示すブロック図である。
【発明を実施するための形態】
【００１６】
当業者は、本発明の以下の記述が単に例示的であることを理解するであろうし、本発明の開示の恩恵を受けるような当業者に対しては、本発明の他の実施形態が容易に示唆されるであろう。
本発明は、コンピュータシステムに関する。より具体的には、本発明は、ｎベースタイプの演算式の最適化に関する。本発明は、更に、（１）本発明のレイアウトパラメータ、及び／又は、（２）コンピュータ上で演算を実行する際に本発明を使用するためのプログラム命令、を記憶した機械読取可能媒体に関する。そのような媒体には、例として挙げると、磁気テープ、磁気ディスク、ＣＤ・ＲＯＭのような光学的読取可能媒体、及び、ＰＣＭＣＩＡカードのような半導体メモリが含まれる。この媒体はまた、小さなディスク、ディスケット、又は、カセットのような携帯用品目の形態を取ってもよい。この媒体はまた、ハードディスクドライブやコンピュータＲＡＭのようなより大きな又は固定式品目の形態を取ってもよい。
【００１７】
リソース限定型装置は、通常のデスクトップコンピュータなどと比べた場合、一般的に、メモリ、及び／又は、計算能力又は速度が比較的制限されているものであると考えられている。以下で検討する特定の実施例はスマートカードに関して説明されるが、本発明は、他のリソース限定型装置と共に使用することができ、それらには、以下に限定されないが、セルラー電話機、境界用走査装置、野外用プログラム可能装置、携帯情報端末（ＰＤＡ）、及び、ポケットベルのほか、他の小型又は小さな衛星電波使用装置が含まれる。本発明はまた、非リソース限定型装置上でも使用することができる。
本発明を開示する目的上、「プロセッサ」という用語は、物理的なコンピュータ又は仮想計算機を意味するように用いられる場合がある。
【００１８】
ここで図４Ａを参照すると、本発明の一実施形態に従ってリソース限定型計算機上で実行するための演算式を変換する段階を説明するブロック図が示されている。コンパイラは、高級言語６２で書かれた演算式６０を取り、そのオペランドをより大きな整数タイプに拡大し、一般的なデスクトップ計算機６６上で実行するためのより大きなベースタイプの命令６４を作り出す。このより大きなベースタイプ命令６４は、リソース限定型計算機７０上で実行するための意味論的に同等なより小さなベースタイプ命令６８に最適化される。例えば、ｓｈｏｒｔタイプの加算命令は、ｓｈｏｒｔタイプのオペランドに対して演算するのに使用され、その結果は、タイプｓｈｏｒｔである。
【００１９】
本発明の別の実施形態によると、意味論的に同等なより小さなベースタイプ命令への最適化は、ジャスト・イン・タイム・コード発生装置の一部である。命令セットが初めて実行される少し前に、最適化されていない命令は、リソース限定型計算機上で実行するための意味論的に同等なより小さなベースタイプ命令に最適化される。同じ命令セットのその後の実行は、その最適化された命令セットを使用する。
本発明の別の実施形態によると、算術命令の意味を保存するためにより大きなタイプ命令６４が必要であり、かつ、より大きなタイプ命令が目標とするプロセッサによってサポートされていない場合、その演算式は、サポートされていないとして拒絶される。
【００２０】
ここで図４Ｂを参照すると、本発明の一実施形態による命令を変換する段階を説明するブロック図が示されている。３２ビットオペランドを有する命令を含むＪａｖａ（登録商標）の部類のファイル７２は、「Ｊａｖａ Ｃａｒｄ（登録商標）」の部類のファイル変換器７４によって受け取られる。この変換器７４は、リソース限定型装置上で実行するために最適化された命令７６を発生する。この最適化は、例として挙げると、より少ないスタック使用量、より小さなプログラムサイズ、及び、より高速の実行を準備する段階を含む。
【００２１】
目標とする計算機は、ｎタイプの算術演算をサポートするであろう。「Ｊａｖａ（登録商標）仮想計算機」は、タイプｉｎｔ演算子をサポートするが、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」は、タイプｓｈｏｒｔ演算子をサポートし、オプションでタイプｉｎｔ演算子をサポートする。他の装置は、ｂｙｔｅタイプの算術演算子のみ、又は、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔタイプの演算の全てをサポートしてもよい。一般的に、８ビット又は１６ビットプロセッサ上で１６ビットの算術を実行するために比較的少ない時間を要し、同じプロセッサ上で３２ビットの算術を実行するためには、比較的多くの時間が必要である。
【００２２】
算術演算に使用される実際の値は最適化時には未知であるから、最適化は、各オペランドに対して最悪の場合の値を仮定する必要がある。オペランドに対する最悪の場合の値は、入力オペランドタイプに基づいて判断される。小さいタイプの演算は、大きいタイプの表示又はより大きなタイプへの桁あふれを必要とする結果を有する可能性がある。すなわち、本発明によると、算術演算子は、桁あふれによって影響される演算子と桁あふれを引き起こす可能性を有する演算子とに分類される。本発明を開示する目的上、桁あふれは、負の値の下位桁あふれを含む。小さいタイプの演算の結果は、その結果を作り出すのに用いられた演算子が大きいタイプの表示への桁あふれを引き起こす可能性を有する演算子のグループに属する場合、潜在的桁あふれを伴うと言われる。中間的な値は、その中間的な値が桁あふれに影響される演算子のグループに属する演算子のためのオペランドとして使用されない限り、潜在的桁あふれを伴うことを許される。
【００２３】
桁あふれを引き起こす可能性を有する演算子は、加算、引き算、乗算、割り算、ネゲート、及び、左側桁送りを含む。これらの演算子に対するＪａｖａ（登録商標）バイトコードは、表１に示されている。
【００２４】
（表１）潜在的桁あふれを伴う演算
【００２５】
桁あふれに影響される演算子は、表２に示されている。桁あふれに影響される算術演算子は、割り算、剰余、ネゲート、右側桁送り、及び、符号なしの右側桁送りを含む。また、桁あふれに影響される非算術演算子は、アレー演算、スイッチ演算、及び、比較演算を含む。
【００２６】
（表２）桁あふれに影響される演算
【００２７】
表１の演算をより小さなタイプに最適化する時、結果は、より大きなタイプの中に桁あふれする場合がある。表２の演算子のうちの１つを用いる表現の結果は、表現中のオペランドのうちの１つが中間的な値であり、潜在的な桁あふれデータを含む場合、精度を失うであろう。最適化を可能にし、高級ソースコードの意味を保存するために、潜在的桁あふれは、結果が表２の演算のうちの１つに入力される場合、その結果のタイプに対する明白なソースレベルの型を用いて是正する必要がある。
【００２８】
表２の演算のいずれかに対する入力オペランドが表１の演算の結果であり、明白な高級ソースコードの型がない場合、最適化は起こることができない。そのような誤った最適化は、意味論的に同等な結果を保証しないであろう。換言すれば、リソース限定型装置上で実行するために発生された最適化コードは、結果をデスクトップコンピュータ用に発生された最適化なしのコードとは異なるようにすることができるであろう。例えば、桁あふれデータは、オペランドのＪａｖａ（登録商標）３２ビット表示で与えることができるが、「Ｊａｖａ Ｃａｒｄ（登録商標）」１６ビット表示ではできないであろう。
【００２９】
表１に列挙された演算子を用いる演算の結果は、より小さなタイプを有する演算子が適用された場合、桁あふれを生じる場合がある。デスクトップコンピュータ・プラットフォームを目標とする命令をリソース限定型コンピュータ・プラットフォームを目標とする命令に最適化する段階に付随するこれらの問題の例は、図５Ａ〜図８Ｂに与えられている。これらの例は、デスクトップコンピュータが３２ビットアーキテクチャに基づいており、比較的メモリが豊富であることを仮定している。リソース限定型コンピュータは、比較的少ないメモリを有する１６ビットアーキテクチャに基づくと仮定されている。当業者は、本発明が様々なアーキテクチャを有する演算プラットフォームに適用されることを認めるであろう。
図５Ａ〜図８Ｂはまた、符号を有する値を使用する。当業者はまた、値の符号の有無に関わらず桁あふれが起こり得ることを認めるであろう。
【００３０】
ここで図５Ａを参照すると、デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本が示されている。値「ａ」は、１６ビットの符号付きｓｈｏｒｔタイプで表すことができる最大値を含む。上記の通り、たとえ値が１６ビットｓｈｏｒｔの値であっても、ｉｎｔタイプの加算が用いられる。すなわち、１６ビット範囲から３２ビット範囲への桁あふれが結果の値の中に存在し、桁あふれの効果は、より大きな正の３２ビット数を作り出すことである。
【００３１】
ここで図５Ｂを参照すると、リソース限定型コンピュータ上で図５Ａにおけるのと同じ値を加算する段階を説明するコード見本が示されている。実行は、リソース限定型コンピュータ上で行われており、両方の値が１６ビットｓｈｏｒｔタイプであるから、命令はｓｈｏｒｔタイプの加算を用いて最適化され、従ってより少ないスタック空間を使用する。しかし、３２ビット加算の代わりに１６ビット加算が用いられるために、加算は符号ビットに桁あふれを引き起こす。デスクトップコンピュータは、３２、７６８という値を計算したのに対し、リソース限定型コンピュータの例で計算された結果は、−３２、７６８という負の数である。この結果は、それがデスクトップコンピュータの結果と異なり、多様なコンピュータ・プラットフォームに亘る相互運用性を妨げる理由から、受け入れられないものである。
【００３２】
ここで図６Ａを参照すると、２つのタイプｓｈｏｒｔの値の加算とその結果を直ちに型に入れる段階とを説明するコード見本が示されている。この例は、加算結果がタイプｓｈｏｒｔに型入れされる点を除いて、図５Ａのものと同じである。タイプをｓｈｏｒｔに型入れする段階は、最も有意な１６ビットをｓｈｏｒｔ値に切り落とし、符号が３２ビット値に広がる。潜在的に桁あふれを伴う演算（ａｄｄ演算）の結果は、タイプｓｈｏｒｔに型入れされ、それによっていかなる潜在的桁あふれの問題も排除する。図６Ｂは、リソース限定型コンピュータ上で１６ビット値として表された、図６Ａにおけるのと同じ値を加算する段階を示す。デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。
【００３３】
ここで図７Ａを参照すると、デスクトップコンピュータ上での３つのタイプｓｈｏｒｔの値の加算を説明するコード見本が示されている。この例においては、ｉｎｔタイプの加算が、１６ビットｓｈｏｒｔ値「ａ」及び「ｂ」を加え、その結果を「ｃ」に加えるために用いられている。最終結果は、ｓｈｏｒｔタイプに型入れされる。
ここで図７Ｂを参照すると、リソース限定型コンピュータ上に潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響されない演算を実行する段階を説明するコード見本が示されている。この例の全ての値は１６ビットのｓｈｏｒｔタイプであるから、全ての中間的な加算に対してｓｈｏｒｔタイプの加算が用いられる。表１に示す通り、加算演算子は、潜在的に桁あふれを引き起こすが、桁あふれに影響されない。すなわち、「ａ」と「ｂ」を加えることは、潜在的に桁あふれを伴う値を作り出す。この値が「ｃ」に加えられ、潜在的に桁あふれを伴う別の値を作り出す。第２のａｄｄ演算は、潜在的に桁あふれ（ａ＋ｂの結果）を伴う１つのオペランドを含むが、ａｄｄ演算は、桁あふれを伴うオペランドに影響されない。最終結果は、タイプｓｈｏｒｔに型入れされ、加算演算から潜在的な桁あふれを取り除く。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。
【００３４】
ここで図８Ａを参照すると、デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算とその結果をタイプｓｈｏｒｔの値で割り算する段階とを説明するコード見本が示されている。実行はデスクトップコンピュータ上で行われているので、ｉｎｔタイプの演算が用いられる。「ａ」及び「ｂ」の値がｉｎｔタイプのａｄｄを用いて互いに加えられ、この中間的な値は、「ｃ]で割り算される。
ここで図８Ｂを参照すると、リソース限定型コンピュータ上で潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響される演算を実行する段階を説明するコード見本が示されている。実行はリソース限定型コンピュータ上で行われているので、ｓｈｏｒｔタイプの演算が用いられる。「ａ」及び「ｂ」の値は、ｓｈｏｒｔタイプのａｄｄを用いて互いに加えられる。この加算は、１６ビット範囲から桁あふれする中間的な値を作り出す。この中間的な値は、「ｃ」で割り算される。図７Ｂで用いられた加算演算子と異なり、割り算演算子は、表２に示す通り桁あふれに影響される。高いビットに値が入っているので、この１６ビット値は、負であると見なされる。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの例は、図６Ａ〜図７Ｂにおけるようなプログラムで表されたタイプ変換で訂正されていない、異なる結果をもたらす。
【００３５】
本発明によると、演算式は、オペランドのタイプに応じて最適であるタイプの命令を用いて最適化される。最適化処理は、潜在的桁あふれの問題に遭遇するまで進行される。その時点で、演算式の入力オペランドに立ち戻り、それを次のより大きなタイプ命令に変換する。この処理は、演算式が最適化された命令セットを用いてデスクトップコンピュータとリソース限定型装置とで同じ結果を示すような、命令の適切なタイプが選択されるまで繰り返される。
【００３６】
変換処理の間は、いくつかの関係が維持される。これらの関係は、命令と、その命令を目標とする計算機上で実行する時に生じることになる値とに関する。関係データには、値に対する実際のタイプ及びターゲットタイプが含まれる。関係データはまた、命令が目標とする計算機上で一旦実行されると目標とする計算機上で値を生み出すことになるソース命令を含む。各命令はまた、そのオペランド関係データにリンクされる。更に、結果に関する関係データは、その結果を消費する命令にリンクされる。各関係データはまた、命令が目標とする計算機上で実行された場合に潜在的桁あふれを生じることになる命令（もしあれば）にリンクされる。この命令は、ロールバックポイントと呼ばれる。潜在的桁あふれを伴う値が桁あふれに敏感な演算子によって消費された場合、誤った最終結果が生み出されることがあるので、生み出されることになる値の各々を桁あふれを引き起こした命令とリンクさせることは、変換処理を先に進めることができない時に桁あふれ問題を引き起こした命令にロールバックする方法を与える。
【００３７】
中間的な値は、後続の命令においてオペランドとして更に消費することができる。中間的な値が潜在的に桁あふれを伴う場合、ロールバック命令もまた、結果内を伝達される。これは、表現を変換する過程で繰り返される。このロールバック作用は、常に中間的な値（又は、オペランド）に作用し、再変換が必要とされる命令までロールバックする。ロールバック命令を判断する方法及び最適化の他の詳細は、以下で検討される。
【００３８】
ここで図９を参照すると、本発明の一実施形態によるｎベースタイプの演算式最適化を説明する流れ図が示されている。参照番号８０で、変換される命令が受け取られる。参照番号８２で、入力オペランドのいずれかが潜在的桁あふれを伴うか否かに関して判断が為される。少なくとも１つのオペランドが潜在的桁あふれを伴う場合、変換される命令が桁あふれに敏感であるか否かに関する判断が参照番号８４で為される。これらに関するＪａｖａ（登録商標）バイトコードが表２に列挙されている。当業者は、桁あふれに影響される演算子のリストが異なる高級言語に関して変動し得ること、及び、本発明がこれらの他の言語にも同様に適用し得ることを認めるであろう。
【００３９】
変換される命令が桁あふれに敏感である場合、変換処理は、参照番号８６において問題の源である命令にロールバックされ、その命令は、より広いベースを有するタイプを用いて変換される。例えば、８ビットのバイトタイプは、１６ビットのワードタイプに拡大され、１６ビットのワードタイプは、３２ビットのワードタイプに拡大されるであろう。オペランドをより大きなタイプに拡大することにより、オペランドのその後の命令変換がより大きなタイプに結合された命令を使用することが必要になる。
【００４０】
変換される命令が桁あふれに敏感でない場合、又は、どの入力オペランドも潜在的桁あふれを伴わない場合、その命令は、参照番号８８で、リソース限定型装置上での実行に対して最も最適なタイプに変換される。参照番号９０で、変換される命令がまだ残っているか否かに関する判断が為される。更なる命令が残っている場合、参照番号８０で次の命令の変換が始まる。最後の命令が変換されると、参照番号９２で変換処理が終了する。
【００４１】
ここで図１０を参照すると、本発明の一実施形態によるｎベースタイプの演算式最適化を説明する詳細な流れ図が示されている。参照番号１００で、変換が完了していないという指示が作られる。参照番号１０２で、第１の命令の変換を実行すべきであるという指示が作られる。参照番号１０４で、命令変換が完了したか否かが判断される。命令変換が完了した場合、実行は参照番号１０６で終了する。変換が完了していない場合、変換が完了したという指示が参照番号１０８で作られる。参照番号１１０で、第１の命令が得られる。参照番号１１２で、その命令が変換されるべきか否かの判断が為される。
【００４２】
命令を変換する必要がある場合、変換が未完了であるという指示、及び、現在の命令を再度変換すべきではないという指示が、参照番号１１４及び１１６で各々作られる。参照番号１１８で、命令は、より小さなベースタイプを有する、目標とする計算機のために最適化された別の命令に変換される。参照番号１２０で、ロールバックが参照番号１１８における変換によってトリガされたか否かに関する判断が為される。ロールバックがトリガされていた場合、ロールバックポイントでの命令が参照番号１２２で得られ、ロールバックポイントでの命令の変換が参照番号１０４で再度開始される。ロールバックがトリガされない場合、結果のタイプ及びターゲットタイプが参照番号１２４で照合される。参照番号１２６で、変換情報は、各制御経路の後続命令に伝達される。
参照番号１２８で、更なる命令が残っているか否かに関する判断が為される。更なる命令が残っている場合、次の命令が参照番号１３０で取得され、参照番号１１２で実行が継続される。変換処理は、最後の命令が変換されると終了する。
【００４３】
ここで図１１を参照すると、本発明の一実施形態による命令を変換する段階を説明する流れ図が示されている。参照番号１４０で、現在の命令が算術命令か否かが判断される。命令が算術命令である場合、それは、参照番号１４２で変換される。同様に、スタック操作命令、ターゲット命令、タイプ変換命令、及び、初期値変換命令は、参照番号１４６、１５０、１５４、及び、１５８で各々変換される。命令が図１１の算術命令、スタック操作命令、タイプ変換命令、又は、初期値命令か否かによる命令の分類は、単に例示的な目的で示されている。当業者は、本発明が他の多くの命令の種類又は分類に対しても同様に適用し得ることを認めるであろう。
【００４４】
ここで図１２Ａを参照すると、本発明の一実施形態によるターゲット命令を変換する方法を説明する流れ図が示されている。「Ｊａｖａ（登録商標）仮想計算機」命令セットにおいては、ターゲット命令は、分岐、スイッチ、アレーアクセス、アレー作成、及び、様々な記憶／保管命令（ｓｔｏｒｅ／ｐｕｔ命令）を含むほか、スタック操作命令、タイプ変換命令、初期値命令、又は、演算式ではない、コンピュータ言語におけるタイプに敏感な他のいかなる非算術命令をも含む。
【００４５】
参照番号１６０で、命令オペランドに対するターゲットタイプが判断される。参照番号１６２で、ターゲット命令が消費するオペランドがそのターゲット命令のターゲットタイプよりも小さいタイプを有するか否かに関する判断が為される。そのオペランドが目標とするものよりも小さなタイプを有する場合、変換処理は、参照番号１６４で、その小さなタイプのオペランドを用いてロールバックされる。オペランドが目標とするものよりも小さなタイプを持たない場合、そのオペランドが潜在的桁あふれを伴うか否かに関する判断が参照番号１６６で為される。オペランドは、それが表１に記載されたオペランドのうちの１つで作り出されたか、又は、オペランド内で桁あふれを伝達する演算子によって作り出された場合、潜在的桁あふれを伴うことがある。桁あふれを伝達する演算子には、例として挙げると、「ａｎｄ」、「ｏｒ」、及び、排他的「ｏｒ」（ｘｏｒ）演算子が含まれる。どのオペランドも潜在的桁あふれを伴わない場合、命令は、参照番号１６７で最適化される。オペランドの少なくとも１つが潜在的に桁あふれを伴っている場合、変換処理は、参照番号１６４で、より小さなオペランドを用いてロールバックされる。
【００４６】
ここで図１２Ｂを参照すると、本発明の一実施形態による初期値命令を変換する方法を説明する流れ図が示されている。初期値命令の例には、獲得／ロード命令（ｇｅｔ／ｌｏａｄ命令）、及び、変数をロードする他の命令が含まれる。初期値命令はまた、方法の結果を戻す、方法呼出し命令を含む。更に、初期値命令は、ロード定数命令を含む。これらの命令は、命令が生み出す値が中間的な計算の結果ではないことから、「初期値」命令と呼ばれる。参照番号１６８で、変数、戻り値、又は、定数のタイプが受け取られる。参照番号１６９で、初期値命令は、変数又は定数のタイプに従って最適化される。例えば、ｓｈｏｒｔタイプのローカル変数をロードするために、ｉｌｏａｄ命令はｓｌｏａｄに最適化される。
【００４７】
ここで図１３を参照すると、本発明の一実施形態によるタイプ変換命令を変換する方法を説明する流れ図が示されている。タイプ変換命令は、オペランドをより大きなタイプ又はより小さなタイプに変換してもよい。例えば、３２ビットのｉｎｔタイプを１６ビットのｓｈｏｒｔタイプに型入れする段階は、オペランドをより小さなタイプに変換する。同様に、８ビットのｂｙｔｅタイプを３２ビットのｉｎｔタイプに型入れする段階は、オペランドをより大きなタイプに変換する。後者の場合、ｂｙｔｅタイプは、オペランドタイプと呼ばれ、ｉｎｔタイプは、ターゲットタイプと呼ばれる。
【００４８】
参照番号１７０で、命令が受け取られる。オペランドタイプ及びターゲットタイプは、各々、参照番号１７２及び１７４において決められる。オペランドタイプがターゲットタイプよりも大きい場合、オペランドタイプは、参照番号１７８でターゲットタイプまで狭められる。オペランドタイプがターゲットタイプよりも小さい場合、オペランドが潜在的に桁あふれを伴っているか否かに関する判断が参照番号１８０で為される。オペランドが潜在的に桁あふれを伴う場合、変換処理は、タイプを訂正するために参照番号１８２でロールバックされる。オペランドタイプが潜在的桁あふれを伴わない場合、オペランドは、参照番号１８４でターゲットタイプまで広げられる。
【００４９】
ここで図１４を参照すると、本発明の一実施形態によるスタック操作命令を変換する方法を説明する流れ図が示されている。「Ｊａｖａ（登録商標）仮想計算機」命令セットにおいては、スタック操作命令は、「ｄｕｐ（複製する）」、「ｓｗａｐ（交換する）」、及び、「ｐｏｐ（ポップする）」命令を含む。参照番号１９０で、命令が受け取られる。参照番号１９２で、その命令がｄｕｐ命令か否かに関する判断が為される。命令がｄｕｐ命令である場合、参照番号１９４で、元のスタックエントリに対するロールバックポイントが存在するか否かに関する判断が為される。元のスタックエントリがロールバックポイントを有する場合、複製されたスタックエントリのロールバックポイントは、参照番号１９６で、元のスタックエントリのロールバックポイントに設定される。元のスタックエントリがロールバックポイントを持たない場合、複製されたスタックエントリのロールバックポイントは、参照番号１９８で、元のスタックエントリのソース命令に設定される。参照番号２００で、命令が変換される。
【００５０】
ここで図１５を参照すると、本発明の一実施形態による演算式を変換する方法を説明する流れ図が示されている。参照番号２１０で、オペランドが潜在的桁あふれを伴っているか否かに関する判断が為される。オペランドが潜在的桁あふれを伴わない場合、参照番号２１２で、オペランドが潜在的桁あふれを持たないという指示が作られる。オペランドが潜在的桁あふれを伴う場合、参照番号２１４で、命令が桁あふれに影響されるか否かに関する判断が為される。命令が桁あふれに影響されない場合、参照番号２１６で、オペランドが潜在的桁あふれを有するという指示が作られる。命令が桁あふれに影響される場合、この変換は、参照番号２１８で、桁あふれを有する第１のオペランドにロールバックされる。変換がロールバックされない場合、最適化された命令タイプが参照番号２２０で決められ、命令が参照番号２２２で最適化され、結果のタイプと結果の桁あふれが参照番号２２４で判断される。
【００５１】
ここで図１６を参照すると、本発明の一実施形態による最適化された命令タイプを判断する方法を説明する流れ図が示されている。参照番号２３０で、少なくとも１つのオペランドが受け取られる。参照番号２３２で、目標とする命令タイプは、そのオペランドに付随する最も大きいタイプに設定される。参照番号２３４で、オペランドのいずれかが目標とする命令タイプよりも小さいタイプを有するか否かに関する判断が為される。少なくとも１つのオペランドが目標とするタイプよりも小さいタイプを有する場合、その小さいオペランドは、タイプを訂正するために参照番号２３６でロールバックされる。
【００５２】
ここで図１７を参照すると、本発明の一実施形態による結果のタイプ及び結果の桁あふれを判断する方法を説明する流れ図が示されている。参照番号２４０で、結果のタイプは、命令タイプに設定される。「Ｊａｖａ Ｃａｒｄ（登録商標）」の戻された結果タイプ及び桁あふれ指示は、以下の表３から表１０にまとめられている。これらの表は、命令のタイプによって構成されている。各表は、１つ又は２つのオペランドのタイプに基づいて、結果タイプと桁あふれ指示とを示している
【００５３】
（表３）加算、乗算、及び、引き算
【００５４】
（表４）割り算
【００５５】
（表５）左側桁送り
【００５６】
（表６）右側桁送り
【００５７】
（表７）ネゲート
【００５８】
（表８）符号なしの右側桁送り
【００５９】
（表９）剰余
【００６０】
（表１０）ａｎｄ、ｏｒ、及び、ｘｏｒ
【００６１】
図１７における「Ｊａｖａ Ｃａｒｄ（登録商標）」の結果タイプ及び桁あふれ指示の使用は、単に例証目的のためである。当業者は、本発明が他のタイプを有する他の高級言語に対しても適用可能であることを認めるであろう。
参照番号２４４で、結果がより最適化された命令を用いることで生じた桁あふれを潜在的に伴うか否かに関する判断が為される。結果が潜在的桁あふれを伴わない場合、参照番号２４６で、オペランドのいずれかが桁あふれを伝達するか否かに関する判断が為される。少なくとも１つのオペランドが桁あふれを伝達するか、又は、結果が潜在的に桁あふれを伴う場合、その結果のロールバックポイントが参照番号２４８で記録され、結果が潜在的桁あふれを有するという指示が参照番号２５０で作られる。
【００６２】
ここで図１８を参照すると、本発明の一実施形態によるロールバックポイントを記録する方法を説明する流れ図が示されている。参照番号２６０で、第１のオペランドがそれに付随するロールバックポイントを有するか否かに関する判断が為される。第１のオペランドがそれに付随するロールバックポイントを有する場合、現在の命令のロールバックポイントは、参照番号２６２で、第１のオペランドのロールバックポイントに設定される。第１のオペランドがそれに付随する桁あふれを持たない場合、参照番号２６４で、第２のオペランドがそれに付随する桁あふれを有するか否かに関する判断が為される。第２のオペランドがそれに付随するロールバックポイントを有する場合、命令のロールバックポイントは、参照番号２６６で、第２のオペランドのロールバックポイントに設定される。どちらのオペランドもそれに付随するロールバックポイントを持たない場合、命令のロールバックポイントは、参照番号２６８で、第１のオペランドに対するソース命令に設定される。
【００６３】
本発明の特定の実施形態によると、図１８に示す通り、「第１のオペランド」は、第１に作り出されたオペランドを意味する。ロールバックポイントをより古いオペランドに対するソース命令に設定することは、より古いオペランドに付随するタイプを訂正することによって、より新しいオペランドがその後に使用するタイプを訂正し得るので、より新しいオペランドに対する追加のロールバック演算を実行する必要性を除外するであろう。
【００６４】
ここで図１９を参照すると、本発明の一実施形態による変換処理をロールバックする方法を設定する流れ図が示されている。参照番号２７０で、現在の命令の変換が割り込まれる。参照番号２７２で、オペランドがロールバックポイントを有するか否かに関する判断が為される。オペランドがロールバックポイントを持たない場合、ロールバック命令は、参照番号２７６で、そのオペランドを作り出したソース命令に設定される。オペランドがロールバックポイントを有する場合、ロールバック命令は、参照番号２７４で、その同じロールバックポイントに設定される。参照番号２７８で、ロールバック命令の目標とするタイプが広げられる。参照番号２８０で、ロールバック命令を変換すべきであるという指示が作られる。変換処理は、参照番号２８２において、ロールバック命令で再開される。参照番号２８４で、ロールバック命令は、新しい目標とするタイプに従って変換される。
【００６５】
ここで図２０を参照すると、本発明の一実施形態による命令最適化の結果を伝達する段階を説明する流れ図が示されている。参照番号２９０で、後続命令が取得される。後続命令とは、現在の命令と同じ制御経路にあって、現在の命令の直ぐ後に発生する命令である。当業者は、１つの命令が多くの制御経路の一部であってもよいことを認めるであろう。
参照番号２９２で、後続命令が変換処理において以前に訪問されたか否かに関する判断が為される。後続命令が以前に訪問されていない場合、後続命令に関する変換情報は、参照番号２９４で現在の命令に関する変換情報と等しいように設定され、参照番号２９６で後続命令を変換すべきであるという指示が作られる。変換情報は、現在の変換点におけるランタイム状態を含んでもよい。例えば、まだ消費されていない現在又は以前の命令によって、それらの値が作り出される。これらの値は、制御経路の後続命令に対してオペランドとして使用されることになる。各値に対して、タイプ、ソース命令、及び、ロールバックポイントが記録される。後続命令が以前に訪問されていた場合、後続命令において以前に記録された変換情報は、参照番号２９８で現在の変換情報と結合される。参照番号３００で、結合された情報の中の値が変更されたか否かに関する判断が為される。値が変更されていた場合、後続命令を変換すべきであるという指示が参照番号２９６で作られる。この処理は、各後続命令に対して繰り返される。
【００６６】
ここで図２１を参照すると、本発明の一実施形態による異なる制御経路からの変換情報を結合する段階を説明する流れ図が示されている。参照番号３１０で、両方の制御経路の対応する入力が比較される。参照番号３１２で、対応する入力のタイプが異なっているか否かに関する判断が為される。タイプが異なる場合、より小さなタイプを有する入力は、参照番号３１４でロールバックされる。この処理は、各オペランドに対して繰り返される。
【００６７】
ここで図２２Ａを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化が可能な演算式への本発明の応用法を示している。図２２Ａは、値ａ、ｂ、及び、ｃをタイプｓｈｏｒｔとする時の以下のＪａｖａ（登録商標）表現に対する変換処理を説明している。
ｓｈｏｒｔ ｃ＝（ｓｈｏｒｔ）（（ｓｈｏｒｔ）（ａ＋ｂ）／ｃ）
この式のＪａｖａ（登録商標）バイトコードシーケンスは、参照番号３１６で示されている。
【００６８】
命令変換は、ｉｌｏａｄ-ａ命令で始まる。第１のより小さなタイプに付随する命令が、ｌｏａｄ及びａｄｄ命令に対して用いられる。表１に明記した通り、ａｄｄ命令は潜在的桁あふれを引き起こすが、ソースレベルにおけるタイプｓｈｏｒｔへの明確な型入れが、桁あふれの可能性を取り除く。ｄｉｖ３３０の命令は、表２に示す通り、桁あふれに影響される。しかし、明確な型入れのために、潜在的桁あふれは何も存在しない。従って、より大きなタイプを作り出すために加算演算に「ロールバック」する必要性は起こらない。
本発明の理解を更に助けるために、上記で検討した例は、図１０から図２１に関連して以下で更に詳細に説明される。
【００６９】
ｉｌｏａｄ命令は、ソース命令である。参照番号１６０において、「ａ」オペランドに対する目標とするタイプはタイプｓｈｏｒｔである。参照番号１６２において、オペランド「ａ」はタイプｓｈｏｒｔである。オペランドは、それらが直接ロードされ、従って、桁あふれを引き起こす演算によって作り出されたのではないために、参照番号１６６で潜在的桁あふれを伴わない。従って、参照番号１６７でｉｌｏａｄ命令をｓｌｏａｄ-ａ命令に変換するのに、ｓｈｏｒｔの気味のある命令が使用される。同様に、ｉｌｏａｄ-ｂ命令は、ｓｌｏａｄ-ｂ命令に変換される。
【００７０】
次に、ｉａｄｄ命令が処理される。ｉａｄｄは桁あふれを引き起こすことがある命令であるから、そのオペランドが潜在的桁あふれを伴うか否かを判断する検査が参照番号２１０で行われる。両方のオペランドは、それらが潜在的桁あふれを伴わないように、直接ロードされる。従って、最適化された結果タイプは、参照番号２２０で判断される。参照番号２３２で、命令タイプは、最大のオペランドタイプに設定される。この例では、この最大オペランドタイプは、オペランド「ａ」及びオペランド「ｂ」の両方がタイプｓｈｏｒｔであるために、タイプｓｈｏｒｔである。両方のオペランドが命令タイプと同じタイプであるから、参照番号２３８で、タイプｓｈｏｒｔが、命令タイプとして戻される。
【００７１】
次に、参照番号２２２で、命令が最適化される。命令タイプがタイプｓｈｏｒｔであるから、最適化された命令は、「ｓａｄｄ」である。次に、結果タイプ及び桁あふれ指示が、参照番号２２４で判断される。参照番号２４０で、結果タイプは、命令タイプであるタイプｓｈｏｒｔに設定される。更に、結果が潜在的桁あふれを有するという指示が表３に従って作られる。結果が潜在的桁あふれを含むので、（ａ＋ｂ）の結果に対するロールバックポイントは、参照番号２４８で記録される。いずれのオペランドもロールバックポイントを持たないので、結果に対するロールバックポイントは、参照番号２６８で、オペランド「ａ」（第１のオペランド）に対するソース命令に設定される。参照番号２５０で、結果が潜在的桁あふれを有するという指示が作られる。
【００７２】
次に、ｉ２ｓ命令が処理される。このｉ２ｓ命令は、タイプ変換命令である。参照番号１７６で、オペランドタイプ（ｓｈｏｒｔ）は、ターゲットタイプ（ｓｈｏｒｔ）と比較される。両方のタイプは同じであるから、参照番号１７８でタイプがタイプｓｈｏｒｔまで狭められ、潜在的桁あふれを取り除く。
次に、ｉｌｏａｄ-ｃ命令が処理される。値ａ及びｂのように、ｃはタイプｓｈｏｒｔであり、ｉｌｏａｄ-ｃ命令は、ｓｌｏａｄ-ｃ命令に変換される。次に、ｉｄｉｖ命令が処理される。表２に明記した通り、ｉｄｉｖは、桁あふれに影響されてもよい命令である。「ａ＋ｂ」オペランドは、ｓｈｏｒｔへの明確なソースレベルの型入れのために潜在的桁あふれを伴わず、従って、最適化された割り算命令タイプは、参照番号２３２でタイプｓｈｏｒｔであると判断され、結果タイプは、参照番号２４０でタイプｓｈｏｒｔに設定される。
【００７３】
次に、ｉ２ｓ命令が処理される。参照番号１７６で、オペランドタイプ（ｓｈｏｒｔ）は、ターゲットタイプ（ｓｈｏｒｔ）と比較される。両方のタイプは同じであるから、このタイプは、参照番号１７８でタイプｓｈｏｒｔまで狭められ、潜在的桁あふれを取り除く。
最後に、ｉｓｔｏｒｅ-ｃ命令が処理される。目標とするタイプがタイプｓｈｏｒｔであり、オペランドが桁あふれを伴わないから、ｉｓｔｏｒｅ-ｃ命令は、参照番号１６７で、ｓｓｔｏｒｅ-ｃ命令に最適化される。変換されたバイトコードは、参照番号３１８で示されている。
【００７４】
ここで図２２Ｂを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化不可能な演算式への本発明の応用法を示している。それにもかかわらず、変換されたコードは、未変換コードとの意味論的同等性を維持している。図２２Ｂは、値ａ、ｂ、及び、ｃをタイプｓｈｏｒｔとする時の以下のＪａｖａ（登録商標）表現に対する変換処理を説明している。
ｓｈｏｒｔ ｃ＝（ｓｈｏｒｔ）（（ａ＋ｂ）／ｃ）
この式に対するＪａｖａ（登録商標）バイトコードシーケンスは、参照番号３２０で示されている。
【００７５】
命令変換は、参照番号３２２で表されたｉｌｏａｄ-ａ命令で始まる。第１のより小さなタイプに付随する命令が、ｌｏａｄ３２２及び３２４とａｄｄ３２６との命令に対して使用される。表１で明記した通り、ａｄｄ命令３２６は、桁あふれの可能性を引き起こすが、第２のより大きなタイプの使用を必要としない。しかし、ｄｉｖ３３０の命令は、桁あふれに影響される。これは、表２で示されている。すなわち、桁あふれの問題を引き起こす命令は、訂正されなければならない。この問題は、参照番号３２２まで「ロールバック」して、オペランド「ａ」に対して第２の大きなタイプの命令を使用することによって訂正される。
【００７６】
命令変換がオペランド「ｂ」もまたより大きなタイプに変換されるべきであると判断され、２度目のロールバックを必要とするまで、命令変換は、参照番号３３２で２度目を続行する。命令変換は、次に、オペランド「ｃ」に対する命令がより大きなタイプの使用を必要とすると命令変換が判断されるまで、参照番号３３４で３度目を続行する。３度目のロールバックが実行され、オペランド「ｃ」のタイプが訂正されて、変換処理は、参照番号３３６で４度目の変換処理が続行された後で完了する。
本発明の理解を更に助けるために、上記で検討した図２２Ｂの例は、図１０から図２１を参照して以下で更に詳細に説明される。
【００７７】
ｉｌｏａｄ-ａ命令、ｉｌｏａｄ-ｂ命令、及び、ｉａｄｄ命令の最初の変換は、前記の例で説明したように進行する。次に、ｉｌｏａｄ-ｃ命令は、参照番号１６７で、ｓｌｏａｄ-ｃ命令に変換される。次に、ｉｄｉｖ命令が処理される。表２で明記した通り、ｉｄｉｖは、桁あふれに影響され得る命令である。「ａ＋ｂ」オペランドは、それが「＋」演算子によって作り出され、その演算子が表１で示したように桁あふれを引き起こすことがあるので、桁あふれの可能性となる。少なくとも１つのオペランドが桁あふれの可能性となっているので、桁あふれを有する第１のオペランドへのロールバックが参照番号２１８で実行される。
【００７８】
参照番号２７０で、現在の命令の変換が割り込まれる。参照番号２７４で、桁あふれがａ＋ｂオペランドと結び付けられ、そのために、ロールバックポイントは、ａ＋ｂオペランドに対するロールバックポイントに設定される。参照番号２７８で、ロールバック命令の目標とするタイプは、タイプｓｈｏｒｔからタイプｉｎｔに広げられる。参照番号２８０で、ロールバックされる行き先の命令を変換する指示が作られる。参照番号２８２で、変換処理は、以前にｓｌｏａｄ-ａ命令に変換されたｉｌｏａｄ-ａ命令において再開される。このｉｌｏａｄ-ａ命令は、参照番号２８４で変換される。
【００７９】
ロールバックの結果として、ｉｌｏａｄ-ａ命令は、参照番号３３８で処理される。参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。処理は、ｉｌｏａｄ-ｂ命令及びｉａｄｄ命令を用いて続行される。ｉａｄｄ命令に対するオペランドは、参照番号２１０において潜在的桁あふれを伴わず、従って、最適化された結果タイプが参照番号２２０で判断される。参照番号２３４で、オペランドのタイプが比較される。「ａ」オペランドが今はタイプｉｎｔであり、「ｂ」オペランドがまだタイプｓｈｏｒｔであるから、「ｂ」オペランドに対してロールバックが実行される。参照番号２７６で、ロールバック命令は、ｉｌｏａｄ-ｂ命令３４０に設定される。また、参照番号２７８で、目標とするタイプはｉｎｔに設定される。参照番号２８０で、現在の命令を変換する指示が作られる。参照番号２８２及び２８４で、変換がｉｌｏａｄ-ｂ命令において再開され、命令が変換される。
参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。
【００８０】
次に、ｉａｄｄ命令が処理される。２度ロールバックした後では、いずれのオペランドも桁あふれの可能性を持っていない。従って、参照番号２１０で、オペランドが潜在的桁あふれを伴わないという指示が作られ、最適化された命令タイプが参照番号２２０で決められる。参照番号２３２で、命令タイプは、最大のオペランドタイプに設定される。「ａ＋ｂ」オペランドがタイプｉｎｔであり、「ｃ」オペランドがタイプｓｈｏｒｔであるから、命令タイプはｉｎｔに設定される。「ｃ」オペランドのタイプが命令タイプと異なるので、参照番号２３６で、「ｃ」オペランドに対してロールバックが実行される。参照番号２７６で、ロールバック命令は、ｉｌｏａｄ-ｃ命令に設定される。参照番号２７８で、ロールバック命令の目標とするタイプは、タイプｓｈｏｒｔからタイプｉｎｔに広げられる。変換処理は、ｉｌｏａｄ-ｃ命令３４２において再開される。
【００８１】
参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。
次に、ｉｄｉｖ命令が処理される。参照番号２３８において、両方のオペランドがタイプｉｎｔであるから、最適化された命令タイプはｉｎｔに設定される。参照番号２２２で、ｉｎｔの気味のある命令（ｉｄｉｖ）が選択される。最後の命令シーケンスは、図２２の参照番号３４４で表されている。
【００８２】
本発明は、整数タイプに関して説明されたが、当業者は、本発明が浮動小数点演算式に対しても同様に適用し得ることを認めるであろう。更に、本発明は、「Ｊａｖａ Ｃａｒｄ（登録商標）」技術に関して説明されたが、当業者は、本発明が他の多くのプラットフォームに対しても同様に適用可能であることを認めるであろう。これらのプラットフォームには、例として挙げると、Ｋ仮想計算機（ＫＶＭ）技術が含まれる。ＫＶＭ技術は、１９９９年６月８日にサン・マイクロシステムズ・インコーポレーテッドから出版された「Ｋ仮想計算機（ＫＶＭ）・白書」で説明されている。
本発明は、ソフトウエア又はハードウエアにおいて実施されるであろう。本発明は、他のプロセッサにおいて実施されてもよく、同様に、プログラム可能ゲートアレー装置、「特定用途向け集積回路（ＡＳＩＣ）」、及び、他のハードウエアにおいて実施されてもよい。
【００８３】
演算式の適応最適化に関する新しい方法が以上のように説明された。同一タイプの命令は、リソース限定型計算機上で実行するために、第２のより小さな（より小さなビット数を有する）整数タイプのための意味論的同等タイプの命令に変換され、従って、比較的効率的なスタック利用と実行速度の増加とをもたらす。本発明の実施形態及び応用例が示され説明されたが、本発明の開示の恩恵を受ける当業者には、本明細書の革新的概念から逸脱することなく、上述のもの以外に更に多くの変更が可能であることが明らかであろう。従って、本発明は、特許請求の範囲の精神において限定されるが、それ以外では限定されないものとする。
【技術分野】
【０００１】
関連出願への相互参照
本出願は、以下の特許に関連する：
スッサー及びシュウェーブによる「リソース限定型装置のためのオブジェクト志向命令セット」という名称の１９９９年２月２日出願の米国特許出願、及び
レビ及びシュウェーブによる「確実に配分されたバイトコード照合を有する仮想計算機」という名称の１９９７年４月１５日出願の米国特許出願。
本発明は、コンピュータシステムに関する。より具体的には、本発明は、ｎベースタイプの演算式の最適化に関する。
【背景技術】
【０００２】
コンピュータプログラムの準備が図１に示されている。ユーザは、プログラムを高級プログラム言語１０で書く。高級プログラム言語１０で書かれたプログラムは、目標とする計算機によって実行することができる低級機械言語１２にコンパイルされる。例えば、高級Ｊａｖａ（登録商標）プログラム言語で書かれたプログラムは、低級バイトコード命令にコンパイルされる。バイトコード命令とは、「Ｊａｖａ（登録商標）仮想計算機」のための機械言語である。「Ｊａｖａ（登録商標）機械言語仕様」は、アジソン・ウェスレーから１９９９年に出版のリンドホルム他著「Ｊａｖａ（登録商標）機械言語仕様」第２版に説明されている。
【０００３】
一般的な高級プログラム言語は、演算式をサポートする。演算式は、１つ又はそれ以上のオペランドに作用する算術演算子によって形成される。一般的にサポートされる演算子は、加算、引き算、乗算、割り算、剰余、ネゲート、桁送り、ビット式論理和、ビット式論理積、及び、ビット式排他的論理和を含む。中間的な値は、１つ又はそれ以上の算術演算の結果である。高級言語はまた、一般的に多重又はｎベースの整数タイプをサポートし、算術演算がオーバ・ロードされる。オーバ・ロードは、演算子が混合タイプを有するオペランドを受け入れることを可能にする。例えば、Ｊａｖａ（登録商標）プログラム言語は、４つのベースの整数タイプ、すなわち、ｂｙｔｅ、ｓｈｏｒｔ、ｉｎｔ、及び、ｌｏｎｇをサポートする。これらのタイプは、各々、８、１６、３２、及び、６４ビット値をサポートする。「＋」演算子のような演算子は、これらの整数タイプのいずれのオペランドも受け入れるであろう。以下の３つの例は、混合ベースタイプを有するオペランドの演算のための「＋」演算子のオーバ・ロードを示している。
ｉｎｔ ａ、ｂ；
ａ＋ｂ；
ｓｈｏｒｔ ａ、ｂ；
ａ＋ｂ；
ｂｙｔｅ ａ、ｂ；
ａ＋ｂ；
【０００４】
このオーバ・ロードは、一般的に、値をより広いベースタイプに広げ、次に、算術演算を実行することによって行われる。例えば、「Ｃ」及びＪａｖａ（登録商標）コンパイラは、通常、タイプｂｙｔｅ及びｓｈｏｒｔの値をタイプｉｎｔに広げる。Ｊａｖａ（登録商標）言語において、タイプｉｎｔは、いつも３２ビットである。すなわち、タイプｓｈｏｒｔの１６ビット値とタイプｂｙｔｅの８ビット値とは、算術演算を実行する前に、３２ビットのタイプｉｎｔまで広げられる。Ｊａｖａ（登録商標）言語においては、上記で列挙した３つの例の各々に対して、以下のバイトコードが発生される。
ｉｌｏａｄ ａ
ｉｌｏａｄ ｂ
ｉａｄｄ
【０００５】
ｉｌｏａｄ命令は、８、１６、又は、３２ビット変数のいずれかをロードし、そのスタック上に３２ビットオペランドを置く。ｉａｄｄ命令は、スタックから２つの３２ビットオペランドを取り出し、それらを加え合わせ、３２ビットの結果をスタック上に戻して置く。
Ｊａｖａ（登録商標）と違って、いくつかの高級言語は、整数タイプ間の関係のみを規定し、各タイプのサイズは規定しない。例えば、「Ｃ」コンパイラの販売業者の１つは、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔのタイプのビットサイズを、各々、８、１６、及び、３２ビットであると規定してもよい。しかし、別の「Ｃ」コンパイラの販売業者は、同じタイプのサイズを、各々、１６、３２、及び、６４ビットであると規定するであろう。更に別のコンパイラは、そのビットサイズを、各々、１６、３２、及び、３２ビットであると規定してもよい。全ての場合において、各タイプのサイズ間の関係は維持されるが（タイプｂｙｔｅで表される値の数＜タイプｓｈｏｒｔで表される値の数、タイプｓｈｏｒｔで表される値の数＜タイプｉｎｔで表される値の数）、各タイプを表すのに使用される実際のビット数は異なってもよい。しかし、Ｊａｖａ（登録商標）のように、「Ｃ」は、特定の各コンパイラによって規定されるｉｎｔタイプのサイズで算術演算を実行する。これには、より小さいベースタイプを有する値をタイプｉｎｔまで広げることが必要である。
【０００６】
このタイプ拡大手法は、機械命令の数を減らし、従って、目標とする計算機の複雑さを低減する。しかし、このタイプ拡大は、一般的により大きな計算スタック空間を必要とする。例えば、タイプｓｈｏｒｔの２つの１６ビット値をそれらが３２ビットタイプに拡大された後で加え合わせることは、図２Ａ及び図２Ｂに示す通り、タイプｉｎｔの２つの３２ビット値を加え合わせるスタック空間と同じ量を使用する。
【０００７】
ここで図２Ａを参照すると、Ｊａｖａ（登録商標）言語のタイプｓｈｏｒｔの２つの１６ビット値を加え合わせる時のスタック使用法を示す流れ図が示されている。参照番号２０において、第１の１６ビットオペランドがロードされ、オペランドスタック上に押し付けられる。この時点のオペランドスタックは、参照番号３０で示されている。参照番号２２において、第１の１６ビットオペランドは、３２ビットに拡大される。参照番号２４において、第２の１６ビットオペランドがロードされ、オペランドスタック上に押し付けられる。参照番号２６において、第２の１６ビットオペランドが３２ビットに拡大される。この時点で、オペランドスタックは、４ｘ１６＝６４ビットを占有する。参照番号２８において、この２つの３２ビットオペランドは、３２ビットａｄｄ演算子を使用して加え合わされる。
【０００８】
ここで図３Ａを参照すると、タイプｉｎｔの２つの３２ビット値を加え合わせる時のスタック使用法を示す流れ図が表されている。参照番号４０において、第１の３２ビットオペランドがロードされ、オペランドスタック上に押し付けられる。このオペランドスタックは、図３Ｂで示されている。参照番号４２において、第２の３２ビットオペランドがロードされ、オペランドスタック上に押し付けられる。参照番号４４において、この２つの３２ビットオペランドは、３２ビットａｄｄ演算子を使用して加え合わされる。すなわち、上述の１６ビット加算及び３２ビット加算例の両方において、２つの３２ビットオペランドは、スタックから取り出されて３２ビットの加算演算を使用して加え合わされる前に、スタック上に押し付けられる。
【０００９】
プログラム実行が進行する間、スタックの大きさは、入れ子プロシージャの呼び出しのレベル、計算された式の複雑さ、及び、局所的に表された変数の数などの要素のためにサイズが変動する場合がある。スマートカードなどのリソース限定型装置においては、一般的に、タイプ拡大が行われるような計算を実行するのに利用できるメモリが不十分である。
リソース限定型装置は、一般的なデスクトップコンピュータなどと比べた場合、一般的に、メモリ、及び／又は、計算能力又は速度が比較的制限されているものであると考えられている。一例として、他のリソース限定型装置には、セルラー電話機、境界用走査装置、野外用プログラム可能装置、携帯情報端末（ＰＤＡ）、及び、ポケットベルや他の小型又は小さな衛星電波使用装置が含まれる。
【００１０】
賢い携帯用データ携行カードとしても知られるスマートカードは、一般的に、プラスチック又は金属から作られ、プログラムを実行するための内蔵マイクロプロセッサ又はマイクロコントローラとプログラム及びデータを記憶するメモリとを含む電子集積回路を有する。ほぼクレジットカードのサイズが可能なその様な装置は、８ビット又は１６ビットのアーキテクチャを備えたコンピュータ集積回路を有する。更に、これらの装置は、一般的に制限された記憶容量を有する。例えば、スマートカードのいくつかは、１キロバイト（１Ｋ）未満のランダムアクセスメモリ（ＲＡＭ）のほか、限られたロム（ＲＯＭ）、及び／又は、電気的消去可能ロム（ＥＥＰＲＯＭ）のような不揮発性メモリを有する。
【００１１】
更に、８ビット又は１６ビットアーキテクチャを有するスマートカードは、一般的に、内蔵８ビット又は１６ビット算術演算を各々有する。従って、スマートカードは、通常、３２ビット演算よりも効率的に８ビット又は１６ビット演算を実行することができる。３２ビットに拡大されたデータに対して３２ビット演算を実行することは、特に非効率的である。すなわち、スマートカードなどのリソース限定型装置の限られたアーキテクチャ及びメモリは、値がより大きな整数タイプに拡大されたプログラムを実行することを非実用的又は不可能にする。
【００１２】
「Ｊａｖａ（登録商標）機械言語」命令セットは、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔの整数タイプの値を処理するための算術命令セットを形成する。タイプｂｙｔｅ及びｓｈｏｒｔの変数は、編集中に整数タイプｉｎｔまで拡大される。反対に、「Ｊａｖａ Ｃａｒｄ（登録商標）（Ｊａｖａ（登録商標）プログラム言語をサポートするスマートカード）仮想計算機」は、整数タイプｉｎｔの変数を処理する命令セットに加えて、タイプｂｙｔｅ及びｓｈｏｒｔの変数を処理する別の命令セットを形成する。ほとんどの「Ｊａｖａ Ｃａｒｄ（登録商標）」アプリケーションは、タイプｓｈｏｒｔ又はｂｙｔｅのデータ値に対して演算する。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
コンピュータ産業においては、同じプログラムをリソース限定型装置で実行することができ、従って縦のプラットフォームに亘る相互運用性が達成されるように、比較的メモリが豊富なデスクトップコンピュータ上で実行するように意図された高級コンピュータ言語をサポートする傾向が増加している。この縦のプラットフォームに亘る相互運用性には、高級プログラム言語で書かれたプログラムがリソース限定型装置で実行された時、それらが仮に比較的メモリが豊富な装置で実行された場合にもたらすであろう同じ結果を示すことが必要である。例えば、Ｊａｖａ（登録商標）プログラム言語で書かれたプログラムの実行を、スマートカードプラットフォーム、手持式装置、消費者電気器具、デスクトップコンピュータ、及び、スーパーコンピュータを含む、様々なプラットフォーム上でサポートすることが必要である。
従って、意味論的に同等な数学的表現をより少ない計算スタック空間を使用して実行することができるように、プログラム表現を変える必要性が存在する。更に、実行速度が増加するようにそのような変形を行う必要性が従来技術において存在する。
【課題を解決するための手段】
【００１４】
演算式最適化の方法は、第１のベースを有する第１のプロセッサのために形成された、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階、全てのオペランドが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに対して敏感でない場合、第１のベースよりも小さい第２のベースを有する第２のプロセッサのために最適化された第２の命令に第１の命令を変換する段階、及び、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合、桁あふれの源である第３の命令をより広いベースに変換する段階を含む。演算式最適化の装置は、プログラム命令を有する少なくとも１つのメモリ、及び、第１のベースを有する第１のプロセッサに対して形成された第１の命令を受信し、少なくとも１つのオペランドのいずれもが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに敏感でない場合には、その第１の命令を第１のベースよりも小さい第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換し、少なくとも１つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合には、桁あふれの源である第３の命令をより広いベースに変換するために、プログラム命令を使用するように形成された少なくとも１つのプロセッサを含む。
【図面の簡単な説明】
【００１５】
【図１】高級言語で書かれたプログラムをコンパイルする方法を示すブロック図である。
【図２】３２ビットに拡大された２つの１６ビットオペランドを加え合わせるためのスタックの使用法を示す流れ図である。
【図３】２つの３２ビットオペランドを加え合わせるためのスタックの使用法を示す流れ図である。
【図４Ａ】本発明の一実施形態に従って、リソース限定型計算機上での実行のために演算式を変換する方法を示すブロック図である。
【図４Ｂ】本発明の一実施形態に従って、Ｊａｖａ（登録商標）の部類に属するファイルを変換する段階を示すブロック図である。
【図５Ａ】デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本を示す図である。
【図５Ｂ】リソース限定型コンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本を示す図である。
【図６Ａ】２つのタイプｓｈｏｒｔの値の加算、及び、その結果を直ちにデスクトップコンピュータ上で型に入れることを説明するコード見本を示す図である。
【図６Ｂ】リソース限定型コンピュータ上に桁あふれを持ち込む可能性のある、演算の結果の直ぐの型入れを説明するコード見本を示す図である。
【図７Ａ】３つのタイプｓｈｏｒｔの値の加算、及び、その結果を直ちにデスクトップコンピュータ上で型に入れることを説明するコード見本を示す図である。
【図７Ｂ】リソース限定型コンピュータ上に桁あふれをもたらす可能性がある演算によるオペランド上の桁あふれによって影響されない演算の実行を説明するコード見本を示す図である。
【図８Ａ】２つのタイプｓｈｏｒｔの値の加算、及び、その結果をデスクトップコンピュータ上のタイプｓｈｏｒｔの値で割り算することを説明するコード見本を示す図である。
【図８Ｂ】リソース限定型コンピュータ上に桁あふれをもたらす可能性がある演算によって作り出されたオペランド上の桁あふれによって影響された演算の実行を説明するコード見本を示す図である。
【図９】本発明の一実施形態によるｎベースタイプの演算式最適化の方法を示す流れ図である。
【図１０】本発明の一実施形態によるｎベースタイプの演算式最適化の方法を示す詳細な流れ図である。
【図１１】本発明の一実施形態による命令を変換する段階を示す流れ図である。
【図１２Ａ】本発明の一実施形態によるターゲット命令を変換する方法を示す流れ図である。
【図１２Ｂ】本発明の一実施形態による初期値命令を変換する方法を示す流れ図である。
【図１３】本発明の一実施形態によるタイプ変換命令を変換する方法を示す流れ図である。
【図１４】本発明の一実施形態によるスタック操作命令を変換する方法を示す流れ図である。
【図１５】本発明の一実施形態による演算式を変換する方法を示す流れ図である。
【図１６】本発明の一実施形態による最適化された命令のタイプを判断する方法を示す流れ図である。
【図１７】本発明の一実施形態による、結果のタイプ及び結果の桁あふれを判断する方法を示す流れ図である。
【図１８】本発明の一実施形態によるロールバックポイントを記録する方法を示す流れ図である。
【図１９】本発明の一実施形態による変換処理をロールバックする方法を示す流れ図である。
【図２０】本発明の一実施形態による命令最適化の結果を伝達する段階を示す流れ図である。
【図２１】本発明の一実施形態による異なる制御経路からの変換情報を結合する段階を示す流れ図である。
【図２２Ａ】本発明の一実施形態による命令変換を示すブロック図である。
【図２２Ｂ】本発明の一実施形態による命令変換を示すブロック図である。
【発明を実施するための形態】
【００１６】
当業者は、本発明の以下の記述が単に例示的であることを理解するであろうし、本発明の開示の恩恵を受けるような当業者に対しては、本発明の他の実施形態が容易に示唆されるであろう。
本発明は、コンピュータシステムに関する。より具体的には、本発明は、ｎベースタイプの演算式の最適化に関する。本発明は、更に、（１）本発明のレイアウトパラメータ、及び／又は、（２）コンピュータ上で演算を実行する際に本発明を使用するためのプログラム命令、を記憶した機械読取可能媒体に関する。そのような媒体には、例として挙げると、磁気テープ、磁気ディスク、ＣＤ・ＲＯＭのような光学的読取可能媒体、及び、ＰＣＭＣＩＡカードのような半導体メモリが含まれる。この媒体はまた、小さなディスク、ディスケット、又は、カセットのような携帯用品目の形態を取ってもよい。この媒体はまた、ハードディスクドライブやコンピュータＲＡＭのようなより大きな又は固定式品目の形態を取ってもよい。
【００１７】
リソース限定型装置は、通常のデスクトップコンピュータなどと比べた場合、一般的に、メモリ、及び／又は、計算能力又は速度が比較的制限されているものであると考えられている。以下で検討する特定の実施例はスマートカードに関して説明されるが、本発明は、他のリソース限定型装置と共に使用することができ、それらには、以下に限定されないが、セルラー電話機、境界用走査装置、野外用プログラム可能装置、携帯情報端末（ＰＤＡ）、及び、ポケットベルのほか、他の小型又は小さな衛星電波使用装置が含まれる。本発明はまた、非リソース限定型装置上でも使用することができる。
本発明を開示する目的上、「プロセッサ」という用語は、物理的なコンピュータ又は仮想計算機を意味するように用いられる場合がある。
【００１８】
ここで図４Ａを参照すると、本発明の一実施形態に従ってリソース限定型計算機上で実行するための演算式を変換する段階を説明するブロック図が示されている。コンパイラは、高級言語６２で書かれた演算式６０を取り、そのオペランドをより大きな整数タイプに拡大し、一般的なデスクトップ計算機６６上で実行するためのより大きなベースタイプの命令６４を作り出す。このより大きなベースタイプ命令６４は、リソース限定型計算機７０上で実行するための意味論的に同等なより小さなベースタイプ命令６８に最適化される。例えば、ｓｈｏｒｔタイプの加算命令は、ｓｈｏｒｔタイプのオペランドに対して演算するのに使用され、その結果は、タイプｓｈｏｒｔである。
【００１９】
本発明の別の実施形態によると、意味論的に同等なより小さなベースタイプ命令への最適化は、ジャスト・イン・タイム・コード発生装置の一部である。命令セットが初めて実行される少し前に、最適化されていない命令は、リソース限定型計算機上で実行するための意味論的に同等なより小さなベースタイプ命令に最適化される。同じ命令セットのその後の実行は、その最適化された命令セットを使用する。
本発明の別の実施形態によると、算術命令の意味を保存するためにより大きなタイプ命令６４が必要であり、かつ、より大きなタイプ命令が目標とするプロセッサによってサポートされていない場合、その演算式は、サポートされていないとして拒絶される。
【００２０】
ここで図４Ｂを参照すると、本発明の一実施形態による命令を変換する段階を説明するブロック図が示されている。３２ビットオペランドを有する命令を含むＪａｖａ（登録商標）の部類のファイル７２は、「Ｊａｖａ Ｃａｒｄ（登録商標）」の部類のファイル変換器７４によって受け取られる。この変換器７４は、リソース限定型装置上で実行するために最適化された命令７６を発生する。この最適化は、例として挙げると、より少ないスタック使用量、より小さなプログラムサイズ、及び、より高速の実行を準備する段階を含む。
【００２１】
目標とする計算機は、ｎタイプの算術演算をサポートするであろう。「Ｊａｖａ（登録商標）仮想計算機」は、タイプｉｎｔ演算子をサポートするが、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」は、タイプｓｈｏｒｔ演算子をサポートし、オプションでタイプｉｎｔ演算子をサポートする。他の装置は、ｂｙｔｅタイプの算術演算子のみ、又は、ｂｙｔｅ、ｓｈｏｒｔ、及び、ｉｎｔタイプの演算の全てをサポートしてもよい。一般的に、８ビット又は１６ビットプロセッサ上で１６ビットの算術を実行するために比較的少ない時間を要し、同じプロセッサ上で３２ビットの算術を実行するためには、比較的多くの時間が必要である。
【００２２】
算術演算に使用される実際の値は最適化時には未知であるから、最適化は、各オペランドに対して最悪の場合の値を仮定する必要がある。オペランドに対する最悪の場合の値は、入力オペランドタイプに基づいて判断される。小さいタイプの演算は、大きいタイプの表示又はより大きなタイプへの桁あふれを必要とする結果を有する可能性がある。すなわち、本発明によると、算術演算子は、桁あふれによって影響される演算子と桁あふれを引き起こす可能性を有する演算子とに分類される。本発明を開示する目的上、桁あふれは、負の値の下位桁あふれを含む。小さいタイプの演算の結果は、その結果を作り出すのに用いられた演算子が大きいタイプの表示への桁あふれを引き起こす可能性を有する演算子のグループに属する場合、潜在的桁あふれを伴うと言われる。中間的な値は、その中間的な値が桁あふれに影響される演算子のグループに属する演算子のためのオペランドとして使用されない限り、潜在的桁あふれを伴うことを許される。
【００２３】
桁あふれを引き起こす可能性を有する演算子は、加算、引き算、乗算、割り算、ネゲート、及び、左側桁送りを含む。これらの演算子に対するＪａｖａ（登録商標）バイトコードは、表１に示されている。
【００２４】
（表１）潜在的桁あふれを伴う演算
【００２５】
桁あふれに影響される演算子は、表２に示されている。桁あふれに影響される算術演算子は、割り算、剰余、ネゲート、右側桁送り、及び、符号なしの右側桁送りを含む。また、桁あふれに影響される非算術演算子は、アレー演算、スイッチ演算、及び、比較演算を含む。
【００２６】
（表２）桁あふれに影響される演算
【００２７】
表１の演算をより小さなタイプに最適化する時、結果は、より大きなタイプの中に桁あふれする場合がある。表２の演算子のうちの１つを用いる表現の結果は、表現中のオペランドのうちの１つが中間的な値であり、潜在的な桁あふれデータを含む場合、精度を失うであろう。最適化を可能にし、高級ソースコードの意味を保存するために、潜在的桁あふれは、結果が表２の演算のうちの１つに入力される場合、その結果のタイプに対する明白なソースレベルの型を用いて是正する必要がある。
【００２８】
表２の演算のいずれかに対する入力オペランドが表１の演算の結果であり、明白な高級ソースコードの型がない場合、最適化は起こることができない。そのような誤った最適化は、意味論的に同等な結果を保証しないであろう。換言すれば、リソース限定型装置上で実行するために発生された最適化コードは、結果をデスクトップコンピュータ用に発生された最適化なしのコードとは異なるようにすることができるであろう。例えば、桁あふれデータは、オペランドのＪａｖａ（登録商標）３２ビット表示で与えることができるが、「Ｊａｖａ Ｃａｒｄ（登録商標）」１６ビット表示ではできないであろう。
【００２９】
表１に列挙された演算子を用いる演算の結果は、より小さなタイプを有する演算子が適用された場合、桁あふれを生じる場合がある。デスクトップコンピュータ・プラットフォームを目標とする命令をリソース限定型コンピュータ・プラットフォームを目標とする命令に最適化する段階に付随するこれらの問題の例は、図５Ａ〜図８Ｂに与えられている。これらの例は、デスクトップコンピュータが３２ビットアーキテクチャに基づいており、比較的メモリが豊富であることを仮定している。リソース限定型コンピュータは、比較的少ないメモリを有する１６ビットアーキテクチャに基づくと仮定されている。当業者は、本発明が様々なアーキテクチャを有する演算プラットフォームに適用されることを認めるであろう。
図５Ａ〜図８Ｂはまた、符号を有する値を使用する。当業者はまた、値の符号の有無に関わらず桁あふれが起こり得ることを認めるであろう。
【００３０】
ここで図５Ａを参照すると、デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算を説明するコード見本が示されている。値「ａ」は、１６ビットの符号付きｓｈｏｒｔタイプで表すことができる最大値を含む。上記の通り、たとえ値が１６ビットｓｈｏｒｔの値であっても、ｉｎｔタイプの加算が用いられる。すなわち、１６ビット範囲から３２ビット範囲への桁あふれが結果の値の中に存在し、桁あふれの効果は、より大きな正の３２ビット数を作り出すことである。
【００３１】
ここで図５Ｂを参照すると、リソース限定型コンピュータ上で図５Ａにおけるのと同じ値を加算する段階を説明するコード見本が示されている。実行は、リソース限定型コンピュータ上で行われており、両方の値が１６ビットｓｈｏｒｔタイプであるから、命令はｓｈｏｒｔタイプの加算を用いて最適化され、従ってより少ないスタック空間を使用する。しかし、３２ビット加算の代わりに１６ビット加算が用いられるために、加算は符号ビットに桁あふれを引き起こす。デスクトップコンピュータは、３２、７６８という値を計算したのに対し、リソース限定型コンピュータの例で計算された結果は、−３２、７６８という負の数である。この結果は、それがデスクトップコンピュータの結果と異なり、多様なコンピュータ・プラットフォームに亘る相互運用性を妨げる理由から、受け入れられないものである。
【００３２】
ここで図６Ａを参照すると、２つのタイプｓｈｏｒｔの値の加算とその結果を直ちに型に入れる段階とを説明するコード見本が示されている。この例は、加算結果がタイプｓｈｏｒｔに型入れされる点を除いて、図５Ａのものと同じである。タイプをｓｈｏｒｔに型入れする段階は、最も有意な１６ビットをｓｈｏｒｔ値に切り落とし、符号が３２ビット値に広がる。潜在的に桁あふれを伴う演算（ａｄｄ演算）の結果は、タイプｓｈｏｒｔに型入れされ、それによっていかなる潜在的桁あふれの問題も排除する。図６Ｂは、リソース限定型コンピュータ上で１６ビット値として表された、図６Ａにおけるのと同じ値を加算する段階を示す。デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。
【００３３】
ここで図７Ａを参照すると、デスクトップコンピュータ上での３つのタイプｓｈｏｒｔの値の加算を説明するコード見本が示されている。この例においては、ｉｎｔタイプの加算が、１６ビットｓｈｏｒｔ値「ａ」及び「ｂ」を加え、その結果を「ｃ」に加えるために用いられている。最終結果は、ｓｈｏｒｔタイプに型入れされる。
ここで図７Ｂを参照すると、リソース限定型コンピュータ上に潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響されない演算を実行する段階を説明するコード見本が示されている。この例の全ての値は１６ビットのｓｈｏｒｔタイプであるから、全ての中間的な加算に対してｓｈｏｒｔタイプの加算が用いられる。表１に示す通り、加算演算子は、潜在的に桁あふれを引き起こすが、桁あふれに影響されない。すなわち、「ａ」と「ｂ」を加えることは、潜在的に桁あふれを伴う値を作り出す。この値が「ｃ」に加えられ、潜在的に桁あふれを伴う別の値を作り出す。第２のａｄｄ演算は、潜在的に桁あふれ（ａ＋ｂの結果）を伴う１つのオペランドを含むが、ａｄｄ演算は、桁あふれを伴うオペランドに影響されない。最終結果は、タイプｓｈｏｒｔに型入れされ、加算演算から潜在的な桁あふれを取り除く。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。
【００３４】
ここで図８Ａを参照すると、デスクトップコンピュータ上での２つのタイプｓｈｏｒｔの値の加算とその結果をタイプｓｈｏｒｔの値で割り算する段階とを説明するコード見本が示されている。実行はデスクトップコンピュータ上で行われているので、ｉｎｔタイプの演算が用いられる。「ａ」及び「ｂ」の値がｉｎｔタイプのａｄｄを用いて互いに加えられ、この中間的な値は、「ｃ]で割り算される。
ここで図８Ｂを参照すると、リソース限定型コンピュータ上で潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響される演算を実行する段階を説明するコード見本が示されている。実行はリソース限定型コンピュータ上で行われているので、ｓｈｏｒｔタイプの演算が用いられる。「ａ」及び「ｂ」の値は、ｓｈｏｒｔタイプのａｄｄを用いて互いに加えられる。この加算は、１６ビット範囲から桁あふれする中間的な値を作り出す。この中間的な値は、「ｃ」で割り算される。図７Ｂで用いられた加算演算子と異なり、割り算演算子は、表２に示す通り桁あふれに影響される。高いビットに値が入っているので、この１６ビット値は、負であると見なされる。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの例は、図６Ａ〜図７Ｂにおけるようなプログラムで表されたタイプ変換で訂正されていない、異なる結果をもたらす。
【００３５】
本発明によると、演算式は、オペランドのタイプに応じて最適であるタイプの命令を用いて最適化される。最適化処理は、潜在的桁あふれの問題に遭遇するまで進行される。その時点で、演算式の入力オペランドに立ち戻り、それを次のより大きなタイプ命令に変換する。この処理は、演算式が最適化された命令セットを用いてデスクトップコンピュータとリソース限定型装置とで同じ結果を示すような、命令の適切なタイプが選択されるまで繰り返される。
【００３６】
変換処理の間は、いくつかの関係が維持される。これらの関係は、命令と、その命令を目標とする計算機上で実行する時に生じることになる値とに関する。関係データには、値に対する実際のタイプ及びターゲットタイプが含まれる。関係データはまた、命令が目標とする計算機上で一旦実行されると目標とする計算機上で値を生み出すことになるソース命令を含む。各命令はまた、そのオペランド関係データにリンクされる。更に、結果に関する関係データは、その結果を消費する命令にリンクされる。各関係データはまた、命令が目標とする計算機上で実行された場合に潜在的桁あふれを生じることになる命令（もしあれば）にリンクされる。この命令は、ロールバックポイントと呼ばれる。潜在的桁あふれを伴う値が桁あふれに敏感な演算子によって消費された場合、誤った最終結果が生み出されることがあるので、生み出されることになる値の各々を桁あふれを引き起こした命令とリンクさせることは、変換処理を先に進めることができない時に桁あふれ問題を引き起こした命令にロールバックする方法を与える。
【００３７】
中間的な値は、後続の命令においてオペランドとして更に消費することができる。中間的な値が潜在的に桁あふれを伴う場合、ロールバック命令もまた、結果内を伝達される。これは、表現を変換する過程で繰り返される。このロールバック作用は、常に中間的な値（又は、オペランド）に作用し、再変換が必要とされる命令までロールバックする。ロールバック命令を判断する方法及び最適化の他の詳細は、以下で検討される。
【００３８】
ここで図９を参照すると、本発明の一実施形態によるｎベースタイプの演算式最適化を説明する流れ図が示されている。参照番号８０で、変換される命令が受け取られる。参照番号８２で、入力オペランドのいずれかが潜在的桁あふれを伴うか否かに関して判断が為される。少なくとも１つのオペランドが潜在的桁あふれを伴う場合、変換される命令が桁あふれに敏感であるか否かに関する判断が参照番号８４で為される。これらに関するＪａｖａ（登録商標）バイトコードが表２に列挙されている。当業者は、桁あふれに影響される演算子のリストが異なる高級言語に関して変動し得ること、及び、本発明がこれらの他の言語にも同様に適用し得ることを認めるであろう。
【００３９】
変換される命令が桁あふれに敏感である場合、変換処理は、参照番号８６において問題の源である命令にロールバックされ、その命令は、より広いベースを有するタイプを用いて変換される。例えば、８ビットのバイトタイプは、１６ビットのワードタイプに拡大され、１６ビットのワードタイプは、３２ビットのワードタイプに拡大されるであろう。オペランドをより大きなタイプに拡大することにより、オペランドのその後の命令変換がより大きなタイプに結合された命令を使用することが必要になる。
【００４０】
変換される命令が桁あふれに敏感でない場合、又は、どの入力オペランドも潜在的桁あふれを伴わない場合、その命令は、参照番号８８で、リソース限定型装置上での実行に対して最も最適なタイプに変換される。参照番号９０で、変換される命令がまだ残っているか否かに関する判断が為される。更なる命令が残っている場合、参照番号８０で次の命令の変換が始まる。最後の命令が変換されると、参照番号９２で変換処理が終了する。
【００４１】
ここで図１０を参照すると、本発明の一実施形態によるｎベースタイプの演算式最適化を説明する詳細な流れ図が示されている。参照番号１００で、変換が完了していないという指示が作られる。参照番号１０２で、第１の命令の変換を実行すべきであるという指示が作られる。参照番号１０４で、命令変換が完了したか否かが判断される。命令変換が完了した場合、実行は参照番号１０６で終了する。変換が完了していない場合、変換が完了したという指示が参照番号１０８で作られる。参照番号１１０で、第１の命令が得られる。参照番号１１２で、その命令が変換されるべきか否かの判断が為される。
【００４２】
命令を変換する必要がある場合、変換が未完了であるという指示、及び、現在の命令を再度変換すべきではないという指示が、参照番号１１４及び１１６で各々作られる。参照番号１１８で、命令は、より小さなベースタイプを有する、目標とする計算機のために最適化された別の命令に変換される。参照番号１２０で、ロールバックが参照番号１１８における変換によってトリガされたか否かに関する判断が為される。ロールバックがトリガされていた場合、ロールバックポイントでの命令が参照番号１２２で得られ、ロールバックポイントでの命令の変換が参照番号１０４で再度開始される。ロールバックがトリガされない場合、結果のタイプ及びターゲットタイプが参照番号１２４で照合される。参照番号１２６で、変換情報は、各制御経路の後続命令に伝達される。
参照番号１２８で、更なる命令が残っているか否かに関する判断が為される。更なる命令が残っている場合、次の命令が参照番号１３０で取得され、参照番号１１２で実行が継続される。変換処理は、最後の命令が変換されると終了する。
【００４３】
ここで図１１を参照すると、本発明の一実施形態による命令を変換する段階を説明する流れ図が示されている。参照番号１４０で、現在の命令が算術命令か否かが判断される。命令が算術命令である場合、それは、参照番号１４２で変換される。同様に、スタック操作命令、ターゲット命令、タイプ変換命令、及び、初期値変換命令は、参照番号１４６、１５０、１５４、及び、１５８で各々変換される。命令が図１１の算術命令、スタック操作命令、タイプ変換命令、又は、初期値命令か否かによる命令の分類は、単に例示的な目的で示されている。当業者は、本発明が他の多くの命令の種類又は分類に対しても同様に適用し得ることを認めるであろう。
【００４４】
ここで図１２Ａを参照すると、本発明の一実施形態によるターゲット命令を変換する方法を説明する流れ図が示されている。「Ｊａｖａ（登録商標）仮想計算機」命令セットにおいては、ターゲット命令は、分岐、スイッチ、アレーアクセス、アレー作成、及び、様々な記憶／保管命令（ｓｔｏｒｅ／ｐｕｔ命令）を含むほか、スタック操作命令、タイプ変換命令、初期値命令、又は、演算式ではない、コンピュータ言語におけるタイプに敏感な他のいかなる非算術命令をも含む。
【００４５】
参照番号１６０で、命令オペランドに対するターゲットタイプが判断される。参照番号１６２で、ターゲット命令が消費するオペランドがそのターゲット命令のターゲットタイプよりも小さいタイプを有するか否かに関する判断が為される。そのオペランドが目標とするものよりも小さなタイプを有する場合、変換処理は、参照番号１６４で、その小さなタイプのオペランドを用いてロールバックされる。オペランドが目標とするものよりも小さなタイプを持たない場合、そのオペランドが潜在的桁あふれを伴うか否かに関する判断が参照番号１６６で為される。オペランドは、それが表１に記載されたオペランドのうちの１つで作り出されたか、又は、オペランド内で桁あふれを伝達する演算子によって作り出された場合、潜在的桁あふれを伴うことがある。桁あふれを伝達する演算子には、例として挙げると、「ａｎｄ」、「ｏｒ」、及び、排他的「ｏｒ」（ｘｏｒ）演算子が含まれる。どのオペランドも潜在的桁あふれを伴わない場合、命令は、参照番号１６７で最適化される。オペランドの少なくとも１つが潜在的に桁あふれを伴っている場合、変換処理は、参照番号１６４で、より小さなオペランドを用いてロールバックされる。
【００４６】
ここで図１２Ｂを参照すると、本発明の一実施形態による初期値命令を変換する方法を説明する流れ図が示されている。初期値命令の例には、獲得／ロード命令（ｇｅｔ／ｌｏａｄ命令）、及び、変数をロードする他の命令が含まれる。初期値命令はまた、方法の結果を戻す、方法呼出し命令を含む。更に、初期値命令は、ロード定数命令を含む。これらの命令は、命令が生み出す値が中間的な計算の結果ではないことから、「初期値」命令と呼ばれる。参照番号１６８で、変数、戻り値、又は、定数のタイプが受け取られる。参照番号１６９で、初期値命令は、変数又は定数のタイプに従って最適化される。例えば、ｓｈｏｒｔタイプのローカル変数をロードするために、ｉｌｏａｄ命令はｓｌｏａｄに最適化される。
【００４７】
ここで図１３を参照すると、本発明の一実施形態によるタイプ変換命令を変換する方法を説明する流れ図が示されている。タイプ変換命令は、オペランドをより大きなタイプ又はより小さなタイプに変換してもよい。例えば、３２ビットのｉｎｔタイプを１６ビットのｓｈｏｒｔタイプに型入れする段階は、オペランドをより小さなタイプに変換する。同様に、８ビットのｂｙｔｅタイプを３２ビットのｉｎｔタイプに型入れする段階は、オペランドをより大きなタイプに変換する。後者の場合、ｂｙｔｅタイプは、オペランドタイプと呼ばれ、ｉｎｔタイプは、ターゲットタイプと呼ばれる。
【００４８】
参照番号１７０で、命令が受け取られる。オペランドタイプ及びターゲットタイプは、各々、参照番号１７２及び１７４において決められる。オペランドタイプがターゲットタイプよりも大きい場合、オペランドタイプは、参照番号１７８でターゲットタイプまで狭められる。オペランドタイプがターゲットタイプよりも小さい場合、オペランドが潜在的に桁あふれを伴っているか否かに関する判断が参照番号１８０で為される。オペランドが潜在的に桁あふれを伴う場合、変換処理は、タイプを訂正するために参照番号１８２でロールバックされる。オペランドタイプが潜在的桁あふれを伴わない場合、オペランドは、参照番号１８４でターゲットタイプまで広げられる。
【００４９】
ここで図１４を参照すると、本発明の一実施形態によるスタック操作命令を変換する方法を説明する流れ図が示されている。「Ｊａｖａ（登録商標）仮想計算機」命令セットにおいては、スタック操作命令は、「ｄｕｐ（複製する）」、「ｓｗａｐ（交換する）」、及び、「ｐｏｐ（ポップする）」命令を含む。参照番号１９０で、命令が受け取られる。参照番号１９２で、その命令がｄｕｐ命令か否かに関する判断が為される。命令がｄｕｐ命令である場合、参照番号１９４で、元のスタックエントリに対するロールバックポイントが存在するか否かに関する判断が為される。元のスタックエントリがロールバックポイントを有する場合、複製されたスタックエントリのロールバックポイントは、参照番号１９６で、元のスタックエントリのロールバックポイントに設定される。元のスタックエントリがロールバックポイントを持たない場合、複製されたスタックエントリのロールバックポイントは、参照番号１９８で、元のスタックエントリのソース命令に設定される。参照番号２００で、命令が変換される。
【００５０】
ここで図１５を参照すると、本発明の一実施形態による演算式を変換する方法を説明する流れ図が示されている。参照番号２１０で、オペランドが潜在的桁あふれを伴っているか否かに関する判断が為される。オペランドが潜在的桁あふれを伴わない場合、参照番号２１２で、オペランドが潜在的桁あふれを持たないという指示が作られる。オペランドが潜在的桁あふれを伴う場合、参照番号２１４で、命令が桁あふれに影響されるか否かに関する判断が為される。命令が桁あふれに影響されない場合、参照番号２１６で、オペランドが潜在的桁あふれを有するという指示が作られる。命令が桁あふれに影響される場合、この変換は、参照番号２１８で、桁あふれを有する第１のオペランドにロールバックされる。変換がロールバックされない場合、最適化された命令タイプが参照番号２２０で決められ、命令が参照番号２２２で最適化され、結果のタイプと結果の桁あふれが参照番号２２４で判断される。
【００５１】
ここで図１６を参照すると、本発明の一実施形態による最適化された命令タイプを判断する方法を説明する流れ図が示されている。参照番号２３０で、少なくとも１つのオペランドが受け取られる。参照番号２３２で、目標とする命令タイプは、そのオペランドに付随する最も大きいタイプに設定される。参照番号２３４で、オペランドのいずれかが目標とする命令タイプよりも小さいタイプを有するか否かに関する判断が為される。少なくとも１つのオペランドが目標とするタイプよりも小さいタイプを有する場合、その小さいオペランドは、タイプを訂正するために参照番号２３６でロールバックされる。
【００５２】
ここで図１７を参照すると、本発明の一実施形態による結果のタイプ及び結果の桁あふれを判断する方法を説明する流れ図が示されている。参照番号２４０で、結果のタイプは、命令タイプに設定される。「Ｊａｖａ Ｃａｒｄ（登録商標）」の戻された結果タイプ及び桁あふれ指示は、以下の表３から表１０にまとめられている。これらの表は、命令のタイプによって構成されている。各表は、１つ又は２つのオペランドのタイプに基づいて、結果タイプと桁あふれ指示とを示している
【００５３】
（表３）加算、乗算、及び、引き算
【００５４】
（表４）割り算
【００５５】
（表５）左側桁送り
【００５６】
（表６）右側桁送り
【００５７】
（表７）ネゲート
【００５８】
（表８）符号なしの右側桁送り
【００５９】
（表９）剰余
【００６０】
（表１０）ａｎｄ、ｏｒ、及び、ｘｏｒ
【００６１】
図１７における「Ｊａｖａ Ｃａｒｄ（登録商標）」の結果タイプ及び桁あふれ指示の使用は、単に例証目的のためである。当業者は、本発明が他のタイプを有する他の高級言語に対しても適用可能であることを認めるであろう。
参照番号２４４で、結果がより最適化された命令を用いることで生じた桁あふれを潜在的に伴うか否かに関する判断が為される。結果が潜在的桁あふれを伴わない場合、参照番号２４６で、オペランドのいずれかが桁あふれを伝達するか否かに関する判断が為される。少なくとも１つのオペランドが桁あふれを伝達するか、又は、結果が潜在的に桁あふれを伴う場合、その結果のロールバックポイントが参照番号２４８で記録され、結果が潜在的桁あふれを有するという指示が参照番号２５０で作られる。
【００６２】
ここで図１８を参照すると、本発明の一実施形態によるロールバックポイントを記録する方法を説明する流れ図が示されている。参照番号２６０で、第１のオペランドがそれに付随するロールバックポイントを有するか否かに関する判断が為される。第１のオペランドがそれに付随するロールバックポイントを有する場合、現在の命令のロールバックポイントは、参照番号２６２で、第１のオペランドのロールバックポイントに設定される。第１のオペランドがそれに付随する桁あふれを持たない場合、参照番号２６４で、第２のオペランドがそれに付随する桁あふれを有するか否かに関する判断が為される。第２のオペランドがそれに付随するロールバックポイントを有する場合、命令のロールバックポイントは、参照番号２６６で、第２のオペランドのロールバックポイントに設定される。どちらのオペランドもそれに付随するロールバックポイントを持たない場合、命令のロールバックポイントは、参照番号２６８で、第１のオペランドに対するソース命令に設定される。
【００６３】
本発明の特定の実施形態によると、図１８に示す通り、「第１のオペランド」は、第１に作り出されたオペランドを意味する。ロールバックポイントをより古いオペランドに対するソース命令に設定することは、より古いオペランドに付随するタイプを訂正することによって、より新しいオペランドがその後に使用するタイプを訂正し得るので、より新しいオペランドに対する追加のロールバック演算を実行する必要性を除外するであろう。
【００６４】
ここで図１９を参照すると、本発明の一実施形態による変換処理をロールバックする方法を設定する流れ図が示されている。参照番号２７０で、現在の命令の変換が割り込まれる。参照番号２７２で、オペランドがロールバックポイントを有するか否かに関する判断が為される。オペランドがロールバックポイントを持たない場合、ロールバック命令は、参照番号２７６で、そのオペランドを作り出したソース命令に設定される。オペランドがロールバックポイントを有する場合、ロールバック命令は、参照番号２７４で、その同じロールバックポイントに設定される。参照番号２７８で、ロールバック命令の目標とするタイプが広げられる。参照番号２８０で、ロールバック命令を変換すべきであるという指示が作られる。変換処理は、参照番号２８２において、ロールバック命令で再開される。参照番号２８４で、ロールバック命令は、新しい目標とするタイプに従って変換される。
【００６５】
ここで図２０を参照すると、本発明の一実施形態による命令最適化の結果を伝達する段階を説明する流れ図が示されている。参照番号２９０で、後続命令が取得される。後続命令とは、現在の命令と同じ制御経路にあって、現在の命令の直ぐ後に発生する命令である。当業者は、１つの命令が多くの制御経路の一部であってもよいことを認めるであろう。
参照番号２９２で、後続命令が変換処理において以前に訪問されたか否かに関する判断が為される。後続命令が以前に訪問されていない場合、後続命令に関する変換情報は、参照番号２９４で現在の命令に関する変換情報と等しいように設定され、参照番号２９６で後続命令を変換すべきであるという指示が作られる。変換情報は、現在の変換点におけるランタイム状態を含んでもよい。例えば、まだ消費されていない現在又は以前の命令によって、それらの値が作り出される。これらの値は、制御経路の後続命令に対してオペランドとして使用されることになる。各値に対して、タイプ、ソース命令、及び、ロールバックポイントが記録される。後続命令が以前に訪問されていた場合、後続命令において以前に記録された変換情報は、参照番号２９８で現在の変換情報と結合される。参照番号３００で、結合された情報の中の値が変更されたか否かに関する判断が為される。値が変更されていた場合、後続命令を変換すべきであるという指示が参照番号２９６で作られる。この処理は、各後続命令に対して繰り返される。
【００６６】
ここで図２１を参照すると、本発明の一実施形態による異なる制御経路からの変換情報を結合する段階を説明する流れ図が示されている。参照番号３１０で、両方の制御経路の対応する入力が比較される。参照番号３１２で、対応する入力のタイプが異なっているか否かに関する判断が為される。タイプが異なる場合、より小さなタイプを有する入力は、参照番号３１４でロールバックされる。この処理は、各オペランドに対して繰り返される。
【００６７】
ここで図２２Ａを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化が可能な演算式への本発明の応用法を示している。図２２Ａは、値ａ、ｂ、及び、ｃをタイプｓｈｏｒｔとする時の以下のＪａｖａ（登録商標）表現に対する変換処理を説明している。
ｓｈｏｒｔ ｃ＝（ｓｈｏｒｔ）（（ｓｈｏｒｔ）（ａ＋ｂ）／ｃ）
この式のＪａｖａ（登録商標）バイトコードシーケンスは、参照番号３１６で示されている。
【００６８】
命令変換は、ｉｌｏａｄ-ａ命令で始まる。第１のより小さなタイプに付随する命令が、ｌｏａｄ及びａｄｄ命令に対して用いられる。表１に明記した通り、ａｄｄ命令は潜在的桁あふれを引き起こすが、ソースレベルにおけるタイプｓｈｏｒｔへの明確な型入れが、桁あふれの可能性を取り除く。ｄｉｖ３３０の命令は、表２に示す通り、桁あふれに影響される。しかし、明確な型入れのために、潜在的桁あふれは何も存在しない。従って、より大きなタイプを作り出すために加算演算に「ロールバック」する必要性は起こらない。
本発明の理解を更に助けるために、上記で検討した例は、図１０から図２１に関連して以下で更に詳細に説明される。
【００６９】
ｉｌｏａｄ命令は、ソース命令である。参照番号１６０において、「ａ」オペランドに対する目標とするタイプはタイプｓｈｏｒｔである。参照番号１６２において、オペランド「ａ」はタイプｓｈｏｒｔである。オペランドは、それらが直接ロードされ、従って、桁あふれを引き起こす演算によって作り出されたのではないために、参照番号１６６で潜在的桁あふれを伴わない。従って、参照番号１６７でｉｌｏａｄ命令をｓｌｏａｄ-ａ命令に変換するのに、ｓｈｏｒｔの気味のある命令が使用される。同様に、ｉｌｏａｄ-ｂ命令は、ｓｌｏａｄ-ｂ命令に変換される。
【００７０】
次に、ｉａｄｄ命令が処理される。ｉａｄｄは桁あふれを引き起こすことがある命令であるから、そのオペランドが潜在的桁あふれを伴うか否かを判断する検査が参照番号２１０で行われる。両方のオペランドは、それらが潜在的桁あふれを伴わないように、直接ロードされる。従って、最適化された結果タイプは、参照番号２２０で判断される。参照番号２３２で、命令タイプは、最大のオペランドタイプに設定される。この例では、この最大オペランドタイプは、オペランド「ａ」及びオペランド「ｂ」の両方がタイプｓｈｏｒｔであるために、タイプｓｈｏｒｔである。両方のオペランドが命令タイプと同じタイプであるから、参照番号２３８で、タイプｓｈｏｒｔが、命令タイプとして戻される。
【００７１】
次に、参照番号２２２で、命令が最適化される。命令タイプがタイプｓｈｏｒｔであるから、最適化された命令は、「ｓａｄｄ」である。次に、結果タイプ及び桁あふれ指示が、参照番号２２４で判断される。参照番号２４０で、結果タイプは、命令タイプであるタイプｓｈｏｒｔに設定される。更に、結果が潜在的桁あふれを有するという指示が表３に従って作られる。結果が潜在的桁あふれを含むので、（ａ＋ｂ）の結果に対するロールバックポイントは、参照番号２４８で記録される。いずれのオペランドもロールバックポイントを持たないので、結果に対するロールバックポイントは、参照番号２６８で、オペランド「ａ」（第１のオペランド）に対するソース命令に設定される。参照番号２５０で、結果が潜在的桁あふれを有するという指示が作られる。
【００７２】
次に、ｉ２ｓ命令が処理される。このｉ２ｓ命令は、タイプ変換命令である。参照番号１７６で、オペランドタイプ（ｓｈｏｒｔ）は、ターゲットタイプ（ｓｈｏｒｔ）と比較される。両方のタイプは同じであるから、参照番号１７８でタイプがタイプｓｈｏｒｔまで狭められ、潜在的桁あふれを取り除く。
次に、ｉｌｏａｄ-ｃ命令が処理される。値ａ及びｂのように、ｃはタイプｓｈｏｒｔであり、ｉｌｏａｄ-ｃ命令は、ｓｌｏａｄ-ｃ命令に変換される。次に、ｉｄｉｖ命令が処理される。表２に明記した通り、ｉｄｉｖは、桁あふれに影響されてもよい命令である。「ａ＋ｂ」オペランドは、ｓｈｏｒｔへの明確なソースレベルの型入れのために潜在的桁あふれを伴わず、従って、最適化された割り算命令タイプは、参照番号２３２でタイプｓｈｏｒｔであると判断され、結果タイプは、参照番号２４０でタイプｓｈｏｒｔに設定される。
【００７３】
次に、ｉ２ｓ命令が処理される。参照番号１７６で、オペランドタイプ（ｓｈｏｒｔ）は、ターゲットタイプ（ｓｈｏｒｔ）と比較される。両方のタイプは同じであるから、このタイプは、参照番号１７８でタイプｓｈｏｒｔまで狭められ、潜在的桁あふれを取り除く。
最後に、ｉｓｔｏｒｅ-ｃ命令が処理される。目標とするタイプがタイプｓｈｏｒｔであり、オペランドが桁あふれを伴わないから、ｉｓｔｏｒｅ-ｃ命令は、参照番号１６７で、ｓｓｔｏｒｅ-ｃ命令に最適化される。変換されたバイトコードは、参照番号３１８で示されている。
【００７４】
ここで図２２Ｂを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化不可能な演算式への本発明の応用法を示している。それにもかかわらず、変換されたコードは、未変換コードとの意味論的同等性を維持している。図２２Ｂは、値ａ、ｂ、及び、ｃをタイプｓｈｏｒｔとする時の以下のＪａｖａ（登録商標）表現に対する変換処理を説明している。
ｓｈｏｒｔ ｃ＝（ｓｈｏｒｔ）（（ａ＋ｂ）／ｃ）
この式に対するＪａｖａ（登録商標）バイトコードシーケンスは、参照番号３２０で示されている。
【００７５】
命令変換は、参照番号３２２で表されたｉｌｏａｄ-ａ命令で始まる。第１のより小さなタイプに付随する命令が、ｌｏａｄ３２２及び３２４とａｄｄ３２６との命令に対して使用される。表１で明記した通り、ａｄｄ命令３２６は、桁あふれの可能性を引き起こすが、第２のより大きなタイプの使用を必要としない。しかし、ｄｉｖ３３０の命令は、桁あふれに影響される。これは、表２で示されている。すなわち、桁あふれの問題を引き起こす命令は、訂正されなければならない。この問題は、参照番号３２２まで「ロールバック」して、オペランド「ａ」に対して第２の大きなタイプの命令を使用することによって訂正される。
【００７６】
命令変換がオペランド「ｂ」もまたより大きなタイプに変換されるべきであると判断され、２度目のロールバックを必要とするまで、命令変換は、参照番号３３２で２度目を続行する。命令変換は、次に、オペランド「ｃ」に対する命令がより大きなタイプの使用を必要とすると命令変換が判断されるまで、参照番号３３４で３度目を続行する。３度目のロールバックが実行され、オペランド「ｃ」のタイプが訂正されて、変換処理は、参照番号３３６で４度目の変換処理が続行された後で完了する。
本発明の理解を更に助けるために、上記で検討した図２２Ｂの例は、図１０から図２１を参照して以下で更に詳細に説明される。
【００７７】
ｉｌｏａｄ-ａ命令、ｉｌｏａｄ-ｂ命令、及び、ｉａｄｄ命令の最初の変換は、前記の例で説明したように進行する。次に、ｉｌｏａｄ-ｃ命令は、参照番号１６７で、ｓｌｏａｄ-ｃ命令に変換される。次に、ｉｄｉｖ命令が処理される。表２で明記した通り、ｉｄｉｖは、桁あふれに影響され得る命令である。「ａ＋ｂ」オペランドは、それが「＋」演算子によって作り出され、その演算子が表１で示したように桁あふれを引き起こすことがあるので、桁あふれの可能性となる。少なくとも１つのオペランドが桁あふれの可能性となっているので、桁あふれを有する第１のオペランドへのロールバックが参照番号２１８で実行される。
【００７８】
参照番号２７０で、現在の命令の変換が割り込まれる。参照番号２７４で、桁あふれがａ＋ｂオペランドと結び付けられ、そのために、ロールバックポイントは、ａ＋ｂオペランドに対するロールバックポイントに設定される。参照番号２７８で、ロールバック命令の目標とするタイプは、タイプｓｈｏｒｔからタイプｉｎｔに広げられる。参照番号２８０で、ロールバックされる行き先の命令を変換する指示が作られる。参照番号２８２で、変換処理は、以前にｓｌｏａｄ-ａ命令に変換されたｉｌｏａｄ-ａ命令において再開される。このｉｌｏａｄ-ａ命令は、参照番号２８４で変換される。
【００７９】
ロールバックの結果として、ｉｌｏａｄ-ａ命令は、参照番号３３８で処理される。参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。処理は、ｉｌｏａｄ-ｂ命令及びｉａｄｄ命令を用いて続行される。ｉａｄｄ命令に対するオペランドは、参照番号２１０において潜在的桁あふれを伴わず、従って、最適化された結果タイプが参照番号２２０で判断される。参照番号２３４で、オペランドのタイプが比較される。「ａ」オペランドが今はタイプｉｎｔであり、「ｂ」オペランドがまだタイプｓｈｏｒｔであるから、「ｂ」オペランドに対してロールバックが実行される。参照番号２７６で、ロールバック命令は、ｉｌｏａｄ-ｂ命令３４０に設定される。また、参照番号２７８で、目標とするタイプはｉｎｔに設定される。参照番号２８０で、現在の命令を変換する指示が作られる。参照番号２８２及び２８４で、変換がｉｌｏａｄ-ｂ命令において再開され、命令が変換される。
参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。
【００８０】
次に、ｉａｄｄ命令が処理される。２度ロールバックした後では、いずれのオペランドも桁あふれの可能性を持っていない。従って、参照番号２１０で、オペランドが潜在的桁あふれを伴わないという指示が作られ、最適化された命令タイプが参照番号２２０で決められる。参照番号２３２で、命令タイプは、最大のオペランドタイプに設定される。「ａ＋ｂ」オペランドがタイプｉｎｔであり、「ｃ」オペランドがタイプｓｈｏｒｔであるから、命令タイプはｉｎｔに設定される。「ｃ」オペランドのタイプが命令タイプと異なるので、参照番号２３６で、「ｃ」オペランドに対してロールバックが実行される。参照番号２７６で、ロールバック命令は、ｉｌｏａｄ-ｃ命令に設定される。参照番号２７８で、ロールバック命令の目標とするタイプは、タイプｓｈｏｒｔからタイプｉｎｔに広げられる。変換処理は、ｉｌｏａｄ-ｃ命令３４２において再開される。
【００８１】
参照番号１２４で、結果のタイプと目標とするタイプとが照合される。結果のタイプがｓｈｏｒｔで、目標とするタイプがｉｎｔであるから、そのタイプは一致しない。すなわち、ｓｈｏｒｔをｉｎｔに上げるために、Ｓ２Ｉ命令が作り出される。
次に、ｉｄｉｖ命令が処理される。参照番号２３８において、両方のオペランドがタイプｉｎｔであるから、最適化された命令タイプはｉｎｔに設定される。参照番号２２２で、ｉｎｔの気味のある命令（ｉｄｉｖ）が選択される。最後の命令シーケンスは、図２２の参照番号３４４で表されている。
【００８２】
本発明は、整数タイプに関して説明されたが、当業者は、本発明が浮動小数点演算式に対しても同様に適用し得ることを認めるであろう。更に、本発明は、「Ｊａｖａ Ｃａｒｄ（登録商標）」技術に関して説明されたが、当業者は、本発明が他の多くのプラットフォームに対しても同様に適用可能であることを認めるであろう。これらのプラットフォームには、例として挙げると、Ｋ仮想計算機（ＫＶＭ）技術が含まれる。ＫＶＭ技術は、１９９９年６月８日にサン・マイクロシステムズ・インコーポレーテッドから出版された「Ｋ仮想計算機（ＫＶＭ）・白書」で説明されている。
本発明は、ソフトウエア又はハードウエアにおいて実施されるであろう。本発明は、他のプロセッサにおいて実施されてもよく、同様に、プログラム可能ゲートアレー装置、「特定用途向け集積回路（ＡＳＩＣ）」、及び、他のハードウエアにおいて実施されてもよい。
【００８３】
演算式の適応最適化に関する新しい方法が以上のように説明された。同一タイプの命令は、リソース限定型計算機上で実行するために、第２のより小さな（より小さなビット数を有する）整数タイプのための意味論的同等タイプの命令に変換され、従って、比較的効率的なスタック利用と実行速度の増加とをもたらす。本発明の実施形態及び応用例が示され説明されたが、本発明の開示の恩恵を受ける当業者には、本明細書の革新的概念から逸脱することなく、上述のもの以外に更に多くの変更が可能であることが明らかであろう。従って、本発明は、特許請求の範囲の精神において限定されるが、それ以外では限定されないものとする。
【特許請求の範囲】
【請求項１】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階と、
前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する段階と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する段階と、
を含むことを特徴とする、演算式最適化の方法。
【請求項２】
より広いベースへの前記変換段階は、前記第３の命令の以前の変換結果を、より広いベースへの前記変換段階の前に廃棄する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項４】
より広いベースへの前記変換段階は、より広い前記ベースが前記第２のプロセッサによってサポートされない時は前記第１の命令を拒否する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の命令は、算術であることを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記第１の命令の前記変換段階の後で、前記第１のプロセッサのために形成された全ての命令が変換されるまで、前記第１の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項５に記載の方法。
【請求項８】
全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記第１の命令の前記変換段階は、
命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、
前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、
前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、
を更に含む、ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１のプロセッサは、「Ｊａｖａ（登録商標）仮想計算機」を含み、
前記第２のプロセッサは、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」を含む、
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズに等しいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズよりも大きいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項９に記載の方法。
【請求項１４】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階と、 前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する段階と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する段階と、
を含む演算式最適化を実行する、計算機が実行可能な命令プログラムを包含することを特徴とする、計算機が読取可能なプログラム記憶装置。
【請求項１６】
より広いベースへの前記変換段階は、前記第３の命令の以前の変換結果を、より広いベースへの前記変換段階の前に破棄する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１７】
前記第２のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１８】
より広いベースへの前記変換段階は、より広い前記ベースが前記第２のプロセッサによってサポートされない時は前記第１の命令を拒否する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１９】
前記第１の命令は、算術であることを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２０】
前記第１の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２１】
前記第１の命令の前記変換段階の後で、前記第１のプロセッサのために形成された全ての命令が変換されるまで、前記第１の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項１９に記載のプログラム記憶装置。
【請求項２２】
全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項２１に記載のプログラム記憶装置。
【請求項２３】
前記第１の命令の前記変換段階は、
命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、
前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、
前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、
を更に含む、ことを特徴とする請求項２２に記載のプログラム記憶装置。
【請求項２４】
前記第１のプロセッサは、「Ｊａｖａ（登録商標）仮想計算機」を含み、
前記第２のプロセッサは、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」を含む、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２５】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズに等しいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２６】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２７】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズよりも大きいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項２３に記載のプログラム記憶装置。
【請求項２８】
プログラム命令を有する少なくとも１つのメモリと、
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取り、
前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換し、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する、
ために前記プログラム命令を使用するように形成された少なくとも１つのプロセッサと、
を含むことを特徴とする、演算式最適化のための装置。
【請求項２９】
前記少なくとも１つのプロセッサは、より広いベースに変換する段階の前に、前記プログラム命令を使用して前記第３の命令の以前の変換結果を破棄するように更に形成されることを特徴とする請求項２８に記載の装置。
【請求項３０】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る手段と、 前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する手段と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する手段と、
を含むことを特徴とする、演算式最適化のための装置。
【請求項３１】
より広いベースに変換する前記手段は、より広いベースに変換する前記段階の前に、前記第３の命令の以前の変換結果を破棄する手段を更に含むことを特徴とする請求項３０に記載の装置。
【請求項３２】
全ての制御経路において、各命令を後続命令にリンクする手段を更に含むことを特徴とする請求項３０に記載の装置。
【請求項３３】
第１のベースを有するプロセッサを目標とする少なくとも１つの命令の演算式最適化を含むアプリケーションソフトウエアプログラムを使用する方法であって、
ソフトウエアプログラムをプロセッサ上に受け取る段階と、
命令のシーケンスを前記プロセッサ上で実行する段階と、
を含むことを特徴とする方法。
【請求項３４】
前記少なくとも１つの命令をリソース限定型装置上に記憶する段階を更に含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
マイクロ制御装置によって実行される仮想計算機、
を含み、
前記仮想計算機は、複数の予め最適化された命令から成るソフトウエアアプリケーションを実行し、
前記仮想計算機は、リソース限定型装置上で実行するために予め最適化されている最適化された命令を受け取る手段と前記命令を実行する手段とを含む、
ことを特徴とする、マイクロ制御装置が組み込まれたスマートカード。
【請求項１】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階と、
前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する段階と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する段階と、
を含むことを特徴とする、演算式最適化の方法。
【請求項２】
より広いベースへの前記変換段階は、前記第３の命令の以前の変換結果を、より広いベースへの前記変換段階の前に廃棄する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項４】
より広いベースへの前記変換段階は、より広い前記ベースが前記第２のプロセッサによってサポートされない時は前記第１の命令を拒否する段階を更に含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の命令は、算術であることを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記第１の命令の前記変換段階の後で、前記第１のプロセッサのために形成された全ての命令が変換されるまで、前記第１の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項５に記載の方法。
【請求項８】
全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記第１の命令の前記変換段階は、
命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、
前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、
前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、
を更に含む、ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１のプロセッサは、「Ｊａｖａ（登録商標）仮想計算機」を含み、
前記第２のプロセッサは、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」を含む、
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズに等しいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズよりも大きいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項９に記載の方法。
【請求項１４】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る段階と、 前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する段階と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する段階と、
を含む演算式最適化を実行する、計算機が実行可能な命令プログラムを包含することを特徴とする、計算機が読取可能なプログラム記憶装置。
【請求項１６】
より広いベースへの前記変換段階は、前記第３の命令の以前の変換結果を、より広いベースへの前記変換段階の前に破棄する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１７】
前記第２のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１８】
より広いベースへの前記変換段階は、より広い前記ベースが前記第２のプロセッサによってサポートされない時は前記第１の命令を拒否する段階を更に含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項１９】
前記第１の命令は、算術であることを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２０】
前記第１の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２１】
前記第１の命令の前記変換段階の後で、前記第１のプロセッサのために形成された全ての命令が変換されるまで、前記第１の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項１９に記載のプログラム記憶装置。
【請求項２２】
全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項２１に記載のプログラム記憶装置。
【請求項２３】
前記第１の命令の前記変換段階は、
命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、
前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、
前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、
を更に含む、ことを特徴とする請求項２２に記載のプログラム記憶装置。
【請求項２４】
前記第１のプロセッサは、「Ｊａｖａ（登録商標）仮想計算機」を含み、
前記第２のプロセッサは、「Ｊａｖａ Ｃａｒｄ（登録商標）仮想計算機」を含む、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２５】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズに等しいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２６】
前記第１のプロセッサは、３２ビットのプロセッサを含み、
前記第２のプロセッサは、リソース限定型１６ビットのプロセッサを含む、
ことを特徴とする請求項１５に記載のプログラム記憶装置。
【請求項２７】
前記第１のベースは、前記第１のベースのサイズよりも小さいサイズを有する少なくとも１つのデータタイプ上で算術演算を実行するために、前記第１のプロセッサによって使用され、
前記少なくとも１つのデータタイプのサイズよりも大きいサイズを有する前記第２のベースは、前記少なくとも１つのデータタイプ上で算術演算を実行するために、前記第２のプロセッサによって使用される、
ことを特徴とする請求項２３に記載のプログラム記憶装置。
【請求項２８】
プログラム命令を有する少なくとも１つのメモリと、
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取り、
前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換し、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する、
ために前記プログラム命令を使用するように形成された少なくとも１つのプロセッサと、
を含むことを特徴とする、演算式最適化のための装置。
【請求項２９】
前記少なくとも１つのプロセッサは、より広いベースに変換する段階の前に、前記プログラム命令を使用して前記第３の命令の以前の変換結果を破棄するように更に形成されることを特徴とする請求項２８に記載の装置。
【請求項３０】
第１のベースを有する第１のプロセッサのために形成され、演算子と少なくとも１つのオペランドとを含む第１の命令を受け取る手段と、 前記少なくとも１つのオペランドが前記第１のベースよりも小さい第２のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第１の命令を、前記第２のベースを有する第２のプロセッサに対して最適化された第２の命令に変換する手段と、
前記少なくとも１つのオペランドが前記第２のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも１つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第３の命令を、前記第２のベースよりも大きく前記第１のベースよりも小さいか又は等しいより広いベースに変換する手段と、
を含むことを特徴とする、演算式最適化のための装置。
【請求項３１】
より広いベースに変換する前記手段は、より広いベースに変換する前記段階の前に、前記第３の命令の以前の変換結果を破棄する手段を更に含むことを特徴とする請求項３０に記載の装置。
【請求項３２】
全ての制御経路において、各命令を後続命令にリンクする手段を更に含むことを特徴とする請求項３０に記載の装置。
【請求項３３】
第１のベースを有するプロセッサを目標とする少なくとも１つの命令の演算式最適化を含むアプリケーションソフトウエアプログラムを使用する方法であって、
ソフトウエアプログラムをプロセッサ上に受け取る段階と、
命令のシーケンスを前記プロセッサ上で実行する段階と、
を含むことを特徴とする方法。
【請求項３４】
前記少なくとも１つの命令をリソース限定型装置上に記憶する段階を更に含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
マイクロ制御装置によって実行される仮想計算機、
を含み、
前記仮想計算機は、複数の予め最適化された命令から成るソフトウエアアプリケーションを実行し、
前記仮想計算機は、リソース限定型装置上で実行するために予め最適化されている最適化された命令を受け取る手段と前記命令を実行する手段とを含む、
ことを特徴とする、マイクロ制御装置が組み込まれたスマートカード。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２Ａ】
【図２２Ｂ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２Ａ】
【図２２Ｂ】
【公開番号】特開２０１１−１５０７２７（Ｐ２０１１−１５０７２７Ａ）
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願番号】特願２０１１−９２２５９（Ｐ２０１１−９２２５９）
【出願日】平成２３年４月１８日（２０１１．４．１８）
【分割の表示】特願２００１−５３６６６９（Ｐ２００１−５３６６６９）の分割
【原出願日】平成１２年１１月１０日（２０００．１１．１０）
【出願人】（５９７００４７２０）オラクル・アメリカ・インコーポレイテッド (23)
【Ｆターム（参考）】
【公開日】平成２３年８月４日（２０１１．８．４）
【国際特許分類】
【出願日】平成２３年４月１８日（２０１１．４．１８）
【分割の表示】特願２００１−５３６６６９（Ｐ２００１−５３６６６９）の分割
【原出願日】平成１２年１１月１０日（２０００．１１．１０）
【出願人】（５９７００４７２０）オラクル・アメリカ・インコーポレイテッド (23)
【Ｆターム（参考）】
[ Back to top ]