第1のベースを有する第1のプロセッサのために形成され、演算子と少なくとも1つのオペランドとを含む第1の命令を受け取る段階と、前記少なくとも1つのオペランドが前記第1のベースよりも小さい第2のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第1の命令を、前記第2のベースを有する第2のプロセッサに対して最適化された第2の命令に変換する段階と、前記少なくとも1つのオペランドが前記第2のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも1つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第3の命令を、前記第2のベースよりも大きく前記第1のベースよりも小さいか又は等しいより広いベースに変換する段階と、を含むことを特徴とする、演算式最適化の方法。より広いベースへの前記変換段階は、前記第3の命令の以前の変換結果を、より広いベースへの前記変換段階の前に廃棄する段階を更に含むことを特徴とする請求項1に記載の方法。前記第2のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項1に記載の方法。より広いベースへの前記変換段階は、より広い前記ベースが前記第2のプロセッサによってサポートされない時は前記第1の命令を拒否する段階を更に含むことを特徴とする請求項1に記載の方法。前記第1の命令は、算術であることを特徴とする請求項1に記載の方法。前記第1の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項1に記載の方法。前記第1の命令の前記変換段階の後で、前記第1のプロセッサのために形成された全ての命令が変換されるまで、前記第1の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項5に記載の方法。全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項7に記載の方法。前記第1の命令の前記変換段階は、命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、を更に含む、ことを特徴とする請求項8に記載の方法。前記第1のプロセッサは、Java登録商標仮想計算機を含み、前記第2のプロセッサは、JavaCard登録商標仮想計算機を含む、ことを特徴とする請求項1に記載の方法。前記第1のベースは、前記第1のベースのサイズよりも小さいサイズを有する少なくとも1つのデータタイプ上で算術演算を実行するために、前記第1のプロセッサによって使用され、前記少なくとも1つのデータタイプのサイズに等しいサイズを有する前記第2のベースは、前記少なくとも1つのデータタイプ上で算術演算を実行するために、前記第2のプロセッサによって使用される、ことを特徴とする請求項1に記載の方法。前記第1のプロセッサは、32ビットのプロセッサを含み、前記第2のプロセッサは、リソース限定型16ビットのプロセッサを含む、ことを特徴とする請求項1に記載の方法。前記第1のベースは、前記第1のベースのサイズよりも小さいサイズを有する少なくとも1つのデータタイプ上で算術演算を実行するために、前記第1のプロセッサによって使用され、前記少なくとも1つのデータタイプのサイズよりも大きいサイズを有する前記第2のベースは、前記少なくとも1つのデータタイプ上で算術演算を実行するために、前記第2のプロセッサによって使用される、ことを特徴とする請求項9に記載の方法。前記第1のプロセッサは、32ビットのプロセッサを含み、前記第2のプロセッサは、リソース限定型16ビットのプロセッサを含む、ことを特徴とする請求項13に記載の方法。第1のベースを有する第1のプロセッサのために形成され、演算子と少なくとも1つのオペランドとを含む第1の命令を受け取る段階と、前記少なくとも1つのオペランドが前記第1のベースよりも小さい第2のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第1の命令を、前記第2のベースを有する第2のプロセッサに対して最適化された第2の命令に変換する段階と、前記少なくとも1つのオペランドが前記第2のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも1つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第3の命令を、前記第2のベースよりも大きく前記第1のベースよりも小さいか又は等しいより広いベースに変換する段階と、を含む演算式最適化を実行する、計算機が実行可能な命令プログラムを包含することを特徴とする、計算機が読取可能なプログラム記憶装置。より広いベースへの前記変換段階は、前記第3の命令の以前の変換結果を、より広いベースへの前記変換段階の前に破棄する段階を更に含むことを特徴とする請求項15に記載のプログラム記憶装置。前記第2のプロセッサ上でより小さなベースに最適化することができない表現を拒否する段階を更に含むことを特徴とする請求項15に記載のプログラム記憶装置。より広いベースへの前記変換段階は、より広い前記ベースが前記第2のプロセッサによってサポートされない時は前記第1の命令を拒否する段階を更に含むことを特徴とする請求項15に記載のプログラム記憶装置。前記第1の命令は、算術であることを特徴とする請求項15に記載のプログラム記憶装置。前記第1の命令は、タイプに敏感な非算術命令を含むことを特徴とする請求項15に記載のプログラム記憶装置。前記第1の命令の前記変換段階の後で、前記第1のプロセッサのために形成された全ての命令が変換されるまで、前記第1の命令を受け取る段階に戻る段階を更に含むことを特徴とする請求項19に記載のプログラム記憶装置。全ての制御経路において、各命令を後続命令にリンクする段階を更に含むことを特徴とする請求項21に記載のプログラム記憶装置。前記第1の命令の前記変換段階は、命令の結果の各々を、前記結果を消費する全ての命令にリンクする段階と、前記変換段階が値を作り出す段階を含む場合、前記値を生み出した命令に前記値をリンクする段階と、前記値が桁あふれの可能性を伴う場合、前記桁あふれを最初に引き起こした命令に前記値をリンクする段階と、を更に含む、ことを特徴とする請求項22に記載のプログラム記憶装置。前記第1のプロセッサは、Java登録商標仮想計算機を含み、前記第2のプロセッサは、JavaCard登録商標仮想計算機を含む、ことを特徴とする請求項15に記載のプログラム記憶装置。前記第1のベースは、前記第1のベースのサイズよりも小さいサイズを有する少なくとも1つのデータタイプ上で算術演算を実行するために、前記第1のプロセッサによって使用され、前記少なくとも1つのデータタイプのサイズに等しいサイズを有する前記第2のベースは、前記少なくとも1つのデータタイプ上で算術演算を実行するために、前記第2のプロセッサによって使用される、ことを特徴とする請求項15に記載のプログラム記憶装置。前記第1のプロセッサは、32ビットのプロセッサを含み、前記第2のプロセッサは、リソース限定型16ビットのプロセッサを含む、ことを特徴とする請求項15に記載のプログラム記憶装置。前記第1のベースは、前記第1のベースのサイズよりも小さいサイズを有する少なくとも1つのデータタイプ上で算術演算を実行するために、前記第1のプロセッサによって使用され、前記少なくとも1つのデータタイプのサイズよりも大きいサイズを有する前記第2のベースは、前記少なくとも1つのデータタイプ上で算術演算を実行するために、前記第2のプロセッサによって使用される、ことを特徴とする請求項23に記載のプログラム記憶装置。プログラム命令を有する少なくとも1つのメモリと、第1のベースを有する第1のプロセッサのために形成され、演算子と少なくとも1つのオペランドとを含む第1の命令を受け取り、前記少なくとも1つのオペランドが前記第1のベースよりも小さい第2のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第1の命令を、前記第2のベースを有する第2のプロセッサに対して最適化された第2の命令に変換し、前記少なくとも1つのオペランドが前記第2のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも1つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第3の命令を、前記第2のベースよりも大きく前記第1のベースよりも小さいか又は等しいより広いベースに変換する、ために前記プログラム命令を使用するように形成された少なくとも1つのプロセッサと、を含むことを特徴とする、演算式最適化のための装置。前記少なくとも1つのプロセッサは、より広いベースに変換する段階の前に、前記プログラム命令を使用して前記第3の命令の以前の変換結果を破棄するように更に形成されることを特徴とする請求項28に記載の装置。第1のベースを有する第1のプロセッサのために形成され、演算子と少なくとも1つのオペランドとを含む第1の命令を受け取る手段と、前記少なくとも1つのオペランドが前記第1のベースよりも小さい第2のベースを超える潜在的桁あふれを伴わない時、又は、前記演算子が桁あふれに敏感でない時、前記第1の命令を、前記第2のベースを有する第2のプロセッサに対して最適化された第2の命令に変換する手段と、前記少なくとも1つのオペランドが前記第2のベースを超える桁あふれの可能性を伴う時、及び、前記演算子が桁あふれに敏感である時、前記少なくとも1つのオペランドに付随する潜在的桁あふれの源であり、以前に最適化されている第3の命令を、前記第2のベースよりも大きく前記第1のベースよりも小さいか又は等しいより広いベースに変換する手段と、を含むことを特徴とする、演算式最適化のための装置。より広いベースに変換する前記手段は、より広いベースに変換する前記段階の前に、前記第3の命令の以前の変換結果を破棄する手段を更に含むことを特徴とする請求項30に記載の装置。全ての制御経路において、各命令を後続命令にリンクする手段を更に含むことを特徴とする請求項30に記載の装置。第1のベースを有するプロセッサを目標とする少なくとも1つの命令の演算式最適化を含むアプリケーションソフトウエアプログラムを使用する方法であって、ソフトウエアプログラムをプロセッサ上に受け取る段階と、命令のシーケンスを前記プロセッサ上で実行する段階と、を含むことを特徴とする方法。前記少なくとも1つの命令をリソース限定型装置上に記憶する段階を更に含むことを特徴とする請求項33に記載の方法。マイクロ制御装置によって実行される仮想計算機、を含み、前記仮想計算機は、複数の予め最適化された命令から成るソフトウエアアプリケーションを実行し、前記仮想計算機は、リソース限定型装置上で実行するために予め最適化されている最適化された命令を受け取る手段と前記命令を実行する手段とを含む、ことを特徴とする、マイクロ制御装置が組み込まれたスマートカード。コンピュータ産業においては、同じプログラムをリソース限定型装置で実行することができ、従って縦のプラットフォームに亘る相互運用性が達成されるように、比較的メモリが豊富なデスクトップコンピュータ上で実行するように意図された高級コンピュータ言語をサポートする傾向が増加している。この縦のプラットフォームに亘る相互運用性には、高級プログラム言語で書かれたプログラムがリソース限定型装置で実行された時、それらが仮に比較的メモリが豊富な装置で実行された場合にもたらすであろう同じ結果を示すことが必要である。例えば、Java登録商標プログラム言語で書かれたプログラムの実行を、スマートカードプラットフォーム、手持式装置、消費者電気器具、デスクトップコンピュータ、及び、スーパーコンピュータを含む、様々なプラットフォーム上でサポートすることが必要である。従って、意味論的に同等な数学的表現をより少ない計算スタック空間を使用して実行することができるように、プログラム表現を変える必要性が存在する。更に、実行速度が増加するようにそのような変形を行う必要性が従来技術において存在する。演算式最適化の方法は、第1のベースを有する第1のプロセッサのために形成された、演算子と少なくとも1つのオペランドとを含む第1の命令を受け取る段階、全てのオペランドが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに対して敏感でない場合、第1のベースよりも小さい第2のベースを有する第2のプロセッサのために最適化された第2の命令に第1の命令を変換する段階、及び、少なくとも1つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合、桁あふれの源である第3の命令をより広いベースに変換する段階を含む。演算式最適化の装置は、プログラム命令を有する少なくとも1つのメモリ、及び、第1のベースを有する第1のプロセッサに対して形成された第1の命令を受信し、少なくとも1つのオペランドのいずれもが潜在的な桁あふれを伴っていないか、又は、演算子が桁あふれに敏感でない場合には、その第1の命令を第1のベースよりも小さい第2のベースを有する第2のプロセッサに対して最適化された第2の命令に変換し、少なくとも1つのオペランドが桁あふれの可能性になっており、かつ、演算子が桁あふれに対して敏感な場合には、桁あふれの源である第3の命令をより広いベースに変換するために、プログラム命令を使用するように形成された少なくとも1つのプロセッサを含む。当業者は、本発明の以下の記述が単に例示的であることを理解するであろうし、本発明の開示の恩恵を受けるような当業者に対しては、本発明の他の実施形態が容易に示唆されるであろう。本発明は、コンピュータシステムに関する。より具体的には、本発明は、nベースタイプの演算式の最適化に関する。本発明は、更に、1本発明のレイアウトパラメータ、及び/又は、2コンピュータ上で演算を実行する際に本発明を使用するためのプログラム命令、を記憶した機械読取可能媒体に関する。そのような媒体には、例として挙げると、磁気テープ、磁気ディスク、CDROMのような光学的読取可能媒体、及び、PCMCIAカードのような半導体メモリが含まれる。この媒体はまた、小さなディスク、ディスケット、又は、カセットのような携帯用品目の形態を取ってもよい。この媒体はまた、ハードディスクドライブやコンピュータRAMのようなより大きな又は固定式品目の形態を取ってもよい。リソース限定型装置は、通常のデスクトップコンピュータなどと比べた場合、一般的に、メモリ、及び/又は、計算能力又は速度が比較的制限されているものであると考えられている。以下で検討する特定の実施例はスマートカードに関して説明されるが、本発明は、他のリソース限定型装置と共に使用することができ、それらには、以下に限定されないが、セルラー電話機、境界用走査装置、野外用プログラム可能装置、携帯情報端末PDA、及び、ポケットベルのほか、他の小型又は小さな衛星電波使用装置が含まれる。本発明はまた、非リソース限定型装置上でも使用することができる。本発明を開示する目的上、プロセッサという用語は、物理的なコンピュータ又は仮想計算機を意味するように用いられる場合がある。ここで図4Aを参照すると、本発明の一実施形態に従ってリソース限定型計算機上で実行するための演算式を変換する段階を説明するブロック図が示されている。コンパイラは、高級言語62で書かれた演算式60を取り、そのオペランドをより大きな整数タイプに拡大し、一般的なデスクトップ計算機66上で実行するためのより大きなベースタイプの命令64を作り出す。このより大きなベースタイプ命令64は、リソース限定型計算機70上で実行するための意味論的に同等なより小さなベースタイプ命令68に最適化される。例えば、shortタイプの加算命令は、shortタイプのオペランドに対して演算するのに使用され、その結果は、タイプshortである。本発明の別の実施形態によると、意味論的に同等なより小さなベースタイプ命令への最適化は、ジャストインタイムコード発生装置の一部である。命令セットが初めて実行される少し前に、最適化されていない命令は、リソース限定型計算機上で実行するための意味論的に同等なより小さなベースタイプ命令に最適化される。同じ命令セットのその後の実行は、その最適化された命令セットを使用する。本発明の別の実施形態によると、算術命令の意味を保存するためにより大きなタイプ命令64が必要であり、かつ、より大きなタイプ命令が目標とするプロセッサによってサポートされていない場合、その演算式は、サポートされていないとして拒絶される。ここで図4Bを参照すると、本発明の一実施形態による命令を変換する段階を説明するブロック図が示されている。32ビットオペランドを有する命令を含むJava登録商標の部類のファイル72は、JavaCard登録商標の部類のファイル変換器74によって受け取られる。この変換器74は、リソース限定型装置上で実行するために最適化された命令76を発生する。この最適化は、例として挙げると、より少ないスタック使用量、より小さなプログラムサイズ、及び、より高速の実行を準備する段階を含む。目標とする計算機は、nタイプの算術演算をサポートするであろう。Java登録商標仮想計算機は、タイプint演算子をサポートするが、JavaCard登録商標仮想計算機は、タイプshort演算子をサポートし、オプションでタイプint演算子をサポートする。他の装置は、byteタイプの算術演算子のみ、又は、byte、short、及び、intタイプの演算の全てをサポートしてもよい。一般的に、8ビット又は16ビットプロセッサ上で16ビットの算術を実行するために比較的少ない時間を要し、同じプロセッサ上で32ビットの算術を実行するためには、比較的多くの時間が必要である。算術演算に使用される実際の値は最適化時には未知であるから、最適化は、各オペランドに対して最悪の場合の値を仮定する必要がある。オペランドに対する最悪の場合の値は、入力オペランドタイプに基づいて判断される。小さいタイプの演算は、大きいタイプの表示又はより大きなタイプへの桁あふれを必要とする結果を有する可能性がある。すなわち、本発明によると、算術演算子は、桁あふれによって影響される演算子と桁あふれを引き起こす可能性を有する演算子とに分類される。本発明を開示する目的上、桁あふれは、負の値の下位桁あふれを含む。小さいタイプの演算の結果は、その結果を作り出すのに用いられた演算子が大きいタイプの表示への桁あふれを引き起こす可能性を有する演算子のグループに属する場合、潜在的桁あふれを伴うと言われる。中間的な値は、その中間的な値が桁あふれに影響される演算子のグループに属する演算子のためのオペランドとして使用されない限り、潜在的桁あふれを伴うことを許される。桁あふれを引き起こす可能性を有する演算子は、加算、引き算、乗算、割り算、ネゲート、及び、左側桁送りを含む。これらの演算子に対するJava登録商標バイトコードは、表1に示されている。表1潜在的桁あふれを伴う演算桁あふれに影響される演算子は、表2に示されている。桁あふれに影響される算術演算子は、割り算、剰余、ネゲート、右側桁送り、及び、符号なしの右側桁送りを含む。また、桁あふれに影響される非算術演算子は、アレー演算、スイッチ演算、及び、比較演算を含む。表2桁あふれに影響される演算表1の演算をより小さなタイプに最適化する時、結果は、より大きなタイプの中に桁あふれする場合がある。表2の演算子のうちの1つを用いる表現の結果は、表現中のオペランドのうちの1つが中間的な値であり、潜在的な桁あふれデータを含む場合、精度を失うであろう。最適化を可能にし、高級ソースコードの意味を保存するために、潜在的桁あふれは、結果が表2の演算のうちの1つに入力される場合、その結果のタイプに対する明白なソースレベルの型を用いて是正する必要がある。表2の演算のいずれかに対する入力オペランドが表1の演算の結果であり、明白な高級ソースコードの型がない場合、最適化は起こることができない。そのような誤った最適化は、意味論的に同等な結果を保証しないであろう。換言すれば、リソース限定型装置上で実行するために発生された最適化コードは、結果をデスクトップコンピュータ用に発生された最適化なしのコードとは異なるようにすることができるであろう。例えば、桁あふれデータは、オペランドのJava登録商標32ビット表示で与えることができるが、JavaCard登録商標16ビット表示ではできないであろう。表1に列挙された演算子を用いる演算の結果は、より小さなタイプを有する演算子が適用された場合、桁あふれを生じる場合がある。デスクトップコンピュータプラットフォームを目標とする命令をリソース限定型コンピュータプラットフォームを目標とする命令に最適化する段階に付随するこれらの問題の例は、図5A~図8Bに与えられている。これらの例は、デスクトップコンピュータが32ビットアーキテクチャに基づいており、比較的メモリが豊富であることを仮定している。リソース限定型コンピュータは、比較的少ないメモリを有する16ビットアーキテクチャに基づくと仮定されている。当業者は、本発明が様々なアーキテクチャを有する演算プラットフォームに適用されることを認めるであろう。図5A~図8Bはまた、符号を有する値を使用する。当業者はまた、値の符号の有無に関わらず桁あふれが起こり得ることを認めるであろう。ここで図5Aを参照すると、デスクトップコンピュータ上での2つのタイプshortの値の加算を説明するコード見本が示されている。値aは、16ビットの符号付きshortタイプで表すことができる最大値を含む。上記の通り、たとえ値が16ビットshortの値であっても、intタイプの加算が用いられる。すなわち、16ビット範囲から32ビット範囲への桁あふれが結果の値の中に存在し、桁あふれの効果は、より大きな正の32ビット数を作り出すことである。ここで図5Bを参照すると、リソース限定型コンピュータ上で図5Aにおけるのと同じ値を加算する段階を説明するコード見本が示されている。実行は、リソース限定型コンピュータ上で行われており、両方の値が16ビットshortタイプであるから、命令はshortタイプの加算を用いて最適化され、従ってより少ないスタック空間を使用する。しかし、32ビット加算の代わりに16ビット加算が用いられるために、加算は符号ビットに桁あふれを引き起こす。デスクトップコンピュータは、32、768という値を計算したのに対し、リソース限定型コンピュータの例で計算された結果は、-32、768という負の数である。この結果は、それがデスクトップコンピュータの結果と異なり、多様なコンピュータプラットフォームに亘る相互運用性を妨げる理由から、受け入れられないものである。ここで図6Aを参照すると、2つのタイプshortの値の加算とその結果を直ちに型に入れる段階とを説明するコード見本が示されている。この例は、加算結果がタイプshortに型入れされる点を除いて、図5Aのものと同じである。タイプをshortに型入れする段階は、最も有意な16ビットをshort値に切り落とし、符号が32ビット値に広がる。潜在的に桁あふれを伴う演算add演算の結果は、タイプshortに型入れされ、それによっていかなる潜在的桁あふれの問題も排除する。図6Bは、リソース限定型コンピュータ上で16ビット値として表された、図6Aにおけるのと同じ値を加算する段階を示す。デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。ここで図7Aを参照すると、デスクトップコンピュータ上での3つのタイプshortの値の加算を説明するコード見本が示されている。この例においては、intタイプの加算が、16ビットshort値a及びbを加え、その結果をcに加えるために用いられている。最終結果は、shortタイプに型入れされる。ここで図7Bを参照すると、リソース限定型コンピュータ上に潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響されない演算を実行する段階を説明するコード見本が示されている。この例の全ての値は16ビットのshortタイプであるから、全ての中間的な加算に対してshortタイプの加算が用いられる。表1に示す通り、加算演算子は、潜在的に桁あふれを引き起こすが、桁あふれに影響されない。すなわち、aとbを加えることは、潜在的に桁あふれを伴う値を作り出す。この値がcに加えられ、潜在的に桁あふれを伴う別の値を作り出す。第2のadd演算は、潜在的に桁あふれabの結果を伴う1つのオペランドを含むが、add演算は、桁あふれを伴うオペランドに影響されない。最終結果は、タイプshortに型入れされ、加算演算から潜在的な桁あふれを取り除く。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの両方に対する結果の値は同じである。ここで図8Aを参照すると、デスクトップコンピュータ上での2つのタイプshortの値の加算とその結果をタイプshortの値で割り算する段階とを説明するコード見本が示されている。実行はデスクトップコンピュータ上で行われているので、intタイプの演算が用いられる。a及びbの値がintタイプのaddを用いて互いに加えられ、この中間的な値は、cで割り算される。ここで図8Bを参照すると、リソース限定型コンピュータ上で潜在的に桁あふれを伴う演算によって引き起こされたオペランドの桁あふれに影響される演算を実行する段階を説明するコード見本が示されている。実行はリソース限定型コンピュータ上で行われているので、shortタイプの演算が用いられる。a及びbの値は、shortタイプのaddを用いて互いに加えられる。この加算は、16ビット範囲から桁あふれする中間的な値を作り出す。この中間的な値は、cで割り算される。図7Bで用いられた加算演算子と異なり、割り算演算子は、表2に示す通り桁あふれに影響される。高いビットに値が入っているので、この16ビット値は、負であると見なされる。すなわち、デスクトップコンピュータ及びリソース限定型コンピュータの例は、図6A~図7Bにおけるようなプログラムで表されたタイプ変換で訂正されていない、異なる結果をもたらす。本発明によると、演算式は、オペランドのタイプに応じて最適であるタイプの命令を用いて最適化される。最適化処理は、潜在的桁あふれの問題に遭遇するまで進行される。その時点で、演算式の入力オペランドに立ち戻り、それを次のより大きなタイプ命令に変換する。この処理は、演算式が最適化された命令セットを用いてデスクトップコンピュータとリソース限定型装置とで同じ結果を示すような、命令の適切なタイプが選択されるまで繰り返される。変換処理の間は、いくつかの関係が維持される。これらの関係は、命令と、その命令を目標とする計算機上で実行する時に生じることになる値とに関する。関係データには、値に対する実際のタイプ及びターゲットタイプが含まれる。関係データはまた、命令が目標とする計算機上で一旦実行されると目標とする計算機上で値を生み出すことになるソース命令を含む。各命令はまた、そのオペランド関係データにリンクされる。更に、結果に関する関係データは、その結果を消費する命令にリンクされる。各関係データはまた、命令が目標とする計算機上で実行された場合に潜在的桁あふれを生じることになる命令もしあればにリンクされる。この命令は、ロールバックポイントと呼ばれる。潜在的桁あふれを伴う値が桁あふれに敏感な演算子によって消費された場合、誤った最終結果が生み出されることがあるので、生み出されることになる値の各々を桁あふれを引き起こした命令とリンクさせることは、変換処理を先に進めることができない時に桁あふれ問題を引き起こした命令にロールバックする方法を与える。中間的な値は、後続の命令においてオペランドとして更に消費することができる。中間的な値が潜在的に桁あふれを伴う場合、ロールバック命令もまた、結果内を伝達される。これは、表現を変換する過程で繰り返される。このロールバック作用は、常に中間的な値又は、オペランドに作用し、再変換が必要とされる命令までロールバックする。ロールバック命令を判断する方法及び最適化の他の詳細は、以下で検討される。ここで図9を参照すると、本発明の一実施形態によるnベースタイプの演算式最適化を説明する流れ図が示されている。参照番号80で、変換される命令が受け取られる。参照番号82で、入力オペランドのいずれかが潜在的桁あふれを伴うか否かに関して判断が為される。少なくとも1つのオペランドが潜在的桁あふれを伴う場合、変換される命令が桁あふれに敏感であるか否かに関する判断が参照番号84で為される。これらに関するJava登録商標バイトコードが表2に列挙されている。当業者は、桁あふれに影響される演算子のリストが異なる高級言語に関して変動し得ること、及び、本発明がこれらの他の言語にも同様に適用し得ることを認めるであろう。変換される命令が桁あふれに敏感である場合、変換処理は、参照番号86において問題の源である命令にロールバックされ、その命令は、より広いベースを有するタイプを用いて変換される。例えば、8ビットのバイトタイプは、16ビットのワードタイプに拡大され、16ビットのワードタイプは、32ビットのワードタイプに拡大されるであろう。オペランドをより大きなタイプに拡大することにより、オペランドのその後の命令変換がより大きなタイプに結合された命令を使用することが必要になる。変換される命令が桁あふれに敏感でない場合、又は、どの入力オペランドも潜在的桁あふれを伴わない場合、その命令は、参照番号88で、リソース限定型装置上での実行に対して最も最適なタイプに変換される。参照番号90で、変換される命令がまだ残っているか否かに関する判断が為される。更なる命令が残っている場合、参照番号80で次の命令の変換が始まる。最後の命令が変換されると、参照番号92で変換処理が終了する。ここで図10を参照すると、本発明の一実施形態によるnベースタイプの演算式最適化を説明する詳細な流れ図が示されている。参照番号100で、変換が完了していないという指示が作られる。参照番号102で、第1の命令の変換を実行すべきであるという指示が作られる。参照番号104で、命令変換が完了したか否かが判断される。命令変換が完了した場合、実行は参照番号106で終了する。変換が完了していない場合、変換が完了したという指示が参照番号108で作られる。参照番号110で、第1の命令が得られる。参照番号112で、その命令が変換されるべきか否かの判断が為される。命令を変換する必要がある場合、変換が未完了であるという指示、及び、現在の命令を再度変換すべきではないという指示が、参照番号114及び116で各々作られる。参照番号118で、命令は、より小さなベースタイプを有する、目標とする計算機のために最適化された別の命令に変換される。参照番号120で、ロールバックが参照番号118における変換によってトリガされたか否かに関する判断が為される。ロールバックがトリガされていた場合、ロールバックポイントでの命令が参照番号122で得られ、ロールバックポイントでの命令の変換が参照番号104で再度開始される。ロールバックがトリガされない場合、結果のタイプ及びターゲットタイプが参照番号124で照合される。参照番号126で、変換情報は、各制御経路の後続命令に伝達される。参照番号128で、更なる命令が残っているか否かに関する判断が為される。更なる命令が残っている場合、次の命令が参照番号130で取得され、参照番号112で実行が継続される。変換処理は、最後の命令が変換されると終了する。ここで図11を参照すると、本発明の一実施形態による命令を変換する段階を説明する流れ図が示されている。参照番号140で、現在の命令が算術命令か否かが判断される。命令が算術命令である場合、それは、参照番号142で変換される。同様に、スタック操作命令、ターゲット命令、タイプ変換命令、及び、初期値変換命令は、参照番号146、150、154、及び、158で各々変換される。命令が図11の算術命令、スタック操作命令、タイプ変換命令、又は、初期値命令か否かによる命令の分類は、単に例示的な目的で示されている。当業者は、本発明が他の多くの命令の種類又は分類に対しても同様に適用し得ることを認めるであろう。ここで図12Aを参照すると、本発明の一実施形態によるターゲット命令を変換する方法を説明する流れ図が示されている。Java登録商標仮想計算機命令セットにおいては、ターゲット命令は、分岐、スイッチ、アレーアクセス、アレー作成、及び、様々な記憶/保管命令store/put命令を含むほか、スタック操作命令、タイプ変換命令、初期値命令、又は、演算式ではない、コンピュータ言語におけるタイプに敏感な他のいかなる非算術命令をも含む。参照番号160で、命令オペランドに対するターゲットタイプが判断される。参照番号162で、ターゲット命令が消費するオペランドがそのターゲット命令のターゲットタイプよりも小さいタイプを有するか否かに関する判断が為される。そのオペランドが目標とするものよりも小さなタイプを有する場合、変換処理は、参照番号164で、その小さなタイプのオペランドを用いてロールバックされる。オペランドが目標とするものよりも小さなタイプを持たない場合、そのオペランドが潜在的桁あふれを伴うか否かに関する判断が参照番号166で為される。オペランドは、それが表1に記載されたオペランドのうちの1つで作り出されたか、又は、オペランド内で桁あふれを伝達する演算子によって作り出された場合、潜在的桁あふれを伴うことがある。桁あふれを伝達する演算子には、例として挙げると、and、or、及び、排他的orxor演算子が含まれる。どのオペランドも潜在的桁あふれを伴わない場合、命令は、参照番号167で最適化される。オペランドの少なくとも1つが潜在的に桁あふれを伴っている場合、変換処理は、参照番号164で、より小さなオペランドを用いてロールバックされる。ここで図12Bを参照すると、本発明の一実施形態による初期値命令を変換する方法を説明する流れ図が示されている。初期値命令の例には、獲得/ロード命令get/load命令、及び、変数をロードする他の命令が含まれる。初期値命令はまた、方法の結果を戻す、方法呼出し命令を含む。更に、初期値命令は、ロード定数命令を含む。これらの命令は、命令が生み出す値が中間的な計算の結果ではないことから、初期値命令と呼ばれる。参照番号168で、変数、戻り値、又は、定数のタイプが受け取られる。参照番号169で、初期値命令は、変数又は定数のタイプに従って最適化される。例えば、shortタイプのローカル変数をロードするために、iload命令はsloadに最適化される。ここで図13を参照すると、本発明の一実施形態によるタイプ変換命令を変換する方法を説明する流れ図が示されている。タイプ変換命令は、オペランドをより大きなタイプ又はより小さなタイプに変換してもよい。例えば、32ビットのintタイプを16ビットのshortタイプに型入れする段階は、オペランドをより小さなタイプに変換する。同様に、8ビットのbyteタイプを32ビットのintタイプに型入れする段階は、オペランドをより大きなタイプに変換する。後者の場合、byteタイプは、オペランドタイプと呼ばれ、intタイプは、ターゲットタイプと呼ばれる。参照番号170で、命令が受け取られる。オペランドタイプ及びターゲットタイプは、各々、参照番号172及び174において決められる。オペランドタイプがターゲットタイプよりも大きい場合、オペランドタイプは、参照番号178でターゲットタイプまで狭められる。オペランドタイプがターゲットタイプよりも小さい場合、オペランドが潜在的に桁あふれを伴っているか否かに関する判断が参照番号180で為される。オペランドが潜在的に桁あふれを伴う場合、変換処理は、タイプを訂正するために参照番号182でロールバックされる。オペランドタイプが潜在的桁あふれを伴わない場合、オペランドは、参照番号184でターゲットタイプまで広げられる。ここで図14を参照すると、本発明の一実施形態によるスタック操作命令を変換する方法を説明する流れ図が示されている。Java登録商標仮想計算機命令セットにおいては、スタック操作命令は、dup複製する、swap交換する、及び、popポップする命令を含む。参照番号190で、命令が受け取られる。参照番号192で、その命令がdup命令か否かに関する判断が為される。命令がdup命令である場合、参照番号194で、元のスタックエントリに対するロールバックポイントが存在するか否かに関する判断が為される。元のスタックエントリがロールバックポイントを有する場合、複製されたスタックエントリのロールバックポイントは、参照番号196で、元のスタックエントリのロールバックポイントに設定される。元のスタックエントリがロールバックポイントを持たない場合、複製されたスタックエントリのロールバックポイントは、参照番号198で、元のスタックエントリのソース命令に設定される。参照番号200で、命令が変換される。ここで図15を参照すると、本発明の一実施形態による演算式を変換する方法を説明する流れ図が示されている。参照番号210で、オペランドが潜在的桁あふれを伴っているか否かに関する判断が為される。オペランドが潜在的桁あふれを伴わない場合、参照番号212で、オペランドが潜在的桁あふれを持たないという指示が作られる。オペランドが潜在的桁あふれを伴う場合、参照番号214で、命令が桁あふれに影響されるか否かに関する判断が為される。命令が桁あふれに影響されない場合、参照番号216で、オペランドが潜在的桁あふれを有するという指示が作られる。命令が桁あふれに影響される場合、この変換は、参照番号218で、桁あふれを有する第1のオペランドにロールバックされる。変換がロールバックされない場合、最適化された命令タイプが参照番号220で決められ、命令が参照番号222で最適化され、結果のタイプと結果の桁あふれが参照番号224で判断される。ここで図16を参照すると、本発明の一実施形態による最適化された命令タイプを判断する方法を説明する流れ図が示されている。参照番号230で、少なくとも1つのオペランドが受け取られる。参照番号232で、目標とする命令タイプは、そのオペランドに付随する最も大きいタイプに設定される。参照番号234で、オペランドのいずれかが目標とする命令タイプよりも小さいタイプを有するか否かに関する判断が為される。少なくとも1つのオペランドが目標とするタイプよりも小さいタイプを有する場合、その小さいオペランドは、タイプを訂正するために参照番号236でロールバックされる。ここで図17を参照すると、本発明の一実施形態による結果のタイプ及び結果の桁あふれを判断する方法を説明する流れ図が示されている。参照番号240で、結果のタイプは、命令タイプに設定される。JavaCard登録商標の戻された結果タイプ及び桁あふれ指示は、以下の表3から表10にまとめられている。これらの表は、命令のタイプによって構成されている。各表は、1つ又は2つのオペランドのタイプに基づいて、結果タイプと桁あふれ指示とを示している表3加算、乗算、及び、引き算表4割り算表5左側桁送り表6右側桁送り表7ネゲート表8符号なしの右側桁送り表9剰余表10and、or、及び、xor図17におけるJavaCard登録商標の結果タイプ及び桁あふれ指示の使用は、単に例証目的のためである。当業者は、本発明が他のタイプを有する他の高級言語に対しても適用可能であることを認めるであろう。参照番号244で、結果がより最適化された命令を用いることで生じた桁あふれを潜在的に伴うか否かに関する判断が為される。結果が潜在的桁あふれを伴わない場合、参照番号246で、オペランドのいずれかが桁あふれを伝達するか否かに関する判断が為される。少なくとも1つのオペランドが桁あふれを伝達するか、又は、結果が潜在的に桁あふれを伴う場合、その結果のロールバックポイントが参照番号248で記録され、結果が潜在的桁あふれを有するという指示が参照番号250で作られる。ここで図18を参照すると、本発明の一実施形態によるロールバックポイントを記録する方法を説明する流れ図が示されている。参照番号260で、第1のオペランドがそれに付随するロールバックポイントを有するか否かに関する判断が為される。第1のオペランドがそれに付随するロールバックポイントを有する場合、現在の命令のロールバックポイントは、参照番号262で、第1のオペランドのロールバックポイントに設定される。第1のオペランドがそれに付随する桁あふれを持たない場合、参照番号264で、第2のオペランドがそれに付随する桁あふれを有するか否かに関する判断が為される。第2のオペランドがそれに付随するロールバックポイントを有する場合、命令のロールバックポイントは、参照番号266で、第2のオペランドのロールバックポイントに設定される。どちらのオペランドもそれに付随するロールバックポイントを持たない場合、命令のロールバックポイントは、参照番号268で、第1のオペランドに対するソース命令に設定される。本発明の特定の実施形態によると、図18に示す通り、第1のオペランドは、第1に作り出されたオペランドを意味する。ロールバックポイントをより古いオペランドに対するソース命令に設定することは、より古いオペランドに付随するタイプを訂正することによって、より新しいオペランドがその後に使用するタイプを訂正し得るので、より新しいオペランドに対する追加のロールバック演算を実行する必要性を除外するであろう。ここで図19を参照すると、本発明の一実施形態による変換処理をロールバックする方法を設定する流れ図が示されている。参照番号270で、現在の命令の変換が割り込まれる。参照番号272で、オペランドがロールバックポイントを有するか否かに関する判断が為される。オペランドがロールバックポイントを持たない場合、ロールバック命令は、参照番号276で、そのオペランドを作り出したソース命令に設定される。オペランドがロールバックポイントを有する場合、ロールバック命令は、参照番号274で、その同じロールバックポイントに設定される。参照番号278で、ロールバック命令の目標とするタイプが広げられる。参照番号280で、ロールバック命令を変換すべきであるという指示が作られる。変換処理は、参照番号282において、ロールバック命令で再開される。参照番号284で、ロールバック命令は、新しい目標とするタイプに従って変換される。ここで図20を参照すると、本発明の一実施形態による命令最適化の結果を伝達する段階を説明する流れ図が示されている。参照番号290で、後続命令が取得される。後続命令とは、現在の命令と同じ制御経路にあって、現在の命令の直ぐ後に発生する命令である。当業者は、1つの命令が多くの制御経路の一部であってもよいことを認めるであろう。参照番号292で、後続命令が変換処理において以前に訪問されたか否かに関する判断が為される。後続命令が以前に訪問されていない場合、後続命令に関する変換情報は、参照番号294で現在の命令に関する変換情報と等しいように設定され、参照番号296で後続命令を変換すべきであるという指示が作られる。変換情報は、現在の変換点におけるランタイム状態を含んでもよい。例えば、まだ消費されていない現在又は以前の命令によって、それらの値が作り出される。これらの値は、制御経路の後続命令に対してオペランドとして使用されることになる。各値に対して、タイプ、ソース命令、及び、ロールバックポイントが記録される。後続命令が以前に訪問されていた場合、後続命令において以前に記録された変換情報は、参照番号298で現在の変換情報と結合される。参照番号300で、結合された情報の中の値が変更されたか否かに関する判断が為される。値が変更されていた場合、後続命令を変換すべきであるという指示が参照番号296で作られる。この処理は、各後続命令に対して繰り返される。ここで図21を参照すると、本発明の一実施形態による異なる制御経路からの変換情報を結合する段階を説明する流れ図が示されている。参照番号310で、両方の制御経路の対応する入力が比較される。参照番号312で、対応する入力のタイプが異なっているか否かに関する判断が為される。タイプが異なる場合、より小さなタイプを有する入力は、参照番号314でロールバックされる。この処理は、各オペランドに対して繰り返される。ここで図22Aを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化が可能な演算式への本発明の応用法を示している。図22Aは、値a、b、及び、cをタイプshortとする時の以下のJava登録商標表現に対する変換処理を説明している。shortc=shortshortab/cこの式のJava登録商標バイトコードシーケンスは、参照番号316で示されている。命令変換は、iloada命令で始まる。第1のより小さなタイプに付随する命令が、load及びadd命令に対して用いられる。表1に明記した通り、add命令は潜在的桁あふれを引き起こすが、ソースレベルにおけるタイプshortへの明確な型入れが、桁あふれの可能性を取り除く。div330の命令は、表2に示す通り、桁あふれに影響される。しかし、明確な型入れのために、潜在的桁あふれは何も存在しない。従って、より大きなタイプを作り出すために加算演算にロールバックする必要性は起こらない。本発明の理解を更に助けるために、上記で検討した例は、図10から図21に関連して以下で更に詳細に説明される。iload命令は、ソース命令である。参照番号160において、aオペランドに対する目標とするタイプはタイプshortである。参照番号162において、オペランドaはタイプshortである。オペランドは、それらが直接ロードされ、従って、桁あふれを引き起こす演算によって作り出されたのではないために、参照番号166で潜在的桁あふれを伴わない。従って、参照番号167でiload命令をsloada命令に変換するのに、shortの気味のある命令が使用される。同様に、iloadb命令は、sloadb命令に変換される。次に、iadd命令が処理される。iaddは桁あふれを引き起こすことがある命令であるから、そのオペランドが潜在的桁あふれを伴うか否かを判断する検査が参照番号210で行われる。両方のオペランドは、それらが潜在的桁あふれを伴わないように、直接ロードされる。従って、最適化された結果タイプは、参照番号220で判断される。参照番号232で、命令タイプは、最大のオペランドタイプに設定される。この例では、この最大オペランドタイプは、オペランドa及びオペランドbの両方がタイプshortであるために、タイプshortである。両方のオペランドが命令タイプと同じタイプであるから、参照番号238で、タイプshortが、命令タイプとして戻される。次に、参照番号222で、命令が最適化される。命令タイプがタイプshortであるから、最適化された命令は、saddである。次に、結果タイプ及び桁あふれ指示が、参照番号224で判断される。参照番号240で、結果タイプは、命令タイプであるタイプshortに設定される。更に、結果が潜在的桁あふれを有するという指示が表3に従って作られる。結果が潜在的桁あふれを含むので、abの結果に対するロールバックポイントは、参照番号248で記録される。いずれのオペランドもロールバックポイントを持たないので、結果に対するロールバックポイントは、参照番号268で、オペランドa第1のオペランドに対するソース命令に設定される。参照番号250で、結果が潜在的桁あふれを有するという指示が作られる。次に、i2s命令が処理される。このi2s命令は、タイプ変換命令である。参照番号176で、オペランドタイプshortは、ターゲットタイプshortと比較される。両方のタイプは同じであるから、参照番号178でタイプがタイプshortまで狭められ、潜在的桁あふれを取り除く。次に、iloadc命令が処理される。値a及びbのように、cはタイプshortであり、iloadc命令は、sloadc命令に変換される。次に、idiv命令が処理される。表2に明記した通り、idivは、桁あふれに影響されてもよい命令である。abオペランドは、shortへの明確なソースレベルの型入れのために潜在的桁あふれを伴わず、従って、最適化された割り算命令タイプは、参照番号232でタイプshortであると判断され、結果タイプは、参照番号240でタイプshortに設定される。次に、i2s命令が処理される。参照番号176で、オペランドタイプshortは、ターゲットタイプshortと比較される。両方のタイプは同じであるから、このタイプは、参照番号178でタイプshortまで狭められ、潜在的桁あふれを取り除く。最後に、istorec命令が処理される。目標とするタイプがタイプshortであり、オペランドが桁あふれを伴わないから、istorec命令は、参照番号167で、sstorec命令に最適化される。変換されたバイトコードは、参照番号318で示されている。ここで図22Bを参照すると、本発明の一実施形態による命令変換を説明するブロック図が示されている。これは、最適化不可能な演算式への本発明の応用法を示している。それにもかかわらず、変換されたコードは、未変換コードとの意味論的同等性を維持している。図22Bは、値a、b、及び、cをタイプshortとする時の以下のJava登録商標表現に対する変換処理を説明している。shortc=shortab/cこの式に対するJava登録商標バイトコードシーケンスは、参照番号320で示されている。命令変換は、参照番号322で表されたiloada命令で始まる。第1のより小さなタイプに付随する命令が、load322及び324とadd326との命令に対して使用される。表1で明記した通り、add命令326は、桁あふれの可能性を引き起こすが、第2のより大きなタイプの使用を必要としない。しかし、div330の命令は、桁あふれに影響される。これは、表2で示されている。すなわち、桁あふれの問題を引き起こす命令は、訂正されなければならない。この問題は、参照番号322までロールバックして、オペランドaに対して第2の大きなタイプの命令を使用することによって訂正される。命令変換がオペランドbもまたより大きなタイプに変換されるべきであると判断され、2度目のロールバックを必要とするまで、命令変換は、参照番号332で2度目を続行する。命令変換は、次に、オペランドcに対する命令がより大きなタイプの使用を必要とすると命令変換が判断されるまで、参照番号334で3度目を続行する。3度目のロールバックが実行され、オペランドcのタイプが訂正されて、変換処理は、参照番号336で4度目の変換処理が続行された後で完了する。本発明の理解を更に助けるために、上記で検討した図22Bの例は、図10から図21を参照して以下で更に詳細に説明される。iloada命令、iloadb命令、及び、iadd命令の最初の変換は、前記の例で説明したように進行する。次に、iloadc命令は、参照番号167で、sloadc命令に変換される。次に、idiv命令が処理される。表2で明記した通り、idivは、桁あふれに影響され得る命令である。abオペランドは、それが演算子によって作り出され、その演算子が表1で示したように桁あふれを引き起こすことがあるので、桁あふれの可能性となる。少なくとも1つのオペランドが桁あふれの可能性となっているので、桁あふれを有する第1のオペランドへのロールバックが参照番号218で実行される。参照番号270で、現在の命令の変換が割り込まれる。参照番号274で、桁あふれがabオペランドと結び付けられ、そのために、ロールバックポイントは、abオペランドに対するロールバックポイントに設定される。参照番号278で、ロールバック命令の目標とするタイプは、タイプshortからタイプintに広げられる。参照番号280で、ロールバックされる行き先の命令を変換する指示が作られる。参照番号282で、変換処理は、以前にsloada命令に変換されたiloada命令において再開される。このiloada命令は、参照番号284で変換される。ロールバックの結果として、iloada命令は、参照番号338で処理される。参照番号124で、結果のタイプと目標とするタイプとが照合される。結果のタイプがshortで、目標とするタイプがintであるから、そのタイプは一致しない。すなわち、shortをintに上げるために、S2I命令が作り出される。処理は、iloadb命令及びiadd命令を用いて続行される。iadd命令に対するオペランドは、参照番号210において潜在的桁あふれを伴わず、従って、最適化された結果タイプが参照番号220で判断される。参照番号234で、オペランドのタイプが比較される。aオペランドが今はタイプintであり、bオペランドがまだタイプshortであるから、bオペランドに対してロールバックが実行される。参照番号276で、ロールバック命令は、iloadb命令340に設定される。また、参照番号278で、目標とするタイプはintに設定される。参照番号280で、現在の命令を変換する指示が作られる。参照番号282及び284で、変換がiloadb命令において再開され、命令が変換される。参照番号124で、結果のタイプと目標とするタイプとが照合される。結果のタイプがshortで、目標とするタイプがintであるから、そのタイプは一致しない。すなわち、shortをintに上げるために、S2I命令が作り出される。次に、iadd命令が処理される。2度ロールバックした後では、いずれのオペランドも桁あふれの可能性を持っていない。従って、参照番号210で、オペランドが潜在的桁あふれを伴わないという指示が作られ、最適化された命令タイプが参照番号220で決められる。参照番号232で、命令タイプは、最大のオペランドタイプに設定される。abオペランドがタイプintであり、cオペランドがタイプshortであるから、命令タイプはintに設定される。cオペランドのタイプが命令タイプと異なるので、参照番号236で、cオペランドに対してロールバックが実行される。参照番号276で、ロールバック命令は、iloadc命令に設定される。参照番号278で、ロールバック命令の目標とするタイプは、タイプshortからタイプintに広げられる。変換処理は、iloadc命令342において再開される。参照番号124で、結果のタイプと目標とするタイプとが照合される。結果のタイプがshortで、目標とするタイプがintであるから、そのタイプは一致しない。すなわち、shortをintに上げるために、S2I命令が作り出される。次に、idiv命令が処理される。参照番号238において、両方のオペランドがタイプintであるから、最適化された命令タイプはintに設定される。参照番号222で、intの気味のある命令idivが選択される。最後の命令シーケンスは、図22の参照番号344で表されている。本発明は、整数タイプに関して説明されたが、当業者は、本発明が浮動小数点演算式に対しても同様に適用し得ることを認めるであろう。更に、本発明は、JavaCard登録商標技術に関して説明されたが、当業者は、本発明が他の多くのプラットフォームに対しても同様に適用可能であることを認めるであろう。これらのプラットフォームには、例として挙げると、K仮想計算機KVM技術が含まれる。KVM技術は、1999年6月8日にサンマイクロシステムズインコーポレーテッドから出版されたK仮想計算機KVM白書で説明されている。本発明は、ソフトウエア又はハードウエアにおいて実施されるであろう。本発明は、他のプロセッサにおいて実施されてもよく、同様に、プログラム可能ゲートアレー装置、特定用途向け集積回路ASIC、及び、他のハードウエアにおいて実施されてもよい。演算式の適応最適化に関する新しい方法が以上のように説明された。同一タイプの命令は、リソース限定型計算機上で実行するために、第2のより小さなより小さなビット数を有する整数タイプのための意味論的同等タイプの命令に変換され、従って、比較的効率的なスタック利用と実行速度の増加とをもたらす。本発明の実施形態及び応用例が示され説明されたが、本発明の開示の恩恵を受ける当業者には、本明細書の革新的概念から逸脱することなく、上述のもの以外に更に多くの変更が可能であることが明らかであろう。従って、本発明は、特許請求の範囲の精神において限定されるが、それ以外では限定されないものとする。