vffl 
 
 m 
 
 m 
 
 mm 
 
 IBS 
 
 MH 
 
 ■ill 
 
 HlSi 
 
 BniliHinnnHDl 
 
 Wuhm 
 
LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 510. 8+ 
 
 IKS, 
 
 Kio. G6I-6G6 
 cop. Z 
 
CENTRAL CIRCULATION BOOKSTACKS 
 
 The person charging this material is re- 
 -ui„» f^r it<; renewal or its return to 
 tKbrar^ °rom which it was borrowed 
 on or belore the Latest Date stamped 
 Sow You may be bargee. «m.n,mum 
 fee of $75.00 for each lost book. 
 
 for dlKlpHnory attlon mnd may ■*»«•" 
 
 £ W^EW^U TELEPHONE CENTER, M3-8400 
 
 AUG 1 4 1996 
 
 AMR 8 1956 
 
 When renewing by Phone, write new due date bdow 
 previous due date. 
 
UIUCDCS-R-71+-66U 
 
 'Mm 
 
 ftlAyL^ 
 
 coo-2383-0010 
 
 The PLW Compiler 
 
 by 
 
 William Vanmelle and Lawrence Lopez 
 
 July, 197^ 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
 JHE LIBRARY OF THE 
 
 AUG- 
 
 nc tl 1 INOiS 
 
UIUCDCS-R-T 1 +-66U COO-2383-0010 
 
 The PLW Compiler 
 by 
 William Vanmelle and Lawrence Lopez 
 
 July, 19lh 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 
 UNIVERSITY OF ILLINOIS AT URBAN A -CHAMPAIGN 
 
 URBANA, ILLINOIS 6l801 
 
 * Supported in part by the Atomic Energy Commission under contract 
 US AEC AT(ll-l)2383. 
 
Digitized by the Internet Archive 
 
 in 2013 
 
 http://archive.org/details/plwcompiler664vanm 
 
TABLE OF CONTENTS 
 
 The PLW Language 1 
 
 Translating Into FORTRAN 7 
 
 Procedures 7 
 
 Allocation 8 
 
 Global Variables 9 
 
 Character Strings 10 
 
 SCAN 13 
 
 Operation of the SCAN Routine 15 
 
 Automatic Alignment of the Source Program 17 
 
 The Symbol Table 18 
 
 The Expression Analyzer 35 
 
 The Command Processor 59 
 
The PLW Language 
 
 PLW was designed to provide a systems programming language 
 to be used on many different computers. The language has greater 
 facility than. a simple language like FORTRAN, hut is nowhere near 
 the general monster PL/I. Our compiler achieves installation 
 independence by converting PLW source into FORTRAN, to be further 
 processed by the particular FORTRAN compiler in use at an installation. 
 Along the way, we get convenient linkage compatability with existing 
 FORTRAN modules . 
 
 The features of the language as described in this document 
 follow: 
 
 Identifiers- these consist of 1 to 31 characters, the first 
 
 of which is a letter and the remainder are letters, 
 digits, or the underscore character. 
 Constants- Integer and real constants are as in FORTRAN. A real 
 constant followed by the letter I denotes an 
 imaginary constant. Character string constants 
 consist of any string of zero or more characters 
 enclosed by single quotes, with internal quotes 
 represented by two consecutive quotes. The 
 logical constants are IB and OB, representing 
 TRUE and FALSE. The null pointer constant is the 
 word NULL. Constants and identifiers may not 
 extend over card boundaries . 
 
Program variables- these are identifiers defined in a 
 
 DECLARE or PROCEDURE statement. A 
 variable must be declared before it is 
 used in any way. The following attributes, 
 abbreviations and alternates may be used: 
 BINARY, BIN- numerical variables 
 FIXED, FIX, INTEGER- integer variables, i.e. 
 
 no fractional part 
 FLOAT, FLT- floating-point variables. A BINARY 
 variable is either FIXED or FLOAT, 
 and the following attributes all imply 
 FLOAT . 
 SINGLE, SGL.- single-precision (default) 
 DOUBLE, DBL, LONG- double precision 
 
 COMPLEX, CMP LX- complex( single-precision by default) 
 FLAG, LOGICAL, BOOLEAN- logical variables, which 
 
 may take on the values IB 
 or OB (true or false) 
 CHARACTER , CHAR- character string, This attribute 
 may be followed by a parenthesized 
 integer constant expression giving 
 the length of the string; otherwise 
 it has length 1. 
 VARYING, VARY- indicates the string has varying 
 
 length. Length given above is then 
 the maximum length . 
 POINTER, PTR- pointer variable, which is used to 
 qualify members of a DSECT. 
 
Variables of the above types may also be arrays, declared by giving 
 
 dimension information on the dimensions. Currently this is restricted 
 
 to upper bounds given by unsigned integers, e.g. DECLARE A(lO) FIXED, B(2,2,2) 
 
 FLOAT. 
 
 AREA- a block of storage used' to contain one 
 
 or more DSECT's. This attribute is followed 
 by a parenthesized constant giving the 
 number of words (an integer occupies one 
 word) in the area. 
 DSECT- describes a section of storage. Each copy 
 of a dsect is allocated in an area and 
 qualified by a pointer. The declaration 
 takes the form : 
 DECLARE name DSECT(<list of members, with 
 
 attributes > ) 
 BASED(<pointer name> ) IN(<area name>). 
 PROC- this names an external procedure. The 
 
 declaration also permits the specification 
 
 of parameter types and the type of value 
 
 returned by the procedure. The general 
 
 form of this declaration is 
 
 DECLARE name PROC [ (<model parmlist> ) ] 
 
 [RETURNS (<type>)] 
 
 The model parmlist consists of a series of 
 
 attributes, separated by commas, e.g. 
 
 PROC(FIXED BIN, FLOAT, CHAR, FLAG). 
 
 External names are limited to six characters, 
 
In addition, the language permits symbolic constants, which are identifiers 
 declared to have a given integer value. Whenever such an identifier 
 appears in the program, it is replaced by its integer value. An expression 
 containing only integer and symbolic constants is simplified to a single 
 integer at compile time. The declaration is DECLARE <name> CON STANT(< value > ) ; 
 where <value> is an expression involving only integers and previously 
 declared symbolic constants. Alternates to CONSTANT are CON and EQU. 
 
 Procedures- these are defined by the PROCEDUEE (PROC) statement 
 of the form 
 
 <name> : PROCEDURE [ (<parmlist> )] [ RETURNS (<type> )] ; 
 Internal procedures must appear before any reference to them. The 
 parameter list may supply attributes, or these may be given in a separate 
 DECLARE statement. 
 
 X: PROC (I FIXED, (A,B) FLOAT); 
 
 is equivalent to 
 
 X: PROC (I,A,B) ; 
 
 DECLARE I FIXED, A FLOAT, B FLOAT; 
 Nesting is permitted in PROCEDURE parmlists, DECLARE statements, and in 
 the list of elements for a DSECT. Further, the PROC statement can also 
 serve as a DECLARE statement simply by replacing the final semi-colon 
 with a comma and follow it with declaration, e.g. 
 
 X: PROC (A,B FIX) RETURNS (FIX) 
 ONE CON (1), (I,J,K) FIXED; 
 Following are the executable statements. DO and CASE may be preceded 
 by a label (identifier followed by colon); labels are otherwise ignored. 
 "Variable term" means simple variable or array name with subscripts, 
 which are any integer expressions; "clause" is a DO block or a single 
 
executable statement other than END. Optional operands are enclosed 
 in brackets. 
 Assignment statement: 
 
 <variable term> = <expression> ; 
 The expression is assigned to the variable or array element indicated. 
 Both must be of the same basic type (BINARY, FLAG, CHAR, etc.). 
 DO statement: 
 
 DO [<variable term> = <lower limit>[TO <upper limit>][BY <increment> ] 
 [WHILE <logical expression> ] ; 
 The control variable must be numeric. If the increment is omitted, it 
 is assumed to be 1. If the upper limit is omitted, it is the largest 
 integer. The range of the DO block is all statements up to the corresponding 
 END statement. The range is executed zero or more times until the control 
 variable exceeds the upper limit or the WHILE expression is false. If 
 neither operand is present, the range is executed once. The increment 
 must be positive or else a negative integer constant, in which case the 
 range is executed until the control variable falls below the upper limit . 
 The limits and increment are calculated once, before the loop begins. 
 The control variable should not be changed within the range. 
 CASE statement: 
 
 CASE <integer expression>; 
 <n object clauses> 
 [OTHER < alternate clause>] 
 END ; 
 
The case expression is evaluated, vith value i. If 1< i <n, then 
 the i object clause is executed. Otherwise, the alternate clause is 
 executed, if present. 
 IF statement: 
 
 IF < logical expression> THEN <then clause> 
 
 [ELSE <else clause> ] 
 The then clause is executed if the expression is true; otherwise the 
 else clause, if present, is executed. 
 END statement: 
 
 END [<label>]; 
 Ends the corresponding PROC, DO, or CASE block. If the label is present, 
 it must match the label on the block it closes. 
 EXIT statement: 
 
 EXIT [<label>]; 
 The label must appear on a DO or CASE statement. If omitted, the 
 innermost DO /CASE is assumed. This statement transfers control to 
 the statement following the END of the indicated block. 
 LOOP statement: 
 
 LOOP [<label>]; 
 The label must appear on a DO statement; if omitted the innermost 
 DO is assumed. The DO block must be one which loops, i.e. it must have a 
 control variable or WHILE operand-. The LOOP statement has the same effect 
 as encountering the END of the DO loop, i.e. the control variable is 
 incremented and tested and the WHILE expression is tested to determine 
 if the DO range is to be executed again. 
 CALL statement: 
 
 CALL <procedure>[ (<argument list>)]; 
 
Calls the indicated procedure. If the procedures parmlist is 
 
 known to the compiler, the arguments are checked for correct type and 
 
 number. 
 
 RETURN statement: 
 
 RETURN [<expression>] ; 
 Restores control to the calling procedure, returning the indicated value 
 if given. The value returned must be of the type (BINARY, CHAR, etc) 
 specified in the RETURNS attribute of the current procedure. 
 NOTE that there is no GOTO statement. This hopefully will result in 
 better-structured programs. It also makes life easier for the compiler. 
 Translating into FORTRAN 
 
 The compiler transforms PLW into FORTRAN in one pass through 
 the source. This requires some restrictions in the structure of the 
 program. Specifically, every variable must be declared before it is 
 used, and internal procedures must appear before they are referred to. 
 The former is a reasonable restriction anyway, and the latter is necessary 
 in order to handle allocation of global variables and provide 
 argument-list checking. 
 
 The FORTRAN used is a popular superset of ANS FORTRAN including 
 some mixed-mode expressions and generalized subscripts. These features 
 are available on most large computers these days. 
 Procedures 
 
 All procedures will become subroutines or functions, depending 
 on whether they declare a RETURNS attribute. This seems the best way 
 to take advantage of parameter and linkage facilities provided by 
 FORTRAN. Recursive procedures will not be permitted. In some cases, 
 
8 
 the pre-compiler will supply extra parameters (see "global variables" 
 below). In a group of nested procedures, the outer procedure, which 
 is to be externally known, will retain the name given by the programmer. 
 Internal procedures will be renamed by modifying the name of the outer 
 procedure, whose name will have to be unique to the first five characters 
 (implementation restriction). Thus there will be no conflict arising 
 from these internal, hidden procedures becoming externally known 
 FORTRAN modules. 
 Allocation 
 
 The only variables that must be dynamically allocated are 
 1. DSECT's and the AREA's in which they are contained and 2. locally- 
 declared arrays with object-time dimensions. All others are handled 
 quite readily within existing FORTRAN specifications. 
 
 All dynamic allocation takes place within the stack. The stack 
 is accessible by being declared as an array in blank common. The first 
 few entries are control information, such as the current stack pointer 
 and the limits of the stack, all expressed as indices in the stack array. 
 The actual stack may be allocated by the control program, perhaps by 
 a GETMAIN, but the indices computed will still be relative to COMMON. 
 
 DSECT's are essentially PKL based structures with only two 
 levels, which must be allocated in an AREA. The declaration is thus: 
 
 DCL <dsect name> DSECT (<list of members with attributes> ) 
 BASED (<pointer variable>) IN (<area variable>); 
 An AREA variable is represented in FORTRAN simply as an integer index 
 in the stack of the start of the area, such that if A is the area variable, 
 then STACK (A + l) is the first word of the area. A pointer variable 
 is similarly an index in the area, such that if P is a pointer variable, 
 the STACK ( A + P + l) is the first word of the DSECT described by A and P. 
 
To reference variables in a DSECT, we consider two cases: 
 1. scalars - for these, the stack has several aliases, one for each 
 date type, all EQUIVALENCE 'd to the stack. Then each scalar in a dsect 
 has a corresponding index I, an integer constant, in the DSECT, and 
 the scalar is referred to as < appropriate stack alias> (A + P + I), 
 (if the scalar has a different length than the stack, then A + P may he 
 (A + P)*2 or (A + P/2, etc.). 2 . arrays - in order that the FORTRAN 
 compiler can do all the worrying about subscript expressions, each array 
 in a DSECT is EQUIVALENCE' d to an appropriate element of the stack, and 
 the first subscript is modified by the area and pointer indices. For 
 example, if X(2,2,2) were declared as the first member of the DSECT 
 BASED (P) IN (A), then S(l,l,l) would be equivalent to the first element 
 of the stack, and X(J,K,L) would be referred to as X(A + P + J, K, L). 
 
 AREA's are readily allocated by the procedure in which they are 
 declared, by manipulation of the stack pointer. 
 
 Dynamic arrays are also allocated in the stack by manipulating 
 the stack pointer. But in order to permit them to be globally accessed 
 by internal procedures, and to retain some semblance of efficiency, these 
 arrays will be allocated by a short subroutine which then passes the array 
 as a parameter to the real subroutine, along with any dimension information 
 needed. (See accompanying table for summary of schemes). 
 Global Variables 
 
 Variables declared in one procedure and referenced by a 
 procedure internal to it are "global" and are treated specially. 
 1. Parameters that are globally referenced are passed as parameters to 
 each procedure which needs them. 2. Ordinary variables are placed in 
 

 labeled COMMON. 10 
 
 Character Strings 
 
 All character manipulation is done by calls to assembly- language 
 subroutines. Character string variables are declared in FORTRAN as 
 integer arrays whose first dimension is the number of words occupied 
 by one member and subsequent dimensions are those declared originally. 
 Each character string consists of one word of control information, 
 followed by the actual string. The control information inlcudes the length, 
 type, and if varying length, the current length. The information is such 
 that the null string is represented by the integer zero. Examples: (360 FOR 1 
 DCL C CHARACTER (12) becomes INTEGER C(U) 
 DCL D(5,^) CHAR(3) becomes INTEGER D(2,5, 1 +). 
 Character string constants are assigned a unique name and initialized by 
 the specification statement. For example, "STRING" might become 
 INTEGER SSOOOl(3)/6, "STRI" , "NG"/ . 
 
 Procedures which return character values are implemented as 
 subroutines with an extra parameter in which to return the function value. 
 
 Assignment statements translate almost directly, with possibly 
 additional CALL statements to handle character strings. The same is true 
 of the CALL statement. 
 
 The IF statement translates as follows: 
 
 IF <expr> THEN < clause 1> [ELSE < clause 2> ] ; 
 
 becomes 
 
 IF (.N0T.(<expr>)) GOTO < label 1 > 
 
 <Glause 1> 
 
 [GOTO <label 2> ] 
 
 <label 1> CONTINUE 
 
 [< clause 2> ] 
 
 [<label 2> CONTINUE 
 
 
11 
 
 A DO block with no operands simply has all the statements 
 in the range translated. If it has operands, then it becomes a FORTRAN 
 DO loop. If no control variable is given, then the DO statement has an 
 increment of zero (symbolic, of course). Otherwise, the lower/upper 
 limits, and increment are assigned to integer variables to be used 
 in the DO statement, unless they are positive integer constants, 
 in which case they may be used directly. The control variable is 
 created by the compiler for use in the DO statement, after which it 
 is assigned to the control variable specified in the source. This 
 easily takes care of control variables which are non-integer, in 
 COMMON, or subscripted. It also allows for two special cases: 
 (l) if the increment is a negative integer, then the upper and lower 
 limits in the DO statement are interchanged and the control variable 
 assignment is <user control variable> = <lower limit> + <upper limit > ■ 
 <FORTRAN control variable> (2) the lower and upper limits are integer 
 constants, but the lower limit is not positive, in which case the limits 
 are adjusted to fit in the DO statement, and a correction is made in 
 the control variable assignment. 
 
 If a WHILE expression is present, it appears after the DO 
 statement as 
 
 IF ( .NOT.(<while expr> ) ) GOTO exit label 
 A CASE block is translated by means of a computed GOTO. Each clause 
 is given a statement number and followed by a GOTO exit label. The 
 very first statement is a GOTO the computed GOTO statement, which is 
 output only after we know what all the case labels are. Thus the 
 
12 
 
 general form is 
 
 <case variable> = <case expression> 
 GOTO < label 1> 
 
 <object clauses, preceeded by labels, followed by GOTO < label 2>> 
 < label 1> GOTO (< labels generated above> ) , <case variable> 
 
 <alternate clause, if present> 
 <label 2> CONTINUE 
 
 On the 360, the computed GOTO falls through if it fails. On 
 other machines, extra IF statements may be needed. 
 
 The EXIT statement translates simply as a GOTO the exit label 
 (following the end of the block). The LOOP statement is a GOTO the 
 last statement in the DO loop. 
 
 The hETURN statement translates as a GOTO the return sequence. 
 If a value is returned, the GOTO is preceeded by assigning the return 
 value to the procedure name or to the special return parameter in 
 the case of character procedures. Depending on the needs of the 
 procedure, the return sequence may simply be the statement RETURN, 
 or it may involve de-allocation as well. 
 CONSTRUCTION OF THE FORTRAN PROGRAM 
 
 The routine STORK handles the FORTRAN output. Each statement 
 generated is sent to STORK, which makes it the next statement in the 
 current procedure. When a new procedure is entered, STORK stacks the 
 old and starts constructing a new FORTRAN subroutine. At the end of 
 a procedure we know all the variables that must be declared for it, as 
 well as where they go (e.g. in COMMON or appended to the parameter list), 
 
13 
 
 so at this point we generate a FUNCTION or SUBROUTINE statement, followed 
 by all the declarations needed. STORK puts this whole group of 
 statements in front of the existing FORTRAN output for the procedure, 
 and when "end of declarations" is signaled, it writes the whole 
 procedure on the file which will he given to the FORTRAN compiler, 
 and returns to processing the previous procedure. 
 SCAN 
 
 Input of the source deck occurs exclusively through this 
 routine. It reads cards as necessary, produces the source listing, with 
 any print control specified, scans over comments, detects invalid 
 characters, and performs some limited manipulations of the actual 
 operands in the source. This routine also has entry points to handle 
 error messages and to flush the remainder of a source statement, if 
 desired, when an error is detected. 
 
 Parameters for SCAN are all located in the COMMON dsect. 
 SCANPTR is the address on the current source card of the input scan 
 pointer. On a call to SCAN, the source is scanned, starting at the 
 column after the location given hy SCANPTR, for an operand. This may 
 he one of the following, none of which is permitted to overlap card 
 boundaries: 
 
 (l) an identifier name, which is an alphanumeric string, 
 starting with an alphabetic character, not to exceed 
 31 characters. If longer, it is truncated to 31, with 
 a suitable error message given. Identifier names can 
 serve as command keywords, variable names, or statement 
 labels. The name is place at NAME, right -padded with 
 
Ill 
 
 blanks to 31 characters, with length at NAMLEN. NAMTYPE 
 is set to zero. 
 
 (2) A decimal constant, which may be (a) an integer, in which 
 case the binary value is stored at NAMVALUE; and 
 NAMFLAG is clear; (b) floating point constant, which 
 contains either a decimal point or an exponent of the 
 form Enn or Dnn, the latter indicating double-precision 
 and setting the DOUBLE bit in NAMFLAG; the FLOAT bit 
 
 is set in NAMFLAG; (c) an imaginary constant, which is a 
 floating point constant followed by the letter I; in 
 addition to the appropriate floating bits set, the 
 COMPLEX bit is set, and the constant is converted to 
 FORTRAN format, i.e. (0, constant). In all of the 
 above cases, NAMTYPE is STBIN, and the constant appears 
 at NAMLEN, NAME. 
 
 (3) A flag (logical) constant, either IB or OB, which are 
 converted to .TRUE, and .FALSE., respectively, at NAME. 
 NAM.TYPE is STFLAG. 
 
 (k) A character string, enclosed in quotes. Any character 
 is valid within the string, and a quote is coded as two 
 consecutive quotes. In moving the string to NAMLEN, 
 NAME, a count is kept of the actual number of characters 
 in the string, which is stored at NAMVALUE. NAMTYPE is 
 STCHAR. 
 
 (5) The null pointer constant, NULL. NAMTYPE is STPOINT, 
 and -1, the Fortran equivalent, is at NAME. 
 
15 
 
 (6) None of the above, in which case NAMTYPE is X'FF' and 
 
 NAMLEN is zero. 
 
 The delimiter following the operand is placed at NAMCHAR. 
 Blanks are not considered delimiters and are ignored unless serving 
 to separate operands. SCANPTR points to the delimiter on exit. 
 
 There is an alternate entry point SCANDELM which is used if 
 no operand is desired, and just a delimiter is returned. If there is 
 an operand, the blank before it, if any, is the delimiter. 
 Operation of the Scan Routine 
 
 Input for SCAN is handled by NEWCARD, which is called whenever 
 the scan pointer reaches the end of the current card. It prints the 
 current card, then any error messages that have accumulated for that 
 card. Error messages are generated by calls to ERROR, which stores the 
 message and marks in a separate buffer the position of the scan pointer 
 at the time. A new card is then read, and a blank is placed in column 73 
 to serve as a delimiter, since we do not permit individual operands to 
 run over a card boundary. Finally, the scan pointer is set at the 
 blank preceding column 1. 
 
 SCAN looks for the first non -blank character, starting at the 
 location given by SCANPTR. If this causes a scan over the end of the 
 card, NEWCARD is called and the step repeated. The non-blank character 
 directs what happens next. If it is a possible first character for an 
 operand, control transfers to the appropriate handler. If it is the 
 comment character (%), the closing comment character or the end of the 
 card, whichever comes first, is sought, and then the scan is repeated. 
 
16 
 If it is an invalid character, an error is signaled. Anything else 
 is considered a delimiter and we exit with no operand. 
 
 After the appropriate routine has processed the operand, the 
 scan pointer is updated to just beyond the operand. Then the above 
 scan is repeated to find the delimmter, with the exception that if the 
 next thing is a possible operand, the preceding blank is taken as 
 the delimiter. Entry at SCANDELM performs only this second scan. 
 
 The routines to handle the various operands are fairly 
 straightforward, moving the operand to NAME while checking for special 
 cases . 
 
 (1) Name scanner. Looks for the first non -alphanumeric 
 character to signal the end of the name, then sets 
 NAMLEN to the length. If that length exceeds 31, it is 
 set to 31. If the final result is the string NULL, then 
 suddenly we switch NAMTYPE to STPOINT and NAME to -1. 
 
 (2) Character string. The string is moved character by character 
 until another quote is found. If this is followed by 
 
 a second quote, the moving continues, but the two quotes 
 are counted as one character for the final count, which 
 is stored at NAMVALUE. 
 
 (3) Number. Tentatively set NAMTYPE to STBIN and clear 
 NAMFLAG. Move numbers until we run into something else. 
 
 A decimal point sets the float bit. If the bit is already 
 
 on, we have an error. 'D' or ! E' also set the bit, and 
 
 'D' sets the double bit, but these also set another flag to 
 
17 
 
 make sure that two such exponents do not occur. At 
 the end of the constant, 'B' makes us check for IB 
 or OB, which result in placing .TRUE, or .FALSE, at 
 NAME and changing NAMTYPE to STFLAG. 'I' requires that 
 the constant be preceded by '(0.0,' and followed by') 1 
 at NAME. If only decimal digits are found, the constant 
 is an integer and is converted to binary, for the benefit 
 of the many callers which are interested in an integer 
 value . 
 AUTOMATIC ALIGNMENT OF THE SOURCE PROGRAM 
 
 As each card of the PLW source is read and printed, it is 
 modified to make the source easier to read. This consists of indenting 
 to read. This consists of indenting the source (starting at the first 
 non-blank character) the distance indicated by the current level of nesting, 
 and, if the line starts with a label, moving the label out to the 
 left-hand margin. The buffer we use for the purpose has the following format: 
 
 +0 
 
 +5 
 
 +11 +15 
 
 +23 
 
 +53 
 
 +125 +133 
 
 
 stmt# 
 
 
 label, if any 
 
 space for shifting 
 
 read card in here 
 
 seq# 
 
 The card is read in on the far right. We scan over blanks to find the 
 
 first character. If a letter, then we see if it is a label by scanning for 
 
 the end of the name and looking for a colon. If found, then the name 
 
 and colon are shifted to +15, and the original label is blanked out. Then 
 
 in any case we use the current level # to compute a "tab setting", not 
 
 to precede the end of the label. We shift the card, starting at the first 
 
18 
 
 non-blank, ignoring the label, through column 72, to the tab setting, 
 and follow the new column 72 with blanks to the old column 72. The 
 sequence information in columns 73-80 remains fixed at the far right. 
 Also during this process we note that current stmt number, and if 
 different from the one printed on the preceding line, we save it. If 
 it is the same, then this is a continuation card, which we indent 
 an extra space. And in the process of checking the first non-blank 
 characters, we can easily check to see if the line is a comment, in which 
 case we scan over it before returning to the caller. 
 THE SYMBOL TABLE 
 
 Stored in the symbol table are all identifiers appearing in 
 DECLARE and PROCEDURE statements, as well as labels, undeclared 
 procedure names , and anything else that turns up that needs to be 
 saved. Each procedure has its own symbol table, headed by a symbol 
 table control block (STCB). The STCB has pointers to the root of the 
 table, to the STCB global to this (to enable us to search for global 
 references), to the STCB next created (thus linking all the tables 
 together for cross-reference time), and to the procedure entry which 
 is responsible for this STCB (defined in the procedure immediately 
 global to this ) . 
 
 Each table takes the form of a height -balanced binary 
 tree. Such trees are reasonably balanced, as well as being easy to 
 maintain. The entries in the table contain fields for the name, type, 
 flags, assigned FORTRAN name, pointers to a reference list, subscript 
 
19 
 list, parameter list, and/or whatever else is appropriate for the entry. 
 The procedure IENTER is responsible for creating new entries in the 
 ;able and maintaining its balance. The algorithm it uses is taken from 
 "Notes on Balanced Binary Search Trees", CS 310, Fall, 1972. Professor 
 teingold. The entries in the table can be of varying length, with 
 just the name, type, and link fields common to all. IENTER uses the 
 >ize given by the global variable LEASE. NEXT always points to free 
 space; LAST points to the end of it. 
 
 The procedure START initializes the symbol table to empty and 
 creates the attribute table. This table has the same form as a 
 symbol table; hence, it can be built and searched by the same routines. 
 The attribute table has an entry for each attribute that may be used in 
 a DECLARE. The type word gives the attribute number, implied type, 
 and auxiliary function (e.g. CHAR may be followed by a length; the 
 function number specifies this). ALL names which identify the same 
 attribute have the same type word, of course (e.g. FIX, FIXED, INTEGER). 
 The attribute table is built by calling IENTER for each attribute name. 
 Finally, a null "outer block" table is created. This table will contain 
 only the name of the outer procedure . 
 
 The procedure LOOK is used to search a table for a given 
 name, located at NAME (which is also where SCAN puts names. ) It does 
 a simple binary search, comparing names at each node on the way until 
 a match is found, in which case the entry pointer is returned, or the 
 path ends, in which case a null pointer (zero) is returned. 
 
 The reference list for an entry is built by the procedure 
 REF. Each call to REF appends the current stmt# to the linked list, 
 
20 
 whose first and last entries are pointed to by the entry. 
 
 The group of routines SYMUTIL provide miscellaneous facilities 
 for the symbol table routines, such as setting and testing flags, 
 binary-to-EBCDIC conversion, etc. 
 A. THE DECLARE/PROCEDURE PROCESSOR 
 
 These statements are handled by DCL, ATR, ATRCHK, CHECK, INTEXP, 
 STNAME, STDEFT, and STJUNK. 
 STJUNK 
 
 To process a PROCEDURE statement, STJUNK (l) is called. 
 The procedure name is assumed to be in NAME. The name is entered in 
 the currently active symbol table, and if it is an internal procedure, 
 a FORTRAN name is generated for it . The names are generated from the 
 outer procedure name to make sure they are unique, since the FORTRAN 
 subroutines we generate will have externally-known names. For example, 
 ii? the outer procedure name is JUNK, then internal procedures will be 
 assigned names JUNK00, JUNK01, JUNK02 , ..., JUNKOZ, JUNK010 , . . . 
 Next we create a new STCB, link it to the old, and save in it a 
 pointer to the procedure entry. Then, since the rest of the PROCEDURE 
 statement looks a lot like a DECLARE statement, we call DCL(l). 
 DCL - 
 
 DECLARE statements are handled by calling DCL(O). DCL(l) differs in 
 that we check for a parameter list and RETURNS attribute. 
 
 We scan off groups of declarations of the form 
 identifier [ (<subscripts> ) ] <attributes> 
 In addition, <identifier> may itself be a list of declarations separated 
 
21 
 
 by commas and enclosed in parentheses. For example, we might have 
 
 (X, Y COMPLEX) DOUBLE 
 or ( A (10) VARY, B) (2) CHARACTER. 
 
 DCL keeps track of the identifiers, and calls on ATR to apply the 
 attributes to them. To this end, we keep a list of identifiers 
 encountered (actually pointers to identifier entries) in the array 
 IDS. When a left parenthesis is encountered, we note in the stack 
 LPS the index of the next space in IDS, which will be the start of 
 the list of identifiers within parentheses. When a right parenthesis 
 is encountered, we pop the top index from LPS. Whenever we syntactically 
 expect attributes, i.e. after processing an identifier or right parenthesis 
 we call ATR, passing the list IDS and the indices of the first and last 
 elements in the list to which the attributes apply (maybe only one 
 element). When we return from ATR, the input delimiter should be comma, 
 right- parenthes is , or semi-colon. 
 
 On reaching an unparenthesized comma, all attributes 
 applying to the identifiers in IDS have been processed, so for each 
 one we call CHECK to finish each off, and then clear out IDS (by 
 resetting TID to 0). 
 
 There are two special types of parenthesized lists: 
 parameter lists and DSECT lists. These correspond to the states 
 IKALL = 1 and IKALL = 2, respectively. IKALL is initially set to the 
 parameter of DCL, or 1. When IKALL = 1, each identifier encountered 
 is marked as a parameter and is linked into the parameter list for the 
 
22 
 
 procedure (the proc entry points to the first parameter). IKALL = 2 
 
 when ATR discovers the attribute DSECT, followed by "l". The opening 
 
 parenthesis is still handled in the usual fashion (stack TID + 1 on LPS) 
 
 Every identifier encountered while IKALL = 2 is marked "qualified" 
 
 and is linked to the dsect entry. In addition, all dsect members 
 
 are linked together in a manner similar to that of a parameter list. 
 
 Finally, when IKALL and the parenthesis which closes the list is 
 
 found, we do not call ATR on the whole list, but rather purge it by 
 
 calling CHECK for each element, and then return to the previous state, 
 
 in which we look for RETURNS attribute for PROC or continue processing 
 
 attributes for the dsect name (i.e. the BASED and IN attributes). 
 
 When IKALL = 2 there is yet another special case. At any 
 
 point in the list of dsect elements, instead of an identifier, one 
 
 may write ORG name , which indicates that identifiers which follow 
 
 start at the same location as name , which also must be an element 
 
 of the dsect. No sharing of storage is implied. This is merely a 
 
 convenient way of describing a dsect with, say, a variable data section 
 
 following a common header. ORG without an operand causes the following 
 
 elements to appear after the last displacement already used. DCL 
 
 checks for ORG whenever it scans an identifier with IKALL = 2. Upon 
 finding one, it creates an "ORG" entry which is linked into the dsect 
 
 list. If an operand follows, it looks it up, checks to make sure 
 it is an element of the same dsect (its QUAL field should point at the 
 dsect entry), then point the ORG entry at it. If no operand, then 
 a null pointer is stored. Later on, CHECK will use the ORG entries 
 
23 
 
 in assigning displacements. 
 ATR 
 
 This procedure is passed a list of zero or more identifiers, 
 to which it applies any attributes in the input. The case of no 
 identifiers, or an identifier is null, it occurs because DCL may find 
 errors, e.g. a duplicate identifier, and wants to process attributes 
 but not apply them to any identifier. 
 
 Before any attribute names there may be a subscript list. 
 This is taken care of by scanning for numbers and commas until the 
 closing right paren. Each number scanned is saved until all have been 
 scanned. Then for each identifier in the passed list, we search for 
 the end of its subscript list — the identifier may already have subscripts 
 since these can be nested — and append each subscript scanned. Finally, 
 the ARRAY bit is set in the flag of the entry. 
 
 The only other thing ATR looks for is attribute names. 
 When we scan a name, we look it up on the attribute table and get 
 its type word. The type word has a function byte which indicates 
 anything special about the attribute. If there is, we take care of it 
 (see below). Then for each identifier in the passed list, we call 
 ATRCHK to apply the attribute and check for conflicts. Here is what 
 is done for special attributes: 
 
 AREA and CHARACTER may be followed by a length in parentheses. 
 So if the attribute name is delimited by "(", we call INTEXP to get 
 value in parentheses. If no "(", then we use a default value. 
 
2k 
 
 CONSTANT is similar to CHARACTER, except there is no default 
 
 value. 
 
 DSECT - this attribute must be followed by "(", and we 
 return to DCL with iKALL = 2 so the dsect list may be processed. 
 
 IN, BASED must be followed by an area or pointer variable, 
 respectively (parentheses optional). We scan off the name, enter it in 
 the active symbol table, and set its type. If the name already exists 
 in the table, we check to see it is the right type. We also set the 
 SPEC bit to permit it to appear in a subsequent declaration. 
 
 RETURNS must be followed by one or more attributes. To 
 process those attributes, we make a dummy entry, initially blank, and call 
 ATRCHK using that entry for each of those attributes. After that list, 
 we store the type word of the dummy entry in the appropriate field of 
 the identifier entry to which the RETURNS applies. 
 
 PROC may be followed by a model parameter list. This is the 
 case if PROC is delimited by "(". The model parameters have no names, 
 just attributes, e.g. PROC (FIX, FLT DOUBLE, FLAG). Each model parameter 
 is a small entry in the symbol table having only a type word and link 
 field. All the model parameters are linked together and the proc entry 
 points to the first one. While processing model parameters we are in 
 the state JKALL = 3- While processing returns attributes, we are in the 
 state JKALL = IKALL + k . 
 ATRCHK 
 
 This procedure is passed an identifier entry, an implied 
 type, function, and attribute number (the last three taken from the 
 
25 
 attribute type-word). It assigns the given type to the identifier, 
 
 checking to see that the type has not been set to something different that 
 
 is all done by function on MUSTBE. The flag for a BINARY identifier 
 
 has 3 bits FLOAT, DOUBLE, and COMPLES and 3 bits denoting their complements. 
 
 All attributes which imply FLOAT BINARY are checked as a unit — type 
 
 must be binary, FIXED bit ( FLOAT) must be off, and then the float bit 
 
 is set. Attributes SINGLE, DOUBLE, REAL, COMPLEX, and FIXED all set 
 
 one bit and check that the complementary bit is off. This prevents 
 
 declarations such as DCL X SINGLE DOUBLE; attributes CONSTANT, AREA, 
 
 AND CHARACTER set a length or value field; VARY sets a bit; PROC : sets 
 
 the EXTRN bit; BASED and IN set a pointer to the indicated variable 
 
 in the entry. And several attributes are not permitted to appear in a 
 
 parmlist, dsectlist, and/or RETURNS attribute, so these are also checked 
 
 for. Any conflict results in an error message. 
 
 CHECK 
 
 Each identifier in a declaration eventually is passed to 
 
 CHECK, which performs last-minute checks on it, and any other details 
 
 to take care of after all attributes are known. It generates the first 
 
 reference for the ID, and clears the SPEC bit, in case this was a 
 
 second declaration of, say, a pointer variable that previously appeared 
 
 with a BASED attribute. If the type is still unknown and the identifier 
 
 is not a parameter, the type is set by default (FORTRAN conventions: 
 
 A - H, Q - Z is FLOAT BINARY; I - N is FIXED BINARY). This is usually 
 
 the case when a variable is declared without attributes, e.g. DCL X; 
 
 In any case, if the type is known, STNAME can assign a FORTRAN name to 
 
26 
 
 the ID. We check for invalid arrays, e.g. DCL F (10) PROC; is invalid. 
 
 If the ID was given an INIT value, we check to see that the value is 
 
 of the right type. And finally, if the type was DSECT, then we chain 
 
 through its list of members, assigning displacements to each. We 
 
 keep a "location counter" LEW, initially zero. For each member of the 
 
 list, we find its elementary length— 1 for FIXED BIN, 2 for FLOAT DBL, 
 
 k for DBL COMPLEX, etc — and align LEW accordingly. If the member is 
 
 CHAK(n) then we take elementary length [(n + 7)A] (IBM 360 ) , but 
 
 align just on fullword (length l). Then if the member is an array, 
 
 we multiply the length by each dimension to get the total length it 
 
 occupies. The aligned LEN gives displacement of this member; then LEN 
 
 is increased by the members total length. If an ORG entry is encountered, 
 
 we save the current value of LEN and reset it to the displacement given 
 
 in the operand of the ORG entry. That displacement must, of course, 
 
 be adjusted by the length of the operand, since we assign displacements 
 
 in terms of the item's length, e.g. we choose the displacement for 
 
 a FLOAT DOUBLE variable for use as a subscript in a double-word array. 
 
 If we encounter an ORG entry without operand, we reset LEN to the greater 
 
 of LEN and the saved value of LEN, i.e. the largest displacement not 
 
 used yet. 
 
 STNAME 
 
 This routine assigns a name to the identifier it is passed. 
 The names are of the form X$n , where X is a letter chosen according to 
 the identifier type, and n is 1 to k decimal digits (unique for each 
 name). There are 6 X's, one each for FIXED BIN, (also AREA, PTR, and 
 
27 
 
 CHARACTER), FLAG, FLOAT DOUBLE, SINGLE, COMPLEX DOUBLE, and COMPLEX 
 SINGLE. The reason the names are so chosen is to reduce the number 
 of FORTRAN declarations needed. In the process of figuring out which 
 kind of name to assign, STNAME figures out which common array the variable 
 wculd be referred to in if it were in a DSECT. That array is actually 
 X$, where X is the same as in the name assigned. The array code (l to 6) 
 is stored in the entry in case it is needed later. 
 B. RESOLVING REFERENCES 
 
 ISCOPE 
 
 This routine is used to look up a variable that may be either 
 locally or globally defined. Assuming the variable is found, ISCOPE 
 calls on REF to generate a reference, and if the type of the variable 
 is unknown, it calls on STDEFT to set the default type. At this point, 
 if the variable is local (in the active symbol table), we just return 
 the pointer to the variable entry. Otherwise we enter a local alias — 
 a short entry of the same name with type ALIAS and a pointer to the 
 original entry. The entry serves two purposes: (l) it shortens the 
 search time if we look up this variable again in this procedure; and 
 (2) it lets us know that the variable was used in this procedure, in 
 case any FORTRAN declarations are needed for it. Finally, all variables 
 of type BINARY, CHAR, FLAG, PTR, AREA, i.e. all types which translate 
 as FORTRAN variables, unless they appear in a dsect, must be made globally 
 accessible. Dsect elements are automatically so, and CONSTANT'S 
 translate as integer constants. There are two allocation schemes, 
 depending on whether the variable is a parameter or not. Non -parameters 
 are allocated in labeled COMMON, by linking the entry into the common 
 
28 
 
 list and setting a common bit in the flag. If the entry has already- 
 been allocated there (if the common bit is already on), then we need 
 do nothing further. Parameters obviously cannot be in COMMON, so the 
 solution is to make them extra parameters for each procedure from the 
 current one up to, but not including the procedure (symbol table) 
 where we found the entry in the first place. The extra parms list 
 is a linked list of pointers to parameter entries attached to the proc 
 entry. Note that even if the entry we found in the search was itself 
 an alias, we only need to add to parameter lists that far, since from 
 that procedure up we have already done so. 
 C. FORTRAN DECLARATIONS 
 
 FORTRAN declarations are generated by the routines RDCL, 
 COMOUT, FDINIT, and BLKDAT. 
 FDCL 
 
 This routine is called when the END statement of a procedure 
 is processed, and is in charge of generating a FUNCTION/ SUBROUTINE 
 statement followed by all declarations needed for the procedure. 
 
 After signalling STORK that we are starting declarations, 
 we construct FUNCTION or SUBROUTINE; the former if the procedure returns 
 a value other than CHARACTER, otherwise the latter. This is followed 
 by the name of the procedure (the assigned name unless it is the outer 
 name). The name is followed by the parameter list. The list is formed 
 by first chaining through the declared parameter list, pointed to 
 by the SPLINK field of the proc entry, adding on the name of the 
 parameter and a comma. While doing this, we have to check for any 
 
29 
 parameters that have unknown type (they would be undeclared and un- 
 referenced) and call STDEFT to give them a type and name. Next we 
 go through the list of extra parameters in a similar fashion, except 
 that none of these can have unknown type or they wouldn't be there in 
 the first place. Finally, if the procedure returns CHARACTER, we supply 
 an extra parameter to return it in. 
 
 Next comes an IMPLICIT statement. This doesn't really simplify 
 FDCL any; in fact, it is a slight complication. But it greatly 
 reduces the number of declarations we need to output, by eliminating 
 declarations for those varibles which are adequatley declared implictly 
 by the first character of the assigned name. 
 
 Every variable used in the procedure is in this symbol table, 
 either as an original entry or as an alias. So now we traverse the 
 symbol table and decide what sort of declaration, if any, each entry 
 calls for. Simple, unsubscripted variables of type other than CHARACTER 
 need no declaration, since the IMPLICIT statement takes care of them. 
 If it is a symbolic constant, it ovbiously needs none, since the 
 FORTRAN compiler sees only an integer. If the variable is an array, we 
 need to generate a statement <type> <name> (<dimension info>). 
 Such a statement is needed also for character strings, since they 
 are represented as INTEGER arrays. They also need to have at least their 
 first elements (length word) initialized. An array in a dsect needs 
 additionally to be EQUIVALENCE ' d to the appropriate stack array 
 (l$, A$, etc.). Scalars in dsects need no declaration, but we do need 
 to note which stack array they use so that we can declare any stack arrays 
 
30 
 we need. String constants need an array declaration and initialization. 
 And, of course, any variable declared with an INIT attribute needs 
 initialization. Procedures, if they return a value (other than 
 CHARACTER), must also be declared with their type, e.g. EXTERNAL FUNC1 
 and INTEGER FUN CI if procedure FUNC1 returns FIXED BIN. 
 
 Generating DATA initialization statements is the task of 
 FDINIT. FDCL just has to know when to call it. We call it for anything 
 described above as needing initialization unless (l) the variable is 
 global to this routine i.e. appears here as an alias, since the 
 initialization must occur where the variable was declared; (2) it is 
 a parameter, since they are never initialized (this problem only 
 occurs with CHAR varibles , since explicit INIT attributes for parameters 
 are rejected by the DCL processor); (3) it is in a dsect , since nothing 
 exists there until it is allocated (again this problem only concerns 
 CHAR variables); or (h) the variable is allocated in COMMON, since 
 such initialization may only be done in a BLOCK DATA subprogram. 
 
 After all programmer variables have been declared, we know 
 which stack arrays, if any (only if dsect members '-ere used), are 
 referenced, so we now generate declarations for those, EQUIVALENCE' d to 
 blank COMMON. 
 
 Next comes a labeled COMMON statement, if any gloLals were 
 allocated there, generated by C0M0UT. Since there may be variables 
 in COMMON not used, and hence not declared, by this procedure, C0M0UT 
 needs to know which variables in COMMON are already known. This is 
 accomplished by clearing the COM bit for each entry processed in this 
 
31 
 symbol table. COMOUT can test the bit and then restore it. 
 
 Next come declarations for any string temporaries used by 
 EXPR. This is done by calling DCLTMP. 
 
 Finally, there may be DATA statements for special variables. 
 In particular, the DO processor likes to have variables initialized to 
 zero and the largest integer available. Now all done with declarations, 
 we tell STORK about it, which then wraps up all the FORTRAN code for 
 this procedure and writes it out for the FORTRAN compiler. 
 FDINIT 
 
 This routine is passed an identifier needing initialization 
 and it generates a DATA statement. There are basically two cases 
 to consider: the easy case, and character strings. 
 
 For BINARY and FLAG variables , we just generate 
 DATA <assigned name> / <init string>/ 
 where init string is simply the initialization value copied from the 
 DECLARE statement and stored with the entry by the declare processor. 
 For FLAG variables, the value is stored as T or F. 
 
 Character variables and constants are somewhat more complicated. 
 They are integer arrays, whose first element gives length information. 
 The bottom half gives the fixed or maximum length, while the top half 
 has the current length or -1 if fixed length. The initialization string 
 is present for character variables with INIT attributes, and for string 
 constants appear in the symbol table. The string must be broken into 
 groups of four characters each, where two consecutive quotes count as 
 one character. While doing this we count the characters used. 
 
32 
 
 i if it was a character variable of fixed length we can pad out 
 the right side with blanks, if needed and if it was varying length 
 we know the "current length" for initializing the length word. Thus 
 the last thing done in a character initialization is filling in the 
 length word. 
 COMOUT 
 
 This routine generates the labeled COMMON statement. All 
 variables in COMMON are linked together in order of allocation, 
 so all we have to do is go through the list and take the name of 
 each variable. There is a slight complication in that variables that 
 have more than one element, i.e. character variables and arrays, must 
 either be previously declared or must appear in the COMMON statement 
 with dimension information, but not both . The problem is taken care 
 of by having the routine that declares a variable (FDCL) turn off 
 the common bit in the entry. Then any variables with common bit 
 on and needing dimension information can be handled by COMOUT, by 
 looking at character length and/ or subscript information. Of course, 
 we turn the common bits back on when finished. The label of COMMON 
 is generated like inner procedure names, by modifying the outer 
 procedure name . 
 BLKMT 
 
 Tnis routine is called at the end of the outer procedure to 
 generate a BLOCK DATA subprogram if anything was allocated in COMMON. 
 It calls on COMOUT, then FDINIT for each entry in COMMON that requires 
 initialization. 
 
33 
 
 D. THE CROSS-REFERENCE TABLE 
 
 This is handled by XREF, which, after writing a suitable 
 title, chains through all the STCB's in order of their creation and 
 calls XPRINT for each of them. Thus the symbol table for the outer 
 procedure comes first, then for inner procedures. The symbol table 
 for any given procedure is preceded by all symbol tables global to it. 
 
 XPRINT first prints a heading containing the name of the 
 procedure whose symbol table we are now doing. Then it traverses the 
 symbol table in preorder (alphabetical order), calling on YPRINT to 
 write cross-reference information for each entry. 
 
 YPRINT writes lines of the form 
 
 stmt# name attribute (s) references 
 
 where the name, of course, is the original name. The statement number 
 where the name was originally defined is the first number in the 
 "reference list"; the remainder of the list is printed as references. 
 The attribute (s) come from examining the type and flag of the entry. 
 The first attribute corresponds to the type. Others may follow 
 according to bits set in the flag, e.g. we might have CHARACTER VARYING 
 or BINARY FLOAT DOUBLE COMPLEX. We give all applicable attributes, 
 even though the actual declaration may have been COMPLEX DBL. If the 
 type is AREA, CHARACTER, or CONSTANT, we follow the attribute with the 
 length, or value for a constant. If the type is PROCEDURE, it may be 
 qualified by EXTERNAL, and if it returns a value this is followed by 
 RETURNS attribute (s ) , where the attributes are found as described above, 
 but using the returns type and flag. The reference list follows the last 
 
3fc 
 
 attribute, references separated by spaces. If we fill up the line, 
 we continue the references on a new line, starting under the place we 
 put the attributes. 
 
35 
 
 THE EXPRESSION ANALYZER 
 
 EXPR translates PLW expressions into their FORTRAN equivalents. 
 It also handles assignment and CALL statements, and can "be United to 
 acting on a single term (simple or subscripted variable). These options 
 can be specified by setting particular bits in the global. EXF LAG. EXPR 
 usually starts analyzing with the next thing returned by SCAN, but can 
 start with the thing most recently returned (e.g. if the calling routine 
 had to check the first operand in order to decide whether to call EXPR) 
 if the EXSCAN bit is set. The FORTRAN output is constructed in a large 
 buffer specified by the calling program. Thus, the output could 
 be appended to something already prepared by the caller. In all cases, 
 EXPR may generate and send to STORK CALL statements to handle any 
 intermediate character string operations. 
 
 The following describes the action on ordinary expressions. 
 The special options which slightly modify this are described later. 
 A. BASIC STRATEGY 
 
 EXPR parses an expression in a simple left-to-right fashion, 
 using a stack. Each entry in the stack specifies an operand followed 
 by an operator. The operator information consists of a type of operator 
 and its precedence. The operand information includes type and flags 
 (similar to those used in the symbol table), value (for integer constants), 
 length (for character strings), and links to argument lists for functions 
 and arrays. The types are a subset of those used in the symbol table. 
 A function has type according to the value it returns. The flag is 
 almost exclusively for use with binary type and has integer, single- 
 precision, and real bits, which are the complement of the bits used in 
 the symbol table. There is also a bit which specifies whether the operand 
 
36 
 
 is a constant (also used for character strings), and if so, there is 
 another bit specifying whether it is imaginary (e.g. 3.21). The latter 
 is useful in simplifying the mess we would otherwise get in translating 
 a ± b. Each stack entry also records the addresses in the output buffer 
 of the first characters of the operand and operator, in case we need 
 to modify them later. 
 
 The basic procedure then is as follows: 
 
 (1) Call SCAN to get an operand and operator; 
 
 (2) If there is an operand, look it up in the symbol table, 
 unless it is a constant, record its type in the new top 
 stack entry, and construct its FORTRAN equivalent in the 
 buffer; 
 
 (3) Decode the operator and record its type and precedence; 
 (h) If the operator in the top stack entry has precedence 
 
 higher than that of the next lower entry, go onto step 
 (6); 
 
 (5) Execute the operator in the next-to-top stack entry, i.e. 
 compute the type of the result of that operator acting 
 
 on top two operands, perform appropriate error checking 
 and conversion, then replace the top two entries with a 
 single entry describing the result. The operator in the 
 resultant entry is taken from the former top of the stack. 
 Now return to step (U); 
 
 (6) Output the operator in the top stack entry, create a 
 
37 
 
 new stack entry on top, and go back to step (l). 
 
 The stack initially contains one entry with the low-precedence 
 "bottom of the stack" operator, and the above process ends when we 
 attempt to execute that operator — the only operators with lower 
 precedence are those that may delimit the expression, e.g. semi -colon, 
 blank, comma. When we execute the bottom-of -stack operator, we take 
 the type, and value if integer constant, of what remains on the stack 
 and return it to the caller. There are, of course, numerous variations 
 on the above procedure, for expressions that do not have the form 
 "operand-operator-operand". The steps are described in greater detail 
 below. 
 B. THE OPERAND 
 
 When we call SCAN, there are various things we can get: 
 
 (1) No operand at ail- generally the case if the operator is 
 unary. Skip to C. 
 
 (2) A constant . This may not be followed by a left parenthesis. 
 We record the type of the constant and set the XCONST bit in the flag of 
 the entry. If the type is binary, we also save the 3 bits qualifying it 
 (float, double, complex), but in complemented form. If the constant is 
 imaginary, the XIMAG bit is also set. If it is an integer, we save its 
 value, so that we may check and simplify the integer constant expression. 
 Then for all types except character strings, the operand is copied directly 
 to the output buffer. Character strings, however, are saved in an 
 auxiliary buffer, and the entry points to that buffer. The length is also 
 stored in the entry. Character string constants cannot be output in 
 
38 
 their original form, since all character strings must be preceded by 
 a length word. So each string is a FORTRAN integer array, initialized 
 in a DATA statement, and the array name is then used in place of the 
 character string. The string is stored in the symbol table for this 
 purpose. But rather than entering it there immediately, we save it, in 
 case two such strings are concatenated. We certainly would prefer to do 
 the concatenation at compile time, rather than at execution time with an 
 extra subroutine call, so that the programmer need not pay extra for 
 splitting a long character string into two pieces on separate cards. 
 
 ( 3 ) An identifier not followed by a left parenthesis . We look 
 it up in the symbol table by calling ISCOPE. If not found, 
 this is an error. If it is a procedure name, it is also an 
 error, since a function must have an argument list. If it 
 is a symbolic constant, we output its value (by means of 
 routine CVDOUT), and the stack entry looks just like an 
 integer constant, as described in (2) above. For any other 
 type we record the type and flag (if binary), and output the 
 name as follows : 
 
 (a) scalar, not in dsect : output the assigned FORTRAN name. 
 
 (b) array, not in dscet : check to be sure this is a func- 
 tion argument, else it is invalid. Output the assigned 
 name. 
 
 (c) scalar in dscet : Output " name ( pointer + disp ) , where 
 name is the name of one of the arrays equivalenced to 
 the common stack, as determined by the array code in 
 the symbol table entry (e.g. 1$ would be used for an 
 integer scalar). Pointer is an expression which gives 
 the displacement in the name array of the beginning of 
 
39 
 the dsect containing the scalar: ( ptr + area ) scale , 
 where area is the assigned name of the area in which 
 the dsect was declared, scale converts from the size 
 of the name array to the standard one-word size, e.g. 
 if name is double-word, then scale is "1/2", and is 
 present only if needed, and ptr is either the name of 
 the pointer declared as default, or an expression in 
 the PLW source qualifying the scalar (P -> NAME). The 
 latter case occurs when the preceeding operator is 
 the pointer operator -»■; the operand preceding it is 
 copied into the ptr space, the original operand is 
 deleted from the output by the routine COMPRESS, and 
 the stack entry containing it is deleted by copying all 
 but the "operand address" field of the top entry into 
 it and moving the stack pointer down. Finally, disp 
 is the displacement of the scalar in the dsect, as 
 given by the symbol table entry. 
 (d) array in dsect : first check, as in (b), then output 
 " name ( pointer + 1 [, 1, ..., l]), where name is the 
 assigned name, pointer is as in (c) above, and as 
 many subscripts are output as the array was declared 
 to have. This expression will give the address of the 
 first element of the array. 
 (k) Identifier followed by left parenthesis . Look it up in the 
 symbol table. The only legal alternatives are as follows: 
 (a) name not found: check list of generic functions (des- 
 cribed later); if not there, assume it is undeclared 
 external function, create symbol table entry for it, 
 
1*0 
 
 type PROC EXTERNAL, give it a default return type, 
 
 and procede roughly as in lb). 
 
 (b) name of procedure: record return type in stack entry, 
 save pointers to regular parameter list and extra 
 parameter list (if any), enter a "function" operator 
 in the entry with appropriate precedence, then output 
 the name — original if external, assigned if internal — 
 followed by left parenthesis. 
 
 (c) name of array: in the stack entry, save the type and 
 a pointer to the subscript list, use an "array" opera- 
 tor with precedence as in (b), and output the name 
 assigned to the array followed by left parenthesis. 
 
 If the array is in a dsect , additionally output 
 " pointer +" as described in (3c) above. This properly 
 displaces the first element of the array. 
 In all of the above cases we skip the operator and execution 
 steps, returning to the scan step to process the first argument or sub- 
 script. 
 C. THE OPERATOR 
 
 We use a table to decode the delimiter returned by SCAN for use 
 as an operator. Our operator codes are used to index various tables. The 
 first of these is a table that tells whether the given operator might be 
 just the first character of a compound operator, e.g. > =, >=,->, **, etc 
 If so, we check the next character on the card, and if the two together 
 form a compound operator, we use its code instead. 
 
 Next we check that the operator is being used in the proper con- 
 text, at least insofar as it is a unary or binary operator. At this time 
 we also discard a unary plus, check for consecutive NOT operators, and 
 
 
kl 
 
 change ordinary minus to unary minus. In the last case, we also supply a 
 "(" if the unary minus was preceded by an arithmetic operator, so that we 
 won't get FORTRAN "double operator" errors. Later on, when the unary 
 minus is executed, the matching ")" will be supplied. 
 
 Finally, after storing the operator we finally decided on in the 
 top stack entry, we calculate the precedence of it by another table, and 
 store that, too. Then we can check to see if the previous operator can be 
 executed. This can occur only when the top stack entry has an operand and 
 the top operator does not have higher precedence than the preceding one. 
 After any execution, output the operator in the top stack entry by still 
 another table look-up. 
 D. EXECUTION 
 
 This is the most complex step, in view of the many different 
 operators available. For that reason, discussion of string operations and 
 special functions is deferred to a later section. 
 
 Execution of an operator generally consists of checking the 
 operands for correct type, performing any necessary conversions, computing 
 the type of the result, and collapsing the two top stack entries into one 
 with the resultant type. In merging two stack entries it is also necessary 
 to merge string temporary lists associated with each. This is discussed 
 later under string operations. Sometimes an operation must be performed by 
 a function reference, i.e. " func (a,b)" instead of "a op b." Conversion of 
 operands is performed conveniently by the routine CONVERT, which forms a 
 converted operand which can either directly replace the original operand or 
 be appended to the current output in the buffer. In general, to replace 
 "a op b" with some expression involving a and b, we form the expression in 
 the buffer following "b" , copying a and b directly where needed, to form 
 "a op b expr(a,b)," then delete the original contents by moving the 
 
U2 
 expression we formed to the left to where "a" originally was. There are 
 several moving routines to perform these operations. The central one is 
 MOVE, which moves a string of given length from its present location to 
 the location given by the current buffer points and then up dates the 
 pointer to just beyond the string. Auxiliary routines include CONCATIT, 
 which moves a given operand to the end of the buffer, and COMPRESS, which 
 deletes a section of the buffer by moving everything on the right of it on 
 top of it. In particular, if we wanted to replace "a op b" with "f(a,b)," 
 the procedure would be: construct "f("; call CONCATIT to move a; append 
 ","; call CONCATIT to move b; call COMPRESS to delete "a op b" ; append 
 ")". Incidentally, all these move routines have to check that we don't 
 overflow the buffer. We are given some flexibility in that the "end" of 
 the buffer is followed by some overflow space; thus, we need not check for 
 overflow every time we put a comma, parenthesis, or other small item in 
 the buffer. 
 
 Execution procedure for most operators follows now. 
 (l) + - * /. The operands must be type binary. Flag operands 
 are permitted, which we convert to binary. The resultant 
 type is found by taking the logical AND of the flags of the 
 two operands. Thus the result is constant (integer, single- 
 precision, real) if and only if both operands are constant 
 (integer, ...). If the result is an integer constant, we 
 compute its value from the values given in the stack entries, 
 checking, of course, for overflow, and also output this 
 value to replace the two operands in the buffer. If the 
 first operand is a real constant and the second is an imagi- 
 nary constant, the two are combined into a single complex 
 constant of common precision by constructing the real part 
 
k3 
 converted to common precision, comma, imaginary part of 
 second constant also converted, all enclosed in parenthesis. 
 CONVERT assists in this operation. If the result is a 
 constant other than integer or the complex constant just 
 described, it is no longer useful to think of it as a con- 
 stant (e.g. we cannot do much with 2.0 + 1.8E12), so we 
 turn off the constant hit. 
 
 (2) **. This is similar to (l) in computing the result type 
 and evaluating it if integer constant. However, we do not 
 deal with flag operands, since they are pretty meaningless 
 here. And if the result is complex, FORTRAN will not per- 
 mit it unless it is complex base and integer exponent; all 
 other cases are handled by function call: a**b becomes 
 [D]P0WR$(a l ,b' ) , where a' and b' are a and b converted to 
 complex of the same precision, which, if double, requires 
 the DPOWRS routine. 
 
 (3) Unary minus. Same strategy as (l), except there is only 
 one operand. Also, we supply a closing parenthesis if we 
 earlier decided to enclose the operation in parentheses 
 (e.g. A*-B must be written A*(-B)). And merging the two 
 stack entries into one is much simpler. 
 
 (1+) =. If the operands are character strings, this is done 
 by function reference. If the operands are complex, not 
 all versions of FORTRAN will accept it. So "a = b" must 
 be rewritten as n Re(a). EQ. Re(b).AND.Im(a) .EQ.Im(b)" , 
 and similarly "a = b" with .EQ. and. AND. replaced by .NE. 
 and .OR. The real and imaginary parts are taken by CONVERT, 
 which handles either constants or general expressions, e.g. 
 
Uk 
 
 the real parts of (l.O, 2.0) and X**2 are 1.0 and REAL 
 (X**2), respectively. FLAG operands may be compared, in 
 which case = is the equivalence operator and = is the exclusive 
 OR operator, but these must be done by function call, since 
 standard FORTRAN has no such operators. Other comparisons 
 for (in)equality are permitted, as long as the operands are 
 of the same type. In all cases, the result is of type 
 FLAG. 
 
 (5) > = <. These operations are only permitted for operands 
 of type CHARACTER or BINARY (not complex). Character 
 comparisons are performed by function call. The result is 
 type FLAG. 
 
 (6) & I . The AND and OR operators must have FLAG operands. The 
 result is type FLAG, as in (h) . 
 
 (7) _n - The single operand of the NOT operator must be type FLAG, 
 as is the result. As in unary minus, the merging operation is 
 almost trivial. 
 
 (8) Parenthesis. A left parenthesis is treated syntactically as a 
 unary operator, and the encounter of a right parenthesis tells 
 when to execute it. If we attempt to execute the left paren 
 when there is no right, we must have mismatched parantheses 
 Execution consists of copying the top stack entry containing the 
 operand into the entry below it, containing the left paren, except 
 for the operand address, which remains that of the left paren 
 
**5 
 
 as originally, and moving the stack pointer down. We 
 output a right parenthesis , unless the entire operand within 
 parenthesis is a constant, in which case we delete the left 
 parenthesis. This makes a cleaner output and also permits 
 us to continue treating the operand as a constant. Next we 
 decrement the parenthesis count, which is incremented for 
 each left paren. Now we need an operator. A right parenthesis 
 is the only operator in the language which must be followed 
 "by an operator. It is useful at this point to think of left 
 parenthesis simply as the first and last characters of an 
 operand. That operand is presently in the top stack entry. 
 To get the operator following it, we call SCANDELM, which will 
 return just an operator, or blank if there is an operand (if 
 we called SCAN, we would run into trouble in such contexts as 
 "IF A = B*(C+2) THEN" because we would read the word THEN instead 
 of stopping at the preceding blank). Then we return to the 
 operator step. 
 (9) Array operator. For both array and function operators, the 
 stack looks something like: 
 
 next-to-top entry top stack entry 
 
 start control array /func addr type control delimiter 
 
 address info operator info 
 
 (array type or func return type) (for argument or subscript) 
 
 (comma or ')' 
 
 The control info in the top entry includes value for integer 
 
 constant or temp list pointer for others; in the other entry is 
 
 the temp list link for the entire array/func reference, and 
 
U6 
 
 a link to a subscript or parameter list. A comma or right 
 parenthesis marks the end of the argument and by its lower 
 precedence causes us to execute the array/func operator. The 
 execution consists of checking the operand for correctness and 
 merging its control info into the array/func entry. We are then 
 done with the argument, and if there was a comma, we output it 
 and return to the scan step to get another.' With a right 
 parenthesis the situation is quite similar to the case described 
 in (8) with just a left parenthesis. The chief difference is 
 that here all the operand information is already in the lower 
 stack entry, so it need not be moved. Outputting the closing 
 parenthesis and getting an operator proceeds in- the same manner. 
 Now specifically for the array operator: The subscript list is 
 presently used only for counting the subscripts. Originally, 
 the entry has the pointer to the start of the subscript list. 
 As each subscript is processed, the pointer is replaced with the 
 pointer to the next subscript entry. When the pointer becomes 
 null, we have processed the last subscript, which had better be 
 followed by a right paren. The only other subscript checking 
 is when the subscript is an integer constant we check to be 
 sure it is positive. This detects such obvious FORTRAN errors 
 as A(-l). 
 (10) Function operator. Mostly described already in (9). The 
 argument list pointer gives the actual parameter entry or 
 
hi 
 
 model parameter for the argument we are currently processing. 
 We use this to check that the argument is of the proper type. 
 If not, we attempt to convert it. When finished with the 
 argument, the pointer is replaced with the link to the next 
 entry in the list. If the argument is a character constant, 
 now is the time we enter it in the symbol table and give it a 
 name, which is output. All this is handled by the routine 
 ENTRCHAR. External functions need not have a parameter list 
 declared, in which case we keep a null pointer and don't bother 
 checking arguments at all. When we finish with the last argument, 
 we output any extra parameters that may be needed (gloLals allocated 
 there by IS COPE ) , which is performed by the routine ADDPARMS. 
 Character functions are slightly different, as described later. 
 
 E. EXTERM OPTION 
 
 By setting the EXTERM bit in EXFLAG, the caller requests a 
 one-term expression. This is handled at the operator step. If the 
 parenthesis count is currently zero and the EXTERM bit is set, the 
 operator is taken to be blank, regardless of what it actually is. This 
 forces the previous operator (the bottom of the stack) to be executed, 
 thereby terminating this expression. If the term was an array with 
 subscripts, the paren count will not be zero at this step until all the 
 subscripts have been processed. 
 
 F. ASSIGNMENT STATEMENT 
 
 By setting the EXASSN bit in EXFLAG, the caller states that 
 
>*8 
 
 signment statement, which should be sent to STORK when 
 ed. The trick here again occurs at the operator step when the 
 parenthesis count is zero. If the operator is "=", it is changed to the 
 assignment operator and the EXASSN bit is cleared. If the operator is 
 anything else, the assignment statement is invalid. By checking when the 
 paren count is zero and then clearing the bit, we are sure to get the "=" 
 right after the first "term" of the statement. 
 
 Execution of the assignment operator involves checking to see 
 that the left- and right-hand-side types are the same, then sending the 
 whole statement to STORK. If the type assigned is character, then the 
 statement becomes a CALL statement, as described later. 
 
 Some further checking is also needed when the EXASSN bit is 
 on. The left-hand side of the statment may not be a constant or function 
 reference. The former is checked at the same time as we find the "="; 
 the latter is checked whenever we process a function by making sure 
 that the preceding operator is not the bottom of the stack. 
 G. CALL STATEMENT 
 
 By setting the EXCALL bit in EXFLAG, the caller states that 
 he has just scanned the word CALL followed by a blank, and wishes us to 
 process and finally output the CALL statement. We start the statement 
 "CALL", call SCAN to get the subroutine name, and look it up in the 
 symbol table. If the name does not exist, we create an entry for it. 
 If the name is followed by a semi-colon, it has no arguments. In this 
 case, if there are any extra parameters specified in the procedure entry 
 we output them (by ADDPARMS), and then we are done. If the name is 
 
U9 
 
 followed by an argument list, we set up a function operator as in the 
 usual operand step. Then we set the EXTERM hit to make sure we stop 
 after the argument list, and then we can continue as in the regular case. 
 H. CHARACTER STRING OPERATIONS 
 
 FORTRAN has almost no facility for manipulating character strings, 
 and those that it has are worthless for providing the general operations 
 used in PLW. Thus, all character operations are performed by calls to 
 short assembly- language routines. The operations available are assignment, 
 concatenation, comparison, and substring extraction. The first word of 
 a character string variable or constant contains length information used 
 by these routines. The length word is coded in such a way that the null 
 string is represented by the integer zero. 
 
 When an expression requires storage of intermediate results, 
 we use string temporaries generated for the purpose. These are integer 
 arrays of the necessary length. They are reusable, and thus their lengths 
 are not fully determined until the end of the procedure, at which point 
 they are declared to be of the longest length used. The expression 
 analyzer attempts to minimize the use of temporaries, e.g. by recognizing 
 that the statement "A = B | | C" indicates one operation requiring no 
 temporaries, not two (concatenation, then assignment). 
 
 The operations are described in greater detail in the following 
 sections. 
 
 (l) The routine GETMP is passed an integer indicating the 
 number of characters in the desired temporary. GETMP 
 allocates a temporary and returns its name (6 characters) 
 and a code to identify it by. When the temporary has 
 
50 
 
 served its purpose and is available for re-use, FRETMP 
 is called with the code. To free all temporaries used 
 during a procedure, call FREALL. At the end of the 
 procedure, when doing declarations, call DCLTMP to generate 
 declarations and initializtions for all temporaries allocated 
 in that procedure. 
 
 GETMP maintains lists of temporaries in a large pool. There 
 is a list for each procedure requesting temporaries, and the 
 lists are stacked: one is started with the first request 
 in a given procedure, and is des carded, after generating 
 the declarations for it. Aside from the control information 
 linking the lists together, a list just consists of a series 
 of numbers 'indicating the lengths of the temporaries allocated. 
 A negative length indicates one in use; a positive length 
 indicates a free one. When a request comes in, GETMP first chec; 
 to see if the current list belongs to the current procedure. 
 If not, a new list is created and linked to the old, and 
 the first element in the list is for the requested temp. 
 If the list already exists, then we search for a temp to fit 
 the request. In scanning the list, we keep track of the 
 smallest length greater than the requested length and the 
 largest length that is too small. Temporaries in use 
 automatically disqualify, since their negative lengths cause 
 all algebraic comparisons to fail. When the search is finished, 
 we pick the temp that fits the best and allocate it by 
 negating its length. If no temps fit, then we pick the largest 
 
51 
 one available and increase its length to the requested size 
 If no temps were free, we add a new one of the required 
 length to the list. The displacement in the list is the 
 temp's "code". And the code determines the final character 
 of the name , whose first characters are $TEMP . 
 
 Given a code , FRETMP frees the temp by negating its length 
 again, to make it positive (if the length was not negative, we 
 have a compiler error). FREALL goes through the whole active 
 list, making all the lengths positive. DCLTMP goes through 
 the list, making a declaration and initialize of length word 
 for each temp. 
 
 Back in EXPR , each operand has a link to a list of codes for 
 all the temporaries used in forming that operand. Generally, 
 when an operator is executed, the temp lists of its operands 
 are combined. A temporary cannot be freed until the FORTRAN 
 statement it is used in is finished and its contents are no 
 longer needed. Before EXPR returns to its caller, it calls 
 FREALL to free all the temps, which is mainly useful when an 
 error occurs and the temps allocated have not had a chance 
 to be freed in the usual fashion. 
 
 (2) Assignment . The statement "a=b" is transformed into "CALL 
 move (a, b)". The transformation occurs when we execute 
 the assignment operator and find that its operands are of 
 type character. This situation only occurs when b is a single 
 "term". If b is a character expression, the assignment is 
 performed as the final step in the evaluation of the expression, 
 
 (3) Concatenation. The resultant length of the concatenation 
 
52 
 
 operation is simply the sums of the lengths of the operands. 
 If the operands are constants, we perform the concatenation 
 directly and continue saving the result. Otherwise, we 
 construct, for " t>," "CALL con cat (a, b, ?)", where the 
 result parameter depends on the context. If the result 
 of the concatenation is assigned to something, i.e. the 
 preceding operator is the assignment operator and the 
 following operator is the "blank" operator at the end of 
 the statement, then that something is the result parameter, 
 and the entire statement is finished. Otherwise , we allocate 
 a temporary of the resultant length to act as the result 
 parameter. The CALL statement is sent to STORK, any 
 temporaries embodied in the operands are freed, and the 
 result temporary replaces the operands. A few examples: 
 
 X = A | | B; becomes CALL con cat (A,B,X) 
 
 X = a||b||c||D; could become CALL con cat (A,B,temp l) 
 
 CALL con cat (temp l,C,temp 2 
 CALL con cat (temp 2,D,X) 
 
 Concatenation never requires more than two temporaries at once. 
 However, more may be needed for character functions. 
 h) Character functions . Since FORTRAN has no facility for 
 functions to return character values, character functions 
 are implemented as subroutines with an extra result parameter. 
 Our only problem is deciding what to use for the result 
 parameter. The decision is basically the same as that for 
 concatenation. However, after processing the last item in 
 
53 
 the argument list, which is when we want to make the 
 
 decision, we do not have enough information, since we do not 
 
 yet know what the operator following the function expression 
 
 is. To solve this problem, when we have finished processing 
 
 the last function argument we set a special flag before 
 
 proceeding on the usual course of scanning for an operator. 
 
 The flag is checked when we finish decoding the operator, and 
 
 if on , a special routine takes over and makes the decision. 
 
 If the decision is to use a temporary, we know what length 
 
 is needed from the procedure declaration. After the CALL 
 
 statement is sent to STORK, all temporaries embodied in the 
 
 arguments are freed (they had been combined into one list 
 
 already) and the result temporary replaces the function in 
 
 the buffer. Examples: 
 
 X = func (A,B,C); becomes CALL func (A,B,C,X) 
 
 X=func (A,B|| C, func(Q,P,R)) Z K; becomes 
 
 CALL con cat (B,C, tempi) 
 CALL func (Q,P ,R ,temp2 ) 
 CALL func (A,templ,temp2 ,temp3) 
 CALL con cat ( temp3 ,Z, tempi) 
 CALL con cat ( tempi, K,X) 
 (5) Substrings . The substring function can occur anywhere, including 
 on the left-hand side of an assignment statement. It has 
 the form SUBSTR (string, index, length), where the arguments 
 specify the string, index of the first character of the 
 
5k 
 
 substring and its length. If the length is omitted or 
 negative, the substring starts at the given index and 
 includes the remainder of the string. 
 
 EXPR discovers SUBSTR when it fails to find the name in the 
 symbol table. We check to see if it is the left-hand side 
 of an assignment (preceding operator is bottom of stack and 
 EXASSN bit is on), in which case we mark it L, otherwise R. 
 Instead of a "function 1 ' operator, we use a "substring" 
 operator. And both cases are implemented by a CALL 
 statement, but the subroutine is different for each case. 
 
 As we process the arguments, we check for correct type and 
 combine temp lists as usual. But we also seek a good 
 estimate on the length of the result. First guess is the 
 length of the first argument. But if the second argument is 
 an integer constant, say with value K, then we can reduce 
 that guess by K-l. And if the third argument is an integer 
 constant we have the length exactly. If the third argument 
 is missing, we supply -1. 
 
 After processing the three arguments, we must supply a fourth 
 In the case of the R substring operator, this is the result 
 argument, which is formed exactly as with any character 
 function, as in (h) above. For the L substring it will 
 be the character string to be assigned to the described 
 substring, i.e. the right-hand side of the assignment. To 
 do this, we scan and make sure we have the "=" operator, 
 
55 
 then change the operator from "left substring" to "substring 
 assignment" and give it the precedence of the assignment 
 operator. Executing this new operator consists of making 
 sure the right-hand side is a character expression and 
 following it with a right parenthesis. 
 Examples : 
 
 X=SUBSTR (A, 1,1); becomes CALL substring (A,1,I,X) 
 
 SUBSTR (A, 1,1) = X; becomes CALL substring (A,1,I,X) 
 
 SUBSTR (X,K,L) = SUBSTR (Y ,2 ,12 ) ; SUBSTR ( Z,2 ,2 ) ; 
 
 becomes CALL substringR ( Y,2 ,12 , tempi ) 
 
 CALL substringR (Z ,2 ,2 ,temp2 ) 
 
 CALL con cat (tempi ,temp2 ,temp3) 
 
 CALL substringL (X,K, L,temp3 ) 
 
 (tempi needs length 12, 
 
 temp2 needs length 2, 
 
 temp3 needs length lk) 
 
 I. GENERIC FUNCTIONS 
 
 EXPR is equipped to handle a certain number of generic functions, 
 
 e.g. ABS,SQRT,MAX. These functions are replaced by the appropriate FORTRAN 
 
 function, according to the type of the arguments. Thus, ABS could become 
 
 LABS,' DABS, CABS or CDABS: MAX become MAXO, AMAX1, or DMAX1 , and in 
 
 addition, all the arguments must be converted to the same type and precision. 
 
 A generic function is recognized at the operand step when the name 
 
 is not found in the symbol table. Thus, if the programmer defined his own 
 
 SQRT function, it would not be treated specially as a generic name. The 
 
56 
 
 name is sought in a table of generics, then, if found, appropriate setup 
 
 action is taken.. This includes outputting the name, with a little room 
 
 for expansion, and storing in the stack a "generic" operator. When the 
 
 operator is later executed, after processing the argument, we check the 
 
 argument type, convert it if necessary, and replace the function name with 
 
 the appropriate FORTRAN name. The functions currently recognized by the 
 
 compiler fall into several groups: (l) ABS ; (2) SQRT,LOG,EXP,SIN ,COS; 
 
 (3) INT; (U) FLOAT; (5) REAL, IMAG; (6) MAX,MIN. All functions in a group 
 
 are handled in the same way. Additional group can be added simply by 
 
 adding the names to the table and writing more code. 
 
 All generic functions use arguments of type binary. For more 
 
 details 
 
 (1) ABS. Output the name with two spaces in front to allow 
 future alteration (e.g. to CDABS). When we execute it, if 
 the argument is an integer, put I in front; else do as in (2). 
 
 (2) SQRT, LOG, etc. As in (l), save two spaces in front of the 
 name. When executing this function, if the argument is an in- 
 teger, convert it to float single. If the argument is double, 
 put a D in front of the name. If the argument is complex, 
 put a C in front of the name (can do both). The result is of 
 the same type and flags as the argument. 
 
 (3) INT. Again, set up with two spaces in front. The argument 
 must be real. If it is double, put ID in front of name to get 
 the double-precision function IDINT. Result is always integer. 
 
 (U) FLOAT. Save no space. Function is meaningless unless the 
 argument is integer. Result is float single. 
 
57 
 
 (5) REAL, IMAG. Save one space. Argument must "be complex. If 
 it is double, put D in front of name. Result is real of the 
 same precision. 
 
 (6) MAX, MIN. Save a space in front and a space after the name. 
 These functions are the most involved, since they have an 
 arbitrary number of arguments. We must eventually convert 
 all arguments to the same type/flag, so we must save all 
 
 the arguments on the stack, unlike regular functions. Processing 
 the first argument is a special case — we tentatively use its 
 flag as the common result flag, and it must "be followed "by a 
 comma. For each subsequent argument, we check to see if it 
 is lower in the hierarchy integer — single-double than the 
 preceding argument, and if so, convert it. When we finish 
 the last argument (followed by right parenthesis instead of 
 comma), we know the type of the result. Now we go backwards 
 through the stack, converting each argument as needed, until 
 we get back to the original function entry, at which time we 
 change the name to MAXO , AMAX1, or DMAX1 (MINO, AMINI , DMINI ) 
 according to the result type. Incidentally, we do not allow 
 complex arguments. 
 J. ERROR CHECKING 
 
 EXPR must pick out as many errors as it can, however trivial 
 or extreme, before the program gets to the FORTRAN compiler, since any 
 diagnostics after that point will be rather meaningless to the programmer. 
 And due to the wide range of possible errors and the difficulty of trying 
 to recover any of them, the policy for most errors is simply to throw out 
 
58 
 
 the whole expression as invalid, scanning to its end by calling DISCAED2 
 (an entry point of SCAN) , and leaving. 
 
59 
 
 THE COMMAND PROCESSOR 
 
 CMD is the main routine of the PLW compiler. It initializes 
 all sorts of things, keeps track of the block structure of the program, 
 decodes commands, and just generally is in charge of seeing that each state- 
 ment is properly processed. It is set up to permit hatching — when it 
 reaches the end of the outer procedure and end-of-file does not occur, it 
 just re-initializes and starts the whole business over again. 
 
 A. THE BLOCK TABLE 
 
 CMD maintains a block table to keep track of the structure of 
 the program. There is an entry in the table for each PROC , DO, CASE, and 
 IF statement, keeping information on the kind of block, statement numbers 
 it uses, and perhaps a bit of symbol table information, as well as links 
 to next and previous entries. Since there is no need to remember anything 
 about a block once it is finished, the block table is operated as a stack. 
 Further details concerning the information in the entries follows in the 
 descriptions of the various statements. Related to the block table are 
 the globals BLKNO and LVLNO , which contain the current block and level 
 numbers. The block number is incremented each time we enter a new block; 
 the level number is incremented on block entry and decremented on exit. 
 
 B. STATEMENT NUMBERS ; GOTO AMD CONTINUE 
 
 Although PLW has not GOTO statement, the FORTRAN translation 
 requires quite a few. So CMD has special facilities to generate unique 
 statement numbers and use them with GOTO and CONTINUE statements. INCLABL 
 generates a new statement number, FORTGOTO generates a GOTO statement 
 transferring to a given label, (statement ft) and FORTCONT generates a 
 
60 
 
 CONTINUE statement having a given label. Labels are generated almost 
 exclusively on CONTINUE statements, since, in general, a PLW statement 
 or even a simple expression can result in several FORTRAN statements, and 
 this saves the trouble of telling a subroutine that the first statement 
 it generates must have a given statement number. In fact , the problem is 
 not even that simple, since the routine might generate no statement, or 
 we could suddenly be starting a new procedure (which can appear most 
 anywhere ) . 
 
 Although various constructions in general may require several 
 labels or transfers, specific programming examples do not always need them, 
 and we really would like to avoid cluttering up the FORTRAN output with 
 unnecessary statements, especially £ince we are already generating quite 
 a few. For example, a DO loop generally requires two labels, one for loop 
 and one for exit, but the exit label is unnecessary if it is never used, e., 
 
 DO I = 1 TO 10; N = N + I; END; 
 will never use the exit label. And IF-THEN-ELSE constructions have the 
 generally voluminous output 
 
 IF (.NOT. (test)) GOTO label 1 
 
 then clause 
 
 GOTO label 2 
 label 1 CONTINUE 
 
 else clause 
 label 2 CONTINUE 
 But a sequence like 
 
 IF A = THEN RETURN; 
 ELSE LOOP; 
 
6l 
 really does not need the extra GOTO and CONTINUE, since the RETURN is 
 
 a transfer statement (in fact, deleting the word ELSE results in an 
 equivalent statement). Not only are those statements unnecessary; their 
 inclusion in the FORTRAN output would result in diagnostics for an unlabeled 
 statement following a transfer statement. 
 
 To do something about the first problem, each statement number 
 is flagged when it is used, e.g. by a GOTO. The flag consists of turning 
 off the top bit, since EBCDIC numbers all begin with a one {h one's, in fact). 
 Then when FORTCONT generates a continue statement for a label, it checks 
 the flag, and if the flag says the label is unused, no statement is generated. 
 
 The other problem is handled by FORTGOTO. Whenever it generates 
 a GOTO statement, in addition to flagging the label as used, it sets a flag 
 in CMD that indicates a GOTO has been output. The flag is cleared whenever 
 a non-GOTO statement is generated. FORTGOTO will not bother generating a 
 GOTO statement if the flag is on. 
 C. SCANNING THE COMMAND 
 
 In scanning a command the first thing encountered must be an 
 identifier. If it is followed by a colon, it is a label, which CMD saves 
 until it has scanned the command word. Only one label is permitted per 
 statement. If the command turns out to be PROC, then STJUNK will use the 
 label in creating the procedure entry. If the command is DO or CASE, the 
 label will be entered in the symbol table, always with information from the 
 block table. On any other command, the label is ignored. 
 
 After scanning an identifier which we expect to be a command, 
 we first see if it is the word PROC or PROCEDURE. If so, we handle it 
 immediately, as described below. If we have not yet encountered a procedure 
 
62 
 statement, any other command is ignored. Next we see if the delimiter 
 is "=". If so, this is an assignment statement. Otherwise, we scan a table 
 of commands in an attempt to identify it. If not found there, the 
 command is unknown, unless it is followed by "(", in which case we tentatively 
 assume it is an assignment statement. 
 
 After identifying the command, we check the delimiter. Any 
 command may be delimited by a blank. The only other permissible delimiters 
 are "(" and ";", and the entry in the command table specifies which of 
 these, if either, is permitted. 
 
 At this point, if this is an assignment statement, we are using 
 a dummy command entry for it, so it looks just like any other command. 
 Now we must take care of some special cases. The commands DECLARE, ELSE, 
 END, and OTHER are marked specially in the command table because they are 
 never objects of THEN, ELSE, OTHER, or CASE. If we are about to do a 
 command that follows THEN or ELSE, we make sure it is not one of those. 
 If a THEN or ELSE block is currently on top of the block table, we have 
 just finished processing the object clause and must close the block, 
 unless we are doing an ELSE. If closing the block results in the same 
 situation again, we repeat the process. Finally, if a CASE block is on 
 top now, we are about to process another case object, unless it is one 
 of the specially-marked commands, and we must provide exit for previous 
 case object and starting label for the new one. After taking care of all 
 this, we transfer to the appropriate routine to handle the statement. 
 D. PROCEDURE STATEMENT 
 
 We first tell STORK that we are starting a new procedure. Then 
 
63 
 
 we create a new block table entry of type PROC. Then call STJUNK(l), 
 which handles the rest of the statement (see section IV. A.). Finally, 
 we save in the block entry the index of the now-active procedure, and 
 generate and save a label which will be used on the return sequence for the 
 procedure. 
 
 E. DECLARE, CALL, AND ASSIGNMENT STATEMENTS 
 
 For the first, call DCL(O) (described in section IV). For the 
 other two, call EXPR, with EXFLAG appropriately set (see sections V. 
 
 F. and G. ) 
 
 F. IF STATEMENT 
 
 Make a new block entry of type THEN, and generate one label. 
 Start constructing in the output buffer "IF (.NOT.(", call EXPR to get 
 the conditional expression, make sure it has type FLAG, then follow it up 
 with ")) GOTO label" and send the whole statement to STORK. This statement 
 will cause a branch around the THEN clause if the condition is not satisfied. 
 Finally, check to see that the conditional expression is followed by the 
 keyword THEN. Return to the command scanner with a flag set to indicate the 
 THEN clause follows. 
 
 A then block is closed before we process the statement following 
 the THEN clause, unless that statement begins "ELSE". To close the block, 
 generate a CONTINUE statement with the label saved in the block entry, then 
 pop the block off the stack. 
 
 When the statement following the THEN clause is "ELSE", the 
 action is slightly different. First generate a new label and make a 
 GOTO to that label. Then make a CONTINUE statement using the THEN label. 
 
6k 
 
 Finally, change the block flag to ELSE, replace the THEN label with the 
 new ELSE label, and return to the command scanner. An ELSE block is 
 later closed in the same fashion as a THEN block. If we run into the 
 command ELSE when the current block is not THEN, this is, of course, 
 cause for an error message. 
 G. DO STATEMENT 
 
 This is probably the most difficult to process, owing to its 
 quite flexible syntax. A DO block entry is created, along with two 
 labels — one each for loop and exit. If the DO is followed immediately by 
 a semi-colon, so that there are no operands, then this is all we have to do. 
 Otherwise, there are three basic sections to do: (l) process a WHILE operand, 
 
 (2) process a control variable and iteration values, and (3) generate the 
 FORTRAN DO and accompanying statements. (l) and (2) may be performed in 
 any order, and either may be missing. 
 
 (1) The WHILE operand . We recognize this by scanning the 
 keyword WHILE. We start constructing in the output buffer 
 "IF (.NOT(", then call EXPR to get the conditional expression 
 which must be of type FLAG, then follow it with ")) GOTO exit 
 label". The statement is not output yet, but rather saved 
 
 in the buffer for later. Set the WHILE bit in the DO block 
 flag and return to scanning operands. 
 
 (2) Control variable, et al . If an identifier is scanned which 
 is not WHILE, it is assumed a control variable. Since the 
 control variable and loop limits can be quite general in 
 PLW while being quite restricted in FORTRAN, we generate 
 
65 
 integer variables of the form JA$nnn, JB$nnn , JC$nnn , JD$nnn , 
 where nnn is the current level number. These names are 
 sufficiently unique, since no two DO loops at the same 
 level can "be nested, and they provide some limited 
 capability of re-using variables. 
 
 For the control variable, we call EXPR with the EXTERM 
 bit set, which will hopefully result in stopping at the 
 "=" (if not, programmer error). We save it in the buffer 
 with some extra space for later. JA$nnn will eventually be 
 used as the control variable in the DO statement, and what 
 we just saved will assign its value to the real control 
 variable. 
 
 The lower and upper limits and increment expressions are all 
 handled by the same code. We construct "Jx$nnn =", where x is 
 B, C, or D for the lower limit, TO, and BY expressions, 
 respectively. Then we call EXPR and check that the result is 
 binary. If it is an integer constant, we save its value; 
 otherwise we output the resulting statement immediately. 
 (3) Putting it all together . If there were any non-integer-constant 
 iteration values, we have already output one or more statements 
 of the form "Jx$nnn = expression". Now if there was no control 
 variable, we can skip the following mess. First check to 
 see if there was an upper limit (a TO expression). If not, 
 supply the pre-declared variable I$BIG instead of JC$nnn. 
 Now if the increment is a negative constant (non-constant 
 increments are assumed to be positive), interchange the lower 
 
66 
 and upper limits (symbolically). Finally, if the limits 
 of iteration were both constants, but the lower one was 
 not positive, and (-lower+l) to both and remember 
 that number. If only one is a constant and happens to be 
 non -positive, then we need to generate a "Jx$nnn = value". 
 With these preliminaries out of the way, we can start generatin, 
 some statements. 
 
 First comes an IF statement to bypass the entire loop if 
 the lower limit exceeds the upper, unless, of course, both 
 are constants, in which case we can tell by inspecting the 
 values. The statement is simply "IF (lower .GT. upper) GOTO 
 exit label", where lower and upper are the integer values or 
 the generated variables JB$nnn , JC$nnn. 
 
 Next comes the DO statement itself, which is pretty simple 
 now: "DO looplabel JA$nnn = lower, upper[ ,incr]" where 
 lower, upper, and incr are integers or the generated Jx$nnn , 
 and incr is omitted if ther was no BY operand. Also, if the 
 increment was negative constant, we use its absolute value. 
 
 Next comes the assignment of JA$nnn to the true control 
 variable. We have already saved the control variable 
 expression in. the buffer, so all we have to do is add the 
 right-hand side. If the increment was not negative, this 
 is simply "JA$nnn", followed by the opposite of the amount, 
 if any, we added onto the iteration limits to make them 
 
67 
 positive. If the increment was negative, we -use "lower + 
 upper — JA$nnn", and if we added onto the iteration limits 
 we subtract that amount off once. 
 
 All of the above was for a control variable. If there was only 
 a WHILE operand, we output instead the single statement 
 
 "DO looplabel JA$nnn = 1, 1, 1$ZER0" 
 which will always loop. The last statement output is the WHILE statement, 
 if any, that we saved in the buffer in step (l). 
 H. CASE STATEMENT 
 
 As for the DO statement, we create a new block entry, two labels, 
 and a control variable JA$nnn . The block entry has type CASE and an 
 additional flag we can set if we encounter the OTHER clause. The second 
 label is for exit, but the first will appear on a computed GOTO statement. 
 Again, the control variable is sufficiently unique, since nested DO/CASE 
 blocks are at different levels . 
 
 The expression following the word CASE (must be binary) is output 
 following "JA$nnn =". Then we generate a GOTO to the first label, and 
 return to the command scanner. 
 
 Now each time CMD is ready to do a command and sees that the 
 CASE entry is visible, it knows that the command is a new case clause, and 
 it generates "GOTO exitlabel" followed by a CONTINUE statement with a new 
 label on it to start the new clause. The labels generated for this purpose 
 are stored sequentially at the end of the CASE block entry (which entry 
 is obviously of variable length). 
 
 When the command OTHER is encountered, we first provide an 
 exit for the last case clause. Then we construct the computed GOTO 
 
68 
 labeled by label 1 in the case entry and containing each label generated for 
 the case clauses: 
 
 lab ell GOTO ( LI , L2 , . . . , LN ) , JA$nnn 
 where L1,...LN are the labels on the clauses. Then we can process the 
 OTHER clause. If there is no OTHER clause, the computed GOTO is generated 
 when we encounter the END. And the CONTINUE using the exit label, of course, 
 comes last. 
 I. EXIT STATEMENT 
 
 We call on CHKLABEL to process any label following the keyword 
 EXIT. If there is no label, or if the operand is not the label of an active 
 block in this procedure, it returns the current block entry; otherwise, the 
 block entry described by the label. The search for that label goes somewhat 
 as follows. First, the active symbol table is searched for the name. If it 
 is found, then it should be a label we defined on a DO or CASE earlier. The 
 label entry specifies the block entry, the latter checks to make sure it is 
 indeed the entry that was active when the label was defined. If the name 
 was not found, we start the laborious search backward through the entire block 
 table, and for each PROC block we find, we see if the label belongs to the 
 proc by comparing the name in the symbol table (it was basically for this 
 reason that we saved the proc index back when we first processed the proc). 
 
 Now armed with the appropriate block table entry, we check that it 
 is a DO/CASE block. If a conditional block, we back up until we find a 
 non-conditional block. Then we output a GOTO to the exit label. 
 J. LOOP STATEMENT 
 
 We call on CHRLABEL to find the proper block, which should be a 
 DO block with a control variable or WHILE operand (again, if conditional 
 
69 
 
 block, back up to a n on -conditional block). Output "GOTO looplabel". 
 K. - RETURN STATEMENT 
 
 Look to see if the active procedure returns anything. If so, 
 look for an expression following RETURN. There are basically two cases here. 
 If the thing returned is not supposed to be a character string, this is a 
 FORTRAN function, and the proper method is to assign the return value to 
 the function name, which we also get from the symbol table entry. But 
 a character string must be assigned to the result parameter by subroutine 
 call. Thus, we construct either "name =" or "CALL move ( $RETCH" , and 
 call EXPR to fill in the value. We check the type to be sure it matches 
 what was declared, supply ")" for the subroutine call, and output the 
 statement. The, whether a value is returned or not, we GOTO the return 
 sequence, whose label is in the proc block entry. 
 L. END STATEMENT 
 
 If we are currently in a conditional block, this is invalid. 
 Again, we call on CHKLABEL to find out which block he is talking about. If 
 it is not the active block, we give him a warning, then proceed to close 
 all blocks within and including the specified block. 
 
 Closing a DO block consists of defining the loop and exit labels 
 with CONTINUE statements (if one or both is unused, FORTCONT will omit them). 
 A CASE block needs only the exit label defined, but if no OTHER was encountered, 
 that must be preceded with the computed GOTO (see H). A PROC is closed 
 with a RETURN statement with the label from the proc entry, and then an END 
 (future editions may need a more complicated return sequence); then we call 
 
70 
 
 STJUNK(l) to handle the symbol table end of it. After a block is closed, 
 we pop its entry from the block table. Repeat this step for as many 
 blocks as need to be closed. 
 
 M. FINISHING IT ALL . . . 
 
 When we close a PROC block and find we are back at level zero, 
 we have just finished the outer procedure. We call XREF to print a 
 cross-reference table. Then we call SCAN to see if there is anything more 
 in the input. If end-of-file now, we are done and the FORTRAN compiler can 
 take over. Otherwise we reinitialize everything, which consists chiefly 
 of clearing out a block table entry, resetting STMTNO and BLKNO to 
 zero, and calling START to reinitialize the symbol table. Then the 
 whole business starts all over again. 
 
,rm AEC-427 
 
 (6/68) 
 AECM 3201 
 
 U.S. ATOMIC ENERGY COMMISSION 
 
 UNIVERSITY-TYPE CONTRACTOR'S RECOMMENDATION FOR 
 
 DISPOSITION OF SCIENTIFIC AND TECHNICAL DOCUMENT 
 
 I See Instructions on Reverse Side ) 
 
 AEC REPORT NO. 
 
 COO-2383-0010 
 
 2. TITLE 
 
 The PLW Compiler 
 
 TYPE OF DOCUMENT (Check one): 
 
 3 a. Scientific and technical report 
 
 ^ b. Conference paper not to be published in a journal: 
 
 Title of conference 
 
 Date of conference 
 
 Exact location of conference 
 
 Sponsoring organization 
 
 Qc. Other (Specify) 
 
 RECOMMENDED ANNOUNCEMENT AND DISTRIBUTION (Check one): 
 
 [3 a. AEC's normal announcement and distribution procedures may be followed. 
 
 ~2 b. Make available only within AEC and to AEC contractors and other U.S. Government agencies and their contractors. 
 ] c. Make no announcement or distrubution. 
 
 REASON FOR RECOMMENDED RESTRICTIONS: 
 
 SUBMITTED BY: NAME AND POSITION (Please print or type) 
 
 Charles W. Gear 
 
 Professor and Principal Investigator 
 
 Organization 
 
 University of Illinois 
 Department of Computer Science 
 Urbana, Illinois 6l801 
 
 Signature 
 
 Date 
 
 July, 197^ 
 
 FOR AEC USE ONLY 
 
 AEC CONTRACT ADMINISTRATOR'S "COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION 
 RECOMMENDATION: 
 
 PATENT CLEARANCE: 
 
 _J a. AEC patent clearance has been granted by responsible AEC patent group. 
 J b. Report has been sent to responsible AEC patent group for clearance. 
 U e. Patent clearance not required. 
 
5LI0GRAPHIC DATA 
 
 EET 
 
 riile and Subtitle 
 
 1. Report No. 
 
 UIUCDCS-R-7U-66U 
 
 The PLW Compiler 
 
 3. Recipient's Accession No. 
 
 5. Report Date 
 
 July, 19 7*+ 
 
 \uthor(s) 
 
 William Vanmelle and Lawrence Lopez 
 
 8. Performing Organization Rept. 
 °" UTIJHPCS-P-7U-t^U 
 
 Performing Organization Name and Address 
 
 Department of Computer Science 
 
 University of Illinois at Urban a- Champaign 
 
 Urbana, Illinois 6l801 
 
 10. Project/Task/Work Unit No. 
 
 11. Contract/Grant No. 
 
 AEC AT (11-1) 2 383 
 
 Snonsoring Organization Name and Address 
 
 US AEC Chicago Operations Office 
 98OO South Cass Avenue 
 Argonne, Illinois 60^39 
 
 13. Type of Report & Period 
 Covered 
 
 14. 
 
 Supplementary Notes 
 
 Abstracts 
 
 The PLW language and the structure of the first PLW compiler, done 
 in assembly language and FORTRAN is detailed herein; eventually the compiler 
 will be written in PLW itself. The PLW language is in many respects like 
 PL/I. The object language of the compiler is FORTRAN. Hence the compiled 
 code is, to a great extent, portable. 
 
 Key Words and Document Analysis. 17a. Descriptors 
 
 PLW 
 
 language 
 
 compiler 
 
 FORTRAN 
 
 OBJECT ■ 
 
 PORTABLE 
 
 Identifiers /Open-Ended 
 
 Terms 
 
 
 
 ' COSATI Field/Group 
 
 
 
 
 Availability Statement 
 
 
 19. Security Class (This 
 Report) 
 
 UNCLASSIFIED 
 
 21. No. of Pages 
 
 75 
 
 Unlimited 
 
 20. Security Class (This 
 Page 
 
 UNCLASSIFIED 
 
 22. Price 
 
 * NTIS-35 (10-70) 
 
 USCOMM-DC 40329-P7 1 
 
AU6 27 117* 
 
% 
 
 ' '/*, 
 
nta 
 
 mn 
 
 in 
 
 ■ 
 
 EH 
 
 mm 
 Hi 
 
 mm 
 
 Hi 
 
 m 
 
 ■ 
 
 mm 
 
 HI 
 
 Hill 
 Wmm \ 
 
 ■H 
 
 IglfiQuwnyHn 
 
 HI 
 
 HI 
 
 IH 
 
 ■1™ 
 
 MM 
 
 ■I 
 
 rami 
 
 m 
 
 991 
 JS8I II 
 
 Hi 
 
 Hi HI 
 
 mm 
 mmffl 
 
 B mm 
 
 fkWBMKa