Инструмент тестирования программного обеспечения: Симулятор набора команд.

Software testing tool

An instruction set simulator (ISS) is a simulation model, usually coded in a high level programming language, which mimics the behavior of a mainframe or microprocessor by "reading" instructions and maintaining internal variables which represent the processor's registers. 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).

The number of instructions to perform the above basic "loop" (Fetch/Execute/calculate new address) depends on hardware but it could be accomplished on IBM S/360/370/390/ES9000 range of machines in around 12 or 13 instructions for many instruction types. Checking for valid memory locations or for conditional "pause"s add considerably to the overhead but optimization techniques can reduce this to acceptable levels. For testing purposes this is normally quite acceptable as powerful debugging capabilities are provided including instruction step, trace and deliberate jump to test error routine (when no actual error). In addition, a full instruction trace can be used to test actual (executed) code coverage.

Occasionally, monitoring the execution of a target program can help to highlight random errors that appear (or sometimes disappear) while monitoring but not in real execution. This can happen when the target program is loaded at a different location than normal because of the physical presence of the monitoring program in the same address space. If the target program picks up the value from a "random" location in memory (one it doesn't 'own' usually), it may for example be nulls (X"00") in almost every normal situation and the program works OK. If the monitoring program shifts the load point, it may pick up say X"FF" and the logic would cause different results during a comparison operation. Alternatively, if the monitoring program is now occupying the space where the value is being "picked up" from, similar results might occur. Re entrancy bugs: accidental use of static variables instead of "dynamic" thread memory can cause re entrancy problems in many situations. Use of a monitoring program can detect these even without a storage protect key. Illegal operations: some operating systems (or hardware) require the application program to be in the correct "mode" for certain calls to the Operating system. Instruction simulation can detect these conditions before execution. Hot spot analysis & instruction usage by counting the instructions executed during simulation (which will match the number executed on the actual processor or unmonitored execution), the simulator can provide both a measure of relative performance between different versions of algorithm and also be used to detect "hot spots" where optimization can then be targeted by the programmer. In this role it can be considered a form of performance analysis as it is not easy to obtain these statistics under normal execution and this is especially true for high level language programs which effectively 'disguise' the extent of machine code instructions by their nature.

Some of these software simulators remains to be used as tools for assembly language and Instruction Set Architecture teaching, with some specifically designed using multiple simulation layers and ISA to ISA simulation, with the ability to even design ISAs and simulate them.

In the first volume of The Art of Computer Programming, Donald Knuth wrote: "In the author's opinion, entirely too much programmers' time has been spent in writing such [machine language] simulators and entirely too much computer time has been wasted in using them." In the following section, however, the author gives examples of how such simulators are useful as trace or monitor routines for debugging purposes.