Dynamic recompilation: Difference between revisions
Tags: Mobile edit Mobile web edit |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{for|more|High and low-level emulation#Modern Dependencies, Advancements and Optimization Strategies}} | |||
'''Dynamic recompilation''' (sometimes abbreviated to '''dynarec''' or '''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. | '''Dynamic recompilation''' (sometimes abbreviated to '''dynarec''' or '''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. | ||
==Accuracy and Relationship with Interpreters== | |||
While dynamic recompilers offer immense performance benefits over standard execution methods, a common misconception is that an interpreter is inherently "more accurate" than a recompiler. In reality, interpretation and recompilation are simply different execution strategies. | |||
Interpreters generally achieve higher accuracy earlier in development because their execution model is more flexible and straightforward to debug. However, if a development team focuses heavily on optimization and edge cases within the recompiler while neglecting the interpreter, the interpreter can become less accurate over time. | |||
In modern emulation software development, this imbalance is rare. Most development teams maintain a robust interpreter to serve as a baseline reference model. When bugs appear in the recompiled code, developers use the interpreter's behavior to pinpoint and fix flaws in the recompiler's logic: a relationship highly analogous to using a pixel-accurate software renderer to debug a high-performance hardware renderer. | |||
==Uses== | ==Uses== | ||
| Line 61: | Line 68: | ||
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). | 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). | ||
==See also== | ==See also== | ||
| Line 93: | Line 81: | ||
*[http://web.archive.org/web/20051018182930/www.zenogais.net/Projects/Tutorials/Dynamic%20Recompiler.html Dynamic recompiler tutorial] | *[http://web.archive.org/web/20051018182930/www.zenogais.net/Projects/Tutorials/Dynamic%20Recompiler.html Dynamic recompiler tutorial] | ||
*[http://emulatemii.com/wordpress/?tag=dynarec Blog posts about writing a MIPS to PPC dynamic recompiler] | *[http://emulatemii.com/wordpress/?tag=dynarec Blog posts about writing a MIPS to PPC dynamic recompiler] | ||
*[https://llvm.org/ LLVM] | |||
*[https://www.phoronix.com/news/TPDE-Faster-Compile-Than-LLVM TPDE] | |||
[[Category:Wikipedia copies]] | [[Category:Wikipedia copies]] | ||