Abstract: The late 70' s find structured programming increasingly popular—this and other techniques are programming's future. But what does experimental evaluation say about their actual effects on programmer performance?

Abstract: A system is described for enabling the connection of a diagnostic/debugging processor to another host processor for the purpose of troubleshooting that processor's hardware and software. The system is composed of an interface between the diagnostic/debugging processor per se and the host processor to be diagnosed, and of software resident in the diagnostic processor to perform functions required by the user of the system. The system is specifically designed for use with a host processor utilizing LSSD design rules.

Abstract: A major portion of the problems associated with software development might be blamed on the lack of appropriate tools to aid in the planning and testing phases of software projects. As one step towards solving this problem, this paper presents a model to estimate the number of bugs remaining in a system at the beginning of the testing and integration phases of development. The model, based on software science metrics, was tested using data currently available in the literature. Extensions to the model are also presented which can be used to obtain such estimates as the expected amount of personnel and computer time required for project validation.

Abstract: The possibility of automatic construction of a complete set of program tests is considered. A test set system is said to be complete if every feasible program branch (segment) is executed by it. The complete test set construction algorithm for commercially oriented data processing programs is outlined, and the results of its functioning on real programs are analyzed.

Abstract: There is disclosed herein an apparatus for use in automated testing of elements in data processing systems such as the central processing unit. The system is comprised of a microprocessor with associated firmware, RAM and peripheral communications devices. There are two communication interface ports for receiving commands and instructions from local and remote computer terminals or from data processing units programmed to cause the testing apparatus to perform predetermined sequences of tests. There is also a port for connection to a portable maintenance panel which can be held in the hand of a field engineer for controlling the testing apparatus. The system is designed to replace prior art maintenance panels used for debugging computer hardware.

Abstract: In a microprogram control system of the type comprising an electronic computer having a programmable interruption control unit and a debugging microprogram executed during interruption which permits single step execution of a user's microprogram. When an interruption is desired, a next address of a program to be debugged is saved in a storage device. After executing the interruption the program operation is returned to a single step operation.

Abstract: ALADDIN is an interactive facility for debugging and testing of assembly language programs. ALADDIN differs from traditional debuggers by allowing the user to specify breakpoint assertions, rather than breakpoint locations. Assertions are logical relations among various components of the program state. If an assertion becomes false during execution of the object program a breakpoint is executed and control is passed to the user's terminal. ALADDIN can also be used as a testing tool to verify that asserted behavior matches actual behavior under various sets of input data and test conditions.

Abstract: For the past two years the Software Management Research Unit at General Electric has been investigating several areas of human factors in software engineering with support from Engineering Psychology Programs of the Office of Naval Research. There have been two major thrusts in this research. The first thrust investigated the effects of several modern programming practices on programmer efficiency. The second thrust investigated the prediction of programmer performance from software complexity metrics such as those proposed by Halstead and McCabe. This research program consisted of separate experiments on the understanding, modification, debugging, and construction of software, each using professional programmers. Each experiment investigated both the effects of experimentally manipulated programming practices, and the values of complexity metrics computed from the programs employed.

Abstract: This paper discusses the development and implementation of a number of hardware and software tools used in the design, development, and debugging of the microcode and nanocode for the MC68000 microprocessor. A functional description of these tools is included as well as an analysis of how each worked with respect to solving the desired problem (ie., generating correct microcode and nanocode). Peculiarities in the integrated circuit industry for microcode verification is considered as well as the automated process of error detection and correction.

Abstract: The Advanced Interactive Debugging System (AIDS) is described. It is a powerful high-level symbolic interactive debugging aid. AIDS is intended to be available in a program's environment without requiring debugging statements in the program's source code or inclusion of AIDS in the program's executable module.

Abstract: There is at present a broad consensus that a capability-based architecture is the best approach to safe systems. 5 , 3 , 6 However, at the bare hardware level, a machine should provide for a set of basic mechanisms (e.g. processor assignment, manipulation of queues of processes, definition of and manipulation on domains) without prejudging of any policy to be applied to these elements. The internal structure of the objects referred to by capabilities, the way they are organized into capability lists and the evolution of these lists in relation to various events appearing throughout the life of a program and of its possible activations should appear at some higher level, so that they can be modified without disturbing the hardware. This demands flexibility (the capability for emulating, for instance), adaptability (to future modifications) or the ability to define a machine which could be orientated, on demand, toward a certain class of applications (see for instance, the Burroughs B1700 approach). In the following, we shall be concerned mainly with this level, which we shall call "virtual architecture level." Considering a basic architecture, which we describe briefly, we define a virtual architecture for higher-level languages (namely PL/1, COBOL, FORTRAN and the system implementation language LIS, 13 ) called the HLL-machine in this discussion. The objectives of the HLL-machine are the following: • To define a virtual architecture as clean and homogeneous as possible, on which compilers may become more simple, and debugging aids more powerful. • To define a minimum of intermediate languages, ideally, just one, for supporting PL/1, COBOL and FORTRAN. • To define a set of run-time mechanisms enforcing safety. • To obtain more compact object programs, as compared to third generation computer systems, so as to reduce the working sets of programs. • To abide by the error confinement principle, which states that a procedure should not have at its disposal more capabilities than actually required for its execution. • To improve overall system performance.

Abstract: Designers and implementors of high‐level language translators can, with relatively little extra effort, greatly facilitate run‐time symbolic debugging. Practical suggestions are presented, based on experiences gained from interfacing several compilers with a run‐time debugging system.

Abstract: We examine the costs and psychology of debugging. We propose a fundamental approach to debugging. We suggest that industry's outlook is perhaps not thorough.

Abstract: Software reliability will be no less a challenge in the 80's than in the previous decade but the basic research of the 70's can be applied to develop software tools to meet this challenge. In this paper one such application is described, namely the development of a debugging package based on two very active areas of research in the late 60's and throughout the 70's: research on proving assertions about programs [7,9,10,14,17] and on symbolic execution [3,11,12,13]. Combining these two areas appears to have been very fruitful in producing an approach to debugging of great promise.The development of the debugging package for a version of Pascal is described and some applications of the package are discussed. Some possibilities for future developments are also given.

Abstract: PURPOSE:To enable easy debugging and program formation, by feeding the simulation program written in the sequence table to the debugging computer, and by performing debugging through the connection of the computer and the sequence control unit through the input and output circuit. CONSTITUTION:The simulation unit 3 including the computer memorizing the sequence table 1 of the decision table type registrating the operation output signal of unit and answer pair every step as the simulation program, and the graphic display unit 2 displaying the process condition of sequence control objective with simulation based on the answer of the simulation unit 3 are provided, allowing easy debugging and program formation.

Abstract: : This report is the third in a series investigating characteristics of software which are related to its psychological complexity. Three independent variables, length of program, complexity of control flow, and type of error, were evaluated for three different Fortran programs in a debugging task. Fifty-four experienced programmers were asked to locate a single bug in each of three programs. Documentation consisted of input files, correct output, and erroneous output. Performance was measured by the time to locate and successfully correct the bug. Small but significant differences in time to locate the bug were related to differences among programs and presentation order. Although there was no main effect for type of bug, there was a large program by error interaction suggesting the existence of context effects. Among measures of software complexity, Halstead's 'E' proved to be the best predictor of performance followed by McCabe's 'v(G)' and the number of lines of code. Number of programming languages known and familiarity with certain programming concepts also predicted performance. As in the previous experiments, experiential factors were better predictors for those participants with three or fewer years experience programming in Fortran. (Author)

Abstract: This paper presents a system (PHENARETE) which understands and improves Incompletely defined LISP programs, such as those written by students beginning to program In LISP. This system takes, as Input, the program without any additional Information. In order to understand the program, the system meta-evaluates It, using a library of pragmatic rules, describing the construction and correction of general program constructs, and a set of specialists describing the syntax and semantics of the standard LISP functions. The system can use its understanding of the program to detect errors In it, to debug them and, eventually, to justify Its proposed modifications. This paper gives a brief survey of the working of the system, emphasizing some commented examples.

Abstract: Dataflow languages and processors are currently being extensively studied because of their respective ability to specify and execute programs which exhibit a high degree of parallel and/or asynchronous activity [12, 7]. This paper describes a comprehensive simulation environment that allows for the execution and monitoring of dataflow programs. One overall objective of this facility was to meet the needs of researchers in such diverse areas as computer architecture, algorithm analysis, and language design and implementation. Another objective was to accommodate the semantics of several of the contending abstract dataflow models [2, 4]. Additionally, it was desired to enhance the abstract dataflow models which the simulator would support. These objectives, combined with the desired debugging and metering requirements, directed the design of the overall system. A brief introduction to dataflow and its related terminology is given to assist the reader. A companion paper [6] describes an augmentation to the basic simulation facility presented here that allows for the execution of dataflow programs on processors having finite resources.

Abstract: Introduction In a recent paper [1] Misra had introduced a metho d of verification of loop programs based upon a given loo p specification. This method employs the ideas of Mills [3 ] and is close to the subgoal induction advanced by Morris an d Wegbreit [2]. In this work we apply a variation of the metho d to program debugging showing how a loop and its specificatio n can be checked for consistency and correctness and possibl y corrected. The method requires an initialization be remove d from the loop construct and its specification be defined so a s to explicitly show the dependence of the final values on th e initial values of the variables of the loop treated as a separat e entity. The presentation is informal, being illustrated wit h a simple example. In what follows a*B stands for the whil e a do B construct, where B : D-> D is the loop body, and D is the domain of a*B. Greek letters stand for vectors o f variables of D. F stands for the function computed by a*B .

Abstract: PURPOSE:To easily perform various diagnoses, debugging, and error analysis, by collecting input and output bus information and storing it in memory based on the trigger information as reference (without burdening the software)

Abstract: PURPOSE:To simplify the formation of software, to make program simple, and to improve capability of debugging by enabling the software to attain access to a memory without relating to CPUs by making each CPU perform CPU-series-number qualification independently. CONSTITUTION:Corresponding to CPUs, main memory unit MM is provided with system areas of the same contents independently from any head address of unit MM in the order of CPU series numbers, and each CPU is provided with its-own- address memory register 25, whose contents are enabled to be inputted to shifter 14 via shifter decoder 15. As for system access at the interrupt-standby time, only one instruction including at least a relative address inside of the system area is given and each CPU performs CPU-series-number qualification independently by an arithmetic function of the CPU to enable the software to attain memory access without relating to CPUs. As a result, the formation of the software is simplified, the program is made simple, and the capability of debugging is improved.

Abstract: PURPOSE:To reduce the cost of debugging by using a PROM for the storing and maintenance of a new program, by executing the debugging by a RAM, and writing the final contents of the RAM to the PROM when the debugging is interrupted CONSTITUTION:A program retained in PROM6 of debugging unit 3 of microprocessor-MPU applied apparatus 1 is transferred to RAM5 by the command of monitor console 11 through the control of general microprocessor GMPU8 controlling unit 3 Next, appreciating chip 4 is started by the command of debugging console 14 to operate apparatus 1 for the debugging of the program, thereby correcting the contents of RAM5 At the time when the debugging is interrupted, the final modified contents of RAM5 are written to PROM6 by PROM write unit 10 under the control of GMPU8 Consequently, even if the power supply is cut off, the program remains inside of PROM6 and no paper tape is used, so that the shortening of the development period and the great reduction of the cost of a MPU applied apparatus can both be realized

Abstract: An operating system is described that was designed to permit the distributed execution of programs composed of collections of communicating tasks on a network of microcomputers. A part of the system on each of the computers provides multitasking and message passing. Only one of the micros has access to peripherals, and it is on that computer that the system tasks for most of the system policies as well as the mechanisms for communication to the outside world are located. Since there is no shared memory among the microcomputers, access to memory and control of tasks in other computers must be accomplished by message passing and the cooperation of agent tasks in the other computers.

Abstract: The Computer System Emulation Operating System is a combination of a basic, general-purpose, timesharing operating system and an emulation system. The system is used as a software development, testing and debugging tool. The gene'ral-purpose operating system was written specifically for this purpose because use of an existing operating system was impractical. The emulation system was added to this operating system. It is probably possible to integrate the emulation system into an existing operating system, giving the user the combined capabilities of the operating system and the emulation system. The emulation system creates an environment which appears as a stand-alone computer system to any program being executed in this environment. The emulation system emulates computer hardware peripherals, and the host computer itself directly executes the machine instructions. This provides the advantage of speed over totally emulating both the computer and peripherals of a system, and has economic advantages over systems which use special hardware