The Implementation Of A Special Language Interpreter
(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
Section V. CLOSING COMMENTS {966 words}
When thoughts first began to develop the Interpreter for the CDC 3100 Computer, they were somewhat vague and unsophisticated. As a result, much of the finished Interpreter is vague and unsophisticated. The original idea was to develop a language which could utilize features of other popular higher level languages, but as the program began to unfold, new requests began to surface. The Interpreter began as a small system primarily for my personal programming needs with the staff's computer, but soon, others became interested in the planned capabilities for the system. High among everyone's priorities was a FORTRAN Interpreter because many of the staff's analysts have massive FORTRAN programs which can be adapted to the CDC system.
The first attempt at the Interpreter does not have the FORTRAN Interpreter, but some effort has been made to lay the groundwork for the change. Essentially, the only modification required is to change some instruction names and to perhaps add some new instructions. It was decided not to move into the FORTRAN version of the Interpreter with this present system because of the following reasons:
l. By the nature of the staff's request and the already mentioned core limitation on the Interpreter, a massive FORTRAN program cannot be executed in 12K words of core.
2. A major concept in FORTRAN programming which has not been dealt with in the first version of the Interpreter, also because of core, is subroutine programming. The reader will probably note that subroutines are designed to save core; however the mechanics of simulating the FORTRAN subroutine will entail lengthy software. It would be nearly pointless to strike out in the direction of subroutines too soon if the results were less than desirable. It is hoped that the opportunity will later arise to update the current Interpreter with the subroutine capability.
3. The entire FORTRAN instruction set is quite massive, and the expected effort for the original Interpreter was to be just a few months. My military tour at the command ends in a short while, and I had hoped to leave at least the current higher level language programming capability for the staff.
As time permits toward the end of my military tour, I hope to fulfill the expectation of a FORTRAN Interpreter in the following ways:
1. The most severe deterrent to the addition of the FORTRAN Interpreter is, as was cited above, core. From Section IV, the reader knows that the length of the user's program is limited to 500 instructions (see Section IV, para lc). Surely most lengthy FORTRAN programs will exceed the instruction limit. In addition, the size of the data tables is limited to 1000 words of core. These limitations simply are not realistic for a user's program, and they must be greatly increased if the Interpreter is to be of value. The update to the Interpreter will shift program and data storage to tapes. This modification alone will unlock core to allow the Interpreter to tackle any and all programs. The use of a tape for program storage and another tape for data files will remove the user from the ridiculous restrictions which must be imposed on the 12K Interpreter.
2. The reader will recall that the Interpreter uses the first two characters to identify the type of'instruction in a statement. The routine PREPROC actually uses a table to compare the instruction name entered by the user with the instruction name recognized by the Interpreter. When a match is found the routine rewrites the instruction using the corresponding two character codes for the instruction. If the table used for the comparisons had a new set of instruction names, and the user changed his instruction set accordingly, then the instruction names have been changed. For example in the current instruction set, the user must use the command CARD to cause the interpreter to read a card. If the name in the table were changed to READ, the user would be required to use READ to have his card read. Of note, the instruction in PERM would still be stored with the same two-digit code CA for CARD, but to the user, the instruction READ would be executed. The above procedure will be implemented to modify the current instruction set to match the FORTRAN instruction set. Of course the instruction set which now exists with the Interpreter is only a small part of the set which will be required for FORTRAN. Thus conversion will require not only changing the names of many of the current instructions, but also the addition of many new routines.
3. As was noted above, the addition of subroutine capability will be a high priority for the upcoming changes.
4. In the I/O Statements, the instructions do not provide for the implied loop that is, the user cannot express the variable operand as an array with the indice being an automatically incrementing variable. At the present time, the user must either loop through the statement until he has covered the desired elements, or he must repeat each element in the I/O instruction. In the update, this implied loop is a planned addition.
5. In Section III, the reader might recall that the Interpreter had reserved jump switch 4 for a special purpose. Now that purpose can be revealed. As programs are written for the Interpreter, a dual requirement will develop for a FORTRAN Interpreter and the special language Interpreter. Therefore, by use of the jump switch 4, the user can have a choice of the Interpreter he prefers.
With the final changes as outlined above, the Interpreter will be finished, unless of course, more needs occur. At that time, the user should have unlimited program and data storage areas, and he should have FORTRAN as well as the Interpreter's language with which to work.
APPENDICES
Back To The Table Of Contents
Back To TLEE's Home Page
Send email to: tlee6040@aol.com