Being an execution-driven simulator, Proteus relies upon the host processor to execute the programs that run on the simulated system. However, Proteus simulates execution timing by augmenting the programs with cycle counting code at every basic block. A basic block here has one entry point and ends with a control transfer instruction (branch, jump, call) or with simulator code (memory access or reading the cycle counter). Each instruction has been assigned a weight (currently compiled into augment), a weight for a basic block is the total weight of instructions in the block. The number of cycles to execute the block (on the simulated system) is the weight divided by the effective issue rate (rounded up).
Before version L3.11, most instructions had a weight of 1 (even floating point divide), and the number of cycles to execute a block was simply its weight. Other simulation parameters would have to be scaled to model most multiple-issue and single-issue processors.
In version L3.11 instruction weights are based on the UltraSparc-II processor, with a weight of 12 for single-precision fp divide and square root, and 22 for double precision; all others are one. Starting with version L3.11 the issue rate of the simulated CPU can be adjusted, albeit in crude fashion.
Since Proteus does not perform detailed microarchitecture simulation, one cannot simply specify functional units and an issue rate for the simulated system, such as 4 for a 4-way superscalar system. Instead, an effective issue rate is used, which should include the effect of branch stalls and resource conflicts, but which should not include cache stalls, which are of course simulated. The effective issue rate is specified by parameters `EFF_ISSUE_RATE', `CYC_LIB', and `CYC_LIB_M'in file `cpu.param'.
Macro `EFF_ISSUE_RATE' specifies the effective issue rate for SimMake-compiled code (the code in the user's working directory), and the libraries too, if `CYC_LIB', and `CYC_LIB_M' are undefined (in which case libraries must be available at the issue rate specified). If libraries are not available at the desired rate, then `CYC_LIB' and `CYC_LIB_M' can be set to the closest match. Libraries are named `libcycXX.a', where XX is 10 times the effective issue rate, truncated to an integer. (E.g., `libcycm27.a' is the name of a math library for an issue rate of 2.7.)
Effective issue rate would be set to account for resource conflicts (e.g., two FP multiply instructions can be started per cycle out of four that can be issued), branch stalls, etc. In code where there was a true data dependence between every adjacent instruction pair the weights chosen would clearly yield cycle counts that are too low; for less extreme code and with an appropriate effective issue rate, a simulated issue rate suitable for studying parallel systems is attainable.
To build libraries at a particular speed, make `lib_src' the current directory and execute the command `MakeSize' EIF, where EIF is the desired issue rate.