A Survey of Current Debugging Concepts

NASA CONTRACTOR REPORT

h c14 m v I PL U

4 r/) 4 z

A SURVEY OF CURRENT DEBUGGING CONCEPTS

by WaZZace Kocher

Prepared by WOLF RESEARCH AND DEVELOPMENTCORPORATION Bladensburg, Md. for Goddard Space Flight Center

NATIONALAERONAUTICS AND SPACE ADMINISTRATION WASHINGTON, D. C. AUGUST 1969 TECH LIBRARY KAFB, Nhl

0060538 NASA CR-I397

A SURVEY OF CURRENT DEBUGGING CONCEPTS

By Wallace Kocher

Distribution of this report is provided in the interestof informationexchange. Responsibility for thecontents resides in the author or organization that prepared it.

Prepared under Contract No. NAS 5-9756-99 by WOLF RESEARCH AND DEVELOPMENT CORPORATION Bladensburg, Md.

for Goddard Space Flight Center

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

For sale by the Clearinghouse for Federal Scientific and Technical Information Springfield, Virginia 22151 - CFSTl price $3.00

TABLE OF CONTENTS

Section Page I INTRODUCTION ------1-1

1-1 Need for DebuggingDevelopment - 1-1 1-2 Scope of ThisReport ------1-1 1-3 DebuggingAspects, Definitions - 1-2 1-4 Categories of Programming Errors 1-3 1-5 Phases of Debugging - - - - 1-4 1-6 Error DiagnosticProcedures 1-4 ._

I1 IMP-F PROGFAM DEBUSGING - - 2-1

2-1 Description of the Programs 2-1 2- 2 Programmer Comments - - - - 2-2 2-3 InterviewGuidelines - - - - 2-3

I11 CURRENT DEBUGGING CONCEPTS - 3-1

3- 1 CurrentConcepts ------3- 1

3-2Preliminary Testing - .- 3-1 3-3 Checkingthe Flow Chart 3-1 I 3-4 Linkingthe Flow Chart to the Coding 3-3 3-5Concluding Steps 02 PreliminaryTesting 3-3

3-6 Assemblingand Coqillng L""""_ 3-4 3-7 AssemblerAids ------3-4 3-8Compiler Aids ------3-5

iii ...... ". - ._._

TABLE OF CONTENTS (Continued)

Section Page 3-9Macro-Instructions ------3-7 3-10Debugging Macros ------3-7 3-11Advantages ofDebugging Macros - - - - 3-8 3-12 The SDC-SFARE DebuggingPackage - - - - 3-9 3-13Inserting' Diagnostic Instructions ------3-11 3-14 B~~~ ------3-12 3-15Postmortem Dumps ------3-12 3-16Snapshot Dumps ------3-13 3-17Inconveniences of PresentTechniques - 3-13 3-18Efforts to Improve Dumping Techniques - 3-14 3-19 The ALCOR Illinois 7090./7094 Post Mortem Dump ------3-15 3-20 The UNIVAC 1108Executive Systems - - - 3-18 3-21 The Snapshot Dump ------3-19 3-22 The Postmortem Dump ------3-20 3-23 Traces ------3-20 3-24Possibilities for Limitingtke Trace - 3-21 3-25Trapping ------3-22 3-26 Static Trace ------3-22 3-27Improved Approach toTracing - - - - - 3-23 3-28 The SEFLO TracingTechnique ------3-25 3-29Dynamic Debugging ------3-25 3-30 FORTRAN DebuggingLanguages ------3-27

iv TABLE OF CONTENTS (Continued)

Section

3-32 DIAGNOSE, Another FORTRAN DebuggingLanguage ------3-28 3-33 BUGTRAN, Another FORTRAN DebuggingLanguage ------3-30 3-34 TESTRAN, for IBM System/360 ------3-32 3-35 Introductionto TESTRAN - - - - 3-32 3-36 Procedure ------3-33 3-37 The "Rip Stopper" Method ------3-35 3-38 The WATCHR I11 System ------3-36 3-39 TIDY and EDIT for FORTRAN ------3-40 3-40 The TIDY program ------3-40 3-41 The EDIT Program ------3-42 3-42 AutomaticFlowcharting ------3-43 3-43 The AUTOFLOW System ------3-43 3-44 Testing ------3-44

3-45 Purposes ------3-44 3-46 Problems ------3-45,

3-49 Satellite Test Data ------3-46 TABLE OF CONTENTS (Continued)

Page

4-1 On-Line Debugging Techniques ------4-1 4-2 Criteria for an On-Line Debugging System - - - 4-2 4-3 The Programmer-Controlled Breakpoint - - - - - 4-2 4-4Assembler-Language Program Debugging: The DDT System ------4-3 4-5 Higher-Level Language Debugging ------4-7 4-6 The LISP System ------4- 7 4-7 The QUIKTRAN System ------4-9 4-8 The Incremental Compiler ------4-9

vi SECTION I INTRODUCTION

1-1. NEED FOR DEBUGGING DEVELOPMENT

Debugging is a general term that refers to the location and correction of errors that occur in computer programs. The debuggingactivity may consume considerable portionsof the total time required for the complete program development.However, the importance of thisarea of programdevelopment has often been minimized. The purpose of this report is toplace some emphasison this important area and to present some ofthe current debugging concepts which may beconsidered for implementation.

Computers are continually becoming faster andmore complex,and applications becoming more extensive, more intricate, and more time-critical. Thus,the need for a greatereffort in the area of debugging is obvious. Two of themajor €actors which make programerrors both harder to find and harder to tolerate are time-constrained programming andclosed-loop applications. These are particularly applicable to many of the space-related programs.

1-2. SCOPE OF THIS REPORT

The projectthat has famished impetus to this report is the IMP-F (InterplanetaryMonitoring Platform). Becausethe IMP-F computer program complex will form the basis for future IMP efforts, it was necessary to document thepresent version as fully as possible in order to reduce the lead time andcost of developing the follow-on IMP

1-1 complexes. One importantarea (and the subject of this paper) is debugging.This report includes, in addition to thedocumentation of the IMP-F debuggingeffort, a survey of currentdebugging concepts which may beconsidered for implementationin future programs.

1-3. DEBUGGING ASPECTS, DEFINITIONS

For thepurposes of thisreport, debugging will be considered to includelogical and clericalerrors but not machinemalfunctions. To be more specific,debugging includesprevention, detection, diagnosis, recovery, and remedy ofprogram errors. It is anon-going process that lasts for theentire lifetime of theprogram. The following 1 definitionsclarify the above mentioned aspects:

a. Prevention - protectiveaction taken against theoccurrence of errorsor omissions.

b. Detection - determination of theoccurrence of anerror or ofan omission at the earliest pointpossible so as to limit theconsequences.

C. Diagnosis - analysisof the error that was detected.

d. Recovery - provision for ameans of bypassing anerror coniiition, especially one ofan intermittentnature, with a minimum loss of timeand effort.

1-2 e. Remedy - rapidremedial action employed to preventfurther occurrences of the same or similar errors andomissions.

1-4. CATEGORIES OF PROGRAMMING ERRORS

Programming errorsfall into two basiccategories - logicaland clerical.

Logicalerrors are those which involve problem analysis.Although they occur less frequently than 'clerical errors they are usually more serious andmore difficult to detect.Since they often occur early in theprogram writing process,they have a tendency to beoverlooked. Frequently they are a result of amisunderstanding of theproblem and requirements.Often, in very complex programs, errors result from failure to cover all possible alternatives that may arise, fromimprope-r identificationof storage areas, etc.

Clericalerrors are those errors which involve the inputdeck or otherinput media; these errors are sometimes referred to asphysical errors, and errors made in writing symbolicinstructions. Numbers may betransposed, cards may beomitted or mispunched,a symbolic namemay be spelled more thanone way, to mentiona few types of these errors.Frequently these errors are the result of careless- ness. Onecommon source of sucherrors may beavoided by keepingprogram listings and decks up to date; old versions shouldbe destroyed or at least marked.

._ . . .. "" ~ __""""_""____"..__I __" . . ~ T"" "" - 1-5. PHASES OF DEBUGGING

The debuggingprocess is generallythought of as 2 consisting of several phases:

a. Desk checking.

b. Assembled or compiledprogram checking.

C. Program-testingusing test data.

d. Error diagnostic procedures.

e. Runningof program using actual data.

1-6. ERROR DIAGNOSTIC PROCEDURES

Inthis report, emphasis is placed on thephase dealingwith error diagnostic procedures. A number of programsand programming techniques are available for diagnosticpurposes. Their underlying principle is to provideinformation about a particular portion or portions of theprogram as control passes through the specified instructions. The amount arid location of theinformation will varydepending on thenature of theerror. Proposals havebeen EaGe fordeveloping software that will allow debugging to beconducted using the same languageas the sourceprogram; however, few of thesehave been implemented. Few if anycomputer systems or majorlanguages today.pro- videcomprehensive symbolic debugging software packages.

1-4 SECTION I1 IMP-F PROGRAM DEBUGGING

2-1. DESCRIPTION OF THE PROGRAMS

Informationconcerning the debugging of time- correction anddecommutation programs for the IMP-F space- craft vas collected through a series of interviewswith programmersand project managers associated with the project.

The IMP-F time-correctionand decommutation programs werewritten in FORTRAN andthe UNIVAC 1108 assemblerlanguage, SLEUTH 11.

a. The time-correctionprograms perform two basic operations:

1. Correctrange time data byremoving discontinuities and filling in missing timedata.

2. Establishfairly precise correlation of spacecraftevents with range (earth-based) tine signals by correcting for propaga- tion delay,

b. Decornmutationoperations are concerned with strippingout, formatting, and providing pertinent data for eachexperimenter.

2-1 2-2. PROGRAMMER COMMENTS

In general,the programmers associated with the project felt the diagnostic system that was available within the1108 Executive system was adequate for theirdebugging needs. The 1108diagnostic system provided for snapshot andpostmortem dumps.However, somecomments and sugges- tionswere made that may provide some insightinto debuggingprocedures that may beconsidered for implementation infuture IMP programs. Among thesesuggestions were the following:

a.Debugging aids may betoo expensive and involve excessiveoverhead. They may requireexcessive corestorage and increase running time beyond practical limits.

b.Care should be taken when implementingdebugging aidsnot to duplicateaids that are already provided for by themanufacturer's system.

c. Duringthe writing of the IMP-F programs, a change inpersonnel occurred. The programmers thattook over the project felt a traceroutine wouldhave been desirable, but that the implementation of a built-in trace routine should havebeen acconplished during the design phase, since a great deal of work is entailed when such a routine is impiementedduring later phases.

d. The WOLF programersassigned to the IMP-F projectwere able to use snapshot dumps for theirtracing needs. Sowever, a problem

2 -2 associatedwith the postmortem dump was that wheneverthe system was lostthrough a drum failure,illegal instruction, system failure, etc., thenthe dump was alsolost.

e. Imbeddedcomments were notonly useful for debuggingpurposes but were valuablein estimatingrunning time.

f. Two specificsuggestions were made concerning future IMP programs:

1. The first was todevelop routines that wouldcheck experimenter's tape for known characteristicssuch as label, format, size, arid specialcharacters, and especially data.

2. The second was todevelop a better method of obtainingtest data.

2- 3. INTERVIEW GUIDELINES

The following is a copyof the checklist of subjects inconducting the interviews with the IMP-F programmersand proj ect managers.

CiiECK LEST

1. Debuggingtechniques employed.

2. Preliminaryphases.

2-3 a. Flow chartand coding

b. Clericalerrors

c. Logical errors

3. Assemblingand compiling phases, suggestions forimprovements.

4. Phasesbeyond assembling.

a. 1108 packageadequacy

b. Other concepts

c. Suggestions

5. Testing.

a. Testsa. employed

b. Generatingtest data

6. Editing or cleaning-upprograms.

7. Management practices.

a. Coordiiiation, etc.

b. Suggestions b.

8. On- linedebugging.

2 -4 9. State-of-art.

a. Techniques

b . Concepts

10. Greatestproblem in debugging IMP-F, special or unusualproblems.

11. Knowledge of debuggingliterature.

2-5 SECTION I11 CURRENT DEBUGGING CONCEPTS

3-1. CURRENTCONCEPTS

Thissection discusses debugging concepts surveyed forfuture implementation in programs such as IMP-F. While theconcepts described.here may notbe entirely new or unknown, andwhile the list may notbe complete, neverthe- lessthese concepts represent a typicalrange of current practices or developments,and as such may suggest known approachesto the subject of debugging.

3-2. PRELIMINARY TESTING

Preliminarytesting, manual checking or desk checking consists of a detailedreview of the program by the programmer.This phase of testing may beviewed as having two parts, the first of which is a reviewof the general logic anddegree of completeness. The secondpart is a manual dryrun using sample data during which the programmer keepstrack of register contents, modified instructions, switches,etc., while following the flow of theprogram. Specialemphasis may beplaced on unlikely situations.

3-3. Checking the Flow Chart

Duringthis phase of testing,the flow chart can andshould be utilized both for detectingerrors and as a logicaltool for debugging procedures. The desired level of detail for such flow chartswould show every decisionor branch and every subroutine execution. Seven basicchecks should be performedon the flow chart. 3

a. The beginningand end should be clearly markedand present.

b.Each decision symbol should have at least two alternatives,and each possible result of thetest should be represented by some flow line. Suchflow lines should be traced so as toinsure that the correct path is takenfor thespecified condition. Each condition shouldbe provided for.

c.Operation symbols should have nomore than one exit andentry line.

d. Flow linesmust. be connected at both ends, eachline must originate at some symboland terminate at a symbol or merge point.

e. On flowcharts of that level of detail which includespartial coding, no variable namemay appear on theright-hand side of a formula, in a decisionsymbol, or asoutput if it has notbeen defined somewhere inthe program in an ,input list or on theleft-hand side of a formula (anystatement calling for theassignment of valuesand quantities). Each variable name whichappears at least once in a program in aninput list (includingthe outputs of subroutines) or on theleft-hand side of a formula is unused if it doesnot appear on the right- handside of a formula,in an output list (includingthe quantities supplied to subroutines by themain program), or in a conditional test. It is, therefore,unneccessary.

3 -2 f. Switchesmust be set or defined at some point previousto usage in the flow chart, and each possible position of the switch must be set at leastonce somewhereon thechart.

g.Each loop must have the following features :

1. Initialization.

2. A 2rocessconsisting of one or more statements.

3. One or more tests to terminateloop.

4. A method forreiterating the loop.

3-4. Linkingthe Flow Chartto Coding

Afterthe programmer is satisfiedwith the flow chart, thecoding is performed.During the coding process, care sho'uldbe taken to link theflow chart with the coding. If changes inthe f.low chartare required, the above checks shouldbe considered to ensure that new errors have not been propagated.

3-5. ConcludingSteps of PreliminaryTesting

The preliminarytesting phase progresses from a roughanalysis through more detailedanalysis to a detailed check of thecoding. If time permits,recopying of the diagram may bedesirable because close reexamination may disclose errors previously hidden by sloppydrawing or erasing. If timeand personnel permit, it is extremely

3 -3

I helpful if a secondperson can assist in the preliminary checkingprocedures. A listing of thecards should be made andchecked against the coding forms, looking for keypunch errorsand sequence.

3-6. ASSEMBLING AND COMPILING

Computersystems supply a certain amount of diagnostic controlin their assembly or compilationprograms. However, thistype of diagnosticaid is in mostcases designed to assistthe programmeronly up to that time at whichthe computer is ableto interpret andexecute the instruction sequences, The diagnosticnotations produced usually deal with clerical typeerrors and seldom with logical errors. Some systemspro- ducediagnostics that indicate the severity of theerror, i.e.,absolute, probable, etc. An error-freecompilation or assemblydoes not indicate that the program is debugged,only thatcertain types of codingerrors have been eliminated. A weaknessof both compiler and assembler debugging aids lies withthe fact that the statements are examined singly. The processor is for themost part unable to detect logical errors in transfer of control.

3-7. AssemblerAids

Mostassemblers produce a program listing with diagnosticnotations adjacent to the instruction containing certain 4 errors.Errors of thisnature include the following:

a. Undefined or multi-definedsymbols.

b.Invalid operation codes.

c. Invalidoperands in a symbolicexpression.

3-4 I

d.Invalid or omittedaddress.

e.Improper use of certain pseudo-operations.

f. Invalid names in name field,such as names containingunauthorized special characters, etc.

The diagnosticnotations are generally singular. Some systemsproduce two notationsin the event that two detectable errorsoccur in a singlestatement.

A list ofsymbol references (the part of a computer listingsometimes called an external symbol dictionary, or a concordance, or a cross-referencetable) may beextremely usefulin revising as well as debugging a program.In the eventthat a change is made thataffects the definition of a symbol, it is importantthat all references to that symbol bechecked. Special care is required when a codingsequence is deleted,since it is likelythat one or moresymbols may beaffected.

3-8. Compiler Aids

The diagnosticnotations produced by compilersystems aresimilar to those produced by assemblers. They are generally printed with the listing andwhere possible make referenceto particular statements. The following summary shows typicaldiagnostics prodxed by one FORTMN compiler: 5

a. Individuala. statements:

1. Invaiidstatement - reservedword, excessivelength, etc.

3-5 2. Mixed arithmeticexpressions - containing real anainteger constants and variables.

3. Misuse of parentheses - anunequal number of left and rightparentheses.

4. Illegalexpression - two operators may have beenused in succession, etc.

5. Suiscri2ting a fixed-pointvariable. b.Intsraction of two or xiore statemenes:

1. Referencedstatement is notpreser,t or is unnumbered.

2. Omission of a DIMENSION statement when subscriptvariables are used.

3. Undefinedvariables - a variablethat appears inan arithmetic expression (on the right side of anari-chmetic statement) that is notdefined or assigned a value earlier inthe Pi-oErm. c. Capacityof words or of memory:

1. Table limits havebeen exceeded - during compilation FORTRAN uses a number OP tables; if theprogrammer uses an excessive number of statements or otherfeatures a diagnostic notationresulrs.

2. Memory capacityof machine is exceeded.

3 -6 3. Number exceedingprecision of computer - number toolarge or too small, requiring an excessive number of decimalplaces is a typical limit of a 36-bitbinary word computer.

d. Logic of program:

1. Flow is unableto reach at least one part of theprogram because of branches;program flow doesnot include one or more executable statements .

2. Illegalentry to a DO loop - entering a DO loopat any statementin the range of theloop other than the "DO" statement itself.

3. Excessivelevels of nested loops - this limit is determined by theindividual computer.

A number of thesediagnostic notations would be appli- cableto anyalgebraic-language program (a.3, a.4, b.1, b.3, c.1, c. 2, andd.1). Others only apply to FORTRAN and certain othercompilers (a.1, a.2, a.5, b.2,c.3, d.2, and d.3).

3- 9. MACRO- INSTRUCTIONS

3- 10. DebuggingMacros

Certain special macro-instructions may be usedduring therunning of anobject program to provide debugging informationthat is notnormally supplied. Instead of usinginter- ruptionsor trap features, the macro calls are inserted in

3 -7 program.These macro-instructions expand into coding that callsfor output routines that are under control of the operatingsystem. Loops, when required,are also provided for bythese macro-instructions. The informationproduced may appearin the same form as does a dump or trace.

Existingmachine instructions may bemodified by macro-definitionsto supply diagnostic information. An exampleof this technique is to modify a storageinstruc- tion so asto write out the data being stored. However, a more common technique is theinsertion of macro-instructions inthe program for thespecific purpose of providing diagnostic information.

3- 11. Advantagesof Debugging Macros

Particularuse is made ofthe writing or printing instructions.Certain condition stipulations may beem?loyed aswell as format specifications (similar to thosein a dump) such as hexadecimal,decimal, octal, or BCD. Xeasseibly ofthe prograrr, is required in order to insertthe additional coding of themacro-instructions, a processthax is not necessarywith the use of dumps or traces.There are, however, 6 severaladvantages to this technique:

a.Symbolic refere.nces may be made tolocations or blocks of locationsthat are to bedumped; inthe event that coding changes are made,thei-e is generally noneed to changethe macro calls, which is oftenthe case with control cards when usingsnapshot d-mps since their addresses are absolute;however, many systemsprovide for syxbolicaddressing for their dumping routines. b.Flexibility is providedthe programmer; he may specifyany sort of dump hewishes. They may resembletraces or dumps orany combination of the two. The macro-instructionsused for dumping aregenerally quite simple in structure,primarily involvingcoding for a loop,for an output calling sequence,and for storage of certain registers. Becauseinformation may bedisplayed in various formats, th.e dump may includesymbolic information whichfacilitates the identification of words and registers.

c. Macro-instructionsare relatively easy to write. The advantage of writingmacro-,instructions for dumping purposesover corresponding coding for a monitorsystem or processor is that instructions mustbe general in natureand each piece of informationmust be stored in memory tables or remainin instructions to be interpreted. The codingemployed with the use of macro-inscructions is specific and is tailoredto the user's needs; also,the iastructions remain in executable form withinthe macro-instruction expansion.

3-12. "The- - " ,SDC-SHARE . Debugging Package

The debuggingpackage which is includedin the SDC- 7 SHARE operatingsystem uses a setof macro-instructions that will produceselective dumps inthe source language at any pointduring the execution of theobject program. The execution of thesemacro-instructions does not affect theoperation of the objecxprogram. The debuggingmacro- instructionsare defined within the compiler and will be insertedinto locations s2ecified by theobject code during

3 -9 compilation. Thedebugging macro-instructions are classified accordingto three categories: information macros, conditional macros,and modal macros.

a.Information Macros. This type of macro-instruction is responsiblefor the actual dumping ofinformation. Thisinformation is written on a tapeduring the executionof the object program after which it is translated and written on anoutput tape. The for- ma'. for the ou*L?ut msy beincluded in the informa- tionmacro, otherwise it will bedescribed in a dictionary by successivelocation syzbols. The dictioriary is developedduring compilation, each entrycontaining a locationsymbol and a corres- pondingformat code to identify the contents of thedescribed cell in memory. Through theuse ofthis dictionary, symbolic output may beproduced. The formatcodes control the printout of all informationfrom the specified location to the locationof the next symbol encountered.

b.Conditional Macros. This type of macro-instruction is usedto control the execution of infomation macros.These macro-instructions are placed immediateLySefore the information macros they control; their co~erol is terminateci wherL the nextnondebugging macro-instruction is encountered. Throughthe use of these conditional macros, a programmer may specifyconditions which must be satisfied before the information macrocan beperformed.

c. Modal Macros.This type of macro-instruction permitsthe program to specify the mode tobe usedin interpreting subsequent information, or

3 -10 to set or reset certainparameters used by the debuggingsystem. Besides defining the mode of operationfor either conditional or information macros,they also provideinternal controls for thedebugging supervisor and some control of outputformat. Modalmacros generally remain in effectuntil countermanded by another modal macro oranother macro-instruction is encounteredthat sets all moaalmacros to normalconditions.

3- 13. INSERTING DIAGXOSTIC INSTRUCTIONS

A relativelysimple but effective aid in the debugging processconsists of inserting throughout the program temporary diagnosticinstructions which will printout messages that displaythe results of the program at various stages. Generally suchinsertions are placed at theconclusion of program segments.This technique will provideinformation as to the flow ofthe program and it may alsobe used to indicateprogram status(the existence of anerror condition). In order to ascertainthe status of the prcgram, various tests are employed. Throughthe use of a test deck(a set of testdata for which theresults at variousstages are known), thearea in which theprogram departs from the correctprocedure can be detected.

The messagesthat are printed out may beused to show theoverflow of storageblocks or a divergingseries of values. Externallycontrolled status reports containing such information as itemcounts, important results, calling-sequence parameters,accession assumptions, pointers, and summary totals may beproduced. Onemay devise tests forall para- metersand 2rovide meaningful messages. In the event that it is notpossible to correctthe error, it may bedesirable toallow the system to approximate the interimresults and

3 -11 continue,especially in theearly stages of thesystem's development. When thepreceding condition occurs, it must beclearly noted. Options should be available to list selectedsubsets of inputsand outputs from peripheraldevices to eachroutine in the system.

A method of cross-controlchecking may beprovided by producing a printout of programassertions at the beginning ofeach program segment and of program expectations at the end 8 of eachprogram segment.

The insertedinstructions and corresponding messages shouldbe coded in some consistent,recognizable way which will permittheir mechanical removal once the program is finalized.

3- 14. DUMPS

Dump is a term that is generallyapplied to a listing ofthe contents of a storagedevice; it may includeali or part of theinternal storage, as well as registers. Dumps may beclassified into several categories: snapshot dumps (dynamic)or postmortem dumps (static).

3- 15. Postmortem Dumps

Thepostmortem dur,p is performedat the termination ofthe object program. This termination may result from some form of erroror by intentionalinstruction. At times it may beadvisable to list the entire memory exceptpossibly themonitor system, since the effects of errorsare unpredic- table and oftenwide-spread. In early testing this method of dumping nay bethe only way toensure that some unsuspected influencingfactor was not overlooked.

3 -12 3- 16. Snapshot Dumps

The snapshot dump is a selectedor dynamic listing . of registers and specified memory locations printed out upon theexecution of strategically located dynamic-dump instructions(breakpoints or checkpoints) . Theprogrammer may insert these dump instructionsin the program before it is runthe first time; or he may insert or changethem before a laterrun, after errors have appeared. This form of dump is useful when the programmerhas little or no ideaas to thelocation of the program error. If the program has previouslybeen segmented, it is relativelyeasy to insert dynamic dump instructions so as toisolate at least the earliesterror tc some particularsegment. Then as the generallocation of the error is identified,the snapshots (dynamic dumps) areinserted more frequentiywithin smaller areasof the segments. Each segment may bechecked indivi- dually. The snapshot dump is anextremely useful debugging aid for the programmer (who should know machinelanguage).

3- 17. Inconveniences~ of Present Techniques

The dumping techniques still widelyused today, even in some of themost modern and advanced computers, are claimedto be obsolete, and produce very inconvenient listings . Criticisms of thedumpkg techniques include thefollowing:

1. If theprogram has run for some time,earlier partswhich may be neaningful are lost.

2. Greatamounts of uselessinformation are some- timesgenerated.

3 -13 3. The listingsare difficult to analyze. One must perform a greatdeal of decoding; know themain characteristics of a particularmachine, its internallanguage, the operating system, and the object(machine) codes corresponding to ins truc- tionswritten in the source language.

3-18. Effortsto ImDrove DumDincE Techniaues

Variousattempts have been made torefine and improve the dumping techniques.These are, inessence, attempts to overcome the previously listed criticisms .

a. The use of symbolicaddress designations for the purposeof dumping is providedfor by certain processorsystems. The advantagesof this approachare evident - considerthe advantages ofsymbolic coding over machine language coding. Inorder to facilitate such a technique a symbol tableassociated with the program being debugged mustbe accessible. Thedumping routinemust convertthe syinbolic addresses on cards to absoluteaddresses.

b. The operatingsystem must assume temporary control from theobject program during the time that the dumped information is beingwritten out. A common way ofaccomplishing this is throughthe use of a trap. The trap is a special form of a conditional breakpointwhich is activatedby the computer itself or byconditions imposed by the operating system,or, by a combination of these. The trap causescontrol to pass to a specified memory loca- tionwithin the operating system. A method of returni,ngcontrol to the object program must also beprovided for. When theoperating system encountersdebugging control instructions, it mustprovide means bywhich the trap will occur at thespecified locations. A record must be made of thelocation in the object program from whichcontrol was transferredto the operating sys tem .

c. The efforts made onimproving dumping techniques havebeen directed toward the pinpointing of dump locations,increasing the selectivity of thestorage locations to be dumped,and editing ofthe printed output.

3-19. The ALCOR Illinois 7090/7094 Post lrlortem Dump

The ALCOR Illinois 7090/7054 Post Mortem Dump (PM- Dump) providesan example of improvedtechniques in the area ofpostmortem dumping.

a. The objectives of thiseffort include the following: 10

1. If the program runs successfully,the execution time mustnot be increased.

2. Specializedknowledge in excess of what was needed to write the program shouldnot berequired for understanding the data provided by PM-Dump.

3. Eventsoccurring before the failure that have a possibleinfluence on its cause shouldbe recorded in PM-Dmp.

3-15 4. All informationthat is notpertinent to thedetermination of the cause of the failureshould be avoided.

5. Informationpertaining to specific machine characteristics should be held to a minimum. b. The PM-Dump is not a singleprogram but consists ofseveral programs, each of which generally per- tainsto oneof the various stages of program processing(translation, loading, execution).

1. Duringthe translation phase the compiler generates dump informationwhich relates the objectcode generated by the compiler to the originalsource-language program. This dump informationprovides the basis for failureanalysis. Since the information which relatesthe source program to the objectcode is availableonly at compilation time,the compiler must save this information. The modification of anexisting compiler may be a difficult andtedious task. The dump information is moved tosecondary storage until later when it is usedat dump time. A loading map is usefulbut it is notnecessary. Such a map wouldbe helpful in locating the point of failure and indetermining how to accessthe proper dump information.

2. At thebeginning of programexecution, a shortroutine indicates to the operating systemwhere control should be transferred inthe event of an unsuccessful termination. This is theonly routine that slows program execution if a dump is requested. The routineconsists of about 100 machine instructionswhich set switchesin the operatingsystem or initialize a few error routines.

3. At thetime of the failure, theoperating systemtransfers control to a connecting routinewhich saves the relevant contents of memory (theprogram and working storage areas)for the main dumping routine.This routinethen calls on themain dumping routineand passes to it suchinformation as thetype of failure and the contents of theinstruction counter. Because of the relativelylong length (about 3600 machine instructions)of the main dumpingprogram, it is desirableto load it into main memory onlyafter a failureoccurs. This is accom- plishedthrough the use of the connecting routine.

4. The maindumping routinecoordinztes and analyzesthe information made available to it bythe previous routines, and presents the programmeran analysisof the state of theprogram and of its history at the time of failure. The objectcode at execution time is notaffected by the dumping routine exceptin the case ofone call. During com- pilationall preparations are made forthe dumping processand the analysis is performed onlyafter the failure has occurred. The dumping routineprovides the programmer withthe following information:

3 -17

I (a) Lists localinformation such as names andvalues of variablesand object codes whichconcern the failure point in the program.

(b) The name of thesubprogram or procedure is listed if the failure point was not in the mainprogram.

(c) A listing of namesand presentvalues of variables is producedbeginning with theblock in which the failure point occursand proceeding to surrounding blocksuntil all blocks in a given procedurehave been processed. Unless theblock terminates in the main programs,the point from which it was called is determinedand is considered a new failure point.

3-20. The UNIVAC 1108Executive Systems

The UNIVAC 1108exdcutive systems provide for both postmortemand snapshot dumps. Snapshot dumps may be initiated when a sourcelanguage element is processed to relocatableelement form or when relocatableelements are combinedby the collector into an absolute program. Post- mortem dumps areinitiate6 by a controlstatement. D-mped information is writtenin a diagnostic file, and is read backfor editing after the program being tested has terminated. Librarysubroutines write out dumps, saveand restore all

3-18 ofthe program's environment. The snapshotfacility may be employedby any processor.

3-21. TheSnapshot Dump

The selective nature of thesnapshot dump is achieved throughthe use of seventeen procedures. These are divided intothree categories - conditional, dump, specification.

a. The conditionalprocedures may precede or be interspersed among a list of dump procedures. The purposeof the conditional procedures is to determine when or if dump proceduresare to be activated.

b. The dump proceduregenerates a callingsequence which writes outthe information comprising the desired dump. If no conditionalprocedures are used,the dump procedures will alwaysproduce output.These instructions enable the programmer toselect the locations and amount ofinformation to be dumped.

c. The specificationprocedures provide a buffer areaand format specifications. A number of standardformats are provided by the system and thesewould suffice in most cases; however, for unusualsituations, one may definespecial formats. An areaof core is definedinto which information fromtapes or drums is read. Theprogrammer is alsoable to save dumps up to a certainpoint in executionand then delete them at his discretion. The overallcontrol of calls to debuggingprocedures is maintainedby two instructionswhich

3 -19 activate or deactivatereferences made tothe debuggingprocedures.

3- 22. The Postmortem Dump

Each diagnosticroutine that is partof the program is processedserially. A common exitin diagnostic library routine will check to see if thenext instruction is a call tothe diagnostic system. This technique ensures that a series of calls will notbe interrupted by the activities of anothersubprogram.

The postmortem dump executivecontrol statement is used to dump currentcore memory followingthe execution of a task. These dumps may consistof overlay segments, elements, orspecified parts of elements.Several options are available tothe progranmer for selecting output format anddefiriing coreareas to be dunlped.

3-23. TRACES

A trace is aninterpretive diagnostic technique which providesan analysis of each executed instruction resulting in a listing of suchinformation as thecontents of words and registersas they are modified and the order in which the instructionsare perforned. This technique does not require recompilationand is particularlyuseful for the programner who is havingdifficuity Zollowing the logic flow since the traceprovides a meansby which one may followthe course of a programas it is executed.

3 -20 However, a detailedtrace producing a lineof informa- tionfor each instruction greatly slows down theexecution of theprogram and generates enormous and excessive listings. Thisapproach, particularly diastrous on large systems, is generallydiscouraged and reserved for use as a last resort.

Anotherproblem associated with the tracing technique is thelack of flexibility of many systemsin that the programmer cannotprovide his own subroutinesfor extended usage, therefore,the system software must provide the capability forselective or conditional tracing techniques. Because of theincreasing sophistication of bothcomputer hardware and software,as exemplified by address indexing, indirect addressing,automatic allocation of relocatable subroutines, numerous residentmonitor and library routines, paging, chaining,and both manual and automatic overlay facilities, thereare increasing difficulties in following the flow of a program, so that it is oftendesirable for the system software tohave an efficient trace routine available.

3-24. Possibilitiesfor Limiting the Trace

Possibilitiesfor limiting the trace include the following:

a. Tracingonly a singletype of instruction such as storage,loading, arithmetic, branching, index, shifting,skipping, or in; ut/output instruction.

b. Tracing a combinationof ther? specified instructions.

C. Tracingonly address modification.

d. Limitingthe number oftracings performed on a single loop. 3 -21 e. Tracingin only selected parts of the program whileother parts run at normalspeed.

f. Tracingonly a singleregister or combination of registers.

3- 25. Trapping

As inthe dumping technique,the operating system mustassume temporary control from the object program during thattime the diagnostic information is beingwritten out. This is generallyaccomplished through the use of hardware interruptsor interpretive software routines (traps).

The IBM 7090 provides a specialtransfer trapping mode whichenables the object program to run at normal speed and toslow down only when a transfer is executedand diag- nosticinformation is writtenout. Whilerunning at normal speedthe flow of control passes sequentially from one instructionto the next, except in the case of a skipafter which it passes to thenext instruction. This technique is particularlyuseful when one is onlytrying to establish thestructure of the program.

3-26.Static Trace

A static tracetechnique was developedby the Mitre Corporationfor use on the IBM 7090. l2 It is referred to as the Masked SearchProgram. Through the use of specifi- cationcards, the programmer specifies a maskand a block ofstorage to be searched by theprogran. TheMasked Search Program then lists thelocations that are in accordance with thespecification cards. An address mask may beused to

3-22 identify all locations that are related to a particular entry point in a subroutine;after obtaining a list of thelocations havingthis entry point as their address, a listing of the storage area being searched would normally tell where in thesearch area the subroutine is beingentered. Through the useof an op-code mask the programmercan locate all instructionswhich change memory. Onemay alsodetermine how certain storagelocations are used.

3-27. ImprovedApproach toTracing

An approachincreasing the speed and efficiency of tracetechniqEes is presentedin a paperby Eugene I. Grunby. 13 Thisapproach is basicallyan attempt to allow the progranmer toexercise his skill andingenuity in developing the trace routine, and toprovide flexibility in the selection of subroutinesthereby eliminating unwanted processing.

The method of allowing for this flexibility in selectingsubroutines is based on theuse of a singletrace routinewhich makes availablethe same basicinformation to eachof a number ofsubroutines. The basicinformation pro- videdby the trace routine generally includes the origin and destinationaddresses that represent a change insequen- tialaddressing. This approach enables the subprogram to beindependent. A set ofsubprograms each of whichserves a specificfunction may bedeveloped. Each of thesesub- Trograms may callanother, thus a composite of functionscan beselected to meet taskrequirements. Theprogrammer is able to select standardsubprograms in any combination or he may constructhis own.

Mr. Grunby’sapproach also includes a methodof eliminatingexcessive and useless printout. The first step is toeliminate all butthe most essential information, the

3 -23 addresses or origin and destination involved in a branch instruction. A secondstep involves the use of a cyclic table. Trace information is storedin a core tableand is usedfor a selective listing at theend of the job, but because of thelimitations of memory available,the trace information is storedon a cyclicbasis, overlaying from the topto bottom. Options should be provided to allow the programmer to select the lengthof the table and make themost efficientuse of this limited storage area. Thirdly, use of formatoptions or otheroptions which maximize output on the printed line and thatare generally supplied by mostsystems should be empioyed when thetable is beinglisted.

Among the mostsignificant applications for the tracing techniquejust described (as implemented on the UNIVAC 1107) arethe following: 14

a. Dumping ofpreselected memory locationsat the time of eachtraced instruction.

b. Continuoustesting for branches to invalid destinations, and initiatean error routine when theevent occars.

c. Continuoustesting to determine if and when an instructionor 1/0 operation is exceeding storagelimitations and which one is at fault, and initiation of an error routine when this eventoccurs.

d.Computation of the distribution of operation codes inexecuting program; it may atthe programmer'srequest include library and resident monitorroutines.

3 -24

I e. Continuousdetection and recording of points wherecharacteristic overflow, characteristic underflow,divide overflow, occur.

f. Combinationsof the preceding applications.

3-28. The SEFLO TracingTechnique

SEFLO, SEquence-FLOw,15 a tracingtechnique, is describedin a paperby Abrom Hisler.This technique may beused either for FORTRAN V or SLEUTH I1 on the UNIVAC 1108. SEFLO enablesthe programmer to follow changes in contents of selectedregisters and storage locations. The packageconsists of two subroutinesand the sequence cards which call for thecontents of trace whenever requested duringrunning of the object program.

3-29. DYNAMIC DEBUGGING

Tracingand dumping eachhas its advantagesand limitations. Any conceptthat employs the advantages of each in a singletechnique can be referred to by a number of titles, but for thepurpose of zhis discussion shail 5e referred to asdynamic debugging. This concept implies that the process takesplace as theprogram is inprogress and that a certain degreeof analysis is performed,producing diagnostic information in addition to a listing such as thatproduced by traces and dumps. l6 The basicconcept of dynamic debugging is simply to provide the programmerwith a snapshot-type dump each time that predefined criteria are met.

3 -25 The main restrictions placed on dynamic debugging are the resultant size of available memory and the ingenuity required of the programmer writing the analysis program. The following is an illustrative list of the diagnostic information this technique may provide 17

a.Contents of the location counter, showing the currentlocation of the program.

b. Contents of allother control and arithmetic registersalong with the status of suchthings asoverflow indicators.

c.Contents of certain memory locationsor blocks oflocations. The optionto specify mode and format may bedesirable; the locations and formatsare specified in the debugging program andformats are likely to change from one point inthe program to another.

d. A recordof the occurrences of a certaincondition, astallied in a counter.Through the use of such a counter,parameters may bespecified for various tests, i.e., listing will beproduced a certain nmber of times or not produced until afterthe condition has occurred a specified number oftimes.

e. A record(desirable under certain circumstances) of a specified number of the last executed branches.

3 -26 3- 30. FORTRAN DebuggingLanguages

Since FORTRAN was used on the IMP-F projectand is particularlyapplicable to this type of programming, it is well toconsider more specificallythose debugging aids associatedwith FORTRAN. Sincethe compiler naturally checks forsimple clerical errors, and since the FORTRAN language is essentiallyclosed with respect to vocabulary, syntax, andstructure, the compiler is ableto check the basic tests outlined in discussions of preliminary testing.

3-31. One FORTRAX EebuggingLanguage

Sinceearlier FORTRAN compilersdid not include an independentdebugging facility, this often forced programmers torely on themachine language for diagnostic purposes. A 18 debugginglanguage in a FORTRAN format is now available. Thislanguage was designed so that reference may be made to specific statements within the bodyof the FORTRAN program withoutbecoming an actual part of that program. Many of thestatements in the FORTRAN languageitself such as GO TO, CALL, RETURN, and STOP areincluded in this system. Much use is made of subroutines.Conditional situations are particularlyapplicable to the use of logicai IF statements. The DUMP statementprovides a convenientmethod for printing out information when thereare no particularformat requirements. The DUMP statement, much likethe FORTRAN READ and WRITE statements,specifies a list of informationto be listed;these specifications may bewithin the statement or inanother statement referenced by the DUMP statement. Throughthe use of a Hollerith field or quotationmarks one may providenotes or messageswith the information listing..

3 -27 TheLIST statementenables one to reference the same informationby more thanone DUMP statement without repeating a list witheach DUMP statement. When necessaryone maydump theentire program with the statement LIST PROGRAM. Onemay cause dumps at certainintervals, thus limiting the amount of outputthrough the use of an ON statement.

A singlecard must proceed each debugging request or groupof debugging requests. This card may set maximum limits on the number ofrequests honored, regardless of type and the maximum number of lines that may beprinted, all other diag- nosticinformation being lost. This control card almost forces the programmer to set explicit limits on hisdebugging request. However, the limit controlfeatures may be left offof the controlcards; thus, no upperbounds are set.

Sincethis FORTRPIN debuggingsystem allows the execution of a programcomposed of many partsand having been compiledseparately, it is necessaryto specify not only which statementsare to be affected, but in which subprogram (function orsubroutine) those statements are tobe found. Each subprogram is referencedby its name. A code is usedto indicate thatthere are nomore debugging requests.

3- 32. DIAGNOSE, Another FORTRAN DebuggingLanguage

DIAGNOSE1’ is a debuggingprogram that is usedto detectthe following three common errorswhich occur during theexecution of FORTRAN-63 programs.

a. Erroneousa. subscripts.

b. Undefinedb. variables.

c. Erroneous DO- loop parameters.

3-28 When one of theabove conditions occurs during the executionof a program,operation is halted andan error messagewritten on a standard outpu.- unit and an error routine is activatedfor dumping purposes. The errormessage is composedof a statementnumber, variable name,and type of error.

The input when operatingwith DIAGNOSE consistsof sourcedecks, binary decks, and data. DIAGNOSE produces a new soucedeck by inserting calls to certain library subrou- tinein the original source deck. The logicalflows and the program results are in no way affected up to the point at whichthe error occurs.

DIAGNOSE makestwo passesthrough the source deck, as follows :

a. The firstpass produces four lists andoutputs part of the original program alongwith other informationand a scratchtape. The four lists are:

1. Arraysand dimensions.

2. Statementnumbers.

3. Terminalstatement numbers and DO loops.

4. Statementnumbers of replacement and CALL statements .

b. The secondpass performs analysis on DO statements, replacementstatements, IF statements,and CALL statements.During the second pass adjustments are made onstatement numbers toinsure that the flow.of the program remains unchanged. .For each

3-29 of theabove statements, DIAGNOSEmay insert CALL statementsto two or more routinesthat do the following:

1. Identifiesstatement currently being checked.

2. Checks subscripts.

3. Checks thevalue that has been assigned to a particular variable:

4. Checks variableparameters of a DO loop.

DIAGNOSE producesan intermediate program that will requireapproximately twenty percent more memory androughly doublesthe running time of theoriginal program. DIAGNOSE requires a compilableprogram (one that is free of syntax errors).

3-33. BUGTWK, Another FORTRAN DebuggingLanguage

BUGTRAN" is anotherdebugging system that applies to FORTRAN. The checkpointmethod requires nearly exact inter- mediateresults which are frequently unavailable; and the traceroutine, as it is commonly used, is cumbersomeand expensive.Thus, BUGTRAN was developedto help overcome theseshortcomings.

a. The BUGTRAN systemincludes a variabletrace, flow trace,trace of programentries and exits, snapshot dumps, conditionaltermination of the program,and an option to print the comments of thesource program. The optionto apply BUGTW to only specified parts of theprogram is provided for. The systemdoes not place any .requirements

3 -30 onthe compiler, such as generating symbol tables, oraffecting the operation of theprogram. A mechanical means of removing thedebugging from theprogram is alsoprovided for. The following is a summary of BUGTRAN features:

1. Check Variables - a list ofvariables is specified in a BUGTRAN controlstatement. If oneof these variables appears on the left-hand side of an arithmetic substitu- tionstatement or as theindex of a DO statement, it will generate a call to the BUGTRAN outputroutine.

2. Check Flow - all GO TO, ASSIGN and IF statementsgenerate calls to the.BUGTRAN outputroutine.

3. Dump - a statement number alongwith the variablesto be dumped is specified in a BUGTRAN controlcard. The dump is executed immediatelybefore the execation of the specifiedstatement. This is accomplished through a generatedcall to the output routine.

4. Check Entries - a call is generatedto the outputroutine each time that a SUBROUTINE, FUNCTION, END or RETURN statement is encountered.

5. Print Comaents - all comments generate a call to x%e BUGTRAN outputroutine, causing the comnent toappear in the output. 6.Terminate - a statement numberand a conditional IF clause are specified on a BUGTRAN controlcard. The condition is tested immediatelybefore the execution of the specifiedstatement, and if thecondition is satisfiedthe program is terminated.

b. A syntaxtable approach is usedto interpret the FORTRAN and BUGTRAN statements. A syntaxtable is first usedto interpret the BUGTRAN control cards.Another syntax table is thengenerated based on thetype modifications specified by the controlcard to process the FORTRAN statements. Onlythose FORTRAN statementswhich are specified areprovided for in the syntax table. The major advantages of thesyntax table are the following:

1. It is possibleto use the same scannerto recognizethe various types of staternents by merelychanging the syntax tables.

2. Changes inthe source language require modificationof the syntax tables only.

3-34. TESTRAN, IBM System/360~ ~ ~"

3- 35. Introductionto TESTRAN

TESTRAN21, or testtranslator, is a facilityoffered by the IBM System/360Operating System. TESTRAN aidsin detectingfaulty logic by providing printed information con- cernjngthe actual operation of theprogram. This facility describesthe changing contents of storageareas, registers, andcontrol blocks, and shows the manner in which control flowsfrom one group of instructionsto another.

3-32 Requestsfor TESTRAN servicesare coded in a TESTRAN sourcemodule. Each of these statements is a coded TESTRAN macro-instruction,which is replacedwith a series ofcon- stantsby the assembler. In effect, theseconstants are a controlstatement that directs the TESTRAN interpreter to perform a specificoperation. The decisionto perform the nextsequential macro-instruction or a logical branch to anothermacro-instruction is determinedby the operation beingperformed.

3- 36. Procedure

The structureof a TESTRAN statementresembles that of a basicassembler language statement. Every statement includes anoperation code and one or more operands. A symbolic name may precedethe operation code and a comment may followthe operands. The operationcode and first operandcombine to definethe type of operation to be performed and are used as generic names forstatements.

a. The generalfunctions of TESTRAN statementsare thefollowing:

1. Recordingfunctions which provide dumps and tracesof the problem program.

2. Linkagefunctions which control linkage to the TESTUN interpreter.

3. Decision-makingfunctions which provide conditiontesting and condition branching.

4. Branchingfunctions which provide uncondi- tionalbrarAching and subroutine capabilities.

3-33 5. Assignmentfunctions which control values ofvariables in the problem program and of specialvariables used in decision making. b. Duringexecution, TESTRAN is ableto test for predefinederror conditions and take corrective action when necessary.Usually, after corrective action is first taken,the final results of the programare still erroneous,but continued pro- cessingwould permit the possibility of finding theadditional errors.

C. The TESTRAN statementsare combined with the program tobe tested by eitherof the following methods :

1. The TESTRAN andthe problem program source modulesare assembled together and result in a singlemodule.

2. The TESTRAN andthe problem program source modulesare assembled separately, resulting inseparate object modules; these are then processedby the linkage editor to form a singleload module. d. The singleload module is thenloaded and executed. Requestsfor testing services are interpreted by the TESTRAN interpreterwhich is a partof the controlprogram that receives control during programinterruptions. Test informationalong withcontrol information copied from the unloaded formof the load module is placedin a TESTRAN data set bvthe TESTRAN internreter.

3-34 e. The TESTRAN editorprints the test information inthe formof dumps andtraces. Like the assembler andthe linkage editor, the TESTRAN editor is a processingprogram that is executedas a jobstep. It puts test informationinto a meaningfulsymbolic format by usingcontrol information copied from theload module. This control information includes symboltables and a controldictionary for each object module that is partof the load module. Boththe control dictionary, which is produced as a standardfeature of the assembler, and the symbol table,which is anoptional feature of the assembler,are placed in the load module as an optionalfeature of the linkage editor.

3-37. The "RipStopper" Method

A majorpart of the conventional debugging effort rests ingoing back from that point at which the error mani- fests itselfto its pointof origin. Frequently, the faulty programdestroys the information that would permit tracking activity. A conceptthat would permit the identification of anerror condition in time to preservethe necessary diagnos- 22 tic information is presented in a paperby Mark Halpern.

The "ripstopper" concept, presented by Mr. Halpern, requires a processorthat is ableto operate in twomodes (debuggingand production). During operation in the debugging mode, theprocessor would require the following programmer- suppliedinformation:

a. Minimum and maximum limits, andwhere appropriate, incrementsize for each numerical variable in the program. Whi1.e operatingin the debugging mode, all computationand transferof control wouldbe executed interpretively. If any limits areviolated, action specified by the programmer is initiated.

Provisionshould be made forthe option to generate, upondemand, codingthat is interpretivelyexecuted, like thatproduced by the debugging mode, withthe purpose of computingthe execution time of the compiled instructions ratherthan testing their validity.

The print-outof diagnostic information should be structured,interpreted, captioned, and ordered so asto followthe steps taken in normal debugging procedures. Tables shouldbe in tabular form, character strings in linear form, numericsin the appropriate external format and base mode,and labels andcomments should be usedfreely. Parts of a single logicalitem that are scattered throughout the memory must becollected and presented in a unifiedform.

3-38. The WATCHR I11 System

An excellent example of a comprehensivedebugging package is the WATCHR IIIZ3 systemthat was developedat New York Universityfor the CDC 6600 computer. It hasthe ability to providetraces of selected instructions or ofall instructions, ofchanges affecting selected variables, of flow of the object program,of changes affecting selected registers, of selected loads,and of selected subroutine calls. Traps may beprovided on selectedaddresses, selected locations stored into, selected addressesloaded from, and selected operation codes. Provision is made for dumping partof core at anytime and anywhere within

3-36 thefield length, and all of the user's registers at any time. The dumpmay be inoctal, integer, floating point, or alpha- numeric;excessive duplication is suppressed.Error checking facilities areprovided for out-of-bounds jumps, memory references,arithmetic errors, etc., indefiniteand infinite results,invalid stores and loads, infinite loops, incorrect valuesfor selected variables. When anerror condition is encountered, a trace ofthe preceding 600 instructions is automaticallygiven. .The WATCHR I11 system makes provision forthe user to examine core or registers during the run, and forrecovery if fatal errors occur.

The system will operateon any central processor binary code,simulates the action of the CPU, andcollects information as directed byswitch settings. At anytime switches may be set or unset,selections may be made. Alsoat anytime the objectprogram may beplaced under or removed from under WATCHR's control.

The following is a summary of WATCHR I11 featuresand 24 options :

a . Traces: a.

1. Instructiontrace - instructions may be selected bymeans of theiroperstion codzs fortracing; any operation code or combinationof operation codes nay be selected for tracing.

2. Registertrace - registersin anycombina- tionor order may beselected for tracing. Thereafter,whenever a selected register acquires a new numericalvalue, both the oldand new valuesare printed out.

3-37 3. Program trace - thelogical flow or sequence ofinstructions is made availablethrough theuse of the MAP option. Pairs of addresses will be printed out periodically. The occurrenceof a branch is indicated with starting of a new pair of signals.

4. Memory reference(load) trace - analogous to the trace of changedlocations except that it providesfor a long comment givingthe functionserved by the variable being loaded. The purposeof this feature is to.enable theprogrammer to see how theprogram under observationactually operates.

5. Subroutinecall trace - analogousto the registertrace. Return jumps aretraced and space is providedfor comments denotingthe purpose of eachsubroutine. b . Traps: b.

The trap is usedto initiate the trap routine. A traproutine is anyinstruction or set of instructions the programmer may wish to execute if trapconditions are satisfied. Traps always occurbefore execution of the instruction in question. Any nunberof traps may be set and they will be able tG operatesimultaneously.

1. Trap on operationcode - the programmer may assignthe starting address of a traprou- tineto any operarion code or combination of operationcodes.

3-38 2. Trapon address - when programcontrol arrives at a specifiedaddress a trap routine is initiated.

3. Trapon storage into a specified location - analogousto a trap onaddress except that theaddresses selected are locationsinto whichstores may be made or areexpected to be made.

4. Trapon load from a specifiedlocation - analogousto a trap on storageinto a specifiedlocation except that the address chosen is to betrapped on when its con- tentsare loaded into a register. c. Reports :

1. Snapshot dump - a parameter list is used to dump currentcontents of selectedlocations.

2. Interpreted dump - this dumpmay becalled on asoften as desired and may bein octal, integer,floating point, BCD, or alpha- numeric.Provision is also made forgiving analphanumeric label to each dump.

3. Reports - these are givenautomatically when a fatalerror is encountered.Reports con- sist of thefollowing:

a. Up to 50 mostrecent branch instructions.

b. Up to 50 mostrecent return jumps.

3-39 c. Up to 50 mostrecent stores.

d. Up to 600 mostrecent executed instructions.

A programrunning under the control of WATCHR I11 will takefrom 40 to 300 times longer. WATCHR I11 requires 16K ofcontrol memory. Thenumber of test runsrequired in thepreparation of a programshould be about 5 timesless withthe judicious use of thepackage. With the employment of WATCHR I11 theoverall usage of computer time should be lessthan or equalto the total computer time used without WATCHR 111. The total programpreparation time should be shortenedby a factor of 5 to 10.

3-39. TIDY AND EDIT FOR FORTRAN

Two programshave been developed for the purpose of editing FORTRAN programs. The employmentof such programs would greatlyfacilitate future changes in the program and thedebugging of suchchanges. The correction of errorsthat appearafter the program has been in operation for some time wouldbe greatly simplified. The following is a summary of these two systems.

3- 40. The TIDY Program

TIDYz5 processesthe old FORTRAN programroutine-by- routine,and prepares and punches a new version of theprogram. The new programhas the Eollowing characteristics.

a.Statement numbers are left-justified and in ascendingconsecutive order.

3 -40 I

b.Only those statements which are referencedby otherstatements are assignedstatement numbers.

c. Statement number references are updatedto con- form to the new statement number assignments.

d. FORMAT statementare collected from within the body of eachroutine and placed at theend.

e. The only FORMAT and CONTINUE statementsretained arethose that are referenced within the routine.

f. Spacesare deleted or inserted as necessary to ensureuniformity and improve readability.

g. Comment cardsare inspected for comments starting inthe statement number field; if found,they areright-shifted so as to start in columnseven.

h.Consecutive blank comment cardsin excess of two aredeleted.

i. All statementsin each new routineare labeled incard columns 73 through 79 with a unique letter-numbercombination. The alphabetic characzer(s)indicate routine, while the number indicatesthe position of thestatement in the routine.

j. Column 80 of each END statement is punchedwith

a - 'I sign(11 punch). This will permit automaticpage ejection when listing TIDY- processedroutines on machines that have the "x-skip" feature. k. Certain FORTRAN I1 statements are rewrittenas FORTRAN IV statements.

A number ofoptions are availablewhich enable one to modify some of theabove characteristics. In additionto theediting function, TIDY offers a limited set ofdiagnostics. Errorsand trouble areas such as missing or duplicate statement numbers,incorrect parenthesis counts, illegal DO-loop indexing, illegalstatements, and inaccessible parts of theprogram are noted.Pseudo-statement numbers are generated when references arefound to nonexisting statement numbers toenable the programmer to make corrections with a minimum of repunching. One optionprovides a list ofcorresponding old and new statementnumbers.

3-41. The EDIT Program

EDITz6 is very much like TIDY. Characteristicsa, d, f, g, and j of TIDY arealso performed by EDIT. The major emphasis of EDIT dealswith the renaming of variables. The variable names used in writing FORTRAN programsoften make theflow of the program hard to follow. Natural conditions whichare largely responsible for the above condition include 27 thefollowing:

a. Programmers may usevariable names thatare convenient to work with but are devoid of ne aning .

b. Awkward expedientvariable names often result fromhasty changes made duringthe debugging phase.

3 -42 C. Poorselection of variable names was made initially, but later, after the program is almostcompleted, the programmer arrives at a greatlyimproved symbolism that he would prefer to use.

It is oftendesirable to change the names ofvariables butthis would entail an amount ofwork that is inexcess of thevalue gained. However, EDIT provides a simplesolution asdetailed in source document.

3-42. AUTOMATIC FLOWCHARTING

Recently,various proprietary systems have been put onthe market that aid in debugging the original source program andprovide documentation, by generating from the source program a flowchartand diagnostics that give a pictureof theprogram logic in its earlieststages, even before assembly if desired,thus facilitating debugging.

3-43. The AUTOFLOW Svstem

28 One ofthese flowcharting systems is called AUTOFLOW , marketed by AppliedData Research, Inc. AUTOFLOW cangenerate flowchartsdirectly from source programs written in assembler language, FORT", or COBOL. The inputto the computer is the AUTOFLOW programand the user's source deck (or tape) ; theresulting computer printout is a flowchartusing standard symbols(decision, processing, connectors, terminals, etc.) , plus a listingof the cross-reference table, and a listingof diagnostics(if any). Theprogram commentsbecome a signifi- cant part of the flowchart.

3 -43 Thistype of flowchart can make instantly visible to theprogrammer any errors in missing destinations in branching instructions,undefined external references, errors in address arithmetic, etc.

Afterthe initial flowchart has assisted in correcting thecoding, then the programmer has the optionof improving theclarity of the flowchart for final documentation by repunchingand rerunning the deck, adding special chart- orientedcodes to the assembler language, FORTRAN, or COBOL cards.Through the use of thesecodes, the level of the flowchart detail may be made moremeaningful.

3- 44. TESTING

3-45. Purr,os es

29 Program testing has two basicpurposes.

a. To insurethat the program has been coded correctlyand that the coding matches the logicaldesign.

b. To insurethat the logical design matches the basicrequirements of thetask as it is definedin the job specification.

As eachsegment of the program is developed,rigorous test data should be preparedand that segment should be tested.After testing each segment separately, the entire sytem is ready for testing.

3 -44 3- 46. Prob lems

The factthat the program is operativeand runs to a satisfactorycompletion does not insure that all of the exceptionalconditions, and their permutations and combinations,have been tested. The considerationof exceptional and unusualconditions frequently accounts for a largeper- centageof the program's instructions. Unless one is careful to providefor these exception conditions in his test data, it is quitepossible to reach the end of the program while checking out only a small proportion of theprogram. Because of the many combinationsand permutations of Conditions inherentin a givenprogram, it is practicailyimpossible to testall conditions which may actuallyoccur. Tnus it is not uncommon for a progranthat has been operating success fullyfor some time to fail oneday due to anunusual set of conditions.

3-47. LogicalTree

The useof a logicaltree can be a valuableaid in selectingthe various combinations of inputdata for testiilg purposes.This technique also aids in locating progrzm erro-fs. The systematicformulstion ~f testdata will eliTitina-ce duglicationof test sitaaciorss and will significantly expand the number ofdifferent test co1:ditions. Through zhe systax- tic selection of ailrealistic combinations of input date., theprogramer niay test all segments of a given program.

3-48. MaintainingTest Data

It may bedesirable to maintain a testsequence that may be runperiodically. One cannotassume that a featwe whichworked Gn one version will work on another. It may

3 -45 alsobe desirable to provide a set of test data that will generatemost system error diagnostics. 31

3-49. SatelliteTest Data

Data thatare used in testing programs that are to pro- cesssatellite telemetry data are derived from thefollowing somces. 32

a.Data generated manuaily by theprogrammer.

b. Dataacquired from the satelliee during groundtesting.

c. Actualdata tapes from previous satellites which havethe same basictelemetry format.

The first two sourceshave a majorlimitation in that thetest data produced do notreflect adequately the actual perturbationspresent in telemetrydata. The thirdsource partially overcomesthe above limitations but it too is or' limitedutility. Often none ofthe data available from pre- vioussatellites have a suitablz format or have beeil obtained viathe same set of datalinks as thegiven satellits. Also informaxionconcerning the specific type and location of mise perturbationsin a givendata tape is notavailable to the programmer.Thus theprograx ;nay notdetect a ?articular perturbation in the data and the programmer will beunaware of thisdeficiency.

3 -46 3-50. DataSimulation Computer Program

Because of theseshortcomings and the necessity of highreliability, another source of datahas been developed - DataSimulation ComputerProgram. The benefitsderived from this programinclude the following:

a. Test data will be provided that realistically take intoaccount the various specified noise conditions.

b. An increaseddegree of reliability other than achievedthrough the use of other sources.

C. Time and effortspent in generating test data is reduced.

d. Reductionin clerical andkeypunch errors.

e. Reducetime of testingcycle.

f. Usefulcriteria for acceptingcontractor- producedprograms.

The DataSimulation ProgramS3 was written for the UNIVAC 1107 computer. A nighdegree of flexibility was incorporatedto provide for differences in taieilletry systexs and fcrmats,varying degrees and types of noise ccnditions, variationsin experiment-dala characteristics, differences informats, etc. The userprovides a deck of punchedcards containingall definitions and parameters for the simulation alorigwith user subroutines for speciaicomputations. The primaryoutput is a digitaltape which contains the sinulated

3 -47 test data. A secondaryoutput is a listing of inputpara- meters, selecteddata channel and record printouts, errors insertedduring simulation, and summary statistics foreach simulated file.

3-51. PROGRAM CORRECTION

Basicallythere are two approachesto progran correction - re-compilation and load-tinepatching. ‘When a large programand a smallerror are involved, re-compilation is inefficient and is of greaterexpense than the correction warrants.Load-time patching does not provide a listing thusthe documentation does not match the card deck. For the programmer who knows onlythe higher-level language there is nochoice, he must re-compile. The option is availableto the programmer who hasthe program listing and knows the ass enb ly 1anguage .

A third possibility for makingprogram corrections exists. 34 This approacheEploys a miniatureassembly program,packaged as a closedsubroutine, which is loaded with tne objectprogram that is to becorrected. The routine is activated by the programmer who specifiesthe input and outputbuffers and key words which indicate patching loca- tionsin the input stream. The key-wordsignals that a patchlocation follows; the input stream is divertedto a work area,where the symbolic language patch is assercbled. Nhen the key word forthe end of thepatch is ezcountered, control will betransferred to thepatch or backto the objectprogram as directed.

Severaladvantages are incurred through the use or’ thissubroutine technique. IC is fasterthan either of -the other two techniques and it providesdocumentatioz. Another

3 -48 advantageover the two conventionalmethods is that it is notconfined to unconditional load-time changes. It may be called upon to modifythe object program at any time during therun, and these changes may be made contingent onany conditionthat may betested by theprogrammer. Several versions of the same procedure may betested during one run, thisis.made possible by having the constant availability ofan assembler. The reducedturn-around time can be an importantconsideration.

3- 52. US’TAXTIXG

Aa areaclosely related to testing is that of restarting.Often mEch timeand expense may beshved by allowingfor the restarting of a program atvarious points. By employing thistechnique one does not need to start at thebeginning of theprogram each time an error condition occurs. The technique of intermittentrestarting may be implementedby incorporating a sequence of checks,perhaps atthe end of eachsegment. If any of thesechecks reveals an errorat rhat point,o;?erations should cease and the 2rcgr;;n res’;artedzt the last yoint -chat wks knawn to be carrect after sorrezti~~~sare implemznted.. in the event that a prcgram is ‘LO be .--&startedar an intcrzzdiate point, clx ‘c3 an elror checkstop, oparator nishar, 3r macl;ine salfunctioil, it is rxzessary eo savs inforhriatioc about the seatus of t;?e program 8-t xhaz point.S~ch irAforxLaximwGulcl include the contents of all memory szoragz &~-~zs>both internal and external. One approachto saving this information is to dump memory atevery check point, always savir,g

vclie ” las’i duz.3. Upon restarting, this inzorixtion wo~ldbe

” relocated. 33

3-49 SECTION IV ON-LINE-DEBUGGING

4-1. ON-LINE DEBUGGING TECHNIQUES

Althoughthe main emphasis of thispaper is intended tobe on conventional or batchdebugging, some mentionof on-linedebugging is inorder. The currentconsensus among computerprofessionals is thaton-line applications repre- sentthe wave of thefuture. 36 On-linecomputer activity probablyrepresents about one percent of thetotal present computeractivity; however, in five years it may represent fifty percent and in ten years it may represent nearly all computeractivity. 37

On-linedebugging is conductedby a programmer who is indirect communication with the computer. The typewriter or teletype is most commonly used. The programmer makes changes, tests, thenagain makes changesin a continu- ousprocess with quick response from the computer until satisfactoryresults are achieved. On smallcomputers or inthe early days of computing when thecomputer was com- pletelydedicated to the programmerand hisprogram, the on-line("hands-on") mode of debugging was a standardprac- tice;but now it is notused as much,where programs are run"remote" on large computers. However, the arrival of large-scaletime-sharing systems has made this mode of operationfeasible on largecomputers.

Much of the work done inthe area of on-line debugging hasbeen described only in unpublished reports or passed on orally. However, anexcellent paper by Thomas G. Evans and D. LucilleDarley pre3,ents a survey of on-linedebugging techniques. 38 Includedin their paper are some possible futuredevelopments as well as a list of references. 4-2,. CRITERIA FOR AN ON-LINE DEBUGGING SYSTEM

The followingprinciples may beconsidered as good 39 criteriafor an on-line debugging system.

a.Flexi.ble control over the program must be pro- videdto the programmer. The programmermust beable to specifythis control in terms of naturalunits, small andlarge, of thelanguage inquestion and be able to carry this control down to thefinest level of detail.

b. Usingthe notation of thelanguage of' theprogram theprogrammer must be able to examine and"incrementally" modify both data. and progran: at. anytime.

c. The debuggingcontrol language should be designed so that a minimum of typing is required andinformation provided the programmer is com- patible,concise, and aids rapid comprehension.

d. Provisionshocld be made forthe automatic updzting of theussr's symbolic'fiie lio reflec; thein-core re2resatation of the program.

4-3. THE PROGRAMMER-CONTROLLED BREA.KPOINT

Perhapsthe central notion of on-linedebugging is the?rogrammer-controlled brezkpoint. 40 Thisconcept allows the 2rogramrner tc specify, generallyin symbolic forms, a point or points in th.e program at which he wishes to inter- rupt theflow and. return to the debuggingroutine. Upon enteringthe debugging routine, th.e si2.t.e of theactive

4-2 registers is storedin order to permit subsequent continua- tion from thebreakpoint. The programmerexamines hisprogram at this breakpoint and may make anydesired changes beforecontinuing.

4-4. ASSEMBLER-LANGUAGE PROGRAM DEBUGGING: THE DDT SYSTEM

When consideringon-line debugging facilities a separation may be made betweenthose that deal with the assemblerlanguage and those that deal with higher level languages.

DDT41 (Digital DebuggingTape) is oneof the better known on-linedebugging programs that deals with an assembler- languageprogram. One ofthe most important characteristics of this program is the care devoted to thedesign of the typingconventions. Single-letter commands and a structure in whichfrequently desired states can be easily reached from thepresent state minimize typing and aid rapid inter- action.Convenient ways of typingcontents of a given register in variousformats such as symbolic, decimai, or octalare also providea. A number ofextensions have been mzde on the DDT system. The following is a suma-ry of som 42 of theseextensions.

a.Because DDT canaccept instructions in symbolic assembler-languageform, it alreadynearly servesas an "on-lineassembler" capable of processingthe on-line writing and testing of smallprograms. In conventional DDT, theintro- duction,in a lineof coded input, of a symbol notpreviously defined by the programmer results inan error. Edwardsand Minsky have added to theconventional 3DT an"undefined symbol"

4-3 feature.This feature results in a special symboltable entry. These entries are linked togetherand when thesymbol is ultimately definedby the programmer its previousoccur- rences are filledin appropriately. b. DDT providesan unlimited freedom to patch a program.This is accomplishedby inserting the desiredcoding in some availablespace, then planting a transferto this insertion whenever desired.Sometines extensively patched programs result. The process of editing or cleaning up such a program is longand susceptible to errors. At least two attemptshave be'en made to facilitate this editing effort.

1. One versionof such an editing facility was developedby Deutsch and Lamson. 43 In responseto a requestby the programmer to insert a specifiedpiece of symbolic coding,the debugging progran performs the following :

(a) Edits "Le chslnges intothe synbolic progranstored on the drum.

(b)Assembles the addition into a "paecli area" of coreand automatically links theresulting code to the main program bycopying instructions and inserting transfers.

4 -4 Thus,the patched binary program in core is equivalentto the edited symbolic ver- sionstored on the drum. At thetermination of the debuggingsession the updated symbolic program is stored among theprogrammer's files.

2. Anothereffort to solve the same problem 44 was developedfor the "460 computer. As inthe previous approach, the on-line programmer presentsinsertions, dele'tions, or a mixtureof both, written in a symbolic assemblerlanguage, to the debugging program. The debuggingprogram performs the following:

(a)Symbolic changes are stored along withthe original symbolic program. At theend of thedebugging session, bothare edited andthe programmer is providedwith an updated symbolic file.

(b)Instead of the patch being made to correspondwith the programmer's changes,the part of the program affected by thechange is relocated appropriatelyin core. This reloca- tionprocess is possibleonly because therelocation information resulting from the assembly of theprogram is collected into a list structurewhich is usedby the debugging program whenever a change is called for and it is thenupdated accordingly. The list

4-5

I structure is alsoused by the relo- cationloader. The symbol table passedby the assembler to the debuggingprogram must also be updatedeach time.

3. Althoughthis approach may betime-consuming, it hasseveral advantages over the "automatic patching" approach :

(a) The patchedbinary and the edited symbolicprogram may behave differently in situations wherethe location of words incore relative to each other is important.

(b)Core may be leftin a ratherconfusing statewhich may require relatively frequentlyreassembly for readability. c. In additionto the flexibiiity in the piacement andmoving of breakpointsprovided for in DDT, a facilitywhich permits the programmer to make thebreakpoints conditional has been added to some systems.Tests are supplied on-line by the programmerand areexecuted when thebreakpoint condition is reachedto determine if control is tobe turned over to the programmer. Several systemshave implemented the use of "canned tests."Older versions and a few ofthe newer versionsof DDT providean option whereby the programmercan specify a certain number of times a pointmust occur before the break can beexecuted.

4-6 I-

d.The provisionfor some form of instruction-by- instructiontracing may bedesirable. Generally such a featurehas been omitted in favor of breakpoints.Tracing facilities may share much of the breakpointmachinery. The programmer shouldbe able to specify a location in his programand ask either for control or for a printing or both whenever a specified point is reachedand associated conditions are satisfied. 45

e. Anotherdesirable but not widely found feature of currenton-line debugging systems is extensibility.Extensibility provides the capability interms of availableprimitives. 46

f. An optionoften found in the DDT systemallows theprogrammer toconduct a searchbetween specified limits incore for all wordsmatching a given word in the bits specified by a given mask. 47

4-5. HIGHER-LEVEL LANGUAGE DEBUGGING

4-6. TheLISP System

The conceptsor techniques of on-lineassembler languagedebugging are the same asthose enployed in the on-linedebugging systems of higher-levellanguages, zhe systemsfor higher-level languages are generallybetter developedand more widely used.

4-7 One well-knownon-line debugging system developed forhigher-level languages is the LIS.P48 system. The following is a summary of some ofthe features of various LISP^' systems .

a.Extensive tracing facilities were originally made availableto the on-line programmer. This feature was laterextended and made conditional in both the MAC and "460 LISP systems.

b. An editingprogram, not a conventional text editor but a programpermitting the user to modifythe list in which LISP functions are stored for interpretation, is providedfor on some LISP systems. The editingfeature has greatlyfacilitated the ease in makingprogram changes.

c.Conditional breakpoints which may beinserted at anypoint in a LISP functiondefinition were providedfor in some LISP systems.Conditional breakpointsand tracking make it possibleto usethe full capacity of the LISP language for on-linecomposition of theconditions. This permitsrelatively simple coding of anelaborate logicalcondition for which the counterpart in assemblylanguage might be quite complex.Greater selectivity may Sescnieved by suppressing irrel- evant t:-ackingand brezkpoints through the "canning" of a few specialpredicates used in writingconditions. It is possibleto find an errorcondition at a breakpointwhile running a test czse,call the editor to make a correction, runthe program on a simplertest case to verify

4-8 thecorrectness of thechange, then continue withthe execution of the original test case fromthe breakpoint.

d.The MAC and "460 LISP systemscontain both an interpreter for LISP functionsstored as list structuresand a compilerfor LISP functionsin symboliccode. These interpreted and compiled functions may beintermixed. The interpreter makes implementationof debugging facilities relativelysimple. The insertion of breakpoints at arbitrarylocations is easily implemented by modifyingthe list structurecorresponding to theprogram.

4-7. The QUIKTRAN System

QUIKTRAN'O is a debuggingsystem based on the inter- pretationof FOXTRAN statements.Modifications of the FORTRAN program are made freely by inserting and deleting statements. The capabilityof examining and modifying variables is provided. A number of modes oftracking are available.Extensive run-time diagnostics are made possible by theinterpretive mode. The systememploys a form of non-conditionalbreakpoint capability. The non-conditional breakpoint means that a statementcan be inserted at any pointin the program which, when reached,has the effec-2 of transfzrringcontrol to -the progra;nmer.

4-8. The IncrementalCompiler

The conceptof an "incremenral compiler" is presented by K. Lock at the California Institute of Technology. 51

4-9 The basicidea is tocompile each program statement .separately andplace the resulting code, together with a copy of the symbolicform of thestatement, certainpointers, and other information,depending on thetype of statement,in a con- tiguousblock of core,These blocks are linkedtogether in lists. With theimplementation of this concept only thoseportions of a program tobe changed need to be recom- piled.Insertions and deletions at thestatement level proceedwith modifications of the list. The breakpoint capabilityoccurs at statement level since control is returnedto the monitor between each statement.

4-10 REFERENCES

1. Computer-.Program,-Dgc.ymentation andDebugging (Wash- ""Zgton: ~ CEIR, Inc., 1968) p. 5. 2. GordanDavis, An Introductionto Electronic Computers (New York: Mc-Eill Book Co.,1965) p. 199. 3. Herbert D. Leedsand Gerald M. Weinberg,Computer

"Programming - Fundamentals, 2nd ed. (New York: McGraw- B~llBook Co., 1966) pp. 362, 363.

4. CEIR, Inc., op. cit., p. 45. 5. Philip M. Sherman, Pro-gramming andCoding Digital Com u-ters, (New York: JohnWiley and Sons, Inc., *404, 405.

6. Ibid .Y PP. 413, 414. 7. J. R. Dingeldineand D. E. Bear,Reference Manual for

"the~ SDC-SHARE Opera.ting_Sys-tern Volume 9 - De- (SantaMonica: System Development Corporation, 1964) pp. 3, 4, 12, 19.

8. CEIR, Inc., op. cit.,p. 41.

9. RudolfBayer, et al, The ALCOR Illinois 7090/7094 Post Mortem Dump (Illinois:" Boeing Scientific ResearchLaboratories, 1967), p. 1.

10. Ibid., pp. 2, 3.

11. UNIVAC 1108 ExecutiveProgrammerp s Reference(Sperry Ranh-Corporation, 1966), Section 17, pp. 1-15.

12. G. S. Stoller, Masked SearchProgram, (Bedford: MitreCorporation, 1965), p. 2. 13. Eugene I. Grunby, An ImprovedApproach toTrace Routines,(Greenbelt-: Goddard ~~ Space Flight Center, 1965),pp. 1-4.

14. Ibid.,pp. 3, 4. 15. A. Hisler, "SEFLO-SequenceFlow, a ProgramDebugging Tool,"(Greenbelt: Goddard Space Flight Center, 1968), PP. 1, 2.

R-1 16. Daniel D. McCracken.Harold Weiss and Lee Tsia-Hwa. Programming Business Computers, (New York: John ' Wileyand Sons, Inc., 1959), p. 236. 17. Ibid ., p. 237. 18. Leeds, op. cit., p. 387. 19. J. A. Thompson,Diagnose, A Routineto Debug FORTRAN -mi&-Pro rams, (Oak Ridge:Union Carbide Corporation, 20. Earl X. Fergusonand Elizabeth Berner, "Debugging sys tems of SourceLanguage Level ,'' Communications of ACM 6, 8 (August 1963), pp.430-434. 21. IBM System/360Operating System TESTRAN (IBM Corpor- ation1967), pp. 8-13.

22. Mark Halpern,"Computer Programming: The Debugging EpochOpens ,'I Computersand Automaticn 14, 11 (November 19651, pp. 28, 29.

23. E. Draughon, WATCHR 111, A ProgramAnalyzing and DebuggingSystem for the CDC 6600 User's Manual (New York: New York University,1966).

24. Ibid. 25. Harry M. Murphy, Jr., TIDY A Computer Code for Renumberingand Editing FO4TRAN SourcePrograms. (AlbuquerqGe: Air Forze Weapons LaboratoG, 1966).

26. Forest McMains , EDIT, A FORTRAN Program for Renaming Variablesin a , (Dover, New Jersey, Picatinny

27. Ibici.

28. _iZuTOFLOW Cmputer DocurtectaeionSys ten (Applied Gata Research,Inc., 19673. 29. Dick H. Srandonand Frederick Kirch, "Standards for

30. Joan C. Millerand Clifford J. Maloney,"Systematic MistakeAnalysis of Digital ComputerPrograms ,It Communications of the ACM 6, 2 (February1963), PP 58-62

R-2 31. CEIR, Inc., op. cit., p. 42. 32. Bernard G. Narrowand Richard C. Lee. A Generalized

Sa-telliteTelemetry ~ .~Data Simulation Program, (Greenbelt:Goddard Space Flight Center, 1966), p. 2.

33. Ibid -9 PP- 1-4. 34. Halpern, op. cit., p.30. 35. Sherman, op. cit., p. 407. 36. CEIR, Inc., op. cit., p.48. 37. Ibid.

38. Thomas, G. Evansand Lucille D. Darley,On-Line DebuggingTechniques: A Survey(Bedford: Air Force CambridgeResearch Laboratories, 1966). 39. Ibid ., p.48. 40. Ibid ., p. 39. 41. Ibid.,p. 39.

42. Ibid -9 P. 39. 43. L. P. Deutschand B. W. Lamson, "DDT Time Sharing DebuggingSystem Reference Manual ,I' (California: Universityof California, 1965).

44. Evans, op. cit. 45. Ibid. 46. Ibid. 47. Ibid.

48. Daniel G. Bobrow, et al, The BBN LISP System, (Bedford: United States Air Force,1967). 49. Evans, op. cit.

50. T. M. Dunn and J. H. Morrissey, "RemoteComputing - An ExperimentalSys tern,'' Proceedings SJCC, 1964.

51. K. Lock,"Structuring Programs for Multi-Program Time-sharingOn-Line Applications," Proceedings of FJCC, 1965.

R-3 BIBLIOGRAPHY Books

Davis, Gordon B., An Introduction"~~ to-Electronic Computers, New York: McCr-aw-Hill Book Company, 1965. Leeds, Herbert D., andWeinberg, Gerald M., Com uter ProgrammingFundamentals, 2nd Ed. NeweMcGraw- Kill Book Company, 1966. McCracken,Daniel D., Weiss,Harold, Tsia-Hwa, Lee, ProgrammingBusiness Computers, New York:John Myley andSons, Inc., 1959.

Sherman, Phillip M., Proporainming-___._-_ and Coding D.igital Computers, New York: Johnilley anr.ozs-,"Inc.l"l963

Manuals

AppliedData Research, Inc., AUTOFLOW ComputerDocumentation Svstem.October 1967.

Deutsch, P. L. and Lamson, B. W., DDT". Time- Sharing- Debugging Syst-em ReferenceManual, Document0.40.10 (Rev.) , University of California, May 1965. Dingeldine, J. R., andBear, D. E., R.eferenceManual for the

i_SDC-SHARE . _iOperating c__ . System". ..~- .Vo'lume 9 - Debuggin S stem. Reportby System Deveropmeht Corporation, Sant: Mznica, California, December 1964.

IBM Corporation. IBM System/360Operating System TESTRAN. "- "" SystemsReference Library. Form C28-6648-0 File Number S360-37.February 1967. Sperry Rand Corporation. UNIVAC 1308 ExecutiveProgrammer's ReferenceManuLl, 13-66."

B-1

I Repor-ts..

Bayer,Rudolf, et al. The ALCOR Illinois 7090/7094 Post Mortem Dump (AD m14). InformationSciences Report No. 3, InformationSciences Laboratory, Boeing ScientificResearch Laboratories, August 1967. Bobrow, Daniel G., et al. , The BBN LISP System.Report preparedfor United States Air Force,Bedford, Massachusetts.July 1967. Dunn, T. M. , andMorrissey, J. H. , "RemoteComputing - An ExperimentalSystem," Proceedings SJCC, 1964. Evans, Thomas G., andDarley, D., Debug,an Extension to CurrentOn-Line Debugging Techniques, Report by Air ForceCambridge Research Labs., Bedford, Mass., November 1964.

Evans , Thomas 2., andDarley, D. Lucille,On-Line Debugging Techniques: A Sxrvey.(AD650016). Report by Air ForceCambridge Research Laboratories, Office of AerospaceResearch, i. G. Hanscom Field,Bedford, Massachusetts,January 1967. Grunby,Eugene I. An ImprovedApproach toTrace Routines, (N65-29802, X-545-65-15)Report by GoddardSpace FlightCenter, Greenbelt, Matyland. February 1965. McMains , Forest. EDIT, A FORTRAN Program for Renaming Variablesin a Source Pro ram. report byData Processing Sys tems Offihcatqnny Arsenal, Dover, New Jersey,July 1967. Murphy, i-iarry, M. , Jr. TIDY, -4 Computer Code for Renunbering and Editing FORTRAN SourceFrograms. A report by Air Force Weapons Laboratory,Kirtland Air Force Base, New Mexico.October 1966.

Stoller, G. S., Masked SearchProgram (AD 610062) A Techni- cal DocumentaryReport Nc. ESD-TDR-64-629) Prepared byMitre Corporation, Bedford, Massachusetts. January1965.

B -2 I

Thompson, J. A., DIAGNOSE, A Routineto Debug FORTRAN Proarams(N66-23235). Report for Oak RidgeNational mryoperated by Union Carbide Corporation for the U.S. AtomicEnergy Commission, June 1965.

Articles andPeriodicals

Brandon, Dick H. andKirch, Frederick "Standards for Computer

Programming" Co2uters~~ ~ and Automation, May 1964, pp.22-28, 43, Ferguson, H. Earl,and Berner, Elizabeth, "DebuggingSystems at a SourceLanguage Level," Communications of ACM 6, 8 (August1963), 43-434. Halpern,Mark, "Computer Programming: The DebuggingEpoch Opens,"Computers and Automation 14, 11 (November 1965), 28-31. Lock, K., "StructuringPrograms for Multi-Program Time- SharingOn-Line Applications ," Proceedings of FJCC, 1965. Miller,Joan C., andMaloney, Clifford J., "Systematic MistakeAnalysis of Digital ComputerPrograms ," Communications of the ACM, 6, 2 (February 1968), 58-62.

Unpublished Material

CEIR, Inc.,Institute for AdvancedTechnology, "Computer ProgramDocumentation and Debugging ,I1 Documentation andDebugging Seminar, Washington, 1968. Eislzr , Abron. "SE2LO-SEQUENCE FLOW, A ComputerPrograa debuggingTool," Preliminary report by Goddard SpaceFlight Center, Greenbelt, Maryland, January 1968.

B-3 APPENDIX

SELECTED DEBUGGING REFERENCES

The following is a selected list of sources that deal in some way with debugging. Abstracts of many appear in the Technical Abstract Bulletin Index published by the Defense Documentation Center (DDC), the Research and Development Reports abstract journal published by U.the S. Department of Commerce, the Scientific and TechnicalAero- space Reports (STAR) index published by the National Aeronautics and Space Administration, and the Computing Reviews pubiished by the Association for Computing Machin- ery. Key words and phrases havebeen noted for someof the sources. "AD" numbers refer to DDC documents and "S" numbers refer to STAR documents.

A-1 APPENDIX Books

Davis, Gordon B., An Introduction to Electronic Computers, New York, McGraw-HillBook Company, 1965.

Leeds, Herbert D., and Weinberg, Geraid M., Com uter Programming Fundamentals, 2nd Ed., New";-M or:L cGraw- Hill Book Company, 1966. ?ages 358-394 Program testing, preliminary testing, assembly output, test cases, philosophy of segmentation, aids to testing, SHARE (DB) IBM 7090, dumping, conditional debugging macros, tracing, program testing, program testing inFORTRAN, FORTRAN debugging system Library of Congress 65-21588

McCracken, Daniel D., Weiss, Harold, Tsia-Hwa, Lee, Programming Business Computers, New York, John Wiley and Sons, Inc. 1959.

Randell, B., and Russell, L. J., ALGOL 60 Ixplementatia, A.P.I.C. Studies in Data Processing, No. 5, Academic Prtss, 1964, xir +418. Compiler, with error-checking and debugging facilities Source: ACM Computing Review

Scott, Theordore G., Computer ProgrammingTechniques, Garden City, New York, Doubleday and Company, Inc., 1964.

A-2 Sherman, Philip M., Programming and Coding Digital lT&"Com uters, New York, John Wiley and Sons, hc.,

Stark, Peter A., Digit-a1 Computer Programming, New York, Macmillan Company, 1967. Program debugging

A-3 Manuals

Appel,Klaus, Reference Manual for Easy, An Automatic ProgrammingSystem for the ALWAC. Computer,Report byUppsala University, Sweden, October 1963.

ALWAC debugging sys terns

Deutsch, P. L. andLamson, B. W., DDT Time SharingDebugging SystemReference Manual , Document #30.40.10(Rev.), University of California, May 1965.

Dingeldine, J. R., ReferenceManual for the SDC. - SHARE erating System, Volume 9, Debuggin-g ~Systern, eport bySystem Development Corporation, Santa Monica,California, December 1964.

SHARE, debugging, SOS macros AD-456058

Draughon, E., WATCHR I1 m- Analyzing- and. gebugging Sys tern er's Manual.,by Report CourantInstitute of MathematicalSciences, New York University, New York, July 1966.

CDC 6600, debugging system N68-81549

Griffith, E. L., SCF Computer ?Togram SystemsManual Trace Program,Report by System DevelopmentCorporation, SmzaMonica, California, November 1963. Trace,debugging tool AD-428179

A-4 I --

IBM. IBM 7090/7094"_ IBSYS-..>-."_ Operating System Version 13 IBJOB Pr-oce-ss-or-pebugglng. PacEe. Systems Reference Library,(January 1965). File No. 7090-27 Form C28-63930

ZBM. IBMSystem/360ORerating System Programmer's Guide ;;"- D~bugg """""Fileing. No. S360-20, Form C28-6670-0.

IBM Corporation. IBM System/36O OperatingSystem TESTFUN. SystemsReference Library. Form C28-6648-0 File Number S360-37.February 1967.

Sperry Rand Corporation. UNIVAC 1108 .ExecutiveProgrammer's

Reference~. ~ Manual, 13a6-67""p ~~~

A-5 Reports

Ammerman, Anne B., Diesen, Larry R., and Thombs, Herman W., Displaytron - A Graphical Displ~ayOriented Conversa-

Virginia, July 1967. Displaytron, on-line, FORTRAN IV, 360/40 AD-656583

Armour Research Foundationof Illinois Institute of Technology, Advanced Studiesof Computer Programming, Report prepared forU. S. Army Signal Research and Development Agency, January 1961. MOBIDIC program debugging systems AD-251951

Arnold, L. J., 160-A Utility Program Descriptions Milestone 11 160-A Core Dump onto Printer, Report by Syst-em Development Corporation, SantaMonica, California, December 1963. Core dump AD-427900

Barbier, John, and Morrissey, Computer Com?iler Organization Studies, RepGrtby Mor-rissey (John) Associates, Inc., New York, May 1966. N57-40182 AD-658196

Bayer, Rudolf, et al., The ALCOR Illinois 7090/7094 Post Mortem Dump ). In-nces Pieport No. ion Sciences Laboratory, Boeing Scientific ResearchLaboratories, August 1967.

A-6 Bell Aerosystems Company,Aero-Space Environment Simulation System (ASESS), Volume 111: Program Modification and Implementation on the Digital Computer, Report prepared for A.F.S.S., Electronic Systems Division, Buffalo, NewYork, November 1964. FORTRAN IV, snapshot, progxam checkout N66-20024 AD-610715

Best, G. C., United Kingdom Atomic Energy Authority,Hamell, England; Electronics and Applied Physics Division, AUTOTOGGLE - An Aid to PDP8 Program Debugging, Xil-y-1-9-66.. Debugging program for PDP8 computer N66-39821 Source:NASA/STAR

Bobrow, D. G., Darley, D. L., Deutsch, L. P., Murphy, D. L., and Teitelman, W., The BBN 940 LISP System Interim Scientific Report, Report by Bolt, Beranek, and Newman, Inc., Cambridge, Massachusetts, July 1967. BBN 940 LISP System, tracking, conditional breakpoints, debugging AD-656771 N67-36746

Brown, W. S., "An Operating Environment for 3ynamic-Recursivz Computer Programming Systems,"of VIII(6), June 1965, pp. 371-77.

Clark, George A,, Jr.,"Technical 3roblems of Simulation Development," Reportby Defense Supply Agency, Alexandria, Virginia, 1967. AD-813899 1

Dunn, T. M., and Morrissey, J. H., "Remote Computing - An Experimental System," ProceedingsSJCC, 1964.

Erickson, W. J., Pilot Study of Interactive Versus Non- interactive Debugging, Reportby System Development Corporation, Santa Monica, California, December 1966. Determining economics of different types of computer sys tems

Evans, Thomas G., and Darley,D., Debug, an Extension to Current On-Line Debugging Techniques, Reportby Air midge- Research Laboratories, Bedford, Massachusetts, November i964. Debug computer program, UNXVAC"460 AD-168825

Evans, Thomas G., and Darley,D. Lucille, On-Line Debugging Techniques: A Survey, Report by Air Force Research Laboratories, L. G. Hanscom Rield, Massachusetts, 1966.

Gildea, Robert A. J., Evaluation of ADAM: An Advanced Data Managenent System, Report by MitreCorporation-,"- Bedford, Massachusetts, August 1967. Debugging facilities, suggestions N68-12069 AD-661273

Grant, E. E., An Empirical Comparisoa- of On-Line and Off- Line Debugging, A Reportby System Development corporation, Santa Monica, California, May1966. On-line and off-line debugging AD-633907

A-8 Griffith, E. L., Util~ityPr.og.ram Descriptions Milestone 11 Memory Dump Routine, Reportby System Developmeni Corporation, Santa Monica, California,May 1964. Dump AD-446860

Grunby, Eugene I., An Improved Approach to Trace Routines, Report for National Aeronautics and Space Admin- istration, Goddard Space Flight Center, Greenbelt, Maryland, February 1965. Trace routines, proposes solutionsto excess of printed diagnostic material, considerably extended execution time, also provisions'for programmers to provide own coded subroutines, UNIVAC 1107 N65-29802 Source:NASA/STAR

Hisler, Abrom, Propellant Utilization Time Trace(PUTT) A Documentation Case Study, Report by Telemetry Computation Branch, Goddard Space Flight Center, Greenbelt, Maryland, September1967. Debugging techniques usedon PUTT 1-560-67-399

IBM Corporation, Computer Programming Techniques for Intelligence Analyst Application, Report No.1, Report by ThomasJ. Watson Researcn Center, Yorktown Heights,-New York for RADC Griffiss AFB, New York, ALigust 1964. Automated debugging techniques AD-605267 N64-29932

A-9 Informatics, Inc., D+splay OrientedComputer Usage System,".. Interim Technical Report October64 - AprTl-6-6, Bethesda, Maryland,June 1966. FORTRAN, on-line, DOCUS AD-487385

Jacoby, K., and Layton, H., "Automation of Program Debugging," Preprints of papers presented at the 16th National Meeting of the ACM, Los Angeles, September5-8, 1961; ACM, New York. Source: ACM Computing Review

Kramfus, I. R., and Yakushin, Debugging Program for Training Computers. N67- 27843

Lampson, Butler W., "Interactive Machine Language Programming,"

" ,Proc. AFIPS Fall Joint Computer Conference,~~ ~~~~ Parti, SDS 930, macro-assembler and debugging facility Source: ACM Computing Relriew

Magnuson, Robert A., ExtendedUse of Macro Assemblers, Report by Research Analysis Corporation,McLean, Virginia, July 1965. Debugging, techniques AD-470105

McMains, Forrest, Edit,A FORTWN Program for Renaminn>"h_ Variables in a Source -P-rog;-am, Technical hepor-c by 'Picatinny Arsenal, Dover, 'E Jersey, July 1967. Edit, FORTRAN IV AD 659-346

A-10 I ~ -

Mitre Corporation,First Congress on theInformation SystemSciences~, Se-ss-ion 12., Programming,Information ProcessingAutomata, Bedgord, Massachusetts, October 1963. Debugging AD-422475

Murphy, Harry M., TIDY, A Comput-erCode for Renumberingand Editing FORTRAN SourcePrograms, Report by AFSC, Air Force Weapons Laboratory,Kirtland Air Force Base, New Mexico,June 1966. TIDY, FORTRAN, editing,renumbering N67-20677

AD-642099

Narrow,Bernard'G., and Lee, Richard C., A Generalized Satellite Telemetry Data'SimulationProgram, Report by NASA GoddardSpace Flight Center, Greenbelt, Maryland, November 1966. Datasimulation program which generates test tapes usedfor debugging and testing

Paul,Manfred, and Wiehle, Hans Ruediger,Bayer, Rudolf, Gries,David, The"ALC0-R Illinqis 7090/94 Post Mortem Dump, Report by-Boeing Scient-i-fic- Kesea~rch Laboratories, Seattle,Washington, Post mortem dump technique

7090 Algol-60

Stoller, G. S., Masked SearchProgram, Report by Mitre Corporation,Bedrord, Massackisetts; January 1365. Masked searchprogram, static trace, debuggingor modifying 7090program N65-35592 AD-610062

A-11 Sutherland, W. R., On-Line Graphical Specification of Computer Procedures, Reportby Massachusetts

Institute of Technology," Lexington,- Massachusetts, May 1966. On-Line, Debugging AD-639734

Sweeney, M. J., 160-A Diagnostic Program (SFCHEX) Milestone 5, Report by System Development Corporation, Santa Monica, California, July 1965. CD6 160A, dump, selective dump, diagnostic program AD-469872

Thompson, J. A., DIAGNOSE, A Routine to Debug FORTRAN Programs,'keport for Oakridge National Laboratory, Tennessee, June 1965. DIAGNOSE, CDC 1604, dehugging, erroneous subscripts and DO-loop parameters, use of variables that have no values assignedto them N66- 23235 Source:NASA/STAX

Yourdon, Edward, "A Debugging Environment for Real-Time Systems," Real-Time Systems Design. Information and Systems Institute, Cambridge, Massachusetts, 1967, pp. 137-151. Dynamic Debugging,Real-Time Source ACM Computing Reviews

A-12 Articles and Periodicals

Apple, C. T., "The Program Monitor - a Device for Program Performance Measurement," Proc. ACM205h National Conference, pp. 66-75. IBM, evaluating software performance Source: ACM Computing Review

Barron, D. W., and Hartley, D. F., "Techniques for Program Error Diagnosis on EDSAC 2," Computer Journal, 6, 1 (April 1963), 44-49. Post-mortem, trace, irrevocable stopson mistake conditions Source: ACM Computing Review

Boehm, E. M., and Steel, T. B., Jr., "The SHARE 709 System: Machine Implementation of SymbolicProgramming," Journal of ACM, 6, 2 (April 1959), pp. 134-140.

Brandon. Dick H. and Kirch. Frederick "Standards for komputer Programming," Computersand Automation, May 1964, pp. 22-28, 43.

Chapin, Ned, "Logical Design to Improve Software Debugging- a Proposal," Computer Automation, 15, 2 (February 1966), pp. 22-24. Hardware- featuresto assist programmer, console trace, small memory snapshot, elaborationof run and dump Source: ACM Computing Review

Constantine, LarryL., "Design and Reductionof Bugs," C.o~ncepts in Program Design, pp.115-126. Rules of program design to help reduce bugs Source: ACM Computing Review

A-13 Evans, Thomas G., and Darley, D. Lucille, "Debug - an Extension of current on-line Debugging Techniques, Communicati~ons of ACM, 8, 5 (May 2965), pp. 321-326. Debug, checkout of assembly language programs, UNIVAC "460, RAP, TIC, STUD prelocating assembler, typewriter program for inspection of memory and control of program execution, text-editing Source: ACM Computing Review

Ferguson, H. Earl, and Berner, Elizabeth, "Debugging Systems at a Source Language Level," Communications-of ACM, 6, 8 (August 1963), pp. 430-434. FORTRAN preprocessor called BUGTRAN traces, dumps, output format which inciuaes symbolic variable names and statement numbers Source: ACM Computing Review

Greenwald, I. D., and Kane, Maureen, "The SHARE 709 System: Programming and Modification," Journal of ACM, 6, 2 (April 1959), pp. 218-133.

Halpern, Mark, "Computer Programming: the Debugging Epoch

Opens," Computer Automation,~ ~- 14, 11 (November 1565), pp. 28-31. References, debugging, arresting, identifying, correcting, examples Source: ACM Computifig Review

King, Clauae F., "Computer Progranmir&g for Control of Spzce

Vehicles," Peaceful Uses of Aueomatlon~ ~~ in Outer~ ~ ~ ~ -~S?ace, pp. 409-414. Source: ACM Computing Review

Lietzke, Majorie P., "A Method of Syntax - Checking ALGOL 60," Consunications of ACM, 7, 8, (Axgust 1964), 475, 478. SHARE ALGOL 6G TRANSLATOR, Syntax checker used as diagnostic, compiler, recursive subroutines, error recovery, error correction Source: ACM ComputiRg Review

A-14 Lunelli, M., andMacchi, V. , "Technicheetempi per la messa a puntodei programmi (techniques and times for programdebugging) ,I' Atti del convegno suilinguaggi simbolicidi programmazione, -AICA - January 1962, 90-95, (Italian) . Debugging, time requirements Source: ACM Computing Review

McCarthy, J., Boilen, S., Fredkin, E., and Lickliaer, J.C.R., "A Time-sharingDebugging System for a SmallComputer,"

~ Proc.." AFIPS 1963 Spring JointComputer Conference, D.et.r'o~i;-~-"-.~chig-an ,~ ~~ . 19 ~7

Typewriter-console command, time-shared, TX-0 computer at MIT, interruptand examine any locationin memory Source: ACM ComputingReview

Miller, Joan C, , andMaloney, Clifford J., "SystematicMistake Analysis of Digital ComputerPrograms," Communications of the ACM, 6, 2 (February1963), 58-62.

Perlis, A.J., "Construction of ProgrammingSystems Using Remote EditingFacilities," Proc.~ of IFIP Congress65, Vol. 1, 229. Description of Debugging aids,experimental programming languages Soarce: ACM CompatlngReview

Schwartz,Jules I. , Coffxan, Edward G., andWeissman, Clark, "Potentials of a Largz-ScaleTime-sharing System,"

"Proceedings~ of 2nd Congress Info. Sys. Sci., 15-32. Time-sharing,large-scale

Source: ACM ComputingReview

Senko, M.E., "A ControlSystem for LogicalBlock Diagnosis withData Loading," Communications of the ACM, 3, 4 .(1960) , 236- 240.

A-15 Instant Turnaround," Communications of ACM, 10, 8 (August 1967), 495-507). Instant turnaround, Syntax correction,-provides a more nearly correct program when logic debugging begins Source: ACM Computing Review ver Steeg, R. L., "TALK - a High-Level Source Language Debugging Technique with Real-Time DataExtraction," Communications of ACM, 7, 7 (July 1964), 418-419. Technique for extracting the values of specified data during the execution of a compiled program, extracted data is processed by a separate editing program producing an annotated listing Source: ACM Computing Review

Weinberg, G. M., "An Experiment in Automatic Verification of Programs," Communications of. ACM, 6, 10 (October 1963), 610-613. Common mistakes in writing and keypunching, FORTRAN symbolic debugging system, multiple access computer sys tern Source: ACM Computing Review

Wengert, R. E., "A Simple Automatic Derivative Evaluation Program," Communications of ACM, 7, 8 (August 1964), 463-464. Debugging tool for programs which contain derivatives Source: ACM Computing Review Related to paper by R. D. Wilkens

Wilkens, R. D., "Investigation of a New Analytical Method for Numerical Derivative Evaluation," Commmications of ACM, 7, 8 (August 1964), 465-471. Numerical derivative evaluation uses as a debugging too, detecting and pinpointing overflow Source: ACM Computing Review Related to paper by Wengert, X. E.

A-16 Wilkerson, M., "The JOVIAC Checker,an Automatic Checkout System forHigher Level Language Programs," Proc. WesternJoint ComputerConference, Los Angeles, mifornia, (May 9-11, 1961),397-404. Recording test results

Zimmerman, Luther L., "On-LineProgram Debugging - A Graphic Approach," Computersand Automation, 16, 11 (November 1967), 30-34," GBUG anon-line assembly language debugging program, graphicterminals

Source: ACM ComputingReview

Unpublished Material

C-E-I-R Inc.,Institute for AdvancedTechnology, "Computer ProgramDocumentation and Debugging," Docmentation andilebugging Seminar, Washington, 1968.

Hisler, Abrom, "SEFLO - Sequence Flow A ComputerProgram DebuggingTool," Goddard Space Flight Center, Greenbelt,Maryland, January 1968.

NASA-Langley, 1969 - 8 CR-1397 A-17