TL;DR: The problem of identifying instructions is examined and an algorithm that will 'usually' perform a correct analysis is described, and other aspects of disassembly are discussed and algorithms outlined.
Abstract: A crucial problem in the decompilation or disassembly of computer programs is the identification of executable code, i.e. the separation of instructions from data. This problem, for most computer architectures, is equivalent to the Halting Problem and is therefore unsolvable in general. The problem of identifying instructions is examined in this paper and an algorithm that will 'usually' perform a correct analysis is described. In addition, other aspects of disassembly are discussed and algorithms outlined. (Received October 1978; revised May 1979)
TL;DR: It is shown that there are reasonable conditions (for programs with a finite number of paths) for which ensuring the testing of all paths does not give better assurance of program correctness, and three examples are presented of methods for determining s-confidence bounds on the failure proportion.
Abstract: The point of all validation techniques is to raise assurance about the program under study, but no current methods can be realistically thought to give 100% assurance that a validated program will perform correctly. There are currently no useful ways for quantifying how 'well-validated' a program is. One measure of program correctness is the proportion of elements in the program's input domain for which it fails to execute correctly, since the proportion is zero i.f.f. the program is correct. This proportion can be estimated statistically from the results of program tests and from prior subjective assessments of the program's correctness. Three examples are presented of methods for determining s-confidence bounds on the failure proportion. It is shown that there are reasonable conditions (for programs with a finite number of paths) for which ensuring the testing of all paths does not give better assurance of program correctness.
TL;DR: This paper presents a demonstration of the current implementation of Tinker, an experimental interactive programming system which integrates program testing with program design and constructs a procedure for the general case from sample calculations.
Abstract: Tinker is an experimental interactive programming system which integrates program testing with program design. New procedures are created by working out the steps of the procedure in concrete situations. Tinker displays the results of each step as it is performed, and constructs a procedure for the general case from sample calculations. The user communicates with Tinker mostly by selecting operations from menus on an interactive graphic display rather than by typing commands. This paper presents a demonstration of our current implementation of Tinker.
TL;DR: Two approaches to the development of efficient and correct iterative programs are contrasted: the construction of an iterative program and a proof of its correctness using invariant assertions of loops, and the construction and proof of a recursive program with a subsequent transformation into an Iterative version by schematically applying suitable recursion removal rules.
Abstract: Two approaches to the development of efficient and correct iterative programs are contrasted: the construction of an iterative program and a proof of its correctness using invariant assertions of loops, and the construction and proof of a recursive program with a subsequent transformation into an iterative version by schematically applying suitable recursion removal rules. The connection between the approaches is demonstrated by augmenting such transformation rules by inductive assertions. It is argued that the latter approach to program development is superior since the correctness proof of a recursive program is easier in most cases. Considerable verification overhead can be avoided this way, in particular, some difficulties with the interaction of successive loops and their associated invariants.
TL;DR: The computer program reported on in this paper is directed towards an improved simulation package to assist decision makers in the construction and process industries and significantly extends the concepts of CYCLONE and also includes a comprehensive treatment of cost with an automatic sensitivity analysis.
Abstract: The computer program reported on in this paper is directed towards an improved simulation package to assist decision makers in the construction and process industries. The starting point for the new simulation program is a modeling methodology called CYLCONE. The new program significantly extends the concepts of CYCLONE and also includes a comprehensive treatment of cost with an automatic sensitivity analysis. Other extensions include improved reports, plots of probability distributions, and regeneration of resources with a change in shifts or the beginning of subsequent days. Equally significant are the improved capabilities of the new simulation program brought about through the use of (GTICES) Georgia Tech Integrated Civil Engineering Systems. This system accommodates very large programs by means of dynamic program linkages and dynamic arrays. GTICES also provides for a very flexible problem oriented language. The simulation methodology for the computer program is developed, the GTICES system is examined briefly.
TL;DR: Results were obtained by attempting to thoroughly understand the "subgoal induction" method by exposing the basic differences of the methods and the underlying principles involved.
Abstract: A study of several of the proof of correctness methods is presented. In particular, the form of induction used is explored in detail. A relational semantic model for programming languages is introduced and its relation to predicate transformers is explored. A rather elementary viewpoint is taken in order to expose, as simply as possible, the basic differences of the methods and the underlying principles involved. These results were obtained by attempting to thoroughly understand the "subgoal induction" method.
TL;DR: A mathematical theory of program testing which describes how testing can be used to show a program's correctness, and a method for generating test data for recursive programs having only certain types of simple errors.
Abstract: This report presents a mathematical theory of program testing which describes how testing can be used to show a program's correctness. We study the situation where the programmer has written a program P which is either correct or which differs from the correct program by one or more errors in a specified class E of errors. The theory relates: (1) The combinatorics of how errors in E could have led to P being written. (2) The type of program behavior that the programmer will observe when testing; for example the program's output or a trace. (3) The characteristics of test data which is guaranteed to reveal the presence of errors in P.
The theory is developed at a general level and is then specialized to the case of recursive programs having only certain types of simple errors, where the programmer observes a trace of each test run. We derive a method for generating test data for recursive programs. The generated test data is complete, meaning that if the only errors in the recursive program are of the specified simple types, then the test data will reveal the errors through at least one incorrect trace. Viewed contrapositively, if one assumes that the program differs from the correct program at most by errors of the specified simple types, then if the trace of each test run is as the programmer intended, then the program must be correct. The test data generation method has been implemented and examples of its operation are given.
TL;DR: A real-environment interactive testing procedure is presented which is based upon a hierarchical decomposition of a program into levels of abstraction based on a program model which involves both control and data flow.
Abstract: A real-environment interactive testing procedure is presented which is based upon a hierarchical decomposition of a program into levels of abstraction. Such a decomposition is defined in terms of a program model which involves both control and data flow. The testing strategy adopted is supposed to follow a typical progress of a programmer who carries out a series of experiments with his program. Several semantical and structural issues involved are discussed.
TL;DR: The axiomatic and functional models of the semantics of structured programming are presented together with their respective methodologies for proving program correctness and for deriving correct programs.
Abstract: This paper discusses axiomatic and functional models of the semantics of structured programming. The models are presented together with their respective methodologies for proving program correctness and for deriving correct programs. Examples using these methodologies are given. Finally, the models are compared and contrasted.
TL;DR: The author reviews an earlier study, in which programmers were largely unsuccessful in finding known errors in a test program, and shows that the fault lies not with the subjects but with the generally poor procedures underlying the writing of much contemporary software, including the test program in question.
Abstract: The data processing discipline is in a deplorable state, says Roger House. The author reviews an earlier study, in which programmers were largely unsuccessful in finding known errors in a test program. House shows that the fault lies not with the subjects but with the generally poor procedures underlying the writing of much contemporary software, including the test program in question. He analyzes the example, offers several specific critiques, and enumerates good software-writing practices.
TL;DR: A graphical representation for data and program specifications is introduced and it is shown how this can simplify the techniques and be very useful in program construction.
Abstract: The present paper discusses a method of program construction based on the specification of the data types. The input and output data types and the mapping between them are specified at a high level of abstraction and this non-procedural specification is used to develop a program schema. The data type and mapping specifications are modified to include a concrete representation of the data and these are used to expand the program schema into a program. A graphical representation for data and program specifications is also introduced and it is shown how this can simplify the techniques and be very useful in program construction. The method is illustrated by developing two programs—the line justifier program described by Gries and the bubblesort.
TL;DR: An exploratory study was conducted to determine what personal, environmental and program-related factors affect the process of discovering errors in computer software.
Abstract: Purpose and Procedure. An exploratory study was conducted to determine what personal, environmental and program-related factors affect the process of discovering errors in computer software. The literature regarding each of the two prevailing philosophies concerning program debugging is review
TL;DR: A better way to check a program you have written is to have someone else write a program that does the same thing and then compare the output of the two programs over a wide range of input.
Abstract: The usual ways of checking computer programs have important flaws. A better way to check a program you have written is to have someone else write a program that does the same thing and then compare the output of the two programs over a wide range of input. Two examples are described.
TL;DR: In this paper, an evaluation methodology based on problem solving techniques is proposed for defining and analyzing problems which impair program performance. But the model is not suitable for the case where the information reported to decision makers may be incomplete, inconclusive and of limited utility in the decision-making process.
TL;DR: Two tools are developed as aids in the above tasks: transformation rules for synthesizing code from specifications in a top-down manner and techniques of program annotation for determining what an incorrect program actually does - before attempting to debug it.
Abstract: : Techniques of program modification are formulated, and an experimental software system implemented, whereby a given program that achieves one goal can be transformed into a new program to achieve a different goal. The essence of the approach is to find an analogy between the specifications of the given program and of the desired program, and then to transform the given program accordingly. Program debugging is considered as a special case of modification: if a program computes wrong results, it must be modified to achieve the intended results. The abstraction of a set of concrete programs to obtain a program schema and the instantiation of abstract schemata to solve concrete problems are also viewed from the perspective of modification techniques. Two tools are developed as aids in the above tasks: We describe transformation rules for synthesizing code from specifications in a top-down manner. They may be used when - in the course of modifying a program - the need arises to completely rewrite a program segment. For the purpose of determining what an incorrect program actually does - before attempting to debug it - we develop techniques of program annotation. These techniques are expressed as inference rules and derive invariant assertions from the program text. (Author)
TL;DR: In this article, a methodology for the analysis of a civil defense program for which estimates of overall performance have been made using the Population Defense (POPDEF) and Program Analysis (PAM) models so as to ascertain the relative contributions of the elements of the program to its effectiveness is presented.
Abstract: : A methodology is documented that allows the analysis of a civil defense program for which estimates of overall performance have been made using the Population Defense (POPDEF) and Program Analysis (PAM) models so as to ascertain the relative contributions of the elements of the program to its effectiveness. The method is applied to a candidate program and estimates of the program in terms of added survival, total and uninjured. The relative effectiveness of program elements, individually and in selected combinations, is given in terms of cost per survivor added. (Author)
TL;DR: A system which automatically generates program documentation is described, starting with a plan generated by analyzing the program, which computes several kinds of summary information about the program.
Abstract: This paper describes a system which automatically generates program documentation. Starting with a plan generated by analyzing the program, the system computes several kinds of summary information about the program. The most notable are: a summary of the cliched computations performed by the loops in the program, and a summary of the types and uses of the arguments to the program. Based on this information, a few English sentences are produced describing each function analysed.
TL;DR: It is pointed out that the analog of Kirchhoff's voltage law does not apply to flowcharts, and that the analogy is likely to be of limited value as an aid to program analysis.
Abstract: A recently proposed analogy between discrete systems and flowcharts is discussed. It is pointed out that the analog of Kirchhoff's voltage law does not apply to flowcharts, and that the analogy is likely to be of limited value as an aid to program analysis.
TL;DR: An original approach of Debugging is presented, which uses a procedural description of the program task, under the form of a program model, to determine the correctness of programs implemented in various ways, very different from the program model.
Abstract: We present in this paper an original approach of Debugging. The general goal in Automatic Verification of Programs is to prove that a program is correct or incorrect. This does not generally provide enough information to catch the bugs. On the opposite, the purpose of the debugging system LAURA, that we have designed and implemented, is to find the errors.
In order to debug a student program, the LAURA system uses a procedural description of the program task, under the form of a program model. Debugging is then viewed as a comparison of two graphs, built from the student program and from the program model. The system can apply powerful semantic transformations on the graphs to increase their resemblances and to identify subgraphs that perform a same task.
The LAURA system has shown to be able to determine the correctness of programs implemented in various ways, very different from the program model. It can also express sophisticated diagnostics and set up proper corrections.
TL;DR: This checking program has successfully met the requirements of low program execution cost, multi-technology capability, and ease of use.
Abstract: The large scale use of the MP2D program along both defense and commercially oriented companies has created the need for an inexpensive means of checking the correctness of the resulting standard-cell based array designs. This checking program has successfully met the requirements of low program execution cost, multi-technology capability, and ease of use.
TL;DR: A significant performance improvement was obtained by altering the program structure of the Pascal‐P compiler to reflect the dynamic behaviour of the program.
Abstract: This note describes some interesting results observed during the implementation of Pascal-P upon a Data General NOVA computer. A significant performance improvement was obtained by altering the program structure of the Pascal-P compiler to reflect the dynamic behaviour of the program. Some implications of this behaviour for the design of computer architectures are discussed.
TL;DR: A solution to one aspect of the program acquisition problem, the incremental construction of program models from informal descriptions, is presented in the form of a framework that includes a formal language for expressing program fragments that contain informalities.
Abstract: Program acquisition is the transformation of a program specification into an executable, but not necessarily efficient, program that meets the given specification. This paper presents a solution to one aspect of the program acquisition problem, the incremental construction of program models from informal descriptions [1], in the form of a framework that includes (1) a formal language for expressing program fragments that contain informalities, (2) a control structure for the incremental recognition and assimilation of such fragments, and (3) a knowledge base of rules for acquiring programs specified with informalities.
TL;DR: Results indicate that flow-graph based program analysis and direct analysis of the program's parse-tree can be performed by essentially the same methods, making uniform data-flow analysis procedure for optimizing compilers possible.