Abstract: Timing Analysis is a design automation program that assists computer design engineers in locating problem timing in a clocked, sequential machine. The program is effective for large machines because, in part, the running time is proportional to the number of circuits. This is in contrast to alternative techniques such as delay simulation, which requires large numbers of test patterns, and path tracing, which requires tracing of all paths. The output of Timing Analysis includes "Slack" at each block to provide a measure of the severity of any timing problem. The program also generates standard deviations for the times so that a statistical timing design can be produced rather than a worst case approach. This system has successfully detected all but a few timing problems for the IBM 3081 Processor Unit (consisting of almost 800 000 circuits) prior to the hardware debugging of timing. The 3081 is characterized by a tight statistical timing design.

Abstract: It is essential to assess the reliability of digital computer systems used for critical real-time control applications (e.g., nuclear power plant safety control systems). This involves the assessment of the design correctness of the combined hardware/software system as well as the reliability of the hardware. In this paper we survey methods of determining the design correctness of systems as applied to computer programs.

Abstract: The long standing conflict between the optimization of code and the ability to symbolically debug the code is examined. The effects of local and global optimizations on the variables of a program are categorized and models for representing the effect of optimizations are given. These models are used by algorithms which determine the subset of variables whose values do not correspond to those in the original program. Algorithms for restoring these variables to their correct values are also developed. Empirical results from the application of these algorithms to local optimization are presented.

Abstract: A tracing facility which is useful in a multiprocessing environment on a single processor is disclosed. Tracing statements are encoded within each process, each statement having arguments to indicate its location in the code and a message which is logged when the sybsystem and function corresponding to that tracing statement are selected for debugging. Each process includes a trace library that is called by each trace statement, and the trace library includes a local sync word and a local trace table having a list of the subsystems and functions currently selected for tracing. Each process has access to a global sync word and a global trace table having a list of the processes, subsystems and functions selected for tracing. A change in the trace operation is made by changing a parameter in the global trace table and changing the value of the global sync word to indicate that a change has been made in the global table. Each call to the trace library causes a comparison to be made between the local sync word and the global sync word to determine whether the local trace table should be updated from parameters in the global trace table. Each trace statement also has an argument that indicates its level of importance in the debugging operation, and both tables are caused to have a parameter which indicates the level at which trace statements are currently required to be logged.

Abstract: Architectural support of high-level, symbolic debugging is described at three levels of abstraction: the user's view of desired debugging functionality, the debugger implementor's view of architectural requirements that support the functionality, and the computer architect's view of architectural features or attributes that implement the requirements. References are made where possible to computing systems that meet the requirements. The paper is written from the viewpoint of debugger implementors, and is addressed primarily to computer architects.

Abstract: This paper describes FADS --- a Form Application Development System which is an interactive system for the development of form-based database applications. FADS reduces the amount of work required to implement a forms application by suppressing much of the detail which would be required by conventional tools (e.g., a screen definition system, a database system, and a programming language). FADS provides direct access to a relational database, a standard model of the user interface, built-in form constructs, and an integrated development and debugging environment. Using FADS, form applications can be developed quickly and the resulting systems are easy to modify.A prototype implementation of the FADS kernel has been completed.

Abstract: DIRECT is a multiprocessor database machine designed and implemented at the University of Wisconsin. This paper describes our experiences with the implementation of DIRECT. We start with a brief overview of the original machine proposal and how it differs from what was actually implemented. We then describe the structure of the DIRECT software. This includes software on host computers that interfaces with the database machine; software on the back-end controller of DIRECT; and software executed by the query processors. In addition to describing the structure of the software we will attempt to motivate and justify its design and implementation. We also discuss a number of implementation issues (e.g., debugging of the code across several machines). We conclude the paper with a list of the "lessons" we have learned from this experience.

Abstract: : This report describes KBS, a Knowledge-Based simulationsystem The report describes the use of SRL, an Al-based knowledge representation system for modeling (eg, factory organizations), and its interpretation of discrete simulations KBS provides facilities for interactive model creation and alteration, simulation monitoring and control, graphics display, and selective instrumentation It also allows the user to define and simulate a system at different levels of abstraction, and to check the completeness and consistency of a model, hence reducing model debugging time (Author)

Abstract: A hand-held application module directs the operation of a programmable manipulator controlled by digital computing means. The module identifies points to which the end effector of the programmable manipulator shall move, programs the programmable manipulator to direct the precise operations relative to the points, selectively runs to one or more points to debug the entered program and retrieves statements for display in its alpha-numeric display facility. Program statements and parameters may be deleted from the program, and program statements and parameters may be added to the program. Entry of commands is made through a keyboard and data is displayed on an alpha-numeric display.

Abstract: This paper presents a partial review of the human factors work on computer programming. It begins by giving an overview of the behavioral science approach to studying programming. Because of space limitations this review will concentrate on cognitive models of programmer problem solving and the experimental research on language characteristics and specification formats. Areas not reviewed include debugging, programming teams, individual differnces, and research methods. The conclusions discuss promising directions for future theory and research.

Abstract: Hardware without software is of little use. Systems that ease the task of debugging software reduce cost and speed development. This paper presents guidelines for designing processors that ease debugging for real-time computer systems. Special hardware can aid the debugging process by tracing execution and accesses to memory. Such hardware requires access to signals that may not be readily available. Other, less exotic hardware provides an interface to the programmer and other processors. The hardware and software of the debugging system should not alter the real-time characteristics of the system under test and should be able to operate on a field-grade processor. It is undesirable to require special versions of processor hardware and software for the debugging system.

Abstract: This thesis describes work done on debugging techniques and tools for communicating, loosely-coupled processes. Our work is intended to reduce the apparent complexity of large systems of communicating programs by regarding only the interprocess activities of such programs. The use of multiple, communicating processes as a model of computation allows for a very clean "cut" of what information is interesting for debugging and what is not. Our approach to debugging is to provide the user with information about how sets of these processes behave rather than what each program associated with each process does. Our tools provide various primitives for manipulating the interprocess activities of processes. We provide nothing to access the source code of any program. Our tools include a debugger program, a mechanism to fire and execute interprocess debugging demons and the ability to obtain transcripts of interprocess activities. The debugger provides commands for the user at a terminal for creating and manipulating individual interprocess events. Demons are an event-driven mechanism used to automatically monitor and modify interprocess events. Transcripts provide a record of interprocess events that can be replayed later. Our debugging techniques make use of these tools to provide individual process control, communication monitoring and process testing. Process control includes the ability to create, suspend and destroy processes as well as the ability to obtain various process-related information. The communication monitoring facility monitors message traffic and can dynamically alter the contents of these messages. Process testing allows a user to isolate a process (or simulate a process) by creating and intercepting all message traffic in and out of a process. This thesis also describes a debugging system called SPIDER that was built to demonstrate the above debugging tools and techniques. A multi-process kernel is included in SPIDER that supports communicating, loosely-coupled processes. SPIDER also includes an implementation of each of our proposed tools: a debugger program, a mechanism for firing demons and a transcriber. Several examples using SPIDER are given to show how our debugging techniques can be achieved with our debugging tools.

Abstract: Most high level languages with multiprocessing do not have built in mechanisms to detect deadlocks during program execution. We present transformation rules for taking an original Ada program P and deriving a new program P', such that P' has a potential deadlock iff P does, and P' signals whenever a deadlock is about to occur. In principle, the transformations can be applied mechanically, giving a practical tool for debugging deadlocks. Since this method modifies the source program, it can be used with any implementation of the language, without special knowledge of the implementation of tasking. The transformations that we have developed thus far are sufficient to handle most of the complexities of Ada tasking, including arbitrary task types, conditional entry calls, selective waits, timed entry calls, and intertask exceptions.In the course of this work, we have developed some generally useful source program transformations, such as one to uniformly introduce task identifiers. We have also developed some interesting concurrent algorithms for the deadlock monitoring.An actual monitor program for detecting deadlocks has been implemented in Ada.Our basic approach and monitoring algorithms are applicable to other languages with multiple processes.

Abstract: : GRAPES is a goal-restricted production system designed for modeling human cognitive processes. The system's declarative knowledge resides in a dynamic working memory and its procedural knowledge is embodied in condition-action rules known as productions. Each production can apply only in reference to the current goal. The goals are organized in an and/or tree with the root mode being the top goal, which is specified by the user. The tree is explored in a left-to-right, depth-first manner. Features of the language include goal parameter specification, flexible goal matching, LISP functions calls within production rules, and a host of user-accessible functions designed for their powerful matching ability. The interpreter includes an interrupt capability, a photo package, a tracing mechanism, and various debugging facilities. One peripheral module contains proceduralization and composition, two learning mechanisms used to acquire new productions. Another module contains useful functions for modelling LISP programmers. GRAPES is best-suited for highly goal-directed tasks involving planning or problem solving.

Abstract: PURPOSE:To increase the debugging efficiency, by displaying the state of execution of a program to be debugged in a 2-dimensional way and in correspondence to a plan of program. CONSTITUTION:The execution process of a program to be debugged at a computer process part 1 is rcorded sequentially to a recording part 6 through an interface 4 and a control part 5 and then displayed on a display part 10 based on the conditions given from an input/output part 11 and under the control of the part 5. The result of execution obtained at that moment is equal to the instruction code of machine word and the internal state such as the contents of a program counter, other register etc., and the program code is stored previously in a storage part 7. Thus the working state can be displayed after developing it into an easy-to-see form in contrast to the program code.

Abstract: and slave processors, this group of microprocessors addresses a wide range of system applications. When LSI/MOS chips were first developed, it was possible for designers to place approximately 1000 active elements on a single chip. Now, ten years later, the number of active elements per chip has risen to over 100,000. As we enter the second decade of LSI/MOS technology, applications for its use are continually expanding as the computational power of newly developed 16-and 32-bit microprocessors approaches that of mainframe computers. In short, microprocessor designers have their work cut out for them. Currently, software development efforts are becoming responsible for ever larger shares of product development costs. To offset these costs, microcomputer designers are shifting toward high-level language programming. Increasingly , users expect microprocessors to provide a cost-effective solution for HLL support with minimal degradation in overall system performance; this sets tougher requirements for microprocessor designers. Sophisticated future systems will require a combination of capabilities. Anticipating these needs, National Semiconductor has developed the NS 16000 microprocessor family to incorporate various architectural features into a new generation of devices. Utilizing National Semiconductor's XMOS technology, the design of the NS16000 family is implemented with 3.5-micron gate technology. This allows for a smaller die size, leading to a reduction in chip cost. The design challenges in creating this new family were met only after thoroughly considering market requirements and LSI technology limitations. This article describes some of the capabilities provided by the NS16000 architecture.

Abstract: In this paper we describe the design, testing, and use of drand48—a good, pseudo-random number generator based upon the linear congruential algorithm and 48-bit integer arithmetic. The drand48 subroutine is callable from C-language programs and is available in the subroutine library of the UNIX∗ operating system. Versions coded in assembly language now exist for both the PDP-11 and VAX-11 computers; a version coded in a “portable” dialect of C language has been produced by Rosler for the Western Electric 3B20 and other machines. Given the same initialization value, all these versions produce the identical sequence of pseudo-random numbers. Versions of drand48 in the assembly language of other computers or for other programming languages clearly could be implemented, and some output results have been tabulated to aid in testing and debugging such newly coded subroutines. Timing results for drand48 on the PDP-11/45, the PDP-11/70, the VAX-11/750, and the VAX-11/780 are also presented and compared.

Abstract: Dartmouth College has implemented a single debugger for several languages sharing a common runtime environment: PL/I, Basic and Fortran. The debugger is fairly powerful; users set breakpoints and traces which occur whenever the values of given variables change, or whenever certain relational expressions become true, for example. All debugging is carried on in a syntax similar to that of a high-level language. This debugger was implemented in about a month. It should be fairly easy to implement on most timesharing systems. This paper describes the debugger's user interface and gives a rough sketch of its implementation.

Abstract: We are currently implementing a system to help experienced programmers during the development, implementation and debugging of their programs This system, built on top of a screen oriented structural editor, offers possibilities of attaching descriptors to every portion of the program and to maintain - simultaneously - different versions of the program being written, including tentative hypothetical versions It comprises a mecanism to maintain minimal consistency between modified parts of code, the non-modified parts of code and the attached descriptors, as well as an evaluation module functioning in different modes : normal evaluation, symbolic evaluation and checking evaluationThe standard programming aids, such as indexors, pretty printers, trace packages, undo- and history-facilities are generalized to handle the descriptors and unfinished programs as well

Abstract: We consider programming languages which allow procedures to be declared dynamically and to be passed as parameters. The influence of these two features on the decidability of "formal parameter correctness," "formal recursivity," and other properties relevant for debugging and optimization has been studied in [5---12]. In this paper we study the feasibility of such decision procedures in those cases where decidability has been proven. Thus this paper presents a complexity-theoretic refinement of some of the recursion-theoretic work from [5---12]. It is divided into two parts. The main results in part I are: In part II [15] we will analyze the complexity of such problems in restricted classes of programs.

Abstract: Emulation is playing a key role in the development of a BELLMAC-32A microprocessor-based computer system at Bell Telephone Laboratories. The emulation is used for the development of the operating system for the new computer system to permit both hardware and software development to proceed in parallel. The emulation's goal is to permit the operating system to be developed before the hardware is available. This is aimed at reducing the time and effort required in the hardware/software integration interval to permit a more rapid introduction of a computer system - both hardware and operating system.Emulation is one of several software/hardware models being used in the development of the computer system. There are also functional, gate-level, manufacturing-model simulations used in the development of the BELLMAC-32A microprocessor. Several steps are used in verifying the emulation as well as cross-verification of the BELLMAC-32A microprocessor portion of the different models.Both the BELLMAC-32A microprocessor and the computer system were emulated. The emulation model includes an emulation of the memory mapping, interrupt structure, memory management and peripherals of the real processor. It is an instruction-level compatible emulation that provides high throughput for software debugging. Since the bit layouts of the software that runs on the emulation and the real machine are identical, code that runs on the emulation will run on the real machine except for time dependent code. Since the emulator is a form of software, it can be instrumented for additional debugging capabilities.The emulator went through a rigorous development methodology of requirements, design, implementation and testing phases. Each phase had reviews and/or walk-throughs. Further, the testing phase was done by personnel other than the emulator developers to ensure that the product met external specifications as seen by the customers of the emulation.The emulator development environment includes both microcode development tools and lab environment debugging tools. Both sets of tools run on the UNIX [1] operating system. The microcode development tools include an assembler, pre- and post-processors for generation of microcode, and a microcode simulator for testing the microcode. Both a pre- and post-processor were developed to aid in generating microcode for the emulator developers. Additional pre-processors were taken from other standard UNIX software to further aid the developers with conditional assemblies and symbolic references.The lab environment for the emulation makes use of a UNIX software based front-end lab support processor that interfaces to the emulation processor. A powerful debugging tool is available to the emulator developers on the front-end processor to permit single stepping at both the micro and macro level, display and modification of internal registers, give microinstruction traces, provide breakpointing capabilities, provide microcode and object code download capabilities and to maintain control of the emulation machine.

Abstract: : In this report a language-independent multiprocessing environment for managing human-computer dialogue is described. One of the main reasons for such an environment is that it helps to enforce the separation of modules that deal with human-computer dialogue from those that deal with computation while at the same time providing for concurrencies that would not otherwise be possible. Embedded in the environment are debugging aids that facilitate software preparation and a priority mechanism for sequencing interprocess communications. (Author)

Abstract: Partitioning is the process of formulating a single application program so that it runs on a system of multiple cooperating processors. When cooperating in this fashion, the processors share the computational work of the problem. This dissertation investigates tools which a programmer may use to simplify the partitioning of algorithms for effective execution on a high-performance multiprocessor. The motivation for partitioning assumed is simple decrease in overall execution time, i.e. multiprocessor speedup of the algorithm. Focus is provided by emphasis on the structure of a particular system currently under construction, the S-1 multiprocessor. The S-1 consists of 16 very high-performance general-purpose uniprocessors connected to a uniformly addressed, fully shared memory. A large number of mechanisms, techniques, and environments are included in the set of tools useful in constructing a partitioned algorithm. The categories of tools considered in this dissertation are: (1) programming language mechanisms for specification and control of partitioning; (2) operating system mechanisms for controlling parallel execution; (3) hardware mechanisms for synchronization, communication, and sharing; (4) automatic aids for discovering and defining parallelism in algorithms; (5) simulation environments for studying aspects or parallel execution with various parameters; (6) debugging tools for use in real and simulated multiprocessing; and (7) performance monitoring and tuning tools. The tools proposed in this dissertation have been successfully applied to the task of partitioning a number of sample programs, which were selected as representative of realistic multiprocessor applications. The partitioning experiments helped discover potential performance difficulties, and also suggested ways to enhance the set of tools.

Abstract: The Real-Time Signal Processor (RSP) is a programmable signal processing architecture that was created to provide a quick and economical way to implement signal processing applications. The objectives that were chosen to meet these goals were that the RSP be easy to program, suitable for LSI implementation, and conveniently connectable into distributed systems. It was also intended that the RSP would be able to capitalize on the Reduced Computational Complexity (RCC) algorithms [1], [2], in order to achieve increased performance. Fabrication of the initial RSP chips was recently announced [3]. In this paper, the basic RSP architecture is given and interesting features of that architecture are highlighted.

Abstract: The feasibility of a speech coding algorithm is most effectively indicated by its successful real-time implementation. The implementation effort presents issues distinct from those related to the development of the algorithm. Problems of real-time software design and debugging, system reliability, and implementation correctness must be addressed. In addition, the power of a general purpose array processing computer may be required to accomplish the real-time aspect of the implementation. The unique, often highly parallel, architecture of available array processors can present the additional issues of multiprocessor intercommunication and control. This paper considers successful approaches to these issues in the context of two real-time speech coder algorithms implemented on an array processor, a linear predictive baseband coder operating at 9.6 kbits/s, and an adaptive predictive coder operating at 16 kbits/s.

Abstract: The “Wolf Fence” method of debugging time-sharing programs in higher languages evolved from the “Lions in South Africa” method that I have taught since the vacuum-tube machine language days. It is a quickly converging iteration that serves to catch run-time errors.

Abstract: The development of computer-aided engineering (CAE) is discussed. Engineering work stations now available on the market provide tools to: simulate circuits that have been drawn, draw circuit designs on a screen by means of a graphics tablet, keep track of different stages of a design so that several designers working on different modules will all be using the proper version of each module, and integrate graphics with text documentation. Simulators are most commonly used to help design large systems, where the cost of building prototypes and debugging them justifies extensive design verification.