(A Thesis Presented to The Faculty of the Department of Applied Science The College of William and Mary in Virginia - August 1975)
by James Thomas Lee, Jr. 07/05/97
The purpose of this program is to provide a higher level language programming capability on a Control Data Corporation 3100 Computer for use by a staff of Operations Analysts. The CDC 3100 Computer has compiler capability for several higher level languages under the SCOPE and MSOS Operating Systems, but these systems cannot be used because of the ECDAPS (Evaluation Center Data Processing System) Software Package. ECDAPS is a dedicated software system which has been designed to accomplish an important military mission. The military mission requires ECDAPS twenty-four hours daily, but ECDAPS does not provide the needed programming capability. Thus a higher level language programming capability is possible only if a special program, an Interpreter, is augmented to the ECDAPS System.
The purpose of this manual is to thoroughly document the important features of the program as well as to teach all potential users to write.the language. Much of the language, in design, resembles FORTRAN, but in striving for additional flexibility, particularly in character string manipulations, and for implementing a more descriptive instruction set, some features from BASIC and ALGOL have been used.
The CDC 3100 Computer and its associated peripheral equipment help make up a highly sophisticated 32K computer system. The System's main memory is achieved from three interconnected storage modules of 8K, 8K, and 16K words of memory while additional memory is also available with two CDC 863 storage drum units. Each drum has a storage capacity of 1,048,576 words with a 500,000 word-per-second (2,000,000 characters per second) transfer rate and a seventeen-millisecond access time [1]. From the main frame, four communication channels join the computer with its peripheral I/O equipment. One of the channels connects to a CDC 3316 Mtiltiplexor which enables the addition of even more peripherals to the system. The various 1/0 equipment includes five teletypewriter circuits which are used for direct data input to the computer's data base from other military installations, a CDC 217 Cathode Ray Tube (CRT) Reader's Display Station which is used for operator data maintenance, a CDC 3192 Console Typewriter, an IBM 523 Card Punch, a CDC 501 High Speed (1000 Lines per minute) Line Printer, a CDC 405 Card Reader, a CalComp 502 Digital Incremental Plotter and four CDC 604 Magnetic Tape Transports (see Figure 1 [not included in this Internet version]).
In addition to the I/O equipment mentioned above, a minicomputer system interfaces, through the Multiplexor, with the CDC 3100 Computer System. The second system, consisting of a Sander's Computer Interactive Display (CID), a Scientific Engineering Laboratory (SEL) 810B mini-computer (16K), an ADDS 900 Digital Converter, and a Bell Telephone Laboratories 202 Data Set, enables a user-controlled display of data that is in the computer. A program request initiated from the CID Station causes a program execution at the CDC 3100 Computer with the subsequent data output transferred to the SEL 810B computer. From the SEL 810B system, the data is forwarded by the ADDS 900 to the Sander CID for display. Since data are displayed simultaneously by this system in both an alphanumeric and a geographic mode, a CID system is a key part of the overall CDC 3100 system, but the second system is always subordinate to and dependent upon the CDC 3100 system, and should be thought of as another I/O device.
The hardware described above becomes a complete system with the addition of ECDAPS. As stated earlier, ECDAPS is a dedicated software system which operates twenty-four hours daily on the CDC 3100 Computer. The software package was initially developed by, and is still maintained by the Bell Telephone Laboratories, Greensboro, North Carolina. The first ECDAPS, in 1968, was packed into only 16K words of core; hence, the main frame is composed of interconnected storage modules (as opposed to one larger unit) and other special function optional modules which mark the gradual growth of the system. As the system has grown, new hardware has been added to the old, and new software has been added to ECDAPS. In recent years, ECDAPS has seen major hardware additions, such as the two CDC 863 storage drum units and the CID System. With these additions and continuing research developments, ECDAPS has changed and is still changing.
Through all the additions, ECDAPS has developed into a massive system of programs, most of which operate on a single data base or other data bases,which are derived from the one data base. Among the different types of programs in the system are routines which list the data (in different formats), routines which calculate statistics or perform other meaningful analysis, routines which handle data maintenance, and routines which drive the CID System. The large volume of programs requires special storage consideration to eliminate the many possible conflicts which might occur with swapping programs in and out of core. For this reason, the first drum is divided into regions of 12K words each for program storage. When a program request is made, the computer loads the entire 12K region into core. Filling out the main memory is a section of program called Utility. Utility contains the data conversion routines, the mathematical functions, and other miscellaneous often-required routines which are essential for program execution. The region loaded is then able to link with the Utility routines and perform the requested program execution. When execution is complete, the 12K region is returned to its place on the drum.
Although desirable the ECDAPS does not have multiprogramming or an adequate priority interrupt system. As a result, many times the system will require users to wait for the completion of current program requests even though the waiter may have a higher priority need. This problem, though, will not be everlasting. The immediate future of ECDAPS calls for a priority interrupt system. The interrupt will cause longer running less important jobs to be interrupted to allow the processing of more important requests. The ECDAPS System is good now, but with the interrupt system, it will be much better.
The reader may be concerned about the pertinence of the above paragraph. Its purpose is to stress that even as ECDAPS programs are changing, the system supervisor is changing and the system Utility is changing, and in future years they will continue to change even more. All of these changes affect how the Interpreter must appear to the system. Since the Interpreter in all probability will have to stand through the changes, it must be developed to be as independent as possible of the ECDAPS System. With this in mind, it is necessary to.set a few ground rules which will provide maximum assurance that the program can stand almost any changes to ECDAPS.
Before it can be decided what the Interpreter may or may not use from the CDC 3100 System, including ECDAPS, an initial assumption must be made. Since all programs in the current ECDAPS versions have been stored in regions of 12K words each, (often more than one program will be in one region), and the Interpreter must also exist in the same region structure, it must be assumed that ECDAPS will always have regions for program storage. Although the above assumption is made, it is not imperative that these regions always be 12K words in length. The Interpreter will tell the supervisor where it lives by a region number, and the supervisor will then take over. So with this assumption, the concern can rightfully turn to which routines, or more accurately, which type of routines are to be included or excluded.
Logically those routines which are still in a developmental mode and are likely to change must be excluded. Such routines are the.ones which support the CID System. The CID System is still very new, and is constantly changing. Of consideration would be to duplicate some vital CID functional routines as part of the Interpreter, but the amount of core required makes such thinking impractical. So whereas the CID System might have been beneficial to users with access to the higher level language capability provided by the Interpreter, its software must be regarded as continually changing software to be avoided.
Also likely to change over time are routines which pass arguments. The arguments passed by these routines are often subject to change as new system capabilities or needs are created; therefore, routines which pass arguments and also routines which may in the future be required to pass arguments should be removed from the Interpreter. Essentially after a review of ECDAPS, it becomes apparent that most routines cannot be used for one of the two above reasons. Therefore, rather than try any longer to second guess the future of ECDAPS, the Interpreter will rely only on the system routines which have not changed, and which logically should never change. These routines are mostly of the variety which make I/O requests of the peripheral equipment and those routines which access the computer's data base. It should be noted that even these routines are not absolutely guaranteed never to change, but they should not change significantly enough to affect the Interpreter. Therefore, the routines which have been borrowed from ECDAPS for use with the Interpreter are as follows:
With such a small selection of system routines used by the Interpreter, many subroutines are required to fill the gaps. The user program, when read into the computer, is in binary coded decimal (BCD) format and must be converted to binary. Conversely, when the results of the program are ready to be printed, the data must be converted back to BCD from binary. Conversion routines will be necessary to convert real numbers, or floating point numbers, to the floating point notation for input and subsequent calculations, and from floating point notation back to a BCD real number for output. In addition, all mathematical routines must be developed and coded. Thus, a major effort in the development of the Interpreter will be the creation of a library of programs or utility routines to satisfy the programing requirements of the user. In the following pages, these routines will be discussed more carefully as seems appropriate.
1. Control Data Corporation, CONTROL DATA COMPUTER SYSTEMS, Section 3. "Peripheral Equipment Data (St. Paul: Control Data Corporation 1971), p. 7.
Section II. THE INTERPRETER IN DESIGN
Send email to: tlee6040@aol.com