Problem

  • x86 complex, higher power
  • want non-x86 microarchitecture that’s fully compatible from system perspective with x86
  • existing approach for mimicing other hardware were really for emulation
    • didn’t handle important cases such as exceptions, interrupts, IO, self-modifying-code, speculative execution/memory reording

(aside: exceptions are defined in the ISA, interrupts are not. Interrupts are serviced when convienient)

Intended users

  • any x86 user/programmer/system builder
  • trading off performance for power
  • consumer oriented
  • paper mentionned QNX, which is a real-time/embedded OS
    • strange, because Code Morphing Software adds variability to execution time

Solution

  • VLIW pipeline(simple/low power)
  • online HW/SW translation from x86 → VLIW
  • speculatively reorders memory operations and code
    • why??
    • need to speculate to create long scheduling blocks in order to extract enough parallelism to fill the VLIW “molecules”
      • otherwise, each basic block is only ~5 instructions on average
    • the same way superscalar, out-of-order cores extract ILP from sequential instruction streams via register renaming

(aside: x86 micro-ops vs. “atoms” in Transmeta)

  • what happens on mispeculation?
    • on out-of-order: flush pipeline!
    • on Transmeta: commit/rollback
      • maintains “shadow state”, occasionally commits speculative state to shadow state once everything is safe
      • on mispeculation, roll back to last commit point
    • what’s the difference between the two approaches? granularity
      • out-of-order approach is akin to very fine-grained commit/rollback: i.e. every instruction is a “commit point”!
      • with shadow state approach, commit points are much more sparse
    • need special HW to detect bad memory reordering - i.e. load/store queue
  • self-modifying-code
    • used to be common optimization technique, now frowned upon
      • allowed tighter code (important in space-constrained environments, e.g. boot sequences)
    • original approach: page-level protection on writes to pages containing code
      • led to many unnecessary protection faults
    • new version added more fine-grained protection mechanisms, but only for few pages (not all of them)

Evaluation

  • unconvincing
  • obtained performance numbers from simulator
  • measured performance with and without certain optimizations (i.e. supressing memory reordering)
  • didn’t tell you how often things happened (i.e. how often memory reordering occured)
  • no baseline

Other remarks

  • neat idea: software monitors performance (hardware can’t do this that well) and identifies where to optimize
    • might be good for high-performance code, since the same code is often repeatedly executed