Abstract: : We believe that software engineering has much to learn from other mature engineering disciplines, such as electrical engineering, and that the problem solving behaviors of engineers in different disciplines have many similarities. Three key ideas in current artificial intelligence theories of engineering problem solving are: Abstraction -- using a simplified view of the problem to guide the problem solving process. Inspection -- problem solving by recognizing the form ('plan') of a solution. Debugging -- incremental modification of an almost satisfactory solution to a more satisfactory one. These three techniques are typically used together in a paradigm which we call AID (for Abstraction, Inspection, Debugging): First an abstract model of the problem is constructed in which some important details are intentionally omitted. In this simplified view inspection methods are more likely to succeed, yielding the initial form of a solution. Further details of the problem are then added one at a time with corresponding incremental modifications to the solution. This paper states the goals and milestones of the remaining three years of a five year research project to study the fundamental principles underlying the design and construction of large software systems and to demonstrate the feasibility of a computer aided design tool for this purpose, called the programmers apprentice. (Author)

Abstract: We have been developing a debugging aid tailored to novice programmers learning to use a simple asaertional database language. Based in part on existing programmer's apprentice and debugging projects, our system makes several novel contributions: it is oriented towards a large audience (several hundred per year) of computernaive users; the system deals with argument passing, recursion, and side-effects. Symbolic evaluation of the user's code produces an effect-description which is compared with an idealised effect-description (derived from a library plan). The library plan uses domain-specific knowledge to allow the user a great deal of freedom to invent alternate approaches to the programming task at hand. Based on effect-description mismatches, a variety of hints for correcting the code can be given to the student.

Abstract: Layout languages provide users with the capability to algorithmically define cells. But the specification language is so non-intuitive that it is impossible to debug a design in that language, one must plot it. Interactive graphics systems, on the other hand, allow the user to debug in the form in which he sees the design, but severely restrict the language he may use to express the graphics. For example, he cannot express loops or conditionals. What is really needed is a single interactive system that combines layout language and graphic modifications to the data. This paper describes just such a system.

Abstract: : This report describes the third in a series of experiments to evaluate the effects of the format of software specifications on programmer performance. The current experiment examined performance on a debugging task. Thirty-six professional programmers were presented with specifications for each of three modular-sized programs. Nine different specification formats were prepared for each program. These formats varied along two dimensions: type of symbology and spatial arrangement. The type of symbology included natural language, constrained language (PDL), and ideograms (flowchart symbols). The spatial arrangement included sequential (vertical flow), branching (flowchart), and hierarchical (tree-like). The participants compared correct specifications to error-seeded program listings. Their task was to locate the several errors per program and to correct the errors using a text editor. The program output was checked automatically and a message informed the participants whether the output was correct or incorrect. The participants were asked to continue debugging until all errors had been located and corrected. The difficulty of the debugging task was measured by the time required to detect and correct the errors and by the number of submissions required for a correct run.

Abstract: This thesis describes an implementation of a facility for interactively debugging distributed programs. These distributed programs consist of groups of cooperating processes concurrently executing on an arbitrarily extensive network of processors. The facility allows the user to monitor and control, at his leisure, the interprocess communications that occur through message passing while execution of the distributed program proceeds. It presents the user with the ability to simulate transmission errors and delays, to alter and create packets, and to precisely control the pattern of such communications. The facility serves as a tool for the detection of lurking bugs, those errors, peculiar to parallel processing, which may or may not appear during the course of any particular execution. The facility possesses a high degree of transparency towards the program being debugged. That is, it has a minimal effect on the events that define the execution of that program. Transparency is a desirable property for any debugger to possess. To achieve such transparency, the processes of the distributed program are made to execute in a logical time environment, reading logical, rather than physical, clocks. We show that the facility obeys a clock condition, with which any logical time system must comply in order to be correct. We also show that the facility actually simulates the program it is being used to debug. Finally, we show that the facility simulates a particular computation of the program that is likely to occur. The notion of probable simulation is defined, and our debugging facility is shown to achieve it.

Abstract: Existing citations of the Sackman programming research are in error. This letter clarifies the scope of the research, and the conclusions which can be properly drawn from it.

Abstract: Recent trends in computer architecture have increased the amount of control logic (e.g., microinstructions) in digital systems, thus making testing and debugging a more formidable task. This correspondence discusses the needs and objectives of software simulators for testing and debugging microprogram logic, and discusses a simulator developed to aid the development of a large microprogrammed system.

Abstract: A master/slave model of writable control store is presented which is claimed to be a better representation of the operating system view of control store than models which more accurately portray the physical reality. Reported work includes the completed development of UNIX tools: an assembler generating relocatable, linkable microcode; a linking, relocating loader; a fast absolute loader; an interactive hard debugging aid allowing the setting of breakpoints; and alterations of the UNIX kernel allowing the driving of WCS as a “slave processor” consistent with the model. Code for the system driver and microcode portions of the debugger are included in the paper. The design goals of the multi-user sharing of control store, representing work now in progress, are listed. These include the use of the UNIX text segment management as the basis for association of control store routines with processes and the use of the debugging aid snapshot routines in the swapper.

Abstract: Introduction to microcomputers computer arithmetic and logic operations the basic computer accumulator and memory reference instruction stacks, sub-routines, and other instructions assembly language for the 6800 hardware configuration of the 6800 system input/output interrupts, timing, and direct memory accesses system debugging other 8-bit microprocessors new concepts in microcomputer development systems real world applications and interfacing techniques CRT display terminal application the 6800 family advanced features of the newer members of the 6800 family.

Abstract: This dissertation addresses the extension of traditional dataflow modeling to include specifications to allow additional control over the execution environment. Three major studies are presented: (1) a comparative analysis of several proposed and existing dataflow models and architectures, (2) the specification of several extensions for generalizing traditional abstract dataflow models and providing the opportunity to express greater parallelism, and (3) the design and implementation of an evolutionary test bed for realizing the simulation of dataflow programs and systems. The extensions to the abstract dataflow model include: (1) a generalized firing rule to eliminate unnecessary synchronization introduced by requiring all inputs to be available before enabling nodal execution, (2) a mechanism for obtaining a higher degree of parallelism through replication of nodes, (3) a concept of generalized termination detection and signaling useful in supporting replication and streaming, and (4) the description of methods for supporting shared data objects and interprocess communications in a multiple process dataflow environment. The dataflow simulator, DFSS, was developed in support of this work and is a highly generalized facility for realizing the execution, debugging, and metering of dataflow programs.

Abstract: PURPOSE:To shorten the time of debugging by executing instructions when control over program processing is transferred from a program to be debugged to the other and then by advancing the program, instruction by instruction, when the control returns to the program to be debugged. CONSTITUTION:Once debugging indication information is input from console input part 3, instruction cycle assigning flip-flop (FF)A, mode setting FFs B and C and FFs for comparison information bits R1 and R2 are put into operation. As an opera- tor indicates the start of a program, an instruction is read out of a memory and tranferred to register information bit parts P1 and P2, whose outputs are compared by comparing circuits C1 and C2. Consequently, whether the program is that to be debugged or not is decided. When neighter FFB nor C is in operation while FFA is in operation, results of comparing circuits C1 and C2 are invalidated and an instruction run mode is validated.

Abstract: PURPOSE:To monitor including debugging with a minimum number of pins, by utilizing searial transfer for the console processing of a microcomputer, and devising the internal processing of a CPU. CONSTITUTION:Address data transferred in series from an external circuit 15 for a console are fetched and stored in a shift register 16, and the address data are compared with data in a program counter 28; when the both coincide, an arithmetic processing part 12 is held. While the CPU is held, memory reading/ writing operation for debugging is performed. Further, address data for an address stop is sent ot the CPU.

Abstract: PURPOSE:To simplify program formation and debugging and shorten the data handling time, by setting conversion mode of address converting circuit, which slave computers have, different from one another. CONSTITUTION:Slave computers 51-5n are connected to memory bus 4, and respective slave computers are equipped with address converting circuits 61-6n, shared memories 71-7n, and local CPUs 81-8n. In this system configuration, conversion modes of circuits 61-6n are set so that these modes are different one another in computers 51-5n. Therefore, memories 71-7n have memory addresses different one another only for read at the view from master CPU1. Consequently, in case that the same data is written from CPU1 to memories 71-7n, the same data can be written to different addresses of memories 71-7n by giving the same memory address to bus 4, so that the access time is reduced to the 1/n. Then, data written into shared memories can be used and processed simultaneously in slave computers.

Abstract: Text is not the only data that needs editing. For example, interactive debuggers edit data structures internal to running programs. This paper describes eds, a generalized editor that allows users to edit arbitrary data structures. Examples show eds maintaining simple databases, editing LISP S-expressions, debugging SNOBOL4 programs, and creating and modifying data structures for a computer graphics system.

Abstract: The KIM-1 simulator is a development tool for the MOS Technology 6502 microprocessor and the KIM-1 microcomputer. It is written in the C programming language and runs under the UNIX operating system on a DEC PDP-11/60. The input to the simulator is ob ject code produced by a cross-assembler. The simu lator helps in debugging 6502 programs by providing the user with the ability to interactively load and display memory and registers, dynamically set and clear breakpoints, handle interrupts, and trace pro gram execution.The simulator is user-oriented; it supplies prompts, English diagnostics, and instructions on usage. Its execution speed and core requirements allow truly interactive debugging.The KIM-1 simulator, in conjunction with the cross- assembler and the actual KIM-1 microcomputers, has been an excellent educational tool for an introduc tory course in computer organization and assembly- language programming. In addition, it has helped researchers using the 6502 microprocessor in appli cations.

Abstract: One of the development aids for the digital signal processor (DSP) is a software simulator, dspsim, which runs interactively under the UNIX∗ operating system. It is a program debugging tool which can be used without access to the DSP hardware environment. It allows the user to monitor run-time characteristics of DSP programs which cannot be observed using the device itself. It is very flexible in providing capabilities for single or multiple program stepping, setting and modifying conditional breakpoints, examining register contents and generating data plots on the terminal.

Abstract: Several methods were employed to detect both the occurrence and source of errors in the operational software of the AN/SLQ-32. A large embedded real time electronic warfare command and control system for the ROLM 1606 computer are presented. The ROLM computer provides information about invalid addressing, improper use of privileged instructions, stack overflows, and unimplemented instructions. Additionally, software techniques were developed to detect invalid jumps, indices out of range, infinte loops, stack underflows, and field size errors. Finally, data are saved to provide information about the status of the system when an error is detected. This information includes I/O buffers, interrupt counts, stack contents, and recently passed locations. The various errors detected, techniques to assist in debugging problems, and segment simulation on a nontarget computer are discussed. These error detection techniques were a major factor in the success of finding the primary cause of error in 98% of over 500 system dumps.

Abstract: PURPOSE:To enable an efficient program test by taking the program test by writing the contents of ROM, in which a program has been written, in RAM by using the ROM as a source of loading. CONSTITUTION:When ROM3 in which a program has been written is inserted into socket 7 and start switch 15 is closed, CPU1 starts through the operation of control program memory 2 to transfer the contents of ROM3 to RAM4 and on the end of the transfer, lamp 8 turns on. When RUN switch 16 is closed with the address of a program to be tested set to entry switch 9, CPU, executes the program from an as signed address to start debugging operation. At the same time, lamp 10 turns on. When the program is relocatable, terminal (a) is connected to (c) in switch 17 to place ROM3 in an unselected state and addresses of RAM4 are changed over for debugging.

Abstract: Experimental results are presented indicating that programming techniques with identation, documentation, mnemonic variable names, modular design, as well as external design aids (i.e. structure charts, data flow diagrams, but not flow charts), correlate with fewer errors. Results also indicate that programmers who use these techniques take less time to detect and solve program bugs, suggesting that efficiency is increased.

Abstract: PURPOSE:To make it possible to improve the efficiency of debugging remarkably while making operation simple and easy by direct inputting an insturction code at a break in the simulation of software CONSTITUTION:In case that instruction MOVM and A happen to stay between addresses 44H and 45H, a break point is set to address 45H and at the point in time when a program is interrupted, instruction code ICD77 is only keyed in manually As a result, instruction MOVM and A are executed to insert the program without any influence on a program counter and any other address change processing Consequently, since instruction INXH at address 45H is executed, ICD insertion and its operation in software simulation become extremely easy and simple, so that the efficiency of software debugging will greatly improve

Abstract: PURPOSE:To prevent the coding miss to shorten the coding time, by providing an input device equipped with pages for different programming languages, a control unit which formats programs according to grammar, a memory unit, and a display unit. CONSTITUTION:This unit consists of processing unit 22 consisting of control unit 12 and main memory 14, floppy discs 18 and 20 connected to control unit 12, input device 10 having the keyboard which includes key mat 30 equipped with many keys 32 connected to control unit 12, and display unit 16 which is connected to control unit 12 and displays images. The program used for generation of four DIVISIONs such as IDENTIFICATION and ENVIRONMENT is stored in disc 18, and the program of the coding result is stored in disc 20. Thus, complicated and redundant fixed-form instructions and sentences can be input with one touch, and coding can be performed automatically, so that the debugging time can be shortened and program development can be achieved in high speed.