Abstract: An introductory course (and its successor) in programming should be concerned with three aspects of programming:1. How to solve problems,2. How to describe an algorithmic solution to a problem,3. How to verify that an algorithm is correct.I should like to discuss mainly the first two aspects. The third is just as important, but if the first two are carried out in a systematic fashion, the third is much easier than commonly supposed. (Note that the third step is not “debugging,” because the word “debugging” conveys the impression that errors are alright—that they are a natural phenomenon which, like flies in a house, must be found and swatted. If “debugging” was called “getting rid of one's mistakes,” I'm sure most programmers would change their attitude and work harder at producing a correct program initially.)

Abstract: Now welcome, the most inspiring book today from a very professional writer in the world, program style design efficiency debugging and testing. This is the book that many people in the world waiting for to publish. After the announced of this book, the book lovers are really curious to see how this book is actually. Are you one of them? That's very proper. You may not be regret now to seek for this book to read.

Abstract: Much attention has been focused lately on the notions of structured programming, a crucial factor when dealing with the design of large programming Systems. Rather than viewing programming as an art and the programmer as the perpetual artist, structured programming provides a more .systematic (and in a way more restricted) approach which facilitates debugging and proving assertions about programs.One of the ideas developed by advocates of structured programming is the top-down elaboration of program control structures by a recursive process of successive refinements [1]. No such process has been developed for dealing with data structures. The main reason for this is the improper intermixing of the semantic and implementation concepts [2] of a data structure. The failure to distinguish between these concepts is a result of the conflicting factors involved in choosing a data structure: simplicity of element access, minimization of search time, dynamics of growth or elimination of data, simplicity of restructuring and extension, efficiency of storage utilization and others.

Abstract: Assembly level instruction trace routines have been used for years by programmers as a debugging aid. However, most of these have the disadvantages that they are usually 1) very slow and 2) not amenable for use with operating system development. This paper shows how the standard ROM resident instruction set of the H-P 2100 was replaced by a new WCS resident set that contains instruction trace routines with physical I/O. The trace routine was designed so that either all instructions could be traced, or only instructions from a specified area of memory; since the specified area may be modified while the program is running, the user has the flexibility to choose how his program will be monitored. Because all the routines are in firmware rather than software, degradation in speed while the trace executes is not nearly as great as it is for software trace routines. Also, since the trace routine requires no system support, such as I/O or loaders, it can be an effective tool for use in operating system development.

Abstract: Debugging of microprograms can be approached in three ways: (1) with the aid of hardware test sets and monitors, (2) through interactive debugging programs, and (3) through simulation techniques This paper discusses these three methods and describes an interactive debugging program and a simulator developed for debugging microprograms for the Interdata model 85 minicomputer

Abstract: The problems of converting programs to decision tables are investigated. Objectives of these conversions are mainly program debugging and optimization in practice. Extensions to the theory of computation and computability are suggested.

Abstract: : The automatic translation of computer programs from one language to another is the ultimate goal of this research project. The translation of programs is a primary concern of users anticipating an upgrading or replacement of computer hardware currently in use. It is also necessary to enable many users to share or purchase applications programs. Economic considerations dictate the general characteristics of the translator. Because of the volume of existing programs and the cost of manual reprogramming, the translator should be as nearly automatic as possible. Because of the complexity of such a translator, which means high developmental cost and time, it must be as generalized as possible. The design of the translating system developed through work on this project stresses flexibility in the use of the system, allowing it to fulfill alternate goals. Portions of the system may be used to provide uniform documentation of programs, or as debugging aids, or for program or compiler evaluation.

Abstract: Conventional dynamic debugging techniques are often restricted to machine level programs, while fully conversational compilers for powerful languages are costly to develop and will not fit into small systems. This paper describes a source-language debugging system for CORAL 66 which allows a user to run his CORAL program under teletype control, and to make changes to the source program. The changes are compiled by the debugging program and immediately incorporated into the object code. This provides a useful facility which can be added to all but the smallest systems.

Abstract: The computing community is now concerned with the cost in time and money consumed by the debugging process. In spite of advances, such as proving program correctness, use of higher level languages and new methods for structuring programs, the problem remains. The panelists will consider many phases of the debugging activity as it exists today, giving their views on current and proposed tools and techniques.

Abstract: SYSL-System Description Language, which is a higer level language like FORTRAN, COBOL and so on, has been developed as a system implementation language for use by DIPS-1 operating system, a large scale OS for time-sharing services, banking control services and so on.Run-time efficiency and space efficiency of SYSL object codes are 1.11 time and 1.17 times, respectively, of those obtained from assembly language.SYSL has been used to write about 90 per cent of language processors and other processing programs of DIPS-1 OSSYSL has reduced the huge amount of time required for coding, debugging, maintaining and documenting.

Abstract: A general syntax-directed strategy is described for translating computer programs written in a machine-level source language into equivalent programs in a higher-level target language. This translation process is referred to as decompilation or inverse compilation. Work on decompilation is potentially applicable in such areas as software portability, source-level debugging and diagnostic systems, and program analysis and validation.

Abstract: This paper describes a method for collecting statistics about the use of compilers as part of the programming process. Results of an application of this method to a time-shared system are presented. A study of the data leads to conclusions about the relative numbers and computer times of compilations used for program writing, correcting and checking. A comparison of two languages surveyed is also made.

Abstract: This paper describes a flexible hardware/software system developed for use with a PDP-8I computer for conducting research in behavioral neurophysiology. A real time monitor was designed to facilitate development, debugging, and modification of programs to run experiments. It relieves the programmer of the burden of dealing with hardware dependent functions such as interrupt handling and input/output. In addition, it provides the user with a large library of callable routines to perform functions commonly needed for conducting experiments. The monitor is modular in design and could be expanded or modified for use with many configurations of the PDP-8 family of computers.

Abstract: Non-programmers were asked to organize natural English commands of a laboratory programming language into programs for solving name-sorting problems. The problems differed in the sort concept to be programmed (conjunction vs. disjunction) and in the form of expression of the letter tests to be made on the names (affirmation vs. negation.) Programming performance was found to be impaired with disjunctive concepts and with letter tests involving negation. Different classes of program structure were identified and were associated with certain problem conditions and error measures. An influence of prior experience with procedures on performance was suggested. Program debugging and testing performance was characterized.

Abstract: The support of efficient debugging environments for systems software and complete operating systems was one of the initial motivations for virtual machine (VM) systems, such as IBM's VM/370 [2.12]. These systems typically provide a user with a VM which is a functional duplicate of a real computer system and which includes simulated switches, buttons, and lights (console functions) for rudimentary system debugging. In the same way that real console functions proved to be inadequate debugging aids for real machines [15, 18], virtual console functions have proved inadequate for VMs [9]. As a result, a number of more powerful debugging tools have been combined with VMs to yield more flexible debugging systems.

Abstract: This experiment represents a new approach to the study of the psychology of programming, and demonstrates the feasibility of studying an isolated part of the programming process in the laboratory. Thirty experienced FORTRAN programmers debugged 12 one-page FORTRAN listings, each of which was syntactically correct but contained one non-syntactic error (bug). Three classes of bugs (Array bugs, Iteration bugs, and bugs in Assignment Statements) in each of four different programs were debugged. The programmers were divided into five groups, based upon the information, or debugging “aids”, given them. Key results were that debug times were short (median = 6 min.). The aids groups did not debug faster than the control group; programmers adopted their debugging strategies based upon the information available to them. The results suggest that programmers often identify the intended state of a program before they find the bug. Assignment bugs were more difficult to find than Array and Iteration bugs, probably beca...

Abstract: A course in debugging techniques is motivated and described. A course outline, reading list, and projects list are included. Certain debugging aids are described. Debugging techniques for elementary algorithms are illustrated. Particular attention is paid to ways to teach debugging and algorithm structure.