MMHwSt BMMMMflfflB ShwhwQ 2mr Hfifl K9P8 3BK ■BE hEK2 - M MM Mi MS fill ■ Ml ^M ■ LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN Q0O.2. 16 r UIUCDCS-R-72-U95 ,2. A > t-'V • • ILLIAC IV Document No. 257 1 SUBROUTINES IN THE GLYPNIR COMPILER By David Michael Baer January 15, 1972 ILLIAC IV Document No. 257 DCS Report No. UIUCDCS-R-72-1+95 SUBROUTINES IN THE GLYPNIR COMPILER By David Michael Baer ILLIAC IV Project University of Illinois at Urbana-Champaign Urbana, Illinois 6l801 January 15, 1972 This work was supported in part "by the Advanced Research Projects Agency under Contract No. USAF 30(602)UlUU and was submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science in the Graduate College of the University of Illinois, 1972. Digitized by the Internet Archive in 2013 http://archive.org/details/subroutinesingly495baer Ill ACKNOWLEDGEMENTS The author wishes to thank Dr. Michael S. Sher of the Center for Advanced Computation, University of Illinois at Urbana-Champaign, Illinois who has acted as advisor to the writing of this thesis. The author is also indebted to Terry Layman and Mike Randal for their suggestions and help during the implementation process of the work presented here, to Duncan H. Lawrie for providing a GLYPNIR compiler to which separately compiled subroutines could be introduced and for giving the author the initiative necessary to start on this venture, and to Suzanne Sluizer for typing this manuscript. Finally, the author wishes to express his gratitude to the ILLIAC IV Project for providing financial support for this work. ABSTRACT The structure of separately compiled procedures in the GLYPNIR compiler and the use of storage areas common to separately compiled program units are described and, for the benefit of those who may wish to modify the compiler, a description is given of the current implementation of both inter- nal and separately compiled subroutines. TABLE OF CONTENTS Chapter . Page 1. INTRODUCTION 1 2. THE SPECIFICATION OF SEPARATELY COMPILED SUBROUTINES IN GLYPNIR k 2.1 An Overview k 2.2 The External Subroutine 5 2.3 The External Subroutine Entry Declaration . . 7 2.1+ The External Subroutine Call 12 2. 5 The Declaration and Use of Common Storage Areas 15 2.6 Linkage to Non- GLYPNIR External Subroutines . 20 2.7 Linkage to the System-Trigonometric Sub - routines 22 2.8 Control Cards and Use of the ZIP Option . . . 23 3- IMPLEMENTATION 25 3.1 Some General Comments on the GLYPNIR Compiler 25 3-2 Description of Compiler Tables 26 3-3 The Declaration 27 3.3*1 The Internal Subroutine Declaration . 27 3. 3-2 The External Subroutine Entry Declaration 28 3.-+ The Subroutine Call 30 3.5 The Treatment of Parameters in Subroutine Linkage 31 3-6 Compilation of the External Subroutine ... 33 3.7 Common Storage 3^ 3.8 Linkage to the System Trigonometric Routines and the GLYPNIR Dynamic Storage Allocation Routine 35 3.9 Linkage to Non-GLYPNIR External Subroutines . 36 k. CONCLUSION 37 LIST OF REFERENCES 38 APPENDICES 39 1. INTRODUCTION GLYPNIR is a high-level block structured language for ILLIAC IV programming. The GLYPNIR compiler is run on the E-65OO and produces ILLIAC IV assembler code. This is then input to the assembler (ASK), also run on the B65OO, which, in turn, produces exacutable ILLIAC IV machine code. This paper describes facilities recently implemented in the GLYPNIR compiler which allow compilation and linkage of separately compiled GLYPNIR subroutines and which provide named common storage areas shared among separately compiled program segments. The implementation of separately compiled GLYPNIR subroutines (heretofore synonymous with external GLYPNIR subroutines) should provide the GLYPNIR user with several benefits. It will now be possible to write sub- sections of GLYPNIR programs and fully debug them for incorporation into larger programs at a later time without having to recompile those subsections each time the main program is modified. It appears as if the B65OO will be overworked in the ILLIAC system, but reducing the compilation time of GLYPNIR programs should ease this strain somewhat. Furthermore, it will be possible to code library routines in GLYPNIR and eliminate the necessity for writing complex packages in ASK. (For the time being, however, external GLYPNIR subroutines may be called only from other GLYPNIR programs.) Finally, a facility has been provided which makes linkage to a non-GLYPNIR subroutine fairly easy to specify in a GLYPNIR program. Little space has been devoted here to a discussion of historical precedent for subroutine linkage methods or for the method of implementation chosen. But the problem was not simply: Given an ILLIAC IV, how does one provide separately compiled subroutines and common facilities? The problem was: Given an ILLIAC IV and a GLYPNIR compiler, how does one add these facilities to the existing compiler without necessitating major revisions to the structure of the compiler? The options available for accomplishing this task in a reasonable amount of time, yet providing the user with a good deal of flexibility, were quite limited. In some areas, particularly in the area of common storage treatment, a more optimal approach might have been used. However, since from the user's point of view there was little differ- ence in terms of efficiency and programming flexibility, the GLYPNIR staff felt that optimal solutions were not justified with respect to the several extra months of work required. Chapter 2 deals primarily with the specification and use of separ- ately compiled GLYPNIR subroutines and is of interest to the general GLYPNIR user. A knowledge of other parts of the GLYPNIR language and familiarity with ILLIAC IV architecture are assumed. (Lawrie [1] provides a good introduction to the GLYPNIR language.) Chapter 3 deals specifically with the ways in which subroutines, both internally and externally compiled, have been implemented in the compiler As such, this chapter will not be particularly useful for the general user. Internal subroutines in GLYPNIR are similar to ALGOL procedures in their declaration, and similar to FORTRAN subroutines in their use. The preparatory work for this paper consisted of implementing separately compiled subroutines and named common facilities. However, since the compiler routines responsible for establishing external subroutine linkages are the same ones responsible for internal subroutine linkages, and since no documentation existed on either aspect, I chose to deal with these as well. (Lawrie and Layman [3] provides a good overall description of the structure of the GLYPNIR compiler. ) 2. THE SPECIFICATION OF SEPARATELY COMPILED SUBROUTINES IN GLYPNIR 2.1 An Over view The use and declaration of external subroutines in GLYPNIR are quite similar to those of internal subroutines. Familiarity with these would assist the reader in following discussions. (See Chapters 9 and 10 in Lawrie [1].) The subroutine call on an external subroutine in GLYPNIR is of exactly the same form as a call on an internal subroutine. Like internal subroutines, external subroutines may be used as function designators if they have been declared with a type. The same restrictions are placed upon them; recursive use of subroutines is not allowed. If the subroutine is declared with a type, the use of the subroutine identifier within the subroutine body is equivalent to the use of a simple variable with the same type. There are two aspects of external subroutine declarations, the first of which is the subroutine itself. The external subroutine is simply a GLYP- NIR program with a subroutine heading at the beginning which must be compiled with its own control cards like any GLYPNIR program. Compiling more than one subroutine in a single run is not possible at this time but may be allowed at a later date. The external subroutine may have its own internal subroutines and may, in turn, reference other external subroutines. All variables used in the subroutine must be declared in it, either as parameters in its heading or as variables declared in the usual fashion; i.e., no variables may be glo- bal to it. The second aspect of external subroutines is the external entry declaration in the calling program. Since the subroutine is compiled separ- ately from the calling program, the compiler must be instructed where to transfer control and where to pass the parameters when performing the linkage. The external entry declaration probides this information and is quite similar to an internal subroutine declaration with no body. GLYPNIR constructs entry point names and ASK variable names from the first five characters of the sub- routine identifier and, therefore, the first five characters in the name of any external subroutines used in the execution of a GLYPNIR program must be unique . Data communication between separately compiled GLYPNIR program seg- ments is accomplished in two ways: variables can be passed as parameters or they can be declared in common storage areas which are shared between the segments. There are instances where this second form of communication is advantageous; these will be discussed later in this chapter. A simple method for establishing linkages to non-GLYPNIR subroutines from GLYPNIR programs is also presented here. Use of this facility, however, requires some knowledge of the way in which subroutine linkages are accom- plished and a thorough understanding of the AS construct in variable declara- tions. 2.2 The External Subroutine GLYPNIR programs may be main programs or subroutines: : : = | The presence of indicates to the compiler that the program is to be compiled as a subroutine, and no other control information is necessary. 6 SYNTAX: EXAMPLE: : : = SUBROUTINE ; | SUBROUTINE ; : : = | AS : : = () | ::= | , : := | AS CINT SUBROUTINE ALPHA AS CAR2 (PC POINT PNT AS RGX, CINT INDEX, BOOLEAN TOG); BEGIN END. Notice that the specification of formal parameters is made in the parameter list; in the compilation of the subroutine, those specifications are treated like any variable declaration. Specification of a parameter as an output (OUT) parameter, corresponding to a call-by-name parameter in ALGOL, is not necessary here, but that information is needed in the external subroutine entry declaration in the calling program. Notice also that specifying a formal parameter as. a vector is not allowed. Vectors can be passed as parameters, however, in the same fashion that they can he passed as parameters to internal subroutines (see Appendix C of this document) or they can be passed to external subroutines by declaring them in a common storage area. The programmer must be aware in either case that a call-by-name is implied; there is no intrinsic way to pass a vector by value in GLYPNIR. If the AS construct is used in the specification of a formal para- meter or subroutine identifier in the case of a typed subroutine, the identi- fier following AS must specify a hardware register, e.g., RGA, CAR1, ADBte. In declaring a variable AS as hardware register, any reference to that vari- able in the program implies a reference to the contents of that register, and the contents of the register are considered to be of the same type (e.g., PE REAL, CU ALPHA) as the type declared for the variable. When formal para- meters are declared AS hardware registers, during the process of subroutine linkage the values of the corresponding actual parameters are placed in those registers before program control is passed to the subroutine (see sections 4.2.3 and 12.2 of Lawrie [1] for a full explanation). Table 1 shows the types allowed with variables declared AS hardware registers. The programmer should also be aware that ADB storage is available for this purpose when formal parameters are CU variables. 2. 3 The External Subroutine Entry Declaration When a GLYPNIR program must be linked to a separately compiled sub- program, the compiler must be informed where the values of the actual para- TABLE 1 HARDWARE REGISTERS Allowed T Register Implicit type RGA PALPHA RGB n RGC 1 it RGD it RGR ii RGS it RGX PCPOINT RGE BOOLEAN RGE1 it RGF 1 ti RGF1 1 tt RGG tt RGH ti RGI tt RGJ ti CARO 2 it CAR1 CALPHA CAR2 k CAR3 CNPOINT CALPHA MODE 2 BOOLEAN PEN 3 PINT NOTES: 1. It is not po^ 2. Stores to MOI §00 / / / / / / / / / / / / / / • / 1/ / implies type is allowed Die to load to these registers. Stores to MODE or CARO cause the E and El hits to he set as well. Formal parameters should not he AS-ed to these registers. Changes to MODE should he made hefore subroutine call or within subroutine hody. PEN is really a pseudo register. PEN Is initialized to the TABLE 1 (continued! PE number at the beginning of execution. ' Formal para- meters cannot be AS-ed to this register. k. Return address passed to subroutine in ACAR3 and therefore it must not be used as a formal parameter. 10 meters are to be stored and where to transfer program control. This informa- tion is specified in the external subroutine entry declaration which, in GLYP- NIR, may appear anywhere a declaration is allowed. SYNTAX: | EXTERNAL SUBROUTINE Subroutine identifier> : := | AS : : = () | ::= | , | OUT : : = | AS ::= ENTRY = | : : = FILENAME = | EXAMPLE: EXTERNAL SUBROUTINE S; EXTERNAL CINT SUBROUTINE ALPHA AS CAR2 (PCPOINT PNT AS RGX, CINT INDEX, 11 BOOLEAN TOG); EXTERNAL PREAL SUBROUTINE FUNCTIONX AS RGA (PREAL ARG AS RGA) ENTRY = XSTART FILENAME = "MYFILES/ASKFUNCTION"; Notice that use of the AS construct in connection with external subroutines requires that the identifier following AS must be a hardware register. Notice also that the declaration of a parameter as an output para- meter (OUT) is important here, since it is the calling program which is res- ponsible for assigning the output values to those actual parameters upon exit from the subroutine. The subroutine identifier and parameter specifications must corre- spond with those of the associated external subroutine heading on a one-to- one basis in type and AS-ed to the same register if the AS construct is used. The presence of explicitly indicates that the external subroutine is a non-GLYPNIR program and should never be used in the external entry declaration for a GLYPNIR subroutine. (Use of the con- struct is explained in Section 2.6 of this Chapter.) The construct is provided for use in conjunction with the GLYPNIR control option ZIP. In compiling a main program with the ZIP option turned on, the compiler will generate the necessary control cards to assembler, collect and load the compiled program. By specifying FILENAME = , where is simply the name of the file containing the assem- bled subroutine code, the compiler is able to generate instructions for including that with the main program code file at collection time. The pres- ence of in an external entry declaration in the body of an 12 external subroutine is allowed, but meaningless (see Section 2.8 of this Chapter) . 2.k The External Subroutine Call SYNTAX: ::= : : = () | ::= | , : : = | j : : = : : = As might be expected, the syntaxes for calls to external and internal subroutines are identical. The actual parameters of the subroutine call cor- respond directly to the formal parameters appearing in the external subroutine entry declaration. An empty actual parameter is equivalent to the occurence of a literal zero (FALSE if Boolean). If the number of actual parameters is less than that of the declared formal parameters, the remaining unspecified actual parameters are considered to be empty and equivalent to the occurence of zero or FALSE. If the actual parameter corresponding to a formal parameter declared as OUT is a simple variable, that variable will hold the value last held by the corresponding parameter in the subroutine when the subroutine is exited. In other words, the effect is the same as that of using a variable as a call- by-name parameter in ALGOL. Should the actual parameter corresponding to an output parameter be an expression or empty, the parameter will be considered 13 as an input parameter only for that particular subroutine call. If the type of the actual parameter differs from that of the for- mal parameter, the value of the actual parameter will be converted to the type of the formal parameter, if such conversion is legal. Table 2 summar- izes the rules for such conversions. If any of the formal parameters in an external entry declaration are declared AS hardware registers, all the actual parameters in calls to that subroutine must be simple variables of the same type as the formal para- meter, or empty. The reason for this is that in evaluating expressions or in performing type conversions, the compiler uses certain hardware registers, and it might overwrite a parameter specified as a hardware register which has been already processed. Consider the following example: PE REAL X,Y; EXTERNAL SUBROUTINE S(PE REAL A AS RGA, PE INTEGER B); S(X,Y) The call on S would result in an error condition due to the follow- ing actions: 1. The compiler would process actual parameter X. It would see that X is of the same type as formal parameter A, and would simply write the contents of X into RGA. 2. The compiler would then attempt to process actual parameter Y. It would notice that a type conversion from REAL to INTEGER is required, and that to perform that conversion RGA must be free. Since RGA is not free, an error condition would result. Ik TABLE 2 PARAMETER CONVERSION, ACTUAL AND FORMAL PARAMETER TYPE DIFFERENCES Actual Type Formal Type Real Integer Alpha Boolean Confined Pointer Non-Confined Pointer Confined Non-Confined Real Integer Alpha Boolean Pointer Pointer 2 2 X X X X X X X X X X X X X X X X X X X X X X X (Blank — no conversion necessary; X = not allowed.) 1. Usual conversion 2. AP is rounded and truncated. If the value of the AP is too large for U 8-bit fixed point representation, an overflow condition results. 15 This is not a manditory requirement, since this sort of problem would not arise in all cases and the compiler does make a fairly thorough check of register misuse in parameter assignment. However, unless the pro- grammer has a good deal of experience, he would be wise to follow the practice of using only simple variables of the correct type for actual parameters cor- responding to formal parameters declared AS registers. 2.5 The Declaration and Use of Common Storage Areas A FORTRAN-like named common facility is available in GLYPNIR which makes it possible for a GLYPNIR program segment to share memory locations of variables declared in the common blocks with every other separately compiled program segment having a declaration for the same common block. SYNTAX: : : = COMMON ; ; ENDCOMMON; : : = | ::= ; : : = | , ::= VECTOR | may be any of the following: PE ALPHA PALPHA PE INTEGER PINT PE REAL PREAL 16 PE CONFINED POINTER PCPOINT CU ALPHA CALPHA CU INTEGER CINT CU REAL CREAL CU NONCONFINED POINTER CNPOINT BOOLEAN Common block declarations may appear in GLYPNIR anywhere a declar- ation is legal, and more than one common "block declaration may occur in a GLYPNIR program or in an external subroutine. The maximum number of common blocks that can be shared among a GLYPNIR main program and all of its exter- nal subroutines is seven. Furthermore, all common blocks must be declared in the main program, even if they are needed only as common storage between two of the subroutines. If only one common block is needed among the main program and sub- routines, that block need not be named ( may be empty>); otherwise the blocks must be named. GLYPNIR uses the first five characters of the common block name to contruct the ASK variable names generated for the declared common variable and, therefore, all identifiers used in naming the common blocks and external subroutines must be unique in the first five characters. Within the program, a variable declared in a common block should be treated as any variable declared in the normal fashion. When corresponding common blocks are declared in their respective programs, however, the prog- rammer must be sure that all variables in the block are declared' in the same order and of the same type as their counterparts in other programs. 17 Vectors may be declared in common blocks and are equivalent to declaring n + 1 simple variables where n is the dimension of the vector. Furthermore, a vector may be declared in a common block where n + 1 simple variables are declared in the same block in a different separately compiled segment. For example, if in one declaration we had: CINT VECTOR CVI[2]; and if in the corresponding declaration in another segment we had: CINT CVA, CVB, CAC, CVD; then CVI[0] and CVA would refer to the same location, as would CVI[1] and CVB, etc. Common blocks in subroutines may have fewer PE variables declared in them than their counterparts in the main program, but in no case may there be more. The same is true for CU and Boolean variables. Declarations for PE, CU, and Boolean variables may be mixed but it is good practice to declare all variables of each respective type together within the common block dec- laration, simply to provide programming clarity. If more variables are dec- lared in a subroutine common block than in its MAIN counterpart, the compiler cannot detect the error, and the effect will probably be an alteration of the values of variables in the main program or in other common blocks. Consider the following example where we have a main program and two separately compiled subroutines, SI and S2, and see Table 3- BEGIN foMAIN PROGRAM EXTERNAL SUBROUTINE SI J EXTERNAL SUBROUTINE S2; COMMON CBA PREAL X, Y, Zj 18 BOOLEAN BM; CINT CI, CJ; ENDCOMMON; COMMON CBB; PINT A, B, C, D, E; ENDCOMMON; END. SUBROUTINE SI COMMON CBA; PREAL Q, R; PINT S; BOOLEAN BS1; CINT CI, CJ; ENDCOMMON; END. SUBROUTINE S2; COMMON CBA; PREAL X, Y, Z; BOOLEAN BS2; CINT CI; ENDCOMMON; COMMON CBB; PINT VECTOR VI [U] ENDCOMMON; END. In some instances it is preferable to communicate data to subrou- tines via common rather than as parameters, especially in the case where the same variables are passed as actual parameters in each call. Using common is more efficient since the time consumed in passing the values of the parameters is eliminated. And although it is not difficult to pass vectors as para- meters, it is much easier to use vectors declared in common blocks. Finally, in the case where an ASK subroutine is written for a GLYPNIR program, it is ON ft t3 CD 0) -p ft CO ft • ft o ft -H a ft cd CO g bDH ft fl fj'ti O •H S O P) ft O H OJ o o ft o H OJ co ft- £ CD S H H &ft + + + + + + + + + + + ft .p Sn •P •H W CO M o ft ?H ft -H < <: < < < Sj pq m pq pq pq ft O ^ CD s ^ b pq ft ft m pq m m pq pq pq pq ft ft O CO CO p O O o o o o p p o o CO ft •P o ft ft ft m o o ft ft ft ft ft CO CO •H W O T3 rt -H CD £ ft ft CO ^ S ■P ft o * O *H Pi OJ ra •H CO CO ^H •P CD id CO !flH (1) & d CD £ ft O p M 5 CO -P w ^ ft o D B w w w w w m <£ -H EH > to ft ft ft ft o ft ft ft ft ft o g CO o ft -H d •H •H fl-PH -P CO •H ft , +2 2 T3 CD ft o o ft CO -H H o ft ^ ft ft -P o CO ft § ft £ O no O o O ft Ph * CO CO • ft ft 9 a cvj s CO ^ CD c§ • co tfH o H OJ on J- S T3 -H ft !5 H OJ i L | i i i i i i i j CD ft ^5 CO CVJ CO H i H H H H H H Ph ft .^ CO EH 0) r-H ft CO X >H Csl pq o i > > > > > CO o •H cd H H -P CO o co Pi CO CO CO o •H i >5 ft ft T3 fi ft CO ^ ?H •H CD CD ft O 1 | M Ph T3 £ S CD [~j 0) cd* O 3 -P S ^ ?H 03 •H U Pi lfj CO -P bD ft ft H H CO O o ft O Jh W co (D ft ft -p O ft CO CO O H CO H h> ft ft CO a? ft CO ft O o o H N pq O a < pq O ft ft CO CD ?H CO ft CO ft pq ft Sd CO o +3 CO O CD ft CJ •P -P o ■H CO CO CO ft P< co o ft • 03 •p -p fit CO CD •H T3 H CD co CD Pi ft W ft O -P O -H o CO •H CO CO S ft o 3 pq •H ■P -H CD I Pi Hi pq Pj O ft Jh !ft ft ft o o w o. o CO O Pf 1 > HI OJ 20 a fairly simple matter for that subroutine to reference common variables (see Section 2.6 of this Chapter). 2.6 Linkage to Non-GLYPNIR External Subroutines When the ENTRY construct is used in an external subroutine entry declaration, it is assumed that a linkage to a non-GLYPNIR subroutine is desired and, as such, a special restriction is placed on the formal para- meters: they must all be declared AS hardware registers. This feature was implemented for linking to ASK subroutines, "but linkage to subroutines writ- ten in another language might be possible, depending on how separately com- piled subroutines are handled in that language. The effect of the call on a subroutine declared in this fashion is that the values of any parameters are placed in their assigned registers, and a branch to the label specified in is performed. The return address is passed to the subroutine in ACAR3, and the subroutine is responsi- ble for saving that address for later use when a return to the calling prog- ram is desired. Also, the subroutine must insure that ACARO contains the current mode upon returning control to the calling program. When the sub- routine is entered, the E and El bits and ACARO (containing a representation of the E and El bits) are left unchanged; i.e., the mode pattern remains the same. The programmer is free to alter the mode within the subroutine, but ACARO must always reflect these changes when the subroutine is exited. An ASK subroutine used in this fashion should be of the approximate form: BEGIN 21 EXCHL(3) $ICR; END. In the example, is the same identifier that follows the "ENTRY=" in the external subroutine entry declaration in the calling program. Appendix B contains a sample ASK subroutine to be used ■with a GLYPNIR program. It is possible for ASK subroutines to reference variables declared in common blocks in the calling program. First, external declarations in the ASK subroutine must be made of the base addresses of the PE, CU, and Boolean storage blocks. To determine the names of these blocks, append the first five characters of the block name to the letters P, C, and B respec- tively. For example, if the subroutine is to reference variable declared in a common block named AREA, there should appear in the subroutine the statement: EXTERNAL PAREA, CAREA, BAREA; These represent the base addresses for those storage areas. To reference the first CU variable declared in the block, one would use the address CAREA + 0, for the second, CAREA + 1, etc. The same is true of the PE and Boolean variables. Needless to say, the contents of those locations should be treated as quantities of the same type (POINTER, REAL, etc.) as their declar- ations in the common block. One useful feature of this method is the ability to link to the 22 available mathematical subroutines like gamma functions and hyperbolic tri- gonometric functions. For instance, the function for hyperbolic tangent has the entrypoint TANH6U and its code file name is I^LIB/TANH6^. Furthermore, it expects a REAL parameter in RGA and returns its REAL result in RGA. Therefore, to call it from a GLYPNIR program, the external entry declaration must be included: EXTERNAL PREAL SUBROUTINE HTAN AS RGA (PREAL X AS RGA) ENTRY = TANH6U FILENAME = "1ULIB/TANH6U"; Thereafter, when one wishes to call the subroutine, the identifier HTAN should be used. If the ZIP option is in effect, the programmmer must see that the file is present on disk when the files are collected. 2.7 Linkage to the System-Trigonometric Subroutines Calls on the square root, natural log, exponentiation, and trigo- nometric functions are now handled intrinsically in GLYPNIR. Those routines are: Subroutine Name SIN COS TAN COT ARCTAN LN EXP Function sine cosine tangent cotangent arctangent natural log exponential 23 Subroutine Name Function SQRT square root Use of these identifiers will result in appropriate calls and no declarations for the subroutines need appear in the program. GLYPNIR prog- rams accomplishing linkages to the routines in the old fashion -will still work. 2.8 Control Cards and Use of the ZIP Option To compile a subroutine with GLYPNIR, the B6500 control cards should be the same as those used in a main program. If the GLYPNIR option ZIP is used, the subroutine will automatically be assembled. The conventions for naming the output files of GLYPNIR and ASK are as follows: for #C0MPILE identifier l>/ WITH GLYPNIR, the ASK code file which GLYPNIR generates will be: identifier l>/GLYPSUB/ where is the name of the subroutine being compiled; and if the ZIP option is used, the output of ASK will be: /< sub routine name>. For example, if a GLYPNIR subroutine named ALPHA were compiled with: #COMPILE A/B WITH GLYPNIR FOR LIBRARY then GLYPNIR would produce: a/glypsub/alpha and ASK would produce: A/ ALPHA. It is the assembled code file produced by ASK which must be speci- fied if the in the external entry declaration in the main 2k program is used. If ZIP is used when compiling a main program having exter- nal entry declarations with specified filenames, GLYPNIR will generate the necessary control cards to assemble the main program, invoke the collector and then the loader. At the collector stage, all subroutine code files specified in the entry declarations will be collected along with the main program and the system trigonometric routines, log routines, etc., if they are called in the program. 25 3 . IMPLEMENTATION 3.1 Some General Comments on the GLYPNIR Compiler GLYPNIR is a one-pass compiler which utilizes the University of Illinois Translator Writing System. It runs on the B65OO, and output from the compiler is ILLIAC IV assembly language. Lawrie and Layman [3] provide a basic introduction to the structure and internal workings of the compiler and, for the most part, the author will not attempt to duplicate that information here. However, a topic of great importance, the way in which GLYPNIR manages the user-declared variables, must be thoroughly understood before a discussion of subroutines can begin. Variables and vectors are assigned space in PE memory in three distinct sets, a PE memory stack, a CU memory stack and a Boolean memory stack. Allocation is done at compile time and all assign- ments are made on a stack basis. PE variables are assigned storage relative to the ASK label contained in the alpha variable PNAME (CNAME for CU variables, and BNAME for Boolean variables) . In a main program the names of these stacks are "PREG, " "CREG" and "BREG" respectively. For an external GLYPNIR subroutine, the stack names are constructed by appending the first five or fewer charac- ters of the subroutine name to the letters P, C and B. Variables declared in common blocks are assigned to their own stacks, the names of which are con- structed in the same fashion as the principal memory stacks of external sub- routines. The systematic way in which these stacks are named provides the compiler with a method for communicating data among separately compiled seg- ments via parameters and common storage areas. 26 3.2 Description of Compiler Tables Wo new tables were added to GLYPNIR in the process of implementing external subroutines but, in some cases, more extensive use of existing tables was made. The tables relevant to this discussion are: BTGTAB: This array contains all identifiers and strings appearing in a program. Each entry for an identifier also contains a pointer to IDTAB. IDTAB: This array is used to hold semantic information associated with identifiers. Each identifier has a two-word entry in IDTAB, the first con- taining information about what entity is represented, its type, etc. If the entity is a subroutine or function, the second word is subdivided into three fields: [U6:2] - SUBDISPF - which indicates whether the subroutine is inter- nal (contains 0) or external (contains 1) [M+:29] - PARAMLINKF - which contains a pointer to the array PADLAR [15:16] - LABF - which contains a label number at which executable subroutine code begins if internal; otherwise, it contains zero. ' PADLAR: This is the principal array used in holding information about sub- routines. Every subroutine declared is assigned a row of PADLAR and, within that row, there is one word of information about each parameter and about the subroutine itself, if it is a function. If the subroutine is external, the first word in the row contains the first five characters of the subroutine name in [29:30]. Otherwise, each word is subdivided into the following fields: [U6:U] - TYPEF - which is the type of parameter or function 27 [38:1] - VALUEF - which is used to indicate an output parameter [35: 16] - PARAMLOCF - which is relative address of a parameter to the base of its associated variable memory stack [16:6] - REGCONDF - which indicates where a parameter is to be stored (i.e., in a register or in a variable memory stack) Remember that the disposition of the subroutine (internal or exter- nal) is contained in the IDTAB entry for the subroutine identifier and the contents of the PADLAR row will be treated according to the disposition. 3.3 The Declaration Processing of the subroutine declaration or external subroutine entry declaration in GLYPNIR consists of setting the parameters in the IDTAB entry for the subroutine identifier, filling the assigned PADLAR row with the appropriate information and, in the case of the internal subroutine, compiling the body of the subroutine. 3»3«1 The Internal Subroutine Declaration When an internal subroutine declaration is encountered, the compiler: 1. Determines whether a function or subroutine is present. 2. Assigns a row in PADLAR to the subroutine. 3. Processes the subroutine identifier. A storage space for the function value is assigned and the first word of the PADLAR row is filled with the necessary information on the function type, etc. k. Generates a branch around the body of subroutine code. All internal labels generated by GLYPNIR are of the form Gn, where n is determined by the compiler. The compiler assigns a label number which will appear at the end of the subroutine code and that number is stored so that the appropriate 28 ASK label can be generated following compilation of the subroutine. 5- Generates a label marking the point at which subroutine code begins, and then generates code for storing the return address on a stack. This stack is maintained during execution time; the return addresses are stacked so that nested subroutine calls can be performed. 6. Processes formal parameters. For each parameter the next word in the PADLAE row is filled with the following information: a. type b. call -by-name (OUTPUT) or call-by-value parameter c. relative address of parameter d. storage condition (in a register or in a variable stack) 7. Puts a zero into the next PADLAR word to mark the end of the parameter list. 8. Compiles the body of the subroutine. 9. Generates a return to address contained in the top of the return address stack. 10. Generates the label saved in Step k. 11. Determines the maximum amount of PE, CU, and Boolean storage subroutine uses. (See Section 5. 1.1 of Lawrie and Layman [3] for a discussion of storage allocation processes.) 3«3'2 The External Subroutine Entry Declaration The compiler takes the following steps upon encountering an exter- nal subroutine entry declaration: 1. Determines whether a function or subroutine is present. 2. Assigns a row in PADLAR to the subroutine. 29 3. Processes the subroutine identifier. It takes the first five characters and places them in the first word of the PADLAR row. Then, if the subroutine is a function, it places type and location information in the second word. h. Processes the formal parameters. For each parameter the next word in the PADLAR row is filled with the following information: a. type b. call-by-name or call -by-value c. relative address of parameter d. storage condition If the parameter is stored in the PE, CU, or Boolean memory stack, the relative address indicates an offset from the base of the subroutine stack, not the stack of the calling program. In the compilation of an external GLYPNIR sub- routine, the parameters specified in the subroutine heading are treated simply as the first variables declared in the program and are therefore assigned the first locations of their respective stacks. In this way, the compiler can determine the relative addresses of the parameters in the external entry dec- laration. 5- Puts a zero into the next PADLAR word to mark the end of the parameter list. 6. If is present, the following actions are taken: a. The compiler generates the ASK speudo-ops: EXTERNAL ; DEFINE = ##; where is the user- specified entry label and is the entry label the compiler would automatically generate 30 for a GLYPNIR external subroutine. b. The compiler checks to see that all parameters have been declared AS registers and generates an error if this is not the case. Thereafter, any calls on this routine look like a call on a GLYPNIR external subroutine to the compiler. The DEFINE generated and the restrictions on the parameters allow the correct linkage to occur despite the compiler's gener- ating a call on a GLYPNIR subroutine. 7- If is present, the compiler saves a pointer to the BIGTAB location of the string containing the name of the file in which is contained the subroutine executable code. This information is used when the collect control deck is built. 8. If the subroutine is a GLYPNIR program ( was not present), the compiler generates ASK external declarations for the entry-point label, and the base of the subroutines PE, CU, and Boolean variable storage stacks. These names are constructed by taking the first five characters of the subroutine name and appending them to the letters L, P, C, and B respec- tively. 3-h The Subroutine Call When the compiler encounters an identifier which has an IDTAB entry indicating it is a subroutine, it proceeds as follows: 1. Finds in the same IDTAB entry the PADLAR row assigned to the subroutine and the subroutine disposition (internal or external). 2. Generates code to purge all registers. 3- Proceeds to process the actualy parameters by performing any 31 conversions required and by placing the values in the appropriate registers or memory locations. (The next section explains the treatment of parameters in detail. ) k. Performs all null assignments for actual parameters which were empty (including the case where there are fewer actual parameters than formal parameters) . 5- Generates a calling sequence. For an internal subroutine this consists of generating a branch to a label Gn where n comes from the subroutine identifiers IDTAB entry. For an external subroutine, the label to which the branch is made is of the form Lcccc where the characters ccccc are obtained from the first word of the subroutine's PADLAR row. 6- Replaces the values of call-by-name parameters with the values held upon exit from the subroutine. The process is identical to the assignment of parameter values but in a reverse direction. 7- If the subroutine is a function, the function value (or values if a PE function) is assigned to a location where the calling program can access it. 3.5 The Treatment of Parameters in Subroutine Linkage Setting up the linkages to subroutines is fairly simple, but passing the values of parameters is quite another matter. Actual parameters can be of three types: simple variables, parameter expressions, or empty (including omitted trailing parameters). Only simple variables can be used as call-by- name parameters; if one of the other types is used for a call-by-name para- meter, the actual parameter will be treated as a call-by-value only for that subroutine call. 32 Extensive policing for register misuse is conducted during the parameter value assignment portion of a subroutine call. The compiler moniters the usage of registers RGA, RGB, RGR, RGS, RGX, ACAR1, ACAR2, and ACAR3- In the process of assigning parameter values, when one of these registers is used to store the value of a parameter, it is marked in use. If the compiler later needs that register to perform a conversion or another assignment, an error condition is detected. The bulk of the work in parameter conversion and assignment is done by the procedure PARAMCONVERASS. Variables global to it, which are set before it is called, indicate the locations of the source and destination of the parameter value and the respective types. PARAMCONVERASS then generates all the necessary code to see that the parameters are converted to the expected type and assigned to the correct location. Furthermore, it moniters register usage in parameter storage and checks for register misuse for each parameter. When the source location is one of the variable memory stacks, PARAMCONVERASS assumes the stack to be the primary PE, CU, or Boolean memory stack of the program (e.g., PREG, CREG, or BREG for a main program). For a destination in one of those stacks, the assignment is made to that same stack if the subroutine is internal. For an external subroutine, the assignment is made to a location relative to the base of one of the subroutine's primary memory stacks. To determine the name of the stack base, the five characters in the first word of the PADLAR row are appended to P, C, or B, depending on the parameter type. If the source is a variable declared in a common block, PARAMCONVERASS will reference the correct location; in no instance will the destination be in a common storage area. For replacing the values of call-by-name parameters, PARAMCONVERASS 33 is once again used to generate the code for assigning the values to the cor- rect location and performing any required conversion; potential register misuse is once again checked. 3.6 Compilation of the External Subroutine The external subroutine is compiled in exactly the same fashion as a main GLYPNIR program, except at two critical points. In processing the subroutine heading, the compiler must undergo initial preparation for compiling the program. First, from the subroutine identifier it constructs the entrypoint name and the names of the three prin- cipal memory stacks. At this point, code is generated for pushing the return address onto the return address stack. If the subroutine is a function, the subroutine identifier is treated in the same fashion as a simple variable of the same type (i.e., an IDTAB entry is constructed for it, a storage location is assigned, etc.) The same is true of the parameters specified. From the compiler's point of view, the subroutine heading: SUBROUTINE S (PREAL X, CINT CI, BOOLEAN B, PREAL Y); is equivalent to: SUBROUTINE S; BEGIN PREAL X, Y; CINT CI; BOOLEAN B; Finally, a pointer to the BIGTAB location of the subroutine identi- fier is saved for use in constructing a file name if a control deck for the collector is to be built. 3k The other point at which compilation differs is at the end of the program. A subroutine return is generated as the last exacutahle instruction. Furthermore, the code appearing at the beginning of the ASK code file differs substantially from that produced for a main program. A good deal less ini- tialization is done and many of the identifiers designating storage areas declared in the main program are simply declared external. 3.7 Common Storage In order to implement common storage facilities, three bits were added to the location field in the IDTAB entries for identifiers residing in one of the memory stacks. The low-order bits still contain the address of the variable relative to its stack base and the upper three bits contain an index indicating which stack is referenced. A zero in the top three bits indicates an address relative to the principal memory stacks (e.g., PREG, BREG, or CREG for a main program). Otherwise, it indicates an address relative to the base of a common storage area. In this case, those bits serve as an index to an array containing the labels of the stack bases. The value of the location field is assigned at the time of the declaration of the variable and never requires alteration. When the compiler generates code referencing a quantity in a stack, it strips off the top three bits to determine which stack, and uses the remainder of the field as the relative address. When a common block declaration is encountered, the compiler pro- ceeds thusly: 1. Saves the values of the storage allocators for the principal PE, CU, and Boolean stacks and sets the allocators to zero. 2. Assigns an index to the common storage block (from 1 to 7) . 35 3- Takes the first five characters of the block name and constructs the base labels of the PE, CU, and Boolean storage for the block by appending those characters to P, C, and B. If the block is unnamed, it assigns the default labels PCOMMN, CCOMMN, and BCOMMN. It then places these labels in the array containing the common block base names. k. Processes the variable declarations in the usual fashion but puts the block index in the top bits of the location field. 5. When ENDCOMMON is reached, it saves the values of the storage allocators for use in making the ASK declarations for the storage blocks, and restores the values the allocators held before the common block began. If the program is a main program, the compiler generates the ASK declarations for each base label and the corresponding number of words or rows in its block. Otherwise, it declares the base labels external. 3.8 Linkage to the System Trigonometric Routines and the GLYPNIR Dynamic Storage Allocation Routine The GLYPNIR identifiers for the system trigonometric, square root, log, and exponentiation routines have entries in IDTAB and PADLAR which are initialized before program compilation begins. The values of the initialized entries are the same as if an external entry declaration had been made for that subroutine. For instance, initialization is made for the identifier SIN identical to the IDTAB and PADLAR entries the compiler would make if it were to process: EXTERNAL PREAL SUBROUTINE SIN AS RGA (PREAL ARG AS RGA) ENTRY = SIN6U; If any of these routines are called during the program, the compiler sets a flag so that their code files can be included in the collect deck. The GLYPNIR dynamic storage allocation routines also have initialized 36 entries which make them look like external subroutines. The code responsible for performing dynamic storage allocation resides in GLYPNIR/ EXTHEAD which is always collected with the main program. In the past they were treated like internal subroutine s, but this did not allow access to them by external GLYPNIR subroutines; therefore, modifications were made. Since the allocation algo- rithms depend upon knowing the last address of the main program in order to assign memory for dynamic storage, it is critical that the GLYPNIR main prog- ram be the last file specified in the collector control deck. 3.9 Linkage to Non-GLYPNIR External Subroutines Setting up linkages to non-GLYPNIR ■ subroutines is a trivial matter. By restricting the specification of all parameters to AS registers, the com- piler can treat a call on the subroutine as a call on a GLYPNIR external sub- routine, since no reference will be made to a subroutine's variable memory stack when parameter values are passed. Therefore, when an external entry declaration specifying ENTRY = is compiled, instead of generating: EXTERNAL Lccccc, Pccccc, Cccccc, Bccccc; as it would for a GLYPNIR subroutine, the compiler generates: EXTERNAL ; DEFINE Lccccc = ##; Thereafter, when the routine is called, the compiler will act as if it were linking to a GLYPNIR external subroutine, but will automatically perform the correct linkage. 37 h. CONCLUSION Facilities have been provided in GLYPNIR which allow the separate compilation of GLYPNIR subroutines that can be called from GLYPNIR programs. It is also possible for GLYPNIR programs to call ASK subroutines specified in a standard fashion. One possible extension of the work already completed is allowing more than one subroutine to be compiled in a single run. This would involve only a minor change in the syntax but would require a fairly tedious reintialization of the compiler for each subroutine. Another possible extension would be an option of compiling GLYPNIR subroutines in such a manner that they can be called from other languages. GLYPNIR subroutines are compiled in such a way that they rely on certain storage declarations and sections of code included with all main programs. To put this option into effect, these declarations and code blocks would have to be included with the subroutines, and a slightly different linkage mechanism would have to be provided. 38 LIST OF REFERENCES [1] Lawrie, Duncan H. GLYPNIR Programming Manual . ILLIAC IV Document Num- ber 232, Department of Computer Science, University of Illinois at Urbana-Champaign. August 1970- [2] Lawrie, Duncan H. GLYPNIR: A List Processing Language for ILLIAC IV . Report 322, Department of Computer Science, University of Illinois at Urbana-Champaign. April 1969- [3] Lawrie, Duncan H. and Terry Layman. GLYPNIR Compiler Maintenance Manual . ILLIAC IV Project Document, University of Illinois at Urbana- Champaign. February 1971- [k] Layman, Terry. "Some Recent GLYPNIR Problems," GLYPNIR Publication Num - ber 2 . ILLIAC IV Project, University of Illinois at Urbana- Champaign. December 1970- [5] Trout, H. R. G. A BNF Like Language for the Description of Syntax Directed Compilers . Report Number 300, Department of Computer Science, University of Illinois at Urbana-Champaign. January 1969« 39 APPENDIX A THE SYNTAX OF SUBROUTINES The syntax given here for subroutines is a portion of the entire syntax for GLYPNIR as input to the translator writing system- The syntax is specified in a form similar to BNF, but there are certain differences which facilitate processing. The reader should refer to Trout [5] for an explana- tion of this form of specification. SYNTAX OF GLYPNlR SUBROUTINES 1+0 r«TYPE* AHEAD SUBROUTINE]* [SUBR0uTlNt/PR0CE0UREPs30 1#S206 "PROGRAM"! I.. PS13 1 t"*l" NOT AS 9S207 / "*i" aS "*l" #S20^3 t ["XFORMAL PARAMETER PART"]! C" " AHEAO #| / C"ANY" BUT #>)*PS208 J #|3 "unla b elled block* c,/" " *si but #end ahead subroutine psah csubroutine / procedure *s303 ps353 c"*i" not as ps31 / "*j" A s "*I" *S3lJ [["FORMAL PARAMETEK PART"H#MpS36 C"UNLABELLED STATEMENT"&]PS37 i •e x teRna»- subr Uti n e entry declaration"! »■ exteRnaL^oi C ["TyPE"/"ANY" BUT SUBROUTINE BUT PROCEDURE BUT #* BUT #END AHEAD SUBROUTINE PS43I CSUBROuTlNE/PROcEnuHEPS303 PS353 l"*I" NOT AS PS202/ "M" AS **I" PS202] C t C"FORMAL PARAMETER PART"3* (iS36 tENTRY«"*I" PS2033& CFILENAME«"*S" *S204]& 3 / C"ANY" BUT #|J* PS34J PS205) "FORMAL PARAMETER ([LIST f"TYPE" U/" PART^im ttOUTH "*I* NOT AS PS32/ C0UT3& "*I" AS "*I" PS323/ LlsTC w ANY" BUT » BUT ) BUT #|]CLOSE PS33J ["ANY" BUT ) BUT #I]*»S33] " AHEAD tt PS34 ]| SEPARATUR #/ in APPENDIX B SAMPLE EXTERNAL SUBROUTINES Three programs are presented "below: a GLYPNIR separately compiled subroutine, an ASK subroutine, and the GLYPNIR main program which calls them. Although the programs are not complex, they should serve to illustrate the critical areas in external subroutine use. The GLYPNIR function ARRAYMAX finds the elements of maximum magni- tude in each row and each column of an array of order n < Sk which is stored straight, and returns the value of the element of maximum magnitude of the array as its function value. The array is passed to the subroutine and the subroutine returns the row maximums via common storage; the column maximums are returned as a parameter. It is assumed that only the first n PE's are enabled at the time of the call. The ASK subroutine evaluates the function f(x) = x + 12 x + "J. Its REAL argument is passed in RGA and it returns its function value in RGA. k2 CREAL SUBROUTINE- ARR a YMAX ( C I NT ORUER.PREAL CnLUMN*AX)| PEGIN COMMON ArEAU PREaL VECTOR ARRAYC63]; CREAL VECTOR RnwMAX[63)J ENUCOMMONJ CI^T INDFX; * % CALCULATE ROW MAXIMUMS t LOUR iNDEXlaO.l.f nRUEH-1 ) "iO Rn^MAyC INDEX! l=MAXCABS(ARRAY[INoEX]))| % CALCULATE COLUMN MAXIMUMS 1 COLUMNMAyrsO.Oj lour Index j=o#i,(nROER-l ) no IF A8 S ( AKKAYt iNHtX] ) GTR cOLljMNMAX THEN COLUMNMAXtaABS( ARRAY! INDEX! )l ARKAYMAXt=MAX(COLllMNMAX); END. U3 ask function fqp r(X) i« x**3 ♦ i2.o*x ♦ 7.0 rsTARICENTHyli «FILL * LUP MLRN MLRN LOs L<> A LlT(l) mlrn aurn L I T C 1 ) ADRN STLC 3^ SA| SRI SRI SAI SRI ■12.0* sci 1 SSI ■7,01 Sri i SICRI kk * GLYKiMlK MaIN PROGRAM REGlN PRLAL X»YJ COMMON ArEAIj PREaL VECTOR ? f 6 3 } ; creal vector rowmax[63]l enucommonj CRLAL CX I external creal subroutine arraymax (clnt dimension. preal out columnmax); External preal surruutine f as rga (PREA(_ ARfi AS Rr,A) ENTRYaFSTART J CX»»ARrAyMAX(64,X) i Yl»F(X)> * ENO. APPENDIX C NOTES ON PASSING VECTORS AS PARAMETERS Vectors can be passed to external GLYPNIR subroutines in the same way that they are passed to internal subroutines. The following excerpt from Layman [k] describes this method: This final problem concerns the use of vectors in and as parameters for subroutines. There are two basic types of parameters- -"CALL BY VALUE" and "CALL BY NAME." In GLYPNIR the latter type is indicated by including "OUT" in the parameter specification. Actual parameters corresponding to CALL BY VALUE formal parameters may be any expression, including subscripted vectors. But subscripted vectors may not be used as CALL BY NAME parameters. To get the same effect as passing vectors "BY NAME" one can do as follows: a) For each vector quantity that you want to pass "BY NAME" include an output parameter of type POINTER in subroutine declaration (PC POINT for PE vectors, CNP0INT for CU vectors). b) When calling the SUBROUTINE, pass just the vector identifier in the place corresponding to the output POINTER quantities. c) Within the subroutine itself you may use the POINTER parameter just as though it had been declared as a vector. Example : BEGIN PE REAL VECTOR VI, V2 [5]; PE REAL X, Y; SUBROUTINE SUBB (PCPOINT OUT PI, PCPOINT OUT P2, PREAL A) BEGIN k6 PI [1] P2 [h] .5; A PI [1] P2 [k] • P2 Ik} PI [2] A; END; SUBB (VI, V2, X); END The compiler actually treats the quantities PI [1], P2 [k] etc. as if you had done the following: REAL FIELD R [0, FULL]; PCPOINT PI, P2; PI. [1] R P2. [h] R .5; etc. That is it treats them as special forms of field content designators. This short form may be used anywhere in GLYPNIR programs also. One final note, this trick only works for REAL vectors. UNCLASSIFIED Security Ctaaaification DOCUMENT CONTROL DATA -R&D (Security clef Ideation ol title, body ol abatrmct and Indonrng annotation muat be entered when the overall report la da filled I ORIGINATING AC Tl VI TV (Cotpormf author) ILLIAC IV Project University of Illinois at Urbana-Champaign Urbana, Illinois 6l801 2*. REPORT SECURITY CLASSIFICATION UNCLASSIFIED 2b. CROUP J REPORT TITLE SUBROUTINES IN THE GLYPNIR COMPILER 4. DESCRIPTIVE NOTE1 (Type ot report and Inelualre datea) Research Report 5 AUTHOR(S) (Firm! name, middle Initial. Imat name) David Michael Baer I. REPORT DATE January 15, 1972 7«. TOTAL NO. OF PACES 52 76. NO. OF REFS 5 M. CONTRACT OR CRANT NO. USAF 30(602)-l+lU b. PROJECT NO. ARPA Order 788 M. ORIGINATOR'S REPORT NUMBER(S) ILLIAC IV Document No. 257 9b. OTHER REPORT NOISI (Any other numbers that may be emmlgned thia report) 10. DISTRIBUTION STATEMENT Copies may be obtained from the address given in (l) above. II. SUPPLEMENTARY NOTES None 12. SPONSORING MILITARY ACTIVITY Rome Air Development Center Griffiss Air Force Base New York 13 ABSTRAC T The structure of separately compiled procedures in the GLYPNIR compiler and the use of storage areas common to separately compiled program units are described and, for the benefit of those who may wish to modify the compiler, a description is given of the current implementation of both internal and separately compiled subroutines. )D , f .r..1473 UNCLASSIFIED Security Classification UNCLASSIFIED Security Classification KEY WORDS Programming Compilers and Generators UNCLASSIFIED Security Classification I.IOGRAPHIC DATA HET 1. Report No. UIUCDCS-R-72-U95 3. Recipient's Accession No. itle and Subtitle JBROUTINES IN THE GLYPNIR COMPILER 5. Report Date January 15, 19 72 uthor(s) 8. Performing Organization Rept. No. erforming Organization Name and Address LLIAC IV Project aiversity of Illinois at Urb ana-Champaign rbana, Illinois 6l801 10. Project/Task/Work Unit No. 11. Contract/Grant No. USAF 30(602)UlUU Sponsoring Organization Name and Address Rome Air Development Center ariffiss AEB, NY 13. Type of Report & Period Covered Research 14. Supplementary Notes •Abstracts The structure of separately compiled procedures in the GLYPNIR compiler and the use of storage areas common to separately compiled program units are iescribed and, for the benefit of those who may wish to modify the compiler, 1 description is given of the current implementation of both internal and separ- ately -compiled subroutines. AKey Words and Document Analysis. 17a. Descriptors Programming Compilers and Generators J Identifiers/Open-Ended Terms COSATI Field/Group I Availability Statement )istribution unlimited. Copies may be obtained from the address given in (9 above . 19. Security Class (This Report) UNCLASSIFIED )20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 52 22. Price ( ,M NTIS-3S (10-70) USCOMM-DC 40329-P7! <\ # ^ JUL 2 6W73 UNIVERSITY OF ILLINOIS-URBANA 510.84 IL6R no. C002 no 493-498(1972 Tree height reduction lor parallel proce , 3 01 2 088400210 HP HSH -W* K» wSSBSSusSBi 1B WBHB Hra HH Hi H ■H riF4Sl ffl^^^l ■