CENTRAL CIRCULATION BOOKSTACKS 
 
 The person charging this material is re- 
 sponsible for its renewal or its return to 
 the library from which it was borrowed 
 on or before the Lotest Date stamped 
 
 Li 3 «?< ««? be Char 9 ed a minimum 
 fee of $75.00 for each lost book. 
 
 !? "*. - * "■ "■ "« ""*rtW«0 o, book. a~ rw , Mns 
 
 z sz:^ °" and moy -* ,n *— *- 
 
 TO RENEW CALL TELEPHONE CENTER, 933-8400 
 
 JjNimsiT^Q^ IUINOIS LIBHAHV AT U8BANA-CHAMPA.GM 
 
 IAPR051! 
 
 When renewing by phone, write new due date below 
 previous due date. L162 
 

 UIUCDCS-R-79-960 
 
 /'(CJUk. 
 
 UILU-ENC 79 1705 
 
 PATH PASCAL USER MANUAL 
 
 by 
 
 Roy Harold Campbell 
 
 Ira Ben Greenberg 
 
 Thomas John Miller 
 
 THE UBRARX OB IHE 
 
 APR 1 7 1979 
 
 March 1979 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/pathpascaluserma960camp 
 
UIUCDCS-R-79-960 
 
 PATH PASCAL USER MANUAL 
 
 by 
 
 Roy Harold Campbell 
 
 Ira Ben Greenberg 
 
 Thomas John Miller 
 
 March 1979 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 
 UNIVERSITY OF ILLINOIS AT URB ANA- CHAMPAIGN 
 
 URBANA, ILLINOIS 61801 
 
 Supported in part by NASA Grant NSG1471 and NSF Grant MCS 77-09128. 
 
TABLE OF CONTENTS 
 
 1 INTRODUCTION 1 
 
 2 DATA ENCAPSULATION 3 
 
 2.1 Scope. 5 
 
 2.2 Declaration of Objects. 5 
 
 2.3 Structured Types Containing Objects. 6 
 
 2.4 Pointers to Objects. 7 
 
 2.5 Path Declaration Part. 7 
 
 2.6 Type Definition Part. 8 
 
 2.7 Variable Declaration Part. 8 
 
 2.8 Operation Declaration Part. 9 
 
 2.9 Initialization Part. 10 
 
 2.10 Operation Invocation. 11 
 
 2.11 Restrictions. 12 
 
 3 OPEN PATH EXPRESSIONS 13 
 
 3.1 Syntax of Open Paths. 13 
 
 3.2 Semantics of Open Paths. 14 
 
 3.2.1 Grouping Precedence 14 
 
 3.2.2 Simplified Discussion of Features 14 
 3-2.3 Full Discussion of Features 16 
 
 3.3 Examples of Open Paths. 20 
 
 4 PROCESSES 23 
 
 4. 1 Process Syntax. 23 
 
 4.2 Creating a Process. 24 
 
 4.3 Process Storage Considerations. 25 
 
 4.4 Process Lifetimes. 25 
 
 4.5 Parameter Restriction. 26 
 
 4.6 Priorities. 27 
 
 4.7 Delaying Processes. 28 
 
 4.8 Interrupt Processes. 28 
 
 5 SUMMARY 31 
 
 6 REFERENCES 32 
 
 APPENDICES 
 
 A PATH PASCAL SYNTAX 
 
 B MESSAGES 
 
 C OPEN PATH ALGORITHMS 
 
 D PROGRAMMING EXAMPLES 
 
 E EXTENDED P-CODE 
 
 F A SUMMARY OF PASCAL P4 
 
Page 1 
 1 INTRODUCTION. 
 
 Experimental Path Pascal is designed to investigate the benefits and 
 problems that arise when path expressions are combined with a language to pro- 
 vide a system programming tool. Instead of altering the Pascal language exten- 
 sively, a minimal number of features was added such that Pascal programs still 
 compile and execute. The language can be used as an instructional tool or for 
 the construction of example system programs. This manual describes the Path 
 Pascal features and the implementation on the Cyber and PDP11. 
 
 Path expressions were introduced as a technique for specifying process 
 synchronization by [Campbell and Habermann, 74] , and further discussed by 
 [Habermann, 75], [Lauer and Campbell, 75], [Flon and Habermann, 76], [Andler, 
 79] and [Campbell, 77]. Variations of the path expression idea have been pro- 
 posed by [ONERA CERT, 77] and notations that are similar to paths that model 
 system behavior have been developed independently by [Shaw, 77] and [Riddle, 
 76]. A specification language has also been designed [Lauer and Shields, 78] 
 based upon the use of a path expression notation. 
 
 Path Pascal is based on the P4 subset of Pascal [Ammann, et al, 76] 
 (see Appendix F for a summary of the P4 subset). The Path Pascal compiler is 
 written in Pascal P4 and will accept any Pascal P4 program that does not use 
 Path Pascal reserved words as identifiers. The modifications to Pascal 
 involved the addition of an encapsulation mechanism (see chapter 3), Open Path 
 expressions [Campbell, 77] (see chapter 4), and processes (see chapter 5). 
 Open Paths are integrated with the encapsulation mechanism to enforce a 
 strict discipline upon the programmer describing shared data objects. All 
 access to encapsulated data is performed by operations synchronized by Open 
 
Page 2 
 Paths. A process invoking such an operation may only execute the operation if 
 permitted to by the Open Path expression associated with the shared data 
 object. 
 
 The following sections describe Path Pascal in more detail. Motiva- 
 tions for the design of Path Pascal are discussed further in [Miller, 78]. A 
 description of Pascal can be found in the Pascal Report [Jensen and Wirth, 
 75]. The additional Path Pascal syntax is listed in Appendix A. Appendix B 
 contains the Path Pascal compiler error messages, and the Path Pascal P code 
 interpreter control options, constants, and error messages. Appendix C 
 describes the semantics of Open Path expressions in terms of P and V opera- 
 tions. Appendix D contains several sample programs. Appendix E describes the 
 changes that have been made to the intermediate code (P-Code) for the addi- 
 tional Path Pascal constructs. 
 
 
Page 3 
 2 DATA ENCAPSULATION . 
 
 Path Pascal Includes an encapsulation mechanism called an object. 
 Objects allow useful user-defined data structues to be programmed but are not 
 intended as a general solution to abstract data types. They permit synchroni- 
 zation to be associated with shared data and are implemented as an extension 
 of the Pascal structured type facility. 
 
 An object provides controlled access to a data structure and consists 
 of a declaration of the data structure together with a set of operations which 
 access the values of that structure. Path Pascal allows algorithms to be 
 expressed in the form of routines (procedures, functions, and processes). 
 Operations are constructed from routines (Thus, operations may be defined in 
 terms of calls upon additional routines). Objects and their operations iso- 
 late the internal data representation of values of the object from the rest of 
 a program. This isolation is enforced by restricting manipulations of the 
 data structure of an object to the textual unit comprising the object. Opera- 
 tions are specified by prefixing the declaration of a routine with the 
 reserved word 'ENTRY'. Since Path Pascal permits concurrent asynchronous 
 processes, several processes can try to access an object at the same time. It 
 is necessary therefore to synchronize and coordinate the execution of these 
 operations. This synchronization is specified for each object by an Open Path 
 Expression. 
 
 BNF for an object is shown below: 
 <object type> ::= OBJECT <object block> END; 
 
Page 4 
 
 <object block> :: = 
 
 <path declaration part> 
 
 <constant definition part> 
 
 <type definition part> 
 
 <object variable declaration part> 
 
 <operation declaration part> 
 
 <initialization part> 
 
 An example of an object is: 
 
 CONST 
 
 nbuf ■ 5; 
 OBJECT 
 
 PATH nbuf: (1: (fill); 1: (empty) ) END; 
 TYPE 
 
 buffsize ■ L.nbuf; 
 
 inbuff » ARRAY [buffsize] OF CHAR; 
 VAR 
 
 buf: inbuff; 
 
 nextspot: ring; 
 ENTRY PROCEDURE fill(inchar: CHAR); 
 
 BEGIN inbuff [nextspot. inpointer] := inchar END; 
 ENTRY FUNCTION empty: CHAR; 
 
 BEGIN empty := inbuff [nextspot. outpointer] END; 
 END; 
 
 The example object implements a five character ring-buffer using an 
 array of characters 'inbuf and a pointer scheme whose algorithm and values 
 are determined by the operations 'inpointer' and 'outpointer' on the variable 
 'nextspot' of type 'ring' (an object declared in an enclosing scope). The 
 example object has an internal data representation constructed from 'inbuf 
 and 'nextspot' and the values of the object are changed by executions of the 
 operations 'fill' and 'empty'. A path expression synchronizes executions of 
 the operations so that the object may be shared between two communicating 
 processes. 
 
Page 5 
 2. 1 Scope . 
 
 An object defines a block, possibly containing local constants, types, 
 variables, routines, and the object's operations. The scope of all the local 
 identifiers except the names of the operations obeys the standard rules of 
 Pascal. The operation's identifiers are exported to the scope of the block, in 
 which the object is declared and may be invoked within that scope. Thus, the 
 data structures within the object may only be manipulated externally by the 
 execution of an operation. In the buffer example above, neither 'nextspot' 
 nor 'inbuff are defined external to the block of the object. 
 
 2.2 Declaration of Objects . 
 
 Like other Pascal structured types, objects can be defined and named 
 in a type declaration, or can appear directly in a variable declaration. An 
 examples of a type declaration is 
 
 TYPE ring = OBJECT 
 
 PATh inpointer , outpointer END; 
 VAR inp, outp: buff size; 
 ENTRY FUNCTION inpointer: buff size; 
 BEGIN inp := inp MOD nbuf + 1; 
 
 inpointer := inp 
 END; 
 ENTRY FUNCTION outpointer: buffsize; 
 BEGIN outp := outp MOD nbuf + 1; 
 
 outpointer := outp 
 END; 
 INIT; 
 
 BEGIN inp := 0; outp := END; 
 END; 
 
 and an example of a variable declaration is 
 
Page 6 
 
 VAR id: OBJECT 
 
 PATH 1: (get) END; 
 
 VAR count: integer; 
 
 ENTRY FUNCTION get: integer; 
 
 BEGIN count :- count + 1; get :■ count END; 
 INIT; 
 
 BEGIN count :- END; 
 END; 
 
 Declaring an object in a type declaration allows its associated name to be 
 used to declare variables of that type. An example of this is 
 
 VAR pointers: ring; 
 Each variable that is declared as an object creates an instance of that object 
 which possesses its own independent 1) block of storage, 2) copy of the 
 object's operations, and 3) synchronization information to control the order 
 in which its copy of the operations are executed. These three items are 
 described, respectively, in an object's 1) object variable declaration part, 
 2) operation part, and 3) path declaration part. Thus, successive executions 
 of the operation 'get' on the variable 'id' above will return the integer 
 values 1, 2, 3, and so on. 
 
 2 . 3 Structured T ypes Containing Objects . 
 
 Structured types containing objects may be declared and objects may be 
 nested within each other. Recursive object definitions cause a compile time 
 error. Two examples of structured types containing objects are 
 
 TYPE rec: RECORD 
 
 fl: ring; 
 
 f2: OBJECT ... END; 
 f3: integer 
 END; 
 
 and 
 
Page 7 
 
 VAR a: array [1 .. 20] of ring; 
 r: rec; 
 
 2.4 Pointers to Objects . 
 
 Pointers to objects or records containing objects may be declared. 
 Examples of such pointer declarations are 
 
 VAR ptrring: ** ring; 
 ptrrec: " rec; 
 
 Dynamic variables may be created from type declarations of objects or records 
 containing objects by executing the standard procedure NEW with the appropri- 
 ate pointer argument. Examples of the creation of dynamic variables are 
 
 NEW (ptrring); 
 NEW (ptrrec); 
 
 2.5 Path Declaration Part . 
 
 The path declaration part consists of a single Open Path expression 
 which serves two purposes. It specifies the synchronization constraints on the 
 object's operations. These constraints must be met before access to the 
 object's data structure is allowed. The path also declares the operation iden- 
 tifiers which are known outside the scope of the object. The compiler checks 
 each path to ensure that each operation id appears exactly once. 
 
 A path declaration part (shown below in BNF) can be either empty or 
 may contain an open path: 
 
 <path declaration part> ::= 
 <empty> | 
 <open path> 
 
Page 8 
 
 Examples of paths are: 
 
 PATH nbuf: ( l:(£ill); 1: (empty) ) END; 
 PATH inpointer, outpointer END; 
 
 Open Path expressions are detailed in chapter 4. 
 
 2.6 Type Definition Part . 
 
 Any type definitions may be declared in the type definition part 
 including new object type definitions. It is therefore possible to nest 
 objects in Path Pascal. Type definitions may use simpler type definitions 
 declared global to the object. 
 
 2 . 7 Variable Declaration Part . 
 
 The object variable declaration part declares the local data structure 
 of the object. This local data structure can contain objects and may use type 
 definitions declared global to the object. 
 
 <object variable declaration part> ::= 
 VAR <variable declaration> 
 
 {; <variable declaration>} ; 
 
 An example of an object variable declaration part is; 
 
 VAR 
 
 buf: inbuff; 
 nextspot: ring; 
 
 This example is taken from an earlier example. 
 
Page 9 
 2.8 Operation Declaration Part . 
 
 The operation declaration part specifies the routines and operations 
 that can be performed on the local data structure of the object. Operations 
 may be invoked outside of the object but other routines are strictly local and 
 can only be invoked by operations or the initialization part. Operations are 
 distinguished from routines by prefixing them with the reserved word 'ENTRY'. 
 Each operation identifier must appear in the object's path expression in order 
 to be synchronized and exported. 
 
 <operation declaration part > ::= { <operation part>) 
 
 <operation part> ::= 
 <operation> | 
 <routine> 
 
 <routine> ::= 
 
 <procedure declaration> | 
 <function declaration> | 
 <process declaration> 
 
 <operation> : : = 
 
 ENTRY <routine> 
 
 An example of operation is: 
 
 ENTRY FUNCTION outpointer: buffsize; 
 BEGIN 
 
 outp := outp MOD nbuf + 1; 
 outpointer := outp 
 END; (*outpointer*) 
 
 Operations and routines within an object can invoke other operations 
 and routines declared within the object as long as these invoked operations 
 and routines are declared first or declared to be forward. Synchronization is 
 applied as usual for an invoked operation. 
 
 An operation can be invoked from within its object as if it were a 
 
Page 10 
 routine. This differs from the notation used when it is invoked from outside 
 its object, as is illustrated in the following example: 
 
 1 PROGRAM test ( ... ); 
 
 2 VAR ob: OBJECT 
 
 3 PATH a, b END; 
 
 4 VAR . . . 
 
 5 ENTRY PROCEDURE a; 
 
 6 BEGIN ... END; 
 
 7 ENTRY PROCEDURE b; 
 
 8 BEGIN ... a; ... END; 
 
 9 PROCEDURE c; 
 
 10 BEGIN ... b; ... END; 
 
 11 END (* ob *); 
 
 12 BEGIN ... ob.a; ... END. 
 
 The references in lines 8 and 10 only specify the entry operation name, while 
 the reference in line 12 must use the dot notation. 
 
 Procedures and functions defined within an object may be recursive. 
 However, recursive entry procedures or entry functions may result in deadlock. 
 Processes are described in detail in chapter 5. 
 
 2.9 Initialization Part . 
 
 The Initialization part is an optional block that is used to initial- 
 ize an object's local data structure and create any local processes. The 
 block is Invoked whenever a new instance of that object is declared or dynami- 
 cally created. Labels, constants, types, variables, and routines can be 
 declared within the initialization block. Any identifiers available inside 
 the object are automatically inherited and can be freely accessed or invoked. 
 Operations of the object may be invoked as routines. 
 
Page 11 
 
 <initialization part> 
 <emp ty> 
 INIT; <block> 
 
 Examples of initializations are: 
 
 INIT; 
 BEGIN 
 
 inp := 0; outp := 
 
 END; 
 
 INIT; 
 
 VAR i: INTEGER; 
 
 PROCEDURE q ( j: INTEGER ); BEGIN ... END; 
 
 BEGIN 
 
 FOR i := 1 TO 10 DO q; 
 END; 
 
 For object variables that contain further objects in their local data struc- 
 ture, the init blocks of the objects in the data structure are executed first. 
 The use within an init block of variables and routines global to the object 
 is discouraged. Hence, the order in which the local objects' init blocks are 
 executed is left undefined. 
 
 2.10 Operation Invocation . 
 
 Operations may be performed on variables declared as objects. An 
 
 operation is executed by specifying the variable, a dot, the entry operation 
 
 and any parameters. This notation is inspired by the Simula 67 dot notation 
 
 [Dahl et al, 68]. For example, operations can be invoked on variables declared 
 
 in examples above by 
 
 nextspot. inpointer 
 a [5] .inpointer 
 r.f 1. inpointer 
 
 Operations on dynamic variables are invoked by dereferencing the pointer as in 
 
 the examples 
 
Page 12 
 
 ptrring~.inpointer 
 ptrrec~.f l.inpointer 
 
 2.11 Restrictions . 
 
 Assignments between variables with the same object type or variables 
 with the same structured type where that structured type contains objects are 
 not permitted because of side-effects caused by the object variables' syn- 
 chronization states. Object variables or structured variables that contain 
 objects are passed as reference parameters to operations. 
 
Page 13 
 3 OPEN PATH EXPRESSIONS . 
 
 Using processes, it is possible to write programs in Path Pascal which 
 have several independent execution paths. It is generally impossible to know 
 the order in which processes will execute, or the speed with which they will 
 execute. In fact, in systems with multiple processors, it is possible for two 
 processes to physically execute in parallel. Because of this uncertainty, it 
 is important to have a synchronization mechanism which can be used to ensure 
 the integrity of shared data. 
 
 The Open Path expressions notation for writing synchronization specif- 
 ications is used in conjunction with objects to synchronize process execu- 
 tions. Shared data is represented by an instance of an object. Each object 
 contains exactly one path expression which specifies the legal orders in which 
 the object's operations can be executed, and the ways in which these opera- 
 tions can execute in parallel. Since only these operations are used to access 
 the data, processes trying to manipulate the data are forced to do so in safe 
 sequences. 
 
 3. 1 Syntax of Open Paths . 
 
 <open path> ::= PATH <list> END; 
 <list> ::= <sequence> <sequence> , <list> 
 <sequence> ::= <item> <item> ; <sequence> 
 <item> ::= <integer bound> : (<list>) 
 
 | [<list>] 
 
 | (<list>) 
 
 | <operation id> 
 <integer bound> ::= <unsigned integer> 
 positive constant> 
 
 An Open Path expression is a list of sequences separated by commas, 
 
Page 14 
 enclosed by the reserved words 'PATH' and 'END'. A sequence is a list of items 
 separated by semi-colons. An item can be an operation name, or a comma 
 separated list of sequences enclosed by parentheses, parentheses with an asso- 
 ciated integer bound, or brackets. 
 
 Each operation name must appear exactly once in an Open Path. 
 
 3.2 Semantics of Open Paths . 
 
 Intuitively, an Open Path works in the following manner. A process 
 tries to execute an operation. The path's specification dictates whether or 
 not that operation can proceed. If it can, then it does so and the path is 
 advanced to its next state. Otherwise, the process must wait until the path 
 enters a state where the operation that was requested can be executed. Waiting 
 processes are later selected for execution in first-in first-out order. 
 
 3.2.1 Grouping Precedence . 
 
 Semi-colons have a higher precedence than commas. This precedence can 
 be over-ridden by the three grouping notations: parentheses, parentheses with 
 an integer bound, and brackets. 
 
 3.2.2 Simplified Discussion of Features . 
 
 This section introduces the components of an Open Path. The discus- 
 sion is simplified by restricting operands and lists to single operation 
 names. The next subsection generalizes these features and introduces some 
 additional details. 
 
 
Page 15 
 
 3.2.2.1 Semi - colon . 
 
 A semi-colon is used to specify sequentially . The notation X;Y 
 requires an execution of operation X to precede an execution of operation Y, 
 and an execution of Y may only follow an execution of X. 
 
 3.2.2.2 Comma . 
 
 Commas specify a set of alternatives, any one of which can execute 
 next. The path X,Y,Z allows either operation X or operation Y or operation Z 
 to execute next. 
 
 3.2.2.3 Parentheses with Bound . 
 
 This construct is used to limit concurrent execution. The integer 
 bound specifies the maximum number of processes that can be concurrently exe- 
 cuting the operation inside the parentheses. A process may immediately start 
 executing the enclosed operation if fewer processes than the specified integer 
 are concurrently executing the operation. Specifying 1: (X) allows only one 
 process at a time to execute X, i. e. executions of X must be mutually 
 exclusive. The path 3: (X) means that at most three processes can be executing 
 X concurrently. The bound may be used to share a limited number of resources 
 between several processes. 
 
 3.2.2.4 Parentheses . 
 
 Parentheses without an associated integer are equivalent to 
 parentheses with an associated integer of infinity. They are only used for 
 grouping and do not limit concurrent execution. The expression (X) is 
 
Page 16 
 equivalent to 'infinity: (X)' and allows up to an unlimited number of con- 
 current executions of X. 
 
 3.2.2.5 PATH and END. 
 
 The keywords 'PATH' and 'END' delimit the entire path expression and 
 are equivalent to a pair of parentheses. The path PATH X END would allow an 
 unlimited number of concurrent executions of X. 
 
 3.2.2.6 Brackets . 
 
 Brackets permit a burst of execution. The burst begins when some pro- 
 cess starts to execute the operation enclosed by the bracket. The burst is 
 continued as long as some process is still executing the operation. While the 
 burst is active, an unlimited number of processes can immediately begin the 
 operation. The burst ends when the last process which is executing the opera- 
 tion completes. In the path [X] a process can immediately start executing X 
 if 1) at least one process is currently executing X, or 2) the path is in a 
 state where [X] can start executing. Otherwise, that process must wait until 
 the path enters a state where [X] can be started again. 
 
 3.2.3 Full Discussion of Features . 
 
 3.2.3.1 Definitions . 
 
 A list of comma separated sequences is referred to as an Open Path 
 
 list. Thus an Open Path expression is an Open Path list enclosed by 'PATH' and 
 
 'END'. Examples of Open Path lists are X,Y,Z and V, (W;X;Y) ,2: (Z) and the sim- 
 ple list X- 
 
Page 17 
 Operation names in an Open Path list are called initial, intermediate, 
 or final operations. Initial operations are those operations in an Open Path 
 list which can be executed when the path is in a state where the Open Path 
 list can be started. Final operations are those operations in an Open Path 
 list whose execution puts the path in a state where the parts of the Open Path 
 expression that follow the Open Path list can start to execute. Intermediate 
 operations are those operations in an Open Path list which can be executed 
 between the Open Path list's initial and final operations. In 'X,Y,Z', X, Y, 
 and Z are both initial and final operations, and there are no intermediate 
 operations. In 'V, (W;X;Y) , 2: (Z ) ' , V, W, and Z are initial operations, X is an 
 intermediate operation, and V, Y, and Z are final operations. 
 
 A sequence of operation executions that starts with one of an Open 
 Path list's initial operations and ends with one of its final operations is 
 called an execution sequence. In 'V, (W;X;Y)' , V is an execution sequence and 
 so is W, X, and Y. A sequence of operation names can be used in more than one 
 execution sequence. For example, two processes can be concurrently executing V 
 according to the above Open Path list yielding two similar execution 
 sequences, V and V. 
 
 The grouping notations inherit the characteristics of the Open Path 
 list which they enclose. Thus brackets in [V,(W;X;Y)] have initial operations 
 of V and W, and an execution sequence of W, X, and Y. 
 
 3.2.3.2 Brackets . 
 
 Brackets are used for grouping and to provide a special burst mode of 
 execution. A burst of execution is started when one of the bracket's initial 
 operations is executed and continues as long as any of the bracket's execution 
 
Page 18 
 sequences is unfinished. One of the bracket's initial operations can be exe- 
 cuted immediately if one of the bracket's execution sequences is unfinished. 
 
 There are two special rules for brackets. First, while a bracket's 
 operations must wait to start until some execution sequence progresses to the 
 point where the bracket is reached, once the bracket has been started (entered 
 burst mode) an unlimited number of the bracket's operations can start immedi- 
 ately as long as one of the bracket's execution sequences is still unfinished. 
 Second, only one execution sequence can contain the bracket in burst mode; i. 
 e. a bracket must be executed in mutual exclusion. This rule is a result of 
 the decision to continue an old burst instead of start a new one when the 
 bracket is in burst mode. 
 
 3.2.3.3 Parentheses with Bound . 
 
 This construct is used for grouping and to limit concurrent execution. 
 It states that at most n execution sequences can proceed concurrently (n is 
 the associated integer). If there are fewer than n concurrent execution 
 sequences, one of the parentheses' initial operations can be executed immedi- 
 ately. 
 
 There is a special rule when this construct is nested. If an attempt 
 is made to execute an operation which is nested within several pairs of 
 parentheses and which could execute if not limited by one of these constructs, 
 the execution restrictions associated with the parentheses are examined from 
 the innermost level. If execution is restricted then the process that was try- 
 ing to execute the operation waits at the level where it was stopped. When the 
 restriction is removed, checking continues from that point. In the path 
 i: (Y,2: (Z)), assuming that the execution sequences Z and Z are unfinished (i. 
 
Page 19 
 e. two processes are executing Z), a process now attempting to execute Z will 
 be stopped by 2:(Z). If another process then attempts to execute Y it wili be 
 permitted to continue. The third attempt to execute Z would not have 'used up' 
 one of the outer parentheses' execution sequences. This rule helps prevent 
 poor system performance. 
 
 3.2.3.4 Parentheses . 
 
 Parentheses are used for grouping and are equivalent to parentheses 
 with an associated integer of infinity. 
 
 3.2.3.5 PATH and END . 
 
 'PATH' and 'END' are equivalent to a pair of parentheses end enclose 
 the Open Path expression. 
 
 3.2.3.6 Semi-colon . 
 
 The path LI; L2 (where LI and L2 are open path lists) allows L2 to 
 being only after some LI is completed. 
 
 3.2.3.7 Comma - 
 
 Any of the operands in a comma separated list can be group enclosed 
 Open Path lists. The path LI, L2, ..., Ln, allows any one initial operation of 
 any of the operands to be executed. Thus any one execution sequence from the 
 operands can be executed. 
 
Page 20 
 3.3 Examples of Open Paths . 
 
 1. PATH A END; 
 
 A can execute at any time, and any number of A's can execute concurrently. 
 The synchronization that is specified is trivial. 
 
 2. PATH A,B,C END; 
 
 A or B or C can execute at any time. Any number of A's, B's, and C's can 
 execute concurrently. The synchronization that is specified is trivial. 
 
 3. PATH A;B END; 
 
 A's can be executed at any time. A B can only be executed if the number of 
 B's that completed or are currently executing is less than the number of 
 A's that are completed. Any process that is given permission to execute 
 can execute concurrently with any other process. 
 
 4. PATH 1: (A) END; 
 
 A's must be executed sequentially. 
 
 5. PATH 2: (A) END; 
 
 At most two A's can execute concurrently. 
 
 6. PATH 1: (A),B END; 
 
 A's must execute sequentially. B's can execute at any time. Any processes 
 that are given permission to execute can execute concurrently. 
 
 7. PATH 1: (A),l: (B) END; 
 
 A's must execute sequentially, and B's must execute sequentially. One A 
 and one B can execute concurrently, however. 
 
 8. PATH 1: (1: (A),l: (B)) END; 
 
 Processes A and B execute in mutual exclusion. The expression PATH 1: (A, 
 B) END would be better. 
 
Page 21 
 
 9. PATH 5: (A;B) END; 
 
 At most five execution sequences can be executing concurrently. Thus at 
 most 5 A's and B's can be executing concurrently, or 4 A's and 1 B, etc. 
 In addition, the number of B's tht are executing or completed must be less 
 than the number of A's that are completed. 
 
 10. PATH 1: (1: (A),B) END; 
 
 The outer parentheses specifies that only one A or one B can execute at a 
 time, and that they cannot execute concurrently. The inner parentheses 
 allow B's to be given priority over A's. This occurs because processes 
 trying to execute A's must first get past the restriction of the inner 
 parentheses, while processes trying to execute B's can go directly to the 
 outer parentheses. 
 
 11. PATH 1: ( [A] ,B) END; 
 
 Either a burst of A's or a B can execute, but not concurrently. The A's in 
 the burst of A's must execute concurrently. When the burst ends, a B will 
 start if a process is waiting to execute a B. Otherwise, either a burst of 
 A's or a B will be executed depending upon whether an A or a B is 
 requested first. 
 
 12. PATH 3: ([A]) END; 
 
 This path is equivalent to PATH 1:([A]) END;, PATH [A] END;, and PATH A 
 END; because bursts must execute sequentially and there is no difference 
 between sequential bursts of A's and the unrestricted execution of A's. 
 
 13. PATH 5: (3: (A), 4: (B)) END; 
 
 At most 3 A's can execute sequentially, and at most 4 B's can execute 
 sequentially. The outer parentheses allow at most 5 concurrent execution 
 sequences, so at most 3 A's and 2 B's, or 2 A's and 3 B's, etc. can exe- 
 cute concurrently. The bounded parentheses can be used to allocate 
 resources. The above expression could be used to allocate five resources 
 to two sets of processes invoking A and B so that there is always one 
 resource available for the set requesting A and two resources available 
 for the set requesting B. 
 
 14. PATH 8: (3: (A), 3: (B)) END; 
 
 This path is equivalent to PATH 6: (3: (A) , 3: (B ) ) END. Setting the outer 
 integer to 8 is superfluous. At most 3 A's can execute concurrently, and 
 at most 3 B's can execute concurrently. Also, all 3 A's and all 3 B's can 
 execute concurrently. 
 
Page 22 
 
 15. PATH TOTAL:(AMAX:(A),BMAX:(B)) END; 
 
 If TOTAL, AMAX, BMAX, are integer constants 5, 3, and 4, then this path is 
 identical to the path in 13. 
 
Page 23 
 A PROCESSES . 
 
 A process is a program structuring unit which has an independent 
 execution path associated with it. Processes can interact and are co- 
 ordinated by performing operations on shared variables. The declaration of a 
 process is, in Path Pascal, distinguished from the activation of a process. A 
 process may be declared in any block and activations of the process may be 
 created in any body of code with scope that includes the declaration. 
 
 4.1 Process Syntax . 
 
 <process declaration> ::= 
 
 <process heading> <block> 
 
 <process heading> :: = 
 
 PROCESS <identifier> <size part>; | 
 PROCESS <identifier> <size part> 
 (<formal parameter section> 
 
 {;<formal parameter section>}); 
 
 <size part> : : = 
 
 [<unsigned integer>] 
 
 Processes are declared like standard Pascal procedures. They may 
 possess parameters, but may also have a size attribute. The parameters can be 
 passed by value or by reference. The size attribute is used to estimate the 
 process's storage requirements. If it is omitted a default value is used. 
 
 An example of a process declaration is: 
 
Page 24 
 
 1 PROCESS printer [200] ( VAR inbuff : buffer); 
 
 2 VAR outbuff : buffer; ch : CHAR; 
 3 
 
 4 PROCEDURE asciitoebcdic ( ch : CHAR); 
 
 5 BEGIN 
 
 6 outbuff. fill(ch) 
 
 7 END; 
 8 
 
 9 PROCESS reader; 
 
 10 VAR ch : CHAR; 
 
 11 BEGIN 
 
 12 REPEAT 
 
 13 ch := inbuff .empty; 
 
 14 asciitoebcdic(ch) 
 
 15 UNTIL false 
 
 16 END; 
 17 
 
 18 BEGIN 
 
 19 reader; (* instantiate a reader process *) 
 
 20 REPEAT (* simulate a writer *) 
 
 21 ch := outbuff .empty; 
 
 22 write(ch) 
 
 23 UNTIL false 
 
 24 END; (* printer *) 
 
 This example contains a printer which manipulates and then prints sequences of 
 characters. The printer has one parameter, 'inbuff a variable of type 
 'buffer' , and a size attribute of 200. The size attribute indicates that 200 
 words will be required at run-time to contain the stack and heap for the pro- 
 cess printer. The 200 words are required for the local variables and for 
 invocations of routines. 'Reader' transforms ascii characters in 'inbuff to 
 ebcdic characters using 'asciitoebcdic'. The ebcdic characters are placed in 
 'outbuff and then printed using the write loop. 
 
 4 . 2 Creating a_ Process . 
 
 An instance of a process is dynamically created by invoking the pro- 
 cess name , Just as in a procedure invocation. This can be seen in line 19 in 
 the above example where the reader process is created. The creating process 
 
Page 25 
 does not have to wait for the created process to terminate before continuing 
 its own execution. Each process created is allocated a run-time heap and 
 stack from the heap of the process which is performing the creation. The 
 number of words allocated is specified by the size attribute, but if this 
 attribute is omitted a system default of 100 words is used. No mechanism is 
 provided to abnormally terminate a process. A process terminates only when it 
 reaches the end of its code body. 
 
 4 . 3 Process Storage Considerations . 
 
 A process's storage may be explicitly released and reused with the 
 procedures MARK and RELEASE just like dynamic variable storage. It is not 
 automatically released when a process terminates. Note, however, that it is an 
 error to release this storage before a process completes just as it is 
 incorrect to release a dynamic variable's storage before reaccessing that 
 variable. Also, notice that MARK will only refer to the active process's local 
 heap . 
 
 4.4 Process Lifetimes . 
 
 The lifetime of a block which contains a process declaration is at 
 least as long as the lifetime of any activation of that process. Intervening 
 blocks between the block that contains the process declaration and the pro- 
 cess creation, can complete before the process completes. Thus a block B 
 (which does not contain the process declaration) can create a process, con- 
 tinue executing, and then return control to its calling block. Later control 
 can reenter block B and another creation of the process can be made, even if 
 the first process is still executing. If an attempt is made to exit a block 
 
Page 26 
 which contains a process declaration for which there is an existing activa- 
 tion, the exit will be delayed until that process completes. The following 
 example illustrates these points. 
 
 PROGRAM example( input, output); 
 VAR w : INTEGER; 
 PROCESS a; BEGIN ... END (*a*); 
 
 PROCEDURE b(VAR x : INTEGER); 
 VAR y : CHAR; 
 
 PROCEDURE c(VAR z : CHAR); 
 BEGIN 
 
 a 
 END (*c*); 
 
 BEGIN 
 c(y) 
 END (*b*); 
 
 BEGIN 
 b(w) 
 END (*example*). 
 
 The program block calls 'b' which calls 'c' which creates process 'a'. 
 *c* can then continue executing and complete, returning control to 'b'. The 
 process 'b' can now continue executing in parallel with the activation of 'a' 
 and can complete, returning control to the program block. The program block 
 can continue executing, but it cannot complete until process 'a' has ter- 
 minated. 
 
 4 . 5 Parameter Restriction . 
 
 The scope of an actual parameter which is passed by reference to a process 
 must contain scope of the process's declaration. Consider the following exam- 
 ple where this rule is violated: 
 
Page 27 
 
 PROCESS a (VAR x : INTEGER); BEGIN ... END; 
 PROCEDURE b; 
 
 VAR y : INTEGER; 
 BEGIN 
 
 a(y) 
 END; 
 PROCEDURE c; BEGIN ...END; 
 
 Calling 'b' creates 'a' and passes 'y* by reference, completes, and 
 returns its activation record to the run-time stack. The routine which called 
 'b' might now call 'c' whose activation record will overlay some or all of the 
 space where 'b's old activation record was stored. If 'a' is still executing 
 and it writes into 'y', it will erroneously write into 'c's activation record. 
 
 4.6 Priorities . 
 
 One of two static priority schemes can be associated with processes in 
 order to provide rudimentary control over process scheduling. In the first 
 scheme, all processes have the same priority. In the other, priority is deter- 
 mined by the static nesting level of a process's declaration, with processes 
 declared at the outermost levels having the highest priority. Within a given 
 priority level, a process is selected for execution by a first-in first-out 
 scheduler. If the level oriented scheme is used in the above example, then the 
 writer has higher priority than the reader and the device driven by 'write' 
 (line 22) is kept as busy as possible. The second priority scheme is selected 
 by default, but equal priorities can be chosen by specifying the NP option on 
 the interpreter command card. 
 
Page 28 
 
 4.7 Delaying Processes . 
 
 A process can be delayed for a fixed time interval by calling the pro- 
 cedure DELAY. An integer argument specifies how long the process is to be 
 delayed. The number of simulated time units which have elapsed since execu- 
 tion began can be obtained from the parameterless function TIME which returns 
 an integer value. 
 
 4.8 Interrupt Processes . 
 
 Interrupt processes are used in Path Pascal to program input and out- 
 put devices of the computer. The DOIO statement is used within the interrupt 
 process to suspend it while input or output is being performed. Only one DOIO 
 statement is allowed within the process block. The DOIO statement may not be 
 used in regular processes. The interrupt process mechanism is based on Modula 
 [Wirth,77] and its syntax is show below in BNF: 
 
 <process declaration :: = 
 
 INTERRUPT interrupt process heading> <block> 
 
 <interrupt process heading> ::«= 
 
 PROCESS <identifier> interrupt params>; | 
 PROCESS <Identifier> <interrupt params> 
 ( <formal parameter section> 
 
 { ; <formal parameter section> } ); 
 
 <interrupt params> ::^ 
 
 [ PRIORITY - <unsigned integer> ; 
 VECTOR - <address>] 
 
 <address> ::- //<unslgned octal integer> 
 <unsigned integer> 
 
 mp le:- 
 
Page 29 
 
 INTERRUPT PROCESS print 
 
 [PRIORITY - 4 ; VECTOR = #64] (buf : linebuffer); 
 
 VAR 
 
 1: INTEGER; 
 
 pts [#177564] :bits; (*printer status word*) 
 
 ptb [#177566] :char; (*printer buffer word*) 
 
 BEGIN 
 
 i :« 0; 
 REPEAT 
 
 i := 1+1; 
 
 pts := [6]; (*enable printer interrupt*) 
 ptb := buf [i]; (*print a character*) 
 DOIO; (*wait for the interrupt to occur*) 
 pts := pts-[6]; (*disable printer interrupt*) 
 UNTIL (( i >= linesize ) OR (buf[i] = cr)); 
 END; (*end of process print*) 
 
 The interrupt parameter is used to store the interrupt vector of the 
 process at the correct place in memory and set the priority of the process. In 
 the example, the vector will be stored at octal location 64 and the priority 
 of the process will be 4. (On the PDP11, the priority of the processor is set 
 to the priority of the process it is running. Interrupts from devices can 
 only affect the process when the process priority is less than the priority of 
 the interrupting device. Other processes run with a processor priority of 0. ) 
 
 Interrupt processes are created in exactly the same manner as other 
 processes. Running duplicate interrupt processes or terminating an interrupt 
 process while an interrupt is pending is discouraged. 
 
 The device registers of the printer are, in this example, at location 
 #177564 and #177566. To allow programs to access device registers, variables 
 can be associated with the absolute device addresses. 
 
 <variable declaration> ::= 
 
 <name> {, <name>> : <type> 
 
Page 30 
 
 <name> ::■ <identifier> 
 
 <identif ier> [<address>] 
 
 Thus, "pts" and 'ptb" are declared to be the status and data registers of the 
 printer. The variable "pts" is declared to be of type "bits", a set of numbers 
 from 1 to 16. The interrupt for the printer is enabled by writing a bit into 
 the status register. This is performed above using one of the operations on 
 sets. The DOIO statement, when executed, suspends the process until the inter- 
 rupt is received. Another process is removed from the ready queue and run. 
 Machine dependent features such as device addresses and the DOIO statement are 
 restricted in their use to the block of an interrupt process. 
 
Page 31 
 5 SUMMARY . 
 
 The Path Pascal programming language is an extension of Pascal P4 which 
 includes concurrent processes, processes for controlling I/O devices, path 
 expressions, and objects. The Path Pascal compiler is written in Pascal P4 
 and is self -compiling. An intermediate code (an extended P-Code) is produced 
 by the Path Pascal compiler and can either be executed interpretively or 
 assembled into machine instructions. The language can be used to simulate sys- 
 tens, as an educational tool, or to construct system and real-time programs. 
 
Page 32 
 
 REFERENCES. 
 
 [Andler,1979] 
 
 Andler, Sten, "Predicate Path Expressions", 6th Annual ACM Symposium on 
 Principles of Programming Languages, San Antonio, Tex., 1979, pp. 226-236. 
 
 [Ammann, Nori, and Jacobi,76] 
 
 Ammann, U. , Nori, K. , and Jacobi, C, "The Portable Pascal Compiler", 
 Institut Fuer Informatik, Eidg. Technische Hochschule CH-8096 Zeurich, 
 1976. 
 
 [Campbell and Habermann, 74] 
 
 Campbell, R. H. and Habermann, A. N. , "The Specification of Process Syn- 
 chronization by Path Expressions," Lecture Notes in Computer Science, 
 Springer Verlag, Volume 16, 1974, pp. 89-102. 
 
 [Campbell, 77] 
 
 Campbell, R. H. , "Path Expressions: A technique for specifying process 
 synchronization," Ph.D. Thesis, The University of Newcastle Upon Tyne, 
 August, 1976. 
 
 [Dahl et al,68] 
 
 Dahl, 0. J., Myhrhaug, B., and Nygaard, K. , "The Simula 67 Common Base 
 Language," Norwegian Computer Center, Oslo, 1968. 
 
 [Flon and Habermann, 76] 
 
 Flon, L. and Habermann, A. N. , '^Towards the Construction of Verifiable 
 Software Systems," SIGPLAN Notices, Volume 8, Number 2, March, 1976. 
 
 [Habermann, 75] 
 
 Habermann, A. N. , "Path Expressions," Technical Report, Carnegie-Mellon 
 University, 1975. 
 
 [Habermann, 76] 
 
 Habermann, A. N. , "Introduction to Operating System Design", Science 
 Research Associates, 1976, p. 89. 
 
 [Jensen and Wirth,75] 
 
 Jensen, K. and Wirth, N. , Pascal User Manual and Report , Springer-Verlag, 
 1972. 
 
 [Lauer and Campbell, 75] 
 
 Lauer, P. E. and Campbell, R. H. , "Formal Semantics of a Class of High 
 Level Primitives for Co-ordinating Concurrent Processes," Acta Informa- 
 tica, Volume 5, 1975, pp. 297-332. 
 
 [Lauer and Shields , 1978] 
 
 Lauer, P. E. and Shields, M. W. , "Abstract Specification of Resource 
 
 Accessing Disciplines: Adequacy, Starvation, Priority and Interrupts," 
 
 Slgplan Notices, Volume 13, Number 12, 1978, pp. 41-59. 
 
Page 33 
 
 [Miller, 78] 
 
 Miller, T. J., "An implementation of Path Expressions in Pascal," M.S. 
 Thesis. University of Illinois, Urbana, May, 1978. 
 
 [ONERA CERT, 78] 
 
 "Parallelism, Control and Synchronization Expressions in a Single Assign- 
 ment Language," SIGPLAN Notices, Volume 13, Number 1, January, 1978, pp. 
 25-33. 
 
 [Riddle, 76] 
 
 Riddle, W. E., "Software System Modelling and Analysis," RSSM/25, Tech. 
 Report, Department of Computer and Communicatin Sciences, University of 
 Michigan, July, 1976. 
 
 [Shaw, 77] 
 
 Shaw, A. C, "Software Descriptions with Flow Expressions," Department of 
 Computer Science, University of Washington, October, 1977. 
 
 [Wirth,77] 
 
 Wirth, N., "Modular a Language for Modular Multiprogramming," Software- 
 Practice and Experience, Volume 7, 1977, pp. 3-84. 
 
Page A-l 
 APPENDIX A 
 PATH PASCAL SYNTAX 
 
 The following Backus-Naur form (BNF) grammar summarizes the syntax of 
 Path Pascal. This list of rules only contains the additions to standard Pas- 
 cal. The following symbols are meta-symbols belonging to the BNF formalism and 
 are not symbols of the language Path Pascal. 
 
 I ::« { > 
 
 The curly braces denote the possible repetition of the enclosed symbols zero 
 or more times. 
 
 <block> ::= 
 
 <label declaration part> 
 <constant definition part> 
 <type definition part> 
 <variable declaration part> 
 <routine part> 
 <statement part> 
 
 <unpacked structured type> ::■ 
 <array type> 
 <record type> | 
 <object type> | 
 <set type> | 
 <file type> 
 
 <object type> ::= OBJECT <object block> END 
 
 <object block> ::- 
 
 <path declaration part> 
 
 <constant definition part> 
 
 <type definition part> 
 
 <object variable declaration part> 
 
 <operation declaration part> 
 
 <initialization part> 
 
Page A- 2 
 
 <path declaration part> 
 <empty> | 
 <open path> 
 
 <open path> ::= PATH <list> END; 
 
 <list> ::= 
 
 <sequence> 
 <sequence> , <list> 
 
 <sequence> : : = 
 <item> | 
 <item> ; <sequence> 
 
 <item> : : = 
 
 <integer bound> : ( <list> ) 
 [ <list> ] | 
 <operation id> | 
 ( <list> ) 
 
 <bound> ::= <unsigned integer> 
 <positive constant> 
 
 <operation id> ::= 
 <identifier> 
 
 <object variable declaration part> ::= 
 VAR <variable declaration> 
 
 { ; <variable declaration> } ; 
 
 <operation declaration part> 
 { <operation part> } 
 
 <operation part> : 
 <routine> | 
 <operation> 
 
 <routine part> : :» 
 { <routine> } 
 
Page A- 3 
 
 <routine> : :■ 
 
 <procedure declaration> 
 <function declaration> 
 <process declaration 
 
 <operation> : : - 
 
 ENTRY <routine> 
 
 <process declaration> ::■ 
 
 <process heading> <block> | 
 
 INTERRUPT <interrupt process heading> <block> 
 
 process heading> : : = 
 
 PROCESS <identifier> <size part>; | 
 PROCESS <identifier> <size part> 
 ( <formal parameter section> 
 
 { ; <formal parameter section> > ); 
 
 <size part> : : ■ 
 
 [ <unsigned integer> ] 
 
 <interrupt process heading> ::= 
 
 PROCESS <identifier> interrupt params>; | 
 PROCESS <identifier> <interrupt params> 
 ( <formal parameter section> 
 
 < ; <f ormal parameter section> } ) ; 
 
 <interrupt params> ::■ 
 
 [ PRIORITY = <unsigned integer> ; 
 VECTOR - <address>] 
 
 <address> : := #<unsigned octal integer> 
 <unsigned integer> 
 
 <Variable declaration : :* 
 
 <name> {, <name>) : <type> 
 
 <name> ::« <identifier> | 
 
 <identifier> [ <address>] 
 
Page A- 4 
 
 <simple statements ::■ 
 
 assignment statement> | 
 <procedure statement> | 
 <proces8 statement> | 
 <go to statement> | 
 <object procedure statement> 
 <object process statement> | 
 DOIO | 
 <empty> 
 
 <object variable> : : = 
 <variable> 
 
 <component variable> : : = 
 <indexed variable> | 
 <field designator> | 
 <file buffer> | 
 <object designator> 
 
 <object designator> ::= 
 
 <record variable> . <object identifier> 
 
 <object identifier> ::= 
 <identifier> 
 
 <factor> ::«= 
 
 <variable> | 
 
 <unsigned constant> | 
 
 ( <expression> ) | 
 
 <function designator> | 
 
 <object function designator> 
 
 <set> | 
 
 NOT <factor> 
 
 <object function designator> ::= 
 
 <object variable> . <function designator> 
 
 <object procedure statement> : : ■ 
 
 <object variable> . procedure statement> 
 
 <object process statement> ::- 
 
 <object variable> . <process statement> 
 
Page A-5 
 
 <process statement> ::■ 
 
 <process identifier> | 
 
 <proce8s identif ier> ( <actual parameter> 
 { , <actual parameter> } ) 
 initialization part> : :« 
 
 <enpty> | 
 
 INIT; <block> 
 
Page B-l 
 APPENDIX B 
 
 ERROR MESSAGES, CONTROL OPTIONS, AND CONSTANTS 
 
 This appendix contains information related to the Path Pascal compiler 
 and interpreter. First, compiler options, an important compiler constant, and 
 error messages issued by the compiler are listed. This is followed by the 
 interpreter control statement options, major constants, load-time error mes- 
 sages, and run-time error messages. 
 
 B.l PATH PASCAL COMPILER OPTIONS 
 
 $T print tables (default -) 
 
 $L print listing (default +) 
 
 $D debug mode (default +) 
 
 $C generate code (default +) 
 
 $S report local storage per block (default +) 
 
 B.2 PATH PASCAL COMPILER CODE AND CONSTANTS 
 
 To convert the Path Pascal compiler from Pascal 6000 to Pascal P4, 
 remove the three portions of code enclosed between comments (**P4REM0VE**) and 
 (**P4ENDREM0VE**). 
 
 LCAFTERMARKSTACK-7; Must have the same value as the inter- 
 preter constant of the same name 
 
Page B-2 
 
 B.3 PATH PASCAL ERROR MESSAGES 
 
 1 
 
 2 
 
 4 
 
 5 
 
 6 
 
 7 
 
 8 
 
 9 
 
 10 
 
 11 
 
 12 
 
 13 
 
 14 
 
 15 
 
 16 
 
 17 
 
 18 
 
 19 
 
 20 
 
 21 
 
 Error in simple type. 
 
 Identifier expected. 
 
 ")'* expected. 
 
 ":" expected. 
 
 Illegal symbol. 
 
 Error in parameter list. 
 
 M 0F" expected. 
 
 "(" expected. 
 
 Error in type. 
 
 "[" expected. 
 
 "] " expected. 
 
 "END" expected. 
 
 ";" expected. 
 
 Integer expected. 
 
 "=" expected. 
 
 "BEGIN" expected. 
 
 Error in declaration part. 
 
 Error in field-list. 
 
 "," expected. 
 
 "*" expected. 
 
 50 
 51 
 52 
 53 
 54 
 55 
 58 
 59 
 
 Error in constant. 
 
 ":■" expected. 
 
 "THEN" expected. 
 
 "UNTIL" expected. 
 
 "DO" expected. 
 
 "TO" or "DOWNTO" expected. 
 
 Error in factor. 
 
 Error in variable. 
 
 101 
 102 
 103 
 104 
 105 
 106 
 107 
 108 
 109 
 110 
 111 
 113 
 114 
 115 
 116 
 117 
 119 
 120 
 
 Identifier declared twice. 
 
 Low bound exceeds high bound. 
 
 Identifier is not of appropriate class. 
 
 Identifier not declared. 
 
 Sign not allowed. 
 
 Number expected. 
 
 Incompatible subrange types. 
 
 File not allowed here. 
 
 Type must not be real. 
 
 Tagfield type must be scalar or subrange. 
 
 Incompatible with tagfield type. 
 
 Index type must be scalar or subrange. 
 
 Base type must not be real. 
 
 Base type must be scalar or subrange. 
 
 Error In type of standard procedure parameter. 
 
 Unsatisfied forward reference. 
 
 Forward declared; repetition of parameter list not allowed. 
 
 Function result type must be scalar, subrange or pointer. 
 
Page B-3 
 
 File value parameter not allowed. 
 
 Forward declared function; repetition of result type not allowed. 
 
 Missing result type in function declaration. 
 
 F-format for real only. 
 
 Error in type of standard function parameter. 
 
 Number of parameters does not agree with declaration. 
 
 Result type of parameter/function does not agree with declaration. 
 
 Type conflict of operands. 
 
 Expression is not of set type. 
 
 Tests on equality allowed only. 
 
 Strict inclusion not allowed. 
 
 File comparison not allowed. 
 
 Illegal type of operand (s). 
 
 Type of operand must be boolean. 
 
 Set element type must be scalar or subrange. 
 
 Set element types not compatible. 
 
 Type of variable is not array. 
 
 Index type is not compatible with declaration. 
 
 Type of variable is not record. 
 
 Type of variable must be file or pointer. 
 
 Illegal parameter substitution. 
 
 Illegal type of loop control variable. 
 
 Illegal type of expression. 
 
 Type conflict. 
 
 Assignment of files not allowed. 
 
 Label type incompatible with selecting expression. 
 
 Subrange bounds must be scalar. 
 
 Index type must not be integer. 
 
 Assignment to standard function is not allowed. 
 
 Assignment to formal function is not allowed. 
 
 No such field in this record. 
 
 Actual parameter must be a variable. 
 
 Control variable must be neither formal nor global. 
 
 Multidefined CASE label. 
 
 Too many CASEs in CASE statement. 
 
 Missing corresponding variant declaration. 
 
 REAL or STRING tagfields not allowed. 
 
 Previous declaration was not forward. 
 
 Again FORWARD declared. 
 
 Parameter size must be constant. 
 
 Multidefined label. 
 
 Multideclared label. 
 
 Undeclared label. 
 
 Undefined label. 
 
 Cannot pass a procedure, function, or process as a formal parameter 
 
 Duplicate value in varient record. 
 
 Error in real constant; digit expected. 
 String constant must not exceed source line. 
 Integer constant exceeds range. 
 
 250: Too many nested scopes of identifiers 
 
Page B-4 
 
 251: Too many nested procedures and/or functions 
 254: Too many LONG constants in this procedure. 
 
 304: Element expression out of range 
 
 381: GOTO leads out of procedure. 
 
 382: Illegal Symbol. 
 
 383: String too long. 
 
 384: Real Pointers not allowed for rangetype. 
 
 385: Strings not available here. 
 
 386: Files not supported. 
 
 387: Procedure not allowed. 
 
 388: Function not allowed. 
 
 389: Only get, put available here. 
 
 390: Character files required. 
 
 391: Only CHARacter type allowed here. 
 
 392: Only character files allowed. 
 
 393: Real pointer not allowed. 
 
 394: Scalar not allowed. 
 
 395: PACK not allowed. 
 
 396: UNPACK not allowed. 
 
 397: Passed argument must not be function or procedure. 
 
 401: Invalid parenthesis in path. 
 
 404: Unable to find procedure entry in path. 
 
 409: Passed variable has nesting level too high. 
 
 410: Interrupt process expected. 
 
 412: Expecting declaration within object. 
 
 413: Indexed variable not allowed. 
 
 414: Indirection limit exceeded (compiler error) 
 
 415: Expecting STRING. 
 
 416: Expression not allowed. 
 
 417: Undefined entry, procedure or function. 
 
 429: PP stack overflow. 
 430: VV stack, overflow. 
 
 500: Files not supported. 
 
 501: Variants, tagflds not allowed. 
 
 502: Files, tagflds, variants not allowed. 
 
 701: Expected stack, priority, or vector. 
 
 702: Machine dependent declarations must be in interrupt processes 
 
 
Page B-5 
 
 B.4 INTERPRETER CONTROL STATEMENT OPTIONS 
 
 /LNLMT - Remove line limit restrictions on OUTPUT and PRR. 
 
 - Default line limit is 500 lines. 
 
 /TRACE - Display HSC machine registers after each pcode instruction. 
 
 - Default action is no display. 
 
 /NP - Do not assign priorities to processes. 
 
 - The default action is to assign priority to processes according to 
 their static nesting level. (See section 5.6 for more details.) 
 
 /DEBUG - Generate a trace of process executions 
 - The default action is no trace 
 
 B.5 INTERPRETER CONSTANTS 
 
 CODEMAX-8192; 
 PCMAX»C0DEMAX*2; 
 MAXSTR-OVERM+1 ; 
 OVERM=8000; 
 OVERBOVERM-4180; 
 OVERS =OVERB-90; 
 OVERR-OVERS-70; 
 OVERI-OVERR-5; 
 MAXSTK«OVERI-5(=3650) ; 
 
 TIMESLICE-1000; 
 
 LCAFTERMARKSTACK-7 ; 
 
 Number of code space words 
 
 Generate 2 instructions per word 
 
 Used to test whether addresses are in range 
 
 Number of data space words 
 
 Reserve 4180 words for character strings 
 
 Reserve 90 words for boundary information 
 
 Reserve 70 words for sets 
 
 Reserve space for 5 REAL constants 
 
 Reserve space for 5 INTEGER constants (Note that 
 3650 words remain for the stack and heap.) 
 
 Number of instructions executed between process 
 switches 
 
 Must have the same value as the compiler constant 
 of the same name 
 
Page B-6 
 
 B.6 INTERPRETER LOAD-TIME ERROR MESSAGES 
 
 DUPLICATED LABEL 
 ILLEGAL INSTRUCTION 
 INTEGER TABLE OVERFLOW 
 
 REAL TABLE OVERFLOW 
 
 ILLEGAL CHARACTER 
 
 SET TABLE OVERFLOW 
 
 BOUNDARY TABLE OVERFLOW 
 
 MULTIPLE TABLE OVERFLOW 
 
 Unknown opcode in pcode 
 
 Too many integer constants (to fix alter inter- 
 preter constant OVERI) 
 
 Too many real constants (to fix alter interpreter 
 constant OVERR) 
 
 Character constant mist be enclosed in single 
 quotes (e.g. , 'x' ) 
 
 Too many set constants (to fix alter interpreter 
 constant OVERS) 
 
 Too many bounds (array bounds or subranges) (to fix 
 alter interpreter constant OVERB) 
 
 Too many character strings (to fix alter inter- 
 preter constant OVERM) 
 
 B.7 INTERPRETER RUN-TIME ERROR MESSAGES 
 
 UNINITIALIZED SEMAPHORE 
 
 GET ON OUTPUT FILE 
 GET ON PRR FILE 
 PUT ON READ FILE 
 PUT ON PRD FILE 
 READLN ON OUTPUT FILE 
 WRITELN ON INPUT FILE 
 WRITELN ON PRD FILE 
 WRITE ON INPUT FILE 
 WRITE ON PRD FILE 
 READ ON OUTPUT FILE 
 
 Illegal use of uninitialized semaphore. (Probably 
 due to compiler error.) 
 
READ ON PRR FILE 
 
 Page B-7 
 
 EOLN OUTPUT FILE 
 EOLN ON PRR FILE 
 
 EOLN only permitted on INPUT and PRD 
 
 STORE OVERFLOW Possible causes 
 
 - Heap exhausted due to NEW 
 
 - Heap exhausted due to processes activation (PST ) 
 
 - Stack exhausted due to activation record (ENT 1) 
 
 - Stack exhausted due to procedure temporary space 
 (ENT 2) 
 
 <,<-»>.>" FOR ADDRESS Only - and <> can be used with a pointer 
 
 SET INCLUSION 
 
 Only " t <>, <■, >= can be used with a set 
 
 BAD POINTER VALUE 
 
 Pointer not within heap 
 
 VALUE OUT OF RANGE 
 
 CODE IN ERROR 
 
 EOF can only be used with INPUT 
 
 CASE - ERROR 
 
 No case provided for this value 
 
 RDY AND EVNT QUES EMPTY All processes waiting for semaphores; program is 
 
 deadlocked 
 
Page C-l 
 APPENDIX C 
 
 SEMANTICS AND REDUCTION ALGORITHM FOR OPEN PATHS 
 
 Open Path semantics are described below in terms of P and V operations 
 on counting semaphores in the prologues and epilogues of the procedures, func- 
 tions, and processes. The following recursive algorithm [Campbell, 77] will 
 translate open paths into this P and V implementation. In general, the path 
 expression to be translated will be surrounded by two strings of generated 
 synchronization operations which are on its left and right (L and R respec- 
 tively.) The following set of transformation rulesis applied in the order 
 given by the parse tree or derivation of the path expression using the produc- 
 tion rules above. The notation "[init: sx <- y] M denotes initializing sx to 
 
 y- 
 
 Initialization of reduction algorithm: 
 
 Replace: "PATH list END" 
 
 by: "list" (L and R are empty strings) 
 
 The comma is used as a distributive mechanism for the synchronization 
 in which it is embedded: 
 
 Replace: "L sequence, list R" 
 
 by: "L sequence R" 
 and 
 
 by: "L list R" 
 
 The strings L and R are duplicated and later used in the application of the 
 
 algorithm to both 'sequence' and 'list'. 
 
 The semicolon is used as a sequencing mechanism; execution of 
 'sequence' may only follow 'item': 
 
Page C-2 
 
 Replace: "L item; sequence R" 
 
 by: "L item V(sl) M 
 and 
 
 by: M P(sl) sequence R" [init: si <- 0] 
 
 When the algorithm is later applied to 'item', V(sl) comprises R; when applied 
 to 'sequence' L is P(sl). 
 
 Colons denote permission for concurrent execution (the sharing of up 
 to n resources): 
 
 Replace: "L n: (list) R M 
 
 by: "P(s2) L list R V(s2) M [init: s2 <- n] 
 
 When a procedure identifier is nested within several of these constructions, 
 
 the order in which operations are concatenated to the strings L and R ensures 
 
 that the synchronization specified by more deeply nested constructions is 
 
 applied first. 
 
 Brackets ("[" and "]") specify "burst execution" and permit concurrent 
 execution to be synchronized with other coordination schemes: 
 
 Replace: "L [list] R" 
 
 by: "PP(c, s, L) list W(c, s, R)" 
 
 [init: s <- 1, c <- 0] 
 
 where PP and W are defined below: 
 
 PROCEDURE PP (COUNTER c; SEMAPHORE s; PROCEDURE synch); 
 BEGIN 
 P(8)J 
 
 c :- c + 1; 
 IF c-1 THEN synch; 
 V(s) 
 END; 
 
 
Page C-3 
 
 PROCEDURE W (COUNTER c; SEMAPHORE s; PROCEDURE synch); 
 BEGIN 
 P(s); 
 
 c :- c - 1 ; 
 IF c-0 THEN synch; 
 V(s) 
 END; 
 
 The PP and VV operations implement the simultaneous execution synchronization. 
 
 Parsing is complete when only routine names remain: 
 
 Replace: "L routine_id R" 
 by : BEGIN 
 L 
 
 body of routine_id 
 R 
 END 
 
 This algorithm must constrain each routine name to appear exactly once 
 in a given Path expression. This restriction may be removed if repeated names 
 are treated as further nesting of synchronization constraints. 
 
Page D-l 
 APPENDIX D 
 
 PROGRAMMING EXAMPLES 
 
 D.l Printer Example 
 
 The following problem is taken from [Habermann, 76] : 
 
 A group of processes pl,p2,...pn (n>»4) share three line printers 
 LP1, LP2, and LP3. In order not to mix output lines from different 
 processes, a process must reserve a line printer before using it. A 
 variable is attached to each printer which specifies the index of 
 the process currently using the line printer or zero if the line 
 printer is free. A lineprinter control process, LPC , has an output 
 buffer with the capacity of one printer line. Once a process 
 succeeds in reserving an LP, it starts interacting with the LPC of 
 the lineprinter to get its output printed. When the buffer is full, 
 the LPC should print its contents and notify the process that the 
 buffer is empty. Write cooperating programs for a process and an LPC 
 and the program reserving and releasing a line printer. 
 
 This problem may be broken up into four parts. First, there should be 
 a line printer control process which has two functions: allocate actual line 
 printers to user processes and deallocate actual line printers from user 
 processes. These functions will be provided by the 'manager'. Second, there 
 should be a process which empties a line printer buffer to the actual line 
 printer. One such process should be instantiated for each line printer. A spe- 
 cial machine dependent process called a 'device process' will be assumed to 
 exist to perform this function. Third, there should be an interface between 
 the user process and the operating system that will help prevent line printer 
 abuse. This 'virtual printer' will interact with the 'manager' to request and 
 release actual line printers and with the line printer buffer to output infor- 
 mation for the user process. Finally, the user process will generate data and 
 have it printed to some line printer. 
 
 The following code is a skeletal outline of how the various system 
 
Page D-2 
 
 components would be declared in the actual program. 
 
 TYPE 
 
 buffer = OBJECT . 
 
 . END; (*buffer*) 
 
 VAR 
 
 manager : OBJECT ... END; (*manager*) 
 lpbuffers : ARRAY [1.. 3] OF buffer; 
 
 PROCEDURE initsyscomponents; 
 
 TYPE 
 
 virtualprlnter "OBJECT ... END; (*virtualprinter*) 
 
 PROCESS userl; BEGIN . 
 PROCESS user 2; BEGIN . 
 
 . END; (*userl*) 
 . END; (*user2*) 
 
 PROCESS usern; BEGIN 
 
 END; (*usern*) 
 
 DEVICE PROCESS lineprinter ( VAR localbuff 
 BEGIN ... END; (*lineprinter*) 
 
 BEGIN 
 
 lineprinter (lpbuffers [1] , . . . ) 
 lineprinter (lpbuffers [2] , « * • ) 
 lineprinter (lpbuffers [3] , . . . ) 
 userl; user2; ... usern 
 
 END; (*initsyscoraponents*) 
 
 buffer;. . . ) ; 
 
 The 'manager' will have two entry operations. The function, 
 'requestno', reserves an actual line printer for a user process. The pro- 
 cedure, 'releaseno', returns an actual line printer to the free pool of line 
 printers. 'Requestno' should be executed mutually exclusively, and 'releaseno' 
 should be executed mutually exclusively. At most three user processes should 
 be allowed to execute the 'requestno' function, and a 'releaseno' should not 
 be allowed until the 'requestno' has been completed. The path 
 
 PATH 3:( 1: (requestno) ; 1 : (releaseno) ) END; 
 
Page D-3 
 specifies these constraints completely. The variable which determines which 
 process is running on which printer is declared as 
 
 processusingprinter - ARRAY [1.. 3] OF processnumber ; 
 
 where processusingprinter [i] tells which process is running on the ith 
 printer. Finally, all printers should be initialized to the idle state. This 
 is acconplished by: 
 
 FOR i := 1 TO 3 DO 
 
 processusingprinter [i] :» 0; 
 
 The following program segment performs the requested duties. 
 
Page D-4 
 
 VAR 
 
 manager : OBJECT 
 
 PATH 3: ( 1: (requestno) ; 1: (releaseno) ) END; 
 
 VAR 
 
 processusingprinter : ARRAY[1..3] OF processnumber 
 
 ENTRY FUNCTION requestno ( 
 
 i : processnumber ) : INTEGER; 
 
 VAR 
 
 j : INTEGER; reserved : BOOLEAN; 
 
 BEGIN 
 
 j := 1; reserved := true; 
 WHILE reserved DO 
 
 IF processusingprinter [j] * 
 THEN BEGIN 
 
 processusingprinter [j] :» i; 
 reserved := false 
 END 
 
 ELSE j := j+1; 
 reqestno := j 
 END; (*requestno*) 
 
 ENTRY PROCEDURE release (i : INTEGER); 
 
 BEGIN 
 
 processusingprinter[i] :* 
 END; (*releaseno*) 
 
 INIT; 
 
 VAR 
 
 i : INTEGER; 
 
 BEGIN 
 
 FOR i :» 1 TO 3 DO 
 
 processusingprinter [i] := 
 END; 
 END; (*manager*) 
 
 Each user process needs a 'virtualprinter' that will interface with 
 the 'manager' and the actual line printer. A user may: 'request' that one of 
 three line printers be reserved for him, 'release' his dedicated line printer, 
 or 'print' Information out to his dedicated printer. A user process may only 
 'request' a line printer if no printer had been previously allocated to it- A 
 
Page D-5 
 user proceas may 'release' only its dedicated printer. Finally, a user process 
 may only 'print' if it has a dedicated line printer. These conditions are 
 specified by the object, 'virtualprinter', declared below. 
 
 TYPE 
 
 virtualprinter - OBJECT 
 
 PATH release , request , print END; 
 
 VAR 
 
 i : 0. .3 
 
 ENTRY PROCEDURE request ( j : processnumber) ; 
 
 BEGIN 
 
 IF i - THEN i :« manager. requestno( j ) 
 END; 
 
 ENTRY PROCEDURE release; 
 
 BEGIN 
 
 IF i > THEN manager, releaseno(i) 
 
 END; 
 
 ENTRY PROCEDURE print (VAR x:line; j rprocessnumber) ; 
 
 BEGIN 
 
 IF i » THEN i :■ manager. requestno(j ) ; 
 
 lpbuffers[i].fill(x) 
 END; 
 
 INIT; 
 
 BEGIN 
 
 1 :- 
 
 END; 
 END; 
 
 DEVICE PROCESS lineprinter ( VAR localbuff : buffer;...); 
 
 VAR 
 
 outline : line; 
 
 BEGIN 
 
 REPEAT 
 
 localbuff .empty (out line) ; 
 <print outline to line printer> 
 UNTIL false 
 END; 
 
Page D-6 
 The device process, 'lineprlnter', is the machine dependent process 
 that takes a line from the user defined buffer, 'localbuff, and outputs it to 
 the line printer. The user defined type, 'buffer', is an object which has been 
 declared earlier. The circular buffer example presented below in Section D.2 
 might be easily adapted for this purpose. 'Buffer' is the same user defined 
 type that appeared in the 'print' procedure in 'virtualprinter' . Notice that 
 in both cases, no information is used about the buffer's internal structure. 
 Therefore, 'buffer' could be modified extensively, as long as 'empty' and 
 'fill' are the entry operations, without forcing the programmer to examine the 
 rest of his program. This illustrates the high degree of program modularity 
 attainable in Path Pascal. The continuation dots in the process heading indi- 
 cate that some machine dependent features might go here (i.e., parameters 
 specifying the line printer priority and interrupt vector address). 
 
 A simple example of how a user program might be declared utilizing a 
 virtual printer is: 
 
 PROCESS userl; 
 
 VAR 
 
 lp : virtualprinter; 
 
 computebuf fer : line; 
 BEGIN 
 
 lp .request (1 ) ; 
 
 REPEAT 
 
 confutation filling computebuf fer 
 lp. print (computebuf fer, 1) 
 
 UNTIL no more computations; 
 
 lp .release 
 END; 
 
 D.2 Circular Buffer Example 1. 
 
 This example is taken from an earlier paper on path expressions [Camp- 
 bell and Habermann, 74] for purposes of comparison. It was used as the major 
 
Page D-7 
 example In the section on encapsulation. 
 
 1 TYPE 
 
 2 buffer - OBJECT 
 
 3 PATH 5 : ( I: (fill) ; 1: (empty) ) END; 
 
 4 TYPE 
 
 5 buffsize - 0. .4; 
 
 6 inbuff - ARRAY [buffsize] of CHAR; 
 
 7 nextspot - OBJECT 
 
 8 PATH inpointer , outpointer END; 
 
 9 VAR 
 
 10 inp,outp : buffsize; 
 
 11 ENTRY PROCEDURE inpointer (VAR x : buffsize); 
 
 12 BEGIN 
 
 13 x := ( inp + 1 ) MOD 5; 
 
 14 inp :» x 
 
 15 END; 
 
 16 ENTRY FUNCTION outpointer : buffsize; 
 
 1 7 BEGIN 
 
 18 outp :» ( outp + 1 ) MOD 5; 
 
 19 outpointer :» outp 
 
 20 END; 
 
 21 INIT; 
 
 22 BEGIN 
 
 23 inp : e 0; outp :■ 
 
 24 END; 
 
 25 END; (*nextspot*) 
 
 26 VAR 
 
 27 buf : inbuff; 
 
 28 pointers : nextspot; 
 
 29 ENTRY PROCEDURE fill ( in char : CHAR ); 
 
 30 VAR 
 
 31 x : buffsize; 
 
 32 BEGIN 
 
 33 pointers. inpointer(x) ; 
 
 34 buf [x] :* inchar 
 
 35 END; (*fill*) 
 
 36 ENTRY FUNCTION empty : CHAR; 
 
 37 VAR 
 
 38 x : buffsize; 
 
 39 BEGIN 
 
 40 x := pointers. outpointer; 
 
 41 empty :- buf [x] 
 
 42 END; (*empty*) 
 
 43 END; (*buffer*) 
 
 This example illustrates circular buffering using five buffers. The 
 path in line 3 states that 5 'fill' operations might be attempted before one 
 'empty' operation, but no 'empty' operation may begin until at least one 
 
Page D-8 
 'fill' has been completed. Unlike the original example, the number of path 
 expressions has been reduced at the expense of making the operation 'fill' 
 mutually exclusive and making the operation 'empty' mutually exclusive. 
 Processes invoking the 'fill' and 'empty' routines must know which buffer they 
 should access. This information is provided by the nested object, 'nextspot'. 
 Only one process at a time should be able to access either of the buffer 
 pointers ('inp' and 'outp'), but one process may access the 'inp' pointer 
 while another process is accessing the 'outp' pointer. These synchronization 
 constraints are imposed by the path expression in line 8. Note, an alternative 
 scheme might have been to declare two separate variables to represent the 
 buffer pointers. Lines 21-24 show how it is possible to initialize object 
 variables at block entry time. Lines 33 and 40 show the notation required to 
 access object variables. 
 
Page D-9 
 
 D.3 Circular Buffer Exaiqple 2. 
 
 PROGRAM EX1 (INPUT, OUTPUT); 
 TYPE 
 
 BUFFER-OBJECT 
 
 PATH 5: (1: (FILL); 1: (EMPTY)) END; 
 TYPE 
 
 BUFINDX-0. .4; 
 
 INBUFF-ARRAY[BUFINDX] OF CHAR; 
 VAR 
 
 INPTR,OUTPTR:BUFINDX; 
 BUF:INBUFF; 
 ENTRY PROCEDURE FILL (INCHAR: CHAR ) ; 
 BEGIN 
 
 INPTR:=(INPTR+1) MOD 5; 
 BUF[INPTR] : -INCHAR; 
 END;(*FILL*) 
 ENTRY FUNCTION EMPTY: CHAR; 
 BEGIN 
 
 OUTPTR:«(OUTPTR+l) MOD 5; 
 EMPTY :-BUF[OUTPTR] ; 
 END;(*EMPTY*) 
 INIT; 
 BEGIN 
 
 INPTR : -0 ;OUTPTR : -0 ; 
 END;(*INIT*) 
 END;(*BUFFER*) 
 VAR 
 
 CIRCULAR: BUFFER; 
 CH1,CH2:CHAR; 
 BEGIN (*MAIN PROGRAM STARTS HERE*) 
 CIRCULAR. FILL (CHI); 
 CH2: -CIRCULAR. EMPTY; 
 END. (*END OF MAIN PROGRAM*) 
 
Page D-10 
 
 D.4 Circular Buffer Exanple 3. 
 
 PROGRAM BUFV2(INPUT,OUTPUT); 
 
 CONST 
 
 NUMBUFFERS-5; 
 
 TYPE 
 RINGBUF=OBJECT 
 
 PATH SPOOL, UNSPOOL END; 
 
 TYPE 
 
 BUFINDX=0. .4; 
 BUF=OBJECT 
 
 PATH 1: (PUT; GET) END; 
 
 VAR CH-.CHAR; 
 
 ENTRY PROCEDURE PUT (C : CHAR); 
 
 BEGIN 
 
 CH:=C; mJ . x 
 
 END-(*END OF ENTRY PROCEDURE PUT*) 
 ENTRY PROCEDURE GET (VAR C:CHAR); 
 BEGIN 
 
 C:=CH; 
 END;(*END OF ENTRY PROCEDURE GET*) 
 END; (*END OF OBJECT BUF*) 
 
 POINTER=OBJECT 
 
 PATH 1: (NEXTPTR) END; 
 
 VAR 
 
 P:BUFINDX; 
 ENTRY FUNCTION NEXTPTR: BUF INDX; 
 
 BEGIN 
 
 NEXTPTR:=P; 
 
 P-=(P+1) MOD NUMBUFFERS; 
 END;(*END OF ENTRY FUNCTION NEXTPTR*) 
 INIT; 
 
 BEGIN 
 P:=0; 
 
 END;(*END OF INIT OF OBJECT POINTER*) 
 
 END;(*END OF OBJECT POINTER*) 
 
 VAR 
 
 HEAD, TAIL :POINTER; 
 
 BUFFER : ARRAY [BUFINDX] OF BUF; 
 
 ENTRY PROCEDURE SPOOL (C : CHAR) ; 
 
 BEGIN 
 
 BUFFER [HEAD. NEXTPTR] .PUT (C) ; 
 
 END; 
 
 ENTRY PROCEDURE UNSPOOL (VAR C:CHAR); 
 
 BEGIN 
 
 BUFFER[TAIL. NEXTPTR]. GET(C); 
 END;(*END OF ENTRY PROCEDURE UNSPOOL*) 
 END;(*END OF OBJECT RINGBUF*) 
 
 BEGIN (*MAIN PROGRAM STARTS HERE*) 
 END. 
 
Page D-ll 
 D.5 Teletype Input/Output. 
 
 PROGRAM MINIOSVl(INPUT, OUTPUT); 
 CONST 
 
 LINEBUFSIZE-160; 
 
 READBUFSIZE-5; 
 
 BS-#010; (*BACKSPACE OR CONTROL H*) 
 
 CR-#015; (CARRIAGE RETURN*) 
 
 ESC-0033; (*ESCAPE*) 
 TYPE 
 
 READPTRTYPE-O. .READBUFSIZE; 
 LINEPTRTYPE-O- .LINEBUFSIZE; 
 READBUFTYPE-ARRAY[1.. READBUFSIZE] OF CHAR; 
 LINEBUFTYPE-ARRAYfi.. LINEBUFSIZE] OF CHAR; 
 PROSIDTYPE-INTEGER; (*PROCESS ID TYPE*) 
 TELEIDTYPE-INTEGER; (*TELETYPE ID TYPE*) 
 BITS-SET OF 0. .15; (*BITS IS USED AS DEVICE 
 
 STATUS /COMMAND WORD*) 
 (*OBJECT DEFINITIONS COMES IN HERE*) 
 OBJOFTELE-OBJECT 
 
 PATH 1: (INTO;OUT),l: (OPEN;CLOSE) END; 
 
 (*ENTRY PROCEDURE INTO IS FOR TELETYPE INPUT*) 
 
 (*ENTRY PROCEDURE OUT IS FOR TELETYPE OUTPUT*) 
 
 (*ENTRY PROCEDURE OPEN IS FOR TELETYPE RESERVING*) 
 
 (*ENTRY PROCEDURE CLOSE IS FOR TELETYPE RELEASING*) 
 
 (*LOCAL OBJECT DIFINITION OF OBJOFTELE*) 
 TYPE 
 
 OBJOFPROMPTOBJECT 
 
 PATH DONEPROMPT;STARTGET END; 
 
 ENTRY PROCEDURE DONEPROMPT; 
 BEGIN 
 
 END; (*END OF ENTRY PROCEDURE DONEPROMPT*) 
 
 ENTRY PROCEDURE STARTGET ; 
 BEGIN 
 
 END; (*END OF ENTRY PROCEDURE STARTGET*) 
 END; (*END OF OBJECT OBJOFPROMPT*) 
 
 VAR 
 
 READBUFFER : READBUFTYPE; 
 
 LINEBUFFER:LINEBUFTYPE; 
 
 TELEUSER:PROSIDTYPE; 
 
 READ I N , ECHOOUT : READPTRT YPE ; 
 
Page D-12 
 
 EDITIN : LINEPTRT YPE ; 
 RESET: BOOLEAN; 
 PROMPTS YNC : OB JOFPROMPT ; 
 INOBJ: OBJECT 
 
 PATH 5: (GETSSYNC; ECHOSYNC) END; 
 
 (*ENTRY PROC GETSSYNC READS ONE CHARACTER 
 
 WHEN IT'S INSTANTIATED*) 
 (*ENTRY PROC ECHOSYNC ECHOS ONE CHARACTER WHEN 
 IT'S INSTANTIATED*) 
 
 PROCEDURE EDIT(VAR EDITIN:LINEPTRTYPE;CH:CHAR) ; 
 BEGIN 
 
 IF ORD(CH)=BS THEN 
 
 IF (EDITIN>(LINEBUFSIZE-1)) THEN 
 
 EDITIN :=(LINEBUFSIZE+EDITIN-1) MOD 
 
 LINEBUFSIZE 
 (*BACK PTR EDITIN BY 1 *) 
 ELSE 
 
 IF (ORD(CH)=ESC) THEN 
 
 EDITIN: =LINEBUFSIZE-1 
 ELSE 
 BEGIN 
 
 EDITIN := (ED ITIN+1) MOD LINEBUFSIZE; 
 LINEBUFFER [EDITIN+1 ] : =CH ; 
 END; 
 END; (*END OF PROCEDURE EDIT*) 
 
 ENTRY PROCEDURE GETSSYNC (VAR READIN : 
 
 READPTRTYPE); 
 BEGIN 
 
 READIN :=(READIN+1) MOD READBUFSIZE; 
 END; (*END OF ENTRY PROCEDURE GETSSYNC*) 
 
 ENTRY PROCEDURE, ECHOSYNC ( 
 
 VAR ECHOOUT, EDITIN: READPTRTYPE); 
 BEGIN 
 
 ECHOOUT :«(ECHOOUT+l) MOD READBUFSIZE; 
 IF NOT RESET THEN 
 
 EDIT(EDITIN,READBUFFER[ECHOOUT+l] ); 
 END; (*END OF ENTRY PROCEDURE ECHOSYNC*) 
 
 END; (*END OF OBJECT INOBJ*) 
 
 FETCHOBJ:OBJECT 
 
 PATH MOVE; FETCH END; 
 
Page D-13 
 
 (*ENTRY PROCEDURE MOVE PUTS LINEBUFFER TO 
 
 EDITBUFFER*) 
 (*ENTRY PROCEDURE FETCH GETS LINEBUFFER FROM 
 
 EDITBUFFER*) 
 ENTRY PROCEDURE MOVE; 
 BEGIN 
 END; (*END OF ENTRY PROCEDURE MOVE*) 
 
 ENTRY PROCEDURE FETCH (VAR BUF:LINEBUFTYPE) ; 
 BEGIN 
 
 BUF: -LINEBUFFER; 
 END; (*END OF ENTRY PROCEDURE FETCH*) 
 
 END; (*END OF OBJECT FETCHOBJ*) 
 
 (*PROCESSES AND PROCEDURES DEFINITIONS OF OBJECTTELE 
 START HERE*) 
 
 INTERRUPT PROCESS GETS [PRIORITY-4; VECTOR-#60] ; 
 VAR 
 
 KBS [#177560] :BITS; 
 KBB [#177562]: CHAR; 
 BEGIN 
 
 PROMPT SYNC. ST ARTGET; (*WAIT UNTIL THE PROMPT IS 
 
 PRINTED*) 
 REPEAT 
 
 INOBJ.GETSSYNC(READIN); 
 KBS: = [0,6] ; 
 DO 10; 
 
 KBS:-KBS-[6]; (*DISABLE READER INTERRUPT*) 
 READBUFFER [READIN+1 ] : -KBB ; 
 UNTIL RESET; 
 END; (* END OF PROCESS GETS*) 
 
 INTERRUPT PROCESS ECHO [PRIORITY-4; VECTOR-64] ; 
 
 VAR 
 
 PTS [#177564] :BITS; 
 
 PTB [#177566] :CHAR; 
 
 BEGIN 
 
 REPEAT 
 
 INOBJ . ECHOS YNC (ECHOOUT , EDITIN ) ; 
 
 PTS:-[6] ; 
 
 PTB: -READBUFFER [ECHOOUT+1] ; 
 
 DOIO; 
 
 PTS:-PTS-[6]; (*DISABLE PRINTER INTERRUPT*) 
 UNTIL ORD (READBUFFER [ECHOOUT+1 ] ) -CR ; 
 
Page D-14 
 
 RESET: -TRUE; 
 
 WHILE (READIN>ECHOOUT) DO 
 
 INOB J. ECHOS YNC (ECHOOUT , EDITIN ) ; 
 FETCHOBJ.MOVE; 
 END; (*END OF PROCESS ECHO*) 
 
 INTERRUPT PROCESS PROMPT [PRIORITY-4 ;VECTOR-#64] ; 
 VAR 
 
 PTS [#177564] :BITS; 
 
 PTB [#177566] :CHAR; 
 BEGIN 
 
 PTS: =[6]; (*ENABLE PRINTER INTERRUPT*) 
 
 PTB:='?'; (*PRINT A PROMPT '?'*) 
 
 DOIO; (*ENTER WAIT STATE UNTIL 10 IS DONE*) 
 
 PTS:=PTS-[6]; (*DISABLE PRINTER INTERRUPT*) 
 
 PROMPT S YNC. DONEPROMPT; 
 END; (*END OF PROCESS PROMPT*) 
 
 INTERRUPT PROCESS DOPRINT [PRI0RITY=4; VECTOR»#64] 
 
 (BUF:LINEBUFTYPE); 
 VAR 
 
 I: INTEGER; 
 
 PTS [#177564] :BITS; (*PRINTER STATUS WORD*) 
 PTB [#177566] :CHAR; (*PRINTER BUFFER WORD*) 
 BEGIN 
 I:-0; 
 REPEAT 
 
 I: =1+1; 
 PTS: = [6] ; 
 PTB:=BUF[I]; 
 
 DOIO; (*ENTER WAIT STATE UNTIL 10 IS DONE*) 
 PTS:=PTS-[6]; (*DISABLE PRINTER INTERRUPT*) 
 UNTIL ((I>=LINESIZE) OR (BUF [I] =CR) ); 
 END; (*END OF PROCESS DOPRINT*) 
 
 ENTRY PROCEDURE OPEN (ID : PROS IDTYPE; VAR I:TELEIDTYPE); 
 BEGIN 
 
 TELEUSER:=ID; 
 END; (*END OF ENTRY PROCEDURE OPEN*) 
 
 ENTRY PROCEDURE CLOSE (ID:PROSIDTYPE;I :TELEIDTYPE) ; 
 BEGIN 
 
 TELEUSER:-0; 
 END; (*END OF ENTRY PROCEDURE CLOSE*) 
 
Page D-15 
 
 ENTRY PROCEDURE INTO (ID: PROS IDT YPE;I :TELEIDTYPE; 
 
 VAR BUF:LINEBUFTYPE); 
 BEGIN 
 
 RESET: -FALSE; 
 
 EDITIN:»LINEBUFSIZE-1; (*SET PTR TO THE TAIL 
 
 OF RING BUFFER*) 
 READIN:«READBUFSIZE-1; (*SAME AS ABOVE*) 
 ECHOOUT:-READIN; 
 
 PROMPT; (*PRINT OUT A PROMPT '?' *) 
 GETS; (*START READING ACTION*) 
 ECHO; (*START ECHOING PROCESS*) 
 FETCHOBJ.FETCH(BUF); (*PUT ONE LINE OF 
 CHARACTERS INTO BUF*) 
 END; (*END OF ENTRY PROCEDURE INTO*) 
 
 ENTRY PROCEDURE OUT (ID: PROS IDTYPE; I : TELETYPE; 
 
 BUF:LINEBUFTYPE); 
 BEGIN 
 
 DOPRINT; 
 END; (*END OF ENTRY PROCEDURE OUT*) 
 
 END; (*END OF OBJECT OBJOFTELE*) 
 
 (*MAIN PROGRAM STARTS HERE*) 
 
 VAR 
 
 TELETYPE : OBJOFTELE ; 
 BUF.-LINEBUFTYPE; 
 PROS ID: PROS IDTYPE; 
 
 TELEID:TELEIDTYPE; (*STORE TELETYPE NUMBER, IF MORE 
 
 THAN ONE TELETYPE*) 
 BEGIN (*MAIN PROGRAM STARTS HERE*) 
 PROSID:=l; (*ID OF THIS PROCESS*) 
 TELETYPE.OPEN(PROSID,TELEID); (*OPEN TELETYPE*, 
 
 RESERVE IT*) 
 TELETYPE. INTO (PROSIS ,TELEID, BUF); (*READ IN ONE 
 
 LINE*) 
 TELETYPE.OUT(PROSID,TELEID,BUF); (*PRINT OUT ONE 
 
 LINE*) 
 TELETYPE. CLOSE (PROS ID, TELEID); (*RETURN TELETYPE 
 
 //TELEID BACK*) 
 END. (*END OF MAIN PROGRAM*) 
 
Page E-l 
 APPENDIX E 
 
 EXTENDED P-CODE 
 
 E. 1 Modifications to P-Code 
 
 The Path Pascal compiler is written in Pascal P4 and can be compiled 
 by the Pascal P4 compiler into P-Code. Pascal P4 programs may be compiled by 
 the Path Pascal compiler into a modified P-Code. The modified P-Code differs 
 from the original by the inclusion of comment cards which mark the beginning 
 of procedure bodies of code. The comment cards are used to provide a primi- 
 tive debuggin facility in the Path Pascal interpreter and can be removed to 
 obtain P-Code which will execute on a standard P-code interpreter. Comment 
 cards do not affect the sequencing or numbering of P-code instructions and 
 appear as: 
 
 * procedurename 
 
 with '*' appearing in column 1 and 'procedurename' being a string of ten char- 
 acters . 
 
 E.2 P-Code Extensions 
 
 The following extensions to P-Code are used by the Path Pascal com- 
 piler to produce code for the extensions to Pascal P4: 
 
 PST P, Q Create a stack, heap and process descriptor record (PDR) 
 for a new process. The instruction behaves in a similar 
 manner to MST. P is the difference level between the calling 
 procedure and called process, and Q is the size of the stack 
 required for the new process. Storage is obtained for the 
 stack and heap from the heap of the calling procedure. Note 
 that parameters for processes must be copied into the initial 
 activation record of the new process. 
 
Page E-2 
 
 SPU P, Q Activate a new process. Similar to CUP. P is the 
 number of locations for parameters, Q is the entry point of 
 the process. The PDR for the new process is updated with the 
 entry point as the value of its program counter and the PDR is 
 placed on the ready list of processes. A count of the number 
 of sons of this process is initialized. 
 
 RTP Process completion. Similar to RET. Wait for the completion of 
 any processes created as sons to this process. Sons are 
 processes created from process declarations within the block 
 of this process. Return PDR storage. (Garbage collection 
 could be done if required). 
 
 CUP Call procedure or function. This instruction has been modi- 
 fied to initialize a count of its sons. 
 
 RET Return from a procedure or function. This instruction has 
 been modified so that a procedure or function will wait for 
 the completion of any processes created as sons before return- 
 ing. 
 
 CSP The following special procedures can be invoked using the CSP 
 instruction. 
 
 ISM Initialize the semaphore whose address is on the top of the 
 stack to the value stored in the top minus one of the stack. 
 
 VOP Perform a V operation on the semaphore whose address is on the 
 stack. 
 
 POP Perform a P operation on the semaphore whose address is on the 
 stack. 
 
 TIM Push the system clock time on the stack. 
 
 DEL Delay the current process by the time given on the stack ( * 
 1000 ). 
 
 SIO Store an interrupt vector for this process at the absolute 
 address loaded on top of the stack, and change the priority of 
 this process to the value found on top minus one of the stack. 
 
 DIO Suspend this process while I/O occurs. Load the interrupt 
 vector of this process with the address of the P-Code instruc- 
 tion following DIO. 
 
 The ready queue and semaphore process queues are maintained in order 
 
 of the priority of processes, processes with the same priority are maintained 
 
 in first in, first out order. 
 
Page E-3 
 E.3 Absolute Addresses 
 
 Absolute addresses may be produced by the Path Pascal compiler for the 
 instructions : 
 
 LDO, SRO and LAO. 
 
 These addresses appear in the P-Code as negative values except for the inter- 
 rupt process vector address. The Path Pascal interpreter currently will not 
 accept absolute addresses in their negative format, and the CSP procedures SIO 
 and DIO are ignored. 
 
 E.4 Activation Records for Path Pascal programs 
 
 The activation record for a Path Pascal program includes a block mark 
 which is 6 stack words long. The additional words are used only by the 
 extended instructions. The block mark is used in the following manner by the 
 Path Pascal interpreter: 
 
 location use 
 
 6 Number of sons 
 
 5 Return address 
 
 4 Check on storage space (Old EP) 
 
 3 Dynamic Linkage (Old MP) 
 
 2 Static Linkage 
 
 1 Function value 
 
Page F-l 
 APPENDIX F 
 
 A SUMMARY OF PASCAL P4 
 
 1. The procedures NEW, MARK, and RELEASE are used in Pascal P to manipulate 
 heap storage instead of the procedures NEW and DISPOSE. MARK takes an 
 integer parameter and assigns that integer the current heap address. 
 RELEASE takes an integer parameter which has presumably been previously set 
 by MARK and returns all of the heap storage from the current heap address 
 to the address of the parameter. Thus the storage assigned to a dynamically 
 allocated variable can be released by calling MARK before the allocation 
 and RELEASE afterward. 
 
 2. Only four files may be used, INPUT, OUTPUT, PRR, and PRD. These files are 
 all text files. PRD is an input file only, PRR is an output file only. 
 
 3. Procedures and functions used as actual parameters to a procedure or func- 
 tion invocation are evaluated prior to the invocation. 
 
 4. Procedures and functions cannot be used as formal parameters. 
 
 5. The type ALPHA is not defined. 
 
 6. Literal character strings have a maximum length of 10 characters. 
 
 7. Variant records must include the declaration of a variable for the tag 
 field. 
 
^BLIOCRAPHIC DATA 
 
 :iEET 
 
 1. Report No. 
 
 UIUCDCS-R-79-960 
 
 I Tit le jnd Subtitle 
 
 PATH PASCAL USER MANUAL 
 
 IA«kor(s) 
 
 R. H. Campbell, I. B. Greenberg, T. J. Miller 
 
 3. Recipient's Accession No. 
 
 5. Report Dste 
 
 March 1979 
 
 6. 
 
 8. Performing Organization Rept. 
 No. 
 
 (Performing Orgsnizstion Name snd Address 
 
 Department of Computer Science 
 University of Illinois U-C 
 Urbana, IL 61801 USA 
 
 10. Project/Tssk/Work Unit No. 
 
 11. Contrsct /Grant No. 
 
 NASA NSG1471 
 NSF MCS77-09128 
 
 1. Sponsoring Orgsnizstion Name and Address 
 
 NASA Langley Research Center 
 
 Hampton, Virginia 
 
 National Science Foundation/MCS 
 Washington, DC 20550 
 
 13. Type of Report & Period 
 Covered 
 
 research 
 
 14. 
 
 .pplementsry Notes 
 
 1 Abstracts 
 
 Experimental Path Pascal is designed to investigate the benefits and problems 
 that arise when path expressions are combined with a language to provide a 
 system programming tool. Instead of altering the Pascal language extensively, 
 a minimal number of features was added such that Pascal programs still 
 compile and execute. The language can be used as an instructional tool or 
 for the construction of example system programs. This manual describes the 
 Path Pascal features and the implementation on the Cyber and PDP11. 
 
 1 Key lords snd Document Analysis. 17a. Descriptors 
 
 Path Pascal 
 path expressions 
 
 1>- Identifiers/ Open-Ended Terms 
 
 COSATI Field/Group 
 
 liability Statement 
 
 unlimited 
 
 19. Security Class (This 
 Report) 
 
 .- . UNCLASSIFIED 
 
 20. Security Class (This 
 
 T: 
 
 NCLASSIFIED 
 
 21. No. of Pages 
 67 
 
 22. Price 
 
 " M NTl»- Jg | 10 . 
 
 USCOMM-DC 40S2S-P71 
 
MAY 3 197ft 
 
flitt; 1 IMS