Software Engineering and Programming Languages
During the past year, the Communications has printed approximately twenty papers in each of three main areas: programming language development, compiler management and construction, and numerical methods. In addition, about twenty new algorithms were published, as well as half a dozen papers covering the general area of education in computer science; new proposed standards were also disseminated for various types of paper tape, punched cards, and for data communication codes. Three of the twelve issues were conference issues consisting of papers originally given at the ACM Conference on Programming Languages and Pragmatics, the ACM Symposium on Symbolic and Algebraic Manipulation, and a Symposium on the Impact of Computing on Undergraduate Mathematics. A survey paper was published on simulation languages, and two reports were printed covering the computer scene in Communist China and Europe, respectively.
DITRAN—a compiler emphasizing diagnostics
DITRAN DIagnostic FORTRAN) is an implementation of ASA Basic FORTRAN with rather extensive error checking capabilities both at compilation time and during execution of a program. The need for improved diagnostic capabilities and some objectives to be met by any compiler are discussed. Attention is given to the design and implementation of DITRAN and the particular techniques employed to provide the diagnostic features. The handling of error messages by a general macro approach is described. Special features which provide teaching aids for use by instructors are noted.
System performance evaluation: survey and appraisal
The state of the art of system performance evaluation is reviewed and evaluation goals and problems are examined. Throughput, turnaround, and availability are defined as fundamental measures of performance; overhead and CPU speed are placed in perspective. The appropriateness of instruction mixes, kernels, simulators, and other tools is discussed, as well as pitfalls which may be encountered when using them. Analysis, simulation, and synthesis are presented as three levels of approach to evaluation, requiring successively greater amounts of information. The central role of measurement in performance evaluation and in the development of evaluation methods is explored.
Data directed input-output in FORTRAN
A statement which is similar to the NAMELIST statement of FORTRAN IV has been incorporated in the FORTRAN 63 compiler. The FORTRAN 63 implementation allows a greater flexibility and simplicity than the FORTRAN IV feature. The Hollerith names, the location, the made and the dimensions of a variable can be discovered by means of standard FORTRAN statements. Methods of using this information are illustrated in relation to general purpose data directed input and output routines; some other uses such as matrix manipulation are discussed.
WATFOR—The University of Waterloo FORTRAN IV compiler
WATFOR is an in-core, load-and-go compiler which has been implemented within the IBM 7040/44 operating system. FORTRAN IV was selected as the source language in order to achieve maximum language compatibility with other available compiling systems, in particular the IBM 7040/44 FORTRAN IV system. The principal advantage of the WATFOR compiler is that it translates FORTRAN IV programs at speeds of up to 100 statements per second. Since the compiler resides in core there is virtually no systems overhead, and hence large batches of “student” programs may be processed very efficiently. The compiler also provides extensive error diagnostics, during both the compilation and the execution phases of a program run. This feature makes the system attractive to both learners and learned users alike.
Letters to the editor: An interpretive input routine for linear programming
In this descriptive article an input code is presented which greatly simplifies data input to any linear programming solution routine, for subsequent use either as a predagogical device or for solving rather small LP problems. This latter (limited) use derives not at all from inherent limitations in the code itself, but from an efficiency evaluation: large LP problems would doubtless benefit from an input system more suited for bulk data handling than the input code described.
From a user's standpoint, input appears almost exactly as a textbook presentation of the LP problem (limited only by a keypunch's inability to write subscripts, etc.). The input interpreter scans columnwise, thus no fixed format data preparation is required. The user may also, under very general requirements only, liberally use editorial comments throughout the input deck as an aid in identification, e.g., of row constraints.
The article includes examples of input, output from a solution routine presently in use, and a skeleton flowchart of the input interpreter.
Shape the Future of Computing
ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.
Get InvolvedCommunications of the ACM (CACM) is now a fully Open Access publication.
By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.
Learn More