World Library  
Flag as Inappropriate
Email this Article

Dynamic recompilation

Article Id: WHEBN0000175417
Reproduction Date:

Title: Dynamic recompilation  
Author: World Heritage Encyclopedia
Language: English
Subject: Java performance, Compiler construction, Binary translation, Adaptive optimization, Emulation software
Collection: Compiler Construction, Emulation Software, Virtualization Software
Publisher: World Heritage Encyclopedia

Dynamic recompilation

In computer science, dynamic recompilation (sometimes abbreviated to dynarec or the pseudo-acronym DRC) is a feature of some emulators and virtual machines, where the system may recompile some part of a program during execution. By compiling during execution, the system can tailor the generated code to reflect the program's run-time environment, and potentially produce more efficient code by exploiting information that is not available to a traditional static compiler.


  • Uses 1
  • Tasks 2
  • Example 3
  • Applications 4
    • General purpose 4.1
    • Gaming 4.2
  • See also 5
  • References 6
  • External links 7


Most dynamic recompilers are used to convert machine code between architectures at runtime. This is a task often needed in the emulation of legacy gaming platforms. In other cases, a system may employ dynamic recompilation as part of an adaptive optimization strategy to execute a portable program representation such as Java or .NET Common Language Runtime bytecodes. Full-speed debuggers also utilize dynamic recompilation to reduce the space overhead incurred in most deoptimization techniques, and other features such as dynamic thread migration.


The main tasks a dynamic recompiler has to perform are:

  • Reading in machine code from the source platform
  • Emitting machine code for the target platform

A dynamic recompiler may also perform some auxiliary tasks:

  • Managing a cache of recompiled code
  • Updating of elapsed cycle counts on platforms with cycle count registers
  • Management of interrupt checking
  • Providing an interface to virtualized support hardware, for example a GPU
  • Optimizing higher level code structures to run efficiently on the target hardware (see below)


Suppose a program is being run in an emulator and needs to copy a null-terminated string. The program is compiled originally for a very simple processor. This processor can only copy a byte at a time, and must do so by first reading it from the source string into a register, then writing it from that register into the destination string. The original program might look something like this:

    mov A,[first string pointer]    ; Put location of first character of source string
                                    ; in register A
    mov B,[second string pointer]   ; Put location of first character of destination string
                                    ; in register B
    mov C,[A]            ; Copy byte at address in register A to register C
    mov [B],C            ; Copy byte in register C to the address in register B
    inc A                ; Increment the address in register A to point to
                         ; the next byte
    inc B                ; Increment the address in register B to point to
                         ; the next byte
    cmp C,#0             ; Compare the data we just copied to 0 (string end marker)
    jnz loop             ; If it wasn't 0 then we have more to copy, so go back
                         ; and copy the next byte
end:                     ; If we didn't loop then we must have finished,
                         ; so carry on with something else.

The emulator might be running on a processor which is similar, but extremely good at copying strings, and the emulator knows it can take advantage of this. It might recognize the string copy sequence of instructions and decide to rewrite them more efficiently just before execution, to speed up the emulation.

Say there is an instruction on our new processor called movs, specifically designed to copy strings efficiently. Our theoretical movs instruction copies 16 bytes at a time, without having to load them into register C in between, but will stop if it copies a 0 byte (which marks the end of a string) and set the zero flag. It also knows that the addresses of the strings will be in registers A and B, so it increments A and B by 16 every time it executes, ready for the next copy.

Our new recompiled code might look something like this:

    mov A,[first string pointer]    ; Put location of first character of source string
                                    ; in register A
    mov B,[second string pointer]   ; Put location of first character of destination string
                                    ; in register B
    movs [B],[A]            ; Copy 16 bytes at address in register A to address
                            ; in register B, then increment A and B by 16
    jnz loop                ; If the zero flag isn't set then we haven't reached
                            ; the end of the string, so go back and copy some more.
end:                        ; If we didn't loop then we must have finished,
                            ; so carry on with something else.

There is an immediate speed benefit simply because the processor doesn't have to load so many instructions to do the same task, but also because the movs instruction is likely to be optimized by the processor designer to be more efficient than the sequence used in the first example. (For example, it may make better use of parallel execution in the processor to increment A and B while it is still copying bytes).


General purpose

  • Many Java virtual machines feature dynamic recompilation.
  • Apple's Rosetta for Mac OS X on x86, allows PowerPC code to be run on the x86 architecture.
  • Later versions of the Mac 68K emulator used in Mac OS to run 680x0 code on the PowerPC hardware.
  • Psyco, a specializing compiler for Python.
  • The HP Dynamo project, an example of a transparent binary dynamic optimizer.[1]
  • The Vx32 virtual machine employs dynamic recompilation to create OS-independent x86 architecture sandboxes for safe application plugins.
  • Microsoft Virtual PC for Mac, used to run x86 code on PowerPC.
  • QEMU, an open-source full system emulator.
  • FreeKEYB, an international DOS keyboard and console driver with many usability enhancements utilized self-modifying code and dynamic dead code elimination to minimize its in-memory image based on its user configuration (selected features, languages, layouts) and actual runtime environment (OS variant and version, loaded drivers, underlying hardware), automatically resolving dependencies, dynamically relocating and recombining code sections on byte-level granularity and optimizing opstrings based on semantic information provided in the source code, relocation information generated by special tools during assembly and profile information obtained at load time.[2][3]
  • OVPsim,[4] a freely-available full system emulator.
  • VirtualBox uses dynamic recompilation
  • Valgrind, a programming tool for memory debugging, memory leak detection, and profiling, uses dynamic recompilation.


See also


  1. ^ "HP Labs' technical report on Dynamo". 
  2. ^ Paul, Matthias; Frinke, Axel C. (1997-10-13) [first published 1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (v6.5 ed.), NB. FreeKEYB is a  
  3. ^ Paul, Matthias; Frinke, Axel C. (2006-01-16), FreeKEYB - Advanced international DOS keyboard and console driver (User Manual) (v7 preliminary ed.) 
  4. ^ "OVPsim". 
  5. ^ Mupen64Plus
  6. ^ "SH2". 
  7. ^ "PCSX 2". 
  8. ^ petebernert. "GCemu". SourceForge. 
  9. ^ "Gameboy Emulator for MSX | The New Image". GEM. Retrieved 2014-01-12. 
  10. ^ "DeSmuME v0.9.9". 
  11. ^ Publicado por Carlos Ballesteros Velasco (2013-07-28). "Soywiz's PSP Emulator: Release : Soywiz's Psp Emulator 2013-07-28 (r525)". Retrieved 2014-01-12. 

External links

  • Dynamic recompiler tutorial
  • Blog posts about writing a MIPS to PPC dynamic recompiler
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from World eBook Library are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.