Paper Title: The Transmeta Code Morphing Software: Using Speculation, Recovery, and Adaptive Retranslation to Address Real-Life Challenges

Goal:

  • System-level emulation of target ISA and platform (x86) on a host ISA (micro-/hidden ISA) with high performance
    • System-level means the result runs existing OS, BIOS, and any low level code
  • Final product is an processor that is fully compatible with x86 ISA

Users of the system:

  • End users: have x86 programs (OS, BIOS, drivers, existing binaries) but don’t like Intel/AMD/Centaur because:
    • Power: VLIW is simpler in hardware, meaning more efficient and lower power
    • Cost/choice: Monopoly on x86 architecture by Intel/AMD/Centuar
  • Designers: increased flexibility of microarchtecture
  • Target audience of this paper: architects, designers of virtual machine and other binary translators
    • Using architects’ language etc.

Solution:

  • Software for translation with hardware support for translation / executing translated code

Interpreter:

  • One x86 instruction at a time: fetch, decode, execute, commit, repeat.
  • Poor performance

Translator and caching:

  • Natively translate and optimize sequences of instructions that are frequently executed to reduce translation overhead
    • Exists of translated sequence either lead to another translated sequence (chaining) or Interpreter
    • After warmup, hopefully the most of the execution can be performed within the translator
  • Improved performance, but doesn’t always work because of the following problems

Sub-problems that comes with Translator and caching:

  • Performance
    • Not ROB/RS/window to limit instruction scheduling in VLIW machine
    • Branch prediction / exception / control flow
    • Load / store aliasing can break memory consistency and cause I/O issue
      • I/O related issue is addressed using exception
        • Identify memory mapped I/O regions
        • Mark reordered memory accesses
        • Trigger exception when reordered memory accesses touch I/O regions
      • Load / store aliasing is addressed using hardware
        • Gate store instructions (similar to store buffer)
        • Alias hardware instead of expensive LSQ, see reference 20.
  • Self modifying code (SMC)
    • Have to fault and retranslate/reinterpret
    • Detecting the problem:
      • Page-level protection
      • Fine-grained protection
    • Solving the problem:
      • Retranslation is the most basic solution
      • Recognize SMC pattern and restructure the software to avoid self modifying behaviors
      • Cache previous translations (translation groups)
      • Self-revalidating and self-checking
  • Precise exception
    • Conflicts with many techniques commonly used in performance optimization
    • Use extra hardwares (shadow registers in this case) and commit and rollback instructions
    • Rollback to previous state and interpret x86 instruction one at a time
    • Optimization: identify genuine x86 faults and narrow translation size around them
  • I/O
    • See performance and precise exception section

Uniqueness in solution:

  • Converting between ISAs
  • Use interpreter as the fallback of translator
  • Speculation, detection and rollback mechanism
  • Software and hardware codesign
  • Various hardware techniques (alias hardware e.g.)

Evaluation:

  • Benchmarks: SPEC, various OS boots (Windows, DOS, Linux), productivity applications, media applications
    • Little description of these benchmarks
  • Show effectiveness of hardware features by turning them on and off
    • Not convincing because of weak/non-existing baseline
  • Possible improvements on evaluation:
    • Convince the importance of benchmarks
    • Show the utilization of VLIW
    • Compare performance with native x86 solutions (the high performance part of the goal)

Next lecture: Influence on other users Background and history on Transmeta