Difference between revisions of "Execution Basics"

From gem5
Jump to: navigation, search
(StaticInsts)
(Execution Basics)
Line 18: Line 18:
  
 
Each ISA instruction derives from StaticInst and implements its own constructor, the execute() function, and, if it is a memory instruction, the memory access functions.  See [[ISA_description_system]] for details about how these ISA instructions are specified.
 
Each ISA instruction derives from StaticInst and implements its own constructor, the execute() function, and, if it is a memory instruction, the memory access functions.  See [[ISA_description_system]] for details about how these ISA instructions are specified.
 +
 +
===DynInsts===
 +
The DynInst is used to hold dynamic information about instructions.  This is necessary for more detailed models or out-of-order models, both of which may need extra information beyond the [[StaticInst]] in order to correctly execute instructions.
 +
 +
Some of the dynamic information that it stores includes:
 +
* The PC of the instruction
 +
* The renamed register indices of the source and destination registers
 +
* The predicted next-PC
 +
* The instruction result
 +
* The thread number of the instruction
 +
* The CPU the instruction is executing on
 +
* Whether or not the instruction is squashed
 +
 +
Additionally the DynInst provides the [[ExecContext]] interface.  When ISA instructions are executed, the DynInst is passed in as the ExecContext, handling all accesses of the ISA to CPU state.
 +
 +
Detailed CPU models can derive from DynInst and create their own specific DynInst subclasses that implement any additional state or functions that might be needed.  See src/cpu/o3/alpha/dyn_inst.hh for an example of this.
 +
  
 
===Microcode support===
 
===Microcode support===

Revision as of 17:22, 19 March 2011

Execution Basics

Predecoding

StaticInsts

The StaticInst provides all static information and methods for a binary instruction.

It holds the following information/methods:

  • Flags to tell what kind of instruction it is (integer, floating point, branch, memory barrier, etc.)
  • The op class of the instruction
  • The number of source and destination registers
  • The number of integer and FP registers used
  • Method to decode a binary instruction into a StaticInst
  • Virtual function execute(), which defines how the specific architectural actions taken for an instruction (e.g. read r1, r2, add them and store in r3.)
  • Virtual functions to handle starting and completing memory operations
  • Virtual functions to execute the address calculation and memory access separately for models that split memory operations into two operations
  • Method to disassemble the instruction, printing it out in a human readable format. (e.g. addq r1 r2 r3)

It does not have dynamic information, such as the PC of the instruction or the values of the source registers or the result. This allows a 1 to 1 mapping of StaticInst to unique binary machine instructions. We take advantage of this fact by caching the mapping of a binary instruction to a StaticInst in a hash_map, allowing us to decode a binary instruction only once, and directly using the StaticInst the rest of the time.

Each ISA instruction derives from StaticInst and implements its own constructor, the execute() function, and, if it is a memory instruction, the memory access functions. See ISA_description_system for details about how these ISA instructions are specified.

DynInsts

The DynInst is used to hold dynamic information about instructions. This is necessary for more detailed models or out-of-order models, both of which may need extra information beyond the StaticInst in order to correctly execute instructions.

Some of the dynamic information that it stores includes:

  • The PC of the instruction
  • The renamed register indices of the source and destination registers
  • The predicted next-PC
  • The instruction result
  • The thread number of the instruction
  • The CPU the instruction is executing on
  • Whether or not the instruction is squashed

Additionally the DynInst provides the ExecContext interface. When ISA instructions are executed, the DynInst is passed in as the ExecContext, handling all accesses of the ISA to CPU state.

Detailed CPU models can derive from DynInst and create their own specific DynInst subclasses that implement any additional state or functions that might be needed. See src/cpu/o3/alpha/dyn_inst.hh for an example of this.


Microcode support

ExecContext

ThreadContext

Faults