CPUエミュレーションが遅い理由[クローズ]

異なるCPU（IA-32、ARM9など）の操作は、本質的に同等（データの移動、読み取り、書き込みなど）である必要があります。異なるCPUが互いにエミュレートするのはそれほど苦痛ではありません。しかし、エミュレートされたソフトウェアの実行が遅すぎるため、それほど簡単ではないようです。実行可能ファイルを単純に変換してから実行できますか？とにかくリソースに依存する理由（他のCPUをエミュレートするために強力なCPUが必要な理由）低レベルの大きなプログラミングスキルはありません。どうもありがとう。

まず、非常によく似た命令は確かにありますが、異なるCPUアーキテクチャで常に同じように動作する命令のセットがあるわけではありません。正確なエミュレーションのためには、各命令を変換するのに（通常）十分ではありません-メモリアクセス、タイミング、割り込みを処理する必要があります...それはCPUのためだけです。

あなたが考えているのは静的再コンパイルであるように見えますが、それは非常に難しいです（実際、それは理論的には不可能になる停止問題に要約されると思います）。実際には、プログラムのサブセットに対して行うこともありますが、あるアーキテクチャのオブジェクトコードを入力として受け取り、別のアーキテクチャの完全に同等のコードを出力する汎用コンパイラを作成することはできません。たとえば、この方法を使用して自己変更コードを処理するのは困難です。

動的な再コンパイル（プログラムの実行中にオンザフライでコードを生成する）の方が成功します（正しく実行するのはまだ簡単ではありません）。ただし、特定の問題はアーキテクチャによって異なります。多くの場合、CPUをエミュレートすることは問題ではありませんが、正確なタイミングを維持しながら、さまざまな周辺機器をエミュレートすることが問題になります（たとえば、SNESのエミュレートに関するbyuuの記事を参照）。

これらの制約の多くを無視して、ソフトウェアのサブセットを動作させるのに十分なハードウェアをエミュレートすることもできますが、実際のハードウェアがない限り、オーバーヘッドがゼロで100％の精度を実現することは不可能です（私の知る限り）。

異なるCPU（IA-32、ARM9など）の操作は、本質的に同等（データの移動、読み取り、書き込みなど）である必要があります。

あるべきですが、そうではありません。CPUアーキテクチャは、設計者が想定した方法に従ってこれらの基本操作を実装します。これは、設計者が何を達成しようとしているかによって大きく異なる場合があります。一部のCPUの1つの命令で実行される処理には、他のCPUで非常に多くの命令が必要になる場合があります。

実行可能ファイルを単純に変換してから実行できますか？とにかくリソースに依存する理由（他のCPUをエミュレートするために強力なCPUが必要な理由）

CPUをエミュレートするだけであれば、比較的簡単に実行できます。その場で実行可能ファイルを「変換」することは「動的再適合」と呼ばれ、多くのエミュレーターはすでにそれを行っています。ただし、通常は、プラットフォーム全体をエミュレートする必要があります。これには、CPU以外のハードウェアが含まれ、そのハードウェアのエミュレートが困難な場合（Atari 2600 TIAなど）または文書化が不十分な場合（NES PPUビデオハードウェア、または現在のGPUハードウェア）があります。CPUは常にプラットフォームのコンテキストで機能し、通常ソフトウェアはCPU +プラットフォームが特定の方法で動作することを期待します。プラットフォームをエミュレートするための要件、および頻繁に必要とされる厳しいタイミング要件でエミュレートするための要件は、ハードでリソースを大量に消費する部分です。