Static andDynamic

Characteristicsof XPL Programs

W. Gregg AlexanderDavid B. Wortman

University of Toronto

Introduction

One use of performance measurement techniques is inthe study of operational characteristics of programs writtenin high-level programming languages. Information derivedfrom such studies can be used to construct benchmarkprograms and synthetic workloads,l 2 detect inefficienciesin programming language implementation, and suggestpossible improvements in the design of computers.3 9,i0Our main interest is in the latter area: the discovery ofprimitive operations, implied by the semantics of aprogramming language, that can be added to the firmwareor hardware of a computer to improve overall systemperformance. These computer architecture optimizationtechniques have been applied in several studies3 9 and havebeen used commercially to design efficient pseudomachines for the Burroughs B1700.10,1 2

This paper summarizes the results of a detailed studythat was made of the static (compile time) and dynamic(execution time) characteristics of programs written in thelanguage XPL.4 We studied a particular implementation ofXPL for the IBM System/360. The complete results of thestudy are described by Alexander.'

In the first part of this paper we discuss whatinformation is worth knowing about the usage charac-

November 1975

teristics of a programming language and then discuss someways of gathering this information. The second partdescribes some results from our study of XPL programs.

Data Collection

The effect of executing a program on a computer can bedescribed in terms of consumption of reusable (e.g.,registers and memory) and non-reusable (e.g., time andpaper) computer resources. In general, one tries tominimize the amount of resources consumed by theexecution of a program. Often the minimization process iscomplicated by interactions between the consumption ofvarious resources (e.g., a space-time tradeoff). What wewant to do is study the consumption of computer resourcesas a function of the programming language being used. Aperformance evaluation technique embodying these ideashas been presented elsewhere.3'6

To determine resource consumption we need to knowboth the static and dynamic usage of programming languageconstructs. The static usage can be related to resourceconsumption that is a function of the static program (e.g.,program size, register usage). The dynamic usage can beused to estimate the resource consumption that is afunction of the pattern of program execution (e.g., CPUtime, machine cycles, memory references).

41

Static Information

Static information about programs can be obtained bywriting a special source program analyzer7', or bymodifying an existing compiler for the language.5 In eithercase, the purpose is to gather information about the usageof programming language constructs that can be used todetermine resource consumption. Information that we havefound useful for this purpose includes

* distribution of constants by type and value;* distribution of variables by type, value, and point of

declaration (lexical nesting);* distribution of statements by type;* complexity of expressions and use of operators in

expressions;* distribution of machine instructions emitted by the

compiler (instruction pairs and triples may also beinteresting);

* distribution of registers, operand addresses, andconstants occurring in emitted instructions.

The data we gather characterizes a single implementationof the programming language, and this reflects on theabilities, constraints, and goals of the language implementa-tion team. Substantially different results might be obtainedif another implementation were examined. 14 1 5

Dynamic Information

The quantity and type of information that needs to begathered about the dynamic characteristics of programexecution depends very much on the purpose of themeasurements and on the cost one is willing to pay for theinformation. Often, easy-to-gather totals of resourceconsumption (e.g., total execution time, total memoryrequired) are sufficient. In the particular study describedhere, we wanted to gather much more detailed informationabout dynamic program behavior.

Our first approach was to modify the interpreterprovided by McKeeman et al.4 to suppress printing and toproduce a file containing information about eachinstruction that was executed. A second program waswritten to analyze the data produced by the interpreter.This process produced voluminous information aboutprogram execution (for example, the dynamic distributionof pairs and triples of executed instructions). Of course, itwas very expensive; the time to interpret a program andanalyze the data produced was, on average, two orders ofmagnitude greater than the time required to simply executethe program.

Another technique was investigated in an attempt toreduce the cost of gathering dynamic information. In XPL,as in most programming language implementations, thestructure of a program is determined when the- program iscompiled; variability during execution is a result ofbranching within the compiled code. The technique ofjump tracing takes advantage of this fact to allow dynamicprogram behavior to be studied more economically. Insteadof interpreting all the instructions in a program, only thebranches are interpreted. The compiler fQr the program-

42

ming language is modified so that the destination of eachbranch (a node) contains a call on a statistics tabulatingroutine. The compiler also tabulates information about thesequence of machine instructions following each node. As aprogram is executed the sequence of nodes visited isrecorded, and all instructions between nodes are executedat machine speed. A simple program can later re-establishthe relationship between nodes visited and instructionsexecuted. We tried both writing the complete node historyout on a file, and also simply counting the number of timeseach node was visited in an in-core array. This latterapproach was the most economical way to gather dataabout dynamic program behavior, although it did not allowus to investigate sequence dependent characteristics.

Characteristics of XPL Programs

In this section, we present a sample of the results of ourstudy of XPL programs. The 19 XPL programs we studiedincluded compilers written by undergraduate and graduatestudents as well as XCOM and ANALYZER, the twoprincipal components of the XPL system.4

Static Characteristics

Statement Distributions Since XCOM is a BNF-production oriented compiler, it was easy to installcounters to tabulate the distribution of statements in XPLprograms as shown in Table 1. Assignment statementspredominated, followed by conditional statements (IF-THEN) and the procedure CALL statement. If one weredesigning a computer specifically to execute XPL programs,one would obviously want to provide mechanisms forexecuting these high-frequency statements efficiently.

Table 1. Distribution of statements by type

Statement Type

ASSIGNMENT

DO.. .ENDDO VAR=E1 to E2; ... .ENDDO VAR=E1 to E2DO WHILE E; ...ENDDO CASE E;...END

CALL STATEMENT

IF... .THEN...IF... .THEN.. .ELSE...

DECLARE STATEMENT

RETURN STATEMENT

PROCEDURE DEFINITION

NULL STATEMENT

GO TO STATEMENT

Number Percentage

13735

336282356

563193

4299

26381630

2725

1114

889

585

365

42

102021

13

85

8

3

3

2

1

COMPUTE R

Expressions The syntactic definition of XPL used BNFgrammar rules to establish the precedence of operators inexpressions. As a result, the reduction of an expressiontypically involves many parse steps. For example, the stepsin the reduction of a number to an expression are shown inFigure 1. Our statistics showed that 72% of all productionsapplied during parsing were used to parse expressions. Ofthese, 61% were required solely to establish operatorprecedence and have no other semantic purpose. A simpletabulation of the usage of BNF rules during expressionparsing produced the distribution of operators inexpressions given in Table 2. The high percentage for theconcatenation operator comes from its use in formattingprinted output in XPL. Our set of sample XPL programscontained 15,969 operators in 21,078 expressions, yieldingan average of 0.76 operators per expression.

Operator

11+

Number

3672

2997

2715

= (equality) 2027

> 954

& 701

<expression>

<logical factor>

<logical secondary>

<logical primary>

<string expression>

<arithmetic expression>

<term>

<primary>

<constant>

<number>

Figure 1. Reduction of <number> to <expression>

-By analysis of the use of other productions in the XPLgrammar we were able to distinguish logical and arithmetic(including string) expressions. Arithmetic expressions(including expressions used with relational operators)contained on average 0.41 arithmetic operators. Logicalexpressions on average contained 0.28 logical operators and0.91 relational operators. Similar results have been obtainedby Knuth.7 The need for elaborate hardware optimizationsis not present. However, the relative frequency of theoperators gives an indication of which computer operationscould be optimized to gain execution time.

Numeric Constants A logarithmic tabulation of thenumeric constants appearing in the sample programsproduced the distribution in Table 3. It is interesting tonote that 56% of all numeric constants could berepresented using 4 bits, and 98% could be representedusing 12 bits or less. The high frequency of the constant 1

suggests that instructions for loading and adding theconstant 1 would be useful. An RR-type instruction thatloaded constants in the range 0-15 into a designated registerwould require half the space of the load address instruction

November 1975

-1<

5 0.0

1 *0.0

100.0

100.0

presently used for this purpose. It could be used to generate56% of all numeric constants in our sample programs.

No negative constants appear in Table 3, because theXPL compiler we studied did not include the optimizationof applying the unary minus operator to constants atcompile time. Many of the numeric constants greater than2**10 were, in fact, masks used to isolate fields in variouspacked data structures; within the XPL language numericconstants used in this way are indistinguishable fromconstants used for arithmetic. If field isolation were doneusing shift instructions, the percentage of numericconstants that could be represented in a small number ofbits would increase.

Dynamic Characteristics

Instruction Usage Using compile-time tabulation andinterpretive execution we were able to compute the staticand dynamic distribution of instructions used in 10 of oursample programs (we lacked suitable input data for running

43

Table 2. Distribution of operators in expressions

Percentage

23.0

18.8

17.0

12.7

6.0

4.4

CumulativePercentage

23.0

41.8

58.8

77.5

77.5

81.9

579

462

418

-(unary)

*

3.6

2.9

2.6

1.9

1.5

1.4

1.4

1.1

1.1

0.6

85.5

88.4

81.0

92.9

94.4

95.8

97.2

98.3

99.4

100.0

311

243

223

210

179

175

96

l

mod

<

Vumber)f bits Number

1 77621 84592 39523 29864 47475 46826 59087 47158 40379 137210 17411 3912 6113 13214 9215 5816 6117 118 1819 6820 7121 10222 11123 4024 7125 126 027 128 429 230 131 832 68

Percentage

15.617.07.96.09.59.4

11.99.58.12.80.30.10.10.30.2.0.10.10.00.00.10.10.20.20.10.10.00.00.00.00.00.00.00.1

CumulativePercentage

15.632.640.546.556.065.477.386.894.997.798.098.198.298.598.798.898.998.998.999.099.19,9.399.599.699.799.799.799.799.799.799.799.799.8+

+Cumulative percentage doesn't sum to 100.0 due to rounding andtruncation of data.

the other 9 programs). Tables 4a and 4b give the completeresults of this investigation. The 10 most frequentinstructions in the static and dynamic distributions aresummarized in Table Sa. Each column represents over 80%of the instructions in an average XPL program.

The most striking result from this table is the dominanceof the L(load) instruction; one out of every four compiledor executed instructions is a load. The reasons for the highfrequency of load instructions are the branching mechanismused by the XPL implementation4 and the architecture ofthe IBM System/360. Branches with a destination beyondthe first 4095 bytes of program are preceded by a loadinstruction that fetches an appropriate address constant. Wecalculated that 87% of all branches are preceded by loadsand that the space for these load instructions representsabout 15% of the total size of the XPL programs. Thisresult together with the distribution of branch distancesindicates that branching relative to the current locationcounter rather than relative to a fixed address in a baseregister would reduce XPL program *size and increaseexecution time by eliminating many load instructions.

The BC (branch and condition) and ST (store)instructions change places in the static and dynamic listsbecause the BC is used in heavily executed constructs likeDO loops and IF statements. The high frequency for the SR(subtract register) comes not from its use in generating the

44

Instruction

LSTBCLASRBALSLLICC

ASTCLHS

LRBCRBALRARSRLSTHNORLTREXTMCRCLCSRAXRSRDA0

DNRx

M

LCRALRSLRMRBCTRALDRSLLMLPRMVC

01CLRTRT

Table 4a. Static instruction usage

CumulativeNumber Percentage Percentage

2556113400892662585230474832132873259021242120158113281284112210368747487046453082932602532452402402401421371321321075957555545302020181010101091

28.615.010.07.05.85.33.63.22.92.42.41.81.51.41.31.21.00.80.80.70.30.30.30.30.30.30.30.30.20.20.10.10.10.10.10.10.10.10.00.00.00.00.00.00.00.00.00.0

28.643.653.660.666.471.775.378.581.483.886.288.089.590.992.293.494.495.296.096.797.097.397.697.998.298.598.899.199.399.599.699.799.899.9100.0100.1100.2100.3100.3100.3100.3100.3100.3100.3100.3100.3100.3100.3

constant zero, but rather from the necessity of clearing a

register before loading a byte value (c.f., the high frequencyof the SR IC pair in Table 5b). A considerable reduction inXPL program size could be obtained by adding a singleSystem/360 instruction that clears a register and loads abyte value.We also studied pairs and triples of instructions, as

shown in Tables Sb and Sc. For the instructionsequence ... L ST L BC . . ., for example, each of L ST,

COMPUTER

Table 3. Distribution of numeric constants

Range A(Logarithmic) a

ZERO[2**0 - 2**1)[2**1 - 2**2)[2**2 - 2**3)[2**3 - 2**4)[2**4 - 2**5)[2**5 - 2**6)[2**6 - 2**7)[2**7 - 2**8)[2**8 - 2**9)[2**9 - 2**10)[2**10 - 2**11)[2**1 1 - 2**12)[2**12 - 2**13)[2**13 - 2**14)[2**14 - 2**15)[2**15 - 2**16)(2**16 - 2**17)[2**17 - 2**18)(2**18 - 2**19)[2**19 - 2**20)(2**20 - 2**21)(2**21 - 2**22)[2**22 - 2**23)[2**23 - 2**24)[2**24 - 2**25)[2**25 - 2**26)[2**26 - 2**27)[2**27 - 2**28)[2**28 - 2**29)[2**29 - 2**30)[2**30 - 2**31)[2**31 - 2**32)

Table 4b. Dynamic instruction usage

Instruction NumberCumulative

Percentage PercentageLSTBCLASRBALSLLICCA

29%15107654332

LBCSTCLASRICASLLN

27%14106654433

a) 10 most frequent instructions.

STA TIC

LBCSTLBALLSTLASRIC

10.3%7.26.55.23.73.73.12.82.72.7

LBCSTSRCBCALLASLL

BCLLICLLASTSRLL

b) 10 most frequent instruction pairs.

STATIC

L BCL STST LST LL BALL SRST LAC LST SRL BC

L

L

BALSTLICSTBCSTLA

4.8%3.43.32.92.82.32.02.01.81.4

L

L

AL

NL

ABCL

BC

SLLSRSTBCLASTLC

LA

c) 10 most frequent instruction triples

ST L, L BC would be counted as one pair. Many of thehigh-frequency triples can be directly related to specificXPL constructs. For example:* L SLL L is generated by array subscripts of the form

A(I);* LA ST results from an assignment of a constant to a

scalar variable;* L A ST and A ST C are from the increment and test

sequence at the head of a DO loop.November 1975

Each of the high-frequency pairs and triples is a

potential candidate for becoming a single instruction in an

improved computer organization. Thirty of the 45 distinctinstructions emitted by the XPL compiler had fewer thanfour different instructions as possible successors. Arithme-tic and comparison instructions all fell into this category.These instructions therefore contain more information thanjust their own function, since they also constrain thepossible instructions that might be executed next. Fosterand Gonterl 1 and Hehner9 have suggested techniques forusing information on possible instruction successors toimprove the design of computers.

45

STA TIC DYNAMIC

LBCSTCLASRICASLLNBCRLRSTCBALLHARSRLLTRCRALSOREXNRMVCTMSTHBCTRSRAXRDRLPR0CLCBALRALRSLRSRDADxMRMSLLCRTRT01LM

DYNAMIC

2453544123041788503255904054451240297936548733016828091324007519192017543012954312772312704912033691836905796657466459610955446553661494324770738992386793690931055310552425512518657057975305425942593332332131841193324238171157100

27.313.79.86.26.14.54.13.73.12.72.11.91.41.41.41.31.01.00.70.70.70.60.60.50.50.40.40.40.30.30.30.20.10.10.10.00.00.00.00.00.00.00.00.00.00.00.0

STLLBCLBALLASTLSR

27.341.050.857.063.167.671.775.478.581.283.385.286.688.089.490.791.792.793.494.194.895.496.096.597.097.497.898.298.598.899.199.399.499.599.699.699.699.699.699.699.699.699.699.699.699.699.6

12.4%8.55.73.83.63.33.33.23.12.9

DYNAMIC

LICLLABCSTCLLAA

2.0%2.02.01.91.91.91.91.81.61.5

Table 5. Instruction distributions

Branches An analysis of compiled and executed branchinstructions showed that 55% of the executed branches and36% of the compiled branches were unconditional. Thedistribution of branch distances is given in Table 6. It isinteresting to note that over half the branches were nomore than 128 bytes from the location of the branchinstruction. This result of course also depends on thecompactness of the code emitted by the XPL compiler.This observation suggests that a high-speed instruction stackwith 128 entries would significantly speed up the executionof XPL programs. If the other instruction space reducingoptimizations we have suggested were also applied, the sizeof such a stack could be reduced.

Conclusions

The study of computer resource usage as a function ofthe programming language being executed leads to manyuseful insights that can be of beriefit to programminglanguage implementors and computer designers. Thejump-trace technique described in the first part of thispaper provides a means for collecting the necessary data.The examples in the second half of the paper illustrate thetype of information that can be easily gathered. This typeof data provides the information required to optimize thedesign of a computer for the execution of programs in aparticular language. .

Table 6. Distribution of branch distances

Distance(Logarithmic)

[2**2 - 2**3)[2**3 - 2**4)[2**4 - 2**5)[2**5 - 2**6)[2**6 - 2**7)[2**7 - 2**8)[2**8 - 2**9)[2**9 - 2**10)[2**10- 2**11)[2**11 - 2**12)[2**12 - 2**13)[2**13 - 2**14)[2**14- 2**15)[2**15 - 2**16)[2**16 - 2**17)[2**17 - 2**18)[2**18- 2**19)

Frequency CumulativeNumber Percentage Percentage

250271465601287981351481201297033174094409045045235397221161046123919432054

5741180

2.414.212.513.111.76.87.24.04.93.42.1

10.23.83.10.10.00.0

2.917.129.642.754.461.268.472.477.380.782.993.096.899.9

100.0100.0100.0

Gregg Alexander is a member of the staff of theDepartment of the Environment at Dorval,Canada, where he is currently working onnumerical weather prediction research. He

J53j Xeceived a B.Sc. degree in mathematics and an

M.Sc. degree in coinputer science, both fromthe University of Toronto, in 1970 and 1971.

References1. K. Sreenivasan and A. J. Kleinman, "On the Construction of a

Representative Synthetic Workload," CACM, Vol. 17, No. 3,March 1974.

2. E. 0. Joslin, "Application Benchmarks: The Key to MeaningfulComputer Evaluation," Proceedings of the ACM NationalConference, 1965.

3. D. B. Wortman, A Study of Language Directed ComputerDesign, Ph.D. thesis, Computer Science Department, StanfordUniversity, 1972.

4. W. M. McKeeman, J. J. Horning, and D. B. Wortman, ACompiler Generator, Prentice-Hall, 1970.

5. W. G. Alexander, How a Programming Language is Used, M.Sc.thesis, Department of Computer Science, University ofToronto, 1972.

6. D. B. Wortman, "Language Directed Computer PerformanceEvaluation," Proceedings of the ACM National Conference,1974.

7. D. E. Knuth, An Empirical Study of Fortran Programs,Software-Practice and Experience, Wiley Interscience, 1971.

David B. Wortman is an associate professor inthe Department of Computer Science at theUniversity of Toronto, and is also a member ofthe Computer Systems Research Group. Hereceived his M.S. and Ph.D. degrees in computerscience from Stanford University in 1968 and1972 respectively. His current research interestsinclude language directed computer design andthe implementation of student-oriented pro-

1 gramming languages on minicomputers.

8. D. H. Ignalls, "FETE - A Fortran Execution Time Estimator,"Report STAN-CS-71-204, Stanford University, 1971.

9. E. C. R. Hehner, Matching Program and Data Representationsto a Computing Environment, Ph.D. thesis, Department ofComputer Science, University of Toronto, 1974.

10. W. T. Wilner, "Design of the B 1700," Proceedings, Fall JointComputer Conference, AFIPS, 1972.

11. C. C. Foster and R. H. Gonter, "Conditional Interpretation ofOperation Codes," IEEE-TC, Vol. C-20, No. 1, January 1971.

12. Burroughs Corporation, "B1700 Cobol/RPG-S-Language,"Small Systems Technical Newsletter, Form 1058823-015,December 1973.

13. E. C. Russell and G. Estrin, "Measurement Based AutomaticAnalysis of FORTRAN Programs," Proceedings, Spring JointComputer Conference, AFIPS, 1969.

14. B. A. Wichmann, Algol 60 Compilation and Assessment,Academic Press, London, 1974.

15. D. B. Wortman, P. J. Khaiat, and D. M. Lasker, "Six PL/ICompilers," Technical Report CSRG-36, Computer SystemsResearch Group, University of Toronto, November 1974.

46 COMPUTE R