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 Latest Date stamped 
 below. You may be charged a minimum 
 fee of $75.00 for each lost book. 
 
 Th«f», mutilation, and underlining of books are reasons 
 for disciplinary action and may result in dismissal from 
 the University. 
 TO RENEW CALL TELEPHONE CENTER, 333-8400 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 JAN 2 8 1996 
 FEB 1 2 1997 
 AUG 2 4 2006 
 
 When renewing by phone, write new due date below 
 previous due date. L162 
 
r 
 
 
UIUCDCS-R-77-861 
 
 rh ^u 
 
 UILU-ENG 77 1713 
 
 H 
 
 is 
 
 A PASCAL COMPILER 
 
 "by 
 Yao-Ching Stephen Chen 
 
 April 1977 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
 The Library of the 
 
 JUN 2 4 1977 
 
 isity or Illinois 
 
A PASCAL COMPILER 
 
 by 
 
 YAO-CHING STEPHEN CHEN 
 
 B.S., National Taiwan University* 1971 
 
 THESIS 
 
 Submitted in partial fulfillment of the requirements 
 
 for the degree of Faster of Science in Computer Science 
 
 in the Graduate College of the 
 
 University of Illinois at Urbana -Champai gn* 1977 
 
 Urbana/ 1 1 I i noi s 
 
Digitized by the Internet Archive 
 
 in 2013 
 
 http://archive.org/details/pascalcompiler861chen 
 
1 1 1 
 
 ACKNOWLEDGEMENTS 
 
 I wish to express my gratitude to professor Thomas T. Chen for 
 his continued advice and support throughout the development of this 
 project. Thanks also go to A. B. Baskin and Douglas W. Jones for 
 their many helpful suggestions during the implementation phase of 
 this pro j ect . 
 
1 V 
 
 TABLE OF CONTENTS 
 
 Page 
 
 1. INTRODUCTION 1 
 
 1.1. THF SYSTEM ENVIRONMENT 2 
 
 1.?. THF DESI6N OF THIS COMPILER 2 
 
 1.2.1. LANGUAGE USED FOR ENCODING THE COMPILER . . 3 
 
 1.2.2. COMPILER TARGET LANGUAGE 4 
 
 1.2.3. THE CHOICE OF A PARSING ALGORITHM .... 4 
 
 1.2.4. ENCODING THE COMPILER 5 
 
 1.2.4.1. SYNTAX ANALYZER AND SCANNER 5 
 
 1.2.4.2. SEMANTIC ANALYZER AND CODE GENERATION . . 6 
 
 1.2.4.3. RUNTIME ROUTINES 6 
 
 2. MSP PASCAL GRAMMAR 7 
 
 2.1. MIXED STRATEGY PRECEDENCE 7 
 
 2.1.1. MSP AND STACKING-DECISION PREDICATE .... 6 
 
 2.1.2. MSP AND PRODUCTION SELECTION 9 
 
 2.2. THE MSP PASCAL GRAMMAR 10 
 
 2.3. DIFFERENCES IN SYNTAX BETWEEN THE MSP PASCAL 
 GRAMMAR AND THE STANDARD PASCAL GRAMMAR ... 11 
 
 2.3.1. THE EMPTY STATEMENT 11 
 
 2.3.2. FILE VARIABLE AND POINTER VARIABLE .... 13 
 
 ^. THE SCANNER AND THE SYNTAX ANALYZER 15 
 
 3.1. THE SCANNER OF THIS COMPILING SYSTEM .... 15 
 
 3.1.1. THE PROCEDURES READ AND WRITE 16 
 
 3.1.2. THE SCANNER AND READ, WRITE PROCEDURES ... 16 
 
 3.2. SYNTAX ANALYSIS 17 
 
 4. SYMBOL TABLE MANAGEMENT 19 
 
 4.1. STRUCTURE OF AN ENTRY IN THE SYMBOL TABLE 
 
 4.2. REPRESENTING STRUCTURE IN THE SYMBOL TABLE 
 
 19 
 21 
 
RUNTIME STORAGE MANAGEMENT 25 
 
 5.1. STACK-BASED STORAGE MANAGEMENT 25 
 
 5.2. HEAP STORAGE ALLOCATION 26 
 
 5.3. STATIC STORAGE MANAGEMENT - AN EXTENSION . . 27 
 
 5. A. DATA STRUCTURES 27 
 
 5.4.1. STORAGE FOR ELEMENTARY DATA TYPES .... 27 
 
 5. A. 2. ARRAY 28 
 
 5. A. 3. RECORD 28 
 
 5. A. A. FILE 28 
 
 5. A. 5. SET TYPES 29 
 
 5. A. 6. PACKED STRUCTURE TYPE 29 
 
 5. A. 7. ACTUAL - FORMAL PARAMETERS . . 30 
 
 SEMANTIC TRANSLATION 32 
 
 6.1. THE SEMANTIC ANALYZER AND CODE GENERATION . . 32 
 
 6.2. CODE GENERATION ROUTINES . 3A 
 
 6.2.1. REGISTER ALLOCATION ROUTINES ...... 3A 
 
 6.2.2. THE BI NOP ROUTINE 3A 
 
 6.3. AN EXAMPLE FOR CODE GENERATION 35 
 
 6. A. REMARKS ON GOTO STATEMENT 36 
 
 6.5. ERROR RECOVERY 37 
 
 6.5.1. RECOVERING FROM SEMANTIC ERRORS 37 
 
 6.5.2. RECOVERING FROM SYNTACTIC ERRORS 37 
 
 7. EXTENSIONS TO THE MODCOMP PASCAL SYSTEM 
 
 39 
 
 7.1. COMMON VARIABLE 39 
 
 7.1.1. SPECIFICATIONS FOR THE COMMON VARIABLE . AO 
 
 7.1.2. AN ALTERNATIVE APPROACH FOR 
 
 VARIABLE INITIALIZATION AD 
 
 7.2. EXTERNAL PROCEDURES A1 
 
 7.2.1. SYNTAX FOR EXTERNAL PROCEDURES 
 
 IN MAIN PROGRAM A2 
 
 7.2.2. PREPARING ASSEMBLY PROGRAM AS 
 
 EXTERNAL PROCEDURE A2 
 
 7.3. FORWARD PROCEDURES A2 
 
 7. A. FILE TYPES A3 
 
 7.5. READ/WRITE PROCEDURES AND RANDOM ACCESS FILES . A5 
 
 SUMMARY . A6 
 
VI 
 
 LIST OF 
 
 APPENDIX 
 APPFNDIX 
 APPFNDIX 
 APPENDIX 
 
 APPENDIX 
 
 APPFNDIX 
 APPENDIX 
 
 REFERENCES A8 
 
 A - THE PASCAL BNF GRAMMAR 50 
 
 B - STATISTICS FOR SYNTAX TABLES 57 
 
 C - SPECIFICATIONS FOR THE SEMANTIC STACK . . 58 
 D - PASCAL RUNTIME PACKAGE AND 
 
 EXTERNAL PROCEDURES 59 
 
 E - MACROS FOR PREPARING ASSEMBLY SUBROUTINE 
 
 AS EXTERNAL PROCEDURE 63 
 
 F - REGISTER ALLOCATION 65 
 
 G - SUBROUTINE LINKAGE 67 
 
Page 1 
 
 1. INTRODUCTION 
 
 * compiler for the PASCAL [4/5/21] programming language has 
 been implemented on the MODCOMP IV [15] computer system. The 
 compi ler/ which is encoded in FORTRAN/ is one pass and generates 
 reentrant assembly code. Its syntax parsing algorithm is based on 
 Mixed Strateay Precedence (MSP) [10]/ and the MSP PASCAL grammar 
 [Chapter 2] used in this compiler is listed in Appendix A. 
 
 The FORTRAN and BASIC currently supplied by MODCOMP are not 
 well suited for system software development. The principal goal of 
 this project is to implement a powerful language which may be 
 compiled into efficient machine code and used for system software 
 and data base management. It is also desired that the project be 
 completed within a reasonable amount of time. After careful 
 analysis/ PASCAL/ which combines a rich data type structure with 
 strono type checking/ was selected as the language to be 
 i mp lemented . 
 
 PASCAL/ designed by Dr. Niklaus Wirth/ is an ALGOL-like [12/14] 
 programming language with extensive data structure facilities. The 
 original language definition is in "The Programming Language PASCAL" 
 [21]/ and the concise definition of an updated standard PASCAL can 
 be found in the Revised Report in the "PASCAL User Manual and 
 Report" [5]. Since detailed information regarding PASCAL is readily 
 available in the literature/ this paper will only concentrate on the 
 local implementation. 
 
Page 
 
 1.1. THE SYSTEM ENVIRONMENT 
 
 The MODCOMP IV is a medi um-to-l arge/ mu I t iprogr ammable / paged 
 memory/ qeneral purpose computer/ with a maximum central memory 
 capacity of one million 8 bit bytes. A disk operating system/ MAX 
 IV/ is provided to control the MODCOMP IV paged memory system/ the 
 register context hardware and the priority task execution 
 [15/16,173. 
 
 Due to local system constraints/ the size of the compiler is 
 limited to a maximum of 27/648 (Hex 6C00) 16 bit words. This has 
 necessitated the tight packing of many tables/ and the excluding of 
 the implementation of some language features. However/ these 
 limitations may be lifted when more core memory becomes available on 
 the local system . 
 
 1.?. THE DESIGN OF THIS COMPILER 
 
 Basically/ this implementation of a PASCAL compiler is a 
 one-pass processor which generates assembly language as its object 
 code. The execution of a PASCAL program requires the service of the 
 PASCAL compiler/ assembler and link-loader in that order. The 
 assembly code generated by the compiler is system compatible and can 
 be stored/ examined and edited by system utilities. 
 
Page 
 
 / 
 1.2.1. LANGUAGE USED FOR ENCODING THE COMPILER 
 
 It was decided in the early stages of development that a hiqh 
 level lanquaqe should be used to encode the compiler. The use of 
 the assembly lanquage could be justified because of efficiency. 
 However the current trend in programming is toward using higher 
 level languages* and regarding programming as an engineering 
 discipline. Its reasons are obvious: easier programming* less 
 effort required in debugging and modification* and less cost. 
 
 FORTRAN certainly is not an ideal compiler writing language. 
 FORTRAN is not flexible enough in its control structures* especially 
 in its lack of recursion. In dealing with data structures* FORTRAN 
 provides very little support in maintaining such well-defined 
 structures as stacks and binary trees. Given the conventional 
 FORTRAN data structures* strings* stacks and binary trees have to be 
 simulated by the use of vectors and appropriate routines to support 
 operations on them. However* FORTRAN was used for the encoding of 
 the PASCAL compiler because it was the best available language on 
 the local system . 
 
 It would be possible to have a boot-strap PASCAL compiler 
 written in PASCAL on another system which already has a PASCAL 
 compiler* and the boot-strapping compiler could generate the target 
 machine executable code. Indeed* this is an elegant method for 
 writing a compiler. It was not adopted here for two main reasons: 
 First* writing a boot-strapping compiler itself requires a 
 
Page A 
 
 tremendous demand on the resources of the other computer system 
 
 which are not readily available. Secondly* the MSP parsing 
 
 aloorithm C 1 03 is based on many syntax tables [Appendix BD* and 
 
 there exist no adequate features in PASCAL to initialize those 
 
 tables. 
 
 1.2.2. COMPILER TARGET LANGUAGE 
 
 The compiler can generate either assembly or machine code. In 
 order to ease the burden of debugging the compiler* the assembly 
 lanouage was selected as the target language. Moreover* this 
 approach takes advantage of utility routines in the assembler* thus 
 reducing the size of basic compiler. For example* the memory 
 allocation of PASCAL can be handled by pseudo assembly instructions. 
 Of equal significance is the availability of macro assembly language 
 features for code generation. 
 
 1.2.3. THE CHOICE OF A PARSING ALGORITHM 
 
 A formal parsing algorithm is used because of the availability 
 of many we I I -deve loped Translator-Writing-Systems (TWS) which are 
 very powerful tools for compiler writing. The Mixed- 
 Strategy-Precedence (MSP) parsing algorithm was selected because of 
 the existence of an MSP grammar analyzer C 1 03 on the IBM/360. 
 
Paoe 
 
 1.2.4. ENCODING THE COMPILER 
 
 A decision must be made about the number of passes for the 
 compiling process before encoding the compiler. A one-pass approach 
 was selected mainly in the interest of the compilation speed. This 
 section serves as an introduction to the encoding of the compiler/" 
 detailed discussions are given in later chapters. 
 
 1.2.4.1. SYNTAX ANALYZER AND SCANNER 
 
 The first step in encodino the PASCAL compiler was to manually 
 develop a grammar [Appendix A3 in Bac kus-Naur-Fo rm[6NF3 . Based on 
 this grammar/ a grammar analyzer/ which is part of the TWS designed 
 by McKeeman [103/ was used to produce the syntax tables [Appendix B3 
 for the MSP parsing algorithm. The grammar analyzer was also 
 designed to check whether the BNF grammar for PASCAL was MSP of 
 degree (2/l;l/1) parsable. Although the grammar analyzer was run 
 under the IBM OS/360/ all of the other tasks in implementing this 
 compiler were done on the local system. 
 
 The next step was the encoding of the MSP syntax recognizer in 
 FORTRAN. This syntax recognizer utilized the tables [Appendix B3 
 produced by the grammar analyzer; however/ those tables had to be 
 transformed from XPL data format into FORTRAN data statements first 
 (XPL is a dialect of PL/I and is part of the TWS C 1 0D > . The scanner 
 [Chapter 33 was developed next/ and the compiler at this stage could 
 be used for syntax checkinn. 
 
Page 
 
 1.2. A. 2. SEMANTIC ANALYZER AND CODE GENERATION 
 
 Semantic analysis and code generation constituted the major 
 effort of writing this compiler. The semantic analyzer includes 
 symbol table management [Chapter 43/ runtime storage management 
 [Chapter 5] and semantic routines [chapter 63 for various constructs 
 in PASCAL. Since this was to be a one-pass compiler* code 
 generation was mixed with semantic analysis/ and the code generation 
 routines [Chapter <S3 were called by semantic routines. 
 
 1.2.4.3. RUNTIME ROUTINES 
 
 Before a PASCAL prooram is ready for execution/ the code 
 aenerated by the compiler must be linked with the PASCAL runtime 
 package. The runtime routines include such standard procedures as 
 READ/ WRITE/ NEW/ etc. [Appendix D3. Also included are external 
 procedures for individual programs [Appendix 03. All the routines 
 in the runtime package were encoded in assembly language for 
 achieving better efficiency/ although most of them could be encoded 
 in PASCAL. 
 
Page 7 
 
 2. MSP PASCAL GRAMMAR 
 
 A BNF qrammar [Appendix A]/ which is MSP of degree (2#1;1/1) 
 parsable/ was developed for this compiler. It will be called the 
 MSF PASCAL grammar hereafter. The syntax analysis of this 
 implementation was based directly on that grammar* and the syntax 
 analyzer is able to parse all standard PASCAL statements. The 
 general concept of MSP and the problems encountered during 
 generatinq the qrammar are discussed in this chapter. 
 
 2.1. MIXED STRATEGY PRECEDENCE 
 
 The Mi xed-St rat egy-Precedence (MSP) algorithm used in this 
 compiler is a bottom-up recognizer. The idea of precedence 
 relations in a grammar was first introduded by Floyd C2D/ while the 
 (1/2)(2/1) precedence extension was introduced by McKeeman L9D . The 
 latter/ which was further refined/ was used in the XPL compiler 
 writing system C103. In MSP/ as with most of other bottom-up 
 parsing algorithms/ the following three steps are iterated until the 
 whole program is reduced to the goal symbol C33: 
 1 . Find the handle x; 
 
 2. Kind a production rule U ::=x; and 
 
 3. Reduce X to U/ and create one branch of the syntax tree. 
 
Page 
 
 The principal advantage of the MSP algorithm is its ability to 
 support a less-costly sh i ft -reduce parsable class of grammars. In 
 other words/ the MSP algorithm uses simple and small tables to make 
 as many decisions as possible/ but extends the class of acceptable 
 grammars by usinq more decisions when necessary. As is further 
 discussed in the next two sections* the MSP algorithm applies the 
 precedence relations ( st ack i ng-dec i s i on predicates) to locate the 
 richt end of the handle; it then uses context checking to both 
 locate the left end of the handle and select the correct production 
 rule for reduction. Therefore/ a grammar is called MSP of degree 
 (p/q;m/n) C10]/ if/ for that grammar/ the st acki ng-dec i s ion 
 predicate is of degree(p*q) and the production selection function is 
 of degree (m/n) . 
 
 2.1.1. MSP AND STACKING-DECISION PREDICATE 
 
 The stack inq-dec i s ion predicate of degree(1*1)s called symbol 
 pair predicate/ may be efficiently represented by a two-dimensional 
 boolean array. Although a symbol pair grammar can be constructed 
 for many languages/ considerable manipulation of the grammar is 
 usually required to make it acceptable to the algorithm; and/ as a 
 result/ the grammar cannot be presented to the user as a reference 
 to the language C13. By using another symbol in the stack/ 
 predicates of degree(2/1) accept a wider class of grammars. 
 However/ direct representation of predicates of degree(2/1) may 
 require an unmanageably large table (order of n**3/ where n is sum 
 
Page 9 
 
 of the terminals and nonterminals in the grammar). Thus* it seems 
 that degree (2/1) is too big and degree (1*1) is too small. Since 
 most grammars for programming lanouages are nearly symbol pair 
 grammars* the MSP algorithm C10D uses a degree (1*1) function with 
 tour values (stack* don't stack* undefined* invalid pair) and 
 reverts to a (2*1) predicate only for pairs in which the (1*1) 
 predicate is undefined. 
 
 2.1.2. MSP AND PRODUCTION SELECTION 
 
 A mixed-strategy approach [10] is also used for choosing the 
 correct production. After sorting* the MSP algorithm categorizes 
 the productions as follows: 
 
 1. Always correct* if this is the first match; 
 
 2. Resolvable by checking n symbols in the text; 
 
 3. Resolvable by checking m symbols in the stack 
 below the right part; 
 
 A. Solvable by using (m*n) contex in the stack and the text; 
 
 and 
 5 . Error . 
 After finding a match* the production is checked against its 
 category according to the above order. It is accepted immediately 
 if it is in category 1/ and the indicated tests are performed on the 
 others. If a production is rejected* the search for a match is 
 cont i nued . 
 
Page 10 
 
 2.?. THE MSP PASCAL GRAMMAR 
 
 A s*»t of productions was developed for the PASCAL language. 
 The MSP PASCAL grammar [Appendix AD was used by the grammar analyzer 
 to generate the tables required by the MSP algorithm as outlined 
 above. A feu manipulations of the production rules [Appendix A3 
 were required to make the MSP PASCAL grammar acceptable to the 
 MSF(2/1;1/1) grammar analyzer. 
 For exampl e : 
 
 rule 159 
 160 
 
 and 
 
 rule 177 
 178 
 
 <s i an 2> : : = ♦ 
 <sion 2> ::=■ - 
 
 <si gn> : : = ♦ 
 < s i «-> n > : : = - 
 
 If the four rules above were merged into two/ the error message 
 'stacking cannot be made with (2/1) context' and/or 'production 
 cannot be distinguished with (1/1) context' would be generated 
 during the grammar analysis phase. Some of the production rules 
 were also created because of semantic considerations. 
 For ex emple : 
 rule 46 <repeat head> ::= REPEAT 
 was inserted there so that detection of the beginning of a REPEAT 
 statement could be communicated to the semantic routines by the 
 syntax parser. 
 
Page 1 1 
 
 After the compiler has been written* it would be rather 
 difficult to adapt to changes on the MSP PASCAL grammar. Thus* it 
 is advisable to resolve the grammar specifications carefully before 
 advancing to the phase of semantic analysis and code generation. 
 Even after the grammar is accepted by the grammar analyzer* there 
 remains a risk that the grammar might not represent the intended 
 taroet lanquaqe* or that semantic considerations miaht require the 
 creation of additional productions. 
 
 2.3. DIFFERENCES IN SYNTAX BETWEEN THE MSP PASCAL GRAMMAR AND 
 THE STANDARD PASCAL GRAMMAR 
 
 The standard PASCAL syntax was presented as a top-down grammar 
 [53. Several difficulties occurred during the process of generating 
 the MSP PASCAL grammar for this implementation* partly because of 
 restraints imposed by MSP algorithm* and partly because of the fact 
 that the top-down grammar was restructured for a bottom-up parsing 
 analyzer. In addition to the extensions presented in chapter 7* 
 there are two minor differences between the syntax specification of 
 this grammar and that of the PASCAL Report. These are explained in 
 the sub-sections below. 
 
 2.3.1. THF EMPTY STATEMENT 
 
 Since the semicolon [ ; D is considered as a statement separator 
 instead of a terminator* the empty statement presents some problems 
 in making the MSP PASCAL grammar acceptable to the MSP grammar 
 analyzer. The empty statement must be explicitly represented in the 
 
Page 12 
 
 MSP PASCAL grammar wherever it is allowed. A considerable amount of 
 
 manipulation of the grammar is required in order to make the grammar 
 
 acceptable. A compromise is suggested in this implementation to 
 
 allow only restricted usaae of the empty statement. 
 
 Empty statements are most commonly used at the following two 
 loc at ions : 
 
 a) Before keyword END or UNTIL; and 
 
 b) After <label> : 
 
 The first usage is possibly due to the programming habit 
 inherited from other languages (e.g./ PL/I/ ALGOL). The PASCAL 
 lannuaqe does allow it/ but interprets it as an empty statement 
 between •;■ and • E ND • / ' UNT I L • . 
 
 The second usage arises under certain situations/ because there 
 is no RETURN statement in PASCAL. Return is implicitly executed at 
 the physical end of a procedure. This should not be considered as a 
 weak point of PASCAL; it reflects the philosophy that disciplined 
 pronramming needs no RETURN statement. However/ should multiple 
 return points be required/ an equivalent return statement must be 
 supplied by a GOTO statement/ together with a label before the last 
 END of the procedure. For example: 
 
Page 13 
 
 PROCEDURE multi return; 
 
 GOTO 100; 
 
 return 
 
 100: end; 
 
 'empty statement between : & END 
 
 The empty statements are not included in the MSP PASCAL grammar 
 dirrectly. The ability to recognize these restricted empty 
 statements was accomplished by the scanner. This is another area 
 where the scanner/ with the knowledge of local context/ can simplify 
 the job of the syntax analyzer. 
 
 2.3.2. FILE VARIABLE AND POINTER VARIABLE 
 
 From the original PASCAL syntax in the Revised Report [53: 
 <file buffer> ::= <file variable> oi . .(a) 
 
 <file variable> ::= <variable> . .(b) 
 
 and 
 
 <referenced variable> ::= <pointer variable> a . .(c) 
 <pointer variable> ::- <variable> . .(d) 
 
 There is not enough context to distinguish between productions 
 (b) and (d) . Three possible solutions to the above problem are 
 considered here. The first one is to treat the <file variable> as a 
 terminal and to delete rule (b). The second approach is simply to 
 replace the % in rule (a) by a new symbol $ . The third approach is 
 
Page 14 
 
 to treat the <file variable> as a physical reference to the buffer. 
 With the last approach* the <file variable> and the <pointer 
 variable > are syntactically and semantically the same/ and the 
 above four productions can be merged into two rules. The second 
 approach was used temporarily for the current version of the PASCAL 
 compiler; however* the decision may be changed in the next version. 
 
Page 15 
 
 3. THE SCANNER AND THE SYNTAX ANALYZER 
 
 The first process of the compiler is lexical analysis or 
 scanning. The input to the scanner is a stream of characters which 
 constitutes the source prooram; the output of the scanner is a 
 stream of tokens which serves as the input to the syntax analyzer. 
 Tokens include identifiers* reserved key words* constants* and 
 single and double character delimiters. The scanner also discards 
 some textual elements* such as* spaces and comments. A scanner may 
 be programmed as a separate pass. Under this one-pass compiling 
 system* the scanner acts as a subroutine called by the syntax 
 analyzer whenever the syntax analyzer needs a new token. 
 
 3.1. THE SCANNER OF THIS COMPILING SYSTEM 
 
 The scanner for this compiling system was hard-coded. The 
 structure of a scanner is quite simple and may be treated as a 
 finite state machine. In fact* this scanner performs more functions 
 other than those given above. For example* it controls the listings 
 of the source program. The listings include headings for each page* 
 statement numbers* nesting level* and block number for identifying 
 the body of each procedure or function. It also includes conversion 
 routines which convert digit streams to internal representation. 
 Moreover* this scanner has an important role in compiling READ and 
 WRITE procedures* which will be further discussed in the next two 
 sections. 
 
P d <j e 1c. 
 
 3.1.1. THE PROCEDURES READ AND WRITE 
 
 The PASCAL Report C 2 1 D defines the standard procedures READ and 
 WRITE to facilitate access to the standard tiles INPUT and OUTPUT/ 
 respectively. This implementation extends the READ and WRITt 
 procedures to any text file. The combination of READ* WRITE and EOL 
 provi Jes equivalent services to the combination of READ/ WRITE/ 
 READLN and WRITELN in the Revised PASCAL Report [53. Notice that 
 the syntax in the Revised Report specifies that the file name/ if 
 thfre is one/ be the first parameter. It is suggested that the 
 separation of file specification from parameter lists would enhance 
 the readability of a program. For this reason/ it was decided to 
 use the syntax specification of the PASCAL compiler from the MESH 
 research project [193. As implemented by the MTSH project/ the file 
 specification is moved to the outsioe of the parameter lists. For 
 example/ the statement: 
 
 READ FILE_X (intl / int?) 
 would read two inteoers from file FILE_X. In this implementation/ 
 files could be declared as direct access files/ also READ/WRITE have 
 been further extended to access those files randomly. These/ with 
 other extensions/ will be discussed in more detail in Chapter 7. 
 
 3.1.2. THE SCANNER AND READ/ WRITE PROCEDURES 
 
 The syntax specifications for callino READ and WRITE procedures 
 are non-standard/ and can be treated as a totally different qrammar. 
 They are different from standard syntax in that their parameter 
 lists allow for a variable number of parameters. Moreover/ the 
 
P a q e 17 
 
 actual parameters can be certain types other than CHAR; in which 
 case/ the data transfer is accompanied by an implicit data 
 conve rsion . 
 
 It is possible to include special production rules in the MSP 
 PASCAL grammar to handle READ and WRITE proceaures/ rut this would 
 unduly increase the size of the grammar. Even with this approach* 
 the scanner has to recognize READ and WRITE as special keywords. 
 Since the scanner has to know local syntax* it was decided to let 
 the scanner handle READ and WRITE statements* rather than to change 
 MSP PASCAL qrammar drastically. 
 
 READ and WRITE statements were first expanded by the scanner so 
 thc;t they may be treated by the syntax analyzer as an ordinary 
 procedure. For example (supposinq i and j have been declared as 
 integers) : 
 
 WRITE(i*j:2) would be expanded as 
 
 HEGIN WRITE(i*10),* WRITF(j*2) END 
 where 10 appears in the first WRITE statement because the default 
 width is 10 for integer. This approach is /in some sense* similar 
 to macro expansion with default parameters. 
 
 3.2. SYNTAX ANALYSIS 
 
 The basic compiling loop C10D for the syntax analysis can De 
 described with the followinq PASCAL statements: 
 
Paqe 18 
 
 WHI LF compi I ing DO 
 BEGIN 
 
 WHILF stackinn DO 
 BEGIN 
 
 scan; 
 
 end; 
 
 reduce; 
 
 end; 
 
 stack token"; 
 qet next token" 
 
 where: 
 
 compilino is a looical variable which is turned on initially* 
 
 and turned off when eno-ot-file has encountered; 
 stacking is the logical decision function which/ based on thp 
 
 MSP st ack i nq-de c i s i on predicate/ 
 
 a) returns a TRUE value if a token is to be stacked/ 
 
 b) returns a EALSE value if a reducion in syntax 
 tree is so desired; 
 
 scan is a procedure which returns the next token; and 
 reduce is a procedure which/ based on MSP production selection 
 rules/ looks up a production rule and makes the 
 syntax reduction after callinq the semantic analyzer 
 to produce the associated code. 
 
 Since the compiler was encoded in FORTRAN/ the syntax analyzer 
 car he transported to any other computer which supports the FORTRAN 
 I a n c; u a q e . 
 
Page 19 
 
 A. SYMBOL TABLE MANAGEMENT 
 
 The principal function of the symbol table is to associate an 
 identifier with its declaration. The structure of the symbol table 
 usually reflects the desion of a compiler. In this i mp lement at i on / 
 the symbol table contains keywords as well as predefined functions/ 
 procedures and type identifiers- 
 Chained hash addressing techniques [3/7/113 were utilized for 
 symbol table construction. Each entry in the symbol table has a 
 c h .* i n field which may contain zero or a pointer to another entry 
 whose identifier has the same hashed value. In addition to the 
 symbol table/ this compiler maintains a hash table whose elements/ 
 called buckets/ are empty initially. Fach bucket either contains 
 2ero or points to the head of a linked list which includes all the 
 identifiers with the same hashed value. 
 
 If the identifier S to be hashed is more than two characters 
 (one word)/ a single word S* is derived by adding all words of S. 
 The hashed address is then calculated as: 
 
 address of bucket = C S* MOD ( s i ze_of _hash t ab le ) D ♦ 1 . 
 The hash function/ though simple/ does have satisfactory results. 
 
 4.1. STRUCTURE OF AN ENTRY IN THE SYMBOL TABLE 
 
 The data structure of an entry in the symbol table can be 
 formulated in these PASCAL statements: 
 
Page 20 
 
 TYPF" i n d e x / I i n k = integer; 
 
 al fa - RECORD 
 
 ptr: index; "index into string-pool" 
 s_long: integer "ft of chars for the identifier 
 
 end; 
 
 addr_pnir = RECORD 
 
 I eve I : integer; 
 offset: i nteger 
 
 end; 
 
 s_type = RECORD 
 
 type: (undefined/ scalar, 
 file/ array/ 
 record/ po inter/ 
 procedure_id/ 
 keyword/ 
 subrange_t ype / 
 reference/ field_id/ 
 file_name/ packed: tool; 
 
 end; 
 
 set / 
 
 list/ 
 
 f unct i on_i d/ 
 
 t ype_id 
 
 const ant _i d 
 
 label); 
 
 s_ent r y = 
 
 RECORD 
 
 id_name : 
 i d_addr : 
 i d_type : 
 i d_ lenqt h 
 brot he r : 
 son : 
 
 end; 
 
 alfa; 
 
 addr_pa i r ; 
 s_t ype; 
 integer; 
 link; 
 link 
 
 VAR symbol_table: ARRAY C1..tablesize!) of s.entry; 
 
 string-pool: PACKED ARRAY C1 . .poo Is i ze] of char; 
 
Paae 21 
 
 In order to maintain a fixed length entry for the symbol taole/ 
 an identifier is represented by storing its length together with an 
 index into the string pool. The "id. length "# a field identifier of 
 the "s_entry"/ indicates the size of the storage allocated to each 
 structure/ and the "type" of "s_type" specifies the type of an 
 identifier. 
 
 There are also four flags used to associate additional 
 
 attributes with an identifier: 
 
 reference - is set to true for the formal parameter called by 
 reference; 
 
 field_id - is set to true for an identifier which is also 
 part of a record; 
 
 file_name - is set to true for an identifier which is also 
 a file name; 
 
 packed - is set to true for packed structures. 
 
 A. 2. REPRESENTING STRUCTURE IN THE SYMBOL TAbLE 
 
 The data structure can be represented by having addditional 
 fields as links 172. PASCAL has no complex COBOL-like 
 Qualification rules; referencina an item inside a record/ except 
 explicitly specified with a "WITH" statement/ has to start from the 
 roct. As a consequence/ only two links/ the brother and son/ are 
 sufficient to represent various structures. 
 
 Three examples/ shown in Figs. 2/ 3/ and A/ are used to 
 demonstrate how structures were constructed in this implementation. 
 Each node in these examples has three fields - INFO/ BROTHER and 
 
Paqe 22 
 
 S r- . The INFO represents the combined information of the id_name* 
 id_addr* id_type and id_lenqth. A node is shown as in Fiq. 1. 
 
 INFO 
 
 | BROTHER | SON | 
 
 Fia.1. A node showing portions of the information 
 stored in an entry of the symbol table. 
 
 VAR d: ARRAY CO. .2] OF ARRAY C1..53 OF INTEGER; 
 
 !• 3 
 
 array 
 
 °~? NM 
 
 : array 
 
 1-* KN 
 
 : i ntege r \\ 
 
 Fia.2. The structure representation for a 
 two dimensional array. 
 
Page 23 
 
 TYPE a = ARRAY CI ..53 OF INTEGER; 
 b = ARRAY CO. .?] Ot a; 
 
 VAR c : b; 
 
 c : 
 
 S 
 
 b : type \ 
 
 1 
 
 : array 
 
 Th 
 
 ; °-- ? 1\N 
 
 rtype |\ 
 
 array 
 
 hH NNI 
 
 :integer |\|\| 
 
 Fiq.3. The structure representation for a two dimensional 
 array with user-defined data types 'a' and 'b*. 
 This array is equivalent to that of Fiy.2. 
 
Page 24 
 
 VAR a: RECORD OF 
 
 b : I N T 6 F R ; 
 
 c: ARRAY C 1 . .53 OF INTEGbR; 
 
 d: INTEGER 
 
 end; 
 
 airecord \ 
 
 
 
 
 
 i 
 
 1 
 
 
 b: scalar 
 
 
 
 
 
 
 \ 
 
 
 
 
 
 c : 
 
 
 
 f 
 
 
 
 ^ r 
 
 
 
 : a r ray 
 
 
 
 
 
 \ 
 
 
 
 
 
 
 ' 
 
 
 
 
 
 : 1 ..5 
 
 ss 
 
 
 ' 
 
 
 
 
 d : sea I ar \ 
 
 
 
 . 
 
 
 
 
 I \ 
 
 ' \ 
 
 [ 
 
 
 :integer |\\l 
 
 Fig. A. The structure representation for a record 
 
Page 25 
 
 5. RUNTIME STORAGE MANAGEMENT 
 
 There are two types of data areas in PASCAL: one is the runtime 
 stack similar to that used in AL60L-60 C12/14J; the other is for 
 dynamic storage allocation of pointer type variables. One important 
 lannuaoe feature of PASCAL is that all space attributes are known at 
 compile time. This feature simplifies storaqe allocation because 
 templates/ which describe attributes at runtime/ are not required. 
 For the same reason* the compiler can generate directly all the 
 necessary code for variable reference; thus/ the more efficient code 
 may be obt ai ned . 
 
 5.1. STACK-BASED STORAGE MANAGEMENT 
 
 The characteristic of the nested last-in/ first-out structure 
 of procedure or function calls in PASCAL makes stack-based storage 
 manaqement a natural choice. At the start of the execution of a 
 PASCAL program/ a contiguous space is assigned as a stack which is 
 initially empty. When a subprogram is called/ a new activation 
 record is created on top of the stack. Termination of a subprogram 
 then causes its deletion from the stack. One major advantage of 
 this orqanization is that it solves automatically the problems of 
 st crane recovery/ compaction and reuse. 
 
 The size of the runtime stack used in this compiler is 
 defaulted to the sum of the storage required by all variables 
 declared in the program and the I/O working area associated with 
 each file declaration. This amount of space permits the nesting of 
 
Page 2<S 
 
 calls to all subprograms once without overflowing the runtime stack. 
 However/ overflow of the stack could happen for highly recursive 
 subprogram calls. It is a waste of memory space to allocate a very 
 hi.- runtime stack without any prediction from the programmer. Since 
 the programmer is the only one who knows the degree of recursion of 
 his program/ one possible solution is to include a directive to the 
 compiler which specifies the size of the stack. Another better 
 solution is to let the operating system allocate space for the 
 runtime stack. Because of the vi rtua I -pageo memory system supported 
 by the MAX IV operating system/ it is possible to invoke an 
 executive service routine to allocate more space for the runtime 
 stack when a page fault occurs. This approach is more appealing and 
 miuht be implemented in the next version. 
 
 5.2. HEAP STORAGE ALLOCATION 
 
 The term 'heap' refers to a block of storage within which 
 pieces are allocatea ana freed in a relatively random manner [133. 
 In PASCAL/ pointer variables refer to variables allocated on a heap/ 
 and they are generated by calling the standard procedure NEW. If a 
 pointer type P consists of an unbounded set of values pointing to 
 elements of a given type T/ then P is said to be bound to T C5D. 
 Therefore/ the procedure NEW requires an implicit parameter which 
 specifies the size of storage required by the type T associated with 
 the pointer P. It was also decided to implement DISPOSE/ the 
 opposite of the procedure NEW/ as a predefined procedure. The 
 procedure DISPOSE relieves the user of the responsibility for 
 maintaining his own free element list/ and it also achieves more 
 
Page 27 
 
 efficiency in storage utilization. The documentation of NEW and 
 DISPOSE is listed in Appendix D. 
 
 5.3. STATIC STORAGE MANAGEMENT 
 
 AN EXTENSION 
 
 Motivated by the necessity for initializing big tables/ common 
 variables were introduced as a local extension CChapter 7 ] . The 
 allocation and initialization of common variables are handled by 
 either the link-loader or the link-editor of the MAX IV system 
 utilities. 
 
 5. A. DATA STRUCTURES 
 
 This section will discuss the various PASCAL data structures; 
 some of the features have been extended in this compiler* while some 
 of them are to be incorporated in the future. 
 
 5.4.1. STORAGE FOR ELEMENTARY DATA TYPES 
 
 The regular word size of this machine is 16 bits* and a byte 
 has 8 bits. There are four standard types for variables and all of 
 them are treated as predefined identifiers of subrange type: 
 
 a. integer -2**15 to 2**15-1; 
 
 b. char 1 to 127; 
 
 c . boo I 
 
 o . rea I 
 
 true or false; the internal representation is 1 for 
 true and for false; 
 
 not implemented in this version. 
 
Page 28 
 
 b. A. 2. ARRAY 
 
 Multidimensional arrays are mapped into memory in row major 
 order. In the present version/ they must be declared as an array of 
 arrays; for example/ a two-dimensional integer array is declared as 
 
 VAR matrix: ARRAY Ca..b3 OF ARRAY Lc.dl OF integer; 
 or it can be defined as 
 
 TYPE vector = ARRAY Cc.dT OF integer; 
 
 VAR matrix: ARRAYCa..b] OF vector; 
 The (i/j)th elememt of matrix is then referenced as ma t r i x C i 3 C j D . 
 However/ this restriction will be removed in the near future/ so 
 th^t the convenient abbreviations can also be used for 
 mu I t i cii mens i ona I arrays: 
 
 VAR matrixCa..b/c..dD of integer; 
 and the (i#j)th element can be referenced as matrixCi/j3. 
 
 5 .A .3. RECORD 
 
 The variant part of a record is not implemented on this version 
 of the compiler. One simplified way to implement variant records is 
 to reserve the maximum storage requested among all variants. With 
 this approach/ the property/ that the S( ace attributes of all 
 variables are known at compile time/ is preserved. 
 
 5. A. A. FILE 
 
 The compilation of a file declaration includes the allocation 
 on the runtime stack an I/O buffer/ and a block of storage which 
 contains the user-file-table C173 and control variables for the 
 
Page 29 
 
 buffer. The size of the 1/0 buffer is set to 256 bytes because that 
 is the most commonly used size of a sector on a disk or a magnetic 
 tape on the M0DC0MP system. At present* the standard files INPUT 
 and OUTPUT are implemented as implicitly declared in the main 
 proqram. However/ they can also be implemented as formal parameters 
 of main programs such that buffers will only be allocated when 
 necessary. The structure of a file has been extended and is further 
 discussed in Chapter 7. 
 
 5. A. 5. SFT TYPES 
 
 A set type defines the set of values that is the powerset of 
 its base type* and the base type must be a scalar type. Set type is 
 not implemented in this version. However* it is possible to 
 implement a set as a bit string. Since the word size is 16 bits* it 
 is natural to reserve a multiple of 16 bits for each set. Thus* it 
 is suqgested that at least 8 words(12fc bits) te allocated for each 
 set if sets are implemented. In doing so* a set may include the 
 whole character set and thus becomes very useful. 
 
 5.4.6. PACKED STRUCTURE TYPE 
 
 In PASCAL* a type definition prefixed with the symbol PACKED 
 requires the compiler to economize storage requirements* even at the 
 expense of additional execution time and a possible expansion of 
 code. The implementation of general packed structures is rather 
 complex* and will increase the size of the basic compiler. Since 
 many of the application programs on the local system include 
 
Paae 30 
 
 character string manipulation/ it was decided that the packed array 
 of characters be implemented on this version. 
 
 The packed array of characters was implemented without too much 
 overhead. This is because the instruction set of the host machine 
 allows direct addressing and manipulation of bytes. Since two 
 characters can be packed into a 16 bit word/ a 50% saving in storage 
 can be achieved with only small loss in efficiency. Strings with 
 n>1 characters were implemented as 
 
 PACKED ARRAY C1..n] OF char; 
 Therefore/ a string constant can also be used in the context where a 
 packed array is allowed. For example/ if a string is declared as a 
 const ant i n 
 
 CONST b = 'a strino'; 
 then the first character of the strinq can be referred to as bC1D. 
 
 5. A. 7. ACTUAL - FORMAL PARAMETERS 
 
 As stated before/ there are two ways to pass parameters: 
 either by reference/ or by value. If a formal parameter is called 
 by reference/ only one word is reserved. The reserved word holds 
 the runtime address of the actual parameter passed by the calling 
 sequence. If a formal parameter is called by value/ a block of 
 storage is allocated as specified by its declaration. Some 
 optimization was performed to minimize code for passing parameters. 
 If the actual parameter is of a simple data type/ the value of the 
 actual parameter will be passed directly to the subprogram. 
 Otherwise/ if the actual parameter is of a structured data type/ 
 
Page 31 
 
 only the address of the structure will be passed/ and the receiving 
 sequence of subprogram will copy the structure into the local data 
 area. 
 
Page 32 
 
 6. SEMANTIC TRANSLATION 
 
 The semantic analysis was accomplished under the control of the 
 subroutine SYNTHESIZF. When a reduction U::=X is recognized 
 according to the MSP PASCAL grammar/ the syntax analyzer calls 
 SYNTHFSIZF* with the production number as the argument. In other 
 words/ before the handle X of the sentential form is reduced to the 
 nonterminal u* some semantic actions may take place. Depending on 
 the production number* semantic actions may involve entering or 
 checkino information in the symbol table* generating assembly code 
 and associating semantic information with the newly created 
 nonterminal U . 
 
 6.1. THE SEMANTIC ANALYZER AND CODE GENERATION 
 
 because this is a one-pass compiler* the semantic analyzer and 
 code generation routines are closely related to each other. The 
 communication between code generation routines and the semantic 
 analyzer is by the use of the semantic stack and the loop stack. 
 The semantic stack holds the semantic attributes associated with a 
 particular nonterminal. Fach entry in the semantic stack consists 
 of two words* where the first word specifies the status of a 
 nonterminal* and the second word is used as a modifier of that 
 status. The structure for an entry on the semantic stack is listed 
 in Appendix C. The loop stack is used to store the address 
 associated with the WHILE* REPEAT* FOR* and IF statements. The 
 function for the loop stack is to maintain the scope of those 
 statements and to provide labels for branch instructions during code 
 
Page 33 
 
 qeneration. Although the semantic stack and loop stack can be 
 combined into a single stack/ they were maintained separately for 
 easier debugginq. 
 
 The sequence to compile an expression C+0 will be given as an 
 example to summarize the compiling process: C is first recognized 
 as an identifier token by the scanner; the syntax reduction* 
 corresponding to production rule 134 [Appendix A* <variable 
 identifier> ::= <identifier> 3* is recognized by the syntax analyzer 
 which* in turn* calls SYNTHESIZE with 134 as the argument. The 
 SYNTHESIZE* with the knowledge that production 134 is used for 
 reduction* first calls another semantic routine LOOKUP to check 
 whether C has been correctly oeclared before pushing the semantic 
 attributes of C into the semantic stack. Through the same process* 
 the semantic attributes of D are then pushed into the semantic 
 stack. After other reductions which invoke no additional semantic 
 actions are applied* the reduction corresponding to production rule 
 155 [Appendix A* <simple expression) ::= <simple expression) ♦ 
 <term> ] is recoqnized* and the rule number 155 is passed to the 
 SYNTHESIZE. A subroutine BINOP* which is next invoked by the 
 SYNTHESIZE* checks the type of C and D* generates code to perform an 
 add operation* and updates the semantic stack. 
 
Page 34 
 
 <S.2. CODE GENERATION ROUTINES 
 
 A set of routines was designed for code generation and simple 
 code optimization. Some of these code generation routines and their 
 basic program logic will be discussed below. 
 
 6.2.1. REGISTER ALLOCATION ROUTINES 
 
 The register assignments are listed in Appendix F/ and several 
 routines are involved in generating code to make efficient use of 
 the accumulators. The semantic status of an operand is always 
 specified by a pointer which points to one entry on the semantic 
 stack. The subroutine INACC is used to check whether the operand is 
 already in an accumulator. Another subroutine/ PIKACC/ is used to 
 search for either a single register or a register pair/ depending on 
 th^ operation to be performed. If none of the accumulators is free/ 
 arbitrary accumulators are pickea by the PIKACC for replacement. 
 The routine FACC is used to force the operand or the runtime 
 absolute address of the operand into an accumulator. If the operand 
 is not in an accumulator/ FACC then loads the operand into free 
 accumulators after calling PIKACC. 
 
 6.?. 2. THE BINOP ROUTINE 
 
 With the operator passed as the araument/ the code generation 
 for a binary operator was managed by a generalized routine BINOP. 
 The routine BINOP always examines the top two entries on the 
 
Page 35 
 
 semantic stack to obtain the semantic information of the two 
 operands. The routine usually forces the left operand into an 
 accumulator. However/ in order to optimize the code/ the routine 
 first checks whether any operand is already in an accumulator for 
 commutative operators. The same check is also applied to a 
 relational operator/ and the opposite operation is performed if the 
 left operand is in the memory while the right operand is already in 
 an accumulator. In case both operands are constant/ the indicated 
 operation will be executed at compile time. Since the code for 
 array reference was accomplished partly by the BINOP routine/ the 
 reUtive address of the element is calculated at compile time if the 
 index is a constant. 
 
 6.3. AN EXAMPLE FOR CODE GENERATION 
 
 Many code generation actions are straightforward/ most of them 
 consist of a few statements embedded in the SYNTHESIS routine. The 
 code can often be generated by explicitly creating entries on the 
 semantic stack/ and followed by calling code generation routines. 
 The sequences to generate the code for iteration control of a FOR 
 statement will now be described as an example. The code to be 
 generated includes implicit incrementing (or decrementino) and 
 testino of the control variable. The steps for code generation are 
 as follows: 
 
 Push address of control variable into semantic stack; 
 
Page 36 
 
 Duplicate the address of control variable; 
 lush constant 1 into semantic stack; 
 Call BINOP(add) (or call PINOP(sub)); 
 rail assign; 
 
 lush the address of the temporary location/ which holds the 
 final value of the control variable/ into semantic stack; 
 
 Call filNOP (equal ) ; 
 
 enerate conditional branch instruction. 
 
 The first call to the subroutine B I H P Generates the code to perform 
 the add or sub operation (control variable +/- 1)/ and the routine 
 ASSIGN generates code to assign the computed result back into the 
 control variable. The second call to the subroutine B1N0P generates 
 code to compare the control variable and the final value; the 
 logical value calculates in turn/ affects the execution of the 
 branch instruction. 
 
 6. A. REMARKS ON GOTO STATEMENT 
 
 In this implementation/ the destination of a GOTO statement 
 must be inside the same subprogram. This is not a severe 
 restriction because the GOTO statement shoula be used only under 
 unusual and uncommon situations according to structured programming 
 [8], The restriction can be removed by associating each label with 
 a compile time subroutine level. If a procedure exit is reguired 
 for a GOTO statement/ the exit sequence [Appendix G ] could then be 
 generated/ instead of producing a simple branch instruction. 
 
Page 37 
 
 6.5. ERROR RbCOVERY 
 
 An attempt should be made to find as many errors as possible in 
 a source program during a single compilation. However/ unlike the 
 compiler for PL/C/ this compiler does not try to "correct" all 
 errors. The error recovery routine is responsible for generatinn 
 error messaqe/ and determining how to continue analyzing a source 
 program when an error is found. Ely the time an error is detected* 
 some erroneous code might have already been generated. Therefore* 
 the GO/NO GO bit C 1 "73 will be reset if any errors are detected* which 
 will then cause the job-control processor to abort the assembler 
 that follows the PASCAL compiler. 
 
 6.5.1. RECOVERING FROM SEMANTIC ERRORS 
 
 This is simply done by generatino an error message and 
 inserting a new symbol taole entry for undeclared identifiers. 
 
 6.5.2. RECOVERING EROM SYNTACTIC ERRORS 
 
 The approach used in this compiler is similar to the techniques 
 used in the XPL compiler and many other automatic bottom-up parsers. 
 When a syntactic error is detected* the compiler is said to be in 
 "panic mode" and the following two steps are performed: 
 
 1. The symbols in the input stream are scanned and discarded 
 
Paqp 3b 
 
 until a token T is found* which is one of the preselected 
 tokens. The set of preselected tokens incluaes ' /' ' / ' V A R • / 
 'END'/ 'TYPE'/ 'BEGIN'/ 'FUNCTION' and 'PROCEDURE'. 
 Txamine and discard symbols popped from the syntactic stack 
 until a symbol x is found such that the token T found in 
 step 1 can leqally follow x. 
 
 However/ before the compiler q o e s to the panic mode/ some tests 
 are conduted by insertinq a token to see if the error can be 
 removed. For example/ it is found that many errors are caused by 
 omittino ';' at the enc of a statement/ therefore/ the symbol ' I ' is 
 inserted for the test. Many ad hoc tests can ce done in the same 
 manner/ yet there is not sufficient data collected to indicate how 
 *p I I they work. 
 
Page 39 
 
 7. EXTENSIONS TO THE MODCOMP PASCAL SYSTEM 
 
 This chapter discusses those PASCAL extensions implemented on 
 this compiling system. All these added features are implemented 
 brsed on the principle that the extension must not creat a situation 
 such that a standaro feature becomes unusable. 
 
 7.1 . COMMON VARIABLE 
 
 The PASCAL lanouaqe has no PL/I-like INITIAL statement/ which 
 Co uses inconvenience to many application programs. The assignment 
 and READ/GET statements in standard PASCAL may be used for variable 
 initialization; however/ both of them are very inefficient. As an 
 example^ it would be clearly very difficult to initialize tables for 
 this table-driven compiler if it were to be encoded in PASCAL. As a 
 result/ the common statement was included as an experimental 
 extension. The main advantage in supporting this extension is that 
 common variables/ when used in conjunction with EXTERNAL statements 
 [Section 8.2]/ supply a convenient way to initialize variables and 
 tables. That is/ the common variables can be initialized by 
 assembly pseudo instructions of the external procedure which is 
 written in assembly lanouage. Another equally important factor is 
 that this feature provides communication between PASCAL programs and 
 proqrtims written in the assembly and FORTRAN languages of the 
 MODCOMP IV. 
 
Page 4 
 
 7.1.1. SPECIFICATIONS FOR ThE COMMON VARIABLE 
 
 Common variables can be declarer) only in the main program/ and 
 
 may contain only simple variables and arrays of standard types 
 
 (intecer/char/bool). The common variable declarations* if any* must 
 
 precede the <variable declaration part> and follow the <type 
 
 definition part>. The syntax changes in regard to the standard 
 
 PASCAL grammar T53 include 
 
 <block> ::= <larel declaration part> 
 
 <constant definition p a r t > 
 
 <type definition part> 
 
 <common variable declaration part> 
 
 <variable declaration p a r t > 
 
 <procedure and function declaration part> 
 
 <st f tement part> 
 
 <common variable declaration part> : : = <empty> ! 
 COMMON <variable declaration> 
 { ; <variable declaration> > 
 
 7.1.2. AN ALTERNATIVE APPROACH FOR VARIABLE INITIALIZATION 
 
 There is another possible solution for variable initialization. 
 In PASCAL/ a constant identifier may either be defined as a number/ 
 a strina/ or another constant identifier. Constant identifiers can 
 be used for variable initialization if the constant definition part 
 has been extended to allow structures [63. As an informal example/ 
 consider the following sample source program: 
 CONST x = 1; 
 y = 3; 
 z = ARRAYCx..y] of INT INITC1/2/3); 
 
Page 41 
 
 The rest of program will treat zC1D as constant 1/ zL21 as constant 
 2 / etc. 
 
 This approach maintains the principle that a PASCAL user should 
 relv only on features of the PASCAL language. However/ detailed 
 i nvest i uat ion of the modifications to the standard PASCAL grammar to 
 facilitate this extension should be performed before its 
 implementation. 
 
 7.?. EXTERNAL PROCEDURES 
 
 The short-term goal of introducing external procedures is to 
 provide the PASCAL program the ability to call programs written in 
 assembly lanou3oe. Thes*» programs/ in turn/ supply access to all 
 system utilities. The long-term goal of having external procedures 
 as an extension is to provide the facility to have several PASCAL 
 proar^ms comoiled separately and linked before program execution. 
 This feature is very helpful to large PASCAL programs because it is 
 not necessary to comcile all subprograms everytime if most of them 
 are already proved to be workinq. 
 
 The feature of a separate compile and link of PASCAL 
 subprograms has not been implemented y e t # however/ it will be 
 implemented in the very near future. The global variable 
 declarations within separate compiled subprograms will also be 
 implemtnetri. Type checking is possible when exactly the same 
 declarations for parameter lists anO global variables are the 
 m contained between the main program and the separate compiled 
 suhproorams. If strict type checking for all modules in a program 
 
Page 4? 
 
 is a necessity/ a special link editor has to be wtitten for PASCAL 
 to enforce it. 
 
 7.P.1. SYNTAX FOR EXTERNAL PROCEDURES IN MAIN PROGRAM 
 
 The syntax for external procedure declaration is the same as 
 thjt for an ordinary procedure/ except that the keyword EXTERNAL 
 must precede the keyword PROCEDURE/ and there may not be any <body 
 blnck> tor the external procedure. The supply of a <formal 
 declaration section> is mandatory/ since the compilation of an 
 external procedure calls requires the type specifications of all 
 parameters. 
 
 1.2.7. PREPARING ASSEMBLY PROGRAM AS EXTERNAL PROCEDURE 
 
 The receivinq sequence/ return sequence/ parameter passing 
 mechanism and local variable allocation for the assembly program 
 must be compatible with the code generated by the PASCAL compiler. 
 Since these conventions are both machine and implementation 
 dependent/ a set of assembly macros were provided to help users. 
 The definitions and specifications for those macros are given in 
 Append i x E - 
 
 7.3. FORWARD PROCEDURES 
 
 In this one-pass compiler/ a procedure can be called only after 
 its declaration. This restriction forbids two procedures from both 
 callino each other/ and the remedy for this shortcoming is to allow 
 forward declaration. The syntax for a forwarO procedure declaration 
 
Page 43 
 
 is the same as that for an external procedure/ except that the 
 keyword EXTERNAL is replaced by the keyword FORWARD. To demonstrate 
 the important usage for forward procedure declaration/ the top-down 
 parsing alqorithm for expressions in the PILOT compiler (a test 
 proqram/ see Chapter is) is given. The expression is parsed by using 
 the recursive descent method/ based on the following grammar 
 
 Z : : = EXP 
 
 EXP ::= SEXP {(>!<!=!>=!<=) SEXP > 
 
 SEXP ::= C-3 TERM {(+!=) TERM > 
 
 TERM : := FACT < (* ! /) FACT) 
 
 FACT ::= VARIABLE ! CONSTANT ! (EXP) 
 One recursive procedure is required for each grammatical rule. For 
 example/ the procedure TERM for the nonterminal TtRM is: 
 
 PROCEDURE TERM; 
 BEGIN 
 
 FACT; "call FACT" 
 
 WHILE (CURCHAR= •*' ) ! (CURCHAR=' /) DO 
 BEGIN 
 
 scan; "get next token" 
 fact; 
 
 END 
 FMD; "END OF PROC TERM" 
 
 Because the procedures EXP/ SEXP/ TERM and FACT all call each other 
 directly or indirectly/ at least one forward procedure declaration 
 i s requi red . 
 
 7.4. FILE TYPES 
 
 The MAX IV operating system [173 provides four modes for I/O 
 transmission - Standard Binary/ Nonstandard Binary/ Standard ASCII 
 and Nonstandard ASCII. Moreover/ in order to save secondary storage 
 
Paqe 44 
 
 sr are and transfer time on many source records/ there is a special 
 convention for recording ASCII data for external media storage on 
 the MODCOMP system (data encoded according to this convention are 
 called compressed ASCII). 
 
 In the standard PASCAL syntax/ a file type is defined as 
 
 <file type> ::= FILE OF <type>. 
 
 However/ it is desirable that the user have the ability to specify 
 
 thr mode of data format; therefore/ more information about tiles may 
 
 be provided in a PASCAL program. The syntax tor the file 
 
 declaration was thus expanded to 
 
 <file type> ::= <random> <packed> <nonst andard> 
 
 <binary> FILE OF <type> 
 
 <random> ::= <empty> | RANDOM 
 
 <packed> ::= <empty> | PACKED 
 
 <nonstandard> ::= <empty> | NONSTANDARD 
 
 <Mnary> n- <empty> | BINARY 
 The four keywords/ RANDOM/ PACKED/ NONSTANDARD and BINARY/ represent 
 additional specifications of a file. The default specifications for 
 a file are sequential/ non-packed/ standard and ASCII/ respectively. 
 Briefly/ RANDOM indicates the ability to reference records randomly 
 on random access devices. PACKED indicates the files are encoded in 
 compressed ASCII/ while NONSTANDARD and bINARY refer to the mode of 
 I/O operation. 
 
Page 45 
 
 7.S. READ/WRITE PROCEDURES AND RANDOM ACCESS FILES 
 
 In standard PASCAL* only the sequential file is supported; yet/ 
 random access to the records of a file is desirable. Therefore/ the 
 file declaration and READ/WRITF procedures were extended to 
 accommodate random access files. As stated in section 4.1./ the 
 syntax of READ and WRITE for accessing sequential files is 
 
 FEAD/WRITF file-name (parameter lists) ; 
 In order to maintain consistency/ the syntax for accessing random 
 files is modified to 
 
 READ/WRITE file-name Cpos i t i on-i ndex 3 (buffer) . 
 In the above statement/ the file-name has to be declared previously 
 as a random file. The position -index/ which indicates the position 
 of the record on the external device/ has to be an expression with 
 an integer value. If the value of the position-index is negative/ 
 the next record will be read in or written to just as that of a 
 sequential file. The buffer/ which is passed to READ or WRITE as an 
 argument/ is the name of a structured variable defined by a user's 
 program. This structured variable is used as the physical I/O 
 buffer/ and its size is fixed to 256 bytes for the initial 
 experiment. Fecause it is often desirable to maintain more than one 
 buffer in core memory for a ranaom access file/ the buffer is 
 designed to be supplied explicitly by the user so that as many 
 buffers can be maintained as desired. 
 
Page 46 
 
 P. SUMMARY 
 
 A PASCAL compiler was implemented based on the scheme outlined 
 in the previous Chapters. Because of the constraints imposed by 
 both the size of the core memory and the amount of time available/ 
 some features of the standard PASCAL* notably type real* have yet to 
 be implemented. However* various extensions [Chapter 73 were added 
 due to demands of the local environment. A predefined procedure REX 
 [Appendix D3 was also supplied to communicate with the executive 
 services provided by the MAX IV operating system. A compiler 
 supporting the core instructions of the PILOT language [183 was 
 prepared by the author as a test program for this PASCAL compiler. 
 Extensions* such as forward procedure and random I/O* were tested by 
 executing the PILOT compiler. In addition to the PILOT compiler* an 
 attempt has been made to execute a program designed to check PASCAL 
 syntax* which was originally written using the PASCAL implementation 
 of the MESH [193 project. During the compilation of that program* 
 the empty statement problem [section 3.4.13 appeared only once. The 
 PASCAL syntax checking program was compiled and executed 
 successfully by accepting itself as the input. 
 
 The Trans lator-Wr it i no-System (TWS) [103 is a sophisticated and 
 powerful technique for constructing a compiler. The use of this TWS 
 system has shortened the time considerably tor generating this 
 PASCAL compiler. However* one difficulty was encountered in 
 adopting the MSP formal parsing algorithm: changes in syntax 
 specifications were not trivial when an extension was added to the 
 
Page 47 
 
 lanquage. Also the MSP PASCAL grammar [Appendix A] was not 
 efficient in describing the syntax for READ ana WRITE statements. 
 Parsinct of the READ/WRITE and other extensions was achieved by 
 treating these as exceptions to the MSP PASCAL grammar. However/ 
 there is no systematic and clean way to accommodate the chanqes 
 without affecting the modularity and readability of the compiler. 
 
 The PASCAL language is becoming more and more popular; several 
 institutions have implemented PASCAL compilers for other computers* 
 including CDC 6000 series/ PDP-11/ DEC System 10/ IBM 360/370/ and 
 UNIVAC 110P. This PASCAL compiler is perhaps the first 
 implementation to use a bottom-up parsing algorithm/ and it would be 
 desirable that a comparison between this compiler and other 
 implementations be conducted in the future. 
 
P a q e A 8 
 
 C13 
 
 LIST OF RE FERENCES 
 
 Feldman/ J. and Gries/ D./ "Translator Writing Systems/" 
 CACM, 2, 1968. 
 
 [23 Ftoyd^ R. W./ "Syntatic analysis and operator precedence/" 
 JACM 10/ pp3l6-333/ July 1963. 
 
 [3J uries/ D./ "Compiler Construction for Digital Computers/" 
 John Wiley R Sons/ Inc./ 1971. 
 
 [43 Hoare/ C. A.R. and Wirth/ N./ "An Axiomatic Definition of the 
 Porqrammino Lange Pascal/" Acta Infcrmatica/ 2/ 1973. 
 
 [53 Jensen/ K. and Wirth/ N.# "PASCAL User Manual and Report/" 
 Sprincier-Verlag New York Inc./ 1^75. 
 
 [63 Jones/ D. W./ personal communication. 
 
 [73 Knuth/ D. E./ "The Art of Computer P roo rammi ny /" Vol 1. 
 
 * ddi son-wes I ey Publishing Company/ Inc. Reading/ Mass./ 1968 
 
 [8 J Knuth/ D. E./ "Structured Programming with GO TO statements/" 
 Computing Surveys/ Vol. 6/ no. 4/ pp 261-301/ December 1974. 
 
 [93 f*ckeeman/ W. M./ "An Approach to Language Design/" CS 48/ 
 Computer Science Dept./ Stanford Univ./ 1966. 
 
 [ 1 T J NcKeeman/ W. M . / Horning/ J. J. and Wortman/ D. B . / 
 "A Compiler oenerator/" Prentice-Hall. Inc./ 1970. 
 
 [113 Morris/ R./ "Scatter Storage Techniques/" CACM 11/ pp38-4 4/ 
 Jan/ 196^. 
 
 [1?3 Naur/ P. (editor)/ "Revised Report on the Algorithmic Language 
 ALGOL 60/" CACM Vol 6/ no.1/ pp1-20/ January 1963. 
 
 [133 Pratt/ T. W./ "Programming Languages: Design and 
 Implementation/" Prentice-Hall/ 1975. 
 
 [143 Randell/ B./ and Russell/ D. J./ "ALGOL 60 Implementation/" 
 Academic Press/ London/ 1°64. 
 
 [15. 1 Reference Manual/ MODCOMP IV Central Processor/ May 1975. 
 
 [163 Reference Manual/ MAX IV System Processors/ vol. 3/ June 1975 
 
Page 49 
 
 [173 Reference Manual/ MAX IV General Operating System/ Vol. 1/ 
 May 1976. 
 
 [1?] Starkweather/ J. A./ PILOT: a system for Programmed Inquiry/ 
 
 Learning or Teaching/ "The Analysis of Communication Content/ 
 John Wiley g Sons/ 1969/ pp 501-504. 
 
 [1^] Stocks/ I./ MESH Reserch Project/ Annual Progress Report/ 
 
 Department of Computer Science/ University of Illinois/ 1975. 
 
 [20] Wegner/ P./ "Programming Languages/ Information Structures/ 
 and Machine Organization/" McGraw-Hill./ New York /1968. 
 
 [21] Wirth/ N./ "The Programming Language PASCAL/" Acta Informatica/ 
 vol. 1/ pp 35-63/ 1971. 
 
Page 50 
 
 APPENDIX A - THE PASCAL BNF GRAMMAR 
 
 F resented in this appendix is the PASCAL BNF grammar/ which is 
 MSP of deqree (2/1*1*1) parsable. The statistics about the syntax 
 tables/ nenerated by grammar analyzer with this BNF grammar as its 
 input/ are given in Appendix B . 
 
 1 <PP0GRAM> ::= <PR06RAM HEADING> <B0DYP> 
 
 2 <PR0GRAM> ::= <B0DYP> 
 
 ? <BO0YP> ::= <B0DY> . 
 
 4 <PR0GRAM HEADING> ::= <PR0GRAM NAME> /' 
 
 b <PR0GRAM HEADING> ::= <PR0GRAM NAME> <PR0GRAM PARAMETERS> ; 
 
 6 <PR0GRAM NAME> ::= PROGRAM <IDENTIFIER> 
 
 7 <PR0GRAM PARAMETERS> ::= <F0RMAL HEAD> <F0RMAL PARAMETER> ) 
 
 i <F0RMAL HEAD> ::= ( 
 
 •' <F0RMAL HfAD> ::= <F0RMAL HEAD> <F0RMAL PARAMETER> ; 
 
 10 <F0RMAL PARAMETER> 
 
 11 <F0RMAL PARAMETER> 
 1? <F0RMAL PARAMETER> 
 13 <F0RMAL PARAMETER> 
 
 = <TYPE DECLARATIONS 
 
 = VAR <TYPE DECLARATI0N> 
 
 = <FUNCTI0N LIST> <TYPE> 
 
 - <PR0CEDURE LIST> <1DENTIFIER> 
 
 U <FUNCTI0N LIST> ::= <FUNCTI0N LIST HEAD> <IDENTIFIER> : 
 
 15 <FUNCTI0N LIST HEAD> ::= FUNCTION 
 
 16 <FUNCTI0N LIST HEAD> ::= <FUNCTI0N LIST HEAD> <IDENTIFIER> / 
 
 17 <PR0CEDURE LIST> ::= PROCEDURE 
 
 18 <PR0CEDURE LIST> ::= <PR0CEDURE LIST> <IDENTIFIER> / 
 
 U <STATEMENT LIST> :: = <STATEMENT> 
 
 20 <STATEMENT LIST> ::= <STATEMENT LIST;> <STATEMENT> 
 
 21 <STATEMENT LIST/'> ::= <STATEMENT LIST> ; 
 
 22 <STATEMENT> ::= <BASIC STATEMENT> 
 21 <STATEMENT> :: = <IF STATEMENT> 
 
 24 <BASTC STATEMENT> ::= <ASSIGNMENT STATEMENT> 
 
Page 51 
 
 25 <RASIC STATEMENTS 
 
 26 <BAS1C STATEMENT> 
 
 27 <BASIC STATEMENT> 
 ?.> <BASIC STATEMENT> 
 
 3d 
 31 
 32 
 
 3 3 
 
 34 
 
 J, 5 
 36 
 37 
 
 38 
 
 4 
 41 
 4^ 
 
 45 
 
 44 
 
 45 
 
 46 
 47 
 4F 
 
 4Y 
 50 
 
 = STRUCTURED STATEMfcNT> 
 
 = <PROCEDURE STATEMENT> 
 
 = <G0T0 STATEMENT> 
 
 = <LABEL DEFINITION <BASIC STATEMENT> 
 
 2<; <LABFL DFFINITION> :: = <UNSI6NED NUMBER> 
 
 <IP STATEMENT> 
 <IF STATEMENT> 
 <IF STATFMENT> 
 
 = <IF CLAUSE> <STATEMENT> 
 
 = <IF CLAUSE> <TRUE PART> <STATEMENT> 
 
 = <LABEL DEFINITION> <IF STATEMENT> 
 
 <IF CLAUSE> 
 <TRUE PART> 
 
 := IF <EXPRESSION> THEN 
 := <BASIC STATEMENT> ELSE 
 
 STRUCTURED STATEMENT> 
 
 <STRUCTURED STATEMENT> 
 
 <STRUCTURED STATEMENT> 
 
 <STRUCTURED STATEMENT> 
 
 = <COMPOUND STATEMENT> 
 = <CASE STATEMENT> 
 = <REPETITIVE STATEMENT> 
 = <WITH STATEMENT> 
 
 3 ( < <COMPOUND STATEMENT> :: = BEGIN STATEMENT LIST> END 
 
 REPETITIVE STATEMENT> 
 REPETITIVE STATEMENT> 
 <REPETITIVE STATEMENT> 
 
 = <WHILE STATEMENT> 
 = <REPEAT STATEMENT> 
 - <F0R STATE KENT> 
 
 <WHILE STATEMENT> ::= <WHILE CLAUSE> DO <STATEMENT> 
 
 <WHILE CLAUSE> ::= WHILE <EXPRESSION> 
 
 <REPEAT STATEMENT> ::= <REPEAT HEAD> <STATEMtNT LIST> UNTIL 
 
 <FXPRESSION> 
 
 <REPEAT HEAD> ::= REPEAT 
 
 <FOR STATEMENT> ::= FOR <STEP DEFINITION> DO <STATEMENT> 
 
 <STEP DEFINITION> ::= <VARIABLE IDENTIFIER> := <EXPRESSION> 
 
 <ITERATION CONTROL> 
 
 <1TERATI0N CONTROL> :: = TO <EXPRESSION> 
 <ITERATION CONTROL> ::= DOWNTO <EXPRESSION> 
 
 51 <CASE STATEMENT> ::= <CASE LIST> <STATEMENT> END 
 
 52 <CASE HEAD> 
 
 53 <CASE HEAD> 
 
 54 <CASE HEAD> 
 
 = CASE <EXPRESSION> OF 
 
 = <CASE HEAD> <CONSTANT> , 
 
 - <CASE LIST> <STATEMENT> ; 
 
 55 <CASE LIST> ::= <CASE HEAD> <CONSTANT> 
 
Paqe 52 
 
 56 PROCEDURE STATEMENT> ::= <PROCEDURE IDENTIPIER> 
 
 57 <PROCEDURE STATEMENT^ ::= <PROC ARG HEA0> <PARAMFTER LIST> ) 
 
 56 <PROC ARG HfcAD> ::= <PROCEDURE IDENTIFIER> ( 
 
 50 <PARAMFTFk LIST> ::= <ACTUAL PARAMETER> 
 
 6G <PARAMETER LIST> ::= <PARAMETER LIST,> <ACTUAL PARAMETER> 
 
 61 <PARAI*ETER LIST/> ::= <PARAHETER LIST> , 
 
 6? <ACTUAL PARAMETER> ::- <EXPRESSION> 
 
 6^ <ACTUAL PARAMfcTER> ::= <PROCEDURE IDENTIFIER> 
 
 6A <PROCEDURE DECLARATION ::= <PROCEDURt HfcADING> <BODYPROC> 
 
 65 <BODYPROC> ::= <BODY> 
 
 66 <PROCEOURE HEADING> ::= <PROC NAKE> ; 
 
 67 <PROCEDURE HEAD1NG> ::= <PROC ARGS> ; 
 
 68 <PROC ARGS> ::= <PROC NAME> <PROGRAM PARAMETERS> 
 *9 <PROC NAME> ::= PROCEOURF <IDENTIFIER> 
 
 70 <FUNCTION DECLARATIONS ::= <FNDCL> <HODYPROC> 
 
 71 <FNDCL> ::= <FUNCTION HEADING> <TYPE> ; 
 
 72 <FUNCTION HEADING> ::= FUNCTION <IDENTIFIER> ; 
 
 73 <FUNCTION HEADING> ::= FUNCTION <IDENTIFIER> 
 
 <PROGRAM PARAMETERS> : 
 
 7U <GOTO STATEMENT> ::= GOTO <UNSIGNED NUMEER> 
 
 75 <BODY> ::= <LABEL DECLARATION PART> <BODY?> 
 
 76 <RODY> : := <B0DY2> 
 
 77 <LABFL DECLARATION PART> :: = <LABEL HEAD> <UNSIGNED NUMBER> ; 
 
 7b <LABEL HEAD> :: = LABEL 
 
 79 <LABEL HEAD> ::= <LABEL HEAD> <UNSIGNED NUNBER> , 
 
 80 <BGDY2> ::= <CONSTANT DEFINITION PART> <B0DY3> 
 
 81 <B0DY2> : : =. <B0DY3> 
 
 82 <CONSTANT> ::= <CONSTANT DEF> <IDENTIFIER> = <CONSTANT DEF> ; 
 8? <CONSTANT DEFINITION PART> ::= <CONSTANT DEF> 
 
 84 <CONSTANT DEF> ::= CONST <IDENTIFIER> = <CONSTANT> ; 
 
 
Page 53 
 
 *-5 <B0DY3> ::= <TYPE DEFINITION PART> <BODY4> 
 86 <EODY3> ::= <B0DY4> 
 
 »7 <TYPF DEFINITION PART> :: = TYPE <TYPE DEFINITION> ; 
 ^ <TYPF DEFINITION PART> :: = <TYPE DEFINITION PART> 
 
 <TYPE DEFINITION> I 
 
 89 <TYPE DEFINITION> ::= <IDENTIFIER> = <TYPE> 
 
 9 
 91 
 9? 
 9? 
 
 94 
 9^ 
 96 
 
 97 
 98 
 09 
 
 101 
 10? 
 
 103 
 
 104 
 
 105 
 
 106 
 
 107 
 
 10h 
 
 10v 
 110 
 
 111 
 112 
 
 <TYPE> 
 <TYPE> 
 <TYPE> 
 <TYPF> 
 
 = <SIMPLE TYPE> 
 
 = STRUCTURED TYPE> 
 
 = 3 <TYPE IDENTIFIER> 
 
 = <SCALAR TYPE> 
 
 <STRUCTURED TYPE> 
 <STRUCTURED TYPE> 
 <STRUCTUPED TYPE> 
 
 - <UNPACKED STRUCTURED TYPE> 
 
 = PACKED <UNPACKED STRUCTURED TYPE> 
 
 = <FILE TYPE> 
 
 <UNPACKED STRUCTURED TYPE> 
 <UNPACKED STRUCTURED TYPE> 
 <UNPACKED STRUCTURED TYPE> 
 
 = <ARRAY TYPE> 
 
 = <RECORD TYPE> 
 
 = <SET 0F> <SIMPLE TYPE> 
 
 100 <SET 0F> : := SET OF 
 
 <SIMPLE TYPO 
 <SIMPLE TYPE> 
 
 = <SUbRANGE TYPE> 
 = <TYPE IDENTIFIER> 
 
 <SCALAR TYPE> 
 <SCALAR HEAD> 
 
 := <SCALAR HEAD> <IDENTIFIER LIST> ) 
 
 := ( 
 
 <SUBRANGE TYPE> ::= <C0NSTANT> .. <C0NSTANT> 
 
 <ARRAY TYPE> ::= <ARRAY HEAD> <SIMPLF TYPE LIST> J <0F TYPE> 
 
 <ARRAY HEAD> ::= ARRAY C 
 
 <0F TYPE> ::= OF <TYPF> 
 
 <SIMPLE TYPE LIST> :: = <SIMPLE TYPE> 
 
 <SIMPLE TYPE LIST> ::= <SIMPLE TYPE LIST> , <SIMPLE TYPE> 
 
 <B0DY4> ::= <VARIABLE DECLARATION> <B0DY5> 
 <B0DY4> : := <B0DY5> 
 
 113 <VARIABLk DECLARATION> ::= <VARIABLE DECLARATION PART> ; 
 
 1H <VARIABLE DECLARATION PART> ::= VAR <TYPE DECLARATION> 
 115 <VARIABLE DECLARATION PART> ::= <VARIABLE DECLARATION ELEMENT> 
 
 <TYPE DECLARATION> 
 
Page 54 
 
 116 <VARIA6LF DECLARATION ELEMENT> ::= <VARIABLfc DECLARATION PART> ; 
 
 117 <TYPE DECLARATION> ::= <NEW TYPE IDENTIFIERS> <TYPE> 
 11H <NEW TYPF IDENTIFIERS> ::= <IDENTIFIER LIST> : 
 
 11V <IDENTIFIER LIST> ::= <IDENTIFIER> 
 
 120 <IDFNTIFIER LIST> ::= <IDFNTIFIER LIST ELEMENT> <IDENTIFIER> 
 
 121 IDENTIFIER LIST ELEMENT> ::= <IDENTIFIER LIST> , 
 
 122 
 123 
 124 
 
 125 
 126 
 
 127 
 
 12fa 
 
 12Q 
 130 
 
 131 
 132 
 
 133 
 
 134 
 
 135 
 136 
 137 
 
 <VARIABLE> 
 <VARI ABLE> 
 <VARIABLE> 
 
 = <ENTIRE VARIABLE> 
 
 = <COMPONENT VARIABLE> 
 
 = <VARIABLE> * 
 
 <PODY5> ::= <PROC DEF> <B0DY6> 
 <BODY5> ::= <B0DY6> 
 
 <B0DY6> ::= <COMPOUND STATEKENT> 
 
 <PROC DEF> ::= <PROC DEF1NITI0NS> 
 
 <PR0C DEFINITIONS> ::- <PROCEDURE OR FUNCTION DECLARATION> ; 
 <PROC DEFINITIONS> :: = <PROC DEFINITIONS> 
 
 <PROCEDURE OR FUNCTION DECLARATION> ; 
 
 <PROCEDURE OR FUNCTION DECLARATION> ::= <PROCEDURE DECLARATION> 
 <PROCEDURE OR FUNCTION DECLARATION> ::= <FUNCTION DECLARATION> 
 
 <ENTIRE VARIABLE> ::= <VARIABLE IDENT1FIER> 
 
 <VARIABLE IDENTIFIER> ::= <IDENTIFIER> 
 
 <COMPONENT VARIABLE> ::= <INDEXED VARIABLb> 
 <COMPONENT VAR1ABLE> ::= <FIELD DESIGNATOR> 
 <COMPONENT VARIABLE> ::= <VARIABLE> % 
 
 13* <VARIABLF IDENTIFIER> ::= <ARRAY VARIABLE> <PARAMETER LIST> 3 
 139 <ARRAY VARIABLE> ::= <VARIABLE IDENTIFIER> C 
 
 140 
 141 
 142 
 143 
 144 
 145 
 
 146 
 147 
 
 <FACTOR> 
 <FACTOR> 
 <FACTOR> 
 <FACTOR> 
 <FACTOR> 
 <F ACTOR> 
 
 = <VARIABLE> 
 
 = <UNSIGNED CONSTANT> 
 
 = <FUNCTION DESI6NAT0R> 
 
 = ( <EXPRESSION> ) 
 
 = <SET> 
 
 = <FACTOR> 
 
 <SET> :: = C <PARAMETER LIST> 3 
 <SET> ::- [ 3 
 
Paqe 55 
 
 148 
 149 
 150 
 151 
 152 
 153 
 
 154 
 155 
 156 
 157 
 158 
 
 159 
 160 
 
 161 
 162 
 
 163 
 164 
 165 
 166 
 167 
 168 
 
 169 
 170 
 
 171 
 172 
 173 
 
 174 
 175 
 176 
 
 177 
 178 
 
 179 
 180 
 
 181 
 
 182 
 
 183 
 
 <TERM> 
 <TERM> 
 <TERM> 
 <TERM> 
 <TERM> 
 <TERM> 
 
 <SIMPLE 
 <SIMPLE 
 <SIMPLE 
 <SIMPLE 
 <SIMPLE 
 
 <FACTOR> 
 
 <TERM> * 
 
 <TERM> 
 
 <TERM> 
 
 <TERM> 
 
 <TERM> 
 
 <FACT0R> 
 / <FACT0R> 
 DIV <FACT0R> 
 MOD <FACTOR> 
 ft <FACTOR> 
 
 < S I G M 
 <SIGN 
 
 2> 
 
 2> 
 
 FXPRESSION> 
 EXPRESSION 
 EXPRESSION 
 EXPRESSION> 
 EXPRESSION> 
 
 = + 
 
 = <TERM> 
 
 = <SIMPLE EXPRESSION> ♦ <TERM> 
 = <SIMPLE EXPRESSION> - <TERM> 
 - <SIMPLE EXPRESSION> ! <TERM> 
 = <SIGN 2> <TERM> 
 
 <EXPRESSION> 
 <EXPRESSION> 
 
 = <SIMPLE 
 
 = <SIMPLE 
 
 <SIMPLE 
 
 EXPRESSION> 
 EXPRESSION> 
 EXPRESSION 
 
 RELATIONAL 0PERATOR> 
 
 RELATIONAL 
 <RELATIONAL 
 RELATIONAL 
 RELATIONAL 
 RELATIONAL 
 RELATIONAL 
 
 OPERATOR> 
 OPERATOR> 
 OPERATOR> 
 OPERATOR> 
 OPERATOR> 
 ()PERATOR> 
 
 = < 
 
 = > 
 
 = > 
 
 = < 
 
 <ASSIGNMENT STATEMENT> ::= <VARIABLE> := <EXPRESSION> 
 <ASSIGNMENT STATEMENT> :: = <FUNCTION IDENTIFIER> := 
 
 <EXPRESSION> 
 
 <UNSIGNED CONSTANT> 
 <UNSIGNED CONSTANT> 
 <UNSIGNED CONSTANT> 
 
 = <UNSIGNED NUMBER> 
 = <STRING> 
 = NIL 
 
 <CONSTANT> : 
 <CONSTANT> : 
 <CONSTANT> : 
 
 = <UNSIGNED NUMBER> 
 
 = <SIGN> <UNSIGNED NUMBQR> 
 
 = <STRING> 
 
 <SIGN> 
 <SIGN> 
 
 = ♦ 
 
 <FUNCTION DESIGNATOR> ::= <FUNCTION IDENTIFIbR> 
 
 <FUNCTION DESIGNATOR> ::= <FN ARG HEAD> RARAMETER LIST> ) 
 
 <FN ARG HEAD> ::= <FUNCTION IOENTIFIER> ( 
 
 <VARIABLE IDENTIFIER> ::= <VARIABLE> . <FIELD IDENTIFIER> 
 
 <RECORD TYPE> ::= RECORD <FIELD LIST> END 
 
Page 56 
 
 1K 
 185 
 1.W 
 
 1F7 
 
 1^ 
 
 1*9 
 190 
 191 
 19? 
 19 6 
 
 1 u f 
 197 
 
 19* 
 
 199 
 
 2 on 
 
 201 
 
 2C2 
 
 2 3 
 
 2( 4 
 
 2 05 
 
 < F I E L D L I ST> 
 
 < F IELD LI ST> 
 
 < F I F L D L I S T > 
 
 = < F I XE D PART> 
 
 = <F I X ED PART> ; < VARIANT PART> 
 
 = <VARIANT PART> 
 
 < F I X F D PART> ::= < T Y P F DECLARATION> 
 
 <FIXFD PART> ::= <FlXtO PART L1ST> <TYPE DECLARATION 
 
 <FIXED PART LIST> ::= <FIXED PART> /' 
 
 < VARIANT PART> ::= <LAPEL LIST> ( <FIELD LIST> ) 
 
 <VA RIANT HEAD> ::= CASE <1DENTIFIER> : 
 
 < V A R I A N T PART HEAD> 
 < VARIANT PART HEAD> 
 <VAF1ANT HART H E A D > 
 
 = <VARIANT HEAD> <TYPE IDENTIFIER> OF 
 = <VARIANT PART HEAD> <CONSTANT> , 
 - <LABEL LIST> ( <FIELD LIST> ) ; 
 
 195 < LABEL LIST> ::= < VARIANT PART HEAD> <CONSTANT> 
 
 <F II F TYi F> 
 
 < F I L E T Y P E > 
 
 < f ILL TYPt 1 > 
 <F ILE TYf F 1> 
 
 = PACKED <F ILE TYPE1> 
 = < F I LE TYPE1> 
 
 : = NONSTANDARD <F1LE TYPE2> 
 := <F I LE TYPE2> 
 
 <FILE TYPF?> ::= PINARY < F I LE TYPE3> 
 
 < F I L F T Y P E 2 > ::- < F I LE T Y P E 3 > 
 
 < F I L E TYPE3> ::= FILE <0F TYPE> 
 
 <WITH STATFMENT> ::= WITH <RECORD VARIABLE LIST> DO <STATEMENT> 
 
 <RFCORD VARIABLE LIST> ::= <VARIABLE> 
 
 <RECORD VARIABLE LIST> ::= <RECORD VARIABLE LIST*> <VARIABLE> 
 
 2 ( j * < R t C R D VARIABLE L I S T , > 
 
 = <RECORD VARIABLE LIST> / 
 
Page 57 
 
 APPENDIX B - STATISTICS FOR SYNTAX TABLES 
 
 Due to the size of the syntax tables generated by the grammar 
 ANALYZFR* only the statistics for those tables are listed below. Also 
 included are those data from the XCOW compiler as a comparison/ where 
 XCO r i is the se I f -compi I ing compiler for XPL. The documentation for 
 these syntax tables can be found in section 9 .5 of "A Compiler 
 (.er.erator" [13. 
 
 PASCAL XCOM 
 
 a************************************************** 
 
 U o f B N F g r a m m a r 2 06 
 
 <•' of terminal 66 
 
 » of nonterminal 180 
 
 C1 (bit) 180*134 
 
 C1TRIPLE (24 bits) 589 
 
 PRTtf (32 bits) 206 
 
 PRDTB(8bits) 207 
 
 HDTF ({■ bits) 207 
 
 PRLENGTH (r hits) 207 
 
 C0^TEXT_CASE (8 bits) 207 
 
 LEFT_C0NTEXT ( * bits) 38 
 
 LEFT_INDEX(8bits) 115 
 
 C0NTFXT_TRIPLE (24 bits) 14 
 
 TR IPLE_INDEX (8 bits) 115 
 
 PR INDEX <x bits) 181 
 
 109 
 
 42 
 
 91 
 
 91*86 
 
 203 
 
 109 
 
 110 
 
 110 
 
 110 
 
 110 
 
 2 
 
 50 
 
 
 
 50 
 
 92 
 
 *************************************************** 
 
Page 58 
 
 AP^tNDIX C - SPECIFICATIONS FOR THE SEMANTIC STACK 
 
 The semantic stack is under the control of the SYNTHESI 
 subroutine which pushes or pops the semantic information associated 
 with a nonterminal node in the syntax tree. The function of the 
 semantic stack is to commute the information between code generation 
 routines. Each entry in the semantic stack consists of two words. 
 The first word is further divided into three subfields: TYPE, FLAG and 
 LlbGTM. The subfield LENGTH specifies number of the bits allocated 
 for <i particular operand. The subfield TYPE is used to indicate the 
 elementary type of an operand and has the following categories 
 
 1 - real 
 
 2 - integer 
 
 3 - boolean 
 U - set 
 5 - character 
 (: - s t r i m constant 
 
 The second word of an entry is used as a modifier whose 
 interpretation depends on the FLAG of the first word. The FLAG and 
 the interpretation of the modifier are 
 
 FLAG 
 
 MODIF IERCsecond word) 
 
 1 - immediate constant 
 
 2 - I a rqe const ant 
 
 (great than 16 bits) 
 
 3 - identifier 
 
 4 - temporary value 
 
 5 - address pointer 
 
 in register 
 
 6 - address pointer in 
 
 temporary location 
 
 7 - value in register 
 
 ?. - byte address pointer 
 in a register pair 
 
 its value (16 bits) 
 
 pointer into constant table 
 
 pointer into symbol table 
 relative stack offset 
 register # of pointer 
 
 relative stack offset 
 
 register tt of value 
 
 even register # of pointer 
 
 The relative stack offset is the offset relative to register 3 
 which is the local data pointer. The TYPE, FLAG and LENGTH subfield; 
 are packed into one word, where TYPE and FLAG subfields occupy 5 bit: 
 each, and the LENGTH subfield occupies 6 bits. New items can be aadei 
 to TYPE and FLAG for design modification or for code optimization. 
 
Page 59 
 
 APFTNDIX D - PASCAL RUNTIME PACKAGE ANO EXTERNAL PROCEDURES 
 
 There is a library for PASCAL routines which includes the runtime 
 packaoe and external procedures. The following procedures are some of 
 the basic routines/ and most of them are defined in PASCAL user manual 
 C53. However/ the members of the library are growing continuously and 
 not all of them are listed here. 
 
 D .1 . THE PROCEDURE WRITE 
 
 The procedure WRITE can be used to access sequential or random 
 files. The syntax of the wRITE statement for sequential files is 
 
 WKITF file-name (parameter lists); 
 wh^re the file is defaulted to OUTPUT if the tile-name is omitted. 
 For rondom files/ the syntax of the WRITE statement is 
 
 WKITT file-name Cpos i t i on-i ndex] (buffer). 
 
 The procedure WRITE was implemented as a group of routines instead of 
 as a single routine with many entry points. With this approach* only 
 thr routines required by a user's program will be loaded into the core 
 memory by the link loader. Therefore/ this PASCAL compiler generates 
 a procedure call to a selected runtime routine/ depending on the type 
 of the file (random or sequential/ packed or nonpacked) and on the 
 tyfe of the parameter. 
 
 In this implementation/ the end of line must be explicitly 
 specified by a predefined character EOL as one of the parameters to 
 the procedure WRITE. A keyword PAGE can also be used as an argument 
 to the procedure WRITE. The routine invokeo by the keyword PAGE will 
 send out the last buffer if it is not empty; it then sends out a 
 control character *1' which means skip to the top of a new paqe for 
 thp line printer. For examp le : (assume the file line_printer is 
 assigned to the line printer) 
 
 WRITt line_printer (PAGE/' a new page '/EOL) 
 would print the message 'a new page' at the top of a new page. 
 
 D.2 
 
 THE PROCEDURE READ 
 
 The syntax for the READ statement is the same as for that of the 
 
 WRITE statement. However/ the default file is INPUT for sequential 
 
 read. The procedure READ was also implemented as a group of routines/ 
 for the same reason as stated above. 
 
 There is a one-character look ahead for reaOing from 
 non-interactive devices/ yet there is no look ahead for interactive 
 devices such as CRT terminals. An end-of-file flag is set for the 
 input file upon readinj in the last character/ and the end-of-file 
 condition can be checked by calling the standard function EOF. An 
 input request to the file with the end-of-file flay set will cause the 
 pro oram to be terminated after sending the error message " ERROR: END 
 
Fage 60 
 
 OF FILF ". In addition to the attributes of the input file/ the 
 response of the READ routines depends on the type of the parameters. 
 For example/ if the parameter is one of the type integer/ the input 
 stream will be seached until a number is found and converted into 
 internal representation. Therefore/ if the input stream is 
 
 A STRING TO BF NEGLECTFD +10/ 20/ ANOTHER STRING -30 
 
 then the statement RE AD ( i / j / k ) / where i/j and k are of type inteqer/ 
 
 will assign 10 to i/ 20 to j and -30 to k. If end-of-file is 
 
 encountered before a number is found/ the executation of the proqram 
 
 will he terminated after sending the error message " ERROR: END OF 
 FILF. " . 
 
 D.3. PROCFDURb RESET (fi le_name) 
 
 The actual parameter file_name is either standard files or user 
 defined files. The procedure RESET will check and send out the last 
 buffer it is not empty/ and will call R E X ( # 7 ) service routine to write 
 end-of-file mark on 1/0 device specified by the file_name. The 
 end-of-file tlaa is cleared/ if the file is not empty/ i.e. 
 tf'F(file_name) becomes false. Otherwise/ the end-of-file flag is set/ 
 and F OF ( f i le_name) becomes true. RESET then calls another RFX(*2) 
 service routine to reset the tile position to its beginning/ and the 
 file is ready for input. 
 
 D.4. PROCEDURE REWRITECfile name) 
 
 The proceure REWRITE causes the file to be 
 end-of-file mark is put at the beginning of the file, 
 is set/ and EOFCfile name) becomes true. 
 
 rewound/ and the 
 The end-of -f i le 
 
 D.3 
 
 FUNC I TI0N EOF (file name) 
 
 The function EOF tests the end-of-file flag/ and it returns true 
 if the flao is set. 
 
 D.6 
 
 FUNCTION 0RD (x) 
 
 The result is the ordinal number of type integer of the value x 
 in the set oefined by the type of x. 0RD is handled at compile time 
 by changing the TYPF subfield of the entry (in the semantic stack) 
 which specifies the attributes of the parameter x. Therefore/ no 
 subroutine call is generated by compiling 0RD. 
 
Page 61 
 
 0.7 
 
 FUNCTION CHR(x) 
 
 The parameter x must be of type integer and the result is the 
 character whose ordinal number is x. The CHR function is compiled in 
 the same way as the ORD function. 
 
 D.J-. DYNAMIC SPACE ALLOCATION PROCEDURES FOR PASCAL 
 
 The procedure NFW(P) allocates a new variable V of type T (to 
 which P is bounded) and assians the pointer V to the pointer variable 
 P. The procedure DISPOSE(P) is used to return storage to the free 
 pool. The dynamic space allocation procedures are cooed by D. W. 
 JOKES and are in the debugging stage at the time of preparing this 
 \. a\ er . 
 
 The NEW procedure allocates a new block of storage each time it 
 is called* and points its parameter at that block. The block is 
 allocated large enouoh to hold the type associated with the pointer 
 parameter* and it is initialized to all zero. NEW will optionally 
 return NIL instead of aborting if it is unable to allocate new 
 storage; this can be used as a signal to the user program to garbage 
 collect its own data structures. 
 
 The FREE procedure returns a block of storage to the free space 
 pool so that it may be reallocated by NEW at some later time. FREE 
 will always set its parameter to NIL on completion* and it will abort 
 if it detects that it is given a reference to already free space. 
 
 When NEW or FREE aborts* it attempts to return appropriate 
 information. The followinq aborts are due to calls to NEW: 
 
 A FORT (NEW MAP #high) - Free space pool entirely used up* 
 
 option POOLMEM not selected. 
 
 ABORT (NEW ALO #cccc) - Allocate memory failed. 
 
 ABORT (NEW MEM flsize) - No free space large enough* 
 
 option POOLSIZE not selected. 
 
 ABORT (NEW INI tfhigh) - On first call tc NEW* unable to startup* 
 
 insufficient unallocated memory. 
 
 The following aborts are due to calls to FREE: 
 
 /SHORT (FPF ERR #pntr) - The space to be freea was either 
 
 already free or not in the pool. 
 ABORT (FRE DAM #pntr) - Freed pages could not be deallocated. 
 
 In these abort messages* the hex values returned are not the 
 address at which the error occured. Instead* they are as follows: 
 
F a g e 6 ? 
 
 tfKiqh - the map Limit or current high address known by NEW. 
 
 *cccr - the condition codes returned by RFX service #29 or #2A 
 
 ftsize - the size of the offending request. 
 
 "pntr - the address of the invalid region being returned. 
 
 D.9. FUNCTION ISHfT(xzCOunter) 
 
 The parameter x must be of type integer* and the counter must be 
 an expression evaluated to an integer value. Let c=ABS ( count er ) MOD 
 16* then x is shift left logically c bit positions if counter>=0* or x 
 is shift riqht logically c bit positions if counter<0. 
 
 P.1C. COMMUNICATION WITH OPERATING SYSTEM 
 
 MAX IV operating system supplies a set of executive service 
 as REX services- RFX services are basically reentran 
 
 The 
 re f e r ed 
 
 sut- routines located in the nucleus of the operating system* and may b 
 c^llej by executing a machine instruction REX. The arguments betwee 
 RFX services and user program are passed and returned in genera 
 registers whenever possible* and* because of 
 
 this scheme* it i 
 
 registers wnenever possible* ana* Decause ot tnis scneme* u l 
 possible to specify a predefined PASCAL procedure REX whose parameter 
 are the imace of 15 reqisters. In order to make the REX procedur 
 callable* a new type "word" is created for describing the type o 
 reqisters. The type "word" instructs the compiler to skip the typ 
 checking* and the RFX is defined as: 
 
 EXTERNAL PROCEDURE REX (register: ARRAYC1..15] of word). 
 
 The REX procedure is equivalent to a very powerful set of library 
 procedures; but* at the same time* it brakes the rule of strong type 
 checkinq in PASCAL. A better long-term solution is to expand the 
 PASCAL library such that each REX service corresponds to a unique 
 external procedure. 
 
 D.11. PROCEDURE FASSIGN 
 
 The procedure FASSIGN can be implemented by calling the procedure 
 REX (D.10); however* it is included as one of the predefined 
 procedures. The FXTERNAL PROCEDURE FASSIGN allows the user to assijn 
 thf logical files (defined by the operatinq system) to the 
 user-defined files at run time. For example* F ASS I GN (OUTPUT* ■ LPP ■ ) 
 would cause the logical file LPP (line printer) to be assigned to the 
 standard file OUTPUT. 
 
Page 63 
 
 APPENDIX E 
 
 - MACROS FOR PREPARING ASSEMBLY SUBROUTINE 
 AS EXTERNAL PROCEDURE 
 
 The extension of external procedure provides the programmer with 
 the flexibility to program his subroutines in assembly language. 
 However^ in order to make the subroutine callable and to maintain the 
 reentrant properity/ the receiving sequence/ return sequence/ 
 parameter passing mechanism/ and local variable allocation for the 
 assembly proqram must be compatible with the code generated by the 
 PASCAL compiler. A set of assembly macros are provided to help users 
 so that they will not be bothered by the unnecessary detail of 
 implementation. 
 
 Reaisters 1/2 and 3 are reserved/ and they cannot be used without 
 storino and restoring. Except for REX calls/ registers 1/2 and 3 are 
 not recommanded to be used. The relative address appearing in the 
 following macro definitions is defined as the offset relative to the 
 local data pointer register. In general/ the format of a macro call 
 is to place its name in the instruction field and followed it by 
 optional arguments. 
 
 F .1 . PROC/x 
 
 Macro PPOC inserts the receiving sequence/ and the argument x is 
 the name of the subroutine. It also defines BASE (BASE=3 and register 
 3 is used as local data pointer) as the symbolic name for local data 
 pointer register. 
 
 E.2. VAR/x 
 
 Macro VAR allocates the space for variable x/ which is the 
 parameter passed to the subroutine by reference. The argument x is 
 then defined as the relative address of the location which holds the 
 address of variable x passed by the calling sequence. 
 
 F.3. VAL/X/y 
 
 Macro VAL allocates the space for varable x/ which is the 
 parameter passed to the subroutine by value. The second argument y/ 
 
 which is op t i ona I 
 (numbe r of words ) . 
 the code to copy 
 argument x is then 
 of variable x . 
 
 and has default value 1/ indicates the size of x 
 If y is greater than 1/ the macro VAL will insert 
 the structure of x into the local stack. The 
 defined as the relative address of the first word 
 
Page 64 
 
 E .U . RETURN/x 
 
 Macro RETURN inserts the return sequences. The argument x is 
 
 optional and is used for function return only. If x presents* it 
 
 points to the register which contains the value to be returned by the 
 f un ct ion. 
 
 F .5 . TEMP/X/y 
 
 facro TEMP is used to allocate space for local variables x. The 
 amument y/ which is optional and has default value 1/ specifies the 
 size (# of words) of the local variable x. The macro TEMP/ if any/ 
 must be placed after the macro VAL and VAR. 
 
 E.6. EXAMPLE 
 
 A simple subroutine is given as an example for clarity. Assume 
 that a routine* which assigns the sum of three integer variables into 
 another variable/ is needed. First/ the subroutine is declared in the 
 main program as 
 
 EXTERNAL PROCEDURTE ADD (VAR SUM:INTE&ER; 
 
 A/B/C :INTEGER)/* 
 
 The subroutine can then be prepared as the following: 
 
 INS MSI/PMAC 
 PROC/ADD 
 
 insert the file of macro definitions 
 receiving sequence 
 
 VAR /SUM 
 VAL/A 
 VAL/B 
 VAL/C 
 
 called by reference 
 called by va lue 
 
 LDM/1Q/BASE A 
 
 ADM/10/BASfc P 
 
 A0M/10/BASE C 
 
 STM*/10/BASE SUM 
 
 load A into register 10 
 
 add B to regi ster 10 
 
 add C to regi ster 10 
 
 store A+B+C indirectly into SUM 
 
 PFTURN 
 END 
 
 return sequence 
 
Page 65 
 
 APPENDIX F - REGISTER ALLOCATION 
 
 The allocation scheme discused below is based on the allocation 
 scheme proposed by Douglas Jones and A. B. Bask in. 
 
 Register assionments: 
 
 Register// 
 
 Use 
 
 Global data pointer (display base pointer) 
 
 Transfer vector pointer 
 
 Local data pointer (link block pointer) 
 
 ♦Scratch indexing* addressing/ and base registers 
 
 * 
 
 8 
 9 
 10 
 11 
 12 
 13 
 14 
 15 
 
 ** ** 
 
 * *Destroyed by subroutine linkage 
 
 * * 
 
 * ** 
 
 *Accumul ators 
 
 * 
 
 * 
 
 ** 
 
 The global data pointer points to the base of the data area. The 
 first 15 locations* starting at the address pointed to by the global 
 data pointer* serve as the 15 display pointers for the 15 levels of 
 the compile time nesting. Variables declared at the outermost level 
 are referenced as displacements from R1 . In addition to variables 
 declared at this outer most level* there may be at most 15 more levels 
 of compile time nesting. 
 
 The transfer vector pointer points to a vector of up to 128 
 entries* each entry of which is the address of a predefined function. 
 All predefined functions are referenced by their predefined index in 
 the transfer vector. The transfer of control to a predefined function 
 is accomplished by using the branch and link inaexed through a table 
 instruction. This allows an absolute minimum of linkage overhead for 
 heavily used standard functions. 
 
 The local data pointer is used to access the currently active 
 local data block. This block contains the save area for subroutine 
 linkage* and the local variables for the currently active program 
 block . 
 
Page 66 
 
 Reaisters 4-7 are used as needed for addressing* and are not 
 normally saved as a part of subroutine linkage. These registers may 
 be used by predefined functions* and their contents must thus be saved 
 prior to call if necessary. 
 
 Fieoisters 8-15 serve as accumulators. R8-R11 are destroyed by 
 subroutine linkage. Registers 12-15 are never destroyed. 
 
Page 67 
 
 APPENDIX 6 - SUBROUTINE LINKAGE 
 
 Two basic forms of subroutine Linkage are proposed. These forms 
 
 are tailored to the needs of normal internal subroutines and special 
 
 predefined routines. Each method of linkage will be discussed in 
 detail be I ow . 
 
 6.1. INTERNAL SUBROUTINE LINKAGE 
 
 Reqisters R8-R10 play a special role in internal linkage. These 
 recisters are destroyed during linkage and are not restored. The use 
 of each register is outlined below: 
 
 Regi st er 
 
 Use 
 
 R8 
 R<? 
 
 P10 
 
 contains the return address 
 contains the old display 
 for the destination level 
 contains the old local data pointer 
 
 The actions involved in internal linkage are completely defined 
 by the code to be generated for subroutine call/ subroutine entry/ 
 subroutine return/ and exit. The functions are handled in the same 
 manner/ except that code to return the result of the function is 
 generated prior to the code to return. 
 
 Subrout ine call: 
 
 TRR/10/3 
 ADI/3 TCP 
 BLT/I 
 
 save the old local data pointer 
 construct new local data pointer 
 branch to the subroutine 
 
 Recieving sequence: 
 
 LDS/9/ level 
 
 STS/3/lvel 
 
 SFX/8/3 
 
 save old display for this level 
 
 set new display entry 
 
 save accumulators and link block 
 
Return sequence : 
 
 Page 68 
 
 LF X,8,3 
 
 TRR/3/10 
 
 S r$/<// leve I 
 
 RRX/f 
 
 restore link block and accumulators 
 
 restore old local data pointer 
 
 restore old display pointer 
 return 
 
 Exit sequence : 
 
 LDS/3/ I evel 
 
 B R U » 
 
 load display for destination level 
 the actual branc h 
 
 where 1 is the index of the subroutine in the ransfer vector and 
 TOE is a compile time variable containing the current maximum offset 
 from the local data pointer. Level is the compile time static nesting 
 level . 
 
 &.?. PREDEFINED SUBROUTINES 
 
 The linkage conventions for predefined subroutines are quite 
 simple. Each predefined function is given a dedicated location in the 
 transfer vector/ and is referenced by a BLT instruction. Only 
 reoisters which are modified by the routine are saved and restored. 
 The minimum convention consists of a BLT and a BRX for call and 
 return/ respectively. 
 
BIBLIOGRAPHIC DATA 
 SHEET 
 
 1. Report No. 
 
 UIUCDCS-R-77-861 
 
 3. Recipient's Accession No. 
 
 4. Title and Subtitle 
 
 A PASCAL COMPILER 
 
 5. Report Date 
 
 April, 1977 
 
 6. 
 
 7. Author(s) 
 
 Yao-Ching Stephen Chen 
 
 8- Performing Organization Rept. 
 No. 
 
 9. Performing Organization Name and Address 
 
 Department of Computer Science and 
 School of Basic Medical Sciences 
 University of Illinois 
 Urbana, IL 61801 
 
 10. Project/Task/Work Unit No. 
 
 11. Contract/Grant No. 
 
 12. Sponsoring Organization Name and Address 
 
 13. Type of Report & Period 
 Covered 
 
 14. 
 
 15. Supplementary Notes 
 
 16. Abstracts 
 
 A PASCAL compiler system, with syntax parser based on the Mixed Strategy Precedence 
 algorithm, is described. The PASCAL compiler, which was implemented on the M0DC0MP 
 IV computer, generates reentrant, relocatable, and self relocating assembly code. 
 It also allows procedures to be separately compiled and merged at linkage time. 
 Local extensions are included for I/O, file declaration, and initialization of data 
 storage areas at load time. 
 
 17. Key Words and Document Analysis. 17a. Descriptors 
 
 PASCAL 
 
 Mixed Strategy Precedence 
 
 scanner 
 
 error recovery 
 
 heap storage allocation 
 
 code generation 
 
 1 7b. Identifiers /Open-Ended Terms 
 
 17c. COSATI Field/Group 
 
 18. Availability Statement 
 
 UNLIMITED RELEASE 
 
 19. Security Class (This 
 Report) 
 
 UNCLASSIFIED 
 
 20. Security Class (This 
 Page 
 
 UNCLASSIFIED 
 
 21- No. of Pages 
 
 73 
 
 22. Price 
 
 ORM NTIS-35 (10-70) 
 
 USCOMM-DC 40329-P7 1 
 
JUt, 
 
 3 0)37?