Editing Binary translation (section)

== Static binary translation ==
A translator using static binary translation aims to convert all of the code of an [[Executable|executable file]] into code that runs on the target architecture and platform without having to run the code first, as is done in dynamic binary translation. This is very difficult to do correctly, since not all the code can be discovered by the translator. For example, some parts of the executable may be reachable only through [[indirect branch]]es, whose value is known only at run-time.

One such static binary translator uses universal [[superoptimization|superoptimizer]] [[peephole optimization|peephole]] technology (developed by [[Sorav Bansal]] and Alex Aiken from [[Stanford University]]) to perform efficient translation between possibly many source and target pairs, with considerably low development costs and high performance of the target binary. In experiments of PowerPC-to-x86 translations, some binaries even outperformed native versions, but on average they ran at two-thirds of native speed.<ref>{{cite conference |last1=Bansal |first1=Sorav |last2=Aiken |first2=Alex |title=Binary Translation Using Peephole Superoptimizers |book-title=Proceedings of the 8th USENIX conference on Operating systems design and implementation |date=December 2008 |pages=177–192 |url=https://www.usenix.org/legacy/events/osdi08/tech/full_papers/bansal/bansal.pdf}}</ref>

=== Examples for static binary translations ===
In 1960s [[Honeywell]] provided a program called the [[Liberator (Honeywell)|Liberator]] for their [[Honeywell 200]] series of computers; it could translate programs for the [[IBM 1400 series]] of computers into programs for the Honeywell 200 series.<ref>{{cite book |url=http://bitsavers.org/pdf/honeywell/series200/charlie_gibbs/012_Series_200_Summary_Description.pdf |title=Honeywell Series 200 Summary Description |date=February 1966 |publisher=[[Honeywell]] |page=11 |quote=For example, the instruction repertoire of Series 200 processors is similar enough to those of several other processing systcms, viz., the IBM 1400 series, to allow automated, one-time translation of programs written for these competitive systems to a form suitable for execution on higher-performance Series 200 systems.}}</ref>

In 1995 Norman Ramsey at [[Bell Communications Research]] and Mary F. Fernandez at Department of Computer Science, [[Princeton University]] developed ''The New Jersey Machine-Code Toolkit'' that had the basic tools for static assembly translation.<ref>{{cite conference |book-title=Proceeding TCON'95 Proceedings of the USENIX 1995 Technical Conference Proceedings |url=https://www.usenix.org/legacy/publications/library/proceedings/neworl/full_papers/ramsey |author-last1=Ramsey |author-first1=Norman |author-last2=Fernandez |author-first2=Mary F. |date=1995 |pages=24 |title=The New Jersey Machine-Code Toolkit |publisher=USENIX Association Berkeley, CA, USA}}</ref>

In 2004 Scott Elliott and Phillip R. Hutchinson at [[Nintendo]] developed a tool to generate "C" code from [[Game Boy]] binary that could then be compiled for a new platform and linked against a hardware library for use in airline entertainment systems.<ref>{{cite patent|country=US|number=7765539|title=System and method for trans-compiling video games|issue-date=2010|inventor1-last=Elliott|inventor2-last=Hutchinson|inventor1-first=Scott|inventor2-first=Phillip|url=http://www.google.com/patents/US7765539}}</ref>

In 2014, an [[ARM architecture]] version of the 1998 [[video game]] ''[[StarCraft (video game)|StarCraft]]'' was generated by static recompilation and additional [[reverse engineering]] of the original [[x86]] version.<ref>{{cite web |author-last=Steinlechner |author-first=Peter |date=March 10, 2014 |title=Starcraft für ARM-Handheld kompiliert |url=http://www.golem.de/news/open-pandora-starcraft-fuer-arm-handheld-kompiliert-1403-105031.html |access-date=March 25, 2014 |publisher=golem.de |language=de}}</ref><ref>{{cite web |author=notaz |date=March 4, 2014 |title=StarCraft |url=http://repo.openpandora.org/?page=detail&app=package.starcraft |access-date=March 26, 2014 |publisher=repo.openpandora.org}}</ref>
The [[Pandora (console)|Pandora]] handheld community was capable of developing the required tools<ref>{{cite web |author=notaz |date=2014-03-01 |title=ia32rtools/ |url=https://github.com/notaz/ia32rtools |access-date=2015-01-09 |publisher=[[GitHub]]}}</ref> on their own and achieving such translations successfully several times.<ref>{{cite web |author=notaz |date=March 4, 2014 |title=Starcraft |url=http://boards.openpandora.org/topic/15820-starcraft/ |access-date=March 29, 2014 |publisher=openpandora.org |quote=''The "no source, no port" rule is not completely true, you can get something similar (but not the same) as a port through static recompilation. Similar stuff was done several times by M-HT for some DOS games. The game was also converted for Android with somewhat similar approach.''}}</ref><ref>{{cite web |author=M-HT |title=Warcraft: Orcs & Humans |url=http://repo.openpandora.org/?page=detail&app=warcraft_sr |publisher=repo.openpandora.org}}</ref>

Another example is the [[Nintendo Entertainment System|NES]]-to-[[x86]] statically recompiled version of the videogame ''[[Super Mario Bros.]]'' which was generated under usage of [[LLVM]] in 2013.<ref>{{cite web |author-last=Kelley |author-first=Andrew |date=2013-07-07 |title=Statically Recompiling NES Games into Native Executables with LLVM and Go |url=http://andrewkelley.me/post/jamulator.html |access-date=2013-08-08 |quote=This article presents original research regarding the possibility of statically disassembling and recompiling Nintendo Entertainment System games into native executables.}}</ref>

For instance, a successful x86-to-[[x64]] static recompilation was generated for the [[Procedural generation|procedural terrain generator]] of the video game ''[[Cube World]]'' in 2014.<ref>{{cite web |author-last=Kærlev |author-first=Mathias |date=2014-04-14 |title=Practical and Portable X86 Recompilation |url=http://mp2.dk/blog/blog/2014/04/14/practical-and-portable-binary-recompilation/ |access-date=2014-08-08 |quote=but then the idea of somehow using the original x86 machine code presented itself. However, for our open server, we need to support x86-64 as well, and in that case, we absolutely need emulation or recompilation. […] Static recompilation to assembler seemed like a much better option, but to keep it portable, we would need to write backends for x86, x86-64, and possibly ARM/PowerPC.}}</ref>