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)

The impact of using TRANSMETA CMS for various users:

  • CMS is a solution for the users who are interested in using VLIW than x86 machine
  • For embedded application
    • (-) code size becomes blown-up by translation
    • (+) high efficiency / low power
  • For Server application
    • Many IO accesses could decrease system performance with small translation size, and have to x86 code in-order execution with exception penalty
    • Size of code
      • HPC can form bigger translation which increases execution optimization
      • Database server has small sized codes (may not be able to utilize potential optimization)
  • DVFS is available at VLIW
  • Where is translation stored?
    • If the translation is stored at disk, we need to access the IO bus. And, if x86 does not support it, storing the information at x86 could be problematic.
    • In order to store the translation at memory, some part of memory space should be spared for VLIW code The method is not specifically addressed in the paper, but the translation is stored at memory (with software visible address space).

Generalization for the class:

  • Hardware & Software co-design
  • The evaluations have some pitfalls
  • Dynamic translation is powerful tool
  • Supporting compatibility brings benefits and costs
  • General approaches such as Rollback is applied to different hierarchy
  • We all knew the examined approaches - but can be better used with software support (always a way to improve more)

Other comments during the class:

  • VLIW machine is still used in DSP and image processing
  • Register Window – to solve the shortage of architectural register number. Different set of registers are supported for different programs by storing the register values on stack.

Additional Information:

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