バイナリ翻訳

コンピューティングにおいて、バイナリ変換はバイナリ再コンパイルの一形態であり、命令のシーケンスがソース命令セットからターゲット命令セットに変換されます。命令セットシミュレーションなどの一部のケースでは、ターゲット命令セットがソース命令セットと同じである場合があり、命令トレース、条件付きブレークポイント、ホットスポット検出などのテストおよびデバッグ機能が提供されます。

バイナリ変換には、静的と動的の 2 つの主な種類があります。変換は、ハードウェア ( CPU内の回路など) またはソフトウェア (ランタイムエンジン、静的再コンパイラー、エミュレーターなど) で実行できます。

モチベーション

バイナリ変換は、ターゲットプラットフォーム用のバイナリが不足している、ターゲットプラットフォーム用にコンパイルするソースコードが不足している、またはターゲットプラットフォーム用にソースをコンパイルするのが難しいなどの理由で行われます。

静的に再コンパイルされたバイナリは、エミュレーションのオーバーヘッドが削除されるため、それぞれのエミュレートされたバイナリよりも高速に実行される可能性があります。これは、一般的な解釈されたプログラムとコンパイルされたプログラムのパフォーマンスの違いに似ています。

静的バイナリ変換

静的バイナリ変換を使用するトランスレータは、動的バイナリ変換のように最初にコードを実行することなく、実行可能ファイルのすべてのコードをターゲットアーキテクチャで実行されるコードに変換することを目的としています。トランスレータがすべてのコードを検出できるわけではないため、これを正しく行うことは非常に困難です。たとえば、実行可能ファイルの一部は、実行時にのみ値がわかる間接分岐を介してのみ到達できる場合があります。

そのような静的バイナリトランスレータの1つは、ユニバーサルスーパーオプティマイザピープホールテクノロジ（スタンフォード大学のSorav BansalとAlex Aikenによって開発）を使用して、多数のソースとターゲットのペア間で効率的な変換を実行し、開発コストを大幅に削減し、ターゲットバイナリの高性能を実現します。PowerPCからx86への変換の実験では、一部のバイナリはネイティブバージョンよりも優れたパフォーマンスを発揮しましたが、平均ではネイティブの3分の2の速度で実行されました。^[1]

静的バイナリ変換の例

ハネウェルは、ハネウェル200シリーズのコンピュータ用にLiberatorと呼ばれるプログラムを提供しました。これは、IBM 1400シリーズのコンピュータ用のプログラムをハネウェル200シリーズのプログラムに変換することができました。^[2]

2014年には、 1998年のビデオゲームStarCraftのARMアーキテクチャバージョンが、オリジナルのx86バージョンの静的再コンパイルと追加のリバースエンジニアリングによって生成されました。 ^[3]^[4] Pandoraハンドヘルドコミュニティは、必要なツール^[5]を独自に開発し、そのような変換を数回成功させることができました。^[6]^[7]

例えば、2014年にはビデオゲームCube Worldの手続き型地形ジェネレーターに対して、 x86からx64への静的再コンパイルが成功しました^。[8]

もう一つの例としては、2013年にLLVMを使用して生成された、ビデオゲーム「スーパーマリオブラザーズ」のNESからx86への静的再コンパイルバージョンがあります^。[9]

2004年、任天堂のスコット・エリオットとフィリップ・R・ハッチンソンは、ゲームボーイのバイナリから「C」コードを生成するツールを開発しました。このコードは新しいプラットフォーム用にコンパイルされ、航空会社のエンターテイメントシステムで使用するためのハードウェアライブラリにリンクされました。^[10]

1995年にベルコミュニケーションズリサーチのノーマン・ラムゼイとプリンストン大学コンピュータサイエンス学部のメアリー・F・フェルナンデスは、静的アセンブリ変換のための基本ツールを備えたニュージャージーマシンコードツールキットを開発しました。 ^[11]

動的バイナリ変換

動的バイナリ変換 (DBT) は、短いコードシーケンス (通常は 1 つの基本ブロック程度) を調べ、それを変換して結果のシーケンスをキャッシュします。コードは、検出された時点で可能な場合にのみ変換され、分岐命令は、すでに変換されて保存されているコードを指すように作成されます (メモ化)。

動的バイナリ変換は単純なエミュレーションとは異なり (エミュレータの主な読み取り、デコード、実行のループ (大きなパフォーマンスのボトルネック) が排除されます)、変換時に大きなオーバーヘッドが発生します。このオーバーヘッドは、変換されたコードシーケンスが複数回実行されるため、おそらく解消されます。

より高度な動的トランスレータは、動的再コンパイルを採用しています。動的再コンパイルでは、変換されたコードが計測され、どの部分が多数回実行されるかが調べられ、これらの部分が積極的に最適化されます。この技術はJIT コンパイラを彷彿とさせますが、実際にこのようなコンパイラ (例: SunのHotSpotテクノロジ) は、仮想命令セット (バイトコード)から実際の命令セットへの動的トランスレータと見なすことができます。

ソフトウェアにおける動的バイナリ変換の例

Apple Computerは、PowerPC MacintoshシリーズにM68Kコードの動的変換エミュレータを実装し^[12]、非常に高いレベルの信頼性、パフォーマンス、互換性を実現しました（Mac 68Kエミュレータを参照）。これにより、Appleは部分的にネイティブなオペレーティングシステムのみを搭載したマシンを市場に投入することができ、エンドユーザーはソフトウェアへの投資を危険にさらすことなく、新しい高速アーキテクチャを採用することができました。エミュレータが非常に成功したため、オペレーティングシステムの多くの部分はエミュレートされたままでした。PowerPCネイティブオペレーティングシステム（OS）への完全な移行は、2001年に Mac OS X （10.0）がリリースされるまで行われませんでした（Mac OS Xの「クラシック」ランタイム環境は、Mac OS X 10.5までPowerPC Macでこのエミュレーション機能を提供し続けました）。
Intel ベースの Mac 用のMac OS X 10.4.4では、Apple の PPC ベースのハードウェアから x86 への移行を容易にするために、Rosetta動的変換レイヤーが導入されました。Transitive Corporationによって Apple 向けに開発された Rosetta ソフトウェアは、Transitive のQuickTransitソリューションの実装です。
QuickTransit は、製品の寿命期間中、SPARC → x86、x86 → PowerPC、およびMIPS → Itanium 2への変換サポートも提供していました。
DEC は、ユーザーがCISC VAXアーキテクチャからAlpha RISCアーキテクチャに移行するのを支援する変換ツールで同様の成功を収めました。^{[引用が必要]}
HP ARIES (Automatic Re-translation and Integrated Environment Simulation) は、高速コード解釈と 2 フェーズの動的変換を組み合わせたソフトウェア^{[13]動的バイナリ変換システムであり、}HP-UX 11i for HPE Integrity Servers上でHP 9000 HP-UXアプリケーションを透過的かつ正確に実行します。^[14] ARIES 高速インタープリタは、ユーザーの介入なしに、特権のないPA-RISC命令の完全なセットをエミュレートします。解釈中は、アプリケーションの実行パターンを監視し、頻繁に実行されるコードのみを実行時にネイティブItaniumコードに変換します。ARIES は、2 フェーズの動的変換を実装します。これは、第 1 フェーズで変換されたコードが実行時プロファイル情報を収集する手法で、この情報は第 2 フェーズの変換で使用され、変換されたコードをさらに最適化します。ARIES は、動的に変換されたコードをコードキャッシュと呼ばれるメモリバッファに格納します。変換された基本ブロックへのさらなる参照は、コードキャッシュ内で直接実行され、追加の解釈や変換は必要ありません。変換されたコードブロックのターゲットは、ほとんどの場合コードキャッシュ内で実行されるようにバックパッチされます。エミュレーションの最後に、ARIES は元のアプリケーションを変更せずに、変換されたすべてのコードを破棄します。ARIES エミュレーションエンジンは、HP 9000 HP-UXアプリケーションのシステムコール、シグナル配信、例外管理、スレッド管理、デバッグ用の HP GDBのエミュレーション、およびアプリケーションのコアファイル作成をエミュレートする環境エミュレーションも実装します。
DECはx86アプリケーションをAlphaアプリケーションに変換するためのFX!32バイナリトランスレータを開発した。 ^[12]
Sun MicrosystemsのWabiソフトウェアには、x86 命令から SPARC 命令への動的な変換が含まれていました。
2000年1月、トランスメタ社はCrusoeという新しいプロセッサ設計を発表しました。^[15]^[16]同社のウェブサイトのFAQ ^[17]によると、
スマートマイクロプロセッサは、エンジンとしてのハードウェアVLIWコアと、コードモーフィングソフトウェアと呼ばれるソフトウェアレイヤーで構成されています。コードモーフィングソフトウェアはシェルとして機能し […]、x86命令をネイティブの Crusoe 命令にモーフィングまたは変換します。さらに、コードモーフィングソフトウェアには、動的コンパイラとコードオプティマイザーが含まれています […] その結果、最小限の電力でパフォーマンスが向上します。 […] [これにより] Transmeta は、膨大なソフトウェアアプリケーションベースに影響を与えることなく、VLIW ハードウェアとコードモーフィングソフトウェアを個別に進化させることができます。
Intel社は、Itaniumベースのシステムで IA-32 アプリケーションをサポートするために設計された動的バイナリトランスレータであるIA-32 実行層を開発および実装しました。これは、 Itaniumアーキテクチャ用のMicrosoft Windows Serverや、Red HatやSuseなどのいくつかのLinuxフレーバーに含まれていました。これにより、IA-32 アプリケーションは、Itanium プロセッサのネイティブ IA-32 モードを使用する場合よりも高速に実行できるようになりました。
Dolphin ( GameCube / Wiiのエミュレーター) は、PowerPC コードを x86 および AArch64 に JIT 再コンパイルします。
Microsoft Virtual PC は、 32 ビットゲストオペレーティングシステムのバイナリ変換をサポートしています。
VMware Workstation 12 以前では、32 ビットゲストオペレーティングシステムのバイナリ変換がサポートされていることが知られています。

ハードウェアにおける動的バイナリ変換の例

Nvidia Tegra K1 Denver は、低速のハードウェアデコーダーを介してARM命令をネイティブマイクロコード命令に変換し、ホットコードにはソフトウェアバイナリトランスレータを使用します。 ^{[引用が必要]}

参照

参考文献

^ Bansal, Sorav; Aiken, Alex (2008 年 12 月)。「ピープホールスーパーオプティマイザーを使用したバイナリ変換」(PDF)。オペレーティングシステムの設計と実装に関する第 8 回 USENIX 会議の議事録。pp. 177– 192。
^ Honeywellシリーズ 200 概要説明(PDF)。Honeywell。1966年 2 月。11 ページ。たとえば、シリーズ 200 プロセッサの命令レパートリーは、IBM 1400 シリーズなど、他のいくつかの処理システムの命令レパートリーと十分に類似しているため、これらの競合システム用に作成されたプログラムを、より高性能なシリーズ 200 システムでの実行に適した形式に自動的に 1 回だけ変換できます。
^ ピーター・シュタインレヒナー (2014-03-10)。「Starcraft für ARM-Handheld kompiliert」 (ドイツ語)。ゴーレムで。2014 年 3 月 25 日に取得。
^ notaz (2014-03-04). 「StarCraft」. repo.openpandora.org . 2014年3月26日閲覧。
^ notaz (2014-03-01). 「ia32rtools/」. GitHub . 2015年1月9日閲覧。
^ notaz (2014-03-04). 「Starcraft」. openpandora.org . 2014-03-29取得。「ソースがなければ移植もできない」というルールは完全には当てはまりません。静的再コンパイルによって、似たようなもの (ただし同じではない) を移植として得ることができます。同様のことは、M-HT によって DOS ゲーム向けに何度か行われました。このゲームは、似たようなアプローチで Android 用にも変換されました。
^ M-HT. 「Warcraft: Orcs & Humans」. repo.openpandora.org.
^ Kærlev, Mathias (2014-04-14). 「実用的でポータブルな X86 再コンパイル」。2014-08-08に取得。しかし、その後、元の x86 マシンコードを何らかの方法で使用しようというアイデアが浮かびました。しかし、私たちのオープンサーバーでは、x86-64 もサポートする必要があり、その場合、エミュレーションまたは再コンパイルが絶対に必要になります。 […] アセンブラへの静的再コンパイルははるかに優れたオプションのように思えますが、移植性を維持するには、x86、x86-64、場合によっては ARM/PowerPC 用のバックエンドを作成する必要があります。
^ Kelley, Andrew (2013-07-07). 「LLVM と Go を使用して NES ゲームをネイティブ実行ファイルに静的に再コンパイルする」。2013-08-08に取得。この記事では、Nintendo Entertainment System ゲームを静的に逆アセンブルしてネイティブ実行ファイルに再コンパイルする可能性に関する独自の研究を紹介します。
^ US 7765539、Elliott、Scott、Hutchinson、Phillip、「ビデオゲームをトランスコンパイルするためのシステムおよび方法」、2010年発行
^ Ramsey, Norman; Fernandez, Mary F. (1995)。「The New Jersey Machine-Code Toolkit」。TCON'95 Proceedings of the USENIX 1995 Technical Conference Proceedings。USENIX Association Berkeley、カリフォルニア州、米国。p. 24。
^ ab Wharton, John Harrison (1994-08-01). 「業界のパイオニア、Gary Kildall が 52 歳で死去: 最初のマイクロコンピュータ言語、ディスクオペレーティングシステムを作成」Microprocessor Report . 8 (10). MicroDesign Resources Inc. (MDR). 2016-11-18にオリジナルからアーカイブ。2016-11-18に取得。 […] 皮肉なことに、 Garyが開拓した技術の多くは、10 年後の現在、再発見されています。AppleとDEC は、バイナリ再コンパイルを、既存のソフトウェアをPowerPCまたはAlphaアーキテクチャに移植するための「新しい」技術として宣伝しています。実際、DRI は1980 年代初頭に8080から8086 へのバイナリ再コンパイラを導入しました。 […]
^ カールソン、ジム、ハック、ジェリー (2003)。Itanium の台頭: ムーアの計算能力の第二法則の突破。プレンティスホールPTR。ISBN 978-0-13046415-6. 2015年1月9日閲覧。
^ 「HP ARIES Dynamic Binary Translator」。HP 。 2015年1月10日時点のオリジナルよりアーカイブ。2015年1月9日閲覧。
^ ストークス、ジョン。「トランスメタ・クルーソーの探究」。Ars Technica 。2015年1月9日閲覧。
^ Hughes, Rob (2000-01-20). 「Transmeta の Crusoe マイクロプロセッサ」. geek.com . 2007-09-27 時点のオリジナルよりアーカイブ。
^ 「 Transmeta Crusoe プロセッサのよくある質問 FAQ」。Transmeta . 2007 年。2007 年 1 月 10 日時点のオリジナルよりアーカイブ。

さらに読む

Haber, Gadi (2010). 「バイナリ変換入門」(PDF) . Intel . 2016-03-09 にオリジナル(PDF)からアーカイブ。2014-03-30に取得。
Bansal, Sorav; Aiken, Alex (2008 年 12 月)。「ピープホールスーパーオプティマイザーを使用したバイナリ変換」。コンピューターサイエンスおよびエンジニアリング学部。インド工科大学デリー校。2014年 3 月 30 日閲覧。
Baraz, Leonid; Devor, Tevi; Etzion, Orna; Goldenberg, Shalom; Skaletsky, Alex; Wang, Yun; Zemach, Yigal (2003)。「IA-32 実行層: Itanium ベースのシステムで IA-32 アプリケーションをサポートするように設計された 2 フェーズの動的トランスレータ」。第 36 回 IEEE/ACM 国際マイクロアーキテクチャシンポジウムの議事録。MICRO 36。ワシントン DC、米国: IEEE コンピュータ協会。pp. 191– 。ISBN 978-0-7695-2043-8。
Toal, Graham. 「エミュレータ作成者の静的バイナリ変換の HOWTO」
チャーノフ、アントン。ヘルデグ、マーク。フックウェイ、レイ。リーブ、クリス。ルービン、ノーマン。タイ、トニー。ヤダヴァリ、S. バラドワジ。ジョン・イェーツ (1998)。「FX!32: プロファイル指向のバイナリトランスレータ」。IEEEマイクロ. 18 (2): 56–64 .土井:10.1109/40.671403。ISSN 0272-1732。
Souza, Maxwell; Nicácio, Daniel; Araújo, Guido (2010-06-23) [2010-06-19]. ISAMAP: 動的変換による命令マッピング。コンピュータアーキテクチャ - ISCA 2010 国際ワークショップ。サンマロ、フランス。pp. 117– 。ISBN 9783642243226。
Chen, Yu-hsin (2009-06-20) [2009-06-18]. 「仮想化のための x86-32 コードから x86-64 コードへの動的バイナリ変換」(PDF) .マサチューセッツ工科大学.

[1] Bansal, Sorav; Aiken, Alex (2008 年 12 月)。「ピープホールスーパーオプティマイザーを使用したバイナリ変換」(PDF)。オペレーティングシステムの設計と実装に関する第 8 回 USENIX 会議の議事録。pp. 177– 192。

[2] Honeywellシリーズ 200 概要説明(PDF)。Honeywell。1966年 2 月。11 ページ。たとえば、シリーズ 200 プロセッサの命令レパートリーは、IBM 1400 シリーズなど、他のいくつかの処理システムの命令レパートリーと十分に類似しているため、これらの競合システム用に作成されたプログラムを、より高性能なシリーズ 200 システムでの実行に適した形式に自動的に 1 回だけ変換できます。

[3] ピーター・シュタインレヒナー (2014-03-10)。「Starcraft für ARM-Handheld kompiliert」 (ドイツ語)。ゴーレムで。2014 年 3 月 25 日に取得。

[4] taz (2014-03-04). 「StarCraft」. repo.openpandora.org . 2014年3月26日閲覧。

[5] taz (2014-03-01). 「ia32rtools/」. GitHub . 2015年1月9日閲覧。

[6] taz (2014-03-04). 「Starcraft」. openpandora.org . 2014-03-29取得。「ソースがなければ移植もできない」というルールは完全には当てはまりません。静的再コンパイルによって、似たようなもの (ただし同じではない) を移植として得ることができます。同様のことは、M-HT によって DOS ゲーム向けに何度か行われました。このゲームは、似たようなアプローチで Android 用にも変換されました。

[7] M-HT. 「Warcraft: Orcs & Humans」. repo.openpandora.org.

[8] Kærlev, Mathias (2014-04-14). 「実用的でポータブルな X86 再コンパイル」。2014-08-08に取得。しかし、その後、元の x86 マシンコードを何らかの方法で使用しようというアイデアが浮かびました。しかし、私たちのオープンサーバーでは、x86-64 もサポートする必要があり、その場合、エミュレーションまたは再コンパイルが絶対に必要になります。 […] アセンブラへの静的再コンパイルははるかに優れたオプションのように思えますが、移植性を維持するには、x86、x86-64、場合によっては ARM/PowerPC 用のバックエンドを作成する必要があります。

[9] Kelley, Andrew (2013-07-07). 「LLVM と Go を使用して NES ゲームをネイティブ実行ファイルに静的に再コンパイルする」。2013-08-08に取得。この記事では、Nintendo Entertainment System ゲームを静的に逆アセンブルしてネイティブ実行ファイルに再コンパイルする可能性に関する独自の研究を紹介します。

[10] US 7765539、Elliott、Scott、Hutchinson、Phillip、「ビデオゲームをトランスコンパイルするためのシステムおよび方法」、2010年発行

[11] Ramsey, Norman; Fernandez, Mary F. (1995)。「The New Jersey Machine-Code Toolkit」。TCON'95 Proceedings of the USENIX 1995 Technical Conference Proceedings。USENIX Association Berkeley、カリフォルニア州、米国。p. 24。

[Wharton_1994-12] Wharton, John Harrison (1994-08-01). 「業界のパイオニア、Gary Kildall が 52 歳で死去: 最初のマイクロコンピュータ言語、ディスクオペレーティングシステムを作成」Microprocessor Report . 8 (10). MicroDesign Resources Inc. (MDR). 2016-11-18にオリジナルからアーカイブ。2016-11-18に取得。 […] 皮肉なことに、 Garyが開拓した技術の多くは、10 年後の現在、再発見されています。AppleとDEC は、バイナリ再コンパイルを、既存のソフトウェアをPowerPCまたはAlphaアーキテクチャに移植するための「新しい」技術として宣伝しています。実際、DRI は1980 年代初頭に8080から8086 へのバイナリ再コンパイラを導入しました。 […]

[13] カールソン、ジム、ハック、ジェリー (2003)。Itanium の台頭: ムーアの計算能力の第二法則の突破。プレンティスホールPTR。ISBN 978-0-13046415-6. 2015年1月9日閲覧。

[14] 「HP ARIES Dynamic Binary Translator」。HP 。 2015年1月10日時点のオリジナルよりアーカイブ。2015年1月9日閲覧。

[15] ストークス、ジョン。「トランスメタ・クルーソーの探究」。Ars Technica 。2015年1月9日閲覧。

[16] Hughes, Rob (2000-01-20). 「Transmeta の Crusoe マイクロプロセッサ」. geek.com . 2007-09-27 時点のオリジナルよりアーカイブ。

[17] ^ 「 Transmeta Crusoe プロセッサのよくある質問 FAQ」。Transmeta . 2007 年。2007 年 1 月 10 日時点のオリジナルよりアーカイブ。