Internals of SimpleScalar Simulators

1. Internals of SimpleScalar Simulators CPEG323 Tutorial Long Chen November, 2005

2. Outline • The SimpleScalar Instruction Set • Internal structure of the SimpleScalar simulator • Software architecture of the simulator • Some important modules • About the project

3. The SimpleScalar Instruction Set • Clean and simple instruction set architecture: • MIPS + more addressing modes • Bi-endian instruction set definition • Facilitetes portability, build to match host endian • 64-bit inst encoding facilitates instruction set research • 16-bit space for hints, new insts, and annotations • Four operand instruction format, up to 256 registers

4. Simulation Architected State

5. Outline • The SimpleScalar Instruction Set • Internal structure of the SimpleScalar simulator • Software architecture of the simulator • Important modules • About the project

6. SimulatorStructure

7. Outline • The SimpleScalar Instruction Set • Internal structure of the SimpleScalar simulator • Software architecture of the simulator • Important modules • About the project

8. Simulator Software Architecture • Interface programming style • All “.c” files have an accompanying “.h” file with same base • “.h” files define public interfaces “exported” by module • Mostly stable, documented with comments, studying these files • “.c” files implement the exported interfaces • Not as stable, study these if you need to hack the functionality • Simulator modules • “sim-*.c” files, each implements a complete simulator core • Reusable S/W components facilitate “rolling your own” • System components • Simulation components • Additional “really useful” components

9. Brief Source Roadmap Start point: main.c Simulator cores sim-fast, sim-safe … Options parsing: options.[c,h] Loader: loader.[c,h] System Call: syscall.[c,h] ISA Def: machine.def ISA routines: machine.[c,h] Memory: memory.[c,h] Cache: cache.[c,h] Register: regs.[c,h]

10. Machine Definition File (machine.def) • A single file describes all aspects of the architecture • Used to generate decoders, dependency analyzers, functional components, disassemblers, appendices, etc. • e.g., machine definition + ~30 line main = functional simulator • Generates fast and reliable codes with minimum effort • Instruction definition example: #define OR_IMPL \ { \ SET_GPR(RD, GPR(RS) | GPR(RT)); \ } DEFINST(OR, 0x50, "or", "d,s,t", IntALU, F_ICOMP, DGPR(RD), DNA, DGPR(RS), DGPR(RT), DNA) semantics opcode disassembly template operands FU req’s inst flags input deps output deps

11. SimpleScalar ISA Module (machine.[hc]) • Macros to expedite the processing of instructions • Constants needed across simulators, for example, the size of the register file • Examples: • /* returns the opcode field value of SimpleScalar instruction INST */ • #define MD_OPFIELD(INST) (INST.a & 0xff) • #define MD_SET_OPCODE(OP, INST) ((OP) = ((INST).a & 0xff)) • /* inst -> enum md_opcode mapping, use this macro to decode insts */ • #define MD_OP_ENUM(MSK) (md_mask2op[MSK]) • /* enum md_opcode -> description string */ • #define MD_OP_NAME(OP) (md_op2name[OP]) • /* enum md_opcode -> opcode operand format, used by disassembler */ • #define MD_OP_FORMAT(OP) (md_op2format[OP]) • /* enum md_opcode -> opcode flags, used by simulators */ • #define MD_OP_FLAGS(OP) (md_op2flags[OP]) • /* disassemble an instruction */ • void md_print_insn(md_inst_t inst, md_addr_t pc, FILE*stream);

12. Instruction Field Accessors

13. Instruction Semantics Specification

14. Main Loop (sim-fast.c) /* set up initial default next PC */ regs.regs_NPC = regs.regs_PC + sizeof(md_inst_t); while (TRUE) { /* maintain $r0 semantics */ regs.regs_R[MD_REG_ZERO] = 0; /* keep an instruction count */ #ifndef NO_INSN_COUNT sim_num_insn++; #endif /* !NO_INSN_COUNT */ /* load instruction */ MD_FETCH_INST(inst, mem, regs.regs_PC); /* decode the instruction */ MD_SET_OPCODE(op, inst); /* execute the instruction */ switch (op) { #define DEFINST(OP,MSK,NAME,OPFORM,RES,FLAGS,O1,O2,I1,I2,I3) \ case OP: \ SYMCAT(OP,_IMPL); \ break; #include "machine.def" default: panic("attempted to execute a bogus opcode"); } /* execute next instruction */ regs.regs_PC = regs.regs_NPC; regs.regs_NPC += sizeof(md_inst_t); } The instruction is executed in a shot here, consider the pipeline approach in the project requirement

15. Outline • The SimpleScalar Instruction Set • Internal structure of the SimpleScalar simulator • Software architecture of the simulator • Important modules • About the project

16. Memory Module (memory.[hc]) • Functions for reading from, writing to, initializing and dumping the contents of the main memory

17. Register Module (reg.[hc]) • Functions to initialize the register files and dump their contents • Access non-speculative register directly, • e.g., regs_R[5] = 12 • e.g., regs_F.f[4] = 23.5; • Floating point register file supports three views • integer word • single-precision, • double-precision /* floating point register file format */ union regs_FP_t { md_gpr_t l[MD_NUM_FREGS]; /* integer word view */ md_SS_FLOAT_TYPE f[SS_NUM_REGS]; /* single-precision FP view */ SS_DOUBLE_TYPE d[SS_NUM_REGS/2]; /* double-precision FP view */ }; /* floating point register file */ extern union md_regs_FP_t regs_F; /* (signed) hi register, holds mult/div results */ extern SS_WORD_TYPE regs_HI; /* (signed) lo register, holds mult/div results */ extern SS_WORD_TYPE regs_LO; /* program counter */ extern SS_ADDR_TYPE regs_PC;

18. Loader Module (loader.[hc])

19. Other Modules • cache.[hc]: general functions to support multiple cache types (you may pay attention to this part for the coming project) • misc.[hc]: numerious useful support functions, such as warn(), info(), elapsed_time() • options.[hc]: process command-line arguments • sim.h: a few extern variable declarations and function prototypes

20. Outline • The SimpleScalar Instruction Set • Internal structure of the SimpleScalar simulator • Software architecture of the simulator • Important modules • About the project

21. Hints for the Phase 2 • sim-safe is the simplest simulator • In the main loop of the original code, there are three steps to fetch inst, decode inst, and execute inst. Although this is not a pipeline, you can start with it • In this phase, you only need to take care of the data dependency among instructions, no need to consider the execution latency • Therefore, all instructions take 5 cycles to complete in the 5-stage pipeline (each stage takes 1 cycle) if there is no need to stall the pipeline because of dependencies • But, keep in mind that this is not true in the real world. For example, load may need 30 cycles to complete in the real case, while add may need 5 cycles. You are going to deal with the timing problem in the coming project

22. What are Expected? • In your project report • How to formulate the problem? • What is your detailed design? • How to distribute the workload among members? • Any problems with the design during the implementation? How did you improve it? • What is the result? Any things could be done better? • Copy of the source code you added/modified with proper comments (printing the entire file is a waste of tree and time) • Email me the source code you added/modified, with a short description

23. Have fun with the simulator 