[go: up one dir, main page]

Jump to content

SIMMON

From Wikipedia, the free encyclopedia

SIMMON (Simulation Monitor) was a proprietary software testing system developed in the late 1960s in the IBM Product Test Laboratory, then at Poughkeepsie, New York It was designed for the then-new line of System/360 computers as a vehicle for testing the software that IBM was developing for that architecture. SIMMON was first described at the IBM SimSymp 1968 symposium, held at Rye, New York.[1]

SIMMON was a hypervisor, similar to the IBM CP-40 system that was being independently developed at the Cambridge Scientific Center at about that same time. The chief difference from CP-40 was that SIMMON supported a single virtual machine for testing of a single guest program running there. CP-40 supported many virtual machines for time-sharing production work. CP-40 evolved by many stages into the present VM/CMS operating system. SIMMON was a useful test vehicle for many years.

SIMMON was designed to dynamically include independently developed programs (test tools) for testing the target guest program. The SIMMON kernel maintained control over the hardware (and the guest) and coordinated invocation of the test tools.

Processing modes

[edit]

Two modes of operation were provided:

  1. Full simulation
  2. Interrupt

Full simulation mode

[edit]

In this mode, each instruction in the guest program was simulated without ever passing control directly to the guest. As an Instruction Set Simulator, SIMMON was unusual in that it simulated the same architecture as that on which it was running, i.e. that of the IBM System/360/370. While an order of magnitude slower than Interrupt mode (below), it allowed close attention to the operation of the guest. This would be the mode used by various instruction trace test tools.

Interrupt mode

[edit]

Interrupt mode (a/k/a Bump mode) constrained the guest program to run in user program state, with the SIMMON kernel handling all hardware interrupts and simulating all privileged instructions the guest attempted to execute. This mode could be used, for example, by a test tool to simulate a hardware device.

Some SIMMON test tools

[edit]

These were some test tools that were developed for use with SIMMON.

ERGENT

[edit]

(ERror GENeration and Test): This test tool was developed to test the device support error recovery in IBM's PCP (Primary Control Program) operating system, then being developed. It used a novel and very efficient table-driven finite-state machine (FSM) to inject simulated errors and verify that the operating system followed the detailed specifications of actions to be taken to attempt recovery.

The table driven FSM aspect was granted U.S. Patent [1] in October, 1972.

MAPPER

[edit]

MAPPER (not to be confused with the Unisys product of the same name) was a statistical performance analysis tool. It operated by allowing the program under test to run in Interrupt mode, but also used the system timer to periodically interrupt it. The addresses where the tested program was interrupted were recorded and later summarized and tabulated in the form of a map, showing the density of interrupts over the memory addresses. The result resembled nuclear scintigraphy images, showing the parts of the program most frequently used under the test conditions.

HOTSPOTS

[edit]

HOTSPOTS was an instruction trace tool written to help identify performance problem areas in IBM's MFT operating system. Branch trace data was written to tape, then summarized. The report took the form of a listing similar to a storage dump, with program entry points and exit points identified, including frequency of use for each instruction sequence.

These data identified the Memory Management component as consuming about 20% of CPU resources, and was used to justify a task force to try to improve the performance.

Stress

[edit]

While not a specific test tool, the distorted timing relationships while running under SIMMON found a number of problems, particularly in the input/output sections. Unless a SIMMON tool was put in place to normalize and delay I/O events, these would appear to the guest program as happening unnaturally quickly.

Programs tested

[edit]

Programs under test -- so-called guest programs -- had to be capable of stand-alone operation on the bare hardware. SIMMON provided services for the test tools, but not for the guest.

These were some of the programs that had been tested using SIMMON:

See also

[edit]

References

[edit]
  1. ^ Lehman MM (ed) Proc. SimSymp 1968, IBM Res. Div., Yorktown Heights, NY; Nov. 1968, 3 vols.