WATFOR(ID:307/wat006)WATerloo FORtranWATerloo FORtran. U Waterloo, Canada. Student-friendly variant of FORTRAN. WATFOR was a fast in-core compiler with good error diagnostics. Students could now submit programs for debugging. What made WATFOR really useful to the inexperienced programmer was those error messages: ERROR SV-0 IN LINE 2 (variable name). The first WATFOR compiler was written for the 7040 by four third-year math students Gus German, Jim Mitchell, Richard Shirley and Bob Zarnke in the summer of 1965 under the supervision of Peter Shantz. Structures: Related languages
References: I. Introduction Much of the attention given to compiling techniques for algebraic languages has been directed toward producing more efficient object code. automating the process of writing a compiler, and incorporating new features into the programming source languages. An area which has not received comparable emphasis is that of developing techniques to improve the diagnostic capabilities of compilers. This lack of emphasis may be in part due to the fact that the usual specifications of a programming language exclude or give little attention to the need of diagnostic capabilities, for example, the specification of ASA Basic FORTRAN or ASA FORTRAN (see [1]). In this paper CSC is described--the results of a compiler project undertaken at the University of Wisconsin Computing Center (UWCC). DITRAN (Diagnostic FORTRAN) is a FORTRAN compiler and operating system which provides extended diagnostic capabilities, both at compilation and execution time. One of the purposes in presenting this paper is to outline some of the design features of DITRAN which, when combined with some known algebraic compiling techniques, make it possible to achieve a high degree of success in the detection and analysis of compile time and execution time errors. DITRAN achieves many of its diagnostic capabilities by extending the notion of a storage unit by associating with each unit a vector of values which describes the status of a variable or array element during the execution of a program. Another purpose of this paper is to discuss, in general, some of the standards or objectives that ought to be set for the diagnostic capabilities of any compiler. DITRAN was written for the CDC 1604 and was put into operation at the UWCC in the summer of 1965. DITRAN has now received considerable use and the success with DITRAN supports the belief that more attention to this area of compiler development can provide worthwhile dividends. Although DITRAN operates as a compile-and-go batch processing system, many of the techniques employed to maintain information required for diagnostic capabilities ought to be of particular use in an interactive environment involving man and computer via an inputoutput device. Extract: Background and Objectives II. Background and Objectives Manufacturer-supplied FORTRAN compilers normally provide rather efficient object code, provide flexible interaction with the operating systems, and have many sophisticated programming features. However, they are inadequate for the needs presented in the area of finding and correcting errors as quickly as possible. In many instances, the description of an error condition lacks resolution and offers the user little assistance in removing the error other than indicating the statement in which the error occurs. A more serious inadequacy is that many error descriptions are given in terms not understandable to a FORTRAN programmer. For example, (1) several types of compilation time errors are passed on to the assembly phase and emerge as assembly errors which are quite often difficult for the user to associate with his source program, or (2) execution time errors are presented in terms of absolute or relative core locations and machine instructions, all of which are of little or no value to the FORTRAN programmer. Perhaps the most serious inadequacy of the compilers is the inability to detect some error conditions. These conditions are prohibited by FORTRAN manuals, but the compilers produce no messages for these errors. At execution time, these errors produce undefined results usually dependent upon the residual contents of storage locations of which the programmer is unaware and over which he has no control, for example, subscripting beyond the limits of an array, accessing an entity which has not been assigned a value, or performing real arithmetic on type integer data assigned to a type real entity through an I/O operation or through equivalence associations. In a university, a large portion of the users of a computing facility are students learning programming and graduate students or research investigators who are not full-time programmers but are faced with the need of using the computer as an educational or research tool. For this group, in particular, the concern of finding and correcting errors in their programs as quickly as possible outweighs the need for efficient object code and sophisticated protramming features. Programs submitted by this group generally involve a rather small amount of computer run time and have rather short useful lives. The ratio of machine time used for program checkout to that used for production is quite high. The interests of this group of users presented a need for a compiler which would provide a maximum of diagnostic information to the progrannner in order to shorten the checkout time. DITRAN was developed to provide a compiler with extensive diagnostic capabilities. It appeared that developing this compiler would increase the service of the computing facility in several areas. By providing more complete diagnostic information on all errors encountered, the compiler would aid in reducing the number of runs required to check out a program and thus would reduce the time to complete a project. It would also reduce the level of experience required to begin using the computer, and thus increase the availability of the facility to a larger number of users. Finally, by helping students and programmers correct errors without resource to an instructor or consultant, DITRAN would increase the utility of the facility for educational functions. in [ACM] CACM 10(01) (Feb 1967) view details DOI in [ACM] CACM 10(01) (Jan 1967) view details in [ACM] CACM 10(01) (Jan 1967) view details in [ACM] CACM 10(01) (Jan 1967) view details in SIGPLAN Notices 5(07) July 1970 view details in SIGPLAN Notices 5(07) July 1970 view details in SIGPLAN Notices 5(07) July 1970 view details in SIGPLAN Notices 5(07) July 1970 view details in SIGPLAN Notices 5(07) July 1970 view details |