私はエミュレータが何をしているのか理解しています。ある機械語を別のものに変更します。しばしば「ジャストインタイム」です。このようなプログラムは、あるアーキテクチャ用に書かれたバイナリを読み込んで、別のアーキテクチャ用の新しいバイナリを保存するという点で、組み込み可能でしょうか？プロセスが完了すると、指定されたアーキテクチャ上でネイティブ実行のためのバイナリの準備が整います。これは、レガシーアーキテクチャのために高価な専用アプリケーションを持つ人にとって特に有用です。エミュレーションをリアルタイムで実行する必要があるのはなぜですか？
このようなアプリケーションを作成することはできますか？バイナリ再コンパイルは新しいコンセプトではありませんが、私はまだそのようなインプリメンテーションを見つけていません。
他の人の助けを借りて、そうしたプログラミングが可能ならば、そのようなプログラムのオープンソースの実装についてコーディングを開始することには喜んでいます。
これを使用して参照ライブラリが再コンパイルされていることを確認することから始めなければなりません。
これは可能ですが、大きな仕事です。
これを行うことでライセンスの問題があるかもしれないと考えてください。元のソフトウェアに基づいて派生物を作成しています。これを可能にするほとんどのライセンスは、ソースを持つこともできるので、単にコンパイルし直すか、ソースを移植することができます。これは簡単です。
これはリバースエンジニアリングとして正確にはカウントされませんでしたか？私はそのような獣を作って、ちょうど裁判所に何らかの先例があるようにしたいと思う。 有用なアプリケーションは、OS X Mountain Lion上でクローズドソースPPCバイナリを実行することです。必要なlibの多くはOSにあり、Snow LeopardやLionから移植することができます。もう1つはコンソールエミュレーションで、ほとんどのlibがゲームに含まれています。 – user1483857
実際には、あなたの再コンパイラは "read-> translate->新しいバージョンを書く"ということになります。これはリバースエンジニアリングよりも派生物のようなものです。リバースエンジニアリングは**それが何をしているのかを理解し、同じことをする新しいコードを書くことです。 – WhyNotHugo
有用なアプリケーションは、OS X Mountain Lion上でクローズドソースPPCバイナリを実行することです。そこには、必要なlibの多くがOSに入っているか、Snow LeopardやLionから移植することができます。もう1つはコンソールエミュレーションで、ほとんどのlibがゲームに含まれています。 私は法的なトラブルに遭遇しますか？ – user1483857
私は静的対動的再コンパイルを探していると思います。動的再コンパイルは、「リアルタイム」エミュレーションまたは再分類と呼ばれるものです。コードはブロック単位で再コンパイルされ、エミュレータは元のコードの実行時環境を正確に反映することができます。
静的な再コンパイルが可能かどうかを確認します。非常に特定の実行時制約が必要なコードは、静的な再コンパイル後に正常に実行されないことがあります。このため、静的な再コンパイルを使用したN64エミュレータのCornは、手作業で最適化された非常に少数のゲームしか実行できず、動的再コンパイルを使用する他のN64エミュレータでは、
さらに複雑で伝統的なコード（つまりx86からPowerPC）では静的再コンパイルが可能ですが、再コンパイラは生成された静的コードを実行するために多くのトリックを使わなければならないため、このような作業は非常に面倒です。ターゲットマシン上で確実に実行できます。動的再コンパイラーは、開発作業のわずかな部分で実行時にこれを行うことができ、パフォーマンスにはほとんど問題ありません。
また、異なるアーキテクチャでの浮動小数点実装の違いがあるとは思いますが、わかりません。 –
スタティック再コンパイルは、バイナリを外部アーキテクチャから別のターゲットアーキテクチャに変換する有望な方法です。ジャストインタイム（JIT）より高速です。なぜなら、実行する直前にコードをコンパイルする必要がなく、生成するコードを最適化するために余分なコンパイル時間が必要になるからです。
しかし、JITコンパイルは動的プログラム解析を使用し、静的再コンパイルは静的プログラム解析（したがって名前）に依存します。
静的解析では、実行時の実行時情報がありません。
これに関する大きな問題は間接ジャンプによって引き起こされます。この用語は、特定のswitch文から生成される可能性のあるコード、関数ポインタの使用、または実行時の多型（think virtual table）からのコードを対象としています。 それはすべての形式の命令に沸く：
JMP reg_A
reg_Aの内容は静的にはわかりません。 したがって、次の命令のアドレスはわかりません。動的再コンパイルでは、レジスタの仮想状態をエミュレートするため、この問題は発生しません。現在の内容は
reg_Aです。さらに、静的な再コンパイルでは、すべての可能なパスをコンパイルする必要があるため、
reg_Aのすべてのの可能な値をこの時点で見つけることに興味があります。動的解析では、現在実行中のパスを生成するために現在の値のみを必要とします。
reg_Aはその値を変更する必要がありますが、他のパスを生成することはできます。 場合によっては、静的解析で候補リストを見つけることができます（
switchの場合は、どこかにオフセットの可能性のあるテーブルが必要です）が、一般的にはわかりません。
ファインと言うと、は、バイナリ内のすべての手順を再コンパイルしましょう。
ここでの問題は、ほとんどのバイナリでコードとデータの両方が含まれていることです。 アーキテクチャによっては、どちらがどちらであるかを判断できない場合があります。
いくつかのアーキテクチャでは、配置制約と可変幅命令がなく、ある時点で逆アセンブルを開始し、オフセットを使って再コンパイルを開始したことを発見することができます。
のは2つの命令と単一レジスタAを備えた単純化された命令セットを見てみましょう：
41 xx (size 2): Add xx to `A`.
42 (size 1): Increment `A` by one.
のは、以下のバイナリプログラムを見てみましょう：
41 42
はのは、開始点は、最初のバイト41あるとしましょう。 あなたは実行します。
41 42 (size 2): Add 42 to `A`.
しかし、どのような41の場合は、データの一部はありますか？次に、あなたのプログラムは次のようになります。
42 (size 1): Increment `A` by one.
この問題は、多くの場合、アセンブリで直接最適化、およびプログラマは意図的expect some byte to be interpreted as both code and data, depending on the context!
さらに悪いことかもしれないし、古いゲーム、に拡大され、再コンパイルプログラムを生成することができコード自体！ JITコンパイラの再コンパイルを想像してみてください。その結果、ソース・アーキテクチャー用のコードが出力され、そのファイルにジャンプしようとします。プログラムがすぐに終了する原因になります。実行時にのみ利用できるコードを静的に再コンパイルするには、無限のトリッキーが必要です！
スタティックバイナリ分析は、（主にセキュリティの分野で、ソースが利用できないシステムの脆弱性を探すための）研究の非常に活発な分野であり、実際にはNES emulator that tries to statically recompile programsを生成しようとしています。 記事は非常に興味深いです。
JITと静的再コンパイルの間の妥協点は、静的に変換できないビットのみを保持してできるだけ多くのコードを静的に再コンパイルすることです。
大きな説明。私は静的/動的再コンパイル - 動的に再コンパイルされたコードチャンクの（ファイルへの）キャッシュ間の別の可能な妥協案について言及したいと思います。おそらく、このアプローチは、実行時分析の「コード・パス発見」能力によって強化された静的再コンパイルの利点の多くを享受するでしょう。 – Cauterite
数回行っています。たとえば、DECのFX！32はx86バイナリを再コンパイルして、DEC Alpha上で動作します。 DECの（誤った）管理を補うだけでは不十分であり、Compaq/HPはそれについてはあまり気にしなかった。 –
エミュレータはなぜそうなのですか？これは本当にエミュレータを書くよりもはるかに難しいことですか？ – user1483857