JP7391983B2 - プログラム論理の表現を生成する方法、逆コンパイル装置、再コンパイルシステムおよびコンピュータプログラム製品 - Google Patents

Description

本発明は、第１のプロセッサアーキテクチャのための低水準プログラミング言語における第１のプログラムコードに基づいて、中間言語におけるプログラム論理の表現を生成するための方法に関する。本発明はさらに、第１のプロセッサアーキテクチャのプロセッサのための第１のプログラムコードを逆コンパイルするための装置、第１のプロセッサアーキテクチャの第１のプログラムコードを第２のプロセッサアーキテクチャのための実行可能なプログラムコードに変換するための再コンパイルシステム、およびコンピュータプログラム製品に関する。

１９５０年代後半から１９８０年代末にかけて、関連するプロセッサアーキテクチャを有するいわゆるメインフレームコンピュータが多数開発された。このようなコンピュータシステムは、そのハードウェアのコストが比較的高いため、通常、コンピュータセンターで一元的に管理されていた。このプロセスでは、異なるアプリケーションを動作させるための異なるコンピュータプログラムが、同じコンピュータシステムのリソースを共有した。

コンピュータシステムの縮小化とそれに関連するコスト削減、および特にコンピュータシステムとその資源の仮想化におけるさらなる技術的進歩により、当時のメインフレームアーキテクチャの集中化されたアプローチは、かなり時代遅れになっている。それにもかかわらず、特に、このようなメインフレームシステム上で動作させるために元々開発された会計、税務管理および複雑な制御システムの分野では特に、比較的多数の専門化されたコンピュータプログラムが引き続き使用されている。

多くの場合、コンピュータプログラムの元々のソースコードは、もはや利用できないか、または合理的な労力では判定することができない。このようなコンピュータプログラムは、元々のアーキテクチャを備えた、まだ機能しているか、若しくは複製されたメインフレームシステム上で実行されるか、または仮想化システムを使用して、このようなメインフレームシステムのアーキテクチャをエミュレートする仮想化システム上で実行されることが増えている。

比較的広範なメインフレームコンピュータアーキテクチャは、それぞれＩＢＭ Ｓｙｓｔｅｍ／３６０（Ｓ／３６０）、ＩＢＭ Ｓｙｓｔｅｍ／３７０（Ｓ／３７０）およびＩＢＭ Ｓｙｓｔｅｍ／３９０（Ｓ／３９０）に基づく。これらのプロセッサアーキテクチャには、多数のプログラムが存在する。今日では、これらは通常、Ｉｎｔｅｌからのいわゆるｘ８６アーキテクチャのプロセッサを有するコンピュータシステム上で実行される。２つのプロセッサアーキテクチャ間の差を補償するために、関連するプロセッサを有するＳ／３６０、Ｓ／３７０またはＳ／３９０システムの動作は、通常、ｘ８６アーキテクチャを有するプロセッサ上でエミュレートされる。

エミュレータは、コンピュータプログラムを、例えば、Ｓ／３９０バイナリコードの個々の機械命令を解釈することによって、いわゆるＳ／３９０バイナリコードの形式で実行する。このような解釈は、コンピュータプログラムの基礎となるプログラム論理から独立しており、ソースプラットフォームの機械命令の意味の分析のみを必要とするため、実装することは概念的には比較的容易である。例えば、Ｓ／３９０アーキテクチャのレジスタおよびメモリアドレスは、ｘ８６アーキテクチャまたは別のターゲットプラットフォームのレジスタおよびメモリアドレスにマッピングされる。

実行時のＳ／３９０バイナリコードの解釈、および基礎となるＣＩＳＣプロセッサアーキテクチャにおける違いにより、効率が大幅に失われる。特に、機械コードのいわゆる「ポンピング」または膨張がある。なぜなら、例えば、使用される符号化された数値のバイト順序をビッグエンディアンからリトルエンディアンに変換しなければならず、既存のレジスタのレジスタ幅が異なり、メモリアクセス中に個々のビットをマスクしなければならず、条件の結果を一時的に記憶しなければならず、追加のレジスタをメインメモリの領域にマッピングし、そこから再ロードしなければならないからである。この追加的な研究は、高水準言語における元々のコンピュータプログラムのセマンティクスに起因するのではなく、ソースプラットフォーム上での元々の技術的実装にのみ起因する。これらの効率損失の技術的原因は極めて複雑であり、したがって一般に避けることができない。

その結果、ターゲットプラットフォーム上でＳ／３９０バイナリコードを解釈するには、典型的には、ソースプラットフォーム上でＳ／３９０バイナリコードを実行するよりもはるかに多くのプロセッササイクルを必要とする。追加的に、例えば既知のエラー（「バグ」）を除去するために、この方法でコンピュータプログラムを拡張または維持することはできない。

図１は、Ｓ／３９０バイナリコード２の形式であるコンピュータプログラム１を動作させるための２つの改善されたアプローチを示す。

第１の改善されたアプローチでは、いわゆるジャスト・イン・タイム（ＪＩＴ）トランスレータ３が、実行時にＳ／３９０バイナリコード２の機械命令をターゲットプラットフォームＴＰの機械命令の対応するシーケンスに変換し、変換されたシーケンスを第１のｘ８６バイナリコード４としてキャッシュする。Ｓ／３９０バイナリコード２の同じ機械命令が再度実行された場合、通常、新しい変換は行われない。その代わりに、キャッシュされた第１のｘ８６バイナリコード４の対応する部分が再度実行され、これは、変換労力を大幅に低減し、コンピュータプログラム１の実行を高速化する。

しかしながら、ポンピングの問題もあるため、ターゲットプラットフォームＴＰ上の第１のｘ８６バイナリコード４の実行は、典型的には、ソースプラットフォームＳＰ上のＳ／３９０バイナリコード２の実行よりもかなり多くのプロセッササイクルを必要とする。さらに、このアプローチは、多くの制約を満たすコンピュータプログラム１にのみ適用可能である。このようなコンピュータプログラム１は、良性または英語の用語「ウェル・ビヘイビア」と呼ばれる。例えば、Ｓ／３９０バイナリコード２の変更につながる可能性のある動作が検出された場合、ｘ８６バイナリコード４を破棄しなければならない。キャッシュされたｘ８６バイナリコード４の安全な実行を確実にするために、ＪＩＴトランスレータ３によって合計約３０の条件を監視しなければならない。これらの条件の１つが違反された場合、キャッシュされたｘ８６バイナリコード４は破棄され、元々のＳ／３９０バイナリコード２は上述のように再解釈される。実行時に条件をチェックすると、追加の労力が発生し、生成されたｘ８６バイナリコード４の速度が低下する。追加的に、このようにしてコンピュータプログラム１を拡張または改善することもできない。

第２の改善されたアプローチは、最初に、逆アセンブラ５によってバイナリコード２を、ソースプラットフォームＳＰのためのアセンブラコード６、すなわち、Ｓ／３９０アセンブラプログラムに逆アセンブリし、次に、変換プログラム７、例えば、富士通テクノロジーソリューションズ社のプログラムＡＳＳＴＲＡＮによって、命令ごとにアセンブラコード６を、ターゲットプラットフォームＴＰのためのバイナリコード、例えば、第２のｘ８６バイナリコード８に変換することからなる。とりわけ、このアプローチは、コンピュータプログラム１がターゲットプラットフォームＴＰ上で再度実行されるごとにではなく、分析および変換のための労力が１回しか生じないという利点を有する。Ｓ／３９０バイナリコード２の複雑さに依存して、生成されたｘ８６バイナリコード８のわずかな最適化が、例えばターゲットプラットフォームＴＰのＣＰＵレジスタの使用に関して、個々の場合にも可能である。第１の改善されたアプローチによるＪＩＴ変換と比較して、ジャンプターゲットを各ジャンプ命令に対して新たに判定する必要はない。

しかし、このような変換は、さらに大きな制約の下でのみ可能である。例えば、基本的に、自己修正または自己解釈するコンピュータプログラムでは不可能である。しかし、自己修正バイナリ符号の使用は、Ｓ／３９０アーキテクチャでは非常に一般的であった。さらに、Ｓ／３９０バイナリコード２にデータを埋め込むと、すでに逆アセンブリが成功しない可能性がある。例えば、実際には、第２の改善されたアプローチは、Ｃｏｂｏｌコンパイラによって生成されたコンピュータプログラムに対しては機能しない。さらに、元々のＳ／３９０バイナリコード２のポンピングは、以前として発生する。なぜなら、高水準言語で変換されるコンピュータプログラム１の元々のプログラム論理ではなく、Ｓ／３９０バイナリコード２のプログラム論理のみであるためである。したがって、コンピュータプログラム１の第２のｘ８６バイナリコード８は、典型的には、元々のＳ／３９０バイナリコード２またはそのソースプラットフォームＳＰ上での実行よりも、より広範で、実行が遅い。

本発明は、とりわけ、機械に近い低水準の表現、特にバイナリコードとしてのみ利用可能なコンピュータプログラムのより良い保守および使用の可能性を創出することを目的とする。とりわけ、別のコンピュータプラットフォーム上でこのようなコンピュータプログラムの実行を加速するための可能性が創出される。

この目的は、中間言語によるプログラム論理の表現を生成する方法によって、特許請求の範囲にしたがって解決される。本方法は、
第１のプロセッサアーキテクチャのための低水準プログラミング言語での第１のプログラムコードを捕捉するステップであって、第１のプログラムコードは、プログラム論理を実装し、高水準言語で定義されたプログラム論理をコンパイラでコンパイルすることによって生成されている、捕捉するステップと、
検出された第１のプログラムコードを、コンパイラに特有の少なくとも部分的にパラメータ化されたコードパターンの所定のセットに基づいてコードセクションのシーケンスに分割するステップであって、各コードセクションに対して、対応するパラメータ化されたコードパターンの各パラメータに対する特定のパラメータ値が捕捉され、中間言語の対応する終端記号は、各コードセクションに割り当られる、分割するステップと、
コードセクションのシーケンスに割り当てられた終端記号を、中間言語の文脈自由文法に基づいて中間言語の非終端記号に割り当てるステップであって、割り当てられた非終端記号の全体が、中間言語における第１のプログラムコードの前記プログラム論理を記述する、割り当てるステップと、
中間言語の関連する非終端記号および捕捉されたパラメータ値に基づいて、第１のプロセッサアーキテクチャから独立したプログラム論理の表現を生成するステップと、を含む。

上述のステップにより、低水準プログラミング言語のプログラムコードに基づくコンピュータプログラムのプログラム論理を、第１のプロセッサアーキテクチャのために復元することができる。用語「プログラム論理」は、コンピュータプログラムの意味、すなわち、高水準言語でプログラマによって表わされるデータ処理のためのアルゴリズムを指す。プログラム論理の復元は、とりわけ、第１のプログラムコードを生成するために元々使用されたコンパイラのコードパターンを考慮することによって可能となる。このプロセスにおいて、プログラム論理は、元々使用された高水準言語ではなく、特定の高水準言語または機械アーキテクチャに特有でない中間言語で表現される。

一般に、コンピュータプログラムのソースコードを、コンパイルされたコンピュータプログラムのアセンブリまたはバイナリコードに基づいて高水準言語で復元することはできない。しかし、本発明者らは、アセンブリまたはバイナリコードおよび／またはそれを生成するために使用されるコンパイラおよび／またはそれを生成するために使用されるプログラミング言語が既知であるか、少なくとも格納可能であるならば、少なくともそのプログラム論理を復元することができると認識した。特に、プログラム論理は、コンパイラが、元々高水準言語で符号化されたコンピュータプログラムの特定の要素を符号化するためにどのコードパターンを使用したかが既知であれば、再構成することができる。このようなコードパターンは、例えば、コンパイラのいわゆるコード生成器バックエンドを分析することによって判定することができる。

これらのコードパターンによって、特に、第１のプログラムコードに含まれるパラメータを識別することができる。各コードセクションに特定のパラメータ値を割り当てることにより、特に、異なるループ変数を持つ異なるまたはネストされたプログラムループなどの、異なる変数または式に向けられているが類似するコードパターンを区別することが可能となる。

また、本発明者らは、ＣＯＢＯＬプログラミング言語が、検討したプログラムの約８０％において、メインフレームアーキテクチャのためのコンピュータプログラムをコンパイルするために非常に頻繁に使用され、また、元々のＣＯＢＯＬプログラムコードは、コードの最適化を伴わない少数の線形コンパイラのみを使用することによって、コンピュータプログラムのバイナリコード表現に翻訳されたことを認識した。したがって、使用されるコンパイラの既知の特殊性、特に既知のＣＯＢＯＬコンパイラを考慮に入れると、コンピュータプログラムによって中間言語で実装されるプログラム論理の表現を得ることができる。この表現は、特に、プログラマによって使用される変数名またはコメントなどの、元々プログラミングに使用された高水準言語の完全なソースコードを含まないが、とりわけ、コンピュータプログラムのメンテナンス、および所望のターゲットプラットフォームのための効率的なバイナリコードの自動的な静的生成を許容する。

記述されたような中間言語で所定のプログラム論理の表現を生成することによって、第１のプログラムコードのうち、元々のターゲットプラットフォームに特に特有であるが、新しいターゲットプラットフォームに効率的にマッピングすることができない部分を、実際のプログラム論理から分離することができ、したがって、コンピュータプログラムをターゲットプラットフォームのための効率的なコードに変換することを可能にする。

少なくとも１つの実施形態において、分割するステップにおいて、第１のプログラムコードのコードセクションは、パターンマッチングによって、コンパイラに特有の少なくとも部分的にパラメータ化されたコードパターンの所定のセットと比較される。対応する終端記号は、対応するパラメータ化されたコードパターンの各パラメータに対するパラメータ値の一貫した割り当てが、検査されたコードセクションに対して可能である場合にのみ割り当てられる。このようなパラメータベースのパターンマッチングは、第１のプログラムコードの分析中に起こり得る割り当て間違いを防止する。例えば、それは、所定のコードパターンに対応することがあるが、実際には関係する機能性を満たさず、コンパイラによって生成されなかった機械命令のシーケンスを、コンパイラのコード生成モジュールによって実際に生成された内部的に一貫性のあるパラメータ値を有する同等のシーケンスから区別するために使用することができる。

少なくとも１つの実施形態において、割り当てるステップにおいて、中間言語の非終端記号に少なくとも１つのコンテキスト依存条件が、分割するステップで検出されたパラメータ値に基づいてチェックされ、少なくとも１つのコンテキスト依存条件が、対応するコードセクションの検出されたパラメータ値によって満たされない場合、非終端記号への可能な割り当てが不正確であるとして拒否される。また、個別の終端記号を非終端記号、すなわち、中間言語のより複雑な表現に割り当てるときに、誤った割り当ての可能性を防止するために、割り当てられたパラメータ値を使用することができる。例えば、ループ変数のアップカウンタを、おそらくネストされた多数のプログラムループの正しいプログラムループに割り当てることができる。まとめると、割り当てられたパラメータに依存し、したがって、文脈依存する中間言語の非終端記号の全ての割り当て規則の条件は、プログラム論理の復元において従うべき宣言型規則システムを形成する。中間言語の可能な割り当て規則による割り当ては、対応する条件が、具体的にパラメータ化された非終端記号によって観察される場合にのみ、許容可能である。

少なくとも１つの実施形態において、割り当てるステップにおいて、コードセクションのシーケンスに割り当てられた終端記号のシーケンスは、パーサ、特にボトムアップパーサによって、プログラム論理の階層的表現、特に構文ツリーに変換される。階層的表現の高レベル要素または構文ツリーの内側ノードは、中間言語の非終端記号に対応する。階層的表現の低レベル要素または構文ツリーのリーフは、中間言語の終端記号にのみ対応する。

換言すれば、中間言語の終端記号は高水準言語の原子要素（ａｔｏｍｉｃ ｅｌｅｍｅｎｔ）であり、非終端記号はプログラム構成（ｐｒｏｇｒａｍ ｃｏｎｓｔｒｕｃｔ）、特に複合プログラム構成である。高水準言語のプログラム構成は、例えば、式および条件の評価、プログラムループの動作、およびサブルーチンの呼び出しを含む。

このようなパーサを階層的表現と併せて使用することにより、文法の縮小規則により、より複雑な一般的なプログラム構成に異なる原子要素を単純に割り当てることが可能となる。このような表現は、例えば、中間言語のプログラム構成の文脈自由文法（いわゆるＣｈｏｍｓｋｙ階層におけるタイプ２文法としても知られる）を使用して、ボトムアップパーサ、特にＬＲパーサによって作成することができる。
少なくとも１つの実施形態によれば、ツリー表現のリーフは、分割するステップにおいて捕捉されたパラメータ値が記憶される第１の属性を含む。
少なくとも１つの実施形態によれば、ツリー表現のノードは、捕捉されたパラメータ値から導出されたパラメータ値が、割り当てるステップにおいて記憶される第２の属性を含む。

少なくとも１つの実施形態によれば、中間言語の非終端記号は、ＣＯＢＯＬ、ＦＯＲＴＲＡＮ、Ｓ３、Ａｌｇｏｌ、および／またはＣなどの複数の命令型高級プログラミング言語の特徴である。上記のプログラミング言語の全ては、条件のチェック、プログラムセクションの条件付き実行、算術式の評価、変数への値の割り当て、１つ以上のパラメータ値または参照を任意で渡す別のプログラムセクションへの呼び出し、特にサブルーチンへの呼び出しおよびそれからのリターン、およびプログラムループのトラバーサルなどの同様のプログラム構成を使用する。このようなプログラム構成は、例えば、条件付きジャンプまたは条件付きコードにおけるジャンプを介して、より低いレベルで実現することができる。コンピュータプログラムを作成するために特に一般的に使用されるプログラミング言語の背景知識を利用することによって、探索されたプログラム論理の適切な中間言語への検索を簡素化することができる。

少なくとも１つの実施例では、生成するステップにおいて、第２のプログラムコードが、中間言語の関連する非終端記号に基づいて第２のプロセッサアーキテクチャのための低水準プログラミング言語で生成される。この場合、プログラムステップは、第２のプロセッサアーキテクチャを有するプロセッサ上で第２のプログラムコードが実行されると、高水準言語で定義されたプログラム論理にしたがって実行される。この実施形態は、インテルｘ８６アーキテクチャなどの所与のターゲットプラットフォームのための実行可能コードを自動的に生成するのに特に有用である。

少なくとも１つの実施形態において、第２のプロセッサアーキテクチャのための最適化された第２のプログラムコードは、生成するステップで生成される。中間言語における表現に基づいて、生成されたプログラムコードの最適化は、例えば、ターゲットプラットフォームのために最適化されたデータ型を使用することによって、またはプログラム論理のデータフロー分析に基づいて可能であり、これは、生成された第２のプログラムコードの実行におけるさらなる加速につながる。

上記の目的は、特許請求の範囲による逆コンパイル装置、再コンパイルシステム、およびコンピュータプログラム製品によってさらに解決される。

本発明のさらに有利な実施形態は、実施形態の以下の説明および同封の特許請求の範囲に開示されている。

本発明は、以下、同封の図面に基づく例示的な実施形態によって詳細に説明される。

既知のコード変換方法の概略図である。 本発明によるコード変換方法の概略図である。 プログラム論理の表現を生成するための方法のフローチャートである。 逆コンパイルデバイスおよび再コンパイルシステムの概略図である。 様々なプログラム構成に対するパラメータ化されたトークンの例示的な割り当てである。 様々なプログラム構成に対するパラメータ化されたトークンの例示的な割り当てである。 再構成されたプログラム論理の一部のツリー表現である。

図２は、ソースプロセッサアーキテクチャのバイナリコードをターゲットプロセッサアーキテクチャの対応するバイナリコードに変換するための本発明による方法を概略的に示す。比較可能性を高めるために、再度、図２に、バイナリコードレベルＬ１におけるＳ／３９０のバイナリコード２の第１のｘ８６のバイナリコード４への直接変換、アセンブリコードレベルＬ２における第２のｘ８６のバイナリコード８への間接変換の可能性を示す。追加的に、特に、中間言語レベルＬ４におけるコンピュータプログラム１のプログラム論理ＰＬの表現の生成を含む第３の方法が示される。

例示的な実施形態では、逆コンパイル装置９は、Ｓ／３９０バイナリコード２から直接、中間言語ＩＬで汎用プログラムコード１０を生成する。汎用プログラムコード１０は、プログラム論理ＰＬの形式で、高水準言語レベルＬ５上のコンピュータプログラム１によって定義される意味を記述する。これに使用される手順は、図３のフローチャートを参照して以下に詳細に記述される。代替的には、汎用プログラムコード１０は、分析プログラム１１によって分解されたアセンブリコード６から生成することができる。

中間言語ＩＬにおける汎用プログラムコード１０は、演算式の評価、プログラムループの定義、またはサブルーチンの呼び出しなどの命令型プログラミング言語のグループに典型的なプログラム構成、および変数または定数へのアクセスなどの、それ以上分解することができない個々の原子要素を含む。このようなプログラム構成によって、上記のプログラミング言語に加えて、いくつかのオブジェクト指向プログラミング言語のプログラムを表現することができる。このような中間言語で表現できないのは、純粋な宣言型プログラミング言語のプログラムだけである。

復元されたプログラム論理ＰＬに基づいて、１つ以上のターゲットプラットフォームＴＰのための機械またはアセンブリコードが、好適なコード生成モジュールを使用して生成される。例示的な実施形態では、ＧＮＵコンパイラコレクション（ＧＣＣ）のｘ８６コード生成器１２を使用して、第３の実行可能なｘ８６バイナリコード１３を生成する。その際、使用されるコード生成モジュールは、ターゲットプラットフォームＴＰのプロセッサアーキテクチャの能力を直接考慮する。したがって、追加的なコード最適化レベルＬ３で第３のバイナリコード１３を生成する場合には、コードオプティマイザ１４を任意選択で使用することができ、これは、ターゲットプラットフォームＴＰのプロセッサアーキテクチャの機械命令に、特に効率的な方式で、中間言語ＩＬにおける汎用プログラムコード１０をマッピングする。

図２は、達成可能な性能利得を示す。例えば、ＣＯＢＯＬのような高水準言語におけるコンピュータプログラム１の単一の文は、ソースプラットフォームＳＰ、ここではＳ／３９０の７つの機械命令に変換することができる。ターゲットプラットフォームＴＰの第１のｘ８６バイナリコード４へのＪＩＴ変換は、７つのＳ／３９０命令から２８ｘ８６機械命令をもたらす。同じＳ／３９０バイナリコード２を、変換プログラム７ ＡＳＳＴＲＡＮによって、第２のｘ８６バイナリコード８に変換することはできない。なぜなら、Ｓ／３９０バイナリコード２は、元々ＣＯＢＯＬコンパイラによって生成されたからである。図２に示されているように、Ｓ／３９０バイナリコード２のプログラム論理ＰＬの表現が、まず、中間言語ＩＬにおいて復元され、続いて、ｘ８６コード生成器１２を使用して第３のｘ８６バイナリコード１３に変換される場合、同じ文は、ターゲットアーキテクチャのｘ８６プロセッサの４つの機械命令によってのみ実装することができる。このように、ターゲットプラットフォームＴＰ上のコンピュータプログラム１の実行においてかなりの利得があり、本例では、ＪＩＴ変換器３と比較して７倍である。

図２に示す中間言語レベルＬ４、コード最適化レベルＬ３、およびおそらく基礎となるアセンブリコードレベルＬ２は、現代のコンパイラによって使用されているが、１９５０年代から１９８０年代の多くのコンパイラには存在しなかったことに留意されたい。したがって、ソースプラットフォームＳＰのためのＳ／３９０バイナリコード２の作成のための対応する中間ステップまたはレベルＬ２～Ｌ４は、破線またはハッチング領域によって図２にのみ示され、概念的に理解されるべきである。実際、メインフレームシステムのための多くのコンパイラは、コンピュータプログラム１をＣＯＢＯＬのような高水準言語からターゲットプラットフォームＴＰのバイナリコード、例えばＳ／３９０バイナリコード２に直接変換している。典型的には、コード最適化のない線形コンパイラが使用され、これは、比較的非効率的なバイナリコードを生成した。しかし、このようにして生成されたバイナリコードは、特に分析が容易であり、以下に説明するように、本発明にしたがってそこに符号化されたプログラム論理ＰＬの再構成を単純化する。

以下、ＣＯＢＯＬプログラミング言語で元々作成され、Ｓ／３９０バイナリコード２にコンパイルされたコンピュータプログラム１の、対応するｘ８６バイナリコード１３への「再コンパイル」と呼ばれる変換について説明する。もちろん、本発明は、前述のソースプラットフォームおよびターゲットプラットフォーム、ＣＯＢＯＬプログラミング言語、または後述する中間言語ＩＬのコードパターンおよび記号に限定されない。むしろ、ＩＣＬシリーズ３９、ＩＢＭ Ｓ／３６０またはＳ／３７０、ＦＯＲＴＲＡＮ、Ｓ３、ＡｌｇｏｌまたはＣプログラミング言語および関連コードパターン、および他の文法を有する中間言語のような様々な他のプラットフォームに転送可能である。

図３は、中間言語ＩＬにおけるＳ／３９０バイナリコード２のプログラム論理ＰＬの表現を生成し、その後、この表現に基づいて第３のｘ８６バイナリコード１３を生成するための方法３０のフローチャートを示す。この方法は、図４に概略的に示す再コンパイルシステム４０によって実行される。

再コンパイルシステム４０は、コンピュータシステムのメモリに記憶され、コンピュータシステムのプロセッサによって実行可能なコンピュータプログラムの実行可能なプログラムコードを含む。コンピュータプログラムは、例えば、ソースプラットフォームＳＰ、ターゲットプラットフォームＴＰ、または別のプラットフォームためのコンピュータプログラムであってもよい。コンピュータプログラムはまた、１つ以上のコードブロックが第１のコンピュータシステム上で実行され、１つ以上の他のコードブロックが第２のコンピュータシステム上で実行される分散システム上で実行されてもよい。

方法３０の第１のステップＳ１では、Ｓ／３９０バイナリコード２に含まれる機械コード４１と、必要に応じてＳ／３９０バイナリコード２に含まれる追加のいわゆるインラインデータとが取得される。Ｓ／３９０バイナリコード２は、元々、コンピュータプログラム１を高水準ＣＯＢＯＬ言語でコンパイルすることによって生成された。しかし、ＣＯＢＯＬのソースコードは使用できなくなっている。

例示的な実施形態では、アドレスオフセット値ｘ８０００は、まず、アーカイブファイルにおける機械コード部分の第１の命令の開始アドレスとして指定される。このアドレスでは、実際の機械コード４１は、Ｓ／３９０バイナリコード２内で開始する。Ｓ／３９０バイナリコード２は、個々のバイトのシーケンスに分解され、いわゆるバイトストリーム４２として逆コンパイルデバイス９に利用可能とされる。

第２の方法ステップＳ２では、捕捉されたＳ／３９０バイナリコード２は、正式な中間言語ＩＬの対応する終端記号ＴＳを有するコードパターンＣＭのリストに分割される。この場合、中間言語ＩＬの終端記号ＴＳに割り当てられたコードパターンＣＭは、本質的に、Ｓ／３９０バイナリコード２を生成するために使用されるコンパイラ、例えば、ＣＯＢＯＬコンパイラのコードパターンに対応する。このようなコードパターンＣＭの一例は、特定のアドレスに記憶された変数の値にアクセスするための、または定数値を有するレジスタをロードするための機械命令のシーケンスである。

この分割では、現在のＳ／３９０バイナリコードにおける実際の機械コード４１が、認識されなければならない。特に、機械命令がＳ／３９０バイナリコード２において位置する場所が判定されなくてはならない。これらは、Ｓ／３９０バイナリコード２に含まれる他のデータ、いわゆるインラインデータと区別されなければならない。

このような分析は、通常、バイナリコードが逆アセンブル可能である場合に可能である。このためには、コンピュータプログラム１の開始アドレスと、ソースプラットフォームＳＰのプロセッサの命令セットとが知られていなければならず、特に、個々の機械命令が有する長さが知られていなければならない。これは、典型的には、各機械命令を実行するために必要とされるパラメータの数によって与えられ、したがって、既知のコンピュータプラットフォームに対して文書化される。

既存のバイナリコードが機械命令のシーケンスであると仮定される古典的な逆アセンブリとは対照的に、バイナリコードを生成するために使用されたコンパイラが、例えば大きな定数を記憶するために、特定のパターンにしたがってインラインデータを生成されたバイナリコードに挿入した場合には、説明した逆コンパイルデバイス９における機械命令の認識も可能である。使用されるコンパイラの既知のコードパターンを考慮することによって、バイナリコードに含まれる任意のインラインデータの位置および範囲を推論することが可能である。例えば、実行時に特定のプログラム部品の通過を制御するために、既知のコードパターンによって生成された場合には、必要に応じて、自己修正バイナリコードでさえも分析することができる。コンパイラによって使用されるパターンが既知であれば、機械命令がバイナリコード２のどこに含まれるかを判定することができ、したがって、それらを他のデータから分離することができる。

ステップＳ２の実装のために、元々使用されたコンパイラに典型的な複数のコードパターンＣＭが、第１のサブステップＳ２．１において提供される。提供されたコードパターンＣＭの全体は、Ｓ／３９０バイナリコード２を中間言語ＩＬの終端記号ＴＳに逆コンパイルするための文法に対応する。これらのコードパターンＣＭの少なくともいくつかは、変化しない形式でＳ／３９０バイナリコードにおいて必ずしも発生しないが、それ自体、数値、メモリアドレス、またはレジスタなどの少なくとも１つのパラメータによって特徴付けられる。インラインデータは、コードパターンで定義することもできる。パターン照合器は、そのようなパラメータ化されたコードパターンＣＭを認識するのに特に好適ある。

典型的には、各コンパイラは、ＣＯＢＯＬなどの高水準言語の入力側コンピュータプログラム１から、低水準プログラミング言語の出力側コンパイルされたコード、特にバイナリコードまたはアセンブリコードを生成するために、コード発生器と多数の所定のコードパターンＣＭを使用する。以下に説明するプログラム論理ＰＬの復元は、これらのコードパターンＣＭの分析または知識に基づく。

例示的な実施形態では、個々のコードパターンＣＭに含まれるパラメータの定義を含む、使用されるコードパターンＣＭは、「トークン」という名前でテキストファイル４３において指定される。そこに含まれるコードパターンＣＭは、パターンパーサ４４によって逆コンパイル装置９に読み込まれる。

コードパターンＣＭは、コンパイラのいわゆるコード生成器バックエンドを分析することによって提供することができ、高水準言語の既知の原子要素を実装するために使用される機械コード・シーケンスはパターンとして提供される。高水準言語の原子要素は、例えば、定数値および変数内容の検索または割り当てを含む。代替的には、好ましくは高水準言語のソースコードと低水準プログラミング言語のコンパイルされたコードの両方が利用可能である既知のコンピュータプログラム１を分析することによって対応するパターンを判定することも可能である。この手順は、コンパイラ自体のソースコードがもはや使用できない場合に特に有用である。

使用されるコンパイラの複雑さに応じて、多数の異なるコードパターンＣＭを使用することができる。比較的古いＣＯＢＯＬコンパイラの説明された例示的な実施形態では、多数のテストプログラムを、分析によって判定された３７のコードパターンＣＭで首尾よく逆コンパイルすることができた。しかし、特に、これらがコンパイラのコード生成モジュールから自動的に導出できる場合には、より多数のコードパターンＣＭを考慮することも可能である。

説明された例示的な実施形態では、コードパターンＣＭは、個々の変数または配列にアクセスするためのコードパターン、Ｓ／３９０プラットフォーム上で典型的な二進化十進数（ＢＣＤ）処理のための値を割り当てるためのコードパターン、条件付きおよび無条件のジャンプ、並びに対応するリターンを含むが、これらに限定されない。

続いて、ステップＳ１で生成されたＳ／３９０バイナリコード２のバイトストリーム４２が、ステップＳ２．１で検出されたコードパターンＣＭと比較され、中間言語ＩＬの関連する終端記号ＴＳを判定する。例示的な実施形態では、パターン認識スキャナを実装するいわゆる照合器４５が、この目的のために使用される。例示的な実施形態では、照合器４５は、バイトストリーム４２の所定の開始アドレスで可能なコードパターンの割り当てを開始する。原理的には、照合器４５自体は、サブステップＳ２．２に従う第１の実行において、コンピュータプログラム１において具体的に使用され、パラメータ化されたコードパターンＣＭのシーケンスを判定するアセンブラのように機能する。第１の実行では、個々のコードパターンＣＭの限界、したがって、その中に含まれるジャンプ命令のジャンプターゲットは、まだ既知ではない。したがって、第１の実行では、対応するジャンプラベルのみが生成されるが、パラメータ化されたコードパターンＣＭの出力は生成されない。

次の第２の実行では、サブステップＳ２において、コンピュータプログラム１で具体的に使用され、おそらくパラメータ化されるコードパターンＣＭのシーケンスが、第１の実行で生成されたジャンプラベルに基づいて生成される。照合器４５の出力として、対応する適切にパラメータ化されたトークン４６が、各割り当てられたコードパターンＣＭに対して出力され、このトークン４６は、コードパターンＣＭのインスタンスの具体的な出現を、Ｓ／３９０バイナリコード２の関連するパラメータで表す。

入力バイトストリーム４２の各部はコードパターンＣＭに割り当てられる。例示的な実施形態では、使用されるコードパターンＣＭの大部分はパラメータ化可能である。これにより、コンピュータプログラム１で使用される具体的にパラメータ化されたトークン４６の出力ストリームをもたらし、各トークンは中間言語ＩＬの終端記号ＴＳに対応する。

照合器４５の動作は、ＢＣＤ番号として符号化されたインデックス変数にアクセスするための名前「ＡＲＲＡＹ＿ＢＣＤＩＤＸ」を有するコードパターンに基づいて以下に説明する。以下に示すコードパターンＡＲＲＡＹ＿ＢＣＤＩＤＸは、パターンパーサ４４によって読み取られ、合計９つのパラメータａ、ｂ、ｏ、ｌ、ｔ、ｒ、ｔ１、ｔ２およびｌ２によってパラメータ化される。これは、本質的に、オペランドが上述のパラメータによって定義されるＳ／３９０機械コマンドのシーケンスを含む。ここで、第２の列に表現されている対応する機械命令（例えば１６進数Ｆ２ｈ）のアセンブリ言語のいわゆるニーモニック（例えば、ＰＡＣＫ）を有する第１の列は、より良く理解するためだけのものである。照合器４５は、Ｓ／３９０バイナリコード２から直接、それぞれの機械命令の１６進値をサーチする。

例示的な実施形態では、山括弧内の表現は、コードパターンＣＭのパラメータ、または固定値を有するパラメータの組み合わせのいずれかである。バイナリコードにおける個々のパラメータの長さは、例示的な実施形態において、それらの命名によって暗黙的に指定されるが、当然ながら、明示的に指定することもできる。

これおよび他のコードパターンＣＭは、パターンパーサ４４によってテキストファイル４３から読み込まれ、可能なコードパターンＣＭを有するアレイにおいて解析され、記憶される。パターンパーサ４４自体は、トップダウン・パーサとして、例えば、再帰的降下パーサとして実装され、実施形態の例では、数百のコードパターンＣＭをサポートする。もちろん、コードパターンＣＭを定義するために、他のパーサまたは構成メカニズムを使用することもできる。

Ｓ／３９０バイナリコード２の入力バイトストリーム４２が所定のコードパターンＣＭの１つに対応する場合、対応するコードパターンＣＭが複製され、割り当てられたコードパターンに含まれるパラメータに対するバイトストリーム４２の具体的なパラメータ値が複製されたコードパターンＣＭに記憶される。したがって、コードパターンの定数値とパラメータ値を考慮しなければならない。あるパラメータがコードパターンＣＭ中に数回発生する場合、対応するコードパターンＣＭは、その中に含まれる全てのパラメータの一貫した割り当てが可能である場合にのみ割り当てられる。山括弧内の式は、照合器４５によって評価され、バイトストリーム４２の対応する位置の値と比較される。したがって、パラメータの割り当ては、宣言型コードパターンＣＭの解を表す。

例えば、ＡＲＲＡＹ＿ＢＣＤＩＤＸでは、パラメータｔ１を合計５回使用する。これらの場所の各々では、コードパターンＡＲＲＡＹ＿ＢＣＤＩＤＸを割り当て可能となるには、ｔ１と同じ値、または式ｔ１＋７－ｌ２と式ｔ１＋７のパラメータ値ｔ１から導出された値がバイナリコードになければならない。別の例として、第２の行の機械コード４１では、機械命令コードＤ７（．ＸＣ）の後のバイトストリーム４２の第１のバイトが、第１の機械命令Ｆ２（．ＰＡＣＫ）の第１のオペランドとしてバイトストリーム４２から読み込まれた値をｌ２のパラメータ値として用いて、式７－ｌ２－１の結果のバイナリ表現に続く４つのゼロビット（１６進数０ｈに対応する）に対応するかどうかをチェックしなければならない。さらに、第３のオペランドの値が第２のオペランドの値に対応するかどうかがチェックされる。なぜなら、これらの２つのオペランドが、コードパターンＡＲＲＡＹ＿ＢＣＤＩＤＸにおける同じパラメータｔ１などに対応すべきであるためである。

一貫した割り当てができない場合、最初にチェックされたものとは別のコードパターンＣＭを使用しなければならないことがある。一貫した割り当てがまったく可能でない場合、入力Ｓ／３９０バイナリコード２は、コードパターンまたは対応するパラメータ化されたトークンに分割することができず、したがって、首尾よく逆コンパイルすることができない。この場合、手順３０はエラーで終了する。これは特に、Ｓ／３９０バイナリコード２がコードパターンＣＭの定義のために分析されたコンパイラによって生成されたのではなく、別のコンパイラによって、またはアセンブラプログラムから直接生成された場合に当てはまる。

説明された実施形態では、照合器４５は、既知のＣＯＢＯＬコンパイラによって生成されたＳ／３９０バイナリコード２が、典型的には、固定コードパターンを使用する単一の線形コード生成プロセスにおいて生成されるという事実を利用する。したがって、逆に、Ｓ／３９０バイナリコード２は、単一パスにおいて対応するコードパターンＣＭに再割り当てすることもできる。したがって、元々ＣＯＢＯＬでプログラミングされたコンピュータプログラムのＳ／３９０バイナリコード２に対する固有の割り当ては、通常、照合器４５によって可能である。

方法３０のステップＳ３では、照合器４５によってコードパターンＣＭの１つに首尾よく割り当てられた中間言語ＩＬの終端記号ＴＳに対応するパラメータ化されたトークン４６が、中間言語ＩＬの非終端記号ＮＴＳに対応する所定のプログラム構成に割り当てられる。割り当ては、２組の別個の規則を満たさなければならない。一方では、１つ以上のトークン４６の縮小は、中間言語ＩＬの文脈自由文法の変換ルールまたは構成を満たさなければならない。他方、関与するパラメータ化されたトークン４６のパラメータは、それぞれの構成規則について与えられた宣言型規則に準拠しなければならない。宣言型規則によって、割り当ての文脈依存が確立される。割り当てが許容される場合、生成された非終端記号には、中間言語ＩＬの関与する終端記号ＴＳに割り当てられたパラメータ値が渡される。

言語理論では、形式言語は４タプルＧ ＝ （ＮＴＳ、ＴＳ、Ｓ、Ｐ） として表現される文法Ｇで定義される。ここでは、ＮＴＳは、非終端記号のアルファベットを記述し、ＴＳは、終端記号ＴＳのアルファベットを記述し、Ｓは、開始記号を記述し、Ｐは、非終端記号ＮＴＳの１つ以上の終端記号ＴＳまたは非終端記号ＮＴＳへの変換を記述する変換規則または生成のセットを記述する。

中間言語ＩＬは、自己完結型の文脈依存言語であり、その非終端ＮＴＳおよび生成Ｐは、コンピュータプログラム１をプログラミングするために使用される高水準言語に特有のものではなく、アセンブリまたはバイナリコード表現でコンパイルすることによって生成されるコンピュータプログラムの全クラスに適用することができる。

上述した逆コンパイルデバイス９では、ボトムアップまたはアップワードパーサの特殊な形態であるいわゆるＬＲパーサ４７が、照合器４５によって既に認識された終端記号ＴＳを、中間言語ＩＬの合成非終端記号ＮＴＳに割り当てるか、または縮小するタスクを引き継ぐ。文脈自由文法のための既知のパーサとは対照的に、割り当てられる非終端記号ＮＴＳの文脈依存がここで利用される。

個々の非終端記号の文脈は、宣言型規則を使用して、末端記号ＴＳに関連するパラメータ値をチェックすることに基づいて縮小するステップにおいて、例示的な実施形態においてチェックされる。例えば、非終端記号ＮＴＳの定義は、異なる終端記号ＴＳまたは非終端記号ＮＴＳを、カウント変数でプログラムループを実行するような、より高レベルの非終端記号ＮＴＳに縮小するために、どのパラメータが、照合器４５によって認識されるコードパターンＣＭのパラメータと一致しなければならないかを指定することができる。説明された例示的な実施形態では、チェックされるべきルールは、ＬＲパーサ４７のプログラムコードにおいて固定的に実装される。代替的には、起動時に構成ファイルの形式でパーサ４７にチェックされるべきルールを読み取ることもできる。

パラメータ化されたトークン４６または終端記号ＴＳおよび中間言語ＩＬの文法のプログラム構成または非終端記号ＮＴＳから形成された構文ツリーは、元々のコンピュータプログラム１の下にあるプログラム論理ＰＬを全体として表す。構文ツリーのルートは文法の開始記号Ｓに対応し、そこから完全なプログラム論理ＰＬを導出することができる。換言すれば、各具体的なコンピュータプログラム１に対して、中間言語ＩＬの単語に対応する構文ツリーが存在する。

ステップＳ３の実装のために、ＬＲパーサ４７は、第１のサブステップＳ３．１において、関連する変換ルールＰにしたがって、以前に判定されたトークン４６および／または既に首尾よく割り当てられた非終端記号ＮＴＳを置き換えるのに適していると思われる中間言語ＩＬの文法Ｇにしたがって、非終端記号ＮＴＳを選択する。そうすることで、ＬＲパーサ４７は、照合器４５によって提供されるトークン４６のシーケンスと、中間言語ＩＬの現在選択されている非終端記号ＮＴＳとの間の一致を可能な限り長く見つけようと試みる。

次のサブステップＳ３．２では、サブステップＳ３．１で割り当てられたトークン４６のパラメータが、選択された非終端記号ＮＴＳの宣言型規則または関連する生成規則に対応するかどうかがチェックされる。あてはまる場合、適用可能なプログラム構成が判定される。

そうでなければ、ＬＲパーサ４７は、サブステップＳ３．１にジャンプして戻り、別の可能な非終端記号ＮＴＳに変換することができる記号の別のシーケンスを見つけようとする。次に、関与するトークン４６のパラメータの割り当ては、最後に、首尾よい割り当てが見つかるか、または、非終端記号ＮＴＳが文法の規則にしたがって首尾よく割り当てられないために、手順がエラーで終了するまで、サブステップＳ３．２で再度チェックされる。

サブステップＳ３．１およびＳ３．２は、記号のシーケンスが文法の開始記号Ｓに遡るまで再帰的に繰り返され、これは、コンピュータプログラム１のプログラム論理ＰＬに記号的に対応する。これが可能であれば、コンピュータプログラム１を逆コンパイルすることができる。そうでなければ、コンピュータプログラム１は逆コンパイル可能ではなく、方法３０はエラーで終了する。

以下では、ＬＲパーサ４７の動作が、例によってさらに説明される。この目的のために、図５Ａおよび図５Ｂは、矢印によって、トークン４６のシーケンスにしたがって、パラメータ化された終端記号ＴＳへの非終端記号ＮＴＳの割り当てのチェックの２つの例を図表で示す。矢印は、関与する終端記号ＴＳのパラメータへの依存性を示す。

図５Ａによる例では、５つの対応するパラメータ化されたコードパターンＢＡＳＥ、ＡＲＲＡＹ＿ＬＶＡＬ、ＡＲＲＡＹ＿ＢＣＤ＿ＩＤＸ、ＢＣＤ＿ＣＯＰＹのシーケンスに対応する合計５つのパラメータ化されたトークン４６が、プログラム構成要素「ｐａｒａｍｅｔｅｒ ａｒｒａｙ ａｓｓｉｇｎ」に割り当てられる。ここで、第１の条件Ｃ１によれば、第１のパラメータ化されたコードパターンＢＡＳＥの第１のパラメータｂの値が、パラメータ化されたコードパターンＡＲＲＡＹ＿ＬＶＡＬの第２のパラメータｂの値と一致しなければならない。同様に、パラメータ化されたコードパターンＡＲＲＡＹ＿ＬＶＡＬの第１のパラメータａの値が、第２の条件Ｃ２によるパラメータ化されたコードパターンＡＲＲＡＹ＿ＢＣＤＩＤＸの第１のパラメータａの値と一致しなければならない。ここで、「ａ ＝ ０ｘ５ ｐａｒｌｉｓｔ－ｆ２＿ｏ＿０００［］」という表現は、オフセット０を有するパラメータリストがアドレス０ｘ５でレジスタａに記憶されることを意味する。

これらの依存関係は、ＬＲパーサ４７によって検証されるものとする。同様に、パラメータ化されたコードパターンＡＲＲＡＹ＿ＢＣＤＩＤＸの第１のパラメータａによるマッピングは、パラメータ化されたコードパターンＢＣＤ＿ＣＯＰＹの第１のパラメータｂ１と一致しなければならず、第２のパラメータ化されたコードパターンＢＡＳＥの第１のパラメータｂによるマッピングは、パラメータ化されたコードパターンＢＣＤ＿ＣＯＰＹの第３のパラメータｂ２と一致しなければならない（図５Ａにおいて破線で示されている）。

図５Ｂは、２つの値の追加に関する第２のプログラム構成要素に対する依存関係を同様に示す。ここでも、ＬＲパーサ４７が、示された４つのパラメータ化されたトークン４６または対応するコードパターンをプログラム構成要素「追加」に首尾よく割り当てることができるように、宣言型規則の形式で定義された境界条件が観察されなければならない。

図５Ｂの例では、とりわけ、２つの条件Ｃ１およびＣ２がチェックされる。関連する規則の宣言的および帰属的部分は、文法Ｇの低減規則の追加条件として表現することができる。以下、それぞれの条件を、対応する縮小規則の後に二重角括弧で示す：

＄＄、＄１などの記号を持つ上記の構文は、Ｙａｃｃ／Ｂｉｓｏｎプロジェクトから知られている構文に適合され、ここで、＄＄は、低減された非終端記号を表し、＄１および＄２は、それぞれ構成規則の第１および第２のコンポーネントを表し、ドット演算子は、割り当てられるか検索される中間言語ＩＬのそれぞれの終端または非終端要素の属性を表す。

方法３０の次のステップＳ４では、元々のコンピュータプログラム１のプログラム論理ＰＬの階層的表現４８が、中間言語ＩＬの割り当てられたプログラム構成に基づいて生成される。この表現は、異なる目的に役立つことができ、したがって、非常に異なるものとすることができる。

第１の変形例Ｓ４．１によれば、図６に示すように、中間言語ＩＬの非終端記号ＮＴＳおよび終端記号ＴＳの構文ツリー６０を出力することができる。図６は、図５Ｂの例からの追加式の構文ツリー６０を効果的に示す。図６に見られるように、トップレベルの追加は、割り当て式６１に対応する。代入式６１の手段によって、より低いレベルの追加式６２の結果が、選択された変数６３に割り当てられる。追加式６２は、さらに別の式６４と定数６５からなる。さらなる表現６４は、従属因子６６を表し、これは、今度はコードパターンＢＣＤ＿ＰＡＣＫの形態の変数呼び出し６７を含む。

図６に見られるように、式６１、６２および６４ならびに因子６６は、中間言語ＩＬの非終端記号ＮＴＳによって具体化される。割り当てられた変数６３、定数６５、および変数呼び出し６７は、ＢＣＤ変数をアンパックするためのパラメータ化されたコードパターンＢＣＤ＿ＵＮＰＡＣＫ、定数を追加するためのＢＣＤ＿ＡＤＤ＿ＣＯＮＳＴ、およびＢＣＤ変数をパックするためのＢＣＤ＿ＰＡＣＫに対応する終端記号ＴＳによって具体化される。

このような構文ツリー６０は、中間言語ＩＬの終端記号ＴＳおよび非終端記号ＮＴＳへの個々のパラメータの割り当てをチェックする際に特に有用である。

例示的な実施形態では、ＬＲパーサ４７は、いわゆるＬＡＬＲ（１）文法（ルックアヘッドＬＲパーサ文法）によって、トークン４６のリストから中間言語ＩＬにおけるプログラム論理ＰＬの対応部分の表現を生成する。これは、例において、図５Ｂに示される追加式のための構文ツリー６０として図６に抜粋して示されるように、コンピュータプログラム１の階層的表現４８を効果的に生成する。明瞭にするために図６には示されていないが、完全なプログラム論理ＰＬの階層的表現４８は、中間言語ＩＬの開始記号Ｓに対応するルート要素プログラムを有し、それから元々のコンピュータプログラム１のプログラム論理ＰＬ全体を導出することができる。

第２の変形例Ｓ４．２によれば、認識されたプログラム構成および認識されたパラメータの擬似コード表現が出力され得る。このような表現は、コンピュータプログラム１の元々のソースコードが失われているが、元々のコンピュータプログラム１のエラーが訂正されるか、または変更された要件にしたがってコンピュータプログラム１がさらに開発される場合に特に有用である。プログラマは、このような表現を使用して、コンピュータプログラム１がどの機能ブロックを通過するかを見ることができ、したがって、合理的な労力によって個々のパラメータの意味を取り戻すことができる。換言すれば、このような表現は、元々のソースコードがもはや利用可能ではない、特に、いわゆるレガシーコードである、文書化されていない、または十分に文書化されていないコンピュータプログラム１を維持する上で特に有用である。

有利な実施形態によれば、任意選択のサブステップＳ４．３において、中間言語ＩＬにおけるプログラム論理ＰＬは、ターゲットプラットフォームＴＰのための低水準プログラミング言語、特にアセンブリまたは機械コードのプログラムコードに変換される。この目的のために、例示的な実施形態では、ステップＳ４．１で生成されたプログラム論理ＰＬの階層的表現４８を解析し、それをスクリーン出力または時間記録のような任意のランタイムライブラリなしでｘ８６プロセッサのためのバイナリまたはアセンブラコード５０に変換するｘ８６コード生成器１２が使用される。もちろん、他の自動コード生成方法も適用してもよい。このような変換は、ｘ８６プロセッサのような所与のターゲットプラットフォームＴＰ上のコンピュータプログラム１の効率的な実行を可能にする。

中間言語ＩＬにおけるプログラム論理ＰＬの表現、例えば、プログラム論理の完全な構文ツリー６０に基づいて、ターゲットプラットフォームＴＰのためのバイナリまたはアセンブリコード５０を生成することは、比較的容易である。最適化が実行されない場合、バイナリまたはアセンブリコード５０は、中間言語ＩＬにおけるプログラム論理ＰＬの階層的表現４８の個々の要素によって直接生成することができる。例えば、バイナリまたはアセンブリコード５０は、そのルート要素から開始する構文ツリー６０を再帰的に解析することによって出力されてもよい。

このようにして生成されたアセンブリコード５０に基づいて、必要に応じて、アセンブリコード５０を備えるか、または含む標準ライブラリまたはさらなるプログラム部品を含め、ターゲットプラットフォームＴＰのための完全に実行可能なアセンブリプログラム５１は生成することができる。アセンブリコード５０またはアセンブリプログラム５１は、アセンブラ５２を用いてそれ自体公知の方法でインテルｘ８６プロセッサのための実行可能なコード５３に変換することができる。

好ましくは、所与のターゲットプラットフォームＴＰのためのさらなる最適化は、アセンブリコード５０または対応するバイナリコードの生成前または生成中に行われてもよい。例えば、本実施形態では、ｘ８６プラットフォーム上で実行するために最適化されたアセンブリコード５０を生成するために、コードオプティマイザ１４が使用されてもよい。

例えば、個々のプログラム構成において使用されるパラメータの実際の意図は、中間言語ＩＬの表現において認識することができる。これに基づいて、元々使用されたコンパイラによって使用されたデータフォーマットが、意図されたターゲットプラットフォームＴＰに必要かつ好適であり、最適であるかどうかを分析することができる。ＣＯＢＯＬコンピュータプログラム１の記載例において、調査中のＣＯＢＯＬコンパイラは、しばしば、非常に少数の数値を符号化するために、いわゆるＢＣＤ変数を使用する。また、元々のＳ／３９０プラットフォームは、ＢＣＤ変数の処理に非常に優れたテクニカルサポートを提供するため、ＢＣＤ変数は、例えば、配列の個々の値にアクセスするためのインデックスとしても使用される。対照的に、ｘ８６プラットフォームは、ＢＣＤ変数を効率的で直接的なサポートはほとんど提供しない。したがって、インデックス変数の許容値は、基本的には、損失なしで２進数として表現することができる符号なし整数であるため、ＢＣＤ変数の形式でインデックスによって配列のエントリにアクセスすることは、技術的な観点からは必要とされない比較的複雑な動作である。したがって、出力アセンブリコード５０を最適化するために、変数が、中間言語ＩＬの認識された構成に基づくインデックス変数であることを認識し、ターゲットプラットフォームＴＰの要件にしたがってそのデータ型を変更することが可能である。

具体的には、ＢＣＤ変数の値が小数点以下第１９位以下であり、ＳＲＰ （Ｓｈｉｆｔ ａｎｄ Ｒｏｕｎｄ Ｐａｃｋｅｄ ＢＣＤ）命令がＢＣＤ番号を丸めるためにそれに適用されず、変数が配列インデックスにアクセスするために使用される場合、またはデータフロー分析により、それがループ変数または帰納変数として使用されることが判明した場合、再コンパイルシステムは、自動的に４０のＢＣＤ変数を６４ビット長整数変数に自動的に置き換える。上記の場合、ソースプラットフォームＳＰで元々使用されていたデータ型を、ターゲットプラットフォームＴＰのための異なるデータ型に置き換えても、精度の損失はもたらさない。換言すれば、プログラム論理ＰＬは同じままである。しかし、代用として使用される６４ビット長整数変数は、ｘ８６プロセッサによってはるかに高速に処理することができる。

図５Ｂおよび図６による例では、ＢＣＤ変数を再フォーマットするためのＳ／３９０に特有の機械コードは、実行される全体的な追加の意味には無関係であり、したがって、ターゲットプラットフォームＴＰの対応する機械コードにマッピングされる必要はない。したがって、ターゲットプラットフォームＴＰのための効率的な機械コードを生成することができる。図６は、図５Ｂによる例について、対応する、自動的に生成されるｘ８６アセンブラコードフラグメント６８を示す。

他の可能な最適化は、ローカル変数とグローバル変数との間の区別、サブ関数の呼び出し、プロローグ、エピローグまたは手続きの個々のセクション（またはバケット）、条件付きジャンプ、基本レジスタのロードに関するものであり、これらは、プログラム論理ＰＬを変更することなく、ターゲットプラットフォームＺＰの対応する機械コマンドによって置き換えることができる。

１ コンピュータプログラム、２ Ｓ／３９０バイナリコード、３ ＪＩＴトランスレータ、４ 第１のｘ８６バイナリコード、５ 逆アセンブラ、６ （逆アセンブルされた）アセンブラコード、７ 変換プログラム、８ 第２のｘ８６バイナリコード、９ 逆コンパイラ、１０ 汎用プログラムコード、１１ 分析プログラム、１２ ｘ８６コード生成器、１３ 第３のｘ８６バイナリコード、１４ コードオプティマイザ、３０ 方法、４０ 再コンパイルシステム、４１ 機械コード、４２ バイトストリーム、４３ テキストファイル、４４ サンプルパーサ、４５ トークン、４７ ＬＲパーサ、４８ （プログラム論理の）階層的表現、５０ アセンブラコード（ターゲットプラットフォーム用）、５１ 実行可能なアセンブラプログラム、５２ アセンブラ、５３ 実行可能なコード（ターゲットプラットフォーム用）、６０ 構文ツリー、６１ 割り当て式、６２ 追加式、６３ 変数割り当て、６４ さらなる式、６５ 定数、６６ 因子、６７ 変数検索、６８ アセンブラコードフラグメント、Ｌ１ バイナリコードレベル、Ｌ２ アセンブラコードレベル、Ｌ３ コード最適化レベル、Ｌ４ 中間言語レベル、Ｌ５ 高言語レベル、ＣＭ コードパターン、ＩＬ 中間言語、ＳＰ ソースプラットフォーム、ＴＰ ターゲットプラットフォーム、ＰＬ プログラム論理、ＴＳ 終端記号、ＮＴＳ 非終端記号

Claims (11)

1. 中間言語におけるプログラム論理の表現を生成するための方法であって、
   第１のプロセッサアーキテクチャのための低水準プログラミング言語での第１のプログラムコードを捕捉するステップであって、前記第１のプログラムコードは、プログラム論理を実装し、高水準言語で定義された前記プログラム論理をコンパイラでコンパイルすることによって生成されている、捕捉するステップと、
   前記捕捉された第１のプログラムコードを、前記コンパイラに特有の少なくとも部分的にパラメータ化されたコードパターンの所定のセットに基づいてコードセクションのシーケンスに分割するステップであって、前記コードパターンは、前記コンパイラが前記高水準言語の既知の原子要素を前記第１のプログラムコードにおいて実装するために使用されており、各コードセクションに対して、対応するパラメータ化されたコードパターンの各パラメータに対する特定のパラメータ値が捕捉され、前記中間言語の終端記号は、各コードセクションに割り当られる、分割するステップと、
   前記コードセクションのシーケンスに割り当てられた前記終端記号を、前記中間言語の文脈自由文法に基づいて前記中間言語の非終端記号に割り当てるステップであって、前記割り当てられた非終端記号の全体が、前記中間言語における前記第１のプログラムコードの前記プログラム論理を記述する、割り当てるステップと、
   前記中間言語の前記割り当てられた非終端記号および前記捕捉されたパラメータ値に基づいて、前記第１のプロセッサアーキテクチャから独立した前記プログラム論理の表現を生成するステップと、を含む、方法。
2. 前記分割するステップにおいて、前記第１のプログラムコードの前記コードセクションは、パターンマッチングによって、前記コンパイラに特有の少なくとも部分的にパラメータ化されたコードパターンの前記所定のセットと比較され、検査されたコードセクションに対して、対応するパラメータ化されたコードパターンの各パラメータに対するパラメータ値の一貫した割り当てが可能である場合にのみ、対応する終端記号が割り当てられる、請求項１に記載の方法。
3. 前記割り当てるステップにおいて、前記中間言語の非終端記号に少なくとも１つのコンテキスト依存条件が、前記分割するステップで捕捉された前記パラメータ値に基づいてチェックされ、前記少なくとも１つのコンテキスト依存条件が、前記対応するコードセクションの前記捕捉されたパラメータ値によって満たされない場合、前記非終端記号への可能な割り当てが不正確であるとして拒否される、請求項１または２に記載の方法。
4. 前記割り当てステップにおいて、前記コードセクションのシーケンスに割り当てられた終端記号のシーケンスが、パーサ、特にボトムアップパーサによって、前記プログラム論理の階層的表現に変換され、前記階層的表現の上位要素は、前記中間言語の前記非終端記号に対応し、前記階層的表現の下位要素は、前記中間言語の前記終端記号にのみ対応する、請求項１～３のいずれか一項に記載の方法。
5. 前記生成するステップにおいて、第２のプログラムコードが、前記中間言語の関連する前記非終端記号に基づいて第２のプロセッサアーキテクチャのための低水準プログラミング言語で生成され、前記第２のプロセッサアーキテクチャを有するプロセッサ上で前記第２のプログラムコードを実行すると、プログラムステップが、前記高水準言語で定義された前記プログラム論理にしたがって実行される、請求項１～４のいずれか一項に記載の方法。
6. 逆コンパイル装置であって、
   第１のプロセッサアーキテクチャのプロセッサのために捕捉された第１のプログラムコードを、少なくとも部分的にパラメータ化されたコードパターンの所定のセットに基づいてコードセクションのシーケンスに分割するための照合器であって、前記第１のプログラムコードは、プログラム論理を実装し、コンパイラによって高水準言語で定義されたコンピュータプログラムをコンパイルすることによって生成されており、前記コードパターンは、前記コンパイラが前記高水準言語の既知の原子要素を前記第１のプログラムコードにおいて実装するために使用されており、前記照合器は、対応するパラメータ化されたコードパターンの各パラメータに対して各コードセクションの特定のパラメータ値について捕捉し、各コードセクションに中間言語の終端記号を割り当てる、照合器と、
   前記コードセクションのシーケンスに割り当てられた終端記号のシーケンスを前記中間言語の非終端記号に縮小するためのパーサ、特にボトムアップパーサであって、縮小によって前記パーサによって生成された前記非終端記号の全体が、前記中間言語における前記コンピュータプログラムの前記プログラム論理を記述する、パーサと、を含む、逆コンパイル装置。
7. 前記照合器が、さらに、前記第１のプロセッサアーキテクチャのためのバイナリコードまたはアセンブリコードを捕捉し、そこに含まれる前記第１のプログラムコードの機械コードを抽出するように適合された、請求項６に記載の逆コンパイル装置。
8. 前記パーサは、非終端記号に縮小するときに、少なくとも１つの文脈条件とのコンプライアンスをチェックし、前記少なくとも１つの文脈条件が、前記対応するコードセクションの前記捕捉されたパラメータ値によって満たされない場合、前記非終端記号への可能な縮小を不正確として拒否するように適合された、請求項６または７に記載の逆コンパイル装置。
9. 前記少なくとも部分的にパラメータ化されたコードパターンの所定のセットの定義を有する少なくとも１つのテキストファイル内で読み取るためのパターンパーサをさらに含む、請求項６～８のいずれか一項に記載の逆コンパイル装置。
10. 請求項６～９のいずれか一項に記載の逆コンパイル装置と、前記中間言語で表現された前記プログラム論理を、第２のプロセッサアーキテクチャのための前記コンピュータプログラムに対応する機械コードに変換するための少なくとも１つのコード生成装置と、を含む、再コンパイルシステム。
11. コンピュータシステムのプロセッサに、
    第１のプロセッサアーキテクチャのプロセッサのための捕捉された第１のプログラムコードを、少なくとも部分的にパラメータ化されたコードパターンの所定のセットに基づいてコードセクションのシーケンスに分割するステップであって、前記第１のプログラムコードは、プログラム論理を実装し、コンパイラによって高水準言語で定義されたコンピュータプログラムをコンパイルすることによって生成されており、前記コードパターンは、前記コンパイラが前記高水準言語の既知の原子要素を前記第１のプログラムコードにおいて実装するために使用されており、対応するパラメータ化されたコードパターンの各パラメータに対する特定のパラメータ値が、各コードセクションに対する前記分割中に捕捉され、中間言語の終端記号が、各コードセクションに割り当てられる、分割するステップと、
    前記コードセクションの分割されたシーケンスに割り当てられた前記終端記号を、前記中間言語の文脈自由文法に基づいて前記中間言語の非終端記号に割り当てるステップであって、前記割り当てられた非終端記号の全体が、前記中間言語で前記コンピュータプログラムの前記プログラム論理を記述する、割り当てるステップと、を実行させるためのプログラムコード。
    

Images