Microcode Simulation
Total Page：16
File Type：pdf, Size：1020Kb
Fast Microcode Interpretation with Transactional Commit/Abort Jens Troger¨ Darek Mihockaˇ Pardo [email protected] [email protected] [email protected] Abstract Keywords: functional system simulation, microcode interpre- tation, binary translation, instrumentation This paper describes the design and implementation of a fast microcode interpreter for functional system simula- tion. While we primarily target architecture simulation, the 1. Introduction design principles can easily be applied to high-level and byte-code interpreters as well. System simulation allows for execution of system level A functional system simulator executes an entire guest software in a controlled software environment. The si- operating system stack and applications, inside a soft- mulator implements a ”guest” CPU architecture, physical ware simulated environment. Such simulators do not simu- memory, TLBs, optionally caches, and some essential de- late cycle accuracy, but run fast enough to run real-world vices like timers and serial I/O devices. The goal is to run workloads. System simulators depend on the architecture unmodified firmware and an operating system stack with of both guest and host, so are traditionally hand-written applications, ideally with the guest software unable to de- and tailored to the respective architectures. Performance tect it is not running on real hardware. The system simula- optimizations like dynamic compilation to host code or as- tor itself is an application that runs on the ”host” machine. sembly coding of key routines are common, but further System simulation has many applications. One com- increase host and guest dependency. The interpreter de- mon use is migration of legacy software to new and dif- scribed here is substantially independent of the host, is ferent host architectures. Architecture research and exper- easily retargeted to new guests, yet achieves performance imentation uses simulation to explore novel features with- competitive with much more hand-crafted simulators. out building hardware, and to collect detailed information Most functional simulators implement a traditional used to refine proposed new features. Simulators can sand- guest instruction set with simple and independent opera- box a guest software stack in a secure and controlled execu- tions such as loads, adds, and so on. In contrast, simu- tion environment for scalable cloud computing. Simulators lating microcode is difficult because each instruction has are also used for debugging low-level code where using a many sub-operations – which may depend on each other, debugger on real hardware is hard, and for developing and and which must atomically commit or abort as a single validating code where new hardware does not yet exist. Fi- transaction. This paper describes techniques for high- nally, a system simulator can observe, log, and manipulate performance transactional simulation. a guest software stack, thus collecting arbitrary informa- The paper measures real-world workloads like Win- tion about the dynamic behavior of the guest software and dows71 and Linux boot, and application runs of Office, web allowing performance analysis and tuning that is difficult browsers, and more. We also report very machine specific or impossible on real hardware. performance details using micro-benchmarks. We then use There are many approaches to simulation, depending that data as a guide for the design and implementation of on the desired accuracy. For example, cycle- and timing- an interpreter that achieves high performance, host porta- accurate simulators mimic low-level implementation de- bility via coding in ”plain” C++, and guest retargetability tails of guests. Performance data is accurate, but may cost via a machine-generated instruction parser and abstracted thousands or millions of host cycles to accurately simu- operations that are reused in retargeting. late bus contention, full-buffer stalls, and so on. The slow Initial results show execution on modern processors as speed usually limits what software can be run. Conversely, fast as a few tens of host cycles per simulated guest in- functional simulators hide many details of the guest, to im- struction, thus executing hundreds of millions operations prove simulation speed. As a result, functional simulators per second, and tens to hundreds of millions of guest in- can boot and run modern operating system stacks, execut- structions per second, depending on their complexity. ing billions of guest instructions in tens of seconds. 1Trade names in this paper are the property of their owners. Even among functional simulators, there are many ap- proaches. Decode-and-dispatch interpreters are often sim- • what common and dominant guest workloads users plest to build, but may take a thousand host cycles per will run; simulated guest instruction. Instruction decode cost often dominates simulation speed, so threaded-code simulators • what critical interpreter paths dominate performance that cache decoded results are often much faster. Dynamic of these guest workloads; and cross compilation is faster yet because it can reduce inter- • instruction simulation costs, but code generators are a sig- how these paths are best executed on a given host ma- nificant effort to build and retarget [EG03]. Finally, user- chine. level simulation often provides highest performance and For guest operations, it is important to measure large simplest implementation, but is only able to run limited workloads that are representative of what will be used software and cannot observe system details. in simulation, since ”inner loop” benchmarks often hide Most simulators in the literature are for guests with rel- system-level behavior that in practice can dominate total atively simple instructions. Even ”complex” instructions, simulation cost. sin such as floating-point , are still conceptually orthogo- For host operations, it is important to measure processor nal and independent of other instructions. Microcode sim- performance in detail, to ensure the simulator makes good ulation is more complex, because each instruction is com- use of the hardware microarchitecture, since small differ- posed of sub-operations that may have interdependencies, ences in cost often have a big impact on running time. can give rise to several simultaneous exceptions, and which complete atomically. For example, a single microcode in- 2.1. Application Benchmarks struction may include memory, integer ALU, floating-point ALU, and branch sub-operations; a compare sub-operation We use guest workload data to discover what guest op- may be forwarded to conditional branch logic in the same erations are common or rare, and thus drive performance microinstruction; multiple units may give rise to excep- decisions in the simulator design. tions, which need to be prioritized; and results from all sub-operations follow atomic commit/abort semantics. Ex- A workload is the code executed and data consumed by isting simulator designs are poorly-suited to simulate such an application to solve a given problem. A benchmark ex- a machine. ercises one or several dedicated workloads. One widely- This paper discusses challenges implementing a used benchmark is SPEC [Cor10]. SPEC CPU, for in- portable and high performance functional system-level in- stance, is ”designed to provide performance measurements terpreter. The simulator is written in C++ and is easily ... used to compare compute-intensive workloads on differ- recompiled on different hosts. It avoids most direct host ent computer systems.” Other SPEC benchmarks focus on dependencies – for example, it avoids multiplexing guest power consumption, render speed and 3D workflows, par- condition codes on to host condition codes, and host/guest allel computation, server loads for virtual machines, and so endianess affects performance but not correctness. The forth. simulator is easily retargeted to different guest ISAs and Another common approach is to run real-world appli- gives good performance for both conventional macro in- cations concurrently so they compete with each other for struction sets and complex microcode. resources. One scenario, for example, is running a web Section 2 discusses different types of workloads and browser that renders media content, while also checking benchmarks, their application, and how they influence the email or playing a game. The data we used to design our design of our interpreter. Section 3 analyzes how design fast interpreter is largely from such real world scenarios, decisions of existing interpreters and dynamic compilers and less from benchmarks. for system simulators affect their performance. Section 4 describes our internal virtual microcode architecture, and 2.2. Micro-Benchmarks introduces the design and implementation of our fast and portable microcode interpreter. Finally, section 5 presents We use micro-benchmarks to understand performance initial performance results of our interpreter which demon- bottlenecks of a host CPU, and use that data to design the strate the feasibility and benefits of our design. data and code layout of our fast interpreter. A micro-benchmark is a short sequence of instructions that exercises one particular feature of the CPU. Listing 1 2. Workloads and Benchmarks shows a micro-benchmark we designed to measure la- tency of the x86 lahf instruction, an instruction often A fast simulator must run common operations quickly. used by interpreters and dynamic instrumentation tools to To design one, we need to understand: retrieve some host arithmetic