Instruction set simulator

Last updated

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.

Contents

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

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

Implementation

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

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. [1] 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.

Consequences

Overhead

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.

Added benefits

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.

Educational purposes

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. [2]

Criticism

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." [3] In the following section, however, the author gives examples of how such simulators are useful as trace or monitor routines for debugging purposes.

Example

Typical trace output from simulation by monitoring program used for test & debugging:

ProgramoffsetinstructionDis-assembledregister/ storage (after execution) TEST001        000000         X'05C0'                BALR   R12,0              R12=002CE00A                000002         X'47F0C00E'            BC    15,X'00C'(R12)                    00000E         X'98ECD00C'            STM   R14,R12,X'00C'(R13)   X'002E0008' ==> X'00004CE,002CE008,..etc....'                000012         X'45E0C122'            BAL   R14,X'122'(R12)     R14=002C0016 SUB1           000124         X'50E0C28A'            ST    R14,X'28A'(R12)       X'002CE294' ==> X'002C0016' etc...

See also

Simulators

Other

Related Research Articles

<span class="mw-page-title-main">Central processing unit</span> Central computer component which executes instructions

A central processing unit (CPU)—also called a central processor or Microprocessor or main processor—is the most important processor in a given computer. Its electronic circuitry executes instructions of a computer program, such as arithmetic, logic, controlling, and input/output (I/O) operations. This role contrasts with that of external components, such as main memory and I/O circuitry, and specialized coprocessors such as graphics processing units (GPUs).

<span class="mw-page-title-main">Interrupt</span> Signal to a computer processor emitted by hardware or software

In digital computers, an interrupt is a request for the processor to interrupt currently executing code, so that the event can be processed in a timely manner. If the request is accepted, the processor will suspend its current activities, save its state, and execute a function called an interrupt handler to deal with the event. This interruption is often temporary, allowing the software to resume normal activities after the interrupt handler finishes, although the interrupt could instead indicate a fatal error.

<span class="mw-page-title-main">Machine code</span> Set of instructions executed by a computer

In computer programming, machine code is computer code consisting of machine language instructions, which are used to control a computer's central processing unit (CPU). Although decimal computers were once common, the contemporary marketplace is dominated by binary computers; for those computers, machine code is "the binary representation of a computer program which is actually read and interpreted by the computer. A program in machine code consists of a sequence of machine instructions ."

In computer science, an instruction set architecture (ISA), also called computer architecture, is an abstract model of a computer. A device that executes instructions described by that ISA, such as a central processing unit (CPU), is called an implementation.

<span class="mw-page-title-main">Debugger</span> Computer program used to test and debug other programs

A debugger or debugging tool is a computer program used to test and debug other programs. The main use of a debugger is to run the target program under controlled conditions that permit the programmer to track its execution and monitor changes in computer resources that may indicate malfunctioning code. Typical debugging facilities include the ability to run or halt the target program at specific points, display the contents of memory, CPU registers or storage devices, and modify memory or register contents in order to enter selected test data that might be a cause of faulty program execution.

ARM is a family of RISC instruction set architectures (ISAs) for computer processors. Arm Ltd. develops the ISAs and licenses them to other companies, who build the physical devices that use the instruction set. It also designs and licenses cores that implement these ISAs.

In-circuit emulation (ICE) is the use of a hardware device or in-circuit emulator used to debug the software of an embedded system. It operates by using a processor with the additional ability to support debugging operations, as well as to carry out the main function of the system. Particularly for older systems, with limited processors, this usually involved replacing the processor temporarily with a hardware emulator: a more powerful although more expensive version. It was historically in the form of bond-out processor which has many internal signals brought out for the purpose of debugging. These signals provide information about the state of the processor.

Simics is a full-system simulator or virtual platform used to run unchanged production binaries of the target hardware. Simics was originally developed by the Swedish Institute of Computer Science (SICS), and then spun off to Virtutech for commercial development in 1998. Virtutech was acquired by Intel in 2010. Currently, Simics is provided by Intel in a public release and sold commercially by Wind River Systems, which was in the past a subsidiary of Intel.

Memory protection is a way to control memory access rights on a computer, and is a part of most modern instruction set architectures and operating systems. The main purpose of memory protection is to prevent a process from accessing memory that has not been allocated to it. This prevents a bug or malware within a process from affecting other processes, or the operating system itself. Protection may encompass all accesses to a specified area of memory, write accesses, or attempts to execute the contents of the area. An attempt to access unauthorized memory results in a hardware fault, e.g., a segmentation fault, storage violation exception, generally causing abnormal termination of the offending process. Memory protection for computer security includes additional techniques such as address space layout randomization and executable space protection.

JTAG is an industry standard for verifying designs and testing printed circuit boards after manufacture.

<span class="mw-page-title-main">Breakpoint</span> Debugging method used in software development

In software development, a breakpoint is an intentional stopping or pausing place in a program, put in place for debugging purposes. It is also sometimes simply referred to as a pause.

A branch is an instruction in a computer program that can cause a computer to begin executing a different instruction sequence and thus deviate from its default behavior of executing instructions in order. Branch may also refer to the act of switching execution to a different instruction sequence as a result of executing a branch instruction. Branch instructions are used to implement control flow in program loops and conditionals.

<span class="mw-page-title-main">Microarchitecture</span> Component of computer engineering

In electronics, computer science and computer engineering, microarchitecture, also called computer organization and sometimes abbreviated as µarch or uarch, is the way a given instruction set architecture (ISA) is implemented in a particular processor. A given ISA may be implemented with different microarchitectures; implementations may vary due to different goals of a given design or due to shifts in technology.

In software engineering, profiling is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization, and more specifically, performance engineering.

<span class="mw-page-title-main">Hardware emulation</span> Emulating hardware devices in IC design

In integrated circuit design, hardware emulation is the process of imitating the behavior of one or more pieces of hardware with another piece of hardware, typically a special purpose emulation system. The emulation model is usually based on a hardware description language source code, which is compiled into the format used by emulation system. The goal is normally debugging and functional verification of the system being designed. Often an emulator is fast enough to be plugged into a working target system in place of a yet-to-be-built chip, so the whole system can be debugged with live data. This is a specific case of in-circuit emulation.

A computer architecture simulator is a program that simulates the execution of computer architecture.

<span class="mw-page-title-main">Emulator</span> System allowing a device to imitate another

In computing, an emulator is hardware or software that enables one computer system to behave like another computer system. An emulator typically enables the host system to run software or use peripheral devices designed for the guest system. Emulation refers to the ability of a computer program in an electronic device to emulate another program or device.

<span class="mw-page-title-main">MikroSim</span>

MikroSim is an educational software computer program for hardware-non-specific explanation of the general functioning and behaviour of a virtual processor, running on the Microsoft Windows operating system. Devices like miniaturized calculators, microcontroller, microprocessors, and computer can be explained on custom-developed instruction code on a register transfer level controlled by sequences of micro instructions (microcode). Based on this it is possible to develop an instruction set to control a virtual application board at higher level of abstraction.

RISC-V is an open standard instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles. Unlike most other ISA designs, RISC-V is provided under royalty-free open-source licenses. Many companies are offering or have announced RISC-V hardware; open source operating systems with RISC-V support are available, and the instruction set is supported in several popular software toolchains.

The Hack Computer is a theoretical computer design created by Noam Nisan and Shimon Schocken and described in their book, The Elements of Computing Systems: Building a Modern Computer from First Principles.  In using the term “modern”, the authors refer to a digital, binary machine that is patterned according to the von Neumann architecture model.

References

  1. Hayes, John P. (1978). Computer Architecture and Organization. McGRAW-HILL International Book Company. p. 51. ISBN   0-07-027363-4.
  2. Almasri, I., Abandah, G., Shhadeh, A., Shahrour, A. (2011, December). Universal ISA simulator with soft processor FPGA implementation. In Applied Electrical Engineering and Computing Technologies (AEECT), 2011 IEEE Jordan Conference on (pp. 1–6). IEEE.
  3. “The Art of Computer Programming”, Donald Knuth, 1997, Volume 1, 3rd edition, Page 202.