バイナリ変換

実行ファイル全体を対象のアーキテクチャ用に変換することを「静的」なバイナリ変換と呼ぶ。変換プログラムが全てのコードを静的に検出することが難しいため、静的なバイナリ変換を正しく行うことは困難である。たとえば実行ファイルの一部は、実行時にしかジャンプ先を特定できない間接ジャンプ（英語版）によってのみ到達できる。「動的」なバイナリ変換では、通常基本ブロック単位の短いコード列に着目し、変換した後出力結果をキャッシュしておく。コード変換は、コードが検出されて変換可能になると実施され、分岐命令の分岐先は変換後のコードを示すようにする。

動的なバイナリ変換は単純なエミュレーションとは異なりコード変換の時間がオーバーヘッドになるが、性能上の大きなボトルネックとなるエミュレータの読み出し-デコード-実行というループが存在しない。変換のオーバーヘッドは変換したコードが複数回実行されれば相殺される。

高度な動的変換プログラムは動的再コンパイル（英語版）を採用しており、どの部分が実行時間の大部分を占めているか計測可能なようコードを変換し、そうした部分は積極的に最適化される。この技術はジャストインタイムコンパイラを彷彿とさせるものだが、実際こうしたコンパイラ（例 : サン・マイクロシステムズのHotSpot技術）は仮想マシンの命令セット（バイトコード）から実際のマシンの命令セットへの動的なバイナリ変換プログラムと捉えることができる。

• Appleは、 M68Kのコードを動的に変換するエミュレータを同社のPowerPC版Macintosh製品向けに開発し、非常に高い安定性と性能、互換性（Mac 68Kエミュレータ参照）を実現した。これによりアップルは、一部のバイナリのみがネイティブという状態でオペレーティングシステム (OS) を出荷し、エンドユーザーはこれまでのソフトウェアへの投資を失うことなく新しい高速なアーキテクチャを採用することができた。エミュレータが非常にうまくいったこともあり、OSの一部もエミュレーションで動作しつづけ、68K用コードを含まないOSへの移行は2001年のMac OS Xのリリースまで行われず、さらにMac OS XではPowerPC版MacintoshにおいてMac OS 9のエミュレーションが行える「クラシック」環境を提供していた。またMac OS X v10.4では、インテルチップを搭載したMacintosh用にRosetta変換レイヤーが提供され、PowerPCからx86への移行を容易なものにした。これも動的なバイナリ変換の一例である。 RosettaはTransitive Corporationによって開発されたもので、PowerPC、MIPS、Itanium、x86などのプラットフォーム間の動的変換に用いられる同社のQuickTransit（英語版）技術のアップル向けの実装である。
• DECはユーザーがCISCのVAXアーキテクチャをDEC Alpha RISCアーキテクチャに移行する手助けとなる変換ツールで、同様の成功を収めた。
• また、DECはx86用のアプリケーションをDEC Alphaのアプリケーションに変換するFX!32（英語版）バイナリ変換プログラムを開発した。
• 2006年3月、インテルはTransitive Binary Translatorを将来のItaniumとXeon CPUでサポートする計画を発表した。
• サン・マイクロシステムズ、IBM、SGIはそれぞれ ^[1] TransitiveのQuickTransitを採用している。 サンの場合にはSPARC→x86、IBM の場合にはx86→Powerアーキテクチャ（英語版）、SGIの場合にはMIPS→Itanium2に変換を行う。
• 2000年、トランスメタはCrusoeと称する革新的なプロセッサ設計を発表した。トランスメタWebサイトの FAQ によれば（以下訳）、「このマイクロプロセッサはハードウェアのVLIWコアとCode Morphingソフトウェアと呼ばれるソフトウェア層をエンジンとして備えています。 Code Morphingソフトウェアはシェルのように働き（中略）、 x86の命令をCrusoeのネイティブ命令に変換します。さらに、Code Morphingソフトウェアは動的コンパイルとコード最適化を行い（中略）最小の消費電力で性能を向上させます（中略）これにより、膨大な数のアプリケーションに影響を与えることなく、トランスメタはVLIWとCode Morphingソフトウェアを改良し続けることができるのです。」 arstechnica、 geek.comにも情報がある。