Binary Translation Richard L. Sites, Anton Chernoff Matthew B. Kirk, Maurice P. Marks, and Scott G. Robinson hen Digital started to design the Alpha AXP architecture in the fall of 1988, the Alpha AXP team was concerned with running existing VAX TM code and MIPS TM code on the new Alpha AXP computers [5, 6]. To get full performance on a new computer architecture, an application must be ported by rebuilding, using native compilers. For a single pro- gram written in a standard programming language, this is a matter of recompile and run. A complex soft- ware application can be built, however, from hundreds of source pieces using dozens of tools. A native port of such an application is only possible when all parts of the build path are running on the new architecture. Therefore, having a way to run an existing (old architecture) binary version of a complex application on a new architecture is an important interim measure. It allows a user to get applications up and running immediately, with minimal porting effort. Once a user's everyday environment is established, appli- cations can be rebuilt over time, using native code or partially native and partially old code. Several techniques are used in the industry to run the binary code of an old architecture on a new architecture. Figure 1 shows four common techni- ques, from slowest to fastest: • Software interpreter (e.g., Insignia Solutions' SoftPC) • Microcoded emulator(e.g., PDP-11 compatibility mode in early VAX computers) • Binary translator (e.g., Hunter System's XDOS) • Native compiler A software interpreter is a program that reads instructions of the old archi- tecture one at a time, performing each operation in turn on a software- maintained version of the old architec- ture's state. Interpreters are not very fast, but run on a wide variety of machines and can faithfully reproduce the behavior of self-modifying pro- grams, programs that branch to data, programs that branch to a checksum of themselves, and so forth. Caching interpreters gain speed by retaining predecoded forms of previously inter- preted instructions. A microcoded emulator operates similarly to a software interpreter but usually with some key hardware assists to decode the old instructions quickly and to hold hardware state information in registers of the micromachine. An emulator is typically faster than an COMMUNICATIONS OF THII A¢II/February 1993/Vol.36, No.2 19interpreter but can run only on a specific microcoded new machine. This technique cannot be used to run existing code on a reduced instruction set computer (RISC) machine, since RISC architectures do not have a microcoded hardware layer underlying the visible machine architecture. A translated binary program is a sequence of new-architecture in- structions that reproduces the behav- ior of an old-architecture program. Typically, much of the state informa- tion of the old machine is kept in reg- isters in the new machine. Translated code reproduces faithfully the calling standard, implicit state, instruction side effects, branching flow, and other artifacts of the old machine. Translated programs can be much faster than interpreters or emulators, but slower than native-compiled pro- grams. Translators can be classified as ei- ther (1) bounded translation systems, in which all the instructions of the old program must exist at translation time and must be found and trans- lated to new instructions [2, 3, 7], or (2) open-ended translation systems, in which code also may be discov- ered, created, or modified at execu- tion time. Bounded systems usually require manual intervention to find 100% of the code; open-ended sys- tems can be fully automatic. To run existing VAX and MIPS programs, an open-ended system is absolutely necessary. For example, some customer programs write li- cense-check code (VAX instructions) to memory and branch to that code. A bounded system fails on such pro- grams. A native-compiled program is a sequence of new-architecture in- structions produced by recompil- ing the program. Usually, native- compiled programs use newer, faster calling conventions than old pro- grams. With a well-tuned optimizing compiler, native-compiled programs can be substantially faster than any of the other choices. Most large programs are not self- contained; they call library routines, windowing services, databases, and toolkits, for example. Also, these Figure 1. Common techniques for running olcl code on new computers Figure 2. Binary translation ancl execution process programs (directly or indirectly) in- voke operating-system services. In simple environments with a single dominant library, it can be sufficient to rewrite that library in native code and to interpret user programs, par- ticularly user programs that actually spend most of their time in the li- brary. This strategy is commonly used to run Windows ~ and Macin- tosh ~° programs under the Unix ~ operating system. In more robust enviromnents, it is not practical to rewrite all the shared libraries by hand; collections of doz- ens or even hundreds of images (such as typical VAX ALL-IN-1 ~ systems) must be run in the old envi- ronment, with an occasional excur- sion into the native operating system. Over time, it is desirable (1) to re- build some images using a native compiler while retaining other im- ages as translated code and (2) to achieve interoperability between these old and new images. The inter- face between an old environment and a new one typically consists of '~jacket" routines that receive a call using old conventions and data struc- tures, reformat the parameters, per- form a native call using new conven- tions and data structures, reformat the result, and return. The Alpha AXP Migration Tools team considered running old VAX binary programs on Alpha AXP computers using a simple software interpreter, but rejected this method because the performance would be too slow to be useful. The idea of using some form of microcoded emulator was rejected also. This technique would compromise the performance of a native Alpha AXP implementation, and VAX compati- bility would be