Instruction set simulator

Instruction simulation is a methodology employed for one of several possible reasons:

• To simulate the instruction set architecture (ISA) of a future processor to allow software development and test to proceed without waiting for the development and production of the hardware to finish. This is often known as "shift-left" or "pre-silicon support" in the hardware development field. A full system simulator or virtual platform for the future hardware typically includes one or more instruction set simulators.
• To simulate the machine code of another hardware device or entire computer for upward compatibility.

For example, the IBM 1401 was simulated on the later IBM/360 through use of microcode emulation.

• To monitor and execute the machine code instructions (but treated as an input stream) on the same hardware for test and debugging purposes, e.g. with memory protection (which protects against accidental or deliberate buffer overflow).
• To improve the speed performance—compared to a slower cycle-accurate simulator—of simulations involving a processor core where the processor itself is not one of the elements being verified; in hardware description language design using Verilog where simulation with tools like ISS can be run faster by means of "PLI" (not to be confused with PL/1, which is a programming language).

Implementation

Instruction-set simulators can be implemented using three main techniques:

• Interpretation, where each instruction is executed directly by the ISS.
• Just-in-time compilation (JIT), where the code to be executed is first translated into the instruction set of the host computer. This is typically about ten times faster than a well-optimized interpreter.
• Virtualization, where processor extensions for virtual machines are used to execute instructions in the ISS. This only works for same-on-same instruction-set simulation, such as running x86 simulators on x86 hosts, or ARM simulators on ARM hosts.

An ISS is often provided with (or is itself) a debugger in order for a software engineer/programmer to debug the program prior to obtaining target hardware. GDB is one debugger which has a compiled-in ISS. It is sometimes integrated with simulated peripheral circuits such as timers, interrupts, serial ports, general I/O ports, etc. to mimic the behavior of a microcontroller.

The basic instruction simulation technique is the same regardless of purpose: first execute the monitoring program passing the name of the target program as an additional input parameter.

The target program is then loaded into memory, but control is never passed to the code. Instead, the entry point within the loaded program is calculated, and a pseudo program status word (PSW) is set to this location. The Program Status Word (PSW) is composed of a status register and a program counter, the latter of which signifies the next instruction to be executed. Therefore, it is specifically the program counter that is assigned to this location. A set of pseudo registers are set to what they would have contained if the program had been given control directly.

It may be necessary to amend some of these to point to other pseudo "control blocks" depending on the hardware and operating system. It may also be necessary to reset the original parameter list to 'strip out' the previously added program name parameter.

Thereafter, execution proceeds as follows:

1. Determine length of instruction at pseudo PSW location (initially the first instruction in the target program). If this instruction offset within the program matches a set of previously given "pause" points, set "Pause" reason, go to 7.
2. "Fetch" the instruction from its original location (if necessary) into the monitor's memory. If "trace" is available and "on", store program name, instruction offset and any other values.
3. Depending upon the instruction type, perform pre-execution checks and execute. If the instruction cannot proceed for any reason (invalid instruction, incorrect mode etc.) go to 7. If the instruction is about to alter memory, check memory destination exists (for this thread) and is sufficiently large. If OK, load appropriate pseudo registers into temporary real registers, perform equivalent move with the real registers, save address and length of altered storage if trace is "on" and go to 4. If the instruction is a "register-to-register" operation, load pseudo registers into monitor's real registers, perform operation, store back to respective pseudo registers, go to 4. If the instruction is a conditional branch, determine if the condition is satisfied: if not go to 4, if condition IS satisfied, calculate branch to address, determine if valid (if not, set error = "Wild branch" and go to 7.) If OK, go to 5. If instruction is an operating system call, do real call from monitoring program by "faking" addresses to return control to monitor program and then reset pseudo registers to reflect call; go to 4.
4. Add instruction length to current Pseudo PSW value.
5. Store next address in Pseudo PSW.
6. Go to 1.
7. Halt execution.

For test and debugging purposes, the monitoring program can provide facilities to view and alter registers, memory, and restart location or obtain a mini core dump or print symbolic program names with current data values. It could permit new conditional "pause" locations, remove unwanted pauses and suchlike.

Instruction simulation provides the opportunity to detect errors BEFORE execution which means that the conditions are still exactly as they were and not destroyed by the error. A very good example from the IBM S/360 world is the following instruction sequence that can cause difficulties debugging without an instruction simulation monitor.

LM R14,R12,12(R13) where r13 incorrectly points to string of X"00"s BR R14 causes PSW to contain X"0000002" with program check "Operation Exception" * all registers on error contain nulls.