Abstract: A critical failure of current software system design and implementation methodology is that the performance of a proposed design is not evaluated before it is actually implemented. In this paper the reasons for this failure are explored, and a new methodology which overcomes many of the difficulties is proposed. A system which integrates performance evaluation with design and implementation is described. This system is based on a simple, high level language which is used to describe the evolving system at all stages of its development. The source language description is used as direct input to performance analysis and simulation routines. Using the performance information obtained from these routines as feedback, the problems which adversely affect performance are detected early enough so that they can be corrected without costly major reimplementation of the proposed system.

Abstract: Although there has been much progress over the years, students learning computer organizations and programming languages are usually still working with the computer through several layers of confusion and delay. Highly responsive interactive computer systems have recently become available which make it possible to create dynamic instructional models of computer organizations and programming languages. With proper development of these systems, such models can economically be used to give the student a more vivid experience with the computing machine and a more vital means of learning to program. Models of computer organization can allow the student to “see” the inner workings of a computing machine as it executes an instruction or a program which has been entered mnemonically at the assembly language level. Models of higher level programming languages can provide the student with constant “help” by presenting alternatives, checking acceptability of inputs, supplying amplifications of correct inputs, displaying syntactic structures to be completed, and prompting him as necessary at any point. Such models should also help provide a more productive environment for accomplished programmers to develop and debug programs. Exploratory models of each of these types have been implemented on a small interactive computer system to demonstrate these techniques.

Abstract: This paper considers various factors affecting system organization for speech understanding research. The structure of the Hearsay system based on a set of cooperating, independent processes using the hypothesize-and-test paradigm is presented. Design considerations for the effective use of multiprocessor and network architectures in speech understanding systems are presented: control of processes, interprocess communication and data sharing, resource allocation, and debugging are discussed.

Abstract: A program for interactively debugging software and firmware on an Intercomputer 1-50 minicomputer is described. Two processors sharing a common memory are used. The debugger is controlled by standard firmware in one processor, and the firmware and software to be debugged run under the other processor. By inserting a small defined routine into the firmware to be debugged, the debugger has control of the other processor, yet is practically invisible to it.

Abstract: This paper is based on a set of lectures given at Cambridge, directed to those who intend to write FORTRAN programs which have more than a transient life. This first part deals with the implications of conforming to the ANSI standard when writing FORTRAN. The second part, which will appear in the next issue, deals with the problem of producing optimal programs, debugging techniques and a number of miscellaneous topics. © 1973 Wiley Periodicals, Inc.

Abstract: This paper describes the Bug Farm, a generator of test cases for compilers, and the Bug Contest, an administrative technique for speeding the process of testing system software. The techniques achieve a high rate of bug detection while minimizing user revulsion at undebugged software. © 1973 Wiley Periodicals, Inc.

Abstract: The second part of this paper addressed to those who write FORTRAN programs of more than transitory life deals with facilities outside the Standard, optimization, recursion, the design of user interfaces, debugging and program proving. © 1973 Wiley Periodicals, Inc.

Abstract: A 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. (This work was supported by the U.S. Atomic Energy Commission.)

Abstract: MANTIS 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. © 1973 Wiley Periodicals, Inc.

Abstract: The user and programming information necessary for the application of the SATELLITE programs for the STARS system are presented. The individual program functions are: (1) data debugging for the STARS-2S program, (2) Fourier series conversion program, (3) data debugging for the STARS-2B program, and (4) data debugging for the STARS-2V program.

Abstract: The behavior of a system running in one virtual machine (OBJECT) is made accessible to an external observer through another virtual machine (SPY) coupled to the previous one. Given the independence of virtual machines, it is possible to run in SPY a fully operational system to which suitable components are added in order to achieve integration and debugging of new systems in OBJECT.

Abstract: : Measurement and analysis of user debugging behavior on present interactive systems can lead to an understanding of how future interactive systems should be implemented. The study presents both an analysis of the on-line usage of the TSS/360 Program Control System (PCS) as well as the results of a questionnaire designed to probe the PCS knowledge of the population of users of that system. The questionnaire response population tended to be divided into three competence groups, the highest of which consisted mostly of system support personnel and Assembler language programmers. The on-line usage analysis showed that PCS commands accounted for 7.2 percent of all commands entered by programmers. PCS was used rarely to modify the logic of a program, but was used as a program variable input/output system. (Modified author abstract)

Abstract: A research program is underway with the purpose of developing a system to integrate the functions of Design, Programming, Debugging and Testing (DPDT) for achieving software reliability. Although we are aiming at developing an actual for realized system for this purpose, emphasis is being placed on the isolation of general principles that can be applied to a variety of programming environments. We are defining a model of computation through which the design phase will be formally described.1 The model will be required to handle a basic definition of modularity besides having features to be integrated with: a class of Algol-like languages (in which programs are to be written), the debugging facilities defined in the language, and a class of program testing strategies. Extensions to a programming language will be defined so as to make it support the requirements of the design model2 and to provide debugging facilities compatible with the design phase and measurements. The measurements will be handled by the systems testing phase for the establishment of some quantitative indices of test completeness. The testing activity will in turn reflect on the design and provoke iterations until a “sufficient verification” of the produced software is met.

Abstract: The purpose of this short document is to exhibit how a HACKER-like top-down planning and debugging system can be applied to the problem of the design and debugging of simple analog electronic circuits. I believe, and I hope to establish, that this kind of processing goes on at all levels of the problem-solving process--from specific, concrete applications, like Electronic Design, through abstract piecing together and debugging of problem-solving strategies. Work reported herein was conducted at the Artificial Intelligence Laboratory, a Massachusetts Institute of Technology research program supported in part by the Advanced Research Projects Agency of the Department of Defense and monitored by the Office of Naval Research under Contract Number N00014-70-A-0362-0005. Working Papers are informal papers intended for internal use. A Scenario of Planning and Debugging in Electronic Circuit Design The purpose of this short document is to exhibit how a HACKERlike top-down planning and debugging system can be applied to the problem of the design and debugging of simple analog electronic circuits. I believe, and I hope to establish, that this kind of processing goes on at all levels of the problem-solving process--from specific, concrete applications, like Electronic Design, through abstract piecing together and debugging of problem-solving strategies. The essence of the theory is that the problem-solver starts out with a set of basic modules which are solutions to various basic problems. Each module is indexed by some coarse description of the problem it is intended to solve. There may be several modules which are solutions to the same coarsely described problem. The choice of which to use in any case constitutes a design decision and must be based upon a finer decription of the module, how it interacts with a finer description of the problem which it is to solve and other modules which it must interact with in solution of the problem of which it is a solution of a subproblem. When confronted by a problem, the problem-solver must first see if it has an immediate coarse solution to try out. If not, it must concoct one by breaking up the problem into subproblems and patching together the subsolutions. The proposed solution is then tried out and debugged. Debugging consists of isolating the cause of failure to one submodule or a particular sort of interaction between the submodules. PAGE 2 The affected region of the solution is then examined in finer detail and a subproblem is generated to patch the bug. The problem solver can be caused to acquire skill by saving the problem solutions i.t generates, coarsely indexing them by generalizations of the problems for which they were constructed. In this scenario the following modules are used: I Class A amplifier: (tube type). It is specified that the signal source, S, is pure A.C. and (to first order) sees an infinite impedance. The output voltage, Vo, has a D.C. bias caused by the battery,B. II The "RC coupling" trick. To pass the AC component of a signal without coupling the DC bias circuits:

Abstract: The best that can be expected from traditional debugging and testing techniques is that the number of bugs will be reduced to a tolerable level. However, programs that either implement or relate to protection in an operating system are examples of programs for which: 1) the number of residual bugs that can be tolerated is zero; 2) it is necessary to know, or at least have convincing objective evidence, that the number of bugs is indeed zero; and 3) the concern extends to bugs which would not arise under normal circumstances and which may be very difficult to find either by testing or by normal use.

Abstract: The research underlying this report is concerned with improving the lot of the programmer in debugging, analyzing and modelling his, or others', programs. It is my belief that the area of “execution analysis tools” has been neglected in the formative stages of system planning in contemporary systems. This has led to the design of many software and hardware “probes”, “performance monitors”, debugging aids, etc. which have been forced to work with uncooperative hardware and operating systems. The state of the art is especially inadequate in on-line debugging and analysis tools. Witness, for example, the difficulties of backtracking, or tracing the values of a set of core locations, or determining all the successors of a particular node in a program (a node being defined in some intuitive sense for the time being), except in several machine-simulator based systems (see (9) for some good examples).In a survey (1) of on-line debugging techniques in 1966, Evans and Darley remark that computer use is becoming “debugging-limited” rather than limited by memory size or processor speed. They further predict that this will be the state of affairs until methods for proving that programs have certain properties are successfully developed and come into wide use. I quite agree with that evaluation and further envision that “high-level execution analysis” tools will become a staple in future software engineering laboratories.

Abstract: A version of the GPSS simulation language, compatible with GPSS V, has been implemented for the CDC 6000 series and is operational at the Naval Air Development Center. In addition, the design goals of NGPSS/6000 were thorough assembly debugging, reduced core requirements, decreased running time, unrestricted use of matrices, and language flexibility to allow flexibility for future enhancements. This implementation seeks to aid both the user unfamiliar with the language with more complete diagnostics; while enabling the experienced user to build very large-scale models and associated data banks. Provisions have been made for future language extensions toward real-time operation, on-line debugging, and a faster execution module for debugged models.

Abstract: We discuss here proposals for two new debugging aids for hybrid-computer programmers. For digital programs, "relevant" post-mortem dumps have long been advocated .1We propose extending this philoso phy to analog dumps. We describe means of making selective dumps via analysis of the topological structure of analog programs. We also propose a novel analog static-check procedure which takes advantage of the greater computational facilities afforded by a digital computer to solve algebraic equations.The analog-dump and static-check methods recommended here, at worst, help hybrid programmers with their debugging efforts by automating certain common tac tics. Many errors can thereby be automatically detected and precisely located. In conclusion, we suggest how correction of these errors can be auto mated to some extent.

Abstract: The SPECL programming system is an attempt to combine the characteristics of an implementation language with those desirable for verifiability (human and mechanical) and transportability. The former requires efficient code generation and access to hardware; the latter requires a highly structured language and isolation of machine dependencies. SPECL will be embedded in the ECL programming system, which currently includes an interpreter and compatible compiler for the extensible language EL1, and a set of tools for debugging, metering, and verification. The SPECL compiler (under design) will restrict the semantics of EL1 to eliminate the need for run-time support and type checking, and couple specification of machine representation of modes and operators with the EL1 definitional mechanism to enable generation of efficient object code.

Abstract: As computers become more prevalent as laboratory equipment, psychologists and graduate assistants will be more likely to be involved with interfacing the experiment to the computer. This paper presents some general ideas about the design and construction of digital computer interfaces and ways to facilitate their check-out and integration into the computer system. The suggestions center around the identification of functional modules within the interface or device from the beginning of the design process. These modules are preserved in the design and construction and are tested separately where possible. Specification of the interface signals between these functional units speeds debugging of a new device and facilitates maintenance of the device at a later date if adequately documented. It is important to ensure that these signals are readily available through test points and/or indicators. The paper suggests minimal equipment necessary to construct and debug an interface. It is suggested that an interactive construction procedure may be the most successful. The device is constructed in stages, with each part being verified as it is built, A simple interface is suggested for the beginner which gives him practice and a useful debugging aid as well.

Abstract: It has been observed [1] that 45 to 50% of programming effort is spent in debugging, checkout and testing, yet the architecture of most modern computer systems does little if anything to facilitate ease of debugging. In most batch systems the programmer is sufficiently removed from the execution of his program as to be severely handicapped in diagnosing errors. There is only so much information that can be easily obtained from a voluminous coredump, for instance. Even programmers on large timesharing systems have available at most an interactive software debugging package which operates through a combination of insertions and replacements of object code and interpretation (rather than execution) of machine code. This can get to be quite inefficient when carried to the extreme and often is useful only if the program has been processed by a special compiler.

Abstract: It appears that the thrust of research in graphical display technology has been towards new applications and the development of economical and more efficient display hardware. There seems to have been a lack of effort in developing software systems by which devices could be used easily and efficiently. In this paper the author considers the basic problems of conversational graphic programming, and describes a general purpose system, Eulalie, in which his proposal has been implemented at the Universite de Grenoble, France. With this system, which is operational, a user can write, debug and execute a graphical program, using only the display unit. The system includes a programming language, Euphemie, specifically oriented towards the simple use of the terminal.

Abstract: A substantial portion of any programmer's time is spent in debugging. One of the major services of any compiler ought to be to provide as much information as possible about compile-time errors in order to minimize the time required for debugging. A good error detection and recovery scheme should maximize the number of errors detected but minimize the number of times it reports an error when there is none. These spurious error detections and their associated error messages are usually engendered by an inappropriate recovery action.In this paper we describe a recovery scheme for syntax errors which provides high quality recovery with good diagnostic information at relatively low cost. In addition, implementation of the recovery scheme can be automated - that is, the recovery routine can be created by a parser-generator. Therefore, the compiler designer need not be burdened with the difficulties of error recovery and the programming effort necessary to design and debug a myriad of ad hoc recovery routines.

Abstract: This paper proposes that all data elements in a computer memory be made to be self-identifying by means of a tag. The paper shows that the advantages of the change from the traditional von Neumann machine to tagged architecture are seen in all software areas including programming systems, operating systems, debugging systems, and systems of software instrumentation. It discusses the advantages that accrue to the hardware designer in the implementation and gives examples for large- and small-scale systems. The economic costs of such an implementation for a minicomputer system are examined. The paper concludes that such a machine architecture may well be a suitable replacement for the traditional von Neumann architecture.