Richard L. Sites, Anton Chernoff Matthew B. Kirk, Maurice P. Marks, and Scott G. Robinson Binary Translation hen Digital started to design partially native and partially old code. Several techniques are used in the the Alpha AXP architecture industry to run the binary code of an in the fall of 1988, the Alpha old architecture on a new architecture. Figure 1 shows four common techni- AXP team was concerned ques, from slowest to fastest: with running existing • Software interpreter (e.g., Insignia VAX TM code and MIPS TM Solutions' SoftPC) code on the new Alpha AXP • Microcoded emulator(e.g., PDP-11 compatibility mode in early VAX computers [5, 6]. To get computers) full performance on a new • Binary translator (e.g., Hunter computer architecture, an System's XDOS) • Native compiler application must be ported A software interpreter is a program by rebuilding, using native that reads instructions of the old archi- compilers. For a single pro- tecture one at a time, performing each operation in turn on a software- gram written in a standard programming language, maintained version of the old architec- this is a matter of recompile and run. A complex soft- ture's state. Interpreters are not very fast, but run on a wide variety of ware application can be built, however, from hundreds machines and can faithfully reproduce of source pieces using dozens of tools. A native port of the behavior of self-modifying pro- such an application is only possible when all parts of grams, programs that branch to data, programs that branch to a checksum of the build path are running on the new architecture. themselves, and so forth. Caching Therefore, having a way to run an existing (old interpreters gain speed by retaining predecoded forms of previously inter- architecture) binary version of a complex application preted instructions. on a new architecture is an important interim measure. A microcoded emulator operates similarly to a software interpreter but It allows a user to get applications up and running usually with some key hardware assists immediately, with minimal porting effort. Once a to decode the old instructions quickly and to hold hardware state information user's everyday environment is established, appli- in registers of the micromachine. An cations can be rebuilt over time, using native code or emulator is typically faster than an COMMUNICATIONS OF THII A¢II/February 1993/Vol.36, No.2 19 ther (1) bounded translation systems, programs (directly or indirectly) in- in which all the instructions of the voke operating-system services. In old program must exist at translation simple environments with a single time and must be found and trans- dominant library, it can be sufficient lated to new instructions [2, 3, 7], or to rewrite that library in native code (2) open-ended translation systems, and to interpret user programs, par- in which code also may be discov- ticularly user programs that actually ered, created, or modified at execu- spend most of their time in the li- tion time. Bounded systems usually brary. This strategy is commonly require manual intervention to find used to run Windows ~ and Macin- interpreter but can run only on a 100% of the code; open-ended sys- tosh ~° programs under the Unix ~ specific microcoded new machine. tems can be fully automatic. operating system. This technique cannot be used to run To run existing VAX and MIPS In more robust enviromnents, it is existing code on a reduced instruction programs, an open-ended system is not practical to rewrite all the shared set computer (RISC) machine, since absolutely necessary. For example, libraries by hand; collections of doz- RISC architectures do not have a some customer programs write li- ens or even hundreds of images microcoded hardware layer underlying cense-check code (VAX instructions) (such as typical VAX ALL-IN-1 ~ the visible machine architecture. to memory and branch to that code. systems) must be run in the old envi- A translated binary program is a A bounded system fails on such pro- ronment, with an occasional excur- sequence of new-architecture in- grams. sion into the native operating system. structions that reproduces the behav- A native-compiled program is a Over time, it is desirable (1) to re- ior of an old-architecture program. sequence of new-architecture in- build some images using a native Typically, much of the state informa- structions produced by recompil- compiler while retaining other im- tion of the old machine is kept in reg- ing the program. Usually, native- ages as translated code and (2) to isters in the new machine. Translated compiled programs use newer, faster achieve interoperability between code reproduces faithfully the calling calling conventions than old pro- these old and new images. The inter- standard, implicit state, instruction grams. With a well-tuned optimizing face between an old environment side effects, branching flow, and compiler, native-compiled programs and a new one typically consists of other artifacts of the old machine. can be substantially faster than any of '~jacket" routines that receive a call Translated programs can be much the other choices. using old conventions and data struc- faster than interpreters or emulators, Most large programs are not self- tures, reformat the parameters, per- but slower than native-compiled pro- contained; they call library routines, form a native call using new conven- grams. windowing services, databases, and tions and data structures, reformat Translators can be classified as ei- toolkits, for example. Also, these the result, and return. The Alpha AXP Migration Tools Figure 1. team considered running old VAX Common binary programs on Alpha AXP techniques for running computers using a simple software olcl code interpreter, but rejected this method on new because the performance would be computers too slow to be useful. The idea of using some form of microcoded Figure 2. Binary emulator was rejected also. This translation technique would compromise the ancl execution performance of a native Alpha AXP process implementation, and VAX compati- bility would be nearly impossible to achieve without microcode, which is inconsistent with a high-speed RISC design. Therefore, we turned to open- ended binary translation. We were aware of the earlier Hewlett-Packard binary translator, but its single-image HP ~ 3000 input code looked much simpler to translate than large collec- tions of hand-coded VAX assembly language programs [1]. One team member wrote a VAX-to-VAX bi- nary translator as a proof of concept, which looked feasible, so we set the 10 February 1993/Vol.36, No.2 /C~UMnUr.,~nI,"J"nUONI OP 'UMllUACre following goals: 1. Open-ended (completely auto- matic) translation of almost all user- mode applications from the OpenVMS VAX system to the OpenVMS AXP system. 2. Open-ended translation of almost all user-mode applications from the ULTRIX system to the DEC OSF/1 system. 3. Run-time performance of trans- lated code on Alpha AXP computers that meets or exceeds the perfor- mance of the original code on the original architecture. 4. Optional reproduction of subtle old-architecture details, at the cost of run-time performance, e.g., complex instruction set computer (CISC) in- struction atomicity for multithreaded applications and exact arithmetic traps for sophisticated error hand- must also include a way to run old run just like native images [4]. Trans- lers. code not discovered (or nonexistent) lated images run with the assistance 5. If translation is not possible, gen- at translation time. The translated- of the translated image environment, eration of explicit messages that give image environment (TIE) and mxr discussed later. The VEST binary reasons and specify what source run-time environment support the translator is written in C++ and changes are necessary. VEST and mx translators, respec- runs on VAX, MIPS, and Alpha AXP While creating the VAX translator, tively, by reproducing the old oper- machines. The TIE is written in the we discovered the process of building ating environments. Each environ- OpenVMS system programming lan- flow graphs and tracking data de- ment supports open-ended guages, Bliss, and Alpha AXP assem- pendencies yielded information translation by including a fallback bler. about source code bugs, perfor- interpreter of old code and extensive To locate VAX code, VEST starts mance bottlenecks, and dependen- run-time feedback to avoid using the disassembling code at known entry cies on features not available in all interpreter except for dynamically points and traces the program's flow Alpha AXP operating systems. This created code. Our design philosophy of control recursively. Entry points analysis information could be valu- is to do everything feasible to stay out come from main and global routines, able to a source code maintainer. of the interpreter, rather than to in- debug symbol table entries, and op- Thus, we added one more product crease the speed of the interpreter. tional information files (including goal: This approach gives better perfor- run-time feedback from the TIE). mance over a wider range of pro- As VEST traces the program, it 6. Optional source analysis informa- grams than using pure interpreters builds a flow graph that consists of tion. or bounded translation systems. basic blocks (i.e., straight-line code To achieve these goals, the team The remainder of this article dis- sequences) annotated with informa- created two binary translators: cusses the two binary translator/run- tion derived from parsing instruc- VEST, which translates OpenVMS time environment pairs available for tions. Then, VEST performs several VAX binary images to OpenVMS Alpha AXP computers: VEST/TIE analyses on the flow graph to propa- AXP images, and mx, which trans- and mx/mxr. To establish a basis for gate context information to each lates ULTRIX MIPS images to DEC the discussion, the reader must un- basic block and eliminate unneces- OSF/1 AXP images.