LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 510.S4- co p. 2 MATHEMATICS The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasoni for disciplinary action and may result in dismissal from the University. To renew call Telephone Center, 333-8400 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA CHAMPAIGN BUILDING JAN 18 USE _0NLY 982 jm i 8 982 L161— O-1096 Digitized by the Internet Archive in 2013 http://archive.org/details/glypnirlistproce322laur Wl(/ /O Report No. 322 13* GLYPNIR A LIST PROCESSING LANGUAGE FOB ILLIAC IV by Duncan Hamish Lawrie JIM 1 6 1259 April 1, 1969 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN Report No. 322 GLYPNIR A LIST PROCESSING LANGUAGE FOR ILLIAC IV* by Duncan Hamish Lawrie April 1, 1969 Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 6l801 * This "work was supported in part by the Advanced Research Projects Agency as administered by the Rome Air Development Center under Contract No. US AF 30(602)4lW+ and submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science, June, 1969* ACKNOWLEDGMENT I wish to thank Professors D. J. Kuck and R. S. Northcote for their continuing support of this project. Also, Terry Layman was of great assistance in the implementation of GLYPNIR. I would like to express my appreciation for the financial support given by the Department of Computer Science and the ILLIAC IV Project. I am also indebted to the machine room staff, especially Mrs. Nancy Stone who keypunched most of the compiler. Finally, my thanks to the secretarial staff for typing several preliminary reports and especially to Mrs. Sharon Hardman who typed the final manuscript. ABSTRACT GLYNPIR is a programming language intended to facilitate the setup and manipulation of generalized pointer -linked data structures on ILLIAC IV. It is intentionally a very machine- dependent language, and, in fact, it can be thought of as a high level assembly language which automatically generates code to load operands, evaluate expressions, set up subroutine calls, etc. As such, it is potentially useful to anyone who is currently writing assembly code for ILLIAC IV. GLYPNIR should also be useful for the implementation of higher level languages either as intermediate object code or as a source code for compilers. In fact, GLYPNIR was originally designed to serve as a base language for high level list processing languages which were to be implemented through the use of macro and procedure statements. TABLE OF CONTENTS Page INTRODUCTION 1 1. DESIGN AND IMPLEMENTATION 2 1.1 Design Objectives 2 1.2 Implementation 5 1.2.1 The TWS Scanner 5 1.2.2 The TWST Parser 7 1.2.3 The GLYPNIR Translator 7 1.2. 3*1 The Identifier Table 7 1.2.3*2 The Main Stack and Operand Descriptors . . 8 1.2. 3*3 Operand and Hardware Control Structure . . 8 2. A DESCRIPTION OF GLYPNIR I 15 2.1 Registers and Data Blocks 15 2.2 Field Content Designators 19 2.2.1 Fields 19 2.2.2 Field Content Designators 23 2.3 Expressions 28 2 . 3 • 1 Boolean Expressions 28 2.3*2 Arithmetic Expressions 29 2.3*3 Alphameric Expressions 30 2. 3**+ Pointer Expressions 31 2.4 Assignment Statements 33 2.5 IF Statements 37 2.6 FOR Statements 38 2.7 Blocks, Compound Statements, and Labels 4-3 2.8 Subroutines ..... kh 2.9 Standard Functions kS 2.9.1 ALGOL Functions 51 2.9.2 Storage Allocation 51 2.9*3 Special Functions » 52 vi Page 3. FORMAL SYNTAX 53 k. EXAMPLES 62 k.l Matrix Addition 62 4.2 A Graphics Application 71 k.3 A Sorting Problem 72 h,k Another Sorting Program 72 LIST OF REFERENCES 90 APPENDIX A. SYNTAX 91 B. RESERVED WORDS 99 LIST OF TABLES Table Page 1. TYPES AND KINDS OF REGISTERS 18 2. DEFINITION OF A OP B 32 3. ASSIGNMENT STATEMENTS, RIGHT AND LEFT SIDE TYPE DIFFERENCES 3^ k. ASSIGNMENT STATEMENTS, RIGHT AND LEFT SIDE KIND DIFFERENCES 35 5- RESTRICTIONS ON FIELD LENGTHS LIST OF FIGUEES Figure Page 1. Flow diagram showing the major steps required to translate a GLYPNIR program G 2. Word formats in IDTAB 9 3» Operand descriptor formats in MSTACK . 11 U. An example of the use of the hardware control structure. . . 13 5. The hardware control links after code has been generated which will cause operand A to be moved to RGS and operand B to be loaded into RGA lU 6. Use and declaration of CU and PE pseudo registers 17 7. The integer field I[l,l6,U8] 20 8. Illustration of the use of FCD's to reference data ..... 9« Illustration of the state of several PE memories after line Ik of figure 8 has been executed. All PE memories will look the same in this case 26 10. Example of the use of pointer indexing 27 11. Illustration of the effect of one type of ko 13. Illustration of an implicit P0PM0DE caused by execution of . Notice the "%" convention used for comments. Line numbers have been added for reference only . k2 Ik. An example of the illegal use of a label which would result in a fatal error kh 15. Illustration of the scope of identifiers used in subroutine bodies. The last statement assigns the value 20 to Y. (Line numbers are for reference only. ) k6 16. Example of declaration and call of a subroutine. U9 17. Illustration of equivalent actions performed during a sub- routine declaration and call 50 Figure Page 18. Matrix addition 63 19- Matrix storage for example 1 65 20. Linked list of point vectors for a graphics application ... 66 21. Storage of the rotation matrix for example 2 . 67 22. A section of the point list for example 2 68 23. Program for example 2 . . . 69 2k, Illustration of a sorting algorithm 73 25. Program for example 3 7^- 26. Code generated by the program of figure 25 76 27. Another code for example 3 8l 28. Code generated by the program of figure 27 Qk INTRODUCTION GLYPNIR is a programming language intended to facilitate the setup and manipulation of generalized pointer-linked data structures on ILLIAC IV. It is intentionally a very machine-dependent language, and, in fact, it can be thought of as a high level assembly language which automatically generates code to load operands, evaluate expressions, set up subroutine calls, etc. As such, it is potentially useful to anyone who is currently writing assembly code for ILLIAC IV. GLYPNIR should also be useful for the implementation of higher level languages either as intermediate object code or as a source code for compilers. In fact, GLYPNIR was originally designed to serve as a base language for high level list processing languages which were to be implemented through the use of macro and procedure statements. This manual is intended to serve as both an introduction to GLYPNIR and a user's manual for Version I. The following chapters des- cribe, both formally and informally, the facilities which will be avail- able in the Version I compiler. The syntax of GLYPNIR has been designed to resemble ALGOL wherever possible, and the reader is assumed to have a basic knowledge of ALGOL. Additionally, it would be helpful to be familiar with the ILLIAC IV computer. 1. DESIGN AND IMPLEMENTATION GLYPNIR is a list processing language for the ILLIAC IV computer [1]. It is evident that "list processing" is a difficult term to define, especially with relation to ILLIAC IV. For the purposes of this paper, we shall define list processing as any computation which is not primarily array oriented, that is, computations characterized by data structures which are not wholly arrays. Studies into several proposed applications [2-5] as well as the possibility of compiling and display processing on ILLIAC IV indicate the desirability for such list processing facilities. 1.1 Design Objectives GLYPNIR has been designed in an attempt to satisfy several requirements which the author feels are necessary in a list processing language for ILLIAC IV. (l) The language should restrict the data structure as little as possible. Certain structures such as vectors and pointers should be inherent in the language, but the user should be able to combine and link his data in any way which will facilitate the calculation in which he is interested. This requirement has been met to a large degree by using the concept of programmer defined fields, similar to those employed in L [6]. The programmer defines the placement, size, and meaning of fields within data blocks, and thus the data structure can (must) be designed entirely by the programmer. This, of course, requires a certain amount of tedious work on the part of the programmer who expects to find his data structure designed for him. However, this is advantageous in that the programmer will not have to fit his data into some pre-ordained structure, and the resulting organization is more likely to allow efficient computation and clearer program logic. (2) The language should be extendable and modifiable in the sense that a user should be able to adapt the language to the point where the routine operations of his application require little effort in program- ming or thought. To a very small degree this requirement has been satisfied in that it is easy to introduce new operators into GLYPNIR at the compiler level and, through the use of the translator writing system [7]> it is relatively easy to change the language syntactically. However, it is obvious that a great deal more work needs to be done in this area. Plans are underway to include macro facilities in the language as well as the ability to introduce new operators at the source program level. Further study of this problem is being directed along the lines of Garwich [8], Leroy [9]> and Barron, et_al. [10]. (3) The programmer should be able to communicate closely with the machine. This would allow optimization of routines where execution speed is critical and to -* Even the very simple macro facilities embodied in the of Burroughs Extended Algol proved to be extremely useful in the implementation of the GLYPNIR compiler. utilize special hardware features. On the other hand, the programmer should not need to worry about routine chores; i.e., operations like common data type conversion, expression evaluation, stack, and mode control, pointer chasing, and partial word masking should be done automatically by the system. The functions mentioned above are performed automatically by the GLYPNIR compiler. However, the programmer may override these functions if he feels it desirable to do so. For example, it is possible to write a statement such as X := (PNT.A + PNT.B) X C + PNT.A However, if this statement is to be executed many times, then it might be desirable to optimize it. This is accomplished by the following sequence : RGX := PNT; RGS := RGX. A; RGA := RGX.B; X := (RGA + RGS) X C + RGS This sequence will result in the generation of better code than the previous * The terms PNT.A and PNT.B are examples of one of the basic methods of specifying operands in GLYPNIR. PNT.A specifies the data in the field A of the block pointed to by the variable PNT. Such a pointer chain, or field content designator (FCD) as they are called here, can be arbitrarily long. FCD's are treated in more detail in the following chapters. *-* RGA, RGS, and RGX are the names of actual hardware registers in ILLIAC IV. The use of these and related facilities will be explained in a separate document. statement in that it eliminates two fetches or I "NT and one fetch and mask of the contents of the field A. In summary, GLYPNIR should be of use to those who are interested in list processing and to those who want a language which is easier to use than assembly language, but who want to avoid the inefficiencies of a higher level language. 1.2 Implementation GLYPNIR has been implemented with a one pass compiler which utilizes the University of Illinois Translator Writing System [7]. The compiler consists of approximately 9000 source cards and was written in Burroughs Extended Algol for the B5500 computer. The current core estimate is approximately 12K words and programs are compiled at 300-400 cards per minute. Output from the compiler is ILLIAC IV assembly language. Figure 1 is a flow diagram showing the major steps required in the translation of a GLYPNIR program. The compiler can be logically divided into three sections: the scanner, the parser, and the translator. A brief description of each of these follows. 1.2.1 The TWS Scanner The primary purpose of the scanner is to interface between the user's program and the parser and translator. The scanner converts Now that the speed and size of the compiler are known, the author readily admits that efforts should have been directed toward a two pass compiler which would improve throughput by providing for syntax debugging in the first pass and postpone actual translation until the second pass. GLYPNIR PROGRAM OPTIONAL I MACRO I EXPANDER I I I GLYPNIR COMPILER I ILLIAC IV ASSEMBLY LANGUAGE I ILLIAC IV ASSEMBLER /RELOCATABLE ( MACHINE V CODE LOADER I EXECUTABLE MACHINE CODE Figure 1. Flow diagram showing the major steps required to translate a GLYPNIR program. identifiers and special symbols into an internal representation constructs the primary identifier table (BIGTAB) . It is essentially the same scanner used by all high level ILLIAC IV languages. 1.2.2 The TWST Parser The parser used in Version I is a table driven recursive descent parser [7]. The tables were generated by the TWST compiler generator pro- gram from the syntax specifications for GLYPNIR (see Appendix A). The pur- pose of the parser is to recognize certain syntactic constructs in the user's program and call appropriate translator routines for semantic action. 1.2.3 The GLYPNIR Translator The GLYPNIR translator performs the actual translation from recognized syntactic entities to ILLIAC IV assembly language. It would be impossible to present a comprehensive description of this part of the com- piler in this paper. We will only attempt a brief overview of the main tables and operand control structures. 1.2.3.1 The Identifier Table . The main data table is LDTAB. IDTAB contains information which tells what each identifier represents as well as various parameters asso- ciated with the identifier and possible links to secondary tables. Figure 2 shows the bounds and use of each field in IDTAB. Notice that each entry in IDTAB consists of two words. The format for the first word is the same PADLAR, the subroutine PArameter Discriptor ARray, is one such secondary table. for all entries although some fields are not used for some identifiers. The format for the second word depends on what the identifier represents. 1.2.3*2 The Main Stack and Operand Descriptors When the parser recognizes an identifier which corresponds to an operand, it places a pointer to BIGTAB in the main stack (MSTACK). BIGTAB contains a further pointer to IDTAB where information about the identifier can be found. Control then passes to the translator where the information in IDTAB is used to construct an operand descriptor which is then placed in MSTACK. The format for this descriptor is shown in Figure 3. After the descriptor is placed in MSTACK, the translator may generate ILLIAC IV assembly code -which would cause the operand to be loaded into an ILLIAC IV register or to be operated on in some other way. Usually, the MSTACK descriptor always reflects changes in the status of an operand which will have been caused by the generated assembly code. It should be kept in mind that these descriptors exist in the compiler, though they describe operands which will exist at execution time on ILLIAC IV. 1.2. 3*3 Operand and Hardware Control Structure As mentioned above, when code is generated which will cause an operand to be loaded into a hardware register, the descriptor for this operator in MSTACK is modified to indicate the new status of this operand. If we wish to cause another operand to be loaded into the same hardware register, then it is important to know that the register is already occupied and by which operand it is being used. This knowledge is obtained by exam- ination of the hardware control structure. 3 ON O OJ ^^ H fe £> g ^ fck H rH p o r< ■g to a o •H p O CH H 03 •H ■s •H !h cd > ■P d -p cd •H O o 03 03 cd 0) P 03 03 P o •H ■d ft EH O P 03 a •H P o 03 03 ■3 d H •H Q3 rH ■S •H !h cd > 03 •H p d CD rH 3 o 03 •H M 03 •H CH ■H P 03 •H 03 P cm H o p p 0) CO t3 •H 3 03 -d rH 03 a •H 13 o 03 OJ XI P o p H H cd C3 •H H o p p 03 CO d H 03 •H <+H >S P •H ■d •H rH cd > 03 a ■H P O « O rH ft 03 P •H P •H O ft a 03 t> •H bO p cd d 03 cd rH O 03 d 03 cd rH 03 •H CH •H P 03 d ■H 03 P 03 03 ? H 03 > 03 rH ^ C3 O rH PQ 03 ■8 rH o Ch ft d 03 03 Pi d 03 cd r-\ O 03 d 03 cd ? m 03 •H CH ■H P 03 'd •H 03 P 03 03 > 03 H 03 d O S d 03 S3 bO •H 03 03 cd a 03 X* 03 cd -3 H 03 ■§ H 03 P h O o d 03 03 pi 03 3 p o p 03 H o p a o o a cd Sh 03 ft o 03 P o p P-4 o o 03 03 •H P 03 -d w 03 P 02 •H bO 03 5h 03 3 O •d o & 10 C/2 fa oo fa i-3 oo C/2 •• fa Lf\ 3 CM a fa P^ O H cq on H fa CD H a co" •H fH 05 > *■— ' U • CD CD P CJ CQ •H •H P bD P CD O Ph • fa ? t3 H CQ 0) 3 bO & -P •H i-q •H CQ C3 £ CQ a O «d CD CQ P co- CQ CO is CQ CD •rl O H u o QJ nd CQ P -d CQ 03 • o3 «5 rH 0) CD CQ CO" £ ■H CD ^ H P P O £ ct3 CD • •H H S & ^ H CD CO P ■? » O -p CQ P ■H M i n3 H |3 H o p ■a H ■a -P H P CQ 0) CQ 3 •H fa •H fa •H fa 0) fa ■H fa a CQ < fa ■H fa fa pq fa fa fa 3 S fa o CD l OJ 0) •H fa 11 fe ITS U KS S51 OJ fe o p 0) 3 CD CD H O O pq d CD ft o O £ (D CD £ W CD -P a a •H d S3 H CD f> H 0) ^H 0) -p w H O H d •H W •H d u CD ft O CD P ph p-4 N CO K O tH o EH h-l 5h ft o and . GLYPNIR allows the use of two kinds of pointers, confined and non- confined. Non- confined pointers are allowed to point from one PE to another. Confined pointers are not allowed to point across PE boundaries. 2.2 Field Content Designators Field content designators, hereafter abbreviated FCD, are the principal means of referencing data in GLYPNIR. An FCD may designate the contents of a register (either a GLYPNIR register or, in some cases, an actual hardware register) or it may designate a particular field within some data block. Registers were introduced in the last section. We will begin this section with an explanation of field identifiers. 2.2.1 Fields Through the use of field declarations, an identifier can be associated with a data field. It is important to understand that, in this paper, "field" refers not only to some part of an ILLIAC IV word, but to a- particular word within a block of words as well. For instance, the following field declaration will cause the identifier "I" to be asso- ciated with the field indicated in Figure 7 : INTEGER FIELD I[l,l6,k8]; 20 Word Word 1 Word 2 4 — first bit l6 4 kS bits long Word Block Figure 7. The integer field I[l,l6,48]. Notice that word numbers and bit numbers both start at zero. Also notice that a type is associated with this field. This will be true of all fields. The various field types are: ALPHA.: Generally used to hold non-numeric data or unsigned integers. The field contents are treated as unsigned integers when used in arithmetic statements unless the field length is 64 in which case the leftmost bit is considered the sign bit. INTEGER: Used to store signed integers. This field may be any length as long as it does not cross a word boundary. However, for the purpose of arithmetic, integer quantities are treated as kQ bit fixed point numbers. Note that the sign bit is stored as the rightmost bit of the field. 21 CONFINED POINTER (POINT): Used to store "confined" pointer. . The field length must be greater than or equal to l6. NON-CONFINED POINTER (NPOINT): This is used to store "non- confined" pointers (pointers which may point across PE boundaries). The field length must be greater than or equal to 2k. REAL: These fields are used to store real numbers. To utilize ILLIAC IV hardware effectively, these fields may refer to any word within a block but they can only refer to one of the following word parts: FULL: bit 0, sign bit of mantissa bits 1-15, exponent bits 16-63^ mantissa INNER: bit 8, sign of mantissa bits 9-15* exponent bits l6-39> mantissa OUTER: bit 0, sign of mantissa bits 1-7 > exponent bits 40-63, mantissa For further information on real fields, see the section on field declaration in Chapter 3 of this paper and the section on data formats in the ILLIAC IV manual. None of the above fields may cross word boundaries. The Version I compiler will try to optimize the use of fields, and the following suggestions will result in more efficient object code: 22 1) Right justify fields when possible. This applies especially to pointer fields. 2) ALPHA, and REAL fields should be as long as possible without interfering with other fields. 3) ALPHA fields should be used to store integers unless the integers might be negative. It is not necessary for all fields to be distinct—fields may be defined within other fields. For example, the ALPHA field EX defined below can be used to alter the exponent part of the REAL field X: ALPHA FIELD EX [0,1,15]; REAL FIELD X[0,FULL] . Also, the ALPHA field AB can be used to operate on the absolute value of the INTEGER field IN in the following: ALPHA FIELD AB [0,10,1^]; INTEGER FIELD IN [0,10,15] • When the contents of a field are specified as an operand for some operation, the following actions are taken before the operations are performed. (This includes the unary alphanumeric operation "C0MP" explained later.) l) If the field is less than 64 bits in length, then the field is right justified and high order bits filled with zeroes. (The only exception to this is REAL fields.) 23 2) If the field is an INTEGER field, then the sign bit which is in the least significant (rightmost) bit position is shifted end around into the correct sign bit position. These actions do not affect other fields in the same word unless those fields overlap the designated field. 2.2.2 Field Content Designators FCD's are constructed from register identifiers and field identifiers as follows: : := | • and . Boolean values were mentioned briefly in connection with Boolean registers, but the evaluation of Boolean expressions will require further analysis. Boolean values ultimately result from Boolean literals or from the evaluation of relations. A Boolean literal is, in opposition to 29 ALGOL, a logical bit pattern which may result from a numerical constant (probably expressed in octal). Each bit corresponds to a true or false value for some PE in the current configuration. This situation is simply a reflection of the result of evaluating relations. As in ALGOL, relations are simply comparisons between arithmetic expressions. Unlike ALGOL, arithmetic expressions can have many values-- a different value for each PE in which the expression is evaluated. Thus, relations are multi-valued since they result from comparisons done in many EE's. At the time when relations are evaluated, some PE's will be enabled while other's will be disabled (this is explained under ) . A relation is evaluated in such a way that true values are returned in all disabled PE's. This is due to the fact that, technically, arithmetic expressions have no value in disabled PE's. 2.3*2 Arithmetic Expressions Arithmetic expressions are again very similar to ALGOL. There are, however, two differences: l) There will be no exponentiation operation (t) in Version I, and 2) primaries are defined as follows: : := () + | | f Type must be real or integer. 30 The principal difference to be noted here is the presence of . These are explained next. It is sufficient to state here that the following is a valid (using the fields and registers defined in Figure 8, page 25). PRL + CRL X PCPNT1.A EOR PCPNT2.A This will be evaluated as though parentheses were inserted as follows: PRL + (CRL X (PCPNT1.A EOR PCPNT2.A)) The result of the alphameric expression will be treated as an unsigned integer. All integers are treated as hQ bit fixed point numbers. Thus, alphameric fields longer than ^8 bits will have the excess high order bits truncated when used in arithmetic expressions. 2.3*3 Alphameric Expressions Alphameric expressions have been introduced for two reasons: l) to allow logical operations on words, and 2) to enable the programmer to utilize several special hardware operations on ILLIAC IV. The syntax follows. There is a minor qualification here. Results of alphameric expressions, when used in arithmetic expressions, are treated like unsigned integers unless the evaluation of the expression causes the zero-th (most significant) bit to be turned on. 31 : := | :: = WAND | WOR | WIMP | WEQU | EOR | NOR | NAND | ADB | SBB | ADD | SUB ::= () COMP | | Notice that due to the large number of operators, no precedence is established between operators —operations are performed from left to right unless parentheses are used. The functions of the operators are specified in Table 2. We will reiterate at this point that wherever fields whose length is less than 6U bits are used as operands in alphameric expressions, the field contents are right justified and high order bits filled with zeroes before any operation is performed. Later versions of GLYPNIR will include more ILLIAC IV instructions as alphameric operators. These, together with the ability to reference actual ILLIAC IV hardware registers provide a limited assembly language capability in the language. 2.3«^ Pointer Expressions Pointer expressions are extremely simple. Their syntax follows. ::= TABLE 2 DEFINITION OF A OP B 32 OP FUNCTION COMP Complement all bits of operand WAND Logical "AND" of operands WOR Logical "OR" or operands WIMP Logical "IMP" of operands WEQV Logical "EQV" of operands EOR COMP (A WEQV B) NOR COMP (A WOR B) NAND COMP (A WAND B) ADB SBB ADD SUB These are special ILLIAC IV instructions. See the appropriate section of the ILLIAC IV manual. 33 Notice that no explicit pointer modification will be allowed in Version I. 2.^4 Assignment Statements Assignment statements are simply one way of moving data from one place to another. In addition to moving data, assignment statements may invoke routines which change data from one form to another. Table 3 lists the allowed combinations of right and left hand sides and the con- versions which are automatically invoked. In addition to differing in type, the right and left hand sides may differ in kind , that is, one may be a multiple (PE) quantity while the other is a single (CU) quantity. These possibilities are enumerated in Table h. Up to this point we have made no provision for moving multiple data from one PE to another, that is, for utilizing the ILLIAC IV ROUTE instruction. This can be done, albeit very inefficiently, by proper use of non-confined pointers, but the use of these will be severely restricted in Version I. For this reason we will now introduce a new construct into the assignment statement. : := := | := [] : := The effect of the routing index involves the concept of the MODE register which, unfortunately, is not discussed until Section 2.6 of this chapter. Those who do not already know about the MODE register 3^ TABLE 3 ASSIGNMENT STATEMENTS, RIGHT AND LEFT SIDE TYPE DIFFERENCES Right Hand Side Type Left Hand Side Type Real Integer Alpha Boolean Confined Pointer Non-Confined Pointer Real Integer Alpha Boolean Confined Pointer Non-Confined Pointer 7 1 1 X X X 2 7 y X X X 2,3 3 y X X X X X X V X X X X X X y X X X X X X y y = No conversion necessary X = Not allowed 1. Usual conversion. 2. RHS is rounded and truncated. If the value of the RHS is too large for U8-bit fixed point representation, an overflow condition results. 3« A negative RHS will result in an overflow condition unless the LHS is a register or 6U-bit field. TABLE k ASSIGNMENT STATEMENTS, RIGHT AND LEFT SIDE KIND DIFFERENCES Left Hand Side Multiple (PE) Simple (CU) Right Hand Side Multiple Single V 1 2 y •/ = No conversion required. 1. Each element specified by the LHS received the same single value which is specified by the RHS. 2. The single destination specified by the LHS receives the logical "OR" of all the values specified by the RHS. 36 should skip the remainder of this section and return after reading Section 2.6. The routing index allows the programmer to specify that the value resulting from the evaluation of an expression in one set of PE's is to be assigned to the left hand side as evaluated in another set of PE's. When an assignment statement is executed, the following steps are taken. 1) The value of the routing index is determined and the MODE register is shifted right (end around) by this amount. 2) With the new mode configuration in effect, the RHS is evaluated. 3) The results of the RHS are routed left, and the MODE register is shifted left, by the amount of the routing index. h) The LHS is evaluated and the assignment performed under the effect of the original mode configuration. An example may help to clarify this. Suppose the MODE register contains 1 1 1 ... . Thus, all odd numbered PE's are disabled, even numbered PE's are enabled. If the assignment statement PNTR.P.X := [1] PNTR.X + PNTR.Y is executed, then the expression PNTR.X + PNTR.Y 37 will be evaluated 1 PE to the right of all enabled PE's (odd PE'a), the result will be routed left (end around) one PE, and the result assigned to PNTR.P.X in all even numbered PE's. Notice that the routing index is only relevant if both the right and left hand sides specify multiple quantities (i.e., PE quantities) Thus, use of the routing index is only allowed under this condition. 2.5 IF Statements The only difficulty encountered in the understanding of is in the effect of the . As men- tioned earlier, Boolean expressions result in multiple true-false values, one for each PE. In the context of , the Boolean expres- sion is considered to be true if and only if the expression is true for all PE's . At this point one might ask if there is not some facility for having a statement executed in just those PE's which do return a true value. That is, for all PE's such that the Boolean expression is true do the following statement . There is, and such a statement would be written FOR ALL DO . This is just one type of and next to FCD's, it is probably the most important construct in GLYPNIR. FOR statements are the subject of the next section. 38 2.6 FOR Statements There are two kinds of in GLYPNIR. The first is similar, at least syntactically, to the of ALGOL. The other is used to set the MODE register. The syntax for the first type of for statement is: : := FOR := STEP UNTIL DO If any of the above arithmetic expressions return multiple values, then independent loops will be established in all enabled PE's. (Those PE's which finish the loop sooner than others will mode themselves off.) An example of such a statement is FOR I := 1 STEP PNTR.X UNTIL PNTR. FINAL DO This is equivalent to the program of Figure 11. BEGIN LABEL LI, L2; BOOLEAN REGISTER SAVEMODE; PE REAL INC, LIMIT; SAVEMODE := MODE; INC := PNTR.X; LIMIT := PNTR. FINAL; I := lj Ll: IF I > LIMIT THEN GO TO L2; MODE := MODE AND I < LIMIT; ; I := I + INC; GO TO Ll; L2: MODE := SAVEMODE END Figure 11. Illustration of the effect of one type of , but we will state now that MODE contains the current mode bit configuration and the assignment of any Boolean value to this register results in the resetting of the mode bits (RGE and RGE1). Uo The syntax for the second type of is ::= FOR ALL DO DO The effect of the "FOR ALL" statement is to construct a new mode word by performing a logical "AND" between the result of the Boolean expression and the current mode word. The current mode word (contents of MODE) is then pushed into the mode stack and the new mode word becomes the current mode word. After the statement following the DO is executed, the old mode word is restored to the mode register and becomes the current mode word again. An example would be FOR ALL I An equivalent program for this is the program of Figure 12. BEGIN LABEL LI; PUSHMODE (I < PNTR. FINAL AND MODE); IF NOT MODE THEN GO TO LI; ; LI: POFMODE END Figure 12. Illustration of the effect of executing the second type of . The procedures PUSHMODE and POPMODE used above cause Boolean values to be pushed and popped on the system mode word stack (the top of which is the special MODE register). Notice that the statement follow- ing the DO is skipped if MODE AND returns false values for all PE's. The statement following the DO can be thought of as being within the "scope" of the may be under the influence of other , but this causes no problem as successive mode words are simply pushed on the mode stack. The execution of a within the scope of a may cause the mode stack to be popped, depending on the destina- tion of the label transferred to. An example should clarify this. Figure 13 shows a case where a is executed within the scope of a where the destination label is not within the scope of the same . In this case, the will cause the mode stack to be popped once before the transfer is performed, thus restoring the original mode configuration. Figure 13 is an example of a particularly poor way to compute e . It should be instructive, however, to stop at this point and work through an example. k2 Line Ref. No. BEGIN 1 % COMPUTATION OF E TO THE X USING 2 io MACLAURIN SERIES. THE ARGUMENTS ARE 3 io INITIALLY STORED IN THE PE REGISTERS k 1@-10 DO 12 BEGIN 13 I - I + 1; Ik TERM - TERM x EX/ 1; 15 NEW *- NEW + TERM; l6 GO TO AGAIN IT END; 18 EX *- NEW 19 END 20 Figure 13 • Illustration of an implicit POPMODE caused by- execution of 1@-10. At line 17 a transfer to AGAIN is performed causing the original mode word to be popped from the mode stack and restored to the MODE register. When the content of TERM is less than or equal to 1 x 10 in all PE's, control will pass directly from line 12 to line 19 where the final result is assigned to EX. Control then leaves this block. 2.7 Blocks, Compound Statements, and Labels The first thing to be noted about blocks and compound statements in GLYPNIR is that there are no compound statements. Anything which begins with BEGIN and ends with END is a block, regardless of whether declarations appear within the block head. Having thus simplified matters, we will proceed to confuse them. kk Labels must "be declared. Further, they must be declared in the innermost "block" in which they are used. Figure li+ is an example of illegal use and declaration of labels. BEGIN LABEL LI; BEGIN LI: A := 1; END END Figure lk. An example of the illegal use of a label which would result in a fatal error. Labels may be used in anywhere within the scope of the label declaration. Thus, a block may be exited from anywhere, but it is impossible to enter a block except through its head. All identifiers must be declared before they can appear elsewhere in a program. Notice that this applies to the use of identifiers in sub- routine declarations where the identifiers and procedure are both local to the same block. This restriction is imposed by the one-pass nature of the Version I compiler. 2.8 Subroutines GLYPNIR subroutines are similar to both FORTRAN subroutines and ALGOL procedures; i.e., they are declared like ALGOL procedures, but they act like FORTRAN subroutines. The syntax for a subroutine declaration is: ::= SUBROUTINE Subroutine identifier^ ; | SUBROUTINE Subroutine identified ; < sub routine body> ::= :: = :: = () ::= I , :: = | OUT Notice that the specification of formal parameters is done in the parameter list itself. In addition to specifying the type of the formal parameters, a parameter may also be specified to be an output parameter (this is related to the call by name of ALGOL). If the actual parameter corresponding to a formal output parameter is a simple register identifier, then this register will be assigned the value last held by the corresponding formal parameter after exit from the subroutine. k6 Identifiers appearing within a subroutine body, which are neither local to the body nor formal parameters, assume the definition of those identifiers at the point of the subroutine declaration, regardless of redeclaration of the identifiers later in the same block head or their meaning at the point where the subroutine is called. This is in differ- ence with formal ALGOL but conforms to the convention established in Burroughs Extended ALGOL. Figure 15 illustrates this point. The last statement of the program (line 10) will assign the value 20 to the regis- ter Y. If line 7 had appeared between lines h and 5, then line 10 would result in Y receiving the value 10. BEGIN 1 PE REAL REGISTER X, Y; 2 X := 10; 3 BEGIN h SUBROUTINE ASSIGN; 5 BEGIN X := 20; END; 6 PE REAL REGISTER X; 7 ASSIGN; 8 END; 9 Y : = X; 10 END 11 Figure 15. Illustration of the scope of identifiers used in subroutine bodies. The last statement assigns the value 20 to Y. (Line numbers are for reference only.) U 7 The syntax for a subroutine call is: ::= ::= () : := | , ::= | | ::= : := which reference labels external to the subroutine are not allowed. 2.9 Standard Functions A number of standard functions will be provided in GLYPNIR. Most of these will not be available in Version I. Those which will be available are described in this section. h 9 BEGIN PINT S; CREAL T, Uj PREAL SUBROUTINE R(PINT I, PALPHA A, PREAL OUT X, PREAL Y, CALPHA OUT CX); ; R(T + U,,S); END Figure l6. Example of declaration and call of a subroutine. 50 BEGIN PINT S; CREAL T, U; LABEL LI, L2; PREAL Rl, XI, Yl; PALPHA Al; PINT II; CALPRA CXI; LI : BEGIN PREAL R, X, Y; PALPHA A; PINT I; CALPHA CX; I *- II; A *- Al; X - XI; Y ^ Yl; CX «- CXI; ; XI «- X; CXI *- CX; Rl 4- R; GO TO L2; END; • II *- T + U; Al «- 0; XI «- S; Yl ^- 0; CXI 4- 0; GO TO LI; L2: S *- XI; END Figure 17 • Illustration of equivalent actions performed during a subroutine declaration and call. 51 2.9«1 ALGOL Functions 1. ABS () 2. SIGN () 3. ENTIER () 2.9*2 Storage Allocation a) GETPEB () Type - PE confined pointer. Action - Causes allocation of a block of words in each enabled PE. Returns a pointer to this block. Failure to satisfy a storage allocation request will result in an overflow condition in the PE(s) which failed. b) FREEPEB («) Type - None. Action - Frees a block of words at the location specified by the pointer expression in all enabled PE's. c) GETCUB () Type - CU non- confined pointer. Action - Causes allocation of a single block of size specified by the arithmetic expression. Returns a single (non-confined) pointer to this block. Failure to find storage will result in a system interrupt. d) FREECUB (.) Type - None. 52 Action - Frees a single block of storage at the location specified by the pointer. 2.9*3 Special Functions A number of special functions "will allow the programmer to make use of special ILLIAC IV hardware features. These "will be announced as they become ready. Some of those which have a high priority are listed below. ROTATE SHIFT SHIFTO SHIFTS EDIT 3. FORMAL SYNTAX This chapter contains the formal definition of GLYPNIR I. This definition will be presented through BNF productions. Many of the non- terminals which appear will be qualified by footnotes which will affect a restriction on the type of the entity represented by the non-terminal. 1. ::= 2. ::= BEGIN declaration part> END 3« ::= ; ; h. ::= | | tl« 00010400 [<•!> NOT ( ?T80 t»S50 / ] 00010500 t. *S* 7 / 00010600 . #t<*l>t]<*I> »S«7 / 00010700 . #[<*N>«] <*!> t»s«7 3*1 00010600 ««, 00010900 GO TO <*I> »St*7 J ooonooo « 's O0011100 NOT T* / LEO / LSS / EftL / OOOHPoo GE« / GTR / NFU /#/#>/#]/ 00011300 96 / 00011600 J 00011700 H« 00011600 tr*/"l *s^ / ] 00011900 [[♦/-I PMOM* t 00012000 ii» 00012100 [T*/ #/1 9S10UM 00017200 U = 00012300 [nitf §S101]*» 00012400 00012500 n, 00012600 0TlAO/ 00012^00 [{[^ARITHMETIC E*PfcFbSION> AHFAO ) 00012800 /T[ BUT ) RUT t\ BUT RFGIN BUT ENOJ* ^S? J 1 [ )/ ) 00012900 • S100 1/ 00013000 / 00013100 <*N> 0S71 * 00013200 ii» 00013300 00013400 [[WANO/WOR/hPfiV/WlMP/EoR/NOR/NANO/AOB/SBB/AOO/SUB] 00013500 9S90 J*J 00013600 00013700 |t* 00013800 (S100 / 00013900 COMP 9S91 / 00014000 00014100 nTl62J 00014200 71 ii« 0001*300 <1MPLTC*T10M> r LOV *M04l* CI OST #S103j 0001*400 O0O14500 < I M P( lCATinN>l le 00014600 f ! ► P *S105)*I OOOU'OO 00014800 ||3 00014900 fOH BOOLEAN FACTOR> *S106l*J O0015000 00015100 M» O0015200 <801LFAn SFCONniKY> [ANO »S107]*J 00015300 00015400 U« 00015500 UNflT 0S1O'/ 00015600 J 00015700 M« 0001^^00 ( )«S100 / 00015900 / 0001«000 I»T161/ 00016100 I 00016200 i« 3 00016300 00016400 00016600 #S1 1 7 > 00016700 its 00016800 LSS Mill /COOF. 30/ O00U900 L Eo nsn2 /cOoE 47/ 00017000 eol »sii3 /■/ oooi7ioo 98 nfo RS116 'cum. tQ / r.Eo «$ll'i /cflor is/ gtk asiib /run* 14» «» = TWljr »S9A/ BUDI EAN(<»RTTHMFTK t*P»E SSI ON* > *S110'

I t* (»Tlft3 *S10?J I la [ RUT »j Bl)T BFlilN HUT END] [ RUT t; BUT BEblN BUT END]* 0S2J i i» kany> but ♦ but - "ut * But */ But oi v but ) but *» hut » rut fnd but begin]* 0S? tt* /-/*/»/ / oi v j jij i l = [ BUT #J Bi)T BFlilN BUT FND]* #$2J END 00017200 0001/300 00017400 00017500 00017600 00017700 00017800 OOOI79OO 00018000 00018100 00018200 00018300 0001*400 00018500 000l 8 600 00018700 00018800 00018900 00019000 00019100 0001*200 99 APPENDIX B RESERVED WORDS 100 Class A Reserved Words Table B-l lists the reserved words of GLYPNIR. If. the RSWD option is not used (see the GLYPNIR operation manual), then these words must be prefixed by a "#" character. TABLE B-l 101 ADB ADD ALL ALPHA AND ANY AS BEGIN BOOLEAN CALFHA CINT CNPOINT COMP CONFINED CREAL CU DIV DO ELSE EOJL EQV EOR END FALSE FIELD FOR FULL GEQ GO GTR HORIZONTAL IF IMP INNER INTEGER LABEL LEQ LSS NAND NEQ NON NOR NOT NPOINT OR OUT OUTER PALPHA PCPOINT PE PINT PNPOINT POINT POINTER PREAL PROCEDURE REAL REGISTER REPEAT SBB STEP SUB SUBROUTINE THEN TO TRUE UNTIL WAND WEQV WIMP WOR 102 Class B Reserved Words Table B-2 lists the class B reserved words. These are predefined register identifiers and are not preceded "by a "#" regardless of whether or not the RSWD option is used. Each of these identifiers has a special meaning in that they refer to actual ILLIAC IV hardware registers. However, the programmer may redefine these identifiers if he does not want or need to access hardware registers. 103 TABLE B-2 CARO RGC RGH CAR1 RGD RGI CAR2 RGE RGJ CAR3 RGE1 RGR MODE RGF RGS RGA RGF1 RGX RGB RGG 10^ Class C Reserved Words These are predeclared GLYPNIR identifiers. They may be redefined by the programmer. TABLE B-3 105 ABS FREEPEB GETPEBL CSTK FREEPEBL PEN ENTIER GETCUB PSTK FREECUB GETHB SIGN FREEHB GETPEB UNCLASSIFIED rcurityClaeaificatlon DOCUMENT CONTROL DATA -R&D (Sac urlly i lammlllcatlon at tltla, body ol abatrmcl mod Indawlnj annotation mum I fta anlaratf whan tha omall tapott la i lamallladi I ORIGINATING AC I I VI T V (Corpora/, mi, lb or) Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 S REPORT TITLI i*".REPORT SECURITY c I A til p I c A T lOl UNCLASSIFIED 26. GROUP GLYPNIR - A LIST PROCESSING LANGUAGE FOR ILLIAC IV 4. DESCRIPTIVE NOTES (TVpa ol raootl and Inclumlr. dataa) Research Report S AUTHORUI (Firm! MM, mlddla Initial, laml n.rr... Duncan Hamish Lavrrie 8 REPORT DATE April 1, 1969 7a. TOTAL NO. OF PACES 114 76. NO. OP REFS 11 la. CONTRACT OR GRANT NO. 46-26-15-305 6 PROJECT NO. USAF 30(602)1+144 •*. ORIGINATOR'S REPORT NUMBER(S) DCS Report No. 322 •6. OTHER REPORT NOIS) (Any other number* that m*y ba aflgnad thlm raport) tO. DISTRIBUTION STATEMENT Qualified requesters may obtain copies of this report from DCS. It. SUPPLEMENTARY NOTES NONE 12. SPONSORING MILITARY ACTIVITY Rome Air Development Center Griffiss Air Force Base Rome. New York 13440 13. ABSTRACT GLYPNIR is a programming language intended to facilitate the setup and manipulation of generalized pointer-linked data structures on ILLIAC IV. It is intentionally a very machine-dependent language, and, in fact, it can be thought of as a high level assembly language which automatically generates code to load operands, evaluate expressions, set up subroutine calls, etc. As such, it is potentially useful to anyone who is currently writing assembly code for ILLIAC IV. GLYPNIR should also be useful for the implementation of higher level languages either as intermediate object code or as a source code for compilers. In fact, GLYNPIR was originally designed to serve as a base language for high level list processing languages which were to be implemented through the use of macro and procedure statements. DD .'.r..1473 UNCLASSIFIED Security Classification UNCLASSIFIED Security Classification KEY WORDS ILLIAC IV list processing language language for parallel computation linked data structures pointer linked data structures UNCLASSIFIED Security Classification .