ABACUS/X(ID:6996/aba004)Data General JOSS dialectEvolution of ABACUS/10 with an extensible language system and precision maths Related languages
References: THE ABACUS/X LANGUAGE ABACUS/X is a lineal descendent of another language known as ABACUS/10. ABACUS/10 in turn is itself an extension of the FOCAL (FOrmula CALculator) language first implemented by Digital Equipment Corporation. A detailed description of FOCAL may be found in (Digital Equipment Corporation). FOCAL is a paragraph-structured language which is designed to be interpreted and is, in fact, one of very few language translators implemented by pure interpretation. That is, the representation of the program stored in memory is pure, unedited and uncompressed ASCII source text. One implication of this approach to implementation is that the resulting interpreter is very slow. However, a more pertinent implication in the single-user minicomputer environment is that the user has unique capabilities and flexibility when utilizing the system interactively, Some characteristics of the language are: 1. Statement numbers consist of a group number and a line number separated by a period (e.g. 2.12, 14.60, etc.). The group number is used to segregate statements into paragraphs. Paragraphs may be executed by means of the "DO" statement in the same manner as the "PERFORM" verb in COBOL. 2. The object of the '~GOTO" and ~:DO" statements may be an arbitrary expression. Such expressions are evaluated at run time and the resulting value regarded as the target line or group number. 3. Individual lines or groups of lines may be deleted from a program either while in console command mode or dynamically while running. 4. Placing a "?" in a program statement activates a trace facility which outputs the ASCII source program statements on the console (or other output device) as they are interpreted. 5. There is no need to dimension arrays since, from FOCAL's viewpoint, a subscripted variable is merely a long variable name and is allocated when it is first referenced. That is, if A(4), A(2000), and A(38) were referenced in a program, space for only three variables would be allocated, not an entire array. FOCAL as originally implemented is unsatisfactory for business applications and, of course, runs only on DEC machines. ABACUS/IO is an extension of FOCAL implemented for Data General Nova computers with added facilities to adapt it for business applications. Among the features added are: support for a variety of disk drives, cassettes, floppy disks, printers and other peripherals. It is possible to chain programs together so one program can load another and initiate the new program's execution without user intervention. It is also possible to do dynamic program overlays on a line-by-line basis. ABACUS/10 has two disadvantages, however, which limit its usefulness. First, it is so slow that its viability becomes marginal in situations where computation is significant or large volumes of data must be processed. Second, its character handling ability may be charitably described as minimal. These defects made it essential to seek a replacement. In designing this replacement we were presented with several criteria: The resulting language was to be as compatible as possible with the original ABACUS/10, ~since there was already a substantial investment in programming; and retraining was to be minimized. Second, the new language was to have powerful character manipulation facilities. Third, the system was to retain all the flexibility of the ABACUS/10 interpreter. Finally, the system was to provide execution speeds comparable to that of compilers. The resulting translator was the incremental compiler ABACUS/X. This language is a superset of the old ABACUS/IO with the addition of the following features: 1. String variables like those in BASIC, including substrings, concatenation, literals, assignment statements, etc. 2. Input/output formatting similar to that in FORTRAN. 3. The integer data type is supported (ABACUS/IO has only reals). Also, double precision reals can be utilized if deslred 4. Logical IF statement (ABACUS/IO has only an arithmetic IF). 5. Encode/decode facility for converting strings to numerics and vice versa. 6. Genuine arrays created by dimension statements with generalized subscript bounds. 7. The I/O structure is far more elaborate than ABACUS/10's. Full access to operating system facilities is provided. Alternate versions exist which run under three different operating systems. 8. The machine code emitted by ABACUS/X is comparable to that produced by FORTRAN IV in both size and execution speed. Besides providing these significant extensions, the ABACUS/X language retains the full flexibility and convenience of its interpretive predecessor. Extract: INTRODUCTION INTRODUCTION Enduring the language translation process in a typical minicomputer environment can be a painfully time-consuming and frustrating experience. The low speed, low cost peripherals usually associated with a minicomputer (console teletype, paper tape reader/punch, magnetic tape cassette unit) are certainly not the translator writer's first choice to meet his input/output needs. Moreover, the seemingly innocent requirement for multiple passes over the source program has unfortunate implications in such an environment. Rewinding a cassette tape seems to take hours, and the message "Reload paper tape source program for second pass" has awakened many users to the fact that many translators do indeed read through the source program more than once. Today most computer programming is done through the use of a high level language for algorithm expression. The advantages of this method, including easier program development and more maintainable programs, are well known. In order for the computer to be able to use the program, however, it must first translate the high level language of the program into something meaningful to itself. Probably the most popular technique for accomplishing this translation is through the use of a compilers which generates the machine language equivalent of the high level language program. In the minicomputer environment, the source program is typically entered via a text editor~ and the resultant character string is then fed to the compiler one or more times to generate the hopefully usable object program. All errors lead one back to the editor for corrections to the source program, where another complete copy of the program is produced. The process is then repeated until either the prope K results have been obtained, or the user gives up from frustration or lack of more paper tape, Compiler object code is executed directly by the machine, and thus is very efficient in terms of execution time. Also, once the program works properly, the object code may be saved, thus eliminating the need for any more compilations. However, if even just one statement needs to be changed, the entire program must be recompiled. Also run time diagnostics tend to be difficult to interpret, due to the fact that there is usually no information maintained correlating the source statements with the resultant object code. Another popular technique for high level language translation involves the use of an interpreter, which scans a source state,cent (or some internalized form of it) each time the statement is to be executed in order to determine what actions are to be taken. An interpreter typically has a built-in editor, thus the source program is entered directly into the interpreter, usually with some amount of syntax checking being done at this time. Any source language errors detected here may be corrected by simply reentering the statement properly. When the entire program has been entered, issuance of a '~RUN' command starts program execution. Errors detected at run time are corrected by forcing the interpreter back to text entry mode, and changing the appropriate program statements to eliminate the error(s). Since the program exists in source language form, changing a single statement causes no retranslation problems, and interpreters are able to give excellent run time diagnostics. However, the interpreter must translate a program statement each time before its use, resulting in much slower execution speeds than when using compiled object code. A third, less popular technique for high level language translation involves the use of an incremental compiler, which generates the machine language equivalent of each source statement as it is entered into the system. The translation is performed on a statement-by-statement basis, rather than on the entire program at once, thus the term "incremental" compilation (See Katzan, 1969 for an excellent discussion of the incremental compilation process.). Source program entry is accomplished much as with an interpreter. Source statement errors are detected and diagnostics produced immediately upon entry of the offending statement. Corrections may be made by reentering the source line properly. Statements are compiled into object code if no source errors are detected, with appropriate links maintained for inter-statement references. Since the object code is generated as the program is entered, when the "RUN" command is issued for execution only inter-statement references need be fixed~up before execution of the complete machine language 6bject program can begin. The object code is directly executable by the machine, and thus is very efficient in terms of execution time, Also, most incremental compilers allow one to save working object code, thus eliminating the need for more compilations. If changes are to be made, however, only the statements affected need to be recompiled. This is accomplished by simply reentering the appropriate source statements. An incremental compiler is ideal for the interactive minicomputer environment, giving immediate source language diagnostics and taking the place of a text editor, while making program changes and corrections easy and fast. However, an incremental compiler may force certain restrictions on the high level language and its users. These restrictions, although not aesthetically pleasing to the purist, are generally of a minor nature, particularly when one considers the benefits gained. Probably the biggest disadvantage of an incremental compiler system is the amount of main memory residence required. In a minicomputer environment this is, of course, a major problem. In this paper we describe an incremental compiler that has been developed for Abacus Corporation, Detroit, Michigan, which takes advantage of the positive aspects of incremental compilers, while minimizing the negative aspects, as will be described herein. The compiler was implemented for the Data General Nova minicomputers (Data General Corporation), and is currently being used in a commercial turnkey system development environment. in SIGPLAN Notices 11(05) (May 1976) view details |