Source files: src/Processor/mainsim.cc, src/Processor/simio.cc, src/Processor/config.cc, src/Processor/exec.cc, src/Processor/units.cc, src/Processor/funcs.cc, src/Processor/traptable.cc, src/MemSys/architecture.c, src/MemSys/net.c, src/Processor/state.cc, src/Processor/startup.cc
Header files: incl/Processor/mainsim.h, incl/Processor/simio.h, incl/Processor/units.h, incl/MemSys/arch.h
RSIM execution starts with the main function provided by YACSIM. This function takes the arguments passed in on the command line and passes them to the UserMain function.
The first purpose of the UserMain function is to parse the command-line arguments. The appropriate global variables (e.g., the size of the active list, the number of register windows) are set based on the options described in Chapter 4.
The various input and output files used by the simulator and application are redirected according to the command-line options. The FILE data structures called simin, simout, and simerr are set up through the SimIOInit function; if the simulator input and output are redirected separately from the application input and output, the function RedirectSimIO is called to point these to the appropriate files.
Next, the function ParseConfigFile is invoked to read in the options from the configuration file (described in Chapter 4) and set global simulation variables based on these options. Each parameter recognized by ParseConfigFile is associated with a global variable and a parsing function in the table called configparams. The parsing function is used to convert the operand given for a parameter into an acceptable input value. For example, the ConfigureCacheProt function converts the protocol names ``mesi'' and ``msi'' to values of type enum CacheCoherenceProtocolType, while the ConfigureInt function merely calls atoi to read a string into an integer variable. The parameter names and values are currently case-insensitive. If the user adds any new entries to this table, the macro NUM_CONFIG_ENTRIES must also be changed accordingly.
The application to be simulated is chosen based on the command line options. The predecoded version of the application executable is read through the read_instructions function. This sets the num_instructions variable according to the number of instructions in the application. The hash table for the SharedPageTable structure is initialized, and initially contains no elements.
UserMain calls the UnitArraySetup function, which defines the functional unit used by each of the instruction types. For memory instructions, this function also specifies the type of memory access and the amount of data read or written by each memory instruction, as well as the address alignment needed.
The FuncTableSetup function is called next to assign each instruction type to the function that emulates its behavior at the functional units. After this, the function TrapTableInit sets up the instruction lists for the simulator traps that are actually simulated (as opposed to only having their effects emulated). These traps include window traps and stores of the floating-point status register.
Next, the SystemInit function is called to set up the RSIM memory system and multiprocessor interconnection network according to the parameters earlier read from the configuration file with ParseConfigFile. After setting some basic parameters according to whether or not certain features are present (such as the write-buffer or pipelined network switches), this function calls dir_net_init. More information about dir_net_init is provided in Section 12.3.
After this point, the first processor data structure (or state) is created. The constructor for this structure sets up fundamental state parameters and initializes the auxiliary data structures used in the processor pipeline (described in Section 10.9).
Now that the first processor data structure has been created, the system must load the application executable and data segment into the processor's address space, and must initialize the processor's stack and register set. The startup function performs each of these actions. For systems with ELF, startup interfaces with the ELF library to extract the relevant sections from the application file; for systems without ELF, startup relies on a version of the application file preprocessed with the unelf utility discussed in Section 2. The stack is set up to hold the command line arguments passed to the application, and the registers %o0 and %o1 are set up to hold the corresponding values of argc and argv. (Environment variables are not currently supported.) The PC (processor program counter) is set to the entry point of the application executable, while the NPC (next program counter) points to the subsequent instruction.
After this point, the RSIM_EVENT function is scheduled for execution using YACSIM, and the event-driven simulator is started.