Several techniques are used in the industry to run the binary code of an old archi tecture on a new archi tecture. Figure 1 shows fou r common tech niques, from slowest to fastest:
Digital Techuicaljourua/ Vol. 4 No. 4 !>jJecial lssue 1992
• Software interpreter (e.g., Insignia Solutions' SoftPC)
• M icrocoded emulator (e.g., PDP-11 compatibility mode in early VA,\: computers)
• Binary translator (e.g., Hunter System's XDOS)
• Native compi ler
A software i nterpreter is a program that reads i nstructions of the old architecture one at a t i me, performing each operation in turn on a soft ware-maintained version of the old architecture's state. Interpreters are not very fast, but they run
on a wide variety of machines and can faithfu l ly
SLOWER SOFTWARE I NTERPRETER M I C ROCODED EMULATOR BINARY TRANSLATOR FASTER NATIVE COMPILER
Figure 1 Common Techniques for Running Old Code on New Computers
reproduce the behavior of self-modi fying pro grams, programs that branch to data, programs that branch to a checksum of themselves, etc. Cachi ng interpreters gain speed by retaining preclecocled forms of previously in terpretecl instructions.
A microcoded emu lator operates similarly to a software interpreter but usual ly with some key hardware assists to decode the old i nstru ctions qu ickly and to hold hardware state i nformation in registers of the micromachine. An emulator is typi cal ly faster than an interpreter 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 (RJSC) machine, since ruse
architectures do not have a microcoded hardware layer u nderly ing the visible machine archi tecture. A translated binary program is a sequence of new-architecture i nstructions that reproduce the behavior of an old-architecture program. Typically, much of the state information of the old machine is kept i n registers i n the new mach i ne. Translated code fai thfu l ly reproduces the cal l ing standard, implicit state, instruction side effects, branchi ng flow, a nd other artiJacts of the old machine. Translated programs can be much faster than interpreters or emulators, but slower than native compiled programs.
Translators can be classified as either ( 1 ) bounded translation systems, i n which all the i nstructions of the old program must exist at trans late time and m ust be found and translated to new i nstructions, 1 '5 or (2) open-ended translation sys tems, in which code may also be d iscovered, cre ated, or modified at execution time. Bounded systems usual ly require manual intervention to find 100 percent of the code; open-ended systems can be ful ly automatic.
To run existing VAX and MIPS programs, an open ended system is absolutely necessary For example, some customer programs write l icense-check code (VAX instructions) to memory, and branch to that code. A bounded system fails on such programs.
A native-compiled program is a sequence of new architecture instructions produced by recompil ing the program. Native-compi led programs usu a l ly use newer, faster cal l ing conventions than old p ro grams. With a wel l - tuned optimizing compiler, native-compiled programs can be substantia l ly faster than any of the other choices.
Most large programs are not self-contained; they cal l l ibrary routines, windowing services, data bases, and tool kits, for example. These programs
also directly or indirectly i nvoke operating system services. In simple environments with a single dom inant l ibrary, it can be sufficient to rewrite that I i brary in native code and to i nterpret user pro grams, particularly user p rograms that actually spend most of their time in the I ibrary. This strategy is commonly used to ru n Windows and Macintosh programs under the UNIX operating system.
In more robust environmen ts, i t is not practical to rewrite all the shared J ibraries by hand ; collec tions of dozens or even hundreds of i mages (such as typical VAX ALL-IN-1 systems) must be run i n the old environment, with an occasional excursion i nto the native operating system. Over time, it is desirable to rebuild some images using a native compiler while retaining other images as translated code, and to achieve interoperabil i ty between these old and new images. The interface between an old environ ment and a new one typical ly consists of "jacket'' routines that receive a call using old conventions and data structures, reformat the parameters, per form a native cal l using new conventions and data structures, reformat the result, and return.
The Alpha ;\.,'\P Migration Tools team considered running old VAX binary programs on Alpha AXP computers using a simple software i nterpreter, but rejected this method because the p e rformance would be too slow to be useful. We a lso rejected the idea of using some form of m icrocoded emula tor. This technique wou ld compromise the perfor mance of a native Alpha AXP imp lementation, and VAX compatibil i ty would be nearly impossible to achieve without m icrocode, which is inconsistent with a high-speed ruse design.
We therefore turned to open-ended binary trans lation. We were aware of the earlier Hew lett Packard binary translator, but its single-image HP 3000 input code looked much simpler to translate than large collections of hand-coded VAX assembly l anguage p rograms .G One member of the team (R. Sites) wrote a VAX-to-VAX binary translator in October 1988 as proof-of-concept. The concept looked feasible, so we set the fol lowing ambitious product goals:
1 . Open-ended (completely au tomatic) translation of a lmost all user-mode applications from the OpenVMS VA)( system to the OpenVMS AXP system
2. Open-ended translation of almost a l l user-mode applications from the ULTRIX system to the DEC
OSF/1 system
3. Run-time performance of translated code on Alpha AXP computers that meets or exceeds the performance 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) instruction atomicity for multi threaded app l ica tions and exact arithmetic traps for sophisti cated error handlers
5. If translation is not possible, generation of expl icit messages that give reasons and specify what source changes are necessary
While we were creating the VA.'( translator, we d iscovered that the process of building flow graphs of the code and tracking data dependencies yielded i nformation about source code bugs, performa nce bottlenecks, and dependencies on features not avail able in all Alpha A.."XP operating systems. This analy sis information could be valuable to a source code maintainer. Thus, we added one more product goal : 6 . Optional source analysis information
O L D B I NARY OPTIONAL IMAGE INTERFACE
DESCRIPTIONS
TRAN SLATOR
(VEST/MX)
N EW BINARY IMAGE OPTIONAL
• OLD DATA LISTING
• OLD CODE AND ERROR
• NEW CODE MESSAGES
RUN· TIME SUPPORT (TIE/MX) PROGRAM LOADER Binary Translation
To achieve these goals, the Alpha AXP M igration Tools team created two binary translators: VEST, which translates OpenVMS VAX binary images to OpenVMS AXP images, and mx, which translates ULTRIX MIPS i mages to DEC OSF/1 A.."XP i mages. However, binary translation is only half the migra tion process. As shown in Figure 2, the other half is to build a run-time environment in which to exe cute the translated code. This second half of the process must bridge any differences between old and new operating systems, cal ling standards, exception hand l ing, etc. For open-ended transla tion, this part of the process must also include a way to run old code that was not d iscovered (or clid not exist) at translate t ime. The translated image
environment (TIE) and mxr run-time environment
support the VEST and mx translators, respectively, by reproducing the old operating environments. Each environment supports open-ended transla tion by including a fal l back interpreter of old code, and extensive run-time feedback to avoid using the interpreter except for dynamical ly created code. Our design philosophy is to do everything feasible to stay out of the i n terpreter, rather than to increase the speed of the interpreter. This approach gives
OPTIONAL OPTIONAL
INTERFACE FLOW DESC R I PTION GRAPHS
OTHER OTHER
TRANSLATED NATIVE
IMAGES I MAGES
Figure 2 Binary Translation ana Execution Process
better performance over a wider range of programs than using pure interpreters or bounded transla tion systems.
The rema inder of this paper d iscusses the two binary translator/run-time environment pairs avail able for Alpha A.,'(P computers: V ESl/TIE ami mx/mxr. To establ ish a basis for the discussion, the reader must understand the following terms: datum, al ignment, instruction atomicity, granular ity, interlocked update, and word tearing. Definitions of these terms appear in the References and Note section.-