LIBRARY OF THE 
 
 UNIVERSITY OF ILLINOIS 
 
 AT URBANA-CHAMPAIGN 
 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/proceduresintran379ozga 
 

 Report No. 379 
 
 (Ui. 
 
 Z^ 
 
 PROCEDURES IN THE TRANQUIL COMPILER 
 Martin Ozga 
 
 April 30, 1970 
 
 ILLIAC IV Document No. 209 
 
Report No. 379 
 
 PROCEDURES IN THE TRAI^UIL COMPILER^ 
 
 Martin Ozga 
 
 April 30, 1970 
 
 Department of Computer Science 
 
 University of Illinois at Urbana-Champaign 
 
 Urtana^ Illinois 618OI 
 
 ■X- 
 
 This work was supported in part by the Advanced Research Projects Agency 
 as administered by the Rome Air Development Center under Contract No. 
 USAF 30(602)-4l44 and submitted in partial fulfillment of the requirements 
 for the degree of Master of Science in Computer Science, January 1970* 
 

 ABSTRACT 
 
 A description is given of the procedure structvire in the TRANQUIL 
 compiler, which allows external and internal procedures which may or may not 
 return a single value. Also, for the benefit of those who may have to change 
 the compiler, a description is given of the current implementation. 
 
Ill 
 
 ACKNOWLEDGEiyEEM' 
 
 The author wishes to thank Professor Robert S. Northcote of the 
 Department of Computer Science, University of Illinois at Urbana-Champaign, 
 Illinois for his suggestions and criticisms on the design and implementation 
 of procedures in TRAIJQUIL, and also on the writing of this thesis. 
 
 Also, the author is indebted to Norma Abel, Paul Budnik, 
 Yoichi Muraoka, and Robert Wilhelmson for their suggestions and aid during 
 the implementation of procedures in TRANQUIL. 
 
 Finally, the author wishes to express his thanks to Mrs. Kay Flessner 
 for typing this manuscript. 
 
IV 
 
 TABLE OF CONTENTS 
 
 Page 
 
 1. INTRODUCTION 1 
 
 2. THE SPECIFICATION OF PROCEDURES IN TRAIJQUIL 5 
 
 2.1 Placement of the Procedure Declaration 5 
 
 2.2 The Procedure Heading 5 
 
 2.2.1 Simple Arithmetic and Boolean Variables 6 
 
 2.2.2 Arrays 7 
 
 2.2.3 Sets 8 
 
 2.2.4 Labels 9 
 
 2.2.5 Procedures 9 
 
 2.3 The EXTERNAL ENTRY Declaration 11 
 
 2.k The Procedure Body 12 
 
 2.U.1 General Description ' 12 
 
 2.U.2 The RETURN Statement 12 
 
 2.4.3 Use of Labels 13 
 
 2.5 External Procedure Declarations l4 
 
 2.6 ROW Procedures 15 
 
 2.7 The Procedure Call 15 
 
 3. IMPLEMENTATION I8 
 
 3.1 Pass 1 Tables I8 
 
 3.1.1 Use of IDTAB I8 
 
 3.1.2 EXTTAB 19 
 
 3.1.3 PARTAB . . , / • • • 20 
 
V 
 
 Page 
 
 3.2 Pass 2 Actions 20 
 
 3.2.1 Passing Parameters 20 
 
 3.2.1.1 Simple Arithmetic and Boolean Variables 22 
 
 3.2.1.2 Sets 22 
 
 3.2.1.3 Arrays 22 
 
 3.2.1.i+ Labels 23 
 
 3.2.1.5 Procedures 23 
 
 3.2.2 The Procedure Body 23 
 
 3.2.2.1 Returning from a Procedure 25 
 
 3.2.3 The Procedure Call 26 
 
 3.2.4 Linking Procedure Calls to Expressions 27 
 
 h. M EXTENSION 28 
 
 4.1 Introduction to Array Procedures 28 
 
 4.2 Proposed Specifications for Array Procedures 29 
 
 4.3 Applications 31 
 
 4.3.1 Mapping Functions 31 
 
 4.3.2 Input/Output 32 
 
 5. CONCLUSION 33 
 
 APPENDIX 
 
 A. THE SYNTAX OF PROCEDURES 3^ 
 
 B. SAMPLE TRANQUIL PROGRAM USHJG PROCEDURES 37 
 
 LIST OF REFERENCES 39 
 
VI 
 
 LIST OF FIGLTRES 
 
 Figiire Page 
 
 1. The relationship between Pass 1 tables for handling procedures. . 21 
 
 2. The structure of a procedure body as generated by the TRANQUIL 
 compiler . . 2U 
 
1. INTRODUCTION 
 
 TRANQUIL is a high-level algorithmic language for ILLIAC TV pro- 
 grajraning. The TRANQUIL compiler is currently being written to run on the 
 B65OO and produce ILLIAC IV assembler code which will then be input to the 
 assembler (ASK), also to run on the B65OO. The latter will output executable 
 ILLIAC IV machine code. This report describes the procedure facility in 
 TRANQUIL and assimes that the reader has a knowledge of other parts of TRANQUIL 
 (Abel, Budnik, Kuck, Miiraoka, Northcote and Wilhelmson [l] provide a good in- 
 troduction to TRANQUIL) and of ILLIAC IV. 
 
 Syntactically, TRANQUIL resembles the major block structure lan- 
 guages now in use, i.e., ALGOL and PL/1, and is particularly modelled after 
 ALGOL. In creating a procedure facility for TRANQUIL, the procedure facil- 
 ities provided in ALGOL and PL/1 have been used as a model. Since ILLIAC TV 
 is structured such that all processing elements execute the same instruction 
 in parallel, about the only difference that might be expected from the pro- 
 cedure structure of languages designed for conventional machines would be the 
 ability to return an array of values. However, since TRANQUIL arrays often 
 contain more elements than can be operated on in parallel simultaneously, 
 this would mean finding storage for the array of values. Since the same 
 effect can always be achieved by passing an array as a parameter and since, 
 in many cases, the array thus created would be immediately substituted into 
 another array thus making poor use of storage, and since the storage/ computing 
 power ratio is quite low in ILLIAC TV, such array procedures have not been 
 implemented in TRANQUIL. However, iinder certain restrictions, TRANQUIL may 
 communicate with procedures written in assembly language which return differ- 
 
ent values in each processing element. In this regard, it is interesting to 
 note that PL/1, which does allow array operations, does not allow user defined 
 functions to return more than a single value. ALGOL, of course, also does not 
 allow functions to return an array of values. 
 
 Between ALGOL and PL/1, three ways of passing parameters to proce- 
 dures may be discerned: passing parameters by value, by address, and by name. 
 When a parameter is passed by value, its value is available to the procedure, 
 but not its address. In B5500 ALGOL and System /360 PL/1, a parameter passed 
 by value causes a dummy location to be initialized to that value so that the 
 formal parameter may be manipulated within the procedure without affecting the 
 actual parameter. When a parameter is passed by address, its address is made 
 available to the procedure so that any changes in the formal parameter are re- 
 flected in the actual parameter. When a parameter is passed by name, each 
 use of the formal parameter within the procedure causes a subroutine (often 
 referred to as a thunk, see Ingerman [2]) to be called which evaluates the 
 actual parameter. In PL/1, parameters may be passed by value or by address. 
 Passing by value is implicit since it occurs whenever an expression is recog- 
 nized in the calling sequence. In ALGOL, parameters may be passed by value 
 or by name. Passing by value is explicit since certain parameters to a pro- 
 cedure may be declared in the procedure heading as being passed by value. 
 Placement of an expression in a calling sequence causes generation of a thunk 
 to evaluate that expression. In TRANQUIL parameters may be passed by address 
 or by value. Both explicit and implicit passing by value are allowed since 
 parameters may be explicitly declared to be passed by value in the procedure 
 heading or parameters may be implicitly passed by value by placing an expres- 
 sion as an actual parameter in the calling sequence. It should be emphasized 
 that only sijnple variables may be passed by value. Passing parameters by 
 
name has not been implemented in TRANQUIL since it is felt that the benefits 
 to be gained are marginal (and, in fact, passing parameters by name has been 
 known to create some bizarre error conditions in ALGOL programs) compared to 
 the difficulty in implementation and the extra execution time required to 
 evaluate the thunks on ILLIAC IV. 
 
 Another important topic is external (i.e., separately compiled or 
 assembled) procedures. PL/1 explicitly allows external procedures whereas 
 formal ALGOL and B5500 ALGOL do not. TRANQUIL does allow external procedures 
 for several reasons. First, since ILLIAC IV was not designed with TRANQUIL 
 (or any other higher level language) in mind, it is to be expected that some 
 routines may be more efficiently coded in assembly language than in TRANQUIL. 
 However, particularly in lengthy programs, users would find it too tedious to 
 code an entire program in assembly language and could, therefore, code as ex- 
 ternal procedures those routines which they consider absolutely crucial in 
 timing. The approach of formal ALGOL in allowing internal procedures to be 
 written in code other than ALGOL would not be sufficient since it is expected 
 that many of the high speed routines would be part of a subroutine library, 
 possibly maintained by different people than the users writing TRANQUIL pro- 
 grams and, therefore, it would be difficult if not impossible for each user to 
 update code procedures in his program. Another reason for having external 
 procedures is to cut down compilation time when a change is made to a long 
 program. Experience has proven that the necessity to recompile an entire 
 long program in order to insert even a small change, as must be done in B5500 
 ALGOL, is highly undesirable. Since the TRANQUIL compiler will, due to the 
 complex analysis which must be performed in order to make efficient use of 
 the parallelism of ILLIAC IV, run. more slowly than many compilers, the bene- 
 fits derived from being able to break a TRANQUIL program into several inde- 
 pendently compilable procedures should be quite substantial. 
 
h 
 
 Finally, there is the question of recursion. ALGOL allows all pro- 
 cedures to be recursive. PL/1 allows only procedures which have the attribute 
 "recursive" to be recursive. In B5500 ALGOL, recursion is quite easy to mple- 
 ment due to the stack structure of the machine. In System/360 PL/1, recursion 
 involves pushing back all core used by the procedure for data with an appro- 
 priate pointer so that it may be recalled and recursion is, therefore, very 
 time consuming. In TRANQUIL recursion is not allowed, at present, due to stor- 
 age allocation problems and the extra execution time which would be required 
 to keep track of either a programmed stack or links to blocks of storage from 
 earlier calls to the procedure. 
 
 In summary, then, the procedure facility in the TRANQUIL compiler 
 allows typed (returning a single value) and non-typed procedures. Procedures 
 may be external or internal (to the main program). External procedures may 
 be written in TRANQUIL, or ASK, or any other language which is now, or may in 
 the future be, implemented for ILLIAC IV, provided that TRANQUIL conventions 
 are followed. Any type of variable allowed in TRANQUIL may be passed as a 
 parameter, i.e., parameters may be simple variables (arithmetic or boolean), 
 arrays, sets, labels, switches, or procedures. Of these, simple arithmetic 
 and boolean variables, may be passed either by value or by address while the 
 others may be passed by address only. Recursion and passing parameters by name 
 are not implemented. 
 
2. THE SPECIFICATION OF PROCEDURES IN TRANQUIL 
 
 2.1 Placement of the Procedure Declaration 
 
 As in ALGOL, a procedure is considered to be a declaration. Since 
 TRANQUIL has the same block structure as ALGOL, internal TRANQUIL procedures 
 must be placed in a block head. Also, a procedure declaration, or an EXTER- 
 NAL ENTRY declaration, must occur before any call on that procedare. A dec- 
 laration for an internal procedure consists of the procedure heading followed 
 by the procedure body. The procedure heading contains the specification for 
 the parameters while the procedure body consists of a block (which, of course, 
 may contain nested blocks) of code which is to be executed when the procedure 
 is invoked. The declaration for an external procedure consists of optionally 
 listing the type of the procedure (if it is to return a value) along with the 
 specification of the parameters. Since it is not possible to access an ex- 
 ternal procedure at compile time to determine agreement between actual and 
 formal parameters, the agreement is checked and the proper call is set up by 
 checking the declaration (known as an EXTERNAL ENTRY declaration) which occurs 
 in the calling program. In order to create an external procedure written in 
 TRANQUIL, the entire TRANQUIL program is set up as an EXTERNAL PROCEDURE dec- 
 laration (not to be confused with an EXTERNAL ENTRY declaration) which is 
 simply a procedure declaration preceded by the word "EXTERNAL." 
 
 2.2 The Procedure Heading 
 
 The procedure heading consists of specifying the name of the pro- 
 cedure, its type (if it returns a value), and the names and types of the para- 
 meters, if any. For example, a procedure P which returns a REAL (6U-bit 
 floating point) value and has no parameters would have the heading: 
 
REAL PROCEDURE P; 
 If P did not return a value it would have as a heading simplj: 
 
 PROCEDURE P; 
 The parameter specifications are quite similar to the declarations 
 for the same type of variables. They will now "be described for the various 
 types of variables which may be passed as parameters. 
 
 2.2.1 Simple Arithmetic and Boolean Variables 
 
 The specifications for simple arithmetic and boolean variables are 
 exactly the same as the declarations for these kinds of variables. These vari- 
 ables may be passed by value in which case the interpretation, as in B5500 
 ALGOL, is that a local variable in the procedure is initialized to the value 
 of the actual parameter but may then be changed arbitrarily by computations 
 within the procedure without affecting the actual parameter. The VALUE 
 specification is the same as in ALGOL, namely, "VALUE" followed by the identi- 
 fier list. If VALUE specifications are used, they must appear before all other 
 specifications in the procedure heading. 
 
 If the formal parameter is boolean, then the actual parameter must be 
 a boolean expression or a boolean variable. If the formal parameter has an 
 arithmetic type (i.e., REAL, INTEGER, etc.), then the actual parameter must be 
 an arithmetic variable or an arithmetic expression returning a single value. If 
 the actual and formal parameters disagree as to arithmetic types, then type 
 conversion will be performed on entry to the procedure and, in the case of call 
 by address, type conversion in the opposite direction will be performed on exit 
 from the procedure in order to return the updated value of the variable in the 
 form required by the attributes of the actual parameter in the calling block. 
 
7 
 
 If axi expression (arithmetic or boolean) is passed by address, then 
 the parameter, for that one particular call, is treated as being passed im- 
 plicitly by value and is handled in the same fashion as if it were explicitly 
 passed by value. At present an array element given as the actual parameter 
 for an arithmetic formal parameter is treated as an arithmetic expression and 
 is, therefore, implicitly passed by value. 
 
 As an example of a procedure heading using boolean and arithmetic 
 variables, consider: 
 
 PROCEDURE VTEST (A, B, C, D); 
 
 VALUE B, C; 
 
 INTEGER A, C; BOOLEAN B; REAL D; 
 
 The procedure VTEST is a non-typed procedure with four parameters. A, B, C, 
 D of which two, B and C, are passed by value. A and C are handled as type 
 INTEGER within the procedure, B as type BOOLEAN and D as type REAL. If the 
 actual parameters corresponding to A, C, or D are of a different arithmetic 
 type, type conversion will be performed at the procedure call. 
 
 2.2.2 Arrays 
 
 Arrays may be passed by address only. The formal and actual para- 
 meter arrays must agree as to mapping function, type, and number of dimensions. 
 In specifying an array in the procedure heading, the mapping function, formal 
 parameter identifier, and dimension information must be given. The dimension 
 information may, for each dimension, be either an asterisk ("■>«■") or an integer. 
 If an asterisk is used, then the formal parameter array takes on the same lower 
 bound in the corresponding dimension as the actual parameter array. If an 
 
integer is used, then the formal parameter array, in that dimension, takes on 
 the given integer value as the lower bound. In either case, the size of each 
 dimension remains the same in the formal parameter array as in the actual par- 
 ameter array. Also, in the specification of any one array, the use of aster- 
 isks and integers may be mixed in any fashion. 
 For example, if 
 
 PROCEDURE ATEST (A, B, C); 
 REAL SKEWED ARRAY A[*, *, *]; 
 INTEGER STRAIGHT ARRAY B[10, *]; 
 REAL STRAIGHT ARRAY C[3]; 
 
 is written, then the procedure ATEST has three parameters. The first para- 
 meter (a) is a three dimensional REAL SKEWED array, all of the dimensions of 
 which are to have the same lower bound as in the actual parameter array. The 
 second parameter (b) is a two-dimensional INTEGER STRAIGHT array. The first 
 dimension is to have a lower bound of 10, regardless of the first dimension of 
 the actual parameter array, but will have the same size as the first dimen- 
 sion of the actual parameter array. The second dimension will have the same 
 lower bound as the actual parameter array. The third parameter (C) is a one- 
 dimensional REAL STRAIGHT array and that one dimension will have a lower bound 
 of 3. 
 
 2.2.3 Sets 
 
 Sets passed as parameters must agree as to type of set and nimiber 
 of dimensions (the present implementation supports only one-dimensional sets, 
 
however). Sets may be passed by address only. In the example: 
 
 PROCEDURE STEST (Sl, S2, S3); 
 INCSET SI; 
 GENSET S2; 
 MONOSET S3;, 
 
 the procedure STEST has three parameters, the first being an INCSET, the 
 second a GENSET, and the third a MONOSET. 
 
 2.2.U Labels 
 
 Labels may be passed as parameters. The only requirement on the 
 actual parameter is that the label be defined at the point of procedure call. 
 The action on transferring to a label passed as a parameter is to jump to the 
 end of the procedure, then to the point of call, and finally to the specified 
 label. For example, in 
 
 PROCEDUEE LTEST (L1); LABEL LI; 
 
 the procedure LTEST is an untyped procedure with one parameter, a label. 
 
 2.2.5 Procedures 
 
 Procedures may be passed as parameters to other procedures. Unlike 
 the\ case in ALGOL, the parameters of a proced\ire passed as a parameter must 
 be fully specified. The fomial and actual parameter procedures must agree as 
 to type (if they are both typed procedures), or both must be untyped pro- 
 cedures, and both must have the same number of parameters. In addition, the 
 
10 
 
 parameters to the actual and formal parameter procedures must agree. That is, 
 if a parameter in one is an arithmetic simple variable, then the corresponding 
 parameter in the other must be a simple arithmetic variable of the same type. 
 If the parameter to one is a boolean variable, then the parameter to the other 
 must also be a boolean variable. In addition, in the case of simple arithmetic 
 and boolean variables, if the parameter in one of the procedure parameters is 
 specified by VALUE, then the parameter in the other must also be specified by 
 VALUE. In the case of arrays, the parameters must agree as to mapping func- 
 tions, type, and number of dimensions. For sets, the parameters must agree 
 as to type of set. For labels or switches, both parameters must be either 
 labels or switches, respectively. For procedures, the parameters must agree 
 as to type (or be both untyped) and, in addition, the parameters of the two 
 must agree as outlined above. 
 
 In specifying the parameters of a procedure passed as a parameter, 
 the attributes only (not identifier names since these are given in the heading 
 of the actual parameter procedure) are listed in parentheses following the 
 name of the procedure. If the procedure which itself is a parameter has 
 another procediire as a parameter, then the attributes of the parameters of 
 the latter procedure are listed in parentheses following the word "PROCEDURE." 
 
 Consider, for example, the following procedure heading: 
 
 PROCEDURE PTEST (Pl, P2); 
 
 REAL PROCEDURE PI (VALUE REAL, INTEGER, 
 INCSET, REAL SKEWED ARRAY [*, *]); 
 
 IIWEGER PROCEDURE P2 (BOOLEAN, 
 PROCEDURE (real)); 
 
11 
 
 Here, procedure PTEST has two parameters, PI and P2. PI is a REAL procedure 
 which has four parameters. The first is of type REAL passed by value. The 
 second is INTEGER passed by address. The third is a set which is defined as 
 an INCSET (increment set). The fourth is a two-dimensional REAL SKEWED array 
 (note that only "*" is used to describe a dimension. If an integer is to 
 appear as the lower bound, it will appear in the procedure heading of the 
 actual parameter procedure) . The second parameter of PTEST is P2, an INTEGER 
 procedure. The first parameter of P2 is a BOOLEAN variable and the second 
 parameter is an untyped procedure which has a single parameter, a REAL simple 
 variable. 
 
 2.3 The EXTERNAL ENTRY Declaration 
 
 When an external procedure is to be called from a TRANQUIL program, 
 an EXTERNAL ENTRY declaration which specifies the type both of the procedure 
 (if the external procedure is to return a value) and the parameters must be 
 provided. The parameters are specified in exactly the same fashion as for a 
 procedure passed as a parameter (see Section 2.2.5 above), only the attributes 
 of the parameters, in parentheses, follow the procedure identifier in the 
 EXTERNAL ENTRY statement. The agreement between formal and actual parameters 
 is the same as for any other proced\ire. 
 
 As an example, consider 
 
 EXTERNAL INTEGER ENTRY ETEST (REAL, 
 VALUE INTEGER, REAL STRAIGHT ARRAY [*,*], 
 INCSET) ; 
 
12 
 
 Then the program in which the above declaration occiirs will expect to have 
 access to an external procedure ETEST which has foiir parameters, a REAL para- 
 meter passed by address, an INTEGER parameter passed by value, a two dimen- 
 sional REAL STRAIGHT array, and an INCSET. 
 
 2.4 The Procedure Body 
 
 2.U.1 General Description 
 
 The procedure body is a TRANQUIL block, if it is programmed in TRAIT- 
 QUIL- The parameters are treated as being declared in a block external to the 
 procediore body (and are, therefore, global to the procedure body) but internal 
 to the block in which the procedure declaration resides (so that the para- 
 meters may not be used anywhere outside the procedure) . Therefore, in partic- 
 ular, identifier names the same as those of the parameters may be redeclared 
 in a block internal to the procedure and, when used in that block, will be 
 accessed as variables local to that block rather than as parameters to the 
 procedure which contains that block. In other respects, the body of a TRAJNIQUIL 
 procedure is like any other block in a TRAUQUIL program with the exception of 
 the use of the RETURN statement and jumping to labels, in certain cases. 
 
 2.U.2 The RETURN Statement 
 
 The RETURN statement is used to exit from a procedure. If a value 
 is to be returned, then the RETURN statement must be used to return the value. 
 If no value is to be returned, then the use of the RETURN statement is optional 
 since a procedure is also exited when the flow of control passes through the 
 end of the procedure body. RETURN statements may occur anywhere in a procedure 
 body and any number of RETURN statements may be used. 
 
13 
 
 In order to return a value from a procedure, the value (which may be 
 a constant or an expression which returns an appropriate value) is placed in 
 parentheses following the word "RETURN"." Execution of such a RETURN statement 
 causes an exit to be made from the procedure body and the value generated to 
 be the value returned from the procedure. 
 
 A RETURN with value may be used only in a typed procedure and the 
 value returned must be arithmetic if the type of the procedure is arithmetic 
 and boolean if the type of the procedure is boolean. An arithmetic value is 
 converted to the type of the procedure if it is not already that type. A 
 RETURN without a value may be made from a typed procedure, in which case a 
 default of zero is assigned if the type of the procedure is arithmetic and 
 FALSE is assigned if the type of the procedure is boolean. 
 
 As an example, the statement 
 
 RETURN (A+B); 
 
 causes exit to be made from a procedure and the value of A+B to be returned. 
 The statement 
 
 RETURN; 
 
 causes exit to be made from a procedure without returning any value and thus 
 may be used in a typed or untyped procedure. 
 
 2.U.3 Use of Labels 
 
 Within a procedure, transfer may be made to other labels also within 
 the procedure body, subject to the usual rules and restrictions for TRANQUIL 
 
lU 
 
 programs. However, transfer may not be made to a label occurring outside the 
 procedure body unless that label is passed as a parameter to the procedure 
 and the label is accessible at the procedure call. 
 
 2 . 5 External Procedure Declarations 
 
 An EXTERNAL PROCEDURE declaration is sijnply a procedure declaration 
 preceded by the word "EXTERNAL." An external procedure is intended to permit 
 separate compilation (and assembly) from other TRANQUIL programs. Therefore, 
 the heading for the external procedure must be the first compilable code sub- 
 mitted to the TRANQUIL compiler when an external procedure is desired and an 
 EXTERNAL PROCEDURE declaration may, therefore, occur at most once in a single 
 compilation (this should be distinguished from the EXTERNAL ENTRY declaration 
 which may occur as often as desired and may occur wherever a declaration is 
 permitted) . In all other respects, an external procediore is like an internal 
 procedure. 
 
 As an example, consider the following trivial EXTERNAL PROCEDURE 
 declaration. 
 
 EXTERNAL INTEGER PROCEDURE ETEST (A,B); 
 VALUE A, B; INTEGER A, B; 
 BEGIN 
 
 RETURN (A+B); 
 END. 
 
 Procedure ETEST would return the integer sura of its two integer parameters. 
 Procedure ETEST would be separately compiled from the calling program, which 
 may not even be written in TRANQUIL. 
 
15 
 
 2.6 ROW Procedures 
 
 Row procedures are a special type of external procedure which must 
 be written In ASK. The function of a row procedure Is to take values In RGA, 
 perform some computation on these values, and return the result to RGA. The 
 returned results should occur only In those PE's which were enabled at the 
 time of the call and the setting of the mode bits should thus be the same at 
 the return as at the call. A row procedure has a single parameter, which is 
 specified as a simple arithmetic variable (in order to allow type conversion). 
 The chief use of row procedures will be to do parallel computations on arrays 
 within SIM loops. 
 
 The EXTERNAL ENTRY declaration for a ROW procedure is like the 
 EXTERNAL ENTRY declaration for any other procedure except that the word "ROW" 
 precedes the word "ENTRY." A ROW procedure should be typed in order that 
 proper conversion may be performed on the returned values. For example, 
 
 EXTERNAL REAL ROW ENTRY RTEST(REAL); 
 
 RTEST is then assumed by the calling program to be a ROW procedure which 
 operates on real values from RGA in all enabled PE's and returns (computed) 
 real values in RGA in these same PE's, while not changing other PE's or 
 the mode bit setting. 
 
 2 -7 The P roced\ire Call 
 
 As in ALGOL, the procedure call consists of the name of the pro- 
 cediire followed by the list of actual parameters, in parentheses. If there 
 are no actual parameters, then the procedure call consists simply of the 
 
16 
 
 procedirre Identifier. The number of formal and actual parameters must be the 
 same. Additional required agreements for various kinds of parameters are as 
 specified in Section 2.2 above. 
 
 If the formal parameter is an arithmetic simple variable, then the 
 actual parameter may be an expression returning a single arithmetic value. 
 If the formal parameter is a boolean variable, then the actual parameter may 
 be an expression returning a single boolean value. In all other cases, the 
 actual parameter must be an identifier and its specifications must agree with 
 those of the corresponding formal parameter. 
 
 A procedTore call (except to a ROW procedure which should be used in 
 an expression within a SIM loop) may occur as a distinct statement whether or 
 not the procedure is typed (if the procedure is typed, the value returned will 
 be lost). In addition, a call to a typed procedure returning an arithmetic 
 value may appear in an arithmetic expression and a call to a typed procedure 
 returning a boolean value may appear in a boolean expression. Any other com- 
 bination of type of expression and type of procedure is not permitted. 
 
 Consider, for example, the procedure heading 
 
 INTEGER PROCEDURE CTEST(A, B); 
 REAL A; INCSET B; 
 
 Let X and Y be declared as REAL simple variables and let J be an IWCSET. 
 Then the following two statements represent permissible calls to procedure 
 CTEST : 
 
 X: = CTEST.(X+Y,J); 
 CTEST(X,J); 
 
17 
 
 In the second case, the value of CTEST is lost, but side effects may have 
 occurred. 
 
18 
 
 3 . IMPLEMENTATION 
 
 This section is intended primarily to document actual work done on 
 the TRANQUIL compiler for the benefit of those who may have occasion to modify 
 those portions of TRANQUIL concerned with procedures. However, certain parts 
 of Section 3-2 dealing with PASS 2 implementation will be useful to persons 
 writing programs in other languages which will commiinicate with TRANQUIL pro- 
 grams via the EXTERNAL PROCEDURE facility. Finally, as a brief clarification 
 of what has been said here, the TRANQUIL compiler is basically divided into 
 two passes [3]* In the first pass, the source code is parsed, tables are 
 built up, and the intermediate language code (which is far simpler than the 
 source code) is generated. The second pass reads the intermediate language 
 code and takes actions on the various operators, using also the tables con- 
 structed in the first pass, to generate assembly code. 
 
 3.1 Pass 1 Tables 
 
 3.1.1 Use of IDTAB 
 
 Two principal new tables, PARTAB and EXTTAB, have been created in 
 the TRANQUIL compiler for use in handling procedures. In addition, the already 
 existing table IDTAB is used. IDTAB is used (in connection with procedures) to 
 provide an entry for each type of variable (procedure identifiers or para- 
 meters) for which the user supplies a name and thus allows TRANQUIL to access 
 the correct entry every time that the name appears within a program. EXTTAB 
 is used to save the name assigned by the user to an EXTERNAL PROCEDURE or 
 EXTERNAL ENTRY identifier so that this name may be used during assembly code 
 
19 
 
 generation in PASS 2. The external name will be needed, of course, so that 
 the loader may properly link together the various segments to make the com- 
 plete program required by the user. PARTAB is used to store parameter infor- 
 mation for parameters which are not assigned names. These parameters may 
 occur in two places: the EXTERNAL ENTRY declaration and, within the procedure 
 heading, as the parameters of a procedure passed as a parameter. 
 
 For any given procedure identifier, there is a field in its IDTAB 
 entry known as NPARS or PARPTR (this is one field, but the name used in the 
 coding depends on the usage of the field) . There are also two one bit fields 
 which are of interest here, EXTERML and PARAM. One or neither (but not both) 
 of these bits may be set in the IDTAB entry for a procedure. If the EXTERML 
 bit is set, then the PARPTR field points to EXTTAB. If the PARAM bit is set, 
 the PARPTR field points to PARTAB. If neither of these bits is set, then the 
 field is known as NPARS and it contains a value for the number of parameters 
 each of which will have an entry in IDTAB since, in this case, the user will 
 have assigned an explicit name to each formal parameter. 
 
 3.1.2 EXTTAB 
 
 The table EXTTAB is used to hold the external (user assigned) name 
 so that it may be output during PASS 2 generation of assembly code. The 
 lengths of entries in EXTTAB vary depending on the length of the external 
 name, but all entries are at least two words long. The first word of each 
 entry contains the number of characters in the external name, a pointer to 
 the first word in the next entry in EXTTAB, and a pointer to PARTAB. Entries 
 in EXTTAB always end on a word boundary with any extra characters in the last 
 word being filled with trailing blanks. 
 
20 
 
 3.1.3 PARTAB 
 
 The table PARTAB, as mentioned before, is used to hold parameter 
 information for parameters which are given attributes only (instead of ex- 
 plicit names) by the user. The type of information stored varies with the 
 type of parameter (set, array, etc.) and is similar to the information stored 
 in IDTAB for the same tjrpe of variable except that only sufficient infonnation 
 is stored to allow complete comparison between formal and actual parameters. 
 
 However, since procedures used as parameters may themselves have 
 procedures as parameters and since the parameters of the latter procedures 
 must also be completely specified, PARTAB must, in that case, have a tree 
 structure. Since the tree, once set up, is not changed and since traversal 
 is always top down, a sequential structure devoid of any threads or other 
 backward pointers is sufficient. However, for convenience, at each entry for 
 a procedure a pointer to the next parameter on the same level as the procedure 
 is maintained (the pointer is zero if the procedure is the last parameter). 
 
 The first word of an entry in PARTAB is a control word. This word 
 contains the number of first level parameters (allowing the check on number of 
 parameters to be made before the parameters are actually compared) and also 
 the number of words in the entry and a pointer back to the IDTAB entry which 
 points to the PARTAB entry, either directly or through EXTTAB. 
 
 3.2 Pass 2 Actions 
 
 3.2.1 Passing Parameters 
 
 Standard methods, as specified in the operating system, are to be 
 used in passing parameters and in addressing parameters in procedures. There- 
 
21 
 
 u 
 <u 
 -p 
 
 •H 
 
 O 
 
 ft 
 
 >3 
 
 <V -P 
 
 EH 
 
 ^ 
 
 
 o 
 
 
 Ch 
 
 
 >> 
 
 0) 
 
 -p 
 
 ^ 
 
 C! 
 
 •n 
 
 
 
 d) 
 
 
 V 
 
 9 
 
 o 
 
 M 
 
 ft 
 
 M 
 
 
 H 
 
 aJ 
 
 4«i 
 
 QJ 
 -P 
 
 •H 
 O 
 ft 
 
 W 0) 
 
 ^ b 
 
 <U P M 
 
 -P Ti -H 
 
 0) 
 
 a o ^ q; 
 
 c3 O o 
 
 CD ft^ 
 
 ft 15 
 
 <=- o 
 
 -p 
 
 Ph 
 
 I 
 
 l>5 
 
 -p 
 
 0) 
 
 o 
 
 w 
 •H ^ 
 
 CO (P w 
 
 rQ 'd -p 
 
 a in a 
 
 p O 0) 
 
 fl IS 
 
 CD 
 
 ft 
 
 lM»4 
 
 OJ 
 
 ft 
 
 0) 
 (U P 
 0) <D 
 
 c3 o 
 
 3 ft 
 ft 
 
 %*•! 
 
 P> 
 
 ft 
 
 O Tli 
 
 QJ 
 ■P 
 
 •H 
 O 
 ft 
 
 -P 0) 
 X -P 
 (D CD 
 
 H 
 H 
 
 CO Eh 
 K Ph 
 
 CM <; p:^ <; S 
 
 WXEhWcc;^<JhJ) 
 
 •d 
 
 0) 
 
 o 
 o 
 u 
 ft 
 
 tiD 
 •H 
 
 o 
 
 <H 
 
 CO 
 
 CO 
 H 
 
 -P 
 
 w 
 05 
 P^ 
 
 a 
 a) 
 
 -p 
 
 CD 
 
 ft 
 •H 
 
 CO 
 
 si 
 o 
 
 •H 
 -P 
 05 
 H 
 (U 
 ^ 
 
 
 
 EH 
 
22 
 
 fore, anyone writing a program in some other language which calls a procedure 
 written in TRANQUIL or anyone writing an external procedure in another lan- 
 guage and wishing this procedure to be called by a program written in TRANQUIL 
 must adhere to the operating system conventions (at the time of this writing, 
 these conventions have not been completely specified) . In addition, to co- 
 ordinate a program in another language with a TRANQUIL program, one should be 
 aware of what is passed for each type of parameter. Only one word of informa- 
 tion need be passed for each parameter; this infoirmation will now be described 
 in detail. 
 
 3.2.1.1 Simple Arithmetic and Boolean Variables 
 
 If passed by address, the address within ILLIAC IV memory of the 
 simple variable is passed. If passed by value, the value of the simple vari- 
 able is passed. In addition, for each parameter passed by value, a bit is 
 set in the value word (see 3'2.3 for further discussion on the value word). 
 
 3.2.1.2 Sets 
 
 For a set, the pointer to the set descriptor table location for the 
 set is passed. Briefly, this table, which resides in ILLIAC IV memory, con- 
 tains a pointer to the area where the set is stored and indicates whether this 
 area is in SBLOCKORIGIN or MGSAFE. For further discussion on set structure, 
 reference should be made to Wilhelmson's thesis [h] . 
 
 3.2.1.3 Arrays 
 
 For an array, an array descriptor is set up and passed as a para- 
 meter. This array descriptor contains two 2U-bit fields, stored in the least 
 
23 
 
 significaxit portion of the ILLIAC IV word. The first (most significant) of 
 these fields contains a pointer to DOPETB (a run-time table which contains 
 infonnation about the number and size of dimensions of the array) and the 
 second field contains a pointer to BASETB (a run-time table which contains 
 pointers to the actual locations where the array blocks are stored). Muraoka's 
 thesis [5] gives more information about DOPETB and BASETB. 
 
 3.2.1.4 Labels 
 
 For a label, nothing is passed since a procedure indicates that it 
 is jumping to a label by setting appropriate bits in certain ADB locations, 
 as described in Section 3 -2.2 below. 
 
 3«2.1.5 Procedures 
 
 When a procedure is passed as a parameter, the address of the pro- 
 cedure (i.e., the address at which the executable code for the procedure 
 begins) is passed. 
 
 3.2.2 The Procedure Body 
 
 The entire procedure body is treated as a separate block. In addi- 
 tion, subblocks, as created by the user, are formed. Any block which the user 
 forms within the procedure occurs as a subblock of the procedure block. 
 
 In forming a procedure body, code is first generated to copy para- 
 meters, or pointers to them, from the calling sequence into local areas in 
 the body. Then code is generated which translates the user's TRANQUIL source 
 statements. Finally, code is generated to copy back parameters if necessary. 
 The copying of parameters into local areas is required due to the lack of 
 
2k 
 
 PROCEDURE- 
 BLOCK 
 BEGINS 
 
 PROCEDURE ■ 
 
 BLOCK 
 
 ENDS 
 
 AREA TO COPY PARAMETERS 
 INTO AREAS LOCAL TO THE 
 PROCEDURE 
 
 TRANSLATION OF BODY OF 
 PROCEDURE AS SPECIFIED 
 BY THE USER INTO 
 ASSEMBLY CODE 
 
 AREA TO COPY PARAMETERS 
 FROM AREAS LOCAL TO THE 
 
 ) PROCEDURE BACK TO THE 
 
 ( CALLING PROGRAM 
 
 
 Figure 2. The structure of a procedure body as 
 generated by the TRANQUIL compiler 
 
25 
 
 indirect addressing facilities in ILLIAC IV. Then, in order to pass para- 
 meters by address and thus obtain new values, certain parameters must be 
 copied back. To be specific, for a simple variable, the value is copied in- 
 to a local area; and, if the parameter is passed by address, the value is 
 copied back at the end of the procedure. For a set, the pointer to the set 
 descriptor table is copied into a local area at the beginning of a procedure 
 and copied back at the end of a procedure. For an array, the array descrip- 
 tor is copied into a local area at the beginning of a procedure, but is not 
 copied back since the information it contains is not subject to change. For 
 other types of parameters, no copying is required. 
 
 3'2.2.1 Returning from a Procedure 
 
 There are three ways in which a return may be made from a TRANQUIL 
 procedure: execution of a RETURN statement, jumping to a label passed as a 
 parameter, and causing the execution to run off the end of a procediire. How- 
 ever, before retiirn can be made, the extra portion of code inserted by the 
 compiler at the end of a procedure (see 3*2.2 above) must be executed. This 
 will, of course, occur automatically when the execution stream goes to the 
 end of a procedure. In the case of a RETURN statement or a jump to a label 
 passed a^ a parameter, a jump must first be made to the extra code at the end 
 of the procedure and, at the same time, information must be saved as to the 
 type of return made for use by the calling program. 
 
 Two locations in the ADB are, therefore, set aside for return infor- 
 mation. These are known as RETURNLDB and RETURNLDBl. Only two bits are used 
 in RETURNLDBl: the LABELRETURNBIT and the VALURETURNBIT . If the LABELRETURN- 
 BIT is set, then RETURNLDB will have a bit set according to which number 
 
26 
 
 parameter the label is. Thus, the calling program need only check RETURNLDB 
 to see if a value has been returned or a jump to a label made and taJte the 
 appropriate action using information stored in RETURNLDBl. 
 
 3.2.3 The Procedure Call 
 
 When calling a procedure, the parameter information is stored in an 
 area known as the parameter block which immediately follows the procediore call 
 and is then addressed relative to the parameter block. The first word of the 
 parameter block is the value word which contains one bit for each parameter 
 (thus limiting the number of parameters of any procedure to 6^ in the current 
 implementation). If the bit is set, the parameter is passed by value. For 
 each parameter which is declared as being passed by value in the procedure 
 heading, the corresponding bit is set. In addition, if an actual parameter 
 corresponding to a call by address formal parameter is an expression, then the 
 corresponding bit is set, thus allowing implicit call by value as described 
 above. 
 
 The parameter block then consists of n + 1 words, where n is the 
 niimber of parameters. The parameter information (as described in Section 3 -2.1 
 above) for the i-th parameter is placed in the i-th parameter word following 
 the value word. When an expression is encountered (corresponding to a simple 
 arithmetic or boolean formal parameter), the expression is evaluated using 
 routines built into the TRANQUIL compiler to handle assignment statements and 
 the result is placed in the appropriate word in the parameter block. 
 
 Certain changes may be required in the above scheme as work on the 
 operating system progresses in order to fully coordinate TRAI^QUIL with the 
 operating system. Also, should it be deemed necessary, it woiiLd be relatively 
 
27 
 
 easy to increase the limit on the number of parameters by forming an additional 
 value word. An area to evaluate the information returned by the procedure 
 follows the procedure call and the parameter block. First, the LABELRETURNBIT 
 bit in RETURNLDBl is checked. If the bit is reset, then the entire label area 
 is skipped. Otherwise, the bits which may correspond to labels are checked in 
 succession until one is found set and a jump to the appropriate label is made. 
 If the VALUEETUKNBIT bit in RETURNLDBl is set, then the value is loaded from 
 RETURMjDB to RGA of all PE's to be used in the expression (if any) in which 
 the procedure call resides. 
 
 3.2.4 Linking Procedure Calls to Expressions 
 
 In order to allow procedure calls (to typed procedures) to be em- 
 bedded in expressions and in order to allow general expressions (including 
 proced-ure calls) to appear as parameters, what is essentially the ILCODE 
 (intermediate language code) for the entire procediire call is pushed into 
 array ARITHSTACK and then, at the end of the statement, is evaluated in 
 procedure EXEC2GC so that the innermost expressions are evaluated first. Es- 
 sentially the same scheme, with minor changes, works for ordinary procedures 
 in statements not imder SIM control and also for ROW procedures in statements 
 under siM control. Budnik's thesis [3] contains further details of this 
 scheme for handling exi)ressions. 
 
28 
 
 h. M EXTENSION 
 
 k.l Introduction to Array Procedures 
 
 On conventional machines, most algebraic compilers have procedures 
 or subroutines which are capable of returning a single ,^lue. Since ILLIAC 
 IV is intended to be a parallel array-processing machine, it would seem 
 logical to have, in TRANQUIL, procediires which would be capable of returning 
 an entire array of values. ROW procedures, in very restricted cases, have 
 this capability but they return only a row of values (i.e., across 64 or less 
 PE's) and must be written in assembly language. 
 
 However, array procedures present some special problems. The first 
 of these is a storage problem for the resultant array. When a single value 
 is returned, a single word or register may be used to store the value. In a 
 single quadrant ILLIAC IV, it could be reasonably assumed that up to 6k values 
 could be returned in this fashion by using a designated register in each PE or 
 by setting aside a designated row of PE memory exclusively for values retiirned 
 from the procedure. Such methods would be fine if TRANQUIL were a row language, 
 but it is not. For array procedures to be meaningfiol in TRANQUIL, the arrays 
 which are returned must be general and must correspond to arrays which may be 
 declared in TRANQUIL programs. The storage problem then arises since ILLIAC 
 rv memory is rather small in comparison with some of the arrays which are 
 expected to occur in various applications. Additional arrays, to be associated 
 with procedures, would fill up memory even more. A good fast overlay scheme 
 would allay many of these difficulties and perhaps make it possible to imple- 
 ment array procedures in a reasonable fashion. Users of TRANQUIL would, no 
 doubt, find array procedures very convenient, particularly when dealing with 
 
29 
 
 array operations. Some additional uses for array procedures will be presented 
 later. 
 
 k.2 Proposed Specifications for Array Procedures 
 
 Since array procedures are both arrays and procedures, their speci- 
 fication must contain both array and procedure information. The array infor- 
 mation would consist of type of array, mapping function, and nijmber and 
 bounds of dimensions. The proced\ire information would consist of parameter 
 specifications and, of course, the procedure body. 
 
 However, to give greater freedom, a distinction could be made be- 
 tween two types of array procedures, STATIC and DYMMIC. The difference be- 
 tween the two is that the bounds on each dimension of a STATIC procedure are 
 fixed at the declaration whereas the bounds for a DYNAMIC procedure are dif- 
 ferent at each procedure call and, if specified by variables, may, in fact, 
 change every time the procediire call is executed. Therefore, the array asso- 
 ciated with a STATIC array procedure would be exactly like any other array 
 declared in the TRANQUIL program and the block with which this array would be 
 associated would, of course, be the block in which the procedure declaration 
 appeared. On the other hand, the DYTMMEC array size changes after each pro- 
 cedure call and the array as such does not come into existence until a pro- 
 cedure call is executed. For the DYKAMIC array, the mapping function and 
 number of dimensions does not change. 
 
 As an example, consider the following first part of the specification 
 of a STATIC array procedure : 
 
 STATIC REAL SKEWED ARRAY PROCEDURE P(A) [0:10, 1:6^+]; 
 
30 
 
 This indicates that P is an array procedure with one parameter A (the para- 
 meter A would be specified as elsewhere in TRANQUIL and so does not concern 
 us here) and that the array associated with the procedure is a REAL SKEWED 
 array of two dmensions, the first of which is 11 long aad the second 6U. If 
 P is to be a DYNAMIC procedure, then the declaration is: 
 
 DYNAMIC REAL SKMED ARRAY PROCEDURE P(A) [*,*]; 
 
 which is the same as above except that the bounds of the dimensions must be 
 specified in the calling statement. 
 
 Since an array procedure, when called, would generate an entire 
 array of values in memory, it would seem wasteful not to have this array avail- 
 able for use after the statement in which the array procedure occurred. How- 
 ever, the problem then arises of being able to syntactically distinguish be- 
 tween a call to the procedure and a use of the array. A possible way to do 
 this would be to use the word "CALL" to indicate a procedure call which would 
 fill up the array and then to use the procedure name in following statements 
 just as one would use any other array. For instance, for the array procedure 
 P, if declared STATIC as in the first example above, we could write: 
 
 CALL P(X); 
 Z: = P[l, 2]; 
 
 noting that the parameter appears in the CALL but not in the use of the array. 
 
 When a DYNAMIC array procedujre is called, additional information 
 must be supplied in order to give the bounds of the dimensions for this partic- 
 
31 
 
 ular call. The most obvious method is to specify the bounds in the call. 
 Thus, if P is the DYNAMIC array procedure from the second example above, we 
 could write: 
 
 GALL P(X) [l:10,l:6i+]; 
 
 where, of course, arithmetic expressions could also be used in the brackets 
 with the understanding that the array take the bounds determined by evaluating 
 the arithmetic expression(s) before the procedure call occurs. Another in- 
 teresting possibility would be to have the bounds take on the bounds of some 
 other array. This could be specified by writing: 
 
 CALL P(X) (b); 
 
 where B is some two dimensional array, and the second set of parentheses pro- 
 vides a convenient method for signalling the parser that an array identifier 
 is being used to supply the bounds as opposed to an array element appearing 
 in some arithmetic expression. 
 
 k.3 Applications 
 
 U.3.1 Kapping Functions 
 
 An interesting application of array procedures would be for use in 
 creating non-standard mapping functions for special applications. It is well 
 known that, for various problems, maximum efficiency of use of ILLIAC IV is 
 achieved by having the array elements arranged in a special fashion. Thus, 
 
32 
 
 axi array procedure could be used to build up an array of elements in a special 
 fashion by use of the CALL. Then the array could be used in the application 
 and subsequently, perhaps, another array procedure could be used to bring the 
 array to a different mapping function. Of course, the TRANQUIL generated code 
 would work on the array as if it were in one of the standard mapping functions 
 (straight, skewed, etc.), but the procedure would have manipulated the elements 
 in such a fashion that in reality the operations would be performed on the 
 elements under a different mapping function. In particular, by using DYNAMIC 
 array procedures, the same array procedure could be used to convert a variety 
 of arrays to the new mapping function. 
 
 U.3.2 Input /Output 
 
 Another possible interesting use of array procedures could be in 
 Input /output . The array procedure could act like a singly buffered input- 
 output routine. Whenever the array procedure is called, the resultant array 
 could be filled from an input file, the array elements could be used as needed, 
 and the procedure could be called again to refill the array. On the other 
 hand, the array procediire could be used to build up an array which could then 
 be written on the output file and the array procediire could be called again 
 to refill the array, and so forth. 
 
33 
 
 5 . CONCLUSION 
 
 A procedure structure has been provided in TRANQUIL which allows 
 the user to write internal procedures in TRANQUIL and external procedures in 
 TRANQUIL or any other language which is able to meet TRANQUIL specifications. 
 Any TRANQUIL constructs may be passed as parameters and procedures may or may 
 not return single values. Recursion is^ however, not allowed. 
 
 Essential work has been completed on the procedure structure in 
 TRANQUIL, but a relatively small amount of work will be required to complete 
 interface with the ILLIAC IV operating system which is currently being de- 
 veloped. To this end, the procedure structure has been kept flexible. 
 
3k 
 
 APPEKDIK A 
 
 THE SYOTAX OF PROCEDURES 
 The syntax given here for procedures is a portion of the entire 
 syntax for TRANQUIL as input to the translator writing system except that 
 calls to semantic actions, which wo\ild not be relevant here, have been de- 
 leted. The syntax is similar to BNF, but there are certain differences which 
 facilitate processing [6] . The main differences in the syntax appearing here 
 are: the use of "&" to indicate one or no occurrences of a construct; the use 
 of quotes to surroTjnd metalinguistic variables; the use of "/" in place of the 
 vertical bar to indicate an alternative; the use of the LIST -SEPARATOR -CLOSE 
 construct to indicate left recursion; the use of "*I" to indicate any per- 
 missible identifier; the use of "■'^N" to indicate any permissible number; and 
 the use of "#" to precede reserved words and also reserved characters when the 
 latter are to appear in the language itself. 
 
35 
 
 SYNTAX OF PROCEDUPES IN TRANOUlL 
 
 ♦♦PROCEDURE OECLARATION* ll« [ ♦♦ATTRIBUTE^' H IPROCEnURr 
 ♦♦*!♦♦ [♦♦PROCEDURE HEADING^^ $t f ill 
 ♦•KUM EMPTY STATEMENT** I 
 ♦•FXTERNAl PROCEDURE OECL ARAT InN«^ tie *EXTERNA| 
 
 ♦•PROCEDURE DECLARATION^' \ 
 ♦•PROCEDURE hEADING^^ ll« (LIST [ ♦♦*!♦♦ 1 SEPARATOR » CLOSE-* 
 
 #; [LIST [ #VAIUE LIST C ♦♦*I^' ) SEPARATOR . CLO«;E] 
 SEPARATOR t\ CLOSE #1 1« 
 
 LIST [♦♦SPECIF ICATION** 1 SEPARATOR t\ ClOsF I 
 ♦•SPECIFICATION^^ »l« ♦♦ARRAY SPF C IFI CATION^^ / 
 ♦•PROCEDURE SPECIFICATION*' / 
 
 ♦♦ATTRIPUTE^^ LIST [ ♦♦♦I^' ] SEPARATOR , CLOSE / 
 ILAPEL LIST [ "♦I^^ ] SEPARATOR # C| OSE / 
 
 fSHlTCK LIST [ ♦♦*!♦♦ 1 SFPAfiATOR , cLoSF / 
 LIST [ ♦'SET ATTHTPUTf" LIST [♦'*I" ] 
 
 SEPAPA70R * CLOSE 1 SEPARATOR . CLOSf; 
 ♦♦ARRAY SPECIFICATION^^ ll« ♦'ARRAY ATTRIBUTE^' LIST [ 
 
 LIST [♦♦*!♦• ] SEPARATOR , CLOSf 
 t[ LIST C f* / ♦♦♦N^^ ] 
 SEPARATOR , CLOSF #3 1 SEPARATOR » CLOSE) 
 ♦•PROCtrURE SPECIFICATION** l«« [♦♦ATTRIBUTE" ] & 
 
 [ tROk 3& IPROCEDUHF 
 
 ♦•♦I^* [ ( LIST [♦•PARAMETER SPEC IF I CAT I ONS^^ ] 
 
 SEPARATOR , CLOSF )UI 
 
 ♦•PARAMETtR SPEC I F I C AT I ONS'^ ll« ♦'ARRAY ATTRIPuTF" 
 »( LIST [ #* J SEPARATOR , CLOSE #1 / 
 
 [ ♦•ATTRIBUTE*' ) R [ *ROw ] K fPROCEOURE 
 
 [ { LIST ["PARAMETER SPECIFICATIONS" ] SEPARATOR # 
 CLOSE ) ]& / 
 
36 
 
 [ fVALliE n ♦'ATTRIBUTE'* / 
 
 #LABFL / 
 iSWiTCH / 
 "SET ATTRIRUTE** I 
 
 "EXTERNAL ENTRY DECLARATION" tl« lEVTERNAL 
 
 t "ATTRIPUTE" ] & r *ROW ] & «ENTRV 
 
 "♦I" [ ( LIST "PARAMETER SPECIFICATIONS" 
 SEPARATOR * CLOSE ) U ) 
 
 "PROCEDURE CALL" ll» "ROfc^ PROCFOURF CALL" / "SIMPLE PPnCEDi"' E CALL") 
 "ROW PROCEDURE CALL" ««« "*I" ( 
 
 "ARITHMETIC EXPRESSION" ) i 
 "SIMPLE. PROCEDURE CALL" l«« "*I" [( LIST 
 
 "ACTUAL PARAMETER" SEPARATOR I* ] CLOSE) U I 
 "ACTUAL PARAMETER" Jl» "*T" f AHEAD » / AHFAT ) 1 / 
 [ "PPOIEAN EXPRESSION" / 
 
 "ARITHMETIC EXPRESSlTN" 3 I 
 "RETURN STATEMENT" its tRFTURN K ["ARITHMETIC ExPRESSIOk." 
 / "pnOLEAN EXf-RESSlON** ])]4 t 
 "ARRAY ATTRIBUTE" l«« "ATTRlPUTE" f KSKFWED tPArKEO / 
 tSKEWED / 
 iSTRAIGHT tpACKED / 
 tSTRAIGHT / 
 fCHECKER ] I 
 tAPPAY ; 
 "SET ATTRlPUTE" H« UNCSET / fMONOSET / #f,ENSET f 
 "ATTPTFUTE"! I* IBOOlEAN / #RrAl / fPFALS / tPEALP / 
 
 ^INTEGER / #PYTE8 / IPYTE16 / fiNTEGERS / 
 tiNTFGERL ) 
 
37 
 
 APPENDIX B 
 
 SAMPLE TRAITQUIL PROGRAM USING PROCEDURES 
 
 The TRANQUIL program shown below is intended to illustrate procedure 
 declarations and calls. Procedures are used to do smaller tasks than would be 
 the normal case. An external procedure is given along with a main program 
 which calls the external procedure and some internal procedures. As mentioned 
 before, the external procedure and main program would receive separate compi- 
 lation and assembly. 
 
 The external procedure : 
 
 EXTERML REAL PROCEDURE SQUARE (A); 
 
 VALUE A; REAL A; 
 
 BEGIN 
 
 IF A < .01 THEN A:=0; 
 
 RETURN (A X A); 
 
 END; 
 
 The main program: 
 
 BEGIN 
 
 REAL STRAIGHT ARRAY A,B,C [1:6^+, 1:64]; 
 
 INTEGER I, J; 
 
 INCSET II; 
 
 MONOSET M; 
 
 PROCEDURE SMM (X, Y, Z, W, K); 
 
 VALUE K; 
 
 REAL STRAIGHT ARRAY X, Y, Z [*, *] ; 
 
 MONOSET W; 
 
 INTEGER K; 
 
 BEGIN 
 
 INTEGER I; 
 
 FOR (I) SIM (W) DO 
 
 Z [I,K] : = X [I,K] + 2 X Y [l,K]; 
 END; 
 
38 
 
 REAL PROCEDURE LENGTH (A, M) ; 
 
 REAL STRAIGHT ARRAY A [*,*]} 
 
 INCSET M; 
 
 BEGIN 
 
 EXTERNAL REAL ENTRY SQUARE (VALUE REAL); 
 
 REAL S; 
 
 S: = 0; 
 
 FOR (I) SEQ (M) do 
 
 S: = S + SQUARE (A[I,I]); 
 RETURN (S); 
 END; 
 
 M : = [1, 2, ..., 6k]i 
 II : = [1, 2, ..., 61+]; 
 
 IF LENGTH (A, II) > LENGTH (B,II) THEN 
 BEGIN 
 
 FOR (J) SEQ (II) DO 
 
 34M (A, B, C, M, J); 
 END ELSE 
 BEGIN 
 
 FOR (J) SEQ (II) DO 
 
 SMM (B, A, C, y[, J); 
 END; 
 END. 
 
39 
 
 LIST OF REFERENCES 
 
 [1] Abel^ Norma E., Budnik, Paiil P., Kuck, David J., Muraoka, Yoichi, 
 
 Northcote, Robert S., Wilhelmson, Robert B., "TRANQUIL: A Language 
 for an Array Processing Computer", Proc . SJCC (I969) PP« 57-73 • 
 
 [2] Ingerman, P. Z., "THUNKS", CACM , k (Jaji., I961) pp. 55-58. 
 
 [3] Budnik, Paul P., "TRANQUIL Arithmetic", Report No. 296, Department of 
 
 Computer Science, University of Illinois at Urbana-Champaign (Jan., I969) 
 
 [U] Wilhelmson, Robert B., "Control Statement Syntax and Semantics of a 
 Language for Parallel Processors", Report No. 298, Department of Com- 
 puter Science, University of Illinois at Urbana-Champaign (Jan., I969) • 
 
 [5] Miiraoka, Yoichi, "Storage Allocation Algorithms in the TRANQUIL Com- 
 piler", Report No. 297^ Department of Computer Science, University of 
 Illinois at Urbana-Champaign (Jan., 1969)* 
 
 [6] Trout, H. R. G., "A BNF Like Language for the Description of Syntax 
 Directed Compilers", Report No. 300, Department of Computer Science, 
 University of Illinois at Urfeana-Champaign (Jan., 1969)' 
 
UNCLASSIFIED 
 
 Security Cl«»»ific«tion 
 
 DOCUMENT CONTROL DATA -R&D 
 
 (S0curily clmtain^mtlon ot lltl; body ol mbtttmet mnd Ind^Mlng anHolmllan mu«< b» mnfr^ wh»n tff onrmll rmport I* clammiUmd) 
 
 I. ORiSiNATINa ACTIVITY fCorporal* autfior) 
 
 Department of Computer Science 
 
 University of Illinois at Urt ana- Champaign 
 
 UrT^ana. Illinois 6l8ni 
 
 a«. NEPONT SECURITY CL A isi Ft C A TIOKI 
 
 UNCLASSIFIED 
 
 26. aROu^ 
 
 S. REPORT TITLE 
 
 PROCJEDURES IN THE TRANQUIL COMPILER 
 
 4. DESCRIPTIVE NOTES (Trp» o/ raporl mnd htelualrm dmtmm) 
 
 Research Report 
 
 B. AUTHOR(S) (FirmI nmB—, middle InlUal, Immt nmma) 
 
 Martin Ozga 
 
 «. REPORT DATE 
 
 April 30, 1970 
 
 7«. TOTAL NO. OF PACES 
 
 k7 
 
 7b. NO. OF REFS 
 
 •«. CONTRACT OR GRANT NO. 
 
 USAF 30(602)-lflifi|- 
 
 b. PROJECT NO. 
 
 46-26-15-305 
 
 •a. ORIGINATOR'S REPORT NUMBER(S> 
 
 DCS Report No. 379 
 
 Bb. OTHER REPORT NO(S) (Any othmr nimben dtmt mmy be mamlgned 
 thim rmport) 
 
 ILLIAC IV Document No. 209 
 
 10. DISTRIBUTION STATEMENT 
 
 Qualified requesters may ohtain copies from DCS, 
 
 II. SUPPLEMENTARY NOTES 
 
 None 
 
 t2. SPONSORING MILITARY ACTIVITY 
 
 Rome Air Development Center 
 Griffiss Air Force Base 
 Rome, New York 134^0 
 
 13. ABSTRACT 
 
 A description is given of the procedure structure in the 
 TRANQUIL compiler, which allows external and internal procedures which 
 may or may not return a single value. Also, for the "benefit of those 
 who may have to change the compiler, a description is given of the 
 current implementation. 
 
 FORM 
 • NOV as 
 
 1473 
 
 UMCLASSIFrED 
 
 Security Classification 
 
UNCLASSIFIED 
 
 Security Cla««ification 
 
^?^ 
 
 \^ 
 
u,