lASs ■If . 1 tfWfr' 111 lm ■'■•■'. v. IIIIIIUUUIMMnHHBHHMHiBHHHHIIIIIflBHHBH IV LI B RAHY OF THE, U N IVERS'lTY Of ILLINOIS ■■■^■■■■^■■■■■■■■■■■■■■■■■■■MMB^^Kl MATHEMATICS Report No. 197 COO -1018 -1072 A LANGUAGE FOR DESCRIBING DIGITAL COMPUTERS by John A. Wilber February 15, 1966 DEPARTMENT OF COMPUTER SCIENCE • UNIVERSITY OF ILLINOIS • URBANA, ILLINOIS :is U l. in dismisso. from .he Un,ve,s,y. University^of^lUnoisJ^i^ L161— O-1096 Report No. 197 A LANGUAGE FOR DESCRIBING DIGITAL COMPUTERS by John A. Wilber February 15, 1966 Department of Computer Science University of Illinois Urbana, Illinois 61803 * This work was submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering, February, 1966, and was supported in part by the AEC under contract US AEC AT(ll-l)l0l8. ym ACKNOWLEDGEMENT The author wishes to express his sincere thanks to his advisor, Professor B. H. McCormick, for his excellent counsel, support, and encouragement . Thanks are also extended to Mrs. Richard Eddy for typing the manuscript and to Mrs. J. Prendergast for preparing the figures. 111 TABLE OF CONTENTS m 6. 7- INTRODUCTION INFORMATION STRUCTURES 2.1 Regular Sets 2.2 Structure Sets 2.3 Interpretation of Structure Sets 3. DATA DECLARATIONS. 3*1 Orientation , 3.2 Syntax. . . . 3.3 Semantics . , 3 3 1 3 3- 2 3 3 3 3 3 4 3 3< 5 3 3- 6 BLES. Format Primaries Format Secondaries Format Terms , Format Expressions Format and Field Declarations Labeling , k-1 Syntax of Variables . 4.2 Semantics of Variables 4.2.1 Field Variables 4-2.2 Field Specifier List . . . 4.2-3 Field Subscript List . . • 4.2.4 Interpretation of Variables PROCEDURE DECLARATIONS 5-1 Syntax- • 5«2 Semantics 5-2.1 Formal Parameters 5»2.2 Access Procedures 5.2.3 Store Procedures 5.3 Hardware Interpretation • • SAMPLE DESCRIPTION OF A COMPUTER PROBLEMS OF IMPLEMENTATION • . . 7«1 Software Applications 7-2 Introduction of Stack Operations 7-3 Computer Simulator 7 .^4 Hardware Compiler 8 . CONCLUSION REFERENCES . . Page 1 4 k 5 10 13 13 Ik 16 16 17 18 18 19 19 22 22 23 23 23 24 25 29 29 30 30 31 32 33 36 56 56 57 58 59 63 65 IV ■'S« 1. INTRODUCTION A computer-oriented language to describe and define a digital computer is developed. A description of a digital computer in this language may be translated by another computer into a simulator of the defined computer. Alternately, this description may be used as an input to a set of automated design procedures to specify an actual hard- ware configuration of the computer. A computer-oriented language is defined by a set of rules which determine how a string, or sequence of characters, to describe a digital computer may be constructed (syntax) and interpreted (semantics). Since the language consists of strings of characters, direct pictorial description of the computer as input is precluded. The description of the computer is completely contained within the language. Any natural language text (in particular, English) included in the description is redundant and used only for readability. The proposed language is an extension of ALGOL 60, augmented by additional data and procedure declaration capabilities. While the purpose of the language is to describe digital computer hardware, straightforward extensions to software applications are pointed out. A number of computer-oriented artificial languages for describing computers have appeared in the literature [l, 2, 3> ^-l- Although the method and scope of these languages vary considerably, their basic objectives are similar. The design of the computer-oriented language developed here is -1- -2- motivated by three primary goals. First, the language should permit the concise and unambiguous documentation of a digital computer. A language which is easy to learn and understand, yet comprehensive, will provide for effective communication of computer specifications. In addition, a good language can assist the computer system designer in the same way mathematical notation aids the electrical engineer in circuit design. A concise symbolism saves time and enhances the ability to find weaknesses in a design. Secondly, the language may serve as a source or input language to a translator that produces a simulator of a computer defined in the language. The simulator, which runs on an existing computer, will provide an accurate check on the design of the new computer since it is produced directly from the definition of the new computer. Finally, the description of the actual hardware configuration of a computer may be produced by a "computer compiler" from the definition of the computer in the language. The description of a new computer along with a statement of design criteria could be used by a set of computer programs to realize the new computer. The output of these programs might be l) boolean equations and sequencing information, 2) logic drawings, or preferably, 3) the actual specification of the printed circuit cards, location of the cards in bays, and wiring instructions. Although certain guidelines which determine speed and cost trade offs must be furnished, a computer program can reasonably be expected to perform all details of the design procedure. There is growing evidence that the specification of computer software and the specification of computer hardware share a common spirit although they diverge in implementation. Computers which use microprogrammed control sequencing [5, 6] demonstrate an overlap even in implementation. Based on lis premise, the proposed language is an extension of an existing programming -3- language, ALGOL 60. The additions which are made to facilitate hardware description are equally applicable in software applications [7]« In Chapter 2, a model for information structures is developed. The regular set concept of automata theory is extended to provide a model for information structures which are realizable by either hardware or software. In either realization, the model is applicable both to storage allocation and to information transfer and retrieval procedures. Extended data declarations (Chapter 3)> variables (Chapter h) , and procedure declarations (Chapter 5) are then developed for modification of ALGOL 6o. ALGOL 60 itself is not discussed here [8], Use of the proposed language to describe a simple computer is illustrated in Chapter 6. Implementation of the proposed language is discussed in Chapter 7* 2. INFORMATION STRUCTURES 2.1 Regular Sets Although equivalent formulations of regular sets will be found in the literature of automata theory [9* 10], we will define regular sets here as sets of strings over a finite alphabet Z generated as follows : i. A set containing a single string which is just one letter of the alphabet Z is a regular set. The null set, i.e. the empty string containing no letters, is also considered to be a regular set. ii. If A and B denote regular sets then the concatenation of A and B, denoted AB, is a regular set. AB consists of all strings formed by concatenating an element of A with an element of B such that the element of A is on the left, iii. If A and B denote regular sets then the disjunction of A and B, denoted A v B, is a regular set. A v B is the set of all strings contained in either A or B, i.e., the set theoretic union of A and B. iv. If A is a regular set then the iterate of A, denoted A* is a regular set. A* is the infinite set of all strings of finite length formed by the concatenation of strings from the set A. Hence A* consists of all strings of the following form: a, a 1 , o.^a 2 , a^cyx^, . . . -k- -5- where (X is the null, or empty, string and each a is a string from the set A. The expression (abc v db)*a, for example, denotes a regular set of strings over the alphabet a, b, c, and d. By rule i above, a, b, c and d are regular sets. By rule ii, abc and db, and hence by rule iii, (abc ^ db) are regular sets. Finally, by rule iv (abc ^ db)* and hence (abc v- db)*a are regular sets. Members strings of (abc v db)*a include abca, a, abcabcdbabca, dbabca, and dbdbdbdba. The strings db and aba are not strings of (abc v db)*a. Regular sets are just those sets of strings which may be classified by a finite state machine; they include all finite sets and many infinite sets of strings. The properties of regular sets have been thoroughly discussed in the literature. The expressions which are formed by joining the letters of the alphabet E with the operations of concatenation, disjunction, and iteration according to the definition of regular sets are called regular expressions. 2.2 Structure Sets The concepts of regular sets and regular expressions will now be extended to provide a model for information structures. Instead of symbols or letters we will let the alphabet Z designate a set of information cells. The members of L are distinguishable by the amount of information which each represents. In the simplest instance, each member of Z may denote an information cell containing exactly n bits--one and only one member for every positive integer n < N, for some given N. In general, each regular set now denotes a number of alternate sequences of information cells, although a unique sequence may be denoted. The fact that only sequences of information or data cells can be defined is not a serious restriction of the model since -6- any usable data structure can always be mapped into a sequence of information cells, such as consecutive words of a memory addressed by a sequence of integers. If we let the symbol (n) denote an information cell containing n bits where n is an integer, we may define sets of sequences of information cells by means of regular expressions on the alphabet {(n)). (l)(3)(5) and ((l)(U) v (3))* are examples. An information structure, however, consists of more than just a sequence of information cells. The grouping and internal structure associated with a sequence of cells is an integral part of an information structure. This additional property can be derived from the format of the regular expression. In particular, we will consider parentheses used in regular expressions to be essential to the specification of information structure. Parentheses specify hierarchial level of substructures in the information structure. A regular expression considered in this manner to define information structures will be called a structure expression . To aid in the interpretation of structure expressions we will associate a unique tree with each structure expression . Structure expressions which differ only in parentheses normally define different trees. Each explicit pair of parentheses (a right parenthesis and its corresponding left parenthesis in the structure expression) defines a node of the tree. An implicit pair of parentheses embracing the entire expression defines the root node. The parenthesis pairs embracing an integer in the alphabet {(n)} define terminal nodes of the tree. Additional implicit parentheses may be assumed by the precedence of operators as discussed below. If a sequence of parentheses pairs are contained immediately within a parentheses pair, the outer pair is the parent node while the inner parentheses pairs are sibling nodes connected by branches to the parent node. The sibling -7- nodes are ordered left to right in correspondence with the ordering inner parenthesis pairs. In general, every adjacent pair of parenthesis pairs in a sequence of parenthesis pairs will be separated by an operator (concatenation, disjunction, or iteration). A sequence of parenthesis pairs may be sibling nodes of the same parent node only if the parenthesis pairs are all separated by a concatenation operator (juxtaposition) or all separated by a disjunction operator (v). If this condition is not satisfied, additional parentheses will automatically be assumed according to the following rule: the operation of iteration takes precedence (lower hierarchial level in the tree) over concatenation which in turn takes precedence over disjunction. Each time the operation of iteration occurs a new node is implied. This new node has only one sibling node--the node corresponding to the expression iterated. Although each node corresponding to iteration has only one sibling node, it is equivalent to an infinite number of sibling nodes joined by disjunction. Each of these sibling nodes in turn corresponds to a finite concatenation of the single sibling node. In selecting a particular member, one of the concatenated nodes must be selected. For example, the structure expression ( (3)(*0 )( (1)(6)(3) ) - ( (5) - (2) ) * (9) - (1) has the tree shown in Figure 1. The single structure defined by ( (3)(^) )( (l)(6)(3) ) i- s one member of the set of structures defined by the example. The corresponding tree is given in Figure 2. Another member which demonstrates the selection of a member of an iterated substructure is ( (5) (2) (5) (5) )(9) whose tree is given in Figure 3 In summary, every structure expression defines a set of sequences -8- (3) (4) (I) (6) (3) (5) (2) FIGURE I. THE TREE CORRESPONDING TO ((3)(4))((l)(6)(3)v((5)v(2))*(9)v(|). (3) (4) (I) (6) (3) FIGURE 2. THE TREE CORRESPONDING TO ((3)(4))((l)(6)(3)). -9- (5) (2) (5) (5) FIGURE 3. THE TREE CORRESPONDING TO ((5) (2) (5) (5)) (9). FIGURE 4. A REPRESENTATION OF (((8)v(|6))D*. -10- of information cells. In addition, every structure expression has a unique corresponding tree. Each member of a structure set contains one sequence of information cells and has a unique associated subtree. Further, this subtree, and its corresponding structure expression, may be derived directly from the parent tree. We will define an idealized information structure as a tree corresponding to a structure expression which defines a single sequence of information cells. Any set of information structures which may be defined by an arbitrary structure expression will be called a structure set . A structure expression may alternatively be viewed as a generative grammar. The sentences generated by the grammar correspond to individual sequences of information cells. The set of all information cell sequences corresponds to the language generated by the grammar. An information structure then corresponds to a p-marker or derivation in the grammar while a structure set corresponds to the set of all p-markers which may be obtained from the grammar. Concepts such as equivalence of grammars also carry over to structure expressions. Two structure expressions are strongly equivalent if they define the same set of information structures and are weakly equiva- lent if they define the same set of sequences of information cells. 2.3 Interpretation of Structure Sets A structure set, defined by a structure expression which uses only concatenation, defines a set containing only one information structure. This class of expressions generally defines single registers and their organization in hardware applications. Similarly, in software applications, arbitrary arrays are defined by first grouping the cells into rows, then the rows into a two dimensional array, and so on for each additional dimension. In ral, a single finite sequence of information cells with any grouping -11- arrangement of neighboring cells or groups of cells may be specified by using only concatenation. The use of disjunction in structure expressions permits the specification of a set of alternate structures. By using disjunction at various levels within the structure expression the alternate structure can generally be defined without enumerating all possibilities. Alternate structures are specified by a data declaration with the understanding that only one structure of the set exists in any one instance. In another instance a different structure from the set might be selected. In software applications, choice of an alternate structure may either reallocate memory or reassign or reorganize the existing data structure. In hardware applications, alternate structures are limited to reorganization or reconnection of registers or equivalent memory. The iterate A* of a specified structure set A is interpreted as a stack. Each cell of the stack is a valid information structure from the structure set A which is iterated. An inexhaustible supply of available empty cells which are added to the stack as required is assumed. Hence the iterate of a structure set A, A*, denotes a finite unbounded sequence (possible empty) of cells from the structure A which corresponds to the programming concept of a stack. In software applications, the data structure defined by an iterated structure need not necessarily be a consecutive sequence in storage. For example, the structure set, (((8)v (16)) *) *, implies a stack of stacks where the cells of the internal stacks contain either 8 or l6 bits . The actual implementation of this structure might be a linked list structure using additional information cells or link cells to name the next consecutive sub-information structure or data cell. -12- This structure set might then be represented as shown in Figure k. Hardware implementation of arbitrary structure expressions using iteration will in general require a combination of hardware and software or micro- programming techniques. 3- DATA DECLARATIONS Additional data declarations will now be developed to augment the ALGOL 60 data declarations. These declarations, the format declaration and the field declaration , are based upon the information structure model developed in the last chapter. 3-1 Orientation Both format and field declarations are specified by format expressions , which implement and generalize the concept of structure expressions in the computer-oriented language. Format expressions will be built up from a set of terminal units by concatenation and disjunction in a manner similar to the way in which boolean expressions are introduced in ALGOL 60. Iteration will be reintroduced into the language in Chapter 7. When a field is declared, a register or mutable memory element is allocated. This memory will agree in number of bits and format with that specified by the corresponding format expression. A format declaration, on the other hand, does not declare a physical memory counterpart. A format declaration defines only a generalized information structure detached at the time of declaration from any specific register or memory realization. A declared format may be referred to in a field declaration. At this time, memory will be assigned in accordance with the declared format. Formats also appear in procedure declarations (cf. Chapter 5) to specify the formats of formal parameters and function identifiers; the information formats of buses, input lines and output lines -13- -ik- can be described in this manner. 3.2 Syntax The syntax for data declarations will be given in Backus Normal Form. We assume here that the reader is familiar with the specification of ALGOL 60 as defined in the "Revised Report on the Algorithmic Language - ALGOL 60" [8]. 1) ^declaration " = [ | | This syntatic definition adds format and field declarations to the set of ALGOL 60 declarations. Procedure declarations are extended for compatability in Chapter 5. The syntax and semantics of the remaining declarations are as given in the ALGOL 60 report. 2) 3) U) 5) FORMAT I FORMAT OR FIELD [FIELD OR | | | () ELSE -15- 7) 6) : := | * | : := [] | |() : := | | : denotes an empty sequence of symbols 8) 9) 10) 11 ) 12) | | •' I ' [arithmetic expression>] ' | I ' [arithmetic expression>] 0|l |l «&•: -16. The syntax and semantics of , , and are the same as for ALGOL 60 and will not be redefined here. 3-3 Semantics 3- 3-1 Format Primaries Format primaries define and label component information structures which in turn can be combined into larger information structures. Each format primary defines a component information structure in one of three ways. An arithmetic expression enclosed in square brackets denotes a single information cell containing the number of bits indicated by the arithmetic expression. Secondly, a format primary may be the name of a previously defined format. Finally the format primary may be a format expression, which is itself composed of format primaries. Each format primary creates a node in the tree of the information structure being defined. If the primary is a single information cell then a terminal node of the tree is indicated. If the primary is a previously defined format, the tree corresponding to that format is included in the structure, headed by that node. A format expression as a primary creates a nonterminal node in the tree. The branches from this node will in turn be determined by decomposition of the format expression. A format primary may also assign a label or name to each created node. Any ALGOL identifier may appear in the label part which will serve to identify the corresponding node in all future references to that node. A letter string followed by a colon preceding the identifier in the label part is treated as explanatory labeling and has no further interpretation. If the format expression appears in a field declaration, the -17- identifier appearing in the label part is declared as a field identifier. Since a field declaration allocates storage corresponding to the information structure , the field identifier references storage corresponding to the node designated by the primary. When the format expression appears in a format declaration the identifier is declared to be a format identifier. The format identifier labels the corresponding node of the tree but does not reference any storage at this time. If the format identifier is used as a primary in format expression of another declaration, the format identifier then becomes a label of the corresponding node in that declaration. If the latter declaration is a field declaration, the format identifier and all other identifiers in the tree headed by the format identifier become field identifiers labeling the corresponding storage allocated by the field declaration. Note that the same format may be used in many field declarations to allocate independent storage. To prevent ambiguity in designation, additional labeling conventions are given in Section 3«3«6. 3-3-2 Format Secondaries A format secondary may simply be a format primary, a format primary repeated an integral number of times, or a literal- The repetition of the same structure consecutively is common in digital computers and hence is worth special notation. The structure specified by the format primary preceding the asterisk is repeated (concatenated with itself). The number of times is specified by the arithmetic expression. Note that this operation is not the operation of iteration. A format secondary may also be a literal which is an unalterable information structure having a specified bit pattern. The literal is defined by specifying the bit pattern. The use of arithmetic expressions in specifying literals permits a bit pattern or literal to be repeated consecutively the -18- number of times specified by the arithmetic expression. Literals represent permanent or fixed memory in field declarations, and have a similar meaning in format declarations. 3.3.3 Format Terms The operation of disjunction in structure expressions is implemented through format terms. Each format term represents a sequence, possibly null, of disjunctions. Alternate format secondaries are separated by if clauses which determine which of the alternates is to be selected. The boolean expressions associated with the if clauses are evaluated sequentially. The first format secondary for which the corresponding boolean expression is true is the one selected. If no secondaries can be selected then the term corresponds to an empty information cell. A field declaration may only appear at the beginning of an ALGOL block. Each time an ALGOL block is entered, the format terms of a field declaration are reevaluated. Hence the memory defined by the field declaration may change dynamically. This is not to say that the registers or memory change physically but they may be logically reconnected or restructured dynamically. Format declarations are evaluated each time they are referred to. A previously defined format appearing in a field declaration is reevaluated every time the block embracing the field declaration is entered. A format declaration appearing in a procedure declaration is reevaluated each time the procedure is called. 3-3-^ Format Expressions The operation of concatenation in structure expressions is implemented at expressions. A format expression may consist of a single -19- format term or a finite sequence of format terms separated by commas. Each comma is equivalent to the operation of concatenation. 3.3.5 Format and Field Declarations A field declaration is formed by preceding a format expression with the word FIELD, while a format declaration is formed by preceding a format expression by the word FORMAT. In each case the format expression defines the structure and labeling of the format or field declared. A finite sequence of format or field declarations separated by the word OR provide yet another form of disjunction. While format terms permit selection of alternate structures, only one structure is valid at any given time. All alternate declarations separated by OR define alternate structures for the same format or field and are simultaneously valid. In this sense, information may be considered to be contained in a single sequence of bits to which a number of alternate structures are applicable. The alternate structures are distinguished solely by their labeling. Each declaration in the sequence is independent, but must specify the same number bits. The separation of the declarations by OR signifies that they pertain to the same format or field. The first declaration in the sequence will be called the principal structure and its significance will become apparent in the next chapter. 3-3-6 Labeling Each label associates an identifier with a node of the tree corresponding to the defined information structure. For example, the tree corresponding to the format expression, A(AA(BA(CA[3], [5])*2), BB(CA[2], CC[6])) is shown in Figure 5- -20- (2) (6) FIGURE 5. THE TREE CORRESPONDING TO A(AA(BA(CAC33, C51) * 2), BB(CAC2:, CCC61)). ■ ■ ' ■ l— I L i i i CA CA J V BA, AA BA, CA CC J V BB FIGURE 6. THE REGISTER FORMAT CORRESPONDING TO A(AA(BA(CAC3], [5])* 2), BB(CAC2], CCC6])). -21- Alternately the expression could also be drawn as shown in Figure 6, which more graphically represents an actual memory or register format. Identifiers must uniquely denote a single sub -information structure. However the identifiers themselves need not be unique. In general, the identifiers of higher level nodes will be required to distinguish between identifiers of lower level nodes, as for example, BA and BB are required to distinguish between the fields identified by CA. When an information structure is duplicated an integral number of times the component substructures must be distinguished by indexes as are BA„ and BA, • The format expression A([3], IF N > 2 THEN B[N] ELSE B[2] ) is permitted since at any given time either B[N] is valid or B[2] is valid depending on the value of N. In summary, every labeled format primary introduces a new level of labeling which permits any identifier to be used within that primary provided it is unique within that level of labeling. Similarly, the labeling of each format secondary within the same format term is independent of the labeling within the other secondaries. k . VARIABLES Variables are the means of accessing defined information structures. A field variable is added to the ALGOL set of variables to reference the additional information structures which can be defined in this language. Field variables may be used in any statement where ALGOL permits the use of simple or subscripted variables. k.l Syntax of Variables l) : := | Subscripted variable> | ::= | | The symbol I denotes concatenation 2) 3) k) 5) | | [] . ] -22- •23- 6) 7) I , | U.2 Semantics of Variables 1+.2.1 Field Variables Field variables are formed by concatenating a sequence of field segments. Each field segment either is a literal (as defined in Section 3.3.2) or designates some portion of a declared field or formated function designator by means of a field specifier list. In this manner, portions of various registers and other information sources can be connected together along with constants (literals) to form one variable or information source. A variable may be formed from a number of structures or from a single information structure which is decomposed and reassembled in another order. !+.2.2 Field Specifier List A field specifier list is a sequence of field specifiers separated by the punctuation ".". A field specifier list designates a substructure of a declared information structure by naming successive substructures in the tree corresponding to the structure. The first field specifier in the list must uniquely designate an information structure or substructure. Each succeeding field specifier in sequence designates successive substructures. Since the identifiers naming substructures are not necessarily unique to one information structure, a sequence of field specifiers will often be required to uniquely designate one information field. Only as many field specifiers need to be used, however, as are required for -2k- uniqueness . A function designator, with or without a subscript list, may- appear as the first field specifier in the field specifier list. The remaining field specifiers in the list must then refer to a format which has been assigned to the function designator in its declaration. An access function designator beginning a field specifier list is treated the same as a field identifier; it differs only inasmuch as the procedure must be executed to retrieve the information. If the variable appears in the left part of an assignment statement, indicating a value is to be assigned to the variable, the function designator can only be a store procedure identifier; otherwise the function designator can only be an access procedure identifier. A store and an access procedure having the same identifier can then be distinguished in this manner. U.2.3 Field Subscript List A field specifier may be a single field identifier or it may be a field identifier followed by a field subscript list enclosed in square brackets. The field identifier specifies a sub-tree headed by the node with the corresponding identifier. A subscript list, following the identifier, selects a sub-tree of this sub-tree. The first subscript in the list selects a number of branches from the identified node. Each succeeding subscript in the list selects branches from the next lower level ode -- the nodes on each of the branches selected by the previous subscript. Each subscript is either a single arithmetic expression or two arithmetic expressions separated by a colon. A single arithmetic expression signates a single branch -- the branch whose index is the value of the unetic expression. The indexing begins with the integer "0". When the : expre: are used, the first designates the first branch -25- tc be selected and the second arithmetic expression designates the number of consecutively higher indexed branches to be selected, including the first branch. For example, given the format expression A(B(C((([3], ft])*3)2), [2]> C [3]), whose tree is given in Figure 7 > the field variable, B.C[0:2, 1, 1, 0:3]; designates the sub- information structure indicated in Figure 8 where only the first 3 bits of the four bit cell are included. When a sequence of alternate field or format declarations, separated by OR, define alternate structures for the information source, identical labeling may also be used to reference the same information in many of the alternate declarations. The labels are not multiply defined since they refer to the same information even though they may have alternate structures. When these labels are subscripted in variables, however, ambiguity may arise. The ambiguity will always be resolved by consulting the first or principal declaration in the sequence. For example, let the following field declaration be given FIELD A([3]*2, [3]*3, [3]*2) OR FIELD A (B (C[3L D[6]), E[6], F[6]. The corresponding trees are given in Figures 9 and 10 respectively; the variable A [1:2] denotes the sub--tree of this tree as given in Figure 11. The same sequence of information cells could also be designated by the variable, D[3=3] | | E | | F. h.2^h Interpretation of Variables The purpose of a variable is to reference a declared information structure. The designated accessed information is considered as a single sequence of bits without regard to structure. If the variable appears in a boolean expression or in an equality relation, then the variable is considered -26- (3) (4) (3) (4) (3) (4) (3) (4) (3) (4) (3) FIGURE 7. THE TREE CORRESPONDING TO A(B(C(((C3], [4])*3)*2), C21), CC31). FIGURE 8. THE SUB -TREE ACCESSED BY THE VARIABLE B. CCO=2, I, I, 0=33. -27" (3) (3) (3) (3) (3) (3) (3) FIGURE 9. THE TREE CORRESPONDING TO A([3]*2, C3]*3, C3]*2). B /T E, i ^^»F (6) (6) c/ \d (3) (6) FIGURE 10. THE TREE CORRESPONDING TO A(B(CC3], DC6]), EH6], FC6]). (3) (3) (3) (3) (3) FIGURE II. THE SUB-TREE ACCESSED BY ACh2D -28- as a bit sequence with the operation applying to individual bits. If the variable appears in an arithmetic expression or in a relation (<, >, >, or >) then the variable is considered to be the integer corresponding to the bit sequence. When the variable appears in the left part of an assignment statement, the information is transferred to the substructure designated by the variable as a bit string; any other form of information is converted to a bit string before the transfer. 5- PROCEDURE DECLARATIONS Store and access procedures are introduced to facilitate storage and retrieval procedures respectively. An access procedure is similar to real, boolean, or integer procedures of ALGOL 60. Here however the value of the function designator is an arbitrary information structure rather than restricted to real, boolean, or integer type. A store procedure can appear only in the left part of an assignment statement and serves the opposite purpose of that of an access procedure. ALGOL procedures and functions are also augmented by permitting formal parameters to be specified by formats as well as by the usual ALGOL specifiers. 5-1 Syntax 1) : := PROCEDURE 2) : := REAL | BOOLEAN INTEGER | | ACCESS | STORE 3) : := ; Specification part> h) Specification part> : := | ; i ; | : '.- This syntax is essentially the same as the procedure declaration -29- -30- syntax of AKOL 60. Definition 2) introduces STORE and ACCESS as procedure types and k) permits format declarations as specifications in the specification part of a procedure declaration. For syntax of procedure identifier^ , , , and identifier list> see the revised AICOL 60 report [8] . 5.2 Semantics 5.2.I Formal Parameters The formal parameters of procedures and functions in AI£0L 60 may only he specified as boolean, real, or integer by the AI£0L specifiers, in addition, the proposed language permits arbitrary structure to be assigned to formal parameters. The structure is assigned by a format specification in the specification part of the procedure declaration. The format specification consists of a format declaration in which one primary is labeled with the identifier of the formal parameter. When a formal parameter in a procedure is specified as a format as distinct from real, boolean, or integer, the actual parameter which replaces the formal parameter when the procedure is executed must consist of a compatible number of bits. The structure of the actual parameter, however, need not be the same as the specified structure of the formal parameter. Upon execution of the procedure the actual parameter will be converted to a bit string; the tree structure and labeling of the formal parameter will be assigned to the actual parameter. In this sense, an automatic conversion of type takes place when an actual parameter replaces a formated formal parameter (either by name or by value) in the call of a procedure or . This conversion of type (format) only takes place when the parameters are compatible in number of bits. They are compatible when the -31- selected format of the actual parameter has the same number of bits as the selected format of the formal parameter. The format of the formal parameter may then be used to reference the actual parameter within the body of the procedure declaration. Call by value and call by name apply in the procedure declarations of the proposed language as they do in ALGOL 60. 5.2.2 Access Procedures Access .rocedures access functions) are similar to the ALGOL 60 functions but may have an arbitrary format rather than a specific type. The real, boolean, or integer procedures (functions) of ALGOL may be considered as special cases of access procedures whose formats are real, boolean, or integer respectively -- "formats" that require no further specification. Access procedures, however, require a format declaration to specify the precise format of the function designator. The access procedure is called and evaluated whenever its function designator appears in a variable which is not contained in the left part of an assignment statement. The variable may designate the whole structure associated with the function designator or any subfield (cf. Section U.2.2). In any case, the complete value of the function is obtained and then the value of the designated subfields of the function is assigned as the value of the variable. As with the ALGOL function declarations, there must be at least one assignment statement in the procedure body in which the access function designator appears in the left part. A number of assignment statements may be used where each assignment statement assigns the value of some subfield of the function designator by making use of the structure assigned by the format declaration. Every execution of the procedure must, however, define the value of every bit in structure associated with the function designator. -32- 5.2.3 Store Procedure^ A store procedure deviates from the ALGOL interpretation of functions. The procedure identifier in ALGOL, which is a function designator when the procedure defines a function, serves two purposes. It serves to call the execution of the procedure and it serves as a placeholder for the value of the function within the statement that calls the procedure. In every case, the procedure provides a value which is then used in the calling statement. In addition, these function calls may never occur in the left part of an assignment statement. Conversely, the appearance of a store procedure identifier always occurs in the left part of an assignment statement. Again the procedure identifier serves to call the execution of the procedure but it also serves as a placeholder for information to be transferred to the procedure. As with access procedures, a format declaration in the specification part of the procedure declaration assigns a format to the store procedure identifier. The calling assignment statement transfers a value to each bit of the store procedure identifier under the same conditions as for replacing formal parameters with actual parameters. A store procedure could alternately be viewed as a pure procedure whose first formal parameter is formated and has the same identifier as the procedure itself; then in a store procedure this first formal parameter is deleted and the procedure identifier is used instead. The store procedure itself transfers the value of the procedure identifier into fields declared outside of the procedure declaration. This is accomplished by appearances of the procedure identifier within assignment tatements in procedure body, but not in the left part of these assignment batements. The structure assigned the store procedure identifier may be to assist in the transfer of information by the procedure. ■33- The information flow in store and access procedures is summarized in Figure 2. The appearance of an access function designator as a variable serves to call the procedure and designate how the retrieved information is to be used. The access procedure accepts actual parameters in the specified format and then transfers information from declared fields to the variable. By contrast, an assignment statement which calls a store procedure transfers information to the variable represented by the store function identifier. The store procedure then accepts the actual parameters and transfers the information from the variable to declared fields. 5.3 Hardware Interpretation The primary use of procedures and functions in the proposed language is to simplify the description of a computer by providing a convenient abbreviation for statement sequences which occur frequently in the description. They also improve the readability of the description. Procedures can be specifically interpreted in hardware applications as defining control subsequences, combinatorial logic functions and gating. Figure 12, depicting information flow, can be interpreted for this purpose. Each store or access procedure is represented by a block of logic which will include sequencing logic, if any. A store procedure takes information from an input bus (formated information to be stored) along with parameters which are obtained from the instruction decoding logic or other sources and gates the information into a set of memory elements (declared fields). The access procedure defines the logic to gate information from memory elements to an output bus (formated retrieved information) . Store and access procedures can provide the identification and description of specific buses or data lines. Since data buses do not have 3^ FORMATED .INFORMATION TO BE STORED, FORMATED RETRIEVED INFORMATION PARAMETERS s . / STORE PROCEDURE PARAMETERS ACCESS PROCEDURE STORAGE WHICH HAS BEEN ALLOCATED BY FIELD DECLARATIONS FIGURE 12. INFORMATION FLOW IN STORE AND ACCESS PROCEDURES. -35- memory capacity they cannot be defined by a field declaration. Buses reflect the content of memory elements and are assigned a format through a procedure declaration. 6. SAMPLE DESCRIPTION OF A COMPUTER The computer which will be described in the proposed language l is essentially taken from the design of ILLIAC III [ll]. The order code has been reduced and modified and certain aspects of the organization changed to obtain a smaller, but complete, machine. This example is not intended to present a practical machine but rather to point out features of the proposed language. Briefly, the reduced machine is organized as follows: i) A main store consisting of l6, 777>2l6 bytes of memory is accessed by a 2k bit address. Each byte consists of 8 data bits and a flag bit. Four base registers are used to define files containing up to 2^6 consecutive pages (256 bytes per page) in the main store. A base register designates the address (high order l6 bits) of the first page and the total number of pages (8 bits) in the corresponding file. Memory is addressed relative to a defined file by a l6 bit pointer. Eight pointer registers are provided for this purpose. Each pointer register has a two bit base name which associates a base register with the pointer register, ii) All operations are done within an operand stack which consists of a file defined by a base register and a pointer designating the next available byte in the stack. The stack consists of all bytes from the beginning of the file -36- -37- to the byte designated by pointer 1, the stack pointer. The length of the operands are designated by a cell size field in the instructions and may designate operands of 1, 2, h, and 8 bytes in length. Unary operations apply to an operand of the specified cell size at the top of the stacks while binary operations apply to the top two operands , both of the specified cell size. Although 32 bytes of fast register are provided to contain the "upper- most part of the stack, all programming conventions are as though the stack were located completely in core, iii) Input/output is accomplished through a paper tape reader/ punch. Read and write orders are furnished which transfer a single byte between the operand stack and reader/punch. The organization of the system is shown in Figure 13- While the details of the order code should be clear from the description of the computer in the proposed language, the order code can be summarized as follows . There are four basic instruction formats as shown in Figure lk. The ninth or flag bit of each instruction byte is not used. The tag field designates the pointer register used in the execution of the instruction. The cell size field CSV designates the length of the operands of the instruction; operands lengths are one, two, four, or eight bytes. The four instructions having format 1 are PUSH, POP, LOAD, and STORE. These instructions transfer a single operand of the specifier cell size between the operand stack and the core memory. The pointer designated by the tag field is used (with the base register associated with the pointer register) to address core memory. PUSH transfers data from core to the next empty cell in the operand stack. POP transfers data from the operand stack -38- CONSOLE KEYS AND LIGHTS CORE MEMORY 2 24 BYTES PAPER TAPE READER/PUNCH ARITHMETIC, LOGIC, AND CONTROL UNIT OPERAND STACK (32 BYTES) FIGURE 13. SYSTEM ORGANIZATION OF EXAMPLE COMPUTER. TAG OP CSV FORMAT TAG i I OP ■ ' ' ■ ■ i MODIFIER ■ ' ' I ' ■ ' ' ' MODIFIER _l l I i i i i FORMAT 2 OP I l l I l I I I I FORMAT 3 OP i i I '''' CSV ]_ FORMAT 4 FIGURE 14. EXAMPLE COMPUTER INSTRUCTION FORMATS. -39- to core ; deleting the top cell of the operand stack after the transfer. LOAD replaces the top cell of the operand stack with a cell from core; and STORE places the top cell of the stack in core without deleting the cell from the stack. The next four instructions use a shortened format 2 which does not have a modifier. Load and store base register (LDBR and STBR) loads the base register designated by the low order two bits of the tag field from the top cell in the operand stack or stores the base register in the top cell respectively. Store pointer register (STPR) stores the designated pointer register in the operand stack including the flags. Load pointer (LDPNT) loads only the pointer of the designated pointer register from the operand stack leaving the original base name in the pointer register. The next four instructions use format 2 with a modifier. Set pointer and set pointer register (SETPNT and SETPR) transfer the modifier to the designated pointer register with or without the flags respectively. Increment pointer (INCR) adds the modifier to the designated pointer without changing the flags. Compare modifier to pointer (CMPPNT) and set the equal and the equal/greater indicators accordingly, while leaving the pointer register unchanged. The READ, WRITE, NOP (no operation), and HALT instructions have format 3 as well as the following set of four conditional skip instructions: IFLESS executes the next instruction only if the equal/greater indicator is set; IFEQ and IFGR execute the next instruction only if the equal or the equal/greater but not the equal indicators are set respectively; IFOVFL executes the next instruction only if the overflow indicator is on and then turns the overflow indicator off. The remaining fourteen instructions use format k. The logical instructions (AND, OR, EOR) and the arithmetic instructions (ADD, SUB, ■40- MPY) operate on the top two cells of the designated cell size in the operand stack. These top two cells are popped from the operand stack and the result is then pushed back into the stack. The negate (NEG) instruction replaces the top cell of the operand stack with its two's complement while the complement instruction (COMP) replaces it with its logical complement. The IFZERO and IFNEG instructions are skip type instructions which execute the next instruction only if the top cell is zero or negative respectively. The compare instruction (CPR) compares arithmetically the top two cells of the stack and sets the equal and equal/greater indicators accordingly. The exchange instruction (EXCH) exchanges the top two cells of the operand stack and the zero instruction (ZERO) sets the top cell to zero. The shift instruction (SHIFT) shifts the data bits of the top cell in the operand stack circularly one bit left. A jump instruction is not required since pointer register is the instruction pointer which may be modified as any other pointer register. 4l- BEGIN COMMENT The following declarations define the memory requirements of the sample computer; FORMAT BASIC INFORMATION CELL: BYTE(DATA [8], FLAG[l]); FIELD CORE MEMORY: MEMORY(BYTE) * 2 f 2k); FIELD BASE REGISTERS: BR ((BYTE * 3) *k) ; FIELD POINTER REGISTERS: PR ((BYTE * 2) *8 ) ; COMMENT Up to 32 bytes of the top of the operand stack can be contained in the register, OSR. The number of bytes of the stack held in OSR is specified by the register, OSRD. The operand stack pointer is P(l); FIELD OPERAND STACK REGISTER: OSR (BYTE * 32), OPERAND STACK REGISTER DEPTH: 0SRD[6]; COMMENT The following registers will be used in the definition of the instructions; FIELD TEMP(BYTE * l6), COUNT[6], EXB[l]; COMMENT indicators; FIELD OVERFLOW: OVFL[l] ; CONDITIONS: COND (GREATER OR EQUAL: GEFF[l], EQUAL: EQFF[1]), BOUNDS[l]; COMMENT Console control keys; FIELD STARTKEY[1], AUT0KEY[1], DATAKEYS(BYTE *3), REGSEL[U], INSERT[l]; COMMENT The instruction decoding register is provided with four formats for the four instruction types; FIELD INSTRUCTION DECODING REGISTER: IDR(BYTE * 3) OR FIELD TAG[3], 0P1[3], CSV[2], [19] -1*2- OR FIELD TAG[3], OP2[5L UL MODIFIER(BYTE * 2) OR FIELD OP3[8], [19] OR FIELD OPl*[6], CSV[2', [19]; COMMENT The RDFF and WRTFF are communication flipflops between the computer and the reader/punch; FIELD RDFF[l], WRTFF [l]; COMMENT The following procedures define the pointer, page "base, page count, and base name subfields; COMMENT The pointer P located in each pointer register consists of the 16 data bits of the register; ACCESS PROCEDURE P(PN); FORMAT P[l6], PN[3]j P := PR[PN].DATA; STORE PROCEDURE P(PN); FORMAT P[l6], PN[3]; PR [PN]. DATA := P; COMMENT The page base PGB consists of the data bits of the first two bytes of the base register; ACCESS PROCEDURE PGB(BN); FORMAT PGB[l6], BN[2]; PGB := BR[BN, 0:2]. DATA; STORE PROCEDURE PGB(BN); FORMAT PGB[l6], BN[2]; BR[BN, 0:2]. DATA := PGB; JENT The page count, PGC, consists of the data bits of the third byte of the base register; '•;33 PROCEDURE PGC(BN); FORMAT PGC[8], BN[2]; ■43- PGC := BR[BN, 2]. DATA; STORE PROCEDUEE PGC(BN); FORMAT PGC[8], BN[2]; BR[BN, 2]. DATA := PGC; COMMENT The two flag bits of the data register specify the associated base register ABR for each pointer; ACCESS PROCEDURE ABR(PN); FORMAT ABR[2], PN[3l; ABR := PR[PN].FLAG; STORE PROCEDURE ABR(PN); FORMAT ABR[2], PN[3]; PR [PN]. FLAG := ABR; COMMENT The following procedures will be required in the definition of the instruction set of the computer; COMMENT A fixed length field (l, 2, k, or 8 bytes) in memory may be accessed by specifying a pointer register and cell size variant; ACCESS PROCEDURE CORE(PN, CS); FORMAT PN[3], CORE(BYTE *CS); INTEGER CS; BEGIN IF PGC(ABR (PN)) X 2 t 8 < P(PN) + CS THEN GO TO BOUNDCHECK; CORE := MEMORY [ PGB( ABR (PN)) x 2 t 8 + P(PN) : CS] END ; STORE PROCEDURE CORE(PN, CS); FORMAT PN[3L CORE(BYTE *Cc) ; INTEGER CS; BEGIN IF PGC(ABR(PN)) x 2 t 8 < P(PN) + CS THEN GO TO BOUNDCHECK; MEMORY [ PGB( ABR (PN)) x 2 t 8 + p(PN) : CS] := CORE END; COMMENT Convert cell size variant to cell size; ACCESS PROCEDURE CS; CS := 2 t CSV; -¥+- COMMENT TOP obtains the top cell of size CS from the operand stack. If the operand stack register does not contain enough information, 8 bytes are brought into the stack from core. ACCESS PROCEDURE TOP(CS); FORMAT TOP(BYTE *CS)j INTEGER CS; BEGIN FIELD PART [6]; IF OSRD < CS THEN BEGIN PART := P(l) [0:13] | | , 0[3]' + 8; IF PGC(ABR(l)) x 2 t 8 < PART + 8 THEN GO TO BOUNDCHECK; 0SR[PART[11:5] : 8] : = MEMORY [PGB[ABR(l)) x 2 t 8 + PART : 8]j OSRD := OSRD + 8 END ; PART := P(l) - 8; TOP := 0SR[PART[11:5] : IF PART[11:5] + CS > 32 THEN 32 - PART[11:5] ELSE CS] | | 0SR[0: IF PART[ll:5] + CS > 32 THEN PART[11:5] + CS - 32 ELSE 0] END; COMMENT The store procedure top places a cell of size CS into the operand stack. If the operand stack register does not contain room, 8 bytes are dropped into core. STORE PROCEDURE TOP; FORMAT TOP (BYTE *CC); INTEGER CS; BEGIN FIELD PART[l6]; IF OSRD + CS > 32 THEN BEGIN -45- PART : = P(l) - 31; PART := PART[0:13] || '0[3]'; IF PGC(ABR(l)) x 2 t 8 < PART + 8 THEN GO TO BOUNDCHECK; MEMORY [PGB(ABR(l)) X 2 f 8 + PART] := OSR [PART[ll:5] : 8] OSRD := OSRD - 8; END ; PART := P(l)[0:13] | | '0[3]'> OSR [PART[11:5] : IF PART[ll:5] + CS > 32 THEN 32 - PART[11:5] ELSE CS] OSR [0: IF PART[ll:5] + CS > 32 THEN PART[11:5] + CS - 32 ELSE 0] END; COMMENT Procedure to place stack in core; PROCEDURE STACKDOWN(CELirTFT); FORMAT CELLSLEFT[2]; BEGIN IF OSRD < CELLSLEFT THEN GO TO STD2; SDT1: P(l) := P(l) - OSRD; C0RE(P(1), 1) := 0SR[P(l)[ll:5]]; OSRD := OSRD - 1; P(l) := P(l) + l; IF OSRD > CELLSLEFT THEN GO TO STD1; P(l) := P(l) + CELLSLEFT; STD2 : END ; COMMENT If the operand stack pointer is modified such that the pointer is not at an integral multiple of 8, the top part of the stack is loaded to an integral multiple of 8; -k6- PROCEDURE I STACK; BEGIN FIELD PART[l6]; IF P(1)[13:3] = THEN BEGIN OSRD : = 0; IF AUTOKEY THEN GO TO NEXT ELSE GO TO WAIT END ; PART := P(l)[0:13] | | '0[3]*j IF PGC(ABR(l)) x 2 t 8 < PART + 8 THEN GO TO BOUNDCHECK; 0SR[PART[ll:5] : 8] := MEMORY [PGB(ABR(l) ) x 2 t 8 + PART OSRD := P(l)[ll:5] IF AUTOKEY THEN GO TO NEXT ELSE GO TO WAIT END ; 8]; COMMENT The following section may be considered as master control. The computer begins operation with the statement WAIT. If the STARTKEY is depressed an instruction is executed and the computer will continue execution of instructions while AUTOKEY is set. Manual insertions may be made while the computer is in a waiting mode. WAIT: IF INSERT THEN BEGIN IF REGSEL[0] = THEN PR[REGSEL[ 1 : 3] ] := DATAKEYS [ : 2 ] ELSE IF REGSEL[0:2] = '01' THEN BR[REGSEL[2: 2] ] := DATAKEYS; INSERT := 0; IF REGSEL ^ '0001' THEN ISTACK END ELSE IF STARTKEY GO TO START ELSE GO TO WAIT; SKIP: P(0) := P(o) + 1; IDR := C0RE(0, i+)[0:3]; NEXT: IF 0P1 = '111' THEN P(0) := P(o) + 3 ELSE P(o) := P(0) + 1; ■47- IF AUTOKEY THEN GO TO START ELSE GO TO WAIT; BOUNDCHECK: BOUNDS := 1; GO TO HALT; START: IDR := CORE(0, U)[0:3]; COMMENT Begin instruction decoding; IF OP1 = 'OOO' THEN GO TO PUSH; IF 0P1 = '001* THEN GO TO POP; IF 0P1 = 'Oil' THEN GO TO LOAD; IF 0P1 = '010' THEN GO TO STORE; IF 0P2 = '11000' THEN GO TO LDBR; IF 0P2 = '11001' THEN GO TO LDPNT; IF 0P2 = ' 11011 ' THEN GO TO STBR; IF 0P2 = ' 11010 ' THEN GO TO STPR; IF 0P2 = '11110' THEN GO TO SETPR; IF 0P2 = '11111' THEN GO TO SETPNT; IF 0P2 = '11101' THEN GO TO INCR; IF 0P2 = '11100' THEN GO TO CMPPNT; IF 0P3 = '00010000' THEN GO TO READ; IF 0P3 = '00010001' THEN GO TO WRITE; IF 0P3 = '0001001' THEN GO TO NOP; IF 0P3 = '00010010' THEN GO TO HALT; IF 0P3 = '00010110* THEN GO TO IFLESS; IF 0P3 = ' 00010111 ' THEN GO TO IFGR; IF 0P3 = '00010101' THEN GO TO IFEQ; IF 0P3 = '00010100' THEN GO TO IFOVFL; -kQ- PUSH: IF OPU = 'OOllOO' THEN GO TO ADD; IF OFk = '001101' THEN GO TO SUB; IF OPk = '011100' THEN GO TO MPY; IF OFk = '011101' THEN GO TO NEG; IF OFk = '010100' THEN GO TO AND; IF 0P4 = '010101' THEN GO TO OR; IF OFk = '110100' THEN GO TO EOR; IF OFk = '110101' THEN GO TO COMP; IF OPU = '111100' THEN GO TO IFZERO; IF OPU = '111101' THEN GO TO IFNEG; IF OPU = '101100' THEN GO TO CPR; IF OPU = ' 101101 ' THEN GO TO EXCH; IF 0P4 = '100100' THEN GO TO ZERO; IF 0P4 = '100101' THEN GO TO SHIFT; IF TAG = 1 THEN GO TO NEXT; P(l) := P(l) + CS; ORSD := ORSD + CS; TOP(CS) := CORE (TAG, CS); GO TO NEXT; POP: IF TAG = 1 THEN GO TO NEXT; CORE(TAG, CS) := TOP(CS); P(l) := P(l) - CS; ORSD := ORSD - CS; GO TO NEXT; -l4 9 - LOAD: IF TAG = 1 THEN GO TO NEXT; TOP(CS) := CORE(TAG, CS); GO TO NEXT; STORE: IF TAG = 1 THEN GO TO NEXT; CORE(TAG, CS) := TOP(CS); GO TO NEXT; COMMENT Load base register; LDBR: BR[TAG [1:2]] := TOP(CS)[l: 3] J P(l) := P(l) - hi OSRD := OSRD - k; GO TO NEXT; COMMENT Load pointer; LDPNT: IF TAG = 1 * OSRD - 2 > THEN STACKD0WN(2); P(TAG) := T0P(2).DATA; IF TAG = 1 THEN ISTACK: P(l) := P(l) - 2; OSRD := OSRD - 2; IF TAG = THEN GO TO START ELSE GO TO NEXT; COMMENT Store base register; STBR: P(l) := P(l) + k; OSRD := OSRD + k} TOP(*0 := *0[9]' || BR[TAG[1:2]]; ■ 50- G0 TO NEXT; COMMENT Store pointer register; STPR: TEMP[0:2] := PR[TAG]; P(l) := P(l) + kl OSRD := OSRD + k; T0P(2) := TEMP[0:2]; GO TO NEXT; COMMENT Set pointer register; SETPR: IF TAG = 1* OSRD > THEN STACKDOWN(O); PR [TAG] := MODIFIER; IF TAG = 1 THEN ISTACK; IF TAG = THEN GO TO START ELSE GO TO NEXT; COMMENT Set pointer; SETFNT: IF TAG = 1* OSRD > THEN STACKDOWN(O); P(TAG) := MODIFIER. DATA; IF TAG = 1 THEN ISTACK; IF TAG = THEN GO TO START ELSE GO TO NEXT; COMMENT Increment pointer; INCR: IF TAG = 1 THEN STACKDOWN(O) ; P(TAG) := P(TAG) + MODIFIER. DATA; IF TAG = 1 THEN ISTACK; IF TAG = THEN GO TO START ELSE GO TO NEXT; -51- COMMENT Compare modifier to pointer and set conditions; CMPPNT: IF MODIFIER. DATA > P(TAG) THEN GEFF := 1 ELSE GEFF : IF MODIFIER. DATA = P(TAG) THEN EQFF :« 1 ELSE EQFF : GO TO NEXT; = 0; = 0; COMMENT Each read execution takes one character from paper tape. RDFF is set to indicate RDBUFF has been cleared and is reset by tape unit when RDBUFF is loaded. READ: IF RDFF = 1 THEN GO TO READ; P(l) := P(l) + 1; OSRD := OSRD + 1; TOP(l) := RDBUFF; RDFF := 1; GO TO NEXT; COMMENT Each write execution place one byte in WRTBUFF. WRTFF is reset when byte is punched; WRITE: IF WRTFF = 1 THEN GO TO WRITE; WRTBUFF := TOP(l); WRTFF := 1; P(l) := P(l) - l; OSRD := OSRD - 1; GO TO NEXT; NOP: GO TO NEXT; HALT: P(0) := P(0) + 1; GO TO WAIT; IFLESS: IF — ,GEFF THEN GO TO NEXT ELSE GO TO SKIP; ■52- IFGKt IF— »EQFF ^ GEFF THEN GO TO NEXT ELSE GO TO SKIP; IFEQ: IF EQFF THEN GO TO NEXT ELSE GO TO SKIP; IFOVFL: IF OVFL THEN GO TO SKIP; OVFL := 0; GO TO NEXT; COMMENT All arithmetic is modulo 2 t (8 x CS). All numbers may be considered positive or if the highest order bit is one the number may be considered negative. Overflow is indicated on addition. ADD: TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; EXB || TOP(CS).DATA := TEMP[0: CS].DATA + TOP(CS) .DATA; IF EXB = 1 THEN OVFL := 1; GO TO NEXT; SUB: TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; TEMP [0: CSj.DATA := TOP(CS).DATA - TEMP[0: CS].DATA; TOP(CS) := TEMP[0: CS]; GO TO NEXT; MPY: TEMP := 0; TEMP[l6 - CS: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; COUNT := 8 x CS - 1; TEMP [0: CS].FLAG := TOP(CS).FLAG -53- NEG: AND: OR: EOR: LOOP: IF TEMP[l6].DATA[8] = THEN EXB | | TEMP[0: CS]- DATA := EXB | | TEMP[0: CS].DATA + TOP(CS) .DATA; TEMP. DATA := EXB || TEMP[ 0:15]- DATA | EXB := 0; IF COUNT = THEN GO TO OUT; COUNT := COUNT - 1; GO TO LOOP; OUT. TOP(CS) := TEMP[0: CS] • P(l) := P(l) + CS; OSRD := OSRD + CS; TOP(CS) := TEMP[CS : Cr" GO TO NEXT; TOP(CS).DATA := - TOP(CS) .DATA; GO TO NEXT; TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; TOP(CS) := TOP(CS) a TEMP [0: CS] ; GO TO NEXT; TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; TOP(CS) := TOP(CS) v TEMP [0 : CS]; GO TO NEXT; TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; TEMP[l6].DATA[0:7l; •5k- CCMP: IFZERO: IFNEG: CPR: EXCH: ZERO: OSRD := OSRD - CS; TOP(CS) := 'iTOP(CS) * TEMP[0: CS] v — |TEMP[0: CS] * TOP(CS); GO TO NEXT; TOP(CS) := — |TOP(CS); GO TO NEXT; IF TOP(CS) = THEN GO TO NEXT ELSE GO TO SKIP; IF TOP(CS)[0] .DATA[0] = 1 THEN GO TO NEXT ELSE GO TO SKIP; TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; IF TOP (CS). DATA < TEMP[0: CS]].DATA THEN GEFF := 1 ELSE GEFF := 0; IF TOP(CS).DATA = TEMP[0: CS] .DATA THEN EQFF := 1 ELSE EQFF := 0; P(l) := P(l) + CS; OSRD := OSRD + CS; GO TO NEXT; TEMP[0: CS] := TOP(CS); P(l) := P(l) - CS; OSRD := OSRD - CS; TEMP[8 : CS] := TOP(CS); TOP(CS) := TEMP[0: CS] ; P(l) := P(l) + CS; OSRD := OSRD + CS; TOP(CS) := TEMP[8: CS] ; GO TO NEXT; TOP(CS) := 0; GO TO NEXT; -55- COMMENT The data bits of the top cell are rotated left circularly one bit; SHIFT: TEMP [0: CSJ.FLAG := TOP(CS) .FLAG; EXB || TEMP [0: CS - lj.DATA || TEMP [CS - l].DATA[0:7] := TOP(CS).DATA; TOP(CS) := TEMP [0: CS-l] || TEMP [CS-l].DATA [0:7] || EXB || TEMP [CS-l]. FLAG; END 7- PROBLEMS OF IMPLEMENTATION 7 .1 Software Applications To indicate how the proposed language may be used in programming (software) applications, we will compare the data declaration capabilities of PL/l [12], which also defines structures, to those of the proposed language. Because of this degree of similarity, many aspects of the implementation of the proposed language are the same as for the implementation of ALGOL or PL/ I. Since many of these problems are well known, the techniques of implementation will not be discussed here. Data structures are declared in PL/ I by a DECLARE statement. For example, the PL/ I statement DECLARE JOE FLOAT, JIM FIXED (5, 3), JACK BIT(lO); declares three structures: the structure JOE which is a floating point number, JIM which is a 5 by 3 array of fixed point numbers, and JACK is a 10 bit field. This same structure could be declared in the proposed language by the following statement. FIELD JOE (FLOAT), JIM (FIXED) *3*5, JACK [10] The format identifiers FLOAT and FIXED designate formats which are implicitly declared by the compiler and do not need to be declared in the program. Most of the data types specified by attributes in PL/ I can be specified by implicitly declared formats in the proposed language. Arbitrary structures in PL/ I are declared by prefixing the structure identifiers with an integer to designate the hierarchical level. For example, the statement ■56- ■57' DECLARE 1 A, 2 B BIT(l6), 2 C, 3 D (2) BIT(8), 3 E BIT(l6), 2 F BIT(lO); is equivalent to the following statement in the proposed language. FIELD A(B[l6], C (D[8]*2, E[l6]), F[10]); Disjunctions and specifications of alternate substructures are not provided for in the declarations of PL/l. The implementations of these features are related, however, to the implementation of dynamic storage allocation. The augmented variables in the proposed language, although more general, are related to the concepts of "cross-section" and "qualification" in PL/l. The store and access procedures are extensions of the procedure declarations in ALGOL or PL/l. 7« 2 Introduction of Stack Operations Although the information structure model provides for the definition of stacks, this concept was not implemented in the proposed language. The use of stacks is common in software applications although it is not provided for in ALGOL or PL/ I. Iteration can be introduced into the data declarations as another form of format secondary by the syntactic rule: : := **. The double asterisk is used to distinguish it from repetition of the primary. This form of format secondary declares a stack which is initially empty. The use of the identifier associated with the format primary as a variable will then always refer to the topmost cell of the stack (last cell inserted). Cells can be added or deleted from the stack by a variable in which the identifier of the format primary is followed by a slash (/). If the variable appears in the left part of an assignment statement a new cell is created, which becomes the topmost cell, before the assignment ■58- occurs. If the slashed variable occurs elsewhere, the topmost cell is deleted after referencing that cell. These operations correspond respectively to pushing and popping the stack. Let a stack A be declared by the statement FIELD A [16] **; The sequence of statements A := k; A/ := A; A/ : = 6; A := A/ + A; causes the number h to be pushed into the stack and then duplicated. After the number 6 is pushed into the stack, the top 2 cells of the stack are added, deleting the top cell, and the result 10 is placed back into the top cell. The stack at the end of the sequence consists of a cell containing h followed by a cell containing 10. The last statement in the sequence is equivalent to the statement A/ := A/ + A/; 7« 3 Computer Simulator Basically, an implementation of a computer simulator is identical to an implementation of a translator of the language for software applications. Since the computer is defined by an executable program in the proposed language, such a program may then be translated and executed in the same manner as any other computer program. In a practical implementation, some ; must be provided for loading initial instructions and data into declared tructures corresponding to the main store of the defined computer. This Dader would be produced by the translator as part of the simulator. Initial -59- instructions and data are then loaded for each simulation run. Additional software should also be furnished to provide for dumps and traces which will assist in locating flaws in the specification of the computer. An input compiler should also be furnished to simulate the inputs which occur at the interfaces between the computer and the external world in real time . This compiler would be a independent program which would compile, from some specification, the inputs which are to be used to test the defined computer. These inputs are then accepted by the simulator during the simulation run. If an assembly language for the defined computer has been specified, an alternate approach to simulation may be taken. The description of the computer may be used to generate a translator which translates a program written in the assembly language for the defined computer directly into a program to run on an existing computer -- without the intermediary of a simulator. This latter approach may prove difficult since the description of a new computer in the proposed language is not in the best form for this purpose. In addition, the syntax and semantics of the assembly language must also be provided. The description of the defined computer must be examined by the compiler of the translator to determine an equivalent sequence of instructions for each source instruction in the assembly language of the defined computer. Although sufficient information to perform the task is provided by the description in the proposed language, the translation time is likely to be too great unless considerable additional information is supplied to the compiler. 7-^ Hardware Compiler The ultimate realization of the proposed language is a hardware -60- compiler which converts the description of a new computer in the language into specifications of printed circuit cards (or micro circuit modules), physical locations of the cards, and wiring instructions. The implementation would most likely be broken into two phases. The first phase converts the specification of the computer in the proposed language into a functional description. This description functionally specifies all logic units, sub-units and their interconnections required to implement the computer. The functional description is independent, however, of any physical allocation. The second phase partitions the logic specified by the functional description into component groupings for each individual circuit card. The arrangement and wiring of the cards and the components on the cards are then determined in a manner which minimizes wire length and meets optimally other specific electrical and symmetry conditions. Implementations of second phase for related languages have been described in the literature [13, lh]> In phase one of the compilation, the specification of register and memory requirements can be derived from the field declarations in the description, while the gating and control for these registers are determined by the specific variables used to reference the storage. The requirements of functional units such as adders, multiply/divide units, boolean function units, and external device interfaces can be determined by examination of the operations used in the individual statements of the description. The sequencing of operations follows directly from the sequence of statements in the descriptions. It is understood that operations will be performed concurrently wherever the translator determines that parallel operation will lead to a more optimal design. It is unlikely that the techniques of switching theory can be used to produce a completely optimal computer design. The combinatorial -6l • aspects of these procedures are too great. A modular technique of construction which restricts use of the formal techniques of switching theory to local optimization appears to be feasible. A macro-module concept of computer design is being investigated at Washington University [15 ]• A minimal set of autonomous logic modules , capable of implementing an arbitrary digital computer, is sought. Each module contains its own internal control and sequencing logic A "start" level initiates the sub-operation of the module, and the module furnishes a "finish" level upon completion of the sub-operation. This technique may suggest a feasible method of realizing phase one. A library of modules, which includes the macro-modules but may also be more extensive, would be developed. These modules may range from NAM) and NOR elements to adders and multiply/divide units. The functional descrip- tion of the computer could then be broken into modules. Each module is drawn from the library or is in turn broken into sub-modules. Sub-modules are then taken from the library or again broken down until the functional description is complete. The decomposition of the computer into modules is aided by the procedure declarations and block structure of the language. Although the precise form of the decomposition process is not yet known, there is a definite relation between the modularity of the logic and the modularity specified by the procedures and block structure of the language. The block diagram of store or access procedures in Figure 12 might well represent the module which is the implementation of the procedure. An additional "start" line and "finish" line should be added to each block for this purpose. The "start" line is the physical representation of the procedure call while the finish line is the interpretation of the return to the calling program. Memory defined by field declarations within a -62- procedure body may not necessarily define new registers. The dynamic storage allocation of ALGOL is interpreted to mean that the memory specified in the procedure declaration is only defined while the procedure is being executed. Hence a pool of common registers may be shared by a number of procedures. It is also possible that the memory is not in fact required, but was declared only to make the description simpler. Although for the purpose of definition the description of a computer in the proposed language is complete, additional information will have to be supplied to the hardware compiler. Since no universal criterion for optimal design exists, design objectives in terms of speeds and costs must be supplied. The form and amount of additional information required can only be determined after some experience with the implementation of the hardware compiler is obtained. 8. CONCLUSION A model for information structures has been developed based on the regular set concept of automata theory. This model is capable of representing information structures ranging from registers and buses of a digital computer to complex list structures of programming theory. At the same time the model, using only three operators, requires a minimal amount of notation. In addition, a set of information structures may be defined. A specific instance or member of the set may be selected as required to meet varying conditions such as variable length data. Since the model draws from the well developed theories of regular sets and formal grammars, these areas may provide a basis for future investigation of a theory of information structures- On the basis of this model, the data declarations and the variables of the ALGOL 60 programming language were extended. Although these extensions have definite programming applications, they are introduced primarily to describe and define digital computers. That is, the extended declarations permit information formats and structures to be defined in a form which closely corresponds to the register, memory and data buses of a digital computer. Convenient and natural description of gating in a digital computer is made possible by the use of extended variables. With these extensions, arithmetic, boolean and data transfer operators existing in ALGOL 60 can be interpreted to describe either the software or the hard- ware operations which occur in a contemporary digital computer. The sequence of operations in the digital computer follows directly -63- -6k- from the sequence of statements in the description. Concurrent execution of operations in a digital computer is considered to be an aspect of the optimization rather than basic to the definition of the computer. In Chapter 6 a simple, but nontrivial, computer has been completely- defined in the proposed language. Translators for the language remain to be developed. A translator which will produce a simulator of a computer defined in the language can be constructed in the same manner as translators for ALGOL 60 and PL/l and hence should present little additional difficulty. On the other hand, a compiler which will produce a hardware implementation of a computer described in the proposed language will be a more difficult task. It is unlikely that the exhaustive procedures of switching theory can efficiently be used in the implement of the compiler because these techniques are marred by unwieldly combinatorial aspects. A more likely approach utilizes a hierarchy of modules. Each module used in the implementation is either drawn from a library of modules or specified in terms of component modules. The modules in the library may range from individual NAND elements to multiply units which are complete with sequencing and control. If a module is specified in terms of component modules, some or all of these modules may be taken from the library or again broken down until the computer is completely specified. The division of the computer into modules is determined by the procedures, block structure and and statement construction of the description in the language. A primary problem in the implementation of the hardware compiler will be the specification of the library and methods of breaking up modules. The experience gained in the development of the library and compiler may eventually bring about a fundamental reorganization in the concepts and teaching of arputer design -- as switching theory is integrated with system programming. REFERENCES [I] H. P. Schlaeppi, "A Formal Language for Describing Machine Logic, Timing, and Sequencing (Lotis)," IEEE Transactions on Electronic Computers , Vol . EC-13, PP- i +39- I + J +8 ; October, 1964. [2] Ho Schorr, "Computer -Aided Digital System Design and Analysis Using A Register Transfer Language," IEEE Transactions on Electronic Computers , Vol. EC-13, PP- 730-737; December, 1964. [3] Y. Chu, "An ALGOL-Like Computer Design Language," Communications of the ACM , Vol. 8, pp. 607-615; October, 1965. [4] G. Metze and S. Sheshu, Computer Compiler Part I - Preliminary Report, Coordinated Science Laboratory, University of Illinois, Urbana, Illinois, Rept. R-264; August, 1965° [5] M. W. Allen et__al. , "CIRRUS, An Economical Multiprogram Computer with Microprogram Control," IEEE Transactions on Electronic Computers , Vole, 12, pp. 663-67I; December, 1963- [6] G. B. Gerace, "Microprogrammed Control for Computing Systems," IEEE Transaction s on Elec tronic Computers , Vol. EC-12, pp. 733-747; December, 1963° [7] D. Ross, "SPL Preliminary Report," Carnegie Institute of Technology, Pittsburgh, Pennsylvania, April, 1965° [8] P. Naur (Edo), "Revised Report on the Algorithmic Language ALGOL 60, " Communications of the ACM, Vol. 6, pp. 1-17 J January, 1963- [9] S. C. Kleene, "Representation of Events in Nerve Nets and Finite Automata," in Automata Studies , C E. Shannon and J. McCarthy, Eds., Princeton University Press, Princeton, New Jersey, pp. 3-4l; 1956. [10] N. Chomsky and G. A. Miller, "Introduction to Formal Analysis of Natural Languages," in Handbook of Mathematical Psychology , Vol. II, R. D. Luce, R. R. Bush, and E. Galanter, Eds., John Wiley and Sons, New York, pp. 283-306; 1963° [II] B. H. McCormick (Ed.), "Preliminary Programming Manual for the ILLIAC III Computer," Department of Computer Science, University of Illinois, Urbana, Illinois, Rept. 185; July, 1965* [12] "IBM Operating System/ 36O PL/ I: Language Specifications," International Business Machines, New York, File S360-29; 1965. [13] J. H. Hazelhurst and B. H. McCormick, "WEB: A Language to Describe the Interconnection and Packaging of the Logical Units in a Digital Processor," Department of Computer Science, University of Illinois, Urbana, Illinois, File No. 625; August, 1964. -65- -66- [ik] J. S. Hughes and K. W. Lallier, "Automated Component Placement and Pin Assignment," Space Guidance Center, IBM Federal Systems Division, Owego, New York, IBM No. 65-825-1U22; February, 1965. [15] W. H. Clark, Bio-Medical Computer Laboratory, Washington University, St. Louis, Missouri, personal communication to B. H. McCormick; November 3, 1965- W$mfy IlillililTIHlBMMnflnnHII] ■KHHBtfHlUiiltnaHmHnHaBfl^aiBMBHHMMMiaHrani^AlUWfeM&nraiMaBBan&AMKBBHEBIHSri^^ra^ ^B i 'If . K ■ lit ^,'!!. E n SrTrOMLUNO,S| J»8ANA 30H2103707086 ■ i ■ I I