In computing, binary translation is a form of binary recompilation in which sequences of instructions (machine code or bytecode) are translated from a source instruction set architecture (ISA) to a target instruction set with respect to the operating system for which the binary was compiled. In some cases, such as instruction set simulation, the target instruction set may be the same as the source instruction set, providing testing and debugging features such as instruction tracing, conditional breakpoints, and hot spot detection and optimization.
The two main types are static and dynamic binary translation. Binary translation is commonly implemented in software using static or dynamic translation techniques.
Binary translation can allow software compiled for one instruction set architecture to execute on another without recompiling the original source code, and has been used to migrate existing software between incompatible architectures.
Statically recompiled binaries can avoid the runtime translation overhead incurred by dynamic translation, although the performance of a translated program depends on the translator, source and target architectures, and opportunities for optimization. This is similar to the difference in performance between interpreted and compiled programs in general.
A translator using static binary translation aims to convert the code of an 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 can be very difficult to do correctly, since not all code can be discovered by the translator. For example, some parts of the executable may be reachable only through indirect branches, whose value is known only at run-time.
One such static binary translator uses universal superoptimizer 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.
In the 1960s Honeywell provided a program called the 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.
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.
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.
In 2014, an ARM architecture version of the 1998 video game StarCraft was generated by static recompilation and additional reverse engineering of the original x86 version. The Pandora handheld community developed the required tools on their own and achieved usable translations several times.
Another example is the NES-to-x86 statically recompiled version of the videogame Super Mario Bros. which was generated using LLVM in 2013.
For instance, a successful x86-to-x64 static recompilation was generated for the procedural terrain generator of the video game Cube World in 2014.
In the 2020s, static binary translation tools such as N64 Recomp were developed to automatically recompile Nintendo 64 executables into native C code, enabling modern PC builds with features such as arbitrary frame rates and widescreen support.
Dynamic binary translation (DBT) translates binary code during program execution. A common implementation translates source code in units such as basic blocks and stores the generated target code in a code cache so that previously translated blocks can be reused.
Dynamic binary translation differs from simple emulation because translated target instructions can subsequently execute directly from the code cache. Translation itself imposes a run-time cost, and DBT systems attempt to amortize this overhead by reusing translated code, particularly for frequently executed regions.
More advanced dynamic translators employ dynamic recompilation, using execution information to identify frequently executed regions and apply additional optimization. This approach is similar to just-in-time compilation, although binary translators operate on already compiled machine code rather than source code or a language-level intermediate representation.
Pioneering works include Shade (the fast instruction set simulator and custom trace generator originally developed by Bob Cmelik (Sun Microsystems) and David Keppel (University of Washington))., open-source DAISY (Dynamically Architected Instruction Set from Yorktown) and its successor BOA (Binary-translation and Optimization Architecture) from IBM Research, and the Code Morphing Software used in Transmeta processors.
The smart microprocessor consists of a hardware VLIW core as its engine and a software layer called Code Morphing software. The Code Morphing software acts as a shell [...] morphing or translating x86 instructions to native Crusoe instructions. In addition, the Code Morphing software contains a dynamic compiler and code optimizer [...] The result is increased performance at the least amount of power. [...] [This] allows Transmeta to evolve the VLIW hardware and Code Morphing software separately without affecting the huge base of software applications.
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.
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.
This article presents original research regarding the possibility of statically disassembling and recompiling Nintendo Entertainment System games into native executables.
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.
[...] Ironically, many of the techniques Gary pioneered are being rediscovered now, ten years later. Apple and DEC are touting binary recompilation as a "new" technology for porting existing software to the PowerPC or Alpha architecture. Actually, DRI introduced an 8080-to-8086 binary recompiler in the early 1980s. [...]