DITRAN(ID:2759/dit002)Diagnostic FORTRANfor DIagnostic FORTRAN Moulton, Univ. of Wisconsin, Madison 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 A few of the features of DITR\N worth mentioning are: all diagnostic messages are given with reference to the source language; error messages give a maximum amount of information, to guide the user in making corrections; wherever possible, errors are detected at the compilation stage; linkages for tracing routines are provided (though the routines themselves have not yet been implemented). >DITRAN has reached its goals by compiling directly to core and remaining in memory during execution. There is a discussion of the safeguarding of the compiler against accidental damage, using this method. A particular feature of the compiler is the structure of storage units for variables and arrays. These units are treated as vectors whose components contain various items of information needed for execution-time handling of errors such as: definitional status control; type control; DO nest control, and others. A performance record is kept of program runs which contains items such as: program size, compilation and execution time, number of errors in the various categories, etc. The reported experience with DITRAN seems quite impressive. An improvement by a factor of about ten over standard compilers is claimed, in batch mode processing of students' problems. in [ACM] CACM 10(01) (Feb 1967) view details A few of the features of DITR\N worth mentioning are: all diagnostic messages are given with reference to the source language; error messages give a maximum amount of information, to guide the user in making corrections; wherever possible, errors are detected at the compilation stage; linkages for tracing routines are provided (though the routines themselves have not yet been implemented). >DITRAN has reached its goals by compiling directly to core and remaining in memory during execution. There is a discussion of the safeguarding of the compiler against accidental damage, using this method. A particular feature of the compiler is the structure of storage units for variables and arrays. These units are treated as vectors whose components contain various items of information needed for execution-time handling of errors such as: definitional status control; type control; DO nest control, and others. A performance record is kept of program runs which contains items such as: program size, compilation and execution time, number of errors in the various categories, etc. The reported experience with DITRAN seems quite impressive. An improvement by a factor of about ten over standard compilers is claimed, in batch mode processing of students' problems. in [ACM] CACM 10(01) (Feb 1967) view details Introduction Conversational programming systems are enjoying a great vogue at present. Commercial time-sharing services are doing good business, and following the success of systems such as BASIC and of JOSS (alias TELCOMP alias JEAN) 'conversational FORTRAN' and 'conversational ALGOL' are being offered. However, these terms are not particularly well defined. Very often, all that is provided is a simple editing facility for source programs and an ability to communicate with the teleprinter at run-time, coupled to a more-or-less standard 'batch' compiler. (In one system of the author's acquaintance, the user of the conversational FORTRAN system is required to type his program as formatted card images, without the benefit of a TAB mechanism.) Another term that is used in this connection is 'incremental compiling', again, often without a clear definition. In this paper we aim to define the term 'conversational programming system' in a pragmatic way by considering the facilities that the user might expect to see. We then discuss various ways of achieving this for a FORTRAN-like language, including incremental compilation, and suggest a system that combines the external features that the programmer wants with reasonable internal efficiency. (As will be seen, this does not necessarily imply a fully interactive compiler.) Extract: City Conversational FORTRAN A few years ago a FORTRAN system was developed for student work at The City University: in order to achieve good diagnostics this system employed many of the techniques outlined in this paper, although it was intended for batch use. Unfortunately, no description of this significant piece of work was published at the time. in The Computer Journal 14(1) 1971 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in The Computer Journal 14(1) 1971 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in The Computer Journal 14(1) 1971 view details |