Debugging Facilities Research Articles

Some psychological evidence on how people debug computer programs

Ten experienced programmers were each given the same 12 FORTRAN listings to debug. Each listing contained a non-syntactic error in one line. Median debug times (7 min), number of bugs not found (11% of the listings), and number of incorrect assertions about the location of the bug (less than one per listing) all replicated earlier results ( Gould & Drongowski, 1974 ). Although subjects were given the opportunity to use the interactive debugging facilities of an on-line computer, they rarely did so. Bugs in assignment statements were about three times as hard to detect as array or interaction bugs. Debugging was about three times as efficient on programs subjects had debugged previously (although with a different bug). A number of basic concepts relating to debugging are identified and a gross theory of debugging is described.

The people's time sharing system

AbstractA set of programs running under a multiprogramming batch operating system on the CDC 6600 which provide remote users with a time sharing service is described. The basis for the system is the ability of a user program to create job control statements during execution, thereby tricking the operating system into treating it as an ordinary batch job. The text editor and the interactive debugging facilities are described. The performance of the system, known as the People's Time Sharing System (PTSS), and user reaction to it are also described.

Design of an interactive debugger for FORTRAN: MANTIS

AbstractMANTIS is a natural debugging facility for the FORTRAN language subsystem on the PDP‐10. It was designed and implemented in an existing language subsystem in order to facilitate program preparation and debugging in the time sharing environment available on the PDP‐10.Suitable debugging facilities should be included in the initial design of language subsystems. Language subsystems to run in time sharing operating systems should offer debugging facilities that exploit the interactive environment available to the user. This paper describes experience gained in designing and adding a useful interactive debugger to an existing FORTRAN subsystem. Objectives, implementation experience and system features are discussed and are related to the general problem of designing debuggers for language subsystems.

A Facility for Real-Time Program Development

As part of a multi-access system, a facility was developed to assist in the preparation of real-time programs for a specialist application. The multi-access system (GPO, 1970) is located within the Electronic Switching Group GPO Research Station, Dollis Hill. This group is presently engaged on the development of a computer-controlled telephone exchange. As can be imagined, a considerable software effort is involved even in the initial stage, which consists initially of a four-line exchange controlled by a small computer via a data switch. Plans are in hand to test the system simulating much larger traffic. This software comprises the exhange system executive, a large number of operating routines, of the order of 100, and a complex test program used in the development of the data switch and the other pieces of hardware which make up the exchange. Powerful debug facilities were available and it was desired to extend their use to real-time programs. Because of the programming effort required to implement the system for the exchange and also because the system was to be implemented on a small computer, it was necessary to produce initially an operating system that would provide both multiaccess capabilities and comprehensive debug facilities. A further advantage was that it would permit hardware and software development to proceed simultaneously. The first provision is an obvious one since all computing is done in a 'hands-on' situation, i.e. each programmer is allotted time, during which he may assemble, edit or debug his program. Particularly during the last stage, the computer will be idle for appreciable periods during which the programmer cogitates. Multi-access, therefore, is an obvious method of increasing the efficiency of use of the machine, The comprehensive debug facility ensures that the programmer uses his time as efficiently as possible. The small machine concerned was a Honeywell DDP 516 with 32K words of storage. A high speed punch and reader are connected together with two Teletype ASR 33 and one KSR 35. Optional features which are incorporated in the system are memory lock-out and standard and priority interrupt lines. The high speed reader and punch are connected to the standard interrupt line, while the teletype, real-time clocks, data switch and other hardware links are connected to the priority lines. In the Honeywell interrupt system, when an interrupt occurs, it causes the contents of the program counter, which contains the address of the current instruction to be executed, to be automatically changed, thereby changing the sequence of instruction execution. Interrupts have unique memory locations dedicated to them, whose contents are interpreted as an indirect address. The action of an interrupt causes the program to branch to the location whose address is stored in the dedicated location. These dedicated locations are held in the base sector.

Simulating the Viatron 2140/2150 on the IBM 360

This paper describes the process ofdeveloping an instruction-level simula tion of a digital computer for program checkout, with particular reference to a simulation of the Viatron 2140/2150 minicomputers on the IBM 360. The architecture of these computers is described. Design decisions to be made in simulator development are then covered, including programming language, data representation, approach to timing, and debugging facil ities. A method ofreducing the size of the simulator by "paging" the simu lated memory into and out of the host computer's core memory is discussed. Results of operational use of the simulator are given. Through out, emphasis is placed on those factors which tend to differentiate the simulation of a minicomputer from the simulation of a commercial data- processing computer.