Write up on Tech Geek History: FORTRAN Complier

Literature Review
FORTRAN as a Programming Language
The FORTRAN programming language was conceived in the early 1950s the name produced from the two words Formula Translation. In 1966 the language was standardized and FORTRAN IV was born.
Revision of the language led to FORTRAN 77, the language we use today. The standard for FORTRAN 90 is now available although not yet in widespread use. F77 is a subset of F90.
FORTRAN was designed for scientists and engineers, and has dominated this field. For the past 30 years FORTRAN has been used for such projects as the design of bridges and aero plane structures, it is used for factory automation control, for storm drainage design, analysis of scientific data and so on.
The Fortran Programming Language
Fortran is a programming language with a long history. Originally developed in the 1950s, it was first created in a time before the internet, laptop computers, and desktop computers before computers even have a screen. Fortran was created at a time when computers were almost exclusively designed and operated to carry out numerical operations. Programming in Fortran today is very different from how programmers introduce instructions and compile codes. During the first decades of electronic computers, programming was done with punched cards, data was stored in tapes, and results were printed with dot matrix printers. Over more than 60 years, the language itself has evolved to accommodate new ways of programming, new hardware, new levels of complexity, and new ways of using computers for numerical calculations.
Evolution of Fortran
The first versions of the language introduce many of the concepts used today in most programming languages, the idea of loops, conditionals, and variables. Those elements are so commonplace today that we do not see as anything revolutionary, but FORTRAN was the first language to introduce many of those elements in programming, at least in a way that resemble the ways we program today.
The first milestone in the language was achieved with FORTRAN 77. This standard introduces structured programming and the processing of characters. Structured programming allows us to create larger codes and reuse pieces of code in ways that are easier to understand for a human. FORTRAN 77 was so successful that took more than a decade to reach an agreement over the new milestone. Fortran 90 added array, modular and generic programming. Those elements increase the flexibility of codes to accommodate data in run time instead of requiring constant recompilation when the parameters changed. Modules allow even larger codes to introduce tools to aggregate routines with variables. Fortran 90 left behind some issues that were solved in Fortran 95. Fortran 95 clarify some aspects of the language and was the first to introduce some parallelization techniques (HPF) well before OpenMP and other paradigms proved to be more effective for that. Fortran 2003 was the next big step in introducing Object Oriented Programming in a way that makes sense for scientific computing. The most recent developments in the language come from Fortran 2008 and 2018 which includes native parallel computing in the form of Co-arrays.
With such extensive evolution of the language, the standard retained compatibility with previous versions, being far more conservative than other languages. Scientific codes are developed for decades and used even longer. Many of the codes that run today on larger supercomputers were first developed in the 1980s and could have 1 million lines of code or more. If the language specification does not retain some compatibility many of those efforts could be lost or will become attached to older compilers losing the ability to evolve themselves.
.In this Paper is discussed the Earlier Version of Fotran; the History of:
Focusing on Fotran Compliers what Fotran is most distinctive
The IBM 1401 FORTRAN compiler1 was designed as a set of phases that operate sequentially on the source program. The source program having been placed in core storage, the compiler phases enter core one at a time. Each phase overlays its predecessor, operates on the source program and, in turn, is overlaid by the next phase of the sequence. Thus, in contrast to the customary technique of passing the source program against the compiler in core, the compiler is passed against the source program which resides in core. It is assumed that the source program is more concise than the object program, and that an object program of interest can be accommodated in core.
The 1401 FORTRAN compiler was designed for a minimum of 8000 positions of core, with tape usage being optional. The fundamental design problem stems from the core storage limitation. Because the average number of instructions per phase and the number of phases selected are inversely related (at least to a significant degree), the phase organization was employed to circumvent the core limitation. The 1401 FORTRAN compiler has 63 phases, an average of 150 instructions per phase, and a maximum of 300 instructions in any phase.

---

efficiency of the compilation technique Experience with the compiler suggests that, even though the basic compilation technique requires repetitive scanning of the source program, the time required for this redundant effort is small. The experience lends some credence to the following argument.
If a phase is decomposed into two serially acting phases, assume that the average execution time is increased by a multiplicative factor r. If each component phase is again decomposed into two phases, the average total execution time of the resulting four phases increases to r2 times the original. After k decompositions, 2k phases result, with an average total execution time of rk times the original. Under this assumption, it follows that an n-phase compiler takes rlog2n times longer than a comparable one-phase compiler. Because some phases do not involve scanning, this estimate may tend to be high.
Based on experience with the present compiler, it is conjectured that r ~ 1.05 and that the redundant work occasioned by the use of 63 phases increases compilation time by a factor of 1.05log263 ~ 1.3.
However, this technique reduces compilation time elsewhere, so that the net increase can be expected to be less than conjectured. Since the phases act serially, tape searching is unnecessary. Moreover, no external sorts or merges are required. After one pass of the processor, the object program lies in core storage, ready for execution.
Also, the present technique permits an approach to coding that tends to reduce compilation time. Decomposition into an appropriate number of phases often results in more available core space for execution of an individual phase than the minimum needed.
The typical phase requires only on the order of 150 instructions, although twice that number are accommodated by the allocated region in core. Thus, most of the code can be written for efficient execution without regard to economy in the number of instructions employed. Other advantages inherent in this type of coding are that it is usually faster to write and easier to debug.
________________________________________compilation time Except for certain extreme cases in which the object program fills almost all of core, the compilation time in seconds t is approximated by a linear function of the number of FORTRAN statements n (the statements assumed to be of average complexity). If the compiler is on tape, reads the source program from cards, and punches a self-loading machine language object program, then t = (0.96n + 72) seconds. As a load-and-go system, with the punching of the object program suppressed, t = (0.76n + 22) seconds. If the system is on cards, an additional 173 seconds are required.
________________________________________compiler phases The principal function of each phase of the compiler2 is indicated below. Secondary functions are subordinated; for ex- ample, error checking occurs in almost every phase, but is seldom mentioned.
Phase 00 – Snapshot. Loads a snapshot routine into 350 positions of core storage. This routine lists a specified amount of core storage.
Phase 01 – System Monitor. Brings in the next phase from the system tape or initiates reading of the next phase from cards, depending on whether the compiler is used as a tape or card system. The monitor and snapshot routines are the only ones that exist in storage throughout compilation. Because the phases act serially, very little is required of this phase which consists of only 20 instructions.
Phase 02 – Loader. Stores the entire source program, statement by statement, with all non-significant blanks eliminated. The source program is stored backwards in order to use the 1401 machine instructions that cause address registers to decrement when processing data. Appended on the right of each statement is a three-position internal sequence number (001 for the first statement, 002 for the second, etc.). The sequenced source program is printed.
Phase 03 – Scanner. Determines the type of each statement and appends a code on the right of each statement. For example, D for DO, S for STOP, I for DIMENSION statements, etc.
Phase 04 – Sort I. Determines if there is enough free storage to expand each statement by three characters.
Phase 05 – Sort II. Statements of the same type are chained together. Each statement expands by three characters-the machine address of the next statement of the same type.
Phase 06 – Sort III. The source program is sorted3 internally by statement type. The order of sorting is determined by the order in which statements of a given type undergo specific processing by subsequent phases. For example, since DIMENSION statements are processed (Phase 09) before DO statements (Phase 46), the DIMENSION statements are grouped together lower in core than the DO statements.
Phase 07 – Insert Group Mark. This is a housekeeping phase.
Phase 08 – Squoze. The words that helped define the type of each statement are eliminated, shrinking the source program. For example, the word “DIMENSION” in DIMENSION statements is eliminated.
Phase 09 – Dimension I. The DIMENSION statements are scanned, and an array table is generated in free storage. Each table element consists of the name of an array, its dimensions, and sufficient space for additional data to be. generated by Phases 11 and 12.
Phase 10 – Equivalence I. Adds simple variables present in EQUIVALENCE statements to the array table. These variables are treated, in effect, as one-element arrays.
Phase 11 – Equivalence II. The array table is altered to show the relationship between arrays. Equated arrays are chained together. Essentially, the procedure makes known to every array whose first element is equivalent to a secondary element of another array the “distance” to the first element of the latter array.
Phase 12 – Dimension II. The object-time addresses which delimit each array are computed and inserted in the array table. These addresses are also printed.
Phase 13 – Variables I. The entire source program is scanned for variables. The following changes are made directly within the text of the source program:
Simple variables are tagged for later processing by Phase 16.
Subscripted variables with constant subscripts are replaced by the object-time address of the designated array element.
All other subscripted variables are put into a canonical form which specifies a computation in terms of variables and constants for determining the object-time address of the array element specified.
Non-subscripted array names appearing in lists are replaced by the object-time address that delimit the array named.
Non-subscripted array names appearing elsewhere are replaced by the object-time address of the first element of the array.
Phase 14 – Variables II. All free storage (including the array table) is cleared and partitioned into two tables areas-Tables I and II. Parameters needed for the randomizer of Phase 16 are computed.
Phase 15 – Variables III. Does housekeeping for Phase 16.
Phase 16 – Variables IV. The source program is scanned twice for simple variables (already tagged by Phase 13). During the first scan, the compiler looks for variables being defined, i.e., those appearing on the left of an equal sign or in input lists. By means of a randomizer that computes an indirect address (a Table I address at which is located a Table II address), each such variable and its object-time address is stored uniquely and sequentially (one after another) in Table II. The object-time address replaces the variable name in the source program. During the second scan, all other variables are picked up, and the same process is carried out, except that undefined variables are noted and Table II entries are flagged whenever referenced.
Phase 17 – Variables V. Table II is scanned. The absence of a flag indicates an unreferenced variable. The object-time address of each variable is printed.
Phase 18 – Constants I. The entire source program is scanned for constants. Each constant encountered is normalized and tagged. Tables I and II are destroyed.
Phase 19 – Constants II. All free storage is again cleared and partitioned into two table areas- Tables I and II. Parameters are now stored, each with its identifier (Phase 32), in lower core immediately to the left of the list and format “statements.”
Phase 20 – Constants III. The entire source program is scanned for normalized constants (tagged by Phase 18). By means of a randomizer (as in Phase 16), each normalized constant is stored uniquely and sequentially (next to one another) in Table II. Once stored, these constants are at their object-time address and are not disturbed for the remainder of the compilation. The object-time address replaces the normalized constant directly in the text of the source program.
Phase 21 – Subscripts. Under the action of Phases 14 through 20, the canonical form for subscripted variables (see Phase 13) now specifies a computation in terms of object-time addresses. This phase simplifies the computation, leaving only the object-time addresses which serve as parameters for a closed subroutine at object time.
Phase 22 – Statement Numbers I. Statement numbers that appear in the source program are reduced to a 3-character representation. Statement numbers within the body of a statement are moved to the front of the statement.
Phase 23 – Format I. FORMAT statements are checked to ensure that they are referenced by input/output statements.
Phase 24 – Format II. The object-time format strings are developed and stored immediately preceding the constants at the lower end of storage.
Phase 25 – Lists I. Duplicate lists are checked and eliminated to optimize storage at object time.
Phase 26 – Lists II. The object-time list strings are developed and stored immediately to the left of the format strings at the lower end of storage.
Phase 27 – Lists III. Each input/output statement is reduced to the address of the list string (when present), the address of the format string (when present), and the tape unit number (where applicable).
Phase 28 – Statement Numbers II. All free storage is again cleared and partitioned into two tables-Tables I and II. Parameters needed for Phase 29 are computed.
Phase 29 – Statement Numbers III. By means of a randomizer (as in Phase 16), statement number representations (Phase 22) appearing within statements are stored uniquely, one after another, in Table II. Each such representation is replaced by the machine address at which it is stored.
Phase 30 – Statement Numbers IV. Statement number representations are matched against Table II entries via the randomizer of Phase 29. The sequence number of the statement (Phase 02) replaces the Table II entry. The Table II address (which now contains the sequence number) replaces both the representation and the sequence number in the source program. Undefined and multiply-defined statement numbers are checked.
Phase 31 – Statement Numbers V. Table II is scanned for unreferenced statement numbers (representations).
Note: Whereas the source program originally was composed of constants, variables, and statement numbers of arbitrary length, it is now highly structured and is composed of 3-character machine addresses. Machine addresses substituted for constants and variables are their object-time addresses. Machine addresses substituted for statement numbers are indirect addresses which currently reference Table II entries-sequence numbers of labeled statements. Eventually (Phase 51) these indirect addresses are replaced by the object-time addresses of the labeled statements, i.e., the addresses of object programs compiled from these statements.
Phase 32 – Input/Output I. The residue of each I/O statement other than BACKSPACE, REWIND, and END FILE is substituted into an object-time mask. The filled-in mask and an identifier are stored in lower core immediately adjacent to the last entry in Table II. The identifier is the sequence number (Phase 02) or, only when the statement originally had a statement number, the machine address of the sequence number stored in Table II (Phase 30).
Phase 33 – Arith I. All arithmetic expressions appearing in the source program are scanned. Switches are set to indicate which function routines must be loaded by Phase 52. Minor changes are made to expressions, and sufficient error testing is done to expedite Phase 34.
Phase 34 – Arith II. By means of a transition matrix,4 each arithmetic expression is broken down into a sequence of one or two operand sub-expressions involving temporary dummy storage locations.
Phase 35 – Arith III. Initialization for Phase 36.
Phase 36 – Arith IV. Redundant references to temporary dummy storage locations are eliminated by forming maximal strings of operands and operators from each sequence of sub-expressions. Each string specifies the computation in which (1) unary operators act on the entire substring immediately to their left and (2) binary operators combine this substring with the operand on their right.
Phase 37 – Arith V. Exponentiation operators are replaced by substrings involving log and anti-log functions. Implied mode changes are made explicit by inserting (or deleting) fix or float operators in the strings. The Table II addresses (Phase 29) appearing within IF statements (involving arithmetic expressions) are substituted into masks of object-time instructions. The filled-in mask replaces the addresses in the source program.
Phase 38 – Arith VI. The arithmetic strings are altered so that temporary storage areas are shared whenever possible. Machine addresses are determined for these areas and substituted for the dummy addresses in the strings. Previous arithmetic and IF statements are now stored, each with its identifier (Phase 32), in lower core immediately to the left of the list and format “statements.”
Phase 39 – End file, Rewind, Backspace.
Phase 40 – Computed Go To.
Phase 41 – Go To.
Phase 42 – Stop/Pause.
Phase 43 – Sense Light.
Phase 44 – If (Hardware).
Phases 39 through 44 are essentially the same. In each phase, the residue of statements of the indicated type are substituted into masks of in-line, object-time instructions. The filled-in masks are stored with their identifiers (Phase 32) at the next available locations in lower core.
Phase 45 – Continue. No object-time instructions are generated for these statements. Only the identifiers (Phase 30) are stored in lower core.
Phase 46 – Do. DO statements are analyzed for nesting. Illegal nesting is noted. The residue of each DO statement is substituted into an object-time mask; but in general, the exit address is left blank. The partially filled-in mask and its identifier are stored in lower core. An unconditional branch is generated (uniquely) to follow (via Phase 49) the last statement within the range of the DO.
Note: At thus point, the entire source program has been transformed into (essentially) object program procedure. For simplicity, we continue to write “statement” when we mean “procedure compiled from statement.”
Phase 47 – Resort I. An area is made available for a table to assist in resorting the statements into their original order.
Phase 48 – Resort II. The resort table is filled with the current location of each statement.
Phase 49 – Resort III. The statements are resorted back into their original order with the identifiers eliminated. The Table II entries (sequence numbers of statements originally labeled with statement numbers) are replaced by the current machine ad- dresses of those statements. Exit addresses are substituted into the procedure generated for DO statements (Phase 46). For each executable statement, the sequence number and the object-time starting address of the generated procedure are printed.
Phase 50 – Resort IV. The statements are shifted to the places they will occupy at object time. The Table II entries are bumped accordingly.
Phase 51 – Replace I. The entire object program procedure is scanned for indirect addresses (see note following Phase 31). Each indirect address is replaced by its direct address-now available in Table II.
Phase 52 – Function/Subroutine Loader. Relocatable function routines and subroutines (which comprise Phase 53) are selectively loaded. A table of starting addresses of these routines is created in free storage.
Phase 53 – Relocatable Package. This phase consists of the relocatable routines loaded by Phase 52.
Phase 54 – Format Loader. The object-time format routine, which is included in this phase, is loaded.
Phase 55 – Replace II. Those instructions in the generated object program that should branch to the relocatable routines are modified (via the table of Phase 52) to show the object-time addresses of these routines.
Phase 56 – Snapshot. A snapshot of the generated program is printed if initially requested and if no source program errors have been detected that would make program execution unrewarding.
Phases 57, 58, 59, 60 – Condensed Deck. When requested and if there are no input errors, these phases punch and list the object program as a self-loading condensed card deck.
Phase 61 — Geaux I. This phase prints the end-of-compilation message, initializes the sense lights, and prepares the branch into the object program coding.
Phase 62 – Geaux II. The arithmetic routine (Phase 63) is read into storage. Communication between this routine and the relocatable routines is established. The object program is executed on option.
Phase 63 – Arithmetic Package. This phase consists of the arithmetic routine loaded by Phase 62.
The First IBM Fotran Compiler is discussed on a more Technical -High End Scale Point:
The IBM FORTRAN Pre-Compiler is a program that detects and permits correction of errors in a FORTRAN source program before the object program is compiled. The Pre-Compiler detects many of the more common programming errors in individual source statements, and indicates possible logical errors in the source program as a whole. Two versions of the Pre-Compiler are provided, one for use with the IBM 1621 Paper Tape Reader and IBM Tape Punch, and the other for the IBM 1622 Card Read Punch.
A FORTRAN source program which is to be processed was to be punched in paper tape or cards, or may be entered directly from the typewriter.
The operation of the Pre-Compiler could be divided into two phases: Error Analysis and Final Program Summary. During the error analysis phase, each statement in the FORTRAN program is analyzed for an error. If an error is detected, an error code is typed, the statement containing the error is typed, and the program halts so that you can type the statement correctly.
During this phase, a new FORTRAN source program was punched in paper tape or cards. After all statements have been analyzed and corrected, if desired, a final program summary is typed. The final program summary phase includes information about possible sources of errors not detectable in individual source statements. An additional feature of the Pre-Compiler program, using the 1620 program switches, permits you to easily alter the functions of the error analysis phase for individual requirements. The following options are available.
The following were Instructional Sets based on the Original Fotran Complier:

1. You can suspend the halt and error correction routines, thereby providing a quick error analysis only. These routines can be suspended for the entire program or for individual error halts during normal processing.
2. You can enter the program through the console typewriter rather than by card or paper tape input.
3. You can eliminate punching of an edited source program.
4. You can have correct program statements typed, in addition to the normal operation in which only incorrect statements are typed. The standard 1620 FORTRAN Pre-Compiler system contains all of the functional subroutine names included in the standard FORTRAN system. If you make alterations to the functional names, or if you add additional subroutines to the FORTRAN system, you must make the corresponding alterations and additions to the PreCompiler system.
   Operation of the Pre-Compiler Program Error Codes 72 Before you process any program on the Pre-Compiler, you should be familiar with the nature of the errors that the program is deSigned to detect.
   During the error analysis phase of the program, each statement is analyzed for one or more specific errors. These errors consist of 51 of the most common errors usually found in FORTRAN source programs.
   As an aid in evaluating these errors, they have been grouped into seven categories: Arithmetic statements Arithmetic Statements Variables in Arithmetic
   Expressions DO Loops Constants Variables in arithmetic statements DO loops Constants Statement numbers Transfer statements General
   When an error is detected, an error code is typed on the console typewriter. This code consists of an alphabetic abbreviation of one of the categories listed above, followed by a number that designates the particular error in the category. ARITH
5. Unacceptable form to left of == sign.
6. Multiple == signs.
7. This code has been deleted.
8. Successive operation symbols, or a function which is followed by an operation symbol. 5. Missing operation symbol or operand.
9. Right parenthesis encountered before corresponding left parenthesis.
10. Missing right parenthesis.
11. Mixed mode expression (expression contains fixed and floating point).
12. No variable to the left of equal sign.
13. Involution of a fixed point variable or constant. VAR
14. Variable name longer than 5 alphameric characters.
15. Variable appearing in an expression or as a subscript not previously defined in an input statement; as the index of a DO loop; or defined as the left side of another arithmetic statement.
16. Variable written with a subscript has not been previously defined in a DIMENSION statement.
17. Variable previously defined in a DIMENSION statement has not been subscripted correctly: subscript is in unacceptable form, number of subscripts does not agree with the number specified in DIMENSION statement, numerical subscript is greater than maximum allowed by DIMENSION statement or is less than
18. DO 1. In the statement DO n i == m], m 2 , m,J, the indices m}, m 2 , and m.l , if given, are not all unsigned fixed point variables or constants greater than zero. There are more than 3 indices given.
19. The second index, m2 , is less than mJ, when botq are constants.
20. The third index, m.l , is signed, is zero, or is missing when specified as a constant.
21. The statement number n is not in acceptable form or is missing.
22. The variable name has either been omitted, or is incorrectly stated, or the DO statement is incorrect.
23. The statement specified as the end of an outer loop in a nest of DO’S has been found before an inner loop is complete.
24. A DO loop terminates with a transfer statement, GO TO, computed GO TO, or
    IF. CONST
25. Fixed point constant longer than 4 digits.
26. Floating point constant outside the allowable range.
27. Decimal point omitted from floating point constant that is written with a decimal exponent.

The FORTRAN Pre-Compiler Program
73 Statement Numbers Transfer Statements General
74

4. The decimal exponent following the E in a floating point constant is incorrectly expressed in form or size.
5. The exponent following an E has been omitted.
6. Floating point number followed by an alphabetic character other than E.
   STNO
7. Statement number longer than 4 digits.
8. Statement number has been previously defined.
9. Unnumbered CONTINUE statement. (Should be numbered when used as last statement in a DO loop.)
10. Statement immediately following a transfer statement is not numbered, and is therefore inaccessible to the source program. (If the previous statement is a transfer, the only way the program can process this statement is by a transfer to it, and therefore it must always be numbered.)

TRANS 1. Statement numbers in a transfer statement (GO TO, computed GO TO, or IF) are not acceptable fixed point numbers; there is no comma between statement numbers, or there is not the required number of statement numbers. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. 6. Comma missing after the right parenthesis in a computed GO TO statement. Index in a computed GO TO statement is not a fixed point variable, or is missing. Nonnumerical character follows right parenthesis in an IF statement. In an IF statement, a character other than a left parenthesis follows the word IF. No arithmetic statement within the parentheses after the IF. (However, empty parentheses in an arithmetic statement will not be detected.)

GEN Misspelled or unacceptable nonarithmetic statement. Statement contains an unacceptable character. More than 72 characters in statement (not applicable to cards). Symbol table full (occupies more than 2,500 digits in storage). Statement contains decimal point that is not in a floating point constant. Input/output statement contains no FORMAT number, or is incorrectly stated.

7. First character in an input/ouput list is not alphabetic, or the final character is not a letter or a digit.
8. In a DIMENSION statement, a nonalphabetic character precedes the first variable name or a dimension, or three dimensions have been specified ( only two-dimensional arrays are permitted).
9. A specified dimension is incorrect: a parenthesis has been omitted, a floating point constant or an unacceptable fixed point constant has been used, etc.
10. Unnumbered FORMAT statement.
11. Incomplete FORMAT statement: invalid or incorrect specification, missing parentheses, character after right parenthesis, etc.
12. In an input/output statement, comma is missing after the FORMAT statement number, or the list is missing or invalid.
13. The total record width specified in a FORMAT statement exceeds 87.
14. A variable in a DIMENSION statement has been previously defined.
15. a. The letter H orX is missingin an alphameric FORMAT statement or the width of an alphameric FORMAT statement is greater than
16. b. A FORMAT statement does not contain any of the specification types, I, H, X, E, or F. Error Analysis Phase Restart Procedure Final Program Summary After an error has been detected in a statement, and the appropriate error code has been typed, the original error statement is typed. If switch 3 is off, the carriage is returned and the program halts to wait for a corrected statement to be typed in. After reviewing the erroneous statement and the error code or codes indicated, you can, in most cases, make an immediate correction to the statement. Type the correct statement (followed by a record mark), then press the release and. start keys.
    The program resumes by analyzing the statement just typed to determine if any errors still exist. If the statement is correct, the program will begin analyzing the next statement in the FORTRAN program. In some cases, it may not be possible to re-enter a corrected statement without certain modifications because part of the statement has already been processed as a correct statement. For example, if an error is discovered in a transfer statement (GO TO), you must enter the correct statement with a statement number to avoid error STNO 4, or enter it twice without a statement number. (The program considers the first part of the GO TO to be correct, and requires that any statement following a transfer statement must contain a statement number). When a statement containing a statement number is partially processed due to an error, you cannot re-enter the statement with the statement number because an error STNO 2 will result. In an erroneous DIMENSION statement, for example DIMENSION C ( N ), the C is stored as a nonsubscripted variable and cannot be used later in the program as a subscripted variable. In case of C( 10,N), the C is stored as a one-dimensioned variable. Restart of the Pre-Compiler is necessary.
    For expressions involving involution (raising to a power), the exponent cannot have an involution operation. For example, A * * (B * * 2. +.1) will result in erroneous operation of the Pre-Compiler. This restriction also applies to the arithmetic expression in an IF statement. There is no check for the termination of a DO loop.
    If a dimension specification exceeds the capacity of the storage, erroneous results will follow. If an immediate correction cannot be made, you can resume testing of the next statement by manually branching to BEGIN (see RESTART PROCEDURES). It is important to note that if a new source program is being punched, bypassing the error correction routine will result in the incorrect statement being punched into the output tape or cards.
    The normal operation of the Pre-Compiler program is to type incorrect statements only. If you require a typed copy of all statements, turn on program switch
17. You may find it necessary during processing to interrupt the normal operation of the program. To allow such interruptions, the following re-entry points, given by symbolic label and storage location, are available: CLEAR location 01208: The symbol table and table of statement numbers referenced by DO statements are cleared. CLEAR is the restart point for a new program to be tested. INITL location 01340: The table of statement numbers referenced by DO statements is cleared
18. . BEGIN location 01472: No tables are cleared, but the program will continue to read source program statements. BEGIN is the normal entry point for restarting after a check stop or other interruptions of the Pre-Compiler. After the END statement in a source program has been processed by the PreCompiler program, a final program summary was a typewritter

ENTER SOURCE PROGRAM THEN PUSH START and the program will halt. Set the console program switches for the correct input I output options, mount the source tape or load the source deck, and begin processing by pressing the start key. After the END statement in a source program has been processed, the final program summary will be typed on the console typewriter. This will consist of the following four messages, together with the related lists of statement numbers and relocatable subroutines called by name in the source program.
UNDEFINED STATEMENT NUMBERS UNREFERENCED STATEMENT NUMBERS RELOCATABLE SUBROUTINES CALLED OBJECT PROGRAM DATA TABLE XXXXX STORAGE POSITIONS
The absence of one of the first three messages indicates that no undefined or unreferenced statement numbers have been found, or that no relocatable subroutines have been used by name in the source program. Undefined statement numbers are those referenced by a transfer, DO or Ilo statement, but not defined. After the final summary has been typed, the following message will be typed on the console typewriter and the program will halt.
PROCESSING COMPLETE Pressing the start key causes the program to clear the symbol table compiled during the processing of the previous source program and to prepare to process a new program. When this has been done, the program will type the message which calls for the entry of the source program.
The 1620 FORTRAN Pre-Compiler program deck was made up of four sections, identifiable by sequence number as follows: 00000-00001 Loading routine 00002-00361 Pre-Compiler program 00362-00367 Arithmetic tables 02001-02007 Relocatable subroutine data The relocatable subroutine data consists of a card containing the number of relocatable subroutines included in the program deck, and the following cards contain the names of these subroutines. These cards must be in the proper sequence.
If they are out of sequence, an error message will be typed and the 1620 will halt. Restore the sequence of these cards (including the two cards from the reader stacker), press the reader start and start keys to continue the operation. General Make-up of Program Tape Tape Data Duplicating the Pre-Compiler Tape The relocatable subroutine cards are punched with the function name starting in column 1 and the sequence number in columns 76 through 80. Subroutine names added to the system must be punched in the same manner.
The 1620 FORTRAN Pre-Compiler tape consisted of a loading routine which loads the multiply and add tables, and the program which follows. The last seven records are the relocatable subroutine data containing the number and names of the relocatable subroutines included in the program. These records must be exact duplicates of the corresponding records which are included in the 1620 FORTRAN processor tape. Additions to the list of relocatable subroutines in the system must be made to the Pre-Compiler tape in exactly the same form as prescribed for the 1620 FORTRAN processor tape. For the purpose of tape identification, a title and data message have been incorporated in the 1620 FORTRAN Pre-Compiler tape. The first two records of the tape contain the title and data information. After these records have been read into the 1620, the following message will be typed: 1620 FORTRAN PRECOMPILER 11/15/61 Normal processing continues after the message has been typed.
The FORTRAN Pre-Compiler tape was duplicated and/or modified by the use of the program for duplicating the FORTRAN processor and subroutine tapes, in the manner described for duplicating the processor tape.

References::

http://www.bitsavers.org/pdf/ibm/1620/C26-5619-4_1620_Fortran_Mar64.pdf

https://ibm-1401.info/1401-IBM-Systems-Journal-FORTRAN.html