DOCSLIB.ORG

Lecture 24 –Dynamo-RIO by HP, MIT – Codemorph by Transmeta

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lecture 24 –Dynamo-RIO by HP, MIT – Codemorph by Transmeta Lecture Outline • Binary Translation: Why, What, and When. Dynamic Binary Translation • Why: Guarding against buffer overruns • What, when: overview of two dynamic translators: Lecture 24 –Dynamo-RIO by HP, MIT – CodeMorph by Transmeta • Techniques used in dynamic translators acknowledgement: E. Duesterwald (IBM), S. Amarasinghe (MIT) – Path profiling 2 Ras Bodik CS 164 Lecture 24 1 Ras Bodik CS 164 Lecture 24 Motivation: preventing buffer overruns Preventing buffer overrun attacks Recall the typical buffer overrun attack: Two general approaches: 1. program calls a method foo() • static (compile-time): analyze the program – find all array writes that may outside array bounds 2. foo() copies a string into an on-stack array: – program proven safe before you run it – string supplied by the user – user’s malicious code copied into foo’s array – foo’s return address overwritten to point to user code • dynamic (run-time): analyze the execution – make sure no write outside an array happens 3. foo() returns – unknowingly jumping to the user code – execution proven safe (enough to achieve security) 3 4 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Dynamic buffer overrun prevention A different idea the idea, again: perhaps less safe, but easier to implement: –goal: detect that return address was overwritten. • prevent writes outside the intended array instrument the program so that – as is done in Java – it keeps an extra copy of the return address: – harder in C: must add “size” to each array • done in CCured, a Berkeley project 1. store aside the return address when function called (store it in an inaccessible shadow stack) 2. when returning, check that the return address in AR matches the stored one; 3. if mismatch, terminate program 5 6 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Commercially interesting What is Binary Translation? • Similar idea behind the product by • Translating a program in one binary format to determina.com another, for example: •key problem: –MIPS Æ x86 (to port programs across platforms) – reducing overhead of instrumentation • what’s instrumentation, anyway? • We can view “binary format” liberally: – adding statements to an existing program – Java bytecode Æ x86 (to avoid interpretation) – in our case, to x86 executables – x86 Æ x86 (to optimize the executable) • Determina uses binary translation 7 8 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 When does the translation happen? Why? Translation Allows Program Modification • Static (off-line): before the program is run Static Dynamic – Pros: no serious translation-time constraints Runtime Program Compiler Linker Loader • Dynamic (on-line): while the program is running System –Pros: • Instrumenters • access to complete program (program is fully linked) • access to program state (including values of data struct’s) • Debuggers • can adapt to changes in program behavior • Interpreters • Just-In-Time Compilers • Dynamic Optimizers • Profilers • Note: Pros(dynamic) = Cons(static) • Load time optimizers • Dynamic Checkers • Shared library mechanism • instrumenters 9 • Etc. 10 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Applications, in more detail Dynamic Program Modifiers • profilers: – add instrumentation instructions to count basic Running Program block execution counts (e.g., gprof) • load-time optimizers: Dynamic Program Modifier: Observe/Manipulate Every Instruction in the Running Program – remove caller/callee save instructions (callers/callees known after DLLs are linked) Hardware Platform – replace long jumps with short jumps (code position known after linking) •dynamic checkers – finding memory access bugs (e.g., Rational Purify) 11 12 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 In more detail Dynamic Program Modifiers application application Requirements: application DLL OS DLL 9 Ability to intercept execution at arbitrary points OS 9 Observe executing instructions DLL OS CodeMorph Dynamo 9 Modify executing instructions CPU CPU=VLIW CPU=x86 9 Transparency - modified program is not specially prepared common setup CodeMorph Dynamo-RIO 9 Efficiency (Transmeta) (HP, MIT) - amortize overhead and achieve near-native performance 9 Robustness 9 Maintain full control and capture all code - sampling is not an option (there are security applications) 13 14 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 HP Dynamo-RIO System I: Basic Interpreter next • Building a dynamic program modifier VPC • Trick I: adding a code cache • Trick II: linking fetch next • Trick III: efficient indirect branch handling instruction decode execute update VPC • Trick IV: picking traces exception handling • Dynamo-RIO performance Instruction Interpreter • Run-time trace optimizations 9 Intercept execution 9 Observe & modify executing instructions 9 Transparency Efficiency? - up to several 100 X slowdown 15 16 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Trick I: Adding a Code Cache Example Basic Block Fragment add %eax, %ecx next lookup VPC cmp $4, %eax VPC exception handling jle $0x40106f frag7: add %eax, %ecx fetch block emit execute at VPC block block cmp $4, %eax jle <stub1> jmp <stub2> context switch stub1: mov %eax, eax-slot # spill eax mov &dstub1, %eax # store ptr to stub table BASIC BLOCK jmp context_switch CACHE stub2: mov %eax, eax-slot # spill eax non-control-flow mov &dstub2, %eax # store ptr to stub table instructions jmp context_switch 17 18 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Runtime System with Code Cache Linking a Basic Block Fragment next VPC basic block builder add %eax, %ecx frag7: add %eax, %ecx cmp $4, %eax cmp $4, %eax context switch jle $0x40106f jle <frag42> jmp <frag8> BASIC BLOCK stub1: mov %eax, eax-slot CACHE mov &dstub1, %eax non-control-flow instructions jmp context_switch stub2: mov %eax, eax-slot Improves performance: mov &dstub2, %eax • slowdown reduced from 100x to 17-26x jmp context_switch • remaining bottleneck: frequent (costly) context switches 19 20 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Performance Effect of Trick II: Linking Basic Block Cache with direct branch linking vpr (Spec2000) next 28 lookup VPC 26.03 VPC exception 26 data set 1 handling 24 data set 2 22 20 17.45 fetch block link emit execute until 18 16 at VPC block block cache miss 14 12 10 8 context switch 6 2.97 3.63 4 2 0 BASIC BLOCK Execution Native over Slowdown block cache block cache with direct CACHE linking non-control-flow instructions Performance Problem: mispredicted indirect branches 21 22 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Indirect Branch Linking Indirect Branch Handling Shared Indirect Branch Target Conditionally “inline” a preferred indirect branch target as the (IBT) Table continuation of the trace original target F <load actual target> <compare to inlined target> if equal goto <inlined target> original target H ret mov %edx, edx_slot # save app’s edx <preferred target> pop %edx # load actual target lookup IBT table <save flags> linked if (! tag-match) targets cmp %edx, $0x77f44708 # compare to goto <exit stub> # preferred target jump to tag-value jne <exit stub > H K mov edx_slot, %edx # restore app’s edx <restore flags> I L <inlined target> <inlined preferred target> J 23 <exit stub> Ras Bodik CS 164 Lecture 24 Trick III: Efficient Indirect Branch Handling Performance Effect of indirect branch linking next 26.03 17.45 vpr (Spec2000) VPC 10 9 8 data set 1 7 data set 2 basic block builder 6 5 4 3.63 2.97 context switch Execution 3 2 1.20 1.15 miss 1 Slowdown over Native over Slowdown 0 BASIC BLOCK miss block cache block cache with direct block cache with linking CACHE linking (direct+indirect) non-control-flow indirect instructions branch lookup Performance Problem: poor code layout in code cache 25 26 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Trick IV: Picking Traces Picking Traces Block Cache has poor execution efficiency: • Increased branching, poor locality START basic block builder trace selector Pick traces to: • reduce branching & improve layout and locality dispatch • New optimization opportunities across block boundaries Block Cache Trace Cache context switch A D G J A G B K J BASIC BLOCK TRACE CACHE B E H K E F CACHE H non-control-flow indirect non-control-flow C F I L instructions branch lookup instructions D 27 28 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Picking hot traces Alternative 1: Edge profiling • The goal: path profiling The algorithm: – find frequently executed control-flow paths • Edge profiling: measure frequencies of all control- – Connect basic blocks along these paths into flow edges, then after a while contiguous sequences, called traces. • Trace selection: select hot traces by following highest-frequency branch outcome. • The problem: find a good trade-off between – profiling overhead (counting execution events), and Disadvantages: – accuracy of the profile. • Inaccurate: may select infeasible paths (due to branch correlation) • Overhead: must profile all control-flow edges 29 30 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Alternative 2: Bit-tracing path profiling Alternative 3: Next Executing Tail (NET) The algorithm: This is the algorithm of Dynamo: – collect path signatures and their frequencies – profiling: count only frequencies of start-of-trace – path signature = <start addr>.history points (which are targets of original backedges) – example: <label7>.0101101 – must include addresses of indirect branches – trace selection: when a start-of-trace point becomes sufficiently hot, select the sequence of Advantages: basic blocks executed next. – accuracy Disadvantages: – may select a rare (cold) path, but statistically – overhead: need to monitor every branch selects a hot path! – overhead: counter storage (one counter per path!) 31 32 Ras Bodik CS 164 Lecture 24 Ras Bodik CS 164 Lecture 24 Spec2000 Performance on Windows NET (continued) (w/o trace optimizations) Advantages of NET: 2.2 very light-weight 2.0 #instrumentation points = #targets of backward branches 1.8 1.6 #counters = #targets of backward branches 1.4 1.2 statistically likely to pick the 1.0 hottest path A D G J 0.8 pick only feasible paths 0.6 easy to implement B E H K 0.4 0.2 Slowdown vs.
Load more

Recommended publications
  • Binary Translation Using Peephole Superoptimizers
    Binary Translation Using Peephole Superoptimizers Sorav Bansal Alex Aiken Computer Systems Lab Computer Systems Lab Stanford University Stanford University [email protected] [email protected] Abstract tecture performance for compute-intensive applica- We present a new scheme for performing binary trans- tions. lation that produces code comparable to or better than 2. Because the instruction sets of modern machines existing binary translators with much less engineering tend to be large and idiosyncratic, just writing the effort. Instead of hand-coding the translation from one translation rules from one architecture to another instruction set to another, our approach automatically is a significant engineering challenge, especially if learns translation rules using superoptimization tech- there are significant differences in the semantics of niques. We have implemented a PowerPC-x86 binary the two instruction sets. This problem is exacer- translator and report results on small and large compute- bated by the need to perform optimizations wher- intensive benchmarks. When compared to the native ever possible to minimize problem (1). compiler, our translated code achieves median perfor- mance of 67% on large benchmarks and in some small 3. Because high-performancetranslations must exploit stress tests actually outperforms the native compiler. We architecture-specific semantics to maximize perfor- also report comparisons with the open source binary mance, it is challenging to design a binary translator translator Qemu and a commercial tool, Apple’s Rosetta. that can be quickly retargeted to new architectures. We consistently outperform the former and are compara- One popular approach is to design a common inter- ble to or faster than the latter on all but one benchmark.
    [Show full text]
  • Understanding Full Virtualization, Paravirtualization, and Hardware Assist
    VMware Understanding Full Virtualization, Paravirtualization, and Hardware Assist Contents Introduction .................................................................................................................1 Overview of x86 Virtualization..................................................................................2 CPU Virtualization .......................................................................................................3 The Challenges of x86 Hardware Virtualization ...........................................................................................................3 Technique 1 - Full Virtualization using Binary Translation......................................................................................4 Technique 2 - OS Assisted Virtualization or Paravirtualization.............................................................................5 Technique 3 - Hardware Assisted Virtualization ..........................................................................................................6 Memory Virtualization................................................................................................6 Device and I/O Virtualization.....................................................................................7 Summarizing the Current State of x86 Virtualization Techniques......................8 Full Virtualization with Binary Translation is the Most Established Technology Today..........................8 Hardware Assist is the Future of Virtualization, but the Real Gains Have
    [Show full text]
  • Specification-Driven Dynamic Binary Translation
    Specification-Driven Dynamic Binary Translation Jens Tr¨oger December 2004 A dissertation submitted in partial fulfillment of the requirements for the degree Doctor of Philosophy in Computer Science OUT Programming Languages and Systems Research Group Faculty of Information Technology Queensland University of Technology Brisbane, Australia Copyright c Jens Tr¨oger, MMIV. All rights reserved. [email protected] http://savage.light-speed.de/ The author hereby grants permission to the Queensland University of Technology to reproduce and distribute publicly paper and electronic copies of this thesis document in whole or in part. “But I’ve come to see that as nothing can be made that isn’t flawed, the challenge is twofold: first, not to berate oneself for what is, after all, inevitable; and second, to see in our failed perfection a different thing; a truer thing, perhaps, because it contains both our ambition and the spoiling of that ambition; the exhaustion of order, and the discovery – in the midst of despair – that the beast dogging the heels of beauty has a beauty all of its own.” Clive Barker (Galilee) Keywords Machine emulation; formal specification of machine instructions; dynamic optimization; dynamic binary translation; specification-driven dynamic binary translation. Abstract Machine emulation allows for the simulation of a real or virtual machine, the source machine, on various host computers. A machine emulator interprets programs that are compiled for the emulated machine, but normally at a much reduced speed. Therefore, in order to increase the execution speed of such interpreted programs, a machine emulator may apply different dynamic optimization techniques. In our research we focus on emulators for real machines, i.e.
    [Show full text]
  • Systems, Methods, and Computer Programs for Dynamic Binary Translation in an Interpreter
    (19) TZZ Z_¥4A_T (11) EP 2 605 134 A1 (12) EUROPEAN PATENT APPLICATION (43) Date of publication: (51) Int Cl.: 19.06.2013 Bulletin 2013/25 G06F 9/455 (2006.01) G06F 9/45 (2006.01) (21) Application number: 12186598.4 (22) Date of filing: 14.07.2010 (84) Designated Contracting States: (72) Inventors: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB • Beale, Andrew GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO Mission Viejo, CA 92692 (US) PL PT RO SE SI SK SM TR • Wilton, Loren Rancho Cucamonga, CA 91730 (US) (30) Priority: 14.07.2009 US 502301 • Meyers, Robert 14.07.2009 US 502285 Garden Grove, CA 92840 (US) 14.07.2010 EP 10736925 (74) Representative: Hufton, David Alan (62) Document number(s) of the earlier application(s) in Harrison Goddard Foote accordance with Art. 76 EPC: Fountain Precinct 10736925.8 / 2 454 664 Balm Green Sheffield S1 2JA (GB) (27) Previously filed application: 14.07.2010 PCT/US2010/041973 Remarks: This application was filed on 28-09-2012 as a (71) Applicant: Unisys Corporation divisional application to the application mentioned Blue Bell, PA 19422 (US) under INID code 62. (54) Systems, methods, and computer programs for dynamic binary translation in an interpreter (57) Various embodiments of systems and methods the TCU causing the translation complete event; the TCU for dynamic binary translation in an interpreter are dis- preparing the second stack and scheduling the CPM to closed. An embodiment comprises a method of perform- the second stack; and the CPM executing the native ing dynamic binary translation in a Master Control Pro- code.
    [Show full text]
  • Binary Translation 1 Abstract Binary Translation Is a Technique Used To
    Binary Translation 1 Abstract Binary translation is a technique used to change an executable program for one computer architecture and operating system into an executable program for a different computer architecture and operating system. Two binary translators are among the migration tools available for Alpha AXP computers: VEST translates OpenVMS VAX binary images to OpenVMS AXP images; mx translates ULTRIX MIPS images to DEC OSF/1 AXP images. In both cases, translated code usually runs on Alpha AXP computers as fast or faster than the original code runs on the original architecture. In contrast to other migration efforts in the industry, the VAX translator reproduces subtle CISC behavior on a RISC machine, and both open-ended translators provide good performance on dynamically modified programs. Alpha AXP binary translators are important migration tools - hundreds of translated OpenVMS VAX and ULTRIX MIPS images currently run on Alpha AXP systems. When Digital started to design the Alpha AXP architecture in the fall of 1988, the Alpha AXP team was concerned about how to run existing VAX code and soon-to-exist MIPS code on the new Alpha AXP computers.[1,2] To take full advantage of the performance capability of a new computer architecture, an application must be ported by rebuilding, using native compilers. For a single program written in a standard programming language, this is a matter of recompile and run. A complex software application, however, can be built from hundreds of source pieces using dozens of tools. A native port of such an application is possible only when all parts of the build path are running on the new architecture.
    [Show full text]
  • The Evolution of an X86 Virtual Machine Monitor
    The Evolution of an x86 Virtual Machine Monitor Ole Agesen, Alex Garthwaite, Jeffrey Sheldon, Pratap Subrahmanyam {agesen, alextg, jeffshel, pratap}@vmware.com ABSTRACT While trap-and-emulate virtualization on mainframes was Twelve years have passed since VMware engineers first virtu- well understood at the time, it was – unsurprisingly – not a alized the x86 architecture. This technological breakthrough design goal for the 4004, whose first application was in fact kicked off a transformation of an entire industry, and virtu- a Busicom calculator [7]. However, as x86 CPUs expanded alization is now (once again) a thriving business with a wide their reach, the case for virtualization gradually emerged. range of solutions being deployed, developed and proposed. There was just one problem, seemingly fundamental: the But at the base of it all, the fundamental quest is still the generally accepted wisdom held that x86 virtualization was same: running virtual machines as well as we possibly can impossible, or at best merely impractical, due to inherited on top of a virtual machine monitor. architectural quirks and a requirement to retain compatibil- ity with legacy code. We review how the x86 architecture was originally virtual- ized in the days of the Pentium II (1998), and follow the This impasse was broken twelve years ago when VMware evolution of the virtual machine monitor forward through engineers first virtualized the x86 architecture entirely in the introduction of virtual SMP, 64 bit (x64), and hard- software. By basing the virtual machine monitor (VMM) ware support for virtualization to finish with a contempo- on binary translation, the architectural features that pre- rary challenge, nested virtualization.
    [Show full text]
  • Paper Describes a Technique for Improving Runtime Perfor- Mance of Statically Translated Programs
    Performance, Correctness, Exceptions: Pick Three A Failproof Function Isolation Method for Improving Performance of Translated Binaries Andrea Gussoni Alessandro Di Federico Pietro Fezzardi Giovanni Agosta Politecnico di Milano Politecnico di Milano Politecnico di Milano Politecnico di Milano [email protected] [email protected] [email protected] [email protected] Abstract—Binary translation is the process of taking a pro- existing programs for which the source code is not available, gram compiled for a given CPU architecture and translate it to enabling the analyst to extract insights about its execution that run on another platform without compromising its functionality. would be otherwise very though to obtain. This paper describes a technique for improving runtime perfor- mance of statically translated programs. Binary translation presents two major challenges: func- tional correctness, and performance. Ideally, both are very First, the program to be translated is analyzed to detect important, but in practice any implementation of a binary function boundaries. Then, each function is cloned, isolated and disentangled from the rest of the executable code. This process is translator needs to make trade-offs between them. called function isolation, and it divides the code in two separate On one hand, dynamic binary translators choose to trans- portions: the isolated realm and the non-isolated realm. late code on-the-fly during execution, favoring functional cor- Isolated functions have a simpler control-flow, allowing much rectness. This choice allows to preserve functional correct- more aggressive compiler optimizations to increase performance, ness even in presence of self-modifying code, runtime code but possibly compromising functional correctness.
    [Show full text]
  • 18 a Retargetable Static Binary Translator for the ARM Architecture
    A Retargetable Static Binary Translator for the ARM Architecture BOR-YEH SHEN, WEI-CHUNG HSU, and WUU YANG, National Chiao-Tung University Machines designed with new but incompatible Instruction Set Architecture (ISA) may lack proper applica- tions. Binary translation can address this incompatibility by migrating applications from one legacy ISA to a new one, although binary translation has problems such as code discovery for variable-length ISA and code location issues for handling indirect branches. Dynamic Binary Translation (DBT) has been widely adopted for migrating applications since it avoids those problems. Static Binary Translation (SBT) is a less general solution and has not been actively researched. However, SBT performs more aggressive optimizations, which could yield more compact code and better code quality. Applications translated by SBT can consume less memory, processor cycles, and power than DBT and can be started more quickly. These advantages are even more critical for embedded systems than for general systems. In this article, we designed and implemented a new SBT tool, called LLBT, which translates ARM in- structions into LLVM IRs and then retargets the LLVM IRs to various ISAs, including ×86, ×86–64, ARM, and MIPS. LLBT leverages two important functionalities from LLVM: comprehensive optimizations and 18 retargetability. More importantly, LLBT solves the code discovery problem for ARM/Thumb binaries without resorting to interpretation. LLBT also effectively reduced the size of the address mapping table, making SBT a viable solution for embedded systems. Our experiments based on the EEMBC benchmark suite show that the LLBT-generated code can run more than 6× and 2.3× faster on average than emulation with QEMU and HQEMU, respectively.
    [Show full text]
  • Codbt: a Multi-Source Dynamic Binary Translator Using Hardwareâ
    Journal of Systems Architecture 56 (2010) 500–508 Contents lists available at ScienceDirect Journal of Systems Architecture journal homepage: www.elsevier.com/locate/sysarc CoDBT: A multi-source dynamic binary translator using hardware–software collaborative techniques Haibing Guan, Bo Liu *, Zhengwei Qi, Yindong Yang, Hongbo Yang, Alei Liang Shanghai Jiao Tong University, Shanghai 200240, China article info abstract Article history: For implementing a dynamic binary translation system, traditional software-based solutions suffer from Received 20 September 2009 significant runtime overhead and are not suitable for extra complex optimization. This paper proposes Received in revised form 24 June 2010 using hardware–software collaboration techniques to create an high efficient dynamic binary translation Accepted 24 July 2010 system, CoDBT, which emulates several heterogeneous ISAs (Instruction Set Architectures) on a host pro- Available online 5 August 2010 cessor without changing to the existing processor. We analyze the major performance bottlenecks via evaluating overhead of a pure software-solution DBT. Guidelines are provided for applying a suitable Keywords: hardware–software partition process to CoDBT, as are algorithms for designing hardware-based binary Dynamic binary translation translator and code cache management. An intermediate instruction set is introduced to make Hardware/software collaboration Multi-source multi-source translation more practicable and scalable. Meantime, a novel runtime profiling strategy is Runtime profiling integrated into the infrastructure to collect program hot spots information to supporting potential future optimizations. The advantages of using co-design as an implementation approach for DBT system are assessed by several SPEC benchmarks. Our results demonstrate that significant performance improve- ments can be achieved with appropriate hardware support choices.
    [Show full text]
  • EECS 470 Lecture 20 Binary Translation
    © Wenisch 2007 ‐‐ Portions © Austin, Brehob, Falsafi, Hill, Hoe, Lipasti, Shen, Smith, Sohi, Tyson, Vijaykumar EECS 470 Lecture 20 Binary Translation Fall 2007 Prof. Thomas Wenisch http://www.eecs.umich.edu/courses/eecs4 70 Slides developed in part by Profs. Austin, Brehob, Falsafi, Hill, Hoe, Lipasti, Shen, Smith, Sohi, Tyson, and Vijaykumar of Carnegie Mellon University, Purdue University, University of Michigan, and University of Wisconsin. Lecture 20 EECS 470 Slide 1 © Wenisch 2007 ‐‐ Portions © Austin, Brehob, Falsafi, Hill, Hoe, Lipasti, Shen, Smith, Sohi, Tyson, Vijaykumar Announcements No class Wednesday Project due 12/10 Lecture 20 EECS 470 Slide 2 © Wenisch 2007 ‐‐ Portions © Austin, Brehob, Falsafi, Hill, Hoe, What is Binary TranslationLipasti, Shen, Smith, Sohi, Tyson, Vijaykumar TkiTaking a binary executbltable from a source ISA and generate a new executable in a target ISA such that the new executable has exactly the same functional behavior as the original Same ISA ⇒ Optimization compiler instruction scheduling is a restricted form of translation re‐optim iz ing old binar ies for new, btbut ISA‐compatible, hdhardware Reoptimization can improve performance regardless whether implementation details are exposed by the ISA Across ISAs ⇒ Overcoming binary compatibility two processors are “binary compatible” if they can run the same set of binaries (from BIOS to OS to applications) Strong economic incentive How to get all of the popular software to run on my new processor? How to get my software to run on all of the popular
    [Show full text]
  • Binary Translation Using Peephole Superoptimizers
    Binary Translation Using Peephole Superoptimizers Sorav Bansal Alex Aiken Computer Systems Lab Computer Systems Lab Stanford University Stanford University [email protected] [email protected] Abstract tecture performance for compute-intensive applica- We present a new scheme for performing binary trans- tions. lation that produces code comparable to or better than 2. Because the instruction sets of modern machines existing binary translators with much less engineering tend to be large and idiosyncratic, just writing the effort. Instead of hand-coding the translation from one translation rules from one architecture to another instruction set to another, our approach automatically is a significant engineering challenge, especially if learns translation rules using superoptimization tech- there are significant differences in the semantics of niques. We have implemented a PowerPC-x86 binary the two instruction sets. This problem is exacer- translator and report results on small and large compute- bated by the need to perform optimizations wher- intensive benchmarks. When compared to the native ever possible to minimize problem (1). compiler, our translated code achieves median perfor- mance of 67% on large benchmarks and in some small 3. Because high-performancetranslations must exploit stress tests actually outperforms the native compiler. We architecture-specific semantics to maximize perfor- also report comparisons with the open source binary mance, it is challenging to design a binary translator translator Qemu and a commercial tool, Apple's Rosetta. that can be quickly retargeted to new architectures. We consistently outperform the former and are compara- One popular approach is to design a common inter- ble to or faster than the latter on all but one benchmark.
    [Show full text]
  • Dynamic Binary Translation ∗
    Dynamic Binary Translation ∗ Mark Probst CD Laboratory for Compilation Techniques http://www.complang.tuwien.ac.at/schani/ Abstract get platform, or dynamically, by translating code on the fly. For von Neumann architectures, where This paper presents an overview of dynamic binary code and data reside in the same memory, static bi- translation. Dynamic binary translation is the pro- nary translation is never a complete solution, due to cess of translating code for one instruction set ar- problems such as dynamic linking and self-modifying chitecture to code for another on the fly, i.e., dy- code. Dynamic binary translation overcomes these namically. Dynamic binary translators are used for problems, while at the same time creating new ones. emulation, migration, and recently for the economic Most prominently, dynamic binary translators must implementation of complex instruction set architec- be fast. Otherwise the translation overhead would be tures. higher than the cost of running the translated code. Most of the problems occuring in dynamic binary This paper discusses the most important issues translation are discussed and solutions are presented arising in the design of a dynamic binary transla- and weighed against each other. tor. We will use the terms “foreign” and “native” to Finally, the dynamic binary translator bintrans, distinguish between the platform which is to be em- developed by the author, is presented. ulated and the platform on which the emulator is to be run. 1 Introduction The paper is structured as follows. Section 2 de- scribes the differences between emulating a whole Binary translation is the process of translating ma- hardware platform and emulating the user-level envi- chine code (binaries) from one instruction set archi- ronment which an application sees.
    [Show full text]