NBS TECHNICAL NOTE 763

A Set of Debugging

and Monitoring Facilities

to Improve the

Diagnostic Capabilities

of a Compiler
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards1 was established by an act of Congress March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and

technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides: (1) a basis for the Nation's physical measure- ment system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau consists of the Institute for Basic Standards, the Institute for Materials Research, the Institute for Applied Technology, the Center for Computer Sciences and

Technology, and the Office for Information Programs. THE INSTITUTE FOR BASIC STANDARDS provides the central basis within the United States of a complete and consistent system of physical measurement; coordinates

that system with measurement systems of other nations; and furnishes essential services leading to accurate and uniform physical measurements throughout the Nation's scientific community, industry, and commerce. The Institute consists of a Center for Radiation Research, an Office of Measurement Services and the following divisions: Applied Mathematics — Electricity — Mechanics — Heat — Optical Physics —

Linac Radiation - — Nuclear Radiation - — Applied Radiation - — Quantum

Electronics :l — Electromagnetics ; — Time and Frequency :l — Laboratory

Astrophysics ; — Cryogenics 3

. THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research lead- ing to improved methods of measurement, standards, and data on the properties of

well-characterized materials needed by industry, commerce, educational institutions, and

Government; provides advisory and research services to other Government agencies; and develops, produces, and distributes standard reference materials. The Institute consists of the Office of Standard Reference Materials and the following divisions: Analytical Chemistry—Polymers—Metallurgy—Inorganic Materials—Reactor

Radiation—Physical Chemistry.

THE INSTITUTE FOR APPLIED TECHNOLOGY provides technical services to pro mote the use of available technology and to facilitate technological innovation in industry and Government; cooperates with public and private organizations leading to the development of technological standards (including mandatory safety standards), codes and methods of test; and provides technical advice and services to Government agencies upon request. The Institute also monitors NBS engineering standards activities and

provides liaison between NBS and national and international engineering standards

bodies. The Institute consists of a Center for Building Technology and the following

divisions and offices: Engineering and Product Standards—Weights and Measures—Invention and

Innovation—Product Evaluation Technology—Electronic Technology—Technical Analysis—Measurement Engineering—Building Standards and Code Services4—Housing Technology 1 —Federal Building Technology4—Structures, Materials and Life Safety 4—Building Environment4—Technical Evaluation and

Application4—Fire Technology.

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts re- search and provides technical services designed to aid Government agencies in improving cost effectiveness in the conduct of their programs through the selection, acquisition, and effective utilization of automatic data processing equipment; and serves as the principal focus within the executive branch for the development of Federal standards for automatic data processing equipment, techniques, and computer languages. The Center

consists of the following offices and divisions: Information Processing Standards—Computer Information—Computer Services —Systems Development—Information Processing Technology.

THE OFFICE FOR INFORMATION PROGRAMS promotes optimum dissemination and accessibility of scientific information generated within NBS and other agencies of

the Federal Government; promotes the development of the National Standard Reference Data System and a system of information analysis centers dealing with the broader

aspects of the National Measurement System; provides appropriate services to ensure

that the NBS staff has optimum accessibility to the scientific information of the world, and directs the public information activities of the Bureau. The Office consists of the following organizational units: Office of Standard Reference Data—Office of Technical Information and

Publications—Library—Office of International Relations.

1 Headquarters and Laboratories at Gaithersburg, Maryland, unless otherwise noted; mailing address Washington, D.C. 20234.

2 Part of the Center for Radiation Research.

2 Located at Boulder, Colorado S0302.

4 Part of the Center for Building Technology.
A Set of Debugging and Monitoring Facilities to

Improve the Diagnostic Capabilities of a Compiler

Elizabeth Fons

Systems Development Division

Institute for Computer Sciences and Technology

National Bureau of Standards Washington, D.C. 20234

NBS Technical Notes are designed to supplement the Bureau's regular publications program. They provide a means for making available scientific data that are of

transient for limited interest. Technical Notes may be

listed or referred to in the open literature.

U.S. DEPARTMENT OF COMMERCE, Frederick B. Dent, Secretary

NATIONAL BUREAU OF STANDARDS, Richard W. Roberts, Director

Issued March 1973
National Bureau of Standards Technical Note 763

Nat. Bur. Stand. (U.S.), Tech. Note 763, 25 pages (Mar. 1973) CODEN: NBTNAE

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402.

Price $0.50 domestic postpaid or $0.35 G.P.O. Bookstore.
CONTENTS

Page

1. Introduction 1

2. Scope and Sources 2

3. Descriptions of Debugging and Monitoring Facilities .... 3 3.1 Compile Time Checks 3 3.1.1 Syntax Checking 3 3.1.2 Static Concordance of Variables and Labels ... 4 3.1.3 Language Flagging Features 4 3.1.4 Logical Segmentation of Programs 5 3.1.5 Static Control Structure Concordance 5 3.2 Link/Load Time Checks 5 3.2.1 Formal and Actual Argument Checks 6 3.2.2 Static Subroutine Structure Analysis 6

3 .

3

Execution Time Checks 6 3.3.1 Dynamic Trace of Subroutine Calls 7 3.3.2 Backward Trace of Subroutine Calls Upon Error

Termination 7 3.3.3 Variable Trace 7 3.3.4 Snapshot 7 3.3.5 Flow Trace 7 3.3.6 Array Bounds Checking 7 3.3.7 Effective Address Check 8 3.3.8 Value of the Control Variable Upon Exit .... 8 3.3.9 GOTO Checks 8 3.3.10 Truncation Error Warning 8

4. Conclusions 9

5. References 20

in

A SET OF DEBUGGING AND MONITORING FACILITIES TO IMPROVE THE

DIAGNOSTIC CAPABILITIES OF A COMPILER

Elizabeth Fong

Increasing concern with the quality of computer soft- ware today makes it important to evaluate critically the

debugging facilities available in high-level languages.

This paper presents a collection of program debugging and

monitoring facilities to improve the diagnostic capabilities

of a compiler. A distinction is made between debugging and

monitoring facilities performed at compile time, at link/

load time and at execution time. These facilities are described in terms of this breakdown with a conscious attempt to move the detection of errors from execution time

to compile or link/load time, and to collect information

when the information is available during the compilation

process

.

Key words: Compiler; debugging; error diagnostic; highlevel programming languages; monitoring; procedural-oriented

languages

.

1. INTRODUCTION

Software production requires large amounts of both human and machine

resources. The recent trend has been towards a more systematic development of software and in particular towards producing "quality" soft- ware that is effective and maintainable. During the program development

stage, most of the programmer's effort is spent in debugging. Program

debugging is still a very uncertain process. Professionals do not agree on how to get the bugs out of a program systematically, or how to con- struct the most reliable program. Tools, both automated and manual,

exist but surprisingly, much of the work in this field has been described only in unpublished reports or passed on through oral tradition.

Interest in debugging techniques has .-been aroused recently, and a collection of papers devoted to the topics of debugging -jand maintenance of

large software systems can be found in Reference [1].

The programming activity is rooted in the traditional environment,

that is, writing the program in a high-level programming language, such

as FORTRAN, ALGOL, COBOL, or PL/1 with the usual compile-link/ load-go

situation. To aid the programmers in the stage of program development,

it is advantageous to build debugging aids and monitoring features into a high-level programming language system.

This paper presents a collection of program debugging and monitoring

facilities to improve the diagnostic capabilities of a compiler. A distinction is made between debugging and monitoring facilities performed

1Figures in brackets indicate the literature reference at the end of

this paper.
at compile time, at link/ load time and at execution time. These facilities are described in terms of this breakdown with a conscious attempt:

to move, as much as possible, the detection of errors from execu- tion time to compile or link/load time in order to avoid overhead

in an executing program, and

to collect information when the information is available during

the compilation process. At the user's option, this information

could be output at a later time.

2. SCOPE AND SOURCES

Many programmers think of debugging aids as "dumps" (the display of

the contents of storage cells) and "traces" (the display of the control

flow during execution). However, these basic tools have become considerably more sophisticated over the years. In particular, very powerful

debugging faciliti.es have been built for the on-line interactive environment [2,3] giving the user a high-level language with which to control

the setting of breakpoints and to allow interrogation of individual

storage cells.

The universities in teaching programming to students, have found

that they need an extensive set of debugging facilities. "Forgiving"

compilers have emerged. These include not only error detection but

error correction features as well. Examples include Cornell Computing

Language (CORC) [4], Waterloo FORTRAN (WATFOR and WATFIV) [5], and

Purdue Fast FORTRAN Translator (PUFFT) [6].

Program monitors are another programming aid. These can be viewed

as a logical extension of the debugging aids described above. A program monitor is a program built to measure the behavior of another program. In general, the program monitors that are available commercially

operate in two phases: data gathering and data presentation.

The idea of combining debugging and monitoring facilities as an

augmentation to high-level languages has been attempted in the EXDAMS

Project [7]. Both static and dynamic displays may be exhibited at the

request of the programmer.

Dijxstra's notion of structured programming [8], and Wirth's concept

of program development as the process of successive refinement [9] are

attempts to move programming from a private art to a new level of precision. The essential ingredient in achieving a correct final program

quickly seems to lie in the area called "good" programming practices.

Examples of "good" programming practice include the exhibition of

structured readable source statement as output, planting special checks

and messages for the use of undeclared variables, and elimination of

wild GOTO transfers, etc. Some of these ingredients could be implemented

on a compiler.
3. DESCRIPTIONS OF DEBUGGING AND MONITORING FACILITIES

In a compiler environment, the program text is coded,- keypunched and

fed into a compiler which produces object code. The object code and a system library are link-edited and loaded by a link/loader which produces

absolute code ready to be executed. (see Figure 1). Three distinct

times can be identified at which debugging and monitoring can occur: compile time, link/ load time, and execution. Each individual type of

check is described in terms of this breakdown.

Language

System

Library

Program

in Source

Language

COMPILER

Program

in Object

Code

I

Data

LINK/ LOADER

Program

in Absolute Code

EXECUTION

Output

Figure 1

Debugging and monitoring features described below are categorized

according to these stages. Some features may occur either at compile

time or link- load time depending on the implementation. This three-part

breakdown hypothesizes that the earlier an error is caught, the easier

it is to deal with. Therefore, any tool or technique that moves detection of certain errors from execution time to compile time is valuable.

This breakdown does not apply to the interpretive environment.

3.1 Compile Time Checks

The types of checks performed by the compiler are usually referred to

as static checks because the problems they address are invariant with

execution time and independent of the values of the input data. The following are descriptions of some program debugging and monitoring facilities that could be performed at compile time.

3.1.1 Syntax Checking. One of the first tasks done by a compiler is

to scan the source program statements. Every high-level language has its own established set of syntax rules. Error

situations occur when the compiler cannot translate a source

statement, or the process of syntax-directed parsing is blocked.
Examples of syntax errors include misspelling of reserve words,

punctuation errors such as unmatched parentheses, missing

operators , illegal sequences of operators in expressions , or

missing statement labels. In a class of university-developed

compilers (e.g., CORC, PUFFT, WATFOR) with "forgiving"

features built in, extensive syntax checking is done. These

compilers also do some error-correction during source language

scanning. For example, CORC attempts to define various categories of misspelling and always tries to repair the error and

continue to compile executable code. All compilers have syntax

checking facilities, however the extent of checking varies.

3.1.2 Static Concordance of Variables and Labels . At compile time

,

all the variables and labels are entered into a symbol table or an intermediate file. This information could be made

available during compile time to produce one of the most beneficial aids to debugging. This facility is sometimes called a

cross reference listing. The usual format consists of the

symbolic name followed by the concordance of the line numbers

where the variable is being defined and the line numbers where

this variable is being referenced. Some compilers also print

out data type and relocation information. An example appeared

in Figure 2. In this case, the statement label concordance

appeared as a separate listing. The advantages of such a facility would be to detect a variable or a label being defined

but never referenced or vise versa. For a block-oriented

language such as ALGOL 60 or PL/1, the variables and labels

may be declared as local within a block. Exhibiting a static

concordance of variables and labels plus their scope of

definition would aid debugging. Most of the compilers provide

this facility. There are also programming support packages

available which can generate such a concordance.

3>1 - 3 language Flagging Features . Due to historical development,

most programming languages (e.g., FORTRAN) have undergone modifications and upgrading (e.g., FORTRAN II, Basic FORTRAN,

FORTRAN IV, and extended FORTRAN). Moreover, each implemen- tation of the language may contain differences. Flagging can be done during the source language scanning phase to detect

language syntactic features which deviate from some "standard"

definition such as ASA FORTRAN [10], or additional features

from the previous versions. A message could be printed out

by the compiler as a warning to the user that the particular

feature is unique to this version of the compiler. Very few

compilers have this flagging facility. An idea closely re- lated to this can be found in a COBOL compiler which prints

the message: "REDEF Name feature not the same as previously

defined version". (See Figure 3). It is possible to determine the language feature differences by compiling ±he prev- iously compiled program with the new compiler, however, the
point here is to detect deviations specifically against a

"standard" language definition, or to be able to identify a subset of the language that existed earlier. To make a

full semantic check of a program is not possible.

3.1.4 Logical Segmentation of Programs . A large program may be

considered as consisting of small logical segments. This

permits a modular organization. Modularity aids debugging

because it breaks up the program into manageable sized pieces.

In ALGOL, there are BEGIN-END statements which create a logical segment. In COBOL, a paragraph or a section also is con- sidered to be a logical segment. A formatting facility could

be built into the compiler which would cause more readable

source program statements to be printed out. Examples are.: alignment of BEGINs with corresponding ENDs with nested inner

blocks properly indented; hierarchical data declaration in

COBOL or PL/1 are properly indented to reflect structures even when the input is not punched in the proper column; or

reordering of source statements in order to group declaration

statements, executable statements, and format statements.

Figure 4 shows an example of an ALGOL program printout with

block number and level number generated by the compiler to

reflect logical segments. This facility, although not a debugging feature in the sense that it helps to uncover errors,

could greatly add to the readability of a program. Producing

readable documentation also helps another person in maintaining the program.

3.1.5 Static Control Structure Concordance . The normal flow of con- trol xn a program is sequential. However, control may be

transferred elsewhere in the program by a transfer of control

command, e.g., GOTO, RETURN. A topological structure diagram

showine everv transfer of control at the request of the user would aid debugging. Figure 5 contains such a static control

structure printout, showing that a transfer of control is

occurring at line number n to line number m. Some compilers

do not provide a total topological control structure trace

but merely print out messages such as "Control can never

reach the next statement" or "There is no path to this statement" (See Figure 6 and 7).

3.2 Link/ Load Time Checks

In most batch-oriented installations, compilation produces a binary

program file, usually stored on direct access storage. Subprograms and

the main program are compiled separately and bound together by the link/

loader which associates external references and adjusts addresses. If an external reference is to a system library routine, it link/loads this

routine. The information available at this point enables the system to

perform the following type of debugging or monitoring checks:
3.2.1 Formal and Actual Argument Checks . A subroutine or function

declaration consists of the name of the subroutine or function followed by a list of actual parameters.

For a programming language such as ASA Standard FORTRAN,

the definition of the language specifies that the actual

arguments must agree in order, number and type with the

corresponding formal arguments. A check on all three items

would insure that the program is adhering to a "standard".

In order to perform checks at link/load time, it is necessary

to carry more information than the usual external symbol

definition, for example, the list of formal argument names and their data types, the corresponding actual argument

names and their data types. The advantages of performing the

checks at link/ load time rather than execution time is that

the check would be done only once, rather than each time

the subprogram is executed. The tests that could be performed

include the following:

a) If the subroutine or function does contain a non-standard

return, test that the return label is indeed a label.

b) In the case of FORTRAN, if one of the arguments of the

subroutine or function is a subroutine name or a function

name, the compiler could check to determine if the name

is being declared as an external procedure.

c) Some implementations of FORTRAN compilers allow the num- ber of formal arguments to differ from the number of

actual arguments. If the standard language definition,

e.g. , ASA FORTRAN standard, calls for a match in the number, the check might insure that the program is adhering

to the appropriate standard.

3.2.2 Static Subroutine Structure Analysis . The static information

about subroutine structure consists of caller and call<2e re- lationship derived from the program text. In most languages,

this caller-callee relationship is invariant at execution

time. This information is available at link/ load time and

usually contained in the external symbol definition table.

The link/ loader could optionally produce a concordance of

the source language subprogram caller/callee names. An ex- ample of the "CALL" concordance (Figure 8) and "CALLED-BY"

concordance (Figure 9) was developed at NBS on the UNIVAC

1108 computer.

3 . 3 Execution Time Checks

_ Dynamic information about the actual running of the program is obtainable at this time. To embed tests, the compiler usually inserts
code at appropriate points to be executed in conjunction with the

worker program. Every test introduce 1 will decrease the running effi^

ciency of the worker program and it is necessary to exercise care when

deciding what to measure and where to embed tests. Attention also has

to be given to where the tests are to be inserted to assure uniform

checks

.

3.3.1 Dynamic Trace of Subroutine Calls . Actual subroutine paths

could be traced at execution time. This information not only

aids in debugging but is very useful for program activity

analysis. LEAP (Lambda Efficiency Analysis Program) [11], a software monitor, contains a special section to perform

subroutine structure analysis. A tree-like diagram of the

paths through the hierarchy of subprogram calls from the main

program allows the user to identify the most significant

call chains. Figure 10 shows a portion of a dynamic subroutine trace developed at NBS for the UNIVAC 1108. It con- sists of ten subroutines with its call chain properly reflected by the indented printout.

3.3.2 Backward Trace of Subroutine Calls Upon Error Termination . Upon error termination, an identification of where the error occurred plus a backward trace of the subroutine calls aids

debugging. Figure 11 shows an example of backward trace of

subroutine calls when the program terminated with an error. This example is generated on the UNIVAC 1108 FORTRAN compiler.

This compiler uses an extra word in the calling sequence to

store the "walk-back" or the backward reference to permit

this kind of backward trace.

3.3.3 Variable Trace . This is a dynamic display of the specified

variable and its content at each instant in time. The display

usually occurs as an instruction by instruction accounting of

information or at every instance of a value change. It is

not only useful for debugging, but also useful in spotting

the value changes of certain variables for program analysis.

3.3.4 Snapshot . This is similar to the variable trace except that

the variables and their values are recorded periodically on entering or exiting certain regions of the program.

3.3.5 Flow Trace . This is the dynamic display of every branchpoint

of a running program. The trace records the decision points

and exhibits the branches taken.

3.3.6 Array Bounds Checking . This checking is sometimes built into a computer as a precaution against altering of values incorrectly. The value of the subscript is tested to determine if

it is within the specified dimension of the array element,

and if it is also an integer constant. The check is useful in

monitoring array elements and spotting the activity level of

various parts of the table.

7
3.3.7 Effective Address Check . This is a feature provided for mem- ory protection. Bounds registers are set to certain permitted

address ranges and every effective address value is checked

against these bound registers. In some cases, it is implemented as a hardware feature to avoid system overhead. This

feature is especially important in a multiprogramming environment.

3.3.8 Value of the Control Variable Upon Exit . In an iteration loop

such as FORTRAN-DO or ALGOL-FOR, the value of the control

variable upon exit is undefined if the exit is due to exhaustion of the loop, otherwise it is the same as it was immediately preceding the execution of the exit condition. The

undefined situation is handled by implementors in different

ways. Some compilers even try to "guess" what the user intended. The trouble starts when programmers make use of these

undefined situations on a particular implementation of the

compiler, and later discover that the same program does not

work correctly on a different implementation. Debugging this

type of error is very difficult because it involves an understanding of the semantics of different compiler implementation

of undefined situations. One of the debugging facilities for

this particular undefined situation could be to report all

later use of the control variable or intentionally set the

value of the control variable to "undefined" (minus zero or

some such number) when the exit of the loop is due to exhaustion of the loop.

3.3.9 GOTO Checks . Recently, there has been considerable interest

ui eliminating the GOTO statement [12, 13]. Dijkstra claims

the use of GOTO statements is undesirable, and avoiding it

would increase the readability and proveability of the program.

When GOTO cannot be avoided, and when label variables are allowed e.g. FL/1, the following kinds of checks could be performed by the compiler:

(a) Flag error if the transfer is made to itself or to a nonexecutable statement.

(b) Flag error if the transfer label value is negative or

undefined.

(c) Flag error if the transfer label value is outside of the

user's assigned program space.

(d) Flag warning if the transfer label goes within an iteration loop.

3.3.10 Truncation Error Warning. On an arithmetic or MOVE-data

operation, some bits may be dropped due to computer wordlength. Overflow to the left or to the right of the computer

word is called truncation error. If such overflow is sus-
pected or detected, a warning would be printed by the compiler.

4. CONCLUSIONS

Increasing concern with the quality of computer software today makes

it important to evaluate critically the debugging facilities available

in high-level languages. The debugging and monitoring aids described

above are particularly useful during early implementation and initial

system integration stages. They could be automated by embedding these

checks at appropriate points in the compilation-execution process when

all the needed information is available.

The list of features is not geared to any particular high-level programming language; however, some of the features described are applicable

only to particular language constructs. Techniques of implementation

and the question of how to invoke and suppress these debugging and monitoring facilities have not been addressed here.

Commercially available compilers usually provide some debugging facilities; however, certain trade-off decisions are made which usually sacrifice the extent of providing debugging aids in favor of efficiency of

the compiler. Such a list might prove to be useful as an evaluation

criteria in determining the capabilities of a compiler.

These debugging and monitoring facilities described above could be

automated to aid programmers during program development stage. Certain

bugs are very much problem and situation dependent. Such bugs are difficult even to anticipate. For instance, it would be in general impossible for the compiler to isolate a sequence of code and determine

that it is a non-terminating loop. There also exists a whole class of

"Timing Bugs" which, when certain combination of situation occurs, the

program behaves abnormally.

The problems in the area of debugging and monitoring are many: The

question of how much to output, what should be outputted, how to recover from error conditions, what should be the default situation, etc. All

of these questions are still open and the decisions are usually left

with the implementor.

There are other automated testing techniques for validating purposes,

but they are beyond the scope of this paper. Such techniques include

benchmark tests, exhaustive exercising of the program with different input data, and proof of correctness using formal logic, etc. Testing

methods for validation purposes are very different from those mentioned

here, which are limited to debugging and monitoring aids for program

development purposes.

The author would like to thank Mrs. Frances E. Holberton for giving

her very valuable suggestions. The author also wishes to acknowledge Dr. Rona Stillman for reading the paper. Dr. Selden Stewart and Mr. Justin

Walker provided some of the computer examples.
=0 CO '.O N. ^ w a

(T1 O CM «-4 (A tf> C

fO if* iTi ^D \D %D N- •HtMroroj-uDr-r-.cOCT'

iD CJ> J" f- c? tr to s

ro -* txi h- ire wh joi

(T cr fu w in s i to .$ IT* *0 \D i£> I

VD^^nOMcyJ, Mf"w

C^J-rotTeo-^pnt^infC\J{\J rOCT, OCT, CT1 C\leOC3lf\THLA»i>'C

oroir>roN.c7, (\.N--Hco(\j«;vD CT«3fMvO<Ts «3<r,HJ-J'f^Lr>(T MJvflSOMJlPlTvClvDStOlooin^ffiMiUco

iCTKCTCT'vDcairiir* iMJlTiDNffl^O

ra r~i r^ n O o

iii J- .* iO t.0 <D vl 1 m j- a- m CT1 <M in z z 11 2 z <; z in J- t- £ r^ X E

-* S IA

JCO N. ioo^iirci>l>ori-}

a o o a a

in a l_ 3\ftjtT, ^inrJ VDeONUJUIO, NWNCPJiDI

, r-"u'Mre*rinJ, »DJffZa:^<C(Cinj«l^(

u. o

Ll. v. a i-i

! JlTiOSMro

*iniriif'iriinir'iriiriirjo(js jiDifiD«pw«)woMjcor\jMDj(?iD^aoo\DH

* Snj\DSNWJinL1*Dii)NKN T->l\<K>J'ini£iN-N-C7> C2

U_U_U.L^U_Lj.U.I^Li.lJ-ZLLa^^«2oa(\iC\JiI5f,Ocoij.2in'£, r^oa, t\J-JsOCT1 C\j lUUJUJUJLJliJULULiJliJ^ljJ^ir^^i^JiniA^\D^^LUVH^C\jrOJ, J-»X)f^N.eOO aaacrcraaaaaiLQ; u. a: u. »h

JOOOOOOOOOl LJ UJ

LU UJ

BfflOOCCDOCTCM

U-OXi-hT^_i3: 20 I/IOOOOOCJOOOO o >

UJ 3

10
ccocccccc ccccccccc

c cr c

L b b U L

K - If vf r L b L. L> U

> > > i > > : > > c wwwwCCCCCOCCCCCCC cccccccccocccccro

.- c V c

r, ~- —

>

c u c 3

LbbbbbbbUUbD t CO C

i O C t C C i

t- K V k

D C C t, C G £

& U C Cr o r c 1 1 u a. u.i cr a L U or. u L. L L a c tr ui d er & UJ & & 5>" &

r _ i mr r i CO "

t- h i y t- i £ h k <: h ULC _- (_' (_) «3 _. c< CJ 1 D HHlilZH •- U- C C Cr C c a £ f. H C

U U 7 *- CT b *- U

C C U U

«i u u c

DTCUD D- 0:" C U

I c >

L c _J

_J _J IT t c c & 3 « »- C

t' ^c r c c ^ — w~ U C Lit <- I L

r- i~- r- r*- t*- •-

li

1 c b- c u 1 u

0" >

Cr c

> U L ? r >

«.' b 1 c. c <s K Cr IT * * C* «"

I b - 1 c\ LJ Z> 1 vn 1 K

r- i 1 c C 1 jc n i f. li _i i- b J _J •- u > i- i r

r" 1- > (T < i 5 J. li li ? c c

D D " r r- n C D 7 c

h- h- t* r*. r*- ir a* c C LT o c i/; c _i cr C

L" ~ CI _J 1 C H

1 H

b Cr cl a

' C C O C C C, C ohccc

c\ ~" c\ o r r " c r if

c c c c c c c c u e c

c c c c c c c c c c c c

f- -K - r - .

li c c c

d- ^ ir it ir ir P c o c C P

ccc cr o c c^oc-ooc-ooccoo: occ oocrocroocrcrooc'GOOc

c c: c ccc crocccc-cr. caccroc

o o c cr C' occ c o o

r- r- o c o — o o o c c^ c c - o c e o c c c c~ rr? occ OOODCOCOCCOC-CCCOOOOCC ooo ooooccocoocccoocsccoo ce-c. ccccoctc- cccoc-coc-oc-coc-c

c*-«-— •--•-•"•-•-•" car rv. <\r o.> r ocvcf k. r* p" r-' k.- r r KCcjjri*1

. ddsaa^riririrL'iriririru ir vr rf. *r *f.

c cr c

c. c rt w t d- i-i vD sir ^ o h fj .-o j- ji vC s i c> c h m ^, j j-. vc m p o^(\i <^^-iTiinr^c-a, o-HC\'r<-, jLi^MrtrcHMo

c w h .- h t- h « ^ w pj m pi c\ oj tv^1 p.1 f ^ r. 2 c f» k: k i^ n k• it ,t f p- * ^ s c ^ r* ^ r s ^f j u* .Tj ir lt j" ^ j" it j~ j" .c j"- \f ^

ir

rr

cr

11
•H

12
j- u> in n- i

t-H » <I

~z r> o

O 3 o t-t <a CD O t-< ta o

tz u. >

=3 M 3 <I

U- Z cr

Of o _J > f\i d. s z z

o t- O <T or 11 o aLU O d 3

l- 2 O i— t- O

7 13 c U_ li_ Ll o

t-> U- _J l-t l-t 0/ M o :=*r or iu

o o o o o o

IT iC N «- O' OHMI

13
O*© — O -o r» x O

«<o — O ffi oj u —

Z <» »c 3 (O O 1£ Z.

' (A

<x o-

• is i a * tfi in * fi !* •tflo.a.tAififltftfitf)

• oj> —• •<Da.££a.a.a.a.a.i a:a_£E3-Q_a-a-CLQ_ 5t-a +s»EuJbJExr:z:E^ •euiujexzixex

O *ifl W ac — - Z --ZZZ2Z2T-JQ; » Z - - 3: Z Z Z Z Z O — 3 *[LO— » <N 3" - * - - - - Z Z Q£ — *(M T - - - - - - o — onaim — < — — —• r>* ar ui -o r-» — — m— -o — — —• t\i a- i/i-o r- ox — cczD»<<<:«xxxa:Q:xa: • • z.»<«t<<:.xxa:iEQ:a:

-j <c x <n <x ->

_i c o o o s: in o o o a _i

3-— <"> O O O C 3" —

o c DOOCOCj- OO C O O C? O O _i OO O O O O O C liJ OlO 3 — i/> — — O -1 om oca— QC cc coatrcoiC C O O O C. C O Z CO CCCDOOuJ

C C

— oooaooooodooc-j CO!

1 C C I

! C O ! oooacooe. ooooooDai

o G

c o

o o

c o COCOOOLJ -J

c c c coo

o o c .

I c c

c: o

i o o

o c c o c o c c, o

C- O O C C '

C O 3 O a 3 3 O O O o,ocao3oco3 oooaoooooc ccooocoooc:

GOCCGCCCOCC OCOOOCOO COC actrocwcouctj

COCOCOOOC OOCCOCO— — CiCCCCiCCJDC&O

3 o i o o o i

i D O D O !

— O ZJ O 3 C •D t~ :ro.oc:o<\.zz

r- O c C o f* — us

O O i

i o c ON'

O C O o o o c o

i r c r c c c ifi r 3- — CS.rs,CMODCCCC

d o» — — — oooocro 3- <[— — — •* -O J 3" T T r»-cif^i^p*Cii3cocc

a- to * r- c — (sj «"» t/i r T 3" T J if !/l ill -P i' e; M \ - N MM N N % 'J l- Li 3 D > O O C? C C C Z IT- IP C OXTC. 3GC3<rLJ ccuc-rcocc;;**— it

m :/) I- • o o a o c a

— -JOOOCCj O 3 O C> 3 loccconocococcocc " -OOOOOOOO

: a o o c? o i ) o o o o o o c

^ o o o o ccoocooooo ODOCJOODOO C'

^. I/) I/) lT<

O C- C^ O O O C- I

r? c o c- e ra o > c- 11 c t- E_-

14
CP

CMai CD• CO>z

\-

u.

cr> O ^

lO

O

iD _J

UJ

O »- CE O z O UJ UJ

2: uj

UJ oo

t—

<t «

1- 00

00 a.UJ

oo cd x r> l~ z o t—

t- z

UJ

x 5: 1- UJ

<t H- a <zt— O 00 o z

t—i o

t- 00 UJ

u 00 t-l z o o k-H d Z UJ U. or o C* UJ i— <l UJ D

1—' X z D t- =3

oo

Or: <IaO

a.

CD«r

—I

V o

1— UJ n z

ct: 1—1 UJ >—1

UJ U- U- > UJ u D

00 Z -rH 3 CM

C\J • C3 CT o f) to z ID O o

CL<Io

15
£UO U II U) X 'ClLJU-OX-j*: Q u> U. O X ~3 1* U 1l(3 I ") ^ It 151 T^ \3 X ~> * X ~> : O Q Q

I "> E

o o o

•H

16
) kj «s x <*j n i O'JL «X

17
"3 i£ -J -y x. ^

"3 * ~>

-i •* ij? "3 * X

O f)

O

PM

18
orcc3 c<

s:

Cf- (." ID CC' I/, -^

UJ Z Z < 3 3

a.X 3o

0.X U" UJ UJ *_/ u z z z

U' l^i z 3 3

•— c? car L. u.; 2 LI t/> O

~~

1- t- t- < <. <* z

•—t

z:O

Q

or bj UJ

u. _j _l f— _) -J

t/1 «I" 4

(- or l_J

U

_J o

r> Or wen or — fV

UJ UJ CL oc cc X <0

Ij.' 3 Z U> 1

19
5. REFERENCES

[1] Rustin R. (ed. ) "Debugging Techniques in Large Systems" Courant

Computer Science Symposium 1, 1971.

[2] Evans, T. G. and D. L. Darley, "On-line Debugging Techniques - A Survey" In AFIPS, FJCC Vol. 29, 1966, 37-50.

[3] Evans, T. G. and D. L. Darley, "DEBUG - An Extension to Current Online Debugging Techniques", Coram. ACM 8,5 (May 1965) 321-326.

[4] Freeman, D. N. , "Error Correction in CORC - The Cornell Computing

Language", AFIPS Vol. 26, SJCC, 1965, 15-31.

[5] Cowan, D. D. and J. W. Graham, "Design Characteristics of the

WATFOR Compiler", SIGPLAN Notices Vol. 5, No. 7, July 1970, 25-36.

[6] Rosen, S. , R. A. Spurgean and J. K. Donnelly, "PUFFT- The Purdue

University Fast FORTRAN Translator", Coram, ACM, 8, 11 (Nov. 1965).

[7] Balzer, R. N. "EXDAMS - Extendable Debugging and Monitoring System",

AFTPS Vol. 34, SJCC 1969, 567-580.

[8] Dijkstra, E. W. "Structured Programming" , In NATO Conference on Soft- ware Engineering Technique, Buxton, J. N. and Randell, B. (Eds.)

April 1970.

[9] Wirth, N. "Program Development by Stepwise Refinement", Coram. ACM

14,4 (April 1971), 221-227.

ClO] American Standard FORTRAN, Published by American Standards Assn. Inc. UDC 681.3, 1966.

[11] Lambda Corporation, "A Guide to Program Improvement with LEAP",

Available from Lambda Corp., 1501 Wilson Blvd, Arlington, Virginia

22209, Jan. 1970.

[12] Knuth, D. E. and R. W. Floyd, "Notes on Avoiding GOTO Statement",

Report No. CS-148, Computer Science Department, Stanford Univ, 1970.

[13] Dijkstra, E. W. "GOTO Statement Considered Harmful", Comm. ACM 11,

3 (March 1968), 147.

20
FORM NBS-114A (1-71) U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. NBS TN-763

2. Gov't Accession No.

3. Recipient's Accession No.

4. TITLE AND SUBTITLE A Set of Debugging and Monitoring Facilities to Improve

Diagnostic Capabilities of a Compiler.

5. Publication Date March 1973

6. Performing Organization Code

7. AUTHOR(S) 8. Performing Organization Elizabeth N. Fong

9. PERFORMING ORGANIZATION NAME AND ADDRESS NATIONAL BUREAU OF STANDARDS DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

10. Project/Task/Work Unit No.

11. Contract/Grant No.

12. Sponsoring Organization Name and Address

Same as No. 9

13. Type of Report & Period Covered Final

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

16. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant bibliography or literature survey, mention it here.) Increasing concern with the quality of computer software today makes

it important to evaluate critically the debugging facilities available in

high-level languages. This paper presents a collection of program debugging

and _ monitoring _ facilities to improve the diagnostic capabilities of a compiler.

A distinction is made between debugging and monitoring facilities performed at compile time, at link/ load time and at execution time. These facilities are described in terms of this breakdown with a conscious attempt to move the

detection of errors from execution time to compile or link/ load time, and

to collect information when the information is available during the compilation

process

.

17. KEY W.ORDS (Alphabetical order, separated by semicolons) Compiler; debugging; error diagnostic; high-level programming languages;

monitoring; procedural-oriented languages.

18. AVAILABILITY STATEMENT

[xl UNLIMITED.

I I FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE

TO NTIS.

19. SECURITY CLASS

(THIS REPORT)

UNCLASSIFIED

20. SECURITY CLASS

(THIS PAGE)

UNCLASSIFIED

21. NO. OF PAGES

25

22. Price

$.50 Domestic Postpaid

$.35 GPO Bookstore

USCOMM-DC 66244-P71

U. S. GOVERNMENT PRINTING OFFICE : 1973 O - 511-324 (203)

NBS TECHNICAL PUBLICATIONS

PERIODICALS JOURNAL OF RESEARCH reports National Bureau of Standards research and development in physics, mathematics, and- chemistry. Comprehensive

scientific papers give complete details of the work,

including laboratory data, experimental procedures, and theoretical and mathematical analyses. Illustrated with photographs, drawings, and charts. Includes

listings of other NBS papers as issued.

Published in two sections, available separately:

• Physics and Chemistry (Section A)

Papers of interest primarily to scientists working in these fields. This section covers a broad range of physical and chemical research, with major emphasis on standards of physical measurement, fundamental

constants, and properties of matter. Issued six times a year. Annual subscription: Domestic, $17.00; Foreign, $21.25.

• Mathematical Sciences (Section B)

Studies and compilations designed mainly for the mathematician and theoretical physicist. Topics in mathematical statistics, theory of experiment design, numerical analysis, theoretical physics and chemistry,

logical design and programming of computers and

computer systems. Short numerical tables. Issued quarterly. Annual subscription: Domestic, $9.00; Foreign,

$11.25.

TECHNICAL NEWS BULLETIN

The best single source of information concerning the Bureau's measurement, research, developmental, co- operative, and publication activities, this monthly

publication is designed for the industry-oriented

individual whose daily work involves intimate contact with science and technology

for engineers, chemists,

physicists, research managers, product-development

managers, and company executives. Includes listing of

all NBS papers as issued. Annual subscription: Domestic, $6.50; Foreign, $8.25.

NONPERIODICALS Applied Mathematics Series. Mathematical tables, manuals, and studies. Building Science Series. Research results, test methods, and performance criteria of building materials, components, systems, and structures. Handbooks. Recommended codes of engineering and industrial practice (including safety codes) de- veloped in cooperation with interested industries, professional organizations, and regulatory bodies. Special Publications. Proceedings of NBS conferences, bibliographies, annual reports, wall charts, pamphlets, etc. Monographs. Major contributions to the technical

literature on various subjects related to the Bureau's

scientific and technical activities. National Standard Reference Data Series. NSRDS provides quantitative data on the physical and chemical properties of materials, compiled from

the world's literature and critically evaluated. Product Standards. Provide requirements for sizes, types, quality, and methods for testing various industrial products. , These standards are developed co- operatively with interested Government and industry groups and provide the basis for common understanding of product characteristics for both buyers and

sellers. Their use is voluntary.

Technical Notes. This series consists of communications and reports (covering both other-agency and

NBS-sponsored work) of limited or transitory interest. Federal Information Processing Standards

Publications. This series is the official publication within the FedeTal Government for information on

standards adopted and promulgated under the Public Law 89—306, and Bureau of the Budget Circular A—86

entitled. Standardization of Data Elements and Codes

in Data Systems. Consumer Information Series. Practical information, based on NBS research and experience, cover- ing areas of interest to the consumer. Easily understandable language and illustrations provide useful background knowledge for shopping in today's tech- nological marketplace.

BIBLIOGRAPHIC SUBSCRIPTION SERVICES

The following current-awareness and literature-survey bibliographies are issued periodically by the Bureau

:

Cryogenic Data Center Current Awareness Service (Publications and Reports of Interest in Cryogenics). A literature survey issued weekly. Annual subscription: Domestic, $20.00; foreign, $25.00.

Liquefied Natural Gas. A literature survey issued quarterly. Annual subscription: $20.00.

Superconducting Devices and Materials. A literature survey issued quarterly. Annual subscription : $20.00. Send subscription orders and remittances for the preceding bibliographic services to the U.S. Department

of Commerce, National Technical Information Service, Springfield, Va. 22151.

Electromagnetic Metrology Current Awareness Service (Abstracts of Selected Articles on Measurement

Techniques and Standards of Electromagnetic Quantities from D-C to Millimeter-Wave Frequencies). Issued monthly. Annual subscription: $100.00 (Special rates for multi-subscriptions). Send subscription order and

remittance to the Electromagnetic Metrology Information Center, Electromagnetics Division, National Bureau

of Standards, Boulder, Colo. 80302. Order NBS publications (except Bibliographic Subscription Services) from: Superintendent of Documents, Government Printing Office, Washington, D.C. 20402.
U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Washington, DC. 20234

OFFICIAL BUSINESS

Penalty for Private Use. S300

POSTAGE AND FEES PAID

U.S. DEPARTMENT OF COMMERCE

215