UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

The design and implementation of a run-time analysis and interactive debugging environment Johnson, Mark Scott 1978

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1978_A1 J63.pdf [ 11.44MB ]
Metadata
JSON: 831-1.0051800.json
JSON-LD: 831-1.0051800-ld.json
RDF/XML (Pretty): 831-1.0051800-rdf.xml
RDF/JSON: 831-1.0051800-rdf.json
Turtle: 831-1.0051800-turtle.txt
N-Triples: 831-1.0051800-rdf-ntriples.txt
Original Record: 831-1.0051800-source.json
Full Text
831-1.0051800-fulltext.txt
Citation
831-1.0051800.ris

Full Text

THE D E S I G N AND I M P L E M E N T A T I O N OF A R U N - T I M E A N A L Y S I S AND I N T E R A C T I V E DEBUGGING ENVIRONMENT by HARK SCOTT JOHNSON B.A., U n i v e r s i t y o f C a l i f o r n i a , S a n t a B a r b a r a , 1 9 7 3 M.S., U n i v e r s i t y o f C a l i f o r n i a , S a n t a B a r b a r a , 1 9 7 4 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T OF THE R E Q U I R E M E N T S FOR T H E DEGREE OF DOCTOR OF P H I L O S O P H Y i n THE F A C U L T Y OF GRADUATE S T U D I E S ( D e p a r t m e n t o f C o m p u t e r S c i e n c e ) H e a c c e p t t h i s t h e s i s a s c o n f o r m i n g t o t h e r e q u i r e d s t a n d a r d . ., THE U N I V E R S I T Y OF B R I T I S H C OLOMBIA A u g u s t , 1 9 7 8 (c) M a r k S c o t t J o h n s o n , 1 9 7 8 In p r e s e n t i n g t h i s t h e s i s in p a r t i a l f u l f i l m e n t o f t h e r e q u i r e m e n t s f o i an advanced degree at the U n i v e r s i t y o f B r i t i s h C o l u m b i a , I a g r e e t h a t the L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r r e f e r e n c e and s t u d y . I f u r t h e r agree t h a t p e r m i s s i o n f o r e x t e n s i v e c o p y i n g o f t h i s t h e s i s f o r s c h o l a r l y purposes may be g r a n t e d by the Head o f my D e p a r t m e n t o r by h i s r e p r e s e n t a t i v e s . It i s u n d e r s t o o d that c o p y i n g o r p u b l i c a t i o n o f t h i s t h e s i s f o r f i n a n c i a l g a i n s h a l l not be a l l o w e d w i thout my w r i t t e n p e r m i s s i o n . M a r k S c o t t J o h n s o n r, . , . , . „ ,„„* „ r C o m p u t e r S c i e n c e Department o r r The U n i v e r s i t y o f B r i t i s h Co lumbia 2 0 7 5 W e s b r o o k P l a c e V a n c o u v e r , C a n a d a V 6 T 1W5 Date 1 9 7 8 A u g u s t 14 i i A b s t r a c t The design and implementation of a language-independent, i n t e r a c t i v e system t o f a c i l i t a t e the a n a l y s i s and symbolic debugging of computer programs w r i t t e n i n h i g h - l e v e l languages i s presented. The p r i n c i p a l f e a t u r e s of the system, c a l l e d RAIDE, are: (1) Host source language independence i s supported by the a b s t r a c t i o n of language e n t i t i e s and c o n s t r u c t s (for example, v a r i a b l e s , c o n s t a n t s , procedures, statements, and events) with a language i n t e r f a c e r p r o v i d i n g language-dependent d e t a i l s ; (2) T r a n s l a t o r s can cooperate with RAIDE at v a r y i n g l e v e l s of d e t a i l ; (3) The user i n t e r a c t s with RAIDE and an executing o b j e c t program using an extendable debugging language, c a l l e d D i s p e l ; (1) P r i m i t i v e debugging a c t i o n s are kept t o a minimum and n o n p r i m i t i v e a c t i o n s ( f o r example, t r a c i n g , snapshots, and postmortem dumping) are provided by u s e r - s u p p l i e d and l i b r a r y " procedures w r i t t e n i n D i s p e l ; and (5) The implementation i s aided by s i m u l a t i o n of a v i r t u a l debugging machine, c a l l e d SPAM. To demonstrate RAIDE's f e a s i b i l i t y , a prototype implementa-t i o n was undertaken, i n c l u d i n g a SPAM s i m u l a t o r and the m o d i f i -c a t i o n of two language t r a n s l a t o r s (namely, Asple and BCPL) to i n t e r f a c e with RAIDE. Besides d e s c r i b i n g the e x t e r n a l and i n t e r n a l designs of the debugging system, the a b s t r a c t machine. i i i and the debugging language, the t h e s i s a l s o d i s c u s s e s the advantages and shortcomings of each of these components. Numerous examples of debugging commands w r i t t e n i n D i s p e l are g i v e n . Two s i g n i f i c a n t s i d e - e f f e c t s of the resea r c h are rep o r t e d ; r e f l e c t i o n s on the software t o o l s s u p p o r t i n g the implementation, and sug g e s t i o n s f o r t r a n s l a t o r d e sign t o f a c i l i t a t e run-time debugging. The t h e s i s c o n t a i n s a s u b s t a n t i a l annotated b i b l i o g r a p h y and an e x t e n s i v e index. Key Words and Phrases Primary terms: debuggers, debugging, debugging languages, debugging systems, D i s p e l , e r r o r d e t e c t i o n , i n t e r p r e t e r s , program t e s t i n g , RAIDE, SPAM, v i r t u a l machines A d d i t i o n a l terms; a b s t r a c t machines, automated programming a i d s , command languages, debugging-oriented machines, d i a g n o s t i c systems, dynamic debugging, e r r o r a n a l y s i s , e r r o r checking, e x e c u t i o n p r o f i l e s , i n t e r a c t i v e debugging, i n t e r a c t i v e systems, program a n a l y s i s , programming systems, programming t o o l s , pseudo-machines, s i m u l a t o r s , software debugging, software t o o l s , s p e c i a l - p u r p o s e languages, symbolic debugging, t r a c i n g Commuting, S§2i§2.s c a t e g o r i e s : 4. 13, 4.29, 4.42, 4.6 i v Table of Contents Chapter I. I n t r o d u c t i o n 1 A. The Problem 1 fi. Previous Work 3 C. Concurrent Work .................. .................. .7 Chapter I I . The Debugging System 9 A. Design C r i t e r i a .....9 B. B a s i c RAIDE Concepts .............................. 12 C. Overview of the Implementation 19 Chapter I I I . The Debugging System Language ...., 27 A. Design C r i t e r i a ......................,............ 27 B. Syntax and Semantics .............................. 30 C. Examples 42 D. D i s c u s s i o n ............ ............................ 52 Chapter IV. The V i r t u a l Debugging Machine ....59 A. Design C r i t e r i a ............ ,...................... 59 B. Machine A r c h i t e c t u r e .............................. 61 C. D i s c u s s i o n ........................................ 68 Chapter V. The Implementation 73 A. Scope of the Implementation ....................... 73 B. I n t e r n a l Design of RAIDE ......... ,..,,............ 76 C. I n t e r f a c i n g a Language ........... ................. 80 D. I n t e r f a c i n g a T r a n s l a t o r .......................... 82 E. R e f l e c t i o n s on the Implementation T o o l s ........... 84 Chapter VI. Summary and C o n c l u s i o n s ....................... 94 A. Importance ....... ................................. 95 B. Shortcomings ......... .......... ................... 97 C. Future D i r e c t i o n s ................................ 100 D. Suggestions f o r T r a n s l a t o r Design ................ 103 Gl o s s a r y 112 References and Annotated B i b l i o g r a p h y ......................114 Appendix A. RAIDE System Functions ........................137 1. Status Functions ..................... ....... ..... 137 2. D i s p l a y Format F u n c t i o n s 138 3. A n a l y s i s Functions ...............................138 4. Language-Dependent System Functions ..............139 Appendix B. D i s p e l Syntax Chart ........................... ,140 Appendix C. SPAM D e s c r i p t o r Formats .......................144 Appendix D. SPAM Table Entry Formats ......................149 V Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e ...................152 1. Segment C o n t r o l I n s t r u c t i o n s ..................... 152 2. Data Access I n s t r u c t i o n s ......................... 154 3. A r i t h m e t i c and S t r i n g I n s t r u c t i o n s .,..,..,,....,.156 4. Transput I n s t r u c t i o n s ............................ 156 5. Storage Management I n s t r u c t i o n s 157 6. S t a t u s I n s t r u c t i o n s 157 7. M i s c e l l a n e o u s I n s t r u c t i o n s ....................... 158 Appendix F. An Example SPAM Object Program 159 Appendix G. RAIDE Symbol Table Entry Formats 164 Appendix H. Example RAIDE Symbol T a b l e E n t r i e s .,,...,.,,,,170 Appendix I.. An Example RAIDE Program S p e c i f i c a t i o n ........ 177 B i b l i o g r a p h i c Reference Index 179 General Index ........................ ....................,, 181 v i L i s t o f Tables I. Debugging System Design C r i t e r i a 13 I I . Examples of P o s s i b l e Generics f o r Various Languages .............,...... ...... ..... *....... •... 15 I I I . Information Supplied t o EAIDE by the Language I n t e r f a c e r s ...,.................... 21 IV, Information Supplied t o SPAM by the T r a n s l a t o r s ..... 22 V. Information S u p p l i e d t o RAIDE by the T r a n s l a t o r s .,..,23 VI. L e v e l s of Debugging Support ......................... 25 VII. Debugging Language Design C r i t e r i a 29 v i i L i s t o f F i g u r e s I I - 1 . , Overview of the Implementation ...................... 20 IV-1. B a s i c A r c h i t e c t u r e of SPAM .......................... 62 V-1. B a s i c Information S t r u c t u r e of HAIDE 77 C-1. Segment D e s c r i p t o r Format .......................... 144 C-2. Data D e s c r i p t o r Format 145 C-3. Array D e s c r i p t o r Format 147 C-4. Segment C o n t r o l Stack Entry D e s c r i p t o r Format ...... 148 C-5. Scope Stack Entry D e s c r i p t o r Format .........,...... 148 D-1. Bounds Table Entry Format .. 149 D-2. Type Table E n t r y Format 150 F-1. Towers of Hanoi Source Program 160 F-2. Towers of Hanoi SPAM Code 161 F-3. Towers of Hanoi I n i t i a l SPAM Machine S t a t e 163 G-1. D a t a - S p e c i f i c Symbol T a b l e Entry Format ............ 164 G-2. Segment-Specific Symbol Table Entry Format ......... 165 G-3. Generic Symbol Table E n t r y Format .................. 166 G-4. Event Symbol Ta b l e Entry Format 167 G-5. System Function Symbol Table E n t r y Format 168 G-6. Debugging D a t a - S p e c i f i c Symbol Table Entry Format ., 168 G-7. Debugging Segment-Specific Symbol Table Entry Format . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . ,169 H-1. Program f o r Demonstrating the RAIDE Symbol Table ... 172 H-2. Acce s s i n g a Symbol Table Entry by I d e n t i f i e r 173 H-3. Accessing a Symbol Table Entry by ( l e v e l , o r d e r ) .... 174 H-4. Example Segment-Specific Symbol T a b l e E n t r i e s 176 1-1. Towers of Hanoi Data S p e c i f i c a t i o n s 177 I-2. Towers of Hanoi Segment S p e c i f i c a t i o n s .. 178 v i i i P r e f ace /* The language i s p e r p e t u a l l y i n f l u x : i t i s a l i v i n g stream, s h i f t i n g , changing, r e c e i v i n g new s t r e n g t h from a thousand t r i b u t a r i e s , l o s i n g o l d forms i n the backwaters of time. To suggest t h a t a young w r i t e r not swim i n the main stream o f t h i s t u r b u l e n c e would be f o o l i s h indeed. — W i l l i a m Strunk, J r . , [ S t r u 59:69] */ Altho readers o f t h i s t h e s i s may at f i r s t be s u r p r i s e d to encounter c e r t a i n unusual s p e l l i n g s , they should f i n d a f t e r r e a d i n g t h r u i t that any i n i t i a l d i f f i c u l t i e s w i l l disappear even tho t h e i r academic t r a i n i n g may s t i l l i n h i b i t t h e i r acceptance of such usage. i x Acknowledgements /* A l i g u i d per Omnes. — motto of C a l i s t r a l i a */ Work on t h i s t h e s i s was made p o s s i b l e t h r u the f i n a n c i a l support of the Department o f Computer Science and the Computing Centre of the u n i v e r s i t y of B r i t i s h Columbia., The f i n a l year was supplemented by a UBC Graduate F e l l o w s h i p . T h i s d i s s e r t a t i o n was prepared using the Texture document processor [Text 78], which i s based on the work of Peter van den Bosch [Vand 74]. Members of the Texture Support Group, p a r t i c u -l a r l y Tom Bushworth and Ted Venema, generously gave t h e i r time to a s s i s t me i n understanding the o c c a s i o n a l l y gordian workings of Texture. For t h e i r help i n the fo r m a t i v e years of my computer s c i e n c e t r a i n i n g at the U n i v e r s i t y of C a l i f o r n i a , Santa Barbara, I am t h a n k f u l t o Chuck Dana, Leon P r e s s e r , and John S. Bhite. T h e i r encouragement s i g n i f i c a n t l y a f f e c t e d the course of my academic p e r e g r i n a t i o n . S e v e r a l f e l l o w graduate students made s p e c i a l c o n t r i b u t i o n s t o my work: Greg Wilbur was one of my e a r l i e s t and most ardent rock throwers. Not o n l y d i d he po i n t out shortcomings i n the e a r l y p r o p o s a l s , but he a l s o suggested many a d d i t i o n s and changes. Ted Venema was l i k e w i s e l a v i s h with h i s c o n s t r u c t i v e c r i t i c i s m s , p a r t i c u l a r l y of the a b s t r a c t machine, SPAM. B i l l Appelbe was i n s t r u m e n t a l i n shaping the d i r e c t i o n of the e a r l y X d r a f t s of t h i s t h e s i s . I t s e t h e r e a l w i t t i c i s m s and u b i q u i t o u s acronyms are l a r g e l y c r e d i t e d to (blamed on?) him. , Graeme H i r s t g r a c i o u s l y accepted the onerous task of e d i t i n g and p r o o f r e a d -i n g . A l t ho I was at f i r s t overpowered by the magnitude o f h i s sugg e s t i o n s ("enraged a t h i s v i c i o u s a t t a c k s " more a c c u r a t e l y d e s c r i b e s my i n i t i a l r e a c t i o n ) , I am n e v e r t h e l e s s c o n f i d e n t t h a t h i s e d i t i n g has s i g n i f i c a n t l y improved the g u a l i t y o f t h i s d i s s e r t a t i o n . The extradepartmental members of my examining committee deserve commendation f o r t h e i r perserverance i n s t u d y i n g what must have been to them a somewhat t r a n s l u c e n t document: J . J . F . F o u r n i e r , the c h a i r p e r s o n o f the examining committee; Helene E. Kulsrud, the e x t e r n a l examiner; and Peter Lawrence, the p u b l i c examiner. The members of my guidance committee a l s o deserve s p e c i a l mention f o r t h e i r s u p e r v i s i o n : Alan B a l l a r d , Sam Chanson, Hugh Dempster, Bob F r a l e y , Mabo I t o , and John Peck. I e s p e c i a l l y acknowledge the c o u n s e l of my f a c u l t y a d v i s o r , Harvey Abramson. F i n a l l y , t h i s t h e s i s would not have been completed without the constant encouragement and moral support o f B i l l Appelbe, f e l l o w C a l i s t r a l i a n . When I reached the depths of the academic p i t , h i s o b s t i n a t e c o n s o l a t i o n gave me the s t i m u l u s t o c l i m b out and continue on. B i l l , together with a host of f r i e n d s too numerous to name, have made my sojourn i n Canada a most memorable and b l e s s e d event. 1 Chapter I. I n t r o d u c t i o n /* The best may s l i p , and the most c a u t i o u s f a l l ; He's more than mortal t h a t ne»er e r r e d at a l l . — Rev. John Pomfret, Love Triumphant^ gv§r Reason */ A. The Problem The computer program development c y c l e c o n s i s t s b a s i c a l l y of s i x phases: s p e c i f i c a t i o n , f u n c t i o n a l decomposition, coding, t e s t i n g , debugging, and e v a l u a t i o n . I n recent years software engineers have concentrated on the second and t h i r d of these phases. T h i s i s e x e m p l i f i e d by the a t t e n t i o n p a i d t o language design and the advocacy of s t r u c t u r e d programming., Altho these two p o i n t s are c e r t a i n l y important i n the production of q u a l i t y software, t h e i r emphasis has d e t r a c t e d from progress i n the other phases. I t i s c l e a r t h a t the best manner of d e a l i n g with a programming bug i s to prevent i t s presence i n the f i r s t p lace. Emphasizing the design o f languages which make the i n c l u s i o n of l o g i c e r r o r s d i f f i c u l t and programming methodologies which encourage e r r o r - f r e e programming i s important. N e v e r t h e l e s s , i t i s s t i l l necessary f o r a l l production programs t o e n t e r the t e s t i n g and debugging phases [ Halp 65]. /* Debugging poorly designed and coded software systems i s v e t e r i n a r y medicine f o r d i n o s a u r s . — Harlan D. M i l l s , [ M i l l 76b:271 ] */ T h i s t h e s i s presents the design and implementation of a language-independent, i n t e r a c t i v e system to f a c i l i t a t e the a n a l y s i s and symbolic debugging of computer programs w r i t t e n i n Chapter I. I n t r o d u c t i o n 2 h i g h - l e v e l languages. The primary purpose of the debugging system i s to provide an environment i n which the computer programmer can d e t e c t the presence of e r r o r s and t r a c e t h e i r cause and, thereby, reduce the t o t a l time spent on the debugging phase of the program development c y c l e . The concern o f t h i s t h e s i s i s the i s o l a t i o n and c o r r e c t i o n of e r r o r s d u r i n g program execution. D e t e c t i n g s y n t a c t i c e r r o r s i s not of i n t e r e s t here. The debugging process c o n t a i n s three major components: r e c o g n i t i o n , d i a g n o s i s , and c o r r e c t i o n . S§eo.gnition of a program e r r o r r e q u i r e s knowledge of the a n t i c i p a t e d r e s u l t s and program behavior, and r e a l i z a t i o n of when these e x p e c t a t i o n s are not met. Diagnosis i n v o l v e s the i d e n t i f i c a t i o n o f the cause of an e r r o r , based on i t s symptoms. A l t h o the d i a g n o s t i c process i s l a r g e l y i n t u i t i v e , i t i s d i r e c t e d by answering such questions as "What p r e c i s e l y i s wrong with the program?", "Where was the e r r o r d e t e c t e d ? " , "Under what c o n d i t i o n s does the e r r o r manifest i t s e l f ? " , and "How e x t e n s i v e i s the e r r o r ? " [Brow 73:ch. 9 ] . To be u s e f u l , a debugging system must h e l p t o answer these g u e s t i o n s . Debugging i s a k i n to d e t e c t i v e r y ; a debugging system i s a k i n t o a magnifying g l a s s . , A debugging system should be j u s t one component of a c o l l e c t i o n o f software a i d s a v a i l a b l e to programmers to improve the q u a l i t y and q u a n t i t y of t h e i r software [ B a l z 74, Chea 72, Clap 74, Davi 75, Ledg 76, Stoc 67, T e i t 69, Wile 76, Wino 75]. A debugging system must maximize the amount of usable i n f o r m a t i o n a v a i l a b l e t o the programmer.The need f o r such a Chapter I. I n t r o d u c t i o n 3 system i s apparent from the p r o l i f e r a t i o n of language processing systems which provide inadeguate run-time debugging a i d s . The user of such language p r o c e s s o r s must o f t e n r e s o r t to machine-language dumps or e x t e n s i v e u s e r - s u p p l i e d source language debugging and monitoring r o u t i n e s . , B. Previous Hork /* No vehement e r r o r can e x i s t i n t h i s world with impunity. — James Anthony Froude, Spinoza •/ T h i s s e c t i o n d e s c r i b e s b r i e f l y previous work i n the area of debugging systems. The reader who i s i n t e r e s t e d i n a survey of debugging technigues and concepts should c o n s u l t v a r i o u s of the f o l l o w i n g g e n e r a l r e f e r e n c e s : [Brow 73, Evan 66, Fong 73b, Gain 69, G e l l 75, Koch 69, Ledg 75, Hann 73, Pool 73, Bain 73, S a t t 75, Schw 71, Scow 72, S e i d 68, VanT 74]. The concept of an i n t e r a c t i v e , run-time debugging system i s not new. Before the i n v e n t i o n of batch p r o c e s s i n g , debugging was c a r r i e d out d i r e c t l y a t the o p e r a t o r ' s console using the c o n s o l e switches and l i g h t s to provide c l u e s as to why a program behaved i n c o r r e c t l y . A f t e r the development of batch p r o c e s s i n g , t h i s a c t i v i t y was automated to produce memory and r e g i s t e r dumps [ K i r s 74] and program t r a c e s . In the e a r l y days of i n t e r a c t i v e computing, the v a l u e of i n t e r a c t i v e debugging systems, which were f i r s t a p p l i e d to the d e t e c t i o n of e r r o r s i n machine-language programs, became apparent. V i r t u a l l y every i n t e r a c t i v e computing environment pro v i d e s some such a i d [ B a l l 77, Bern 68, B l a i 71, C r i s 65, Evan 65, Evan 66, Gain 69, G a l l 74, Jdns 68, Chapter I. I n t r o d u c t i o n 4 Jose 69, Kuls 69, Stoc 65, UWM 73, Zimm 67]. The b a s i c f a c i l i t i e s p rovided by such systems i n c l u d e the a b i l i t y to i n s p e c t the s t a t e of the run-time environment at p a r t i c u l a r p o i n t s , to s e t breakp o i n t s i n the program, and to t r a c e the ex e c u t i o n of procedures and the values of v a r i a b l e s . , These systems o f t e n allow one t o patch o b j e c t programs during e x e c u t i o n and t o change the values of v a r i a b l e s . Machine-language debugging systems are of l i m i t e d use to the person who programs i n a h i g h - l e v e l language. The trend away from machine-language programming has emphasized the need to develop debugging t o o l s which provide the user with the a b i l i t y to monitor the exe c u t i o n of a program w i t h i n the terms of some h i g h - l e v e l source language. The user wants to r e f e r a t run-time t o the program using s o u r c e - l e v e l names and n o t a t i o n s without regard t o the r e s u l t s of the t r a n s l a t i o n process. /*• How t r u l y sad i t i s that j u s t a t the very moment when the computer has something important to t e l l us, i t s t a r t s speaking g i b b e r i s h . — Gerald M. Weinberg, [Wein 71:208] */ One common way i n which some run-time debugging a i d f o r h i g h - l e v e l languages has been provided i s t h r u language-p r o c e s s o r - s u p p l i e d symbolic postmortem dumps (e.g., ALCOR A l g c l 60 [Baye 67, F e r l 71], PL/C (Conw 73, Morg 71], Snobol4 f G r i s 71b], Algol-W [ S a t t 72, S i t e 71], and IMP [Step 7 4 ] ) . A symbolic postmortem dump give s the user a p i c t u r e of the s t a t e of the e x e c u t i o n of a program a t the point of abnormal t e r m i n a t i o n by p r i n t i n g the s o u r c e - l e v e l names of v a r i a b l e s and Chapter I. I n t r o d u c t i o n 5 t h e i r values i n a form resembling the terminology of the source language. A symbolic traceback o f the dynamic procedure i n v o c a t i o n h i s t o r y i s u s u a l l y s u p p l i e d as w e l l . Using t h i s i n f o r m a t i o n , i t should be p o s s i b l e f o r the programmer to d i s c e r n the cause of abnormal t e r m i n a t i o n a f t e r the f a c t . A s i g n i f i c a n t advance i n h i g h - l e v e l language debugging has been a f f o r d e d by the implementation of s p e c i a l d i a g n o s t i c t r a n s -l a t o r s . These t r a n s l a t o r s , o f t e n c a l l e d student compilers because of t h e i r o r i e n t a t i o n toward novice programmers, s a c r i -f i c e e f f i c i e n c y t o provide e x t e n s i v e run-time checks t o a i d i n the d e t e c t i o n of program l o g i c e r r o r s . Such e r r o r s i n c l u d e out of range s u b s c r i p t s , mismatched formal and a c t u a l parameters, and a c c e s s i n g u n i n i t i a l i z e d v a r i a b l e s . Examples of t r a n s l a t o r s o r i e n t e d toward students i n c l u d e PLUTO [Boul 72], PL/C fConw 73, Morg 71], and SPLINTER [ Glas 68] f o r PL/I programs; DITRAN [ Moul 67] and B a t f i v [ C r e s 70] f o r F o r t r a n programs; Hatbol f o r Cobol programs; Algol-W [ S a t t 72, S i t e 71]; and FLASC [Thorn 76] f o r A l g o l 68 programs. Another common way i n which the h i g h - l e v e l language user has been given access to debugging t o o l s i s t h r u e x t e n s i o n s t o the host source language i t s e l f [ B a i r 75, B u l l 72, Conw 73, Glas 68, G r i s 71b, G r i s 75, Hans 75, IBM 72, Kemm 76, Leed 66, P u l l 69, Holm 72], These e x t e n s i o n s have taken the form of debugging subrou t i n e s which the user can i n c o r p o r a t e i n t o a source language program, and s y n t a c t i c e x t e n s i o n s of the language which provide e x p l i c i t debugging f a c i l i t i e s . In e i t h e r Chapter I., I n t r o d u c t i o n 6 case, i t i s the use r ' s r e s p o n s i b i l i t y to code i n t o the program i n f o r m a t i o n to f a c i l i t a t e i t s debugging. T h i s approach s u f f e r s from the need t o c a r e f u l l y p r e p l a n the debugging phase of the program development c y c l e . When the programmer d i s c o v e r s some abnormality i n the program, i t o f t e n becomes necessary to modify, r e t r a n s l a t e , and reexecute the program to o b t a i n the d e s i r e d debugging i n f o r m a t i o n . To overcome the disadvantages of user-programmed debugging a i d s , systems have been developed t o provide h i g h - l e v e l language users with e s s e n t i a l l y the same f a c i l i t i e s a v a i l a b l e t o the machine-language user i n l o w - l e v e l debugging systems., High-l e v e l , i n t e r a c t i v e debugging systems have almost i n v a r i a b l y been developed around one p a r t i c u l a r source language (e.g., MANTIS and F o r t r a n [Ash b 73], EX DAMS and PL/I [ B a l z 69], the INTEELISP system [Bobr 72], PL/CT and PL/I [ Con w 77, Moor 75], IBM * s PL/I Checkout Compiler [ C u f f 72], BUGTRAN and F o r t r a n [ F e r g 63], AIDS and F o r t r a n [ G r i s 70], the LISP/MTS system [ H a l l 75, Wile 74], HELPER and F o r t r a n [ Kuls 71], IF and F o r t r a n [Ofiei 76], SIMDDT and Simula [Palm 77], DDS and C o r a l 66 [ P i e r 74], BAIL and S a i l [ R e i s 75], TALK and CS-1 [V e r s 64], and PL/I under M u l t i c s [Wolm 72]). A l t h o some of these systems have i n v o l v e d i n t e g r a t i n g debugging c a p a b i l i t i e s d i r e c t l y i n t o an i n t e r p r e t i v e environment (e.g., INTEELISP, the PL/I Checkout Compiler, and I F ) , o t hers have been designed e x p l i c i t l y as run-time systems manipulating t r a n s l a t e d code (e.g., EXDAMS, AIDS, HELPER, and DDS). Ne v e r t h e l e s s , i n a l l cases a debugging environment has Chapter I. I n t r o d u c t i o n 7 been e s t a b l i s h e d which i s a p p l i c a b l e t o a s i n g l e h i g h - l e v e l language. In view of the c u r r e n t s t a t e of i n t e r a c t i v e debugging, the advantages of a s i n g l e system which i s capable of d e a l i n g with programs w r i t t e n i n v a r i o u s source languages should be obvious. A language-independent debugging system minimizes the d u p l i c a -t i o n of e f f o r t needed i n p r o v i d i n g a debugging environment with the i n t r o d u c t i o n of new programming languages. Such a system a l s o minimizes the u s e r ' s overhead i n l e a r n i n g a new debugging system f o r each new language. A language-independent e n v i r o n -ment allows c o l l e c t i o n s of programs w r i t t e n i n more than one source language t o be debugged i n a uniform manner. M u l t i l i n -g u a l systems are not c u r r e n t l y common, due i n p a r t to the language i n t e r f a c e and debugging problems i n v o l v e d . The c r e a t i o n of a language-independent programming environment should r e s u l t i n software being w r i t t e n i n the best a v a i l a b l e language f o r each subtask, r a t h e r than i n the s i n g l e language deemed most g e n e r a l l y s u i t a b l e t o the e n t i r e p r o j e c t . F i n a l l y , such a debugging system serves as another o f f - t h e - s h e l f t r a n s l a t o r w r i t i n g system resource a v a i l a b l e t o language imple-mentors i n much the same way general-purpose l e x i c a n a l y z e r s and parser g e n e r a t i o n systems are c u r r e n t l y a v a i l a b l e . C Concurrent Work Concurrent with the r e s e a r c h r e p o r t e d i n t h i s t h e s i s has been the design and development of the DAD (Do-All Debugger) Chapter I. I n t r o d u c t i o n 8 debugging system [ V i c t 76a, V i c t 76b, V i c t 77]. I t i s designed f o r use i n a multiprogramming, m u l t i p r o c e s s i n g network environment, i n which components of the system being debugged may be w r i t t e n i n d i f f e r e n t source languages and may be e x e c u t i n g on d i f f e r e n t machines.. T h i s i s accomplished p r i m a r i l y t h r u a r i g i d p r o t o c o l which must be adhered to by a l l o p e r a t i n q systems and language t r a n s l a t o r s i n v o l v e d i n the debugging process. 9 Chapter I I . The Debugging System /* As a famous p h i l o s o p h e r once almost s a i d , "Give ae a s u i t a b l e debugging environment and a t o o l - b u i l d i n g f a c i l i t y powerful (and simple) enough, and I w i l l debug the world." — Robert M. B a l z e r , [ Balz 69:567] */ The debugging system d e s c r i b e d i n t h i s t h e s i s i s c a l l e d RAIDE (Run-time A n a l y s i s and I n t e r a c t i v e Debugging Environment) , named a f t e r another product s u c c e s s f u l l y employed t o e l i m i n a t e bugs from the user's environment. A. Design C r i t e r i a /* A good i n t e r a c t i v e ^ debugging system must be d i f f i c u l t f o r the beginner to master f s i c ]. I t s emphasis must be on completeness, convenience and c o n c i s e n e s s , not on s i m p l i c i t y . B u t l e r H. Lampson, [Lamp 65:478] */ Many c r i t e r i a have been taken i n t o account i n the design o f RAIDE [Conw 73, Gain 69, G r i s 71a, Mann 73, P o o l 73]. The most important of these i s t h a t the system should be language-independent over a l a r g e c l a s s of user source languages. s T h i s c r i t e r i o n v i r t u a l l y d i c t a t e s t hat the system run using t r a n s l a t e d code s i n c e to provide a system which can i n t e r p r e t a broad c l a s s of source languages i s c u r r e n t l y i n f e a s i b l e . A l t h o the debugging system should be language-independent, i t should appear language-dependent from the u s e r ' s p o i n t of view, that i s , the terminology should be t h a t of the source language as much as p o s s i b l e . For example, i f an a r r a y bound i s exceeded during program execution, RAIDE should respond with a Chapter I I . The Debugging System 1 0 message couched i n the terminology of the source language., Thus, f o r A l g o l 68 the message "INDEX EXCEEDS THE BOONDS SPECIFIED IN THE DEFINING OCCURRENCE OF THE HULTIPLE VALUE" might be produced. Another g o a l i s t h a t RAIDE should be usable on m u l t i l i n g u a l c o l l e c t i o n s of programs., Thus, the user can debug a set of programs w r i t t e n i n more than one source language. Another major design c r i t e r i o n i s t h a t the system should be o r i e n t e d toward i n t e r a c t i v e p r o c e s s i n g , but i t ought a l s o to be usable i n a batch p r o c e s s i n g environment without s u b s t a n t i a l d i f f e r e n c e from the user's viewpoint [Goul 75, Gran 66, Sack 68], O b v i o u s l y , many of the i n t e r a c t i v e f e a t u r e s w i l l be of marginal value from the batch stream., N e v e r t h e l e s s , there s t i l l e x i s t s a k e r n e l o f debugging f a c i l i t i e s which are a p p l i c a b l e to both environments., Another major reguirement i s that a l l debugging should be done w i t h i n terms of the source language(s). Knowledge o f the u n d e r l y i n g machine environment should not be necessary. Since the system w i l l always respond to i n q u i r i e s i n symbolic terms, there i s no need to provide core dumps, r e g i s t e r dumps, and other s i m i l a r machine-language debugging f a c i l i t i e s . One consequence of the preceding c r i t e r i o n i s t h a t language t r a n s l a t o r s w i l l need t o supply the debugging system with a s u b s t a n t i a l amount of i n f o r m a t i o n concerning the source program. Data such as the i d e n t i f i e r t a b l e , the type t a b l e , and even the Chapter I I . The Debugging System 11 source code i t s e l f w i l l need to be provided. N e v e r t h e l e s s , i t should be p o s s i b l e f o r t r a n s l a t o r s to provide i n f o r m a t i o n i n i n c r e a s i n g l a y e r s of completeness. T h i s w i l l enable RAIDE to be used even when the t r a n s l a t o r s are not completely c o o p e r a t i n g . I f the user makes a request to which the system i s unable to respond because of l a c k of t r a n s l a t o r - s u p p l i e d i n f o r m a t i o n , RAIDE should r e t u r n a message to t h a t e f f e c t and a l l o w the user to continue with other r e q u e s t s . Another design c r i t e r i o n i s t h a t the system should be capable of s u p p l y i n g e x t e n s i v e i n f o r m a t i o n concerning the s t a t e of program execution. Such c a p a b i l i t i e s w i l l exceed those of any preceding debugging system. I t i s f o r t h i s reason that RAIDE i s a run-time a n a l y s i s and debugging environment, as opposed t o simply a debugging system. A l t h o some a n a l y s i s f e a t u r e s (e.g., e x e c u t i o n p r o f i l e s [Conr 70, Inga 72, Knut 71]) border on the domain of program t e s t i n g , as opposed t o program debugging, such f a c i l i t i e s are needed i n a powerful program debugging environment; indeed, the d i v i d i n g l i n e between program t e s t i n g and debugging i s u n c l e a r . N e v e r t h e l e s s , the debugging i n f o r m a t i o n s u p p l i e d s h o u l d never be overwhelming., That i s , the user should see only what i s r e l e v a n t with d e t a i l e d i n f o r m a t i o n being provided upon a more e x p l i c i t request. The k e r n e l of the system should be minimal, y e t s u f f i c i e n t . That i s , the system must i n c l u d e a s e t of p r i m i t i v e s s u f f i c i e n t to c a r r y out a l l of the d e s i r e d debugging a c t i o n s ; but t h i s s e t should not c o n t a i n p r i m i t i v e s which can e a s i l y be simulated Chapter I I . The Debugging System 12 u s i n g a combination o f the others. Some o v e r l a p may be necessary, however, to produce a set of p r i m i t i v e s e a s i l y usable by the programmer. T h i s design c r i t e r i o n should minimize the e f f o r t r e q u i r e d to implement and t r a n s p o r t the system. To f u r t h e r minimize the implementation e f f o r t , the system must avoid d u p l i c a t i n q r e s o u r c e s provided by the host o p e r a t i n g system. I t i s assumed the user w i l l be f a m i l i a r with the o p e r a t i n g system so that a l t e r n a t i v e f a c i l i t i e s b u i l t i n t o the debugging system w i l l merely be a source of c o n f u s i o n . . One f i n a l design c r i t e r i o n i s t h a t the user should not be r e g u i r e d to make m o d i f i c a t i o n s to the source program t o c a r r y out debugging using RAIDE. I t should be p o s s i b l e t o s p e c i f y at run-time e v e r y t h i n g the user may need to f a c i l i t a t e the debugging and t e s t i n g of a program., T h i s should not, however, pre c l u d e the programmer from d e s i g n i n g some debugging a i d s i n t o the program s i n c e doing so i s a d e s i r a b l e implementation s t r a t e g y [Ledg 75]. In summary, and f o r ease of f u t u r e r e f e r e n c e , the design c r i t e r i a d i s c u s s e d above are l i s t e d i n Table I. B. B a s i c BAIDE Concepts /* Programmers are h a b i t u a t e d to s e s q u i p e d a l i a n u t t e r a n c e s . — R i c h a r d L. Wexelclat, [Sexe 76:333] */ The user i n t e r f a c e s with RAIDE s o l e l y t h r u the dabugqinq system language. Before i t i s p o s s i b l e to d e s c r i b e t h i s l a n -guage, however, i t i s necessary t o d e f i n e some terms and to Chapter I I . The Debugging System 13 1. The system should be source language independent. 2. The user i n t e r f a c e should be language-dependent, 3. ; The system should be usable on m u l t i l i n g u a l c o l l e c t i o n s of programs. 4. The system should be i n t e r a c t i v e - o r i e n t e d , but usable i n batch. 5. Debugging should be done s y m b o l i c a l l y i n source language terms. 6 . T r a n s l a t o r s should be allowed to supply i n f o r m a t i o n i n s u c c e s s i v e l a y e r s of completeness. 7. The system should provide e x t e n s i v e a n a l y t i c i n f o r m a t i o n at run-time. 8 . Information s u p p l i e d by the system should be c o n c i s e and p e r t i n e n t t o the user's request. 9 . A s m a l l , u s a b l e , and s u f f i c i e n t s e t of p r i m i t i v e a c t i o n s should be s u p p l i e d . 10. Operating system r e s o u r c e s should not be d u p l i c a t e d . 1 1 . No t r a n s l a t i o n - t i m e m o d i f i c a t i o n s to the source program should be necessary t o c a r r y out debugging. Table I . Debugging System Design C r i t e r i a e x p l a i n some b a s i c RAIDE concepts which are r e f l e c t e d i n the debugging system language i t s e l f . A program i s a c o l l e c t i o n of procedures which i n t e r a c t to perform one primary task. Thus, the term as a p p l i e d here i s e g u i v a l e n t to sy_stem of p.rojgrams used by many people. In other words, RAIDE i s designed to debug a s i n g l e program d u r i n g one i n t e r a c t i v e s e s s i o n . T h i s program may, however, c o n s i s t of a Chapter I I . , The Debugging System 14 main procedure and any number of subprocedures. I t should be remembered t h a t , from RAIDE*s viewpoint, i t i s not necessary f o r these subprocedures t o have a l l been w r i t t e n i n the same high-l e v e l language. One concept which i s b a s i c to a proper understanding of RAIDE i s the d i s t i n c t i o n between a s p e c i f i c and a g e n e r i c . A s p e c i f i c i s a r e f e r e n c e to a p a r t i c u l a r e n t i t y i n the user's program. For example, X might be one p a r t i c u l a r v a r i a b l e , 10 might be one p a r t i c u l a r constant, and X := 10 might be one p a r t i c u l a r statement. Thus, X, 10, and X := 10 are s p e c i f i c s . On the other hand, a generic--.is a set of e n t i t i e s w i t h i n the user's program a l l o f one homogeneous v a r i e t y . , For example, VARIABLE i s a r e f e r e n c e to a c l a s s of e n t i t i e s of which X i s one p a r t i c u l a r member. S i m i l a r l y , CONSTANT and STATEMENT are exam-p l e s of g e n e r i c s . Furthermore, i t i s convenient t o d i v i d e g e n e r i c s i n t o two c l a s s e s . A seament^aeneric i s a g e n e r i c which r e f e r s t o some executable segment of a u s e r ' s program code. For a b l o c k - s t r u c t u r e d language, t y p i c a l segment-generics are PROCESS, PROCEDURE, BLOCK, and STATEMENT. A d a t a - g e n e r i c r e f e r s to a p a r t i c u l a r c l a s s of data which the user's program can manipulate. Thus, f o r a b l o c k - s t r u c t u r e d language, VARIABLE, PARAMETER, and CONSTANT are examples of d a t a - g e n e r i c s . / G e n e r i c s are host-language-dependent. The only presupposi-t i o n which RAIDE makes concerning them i s t h a t t h e r e are two c l a s s e s : segment and data. For each language which i s t o be i n t e r f a c e d t o RAIDE, i t i s necessary to supply a set of Chapter I I . The Debugging System 15 g e n e r i c s . T a b l e I I con t a i n s examples of g e n e r i c s which might be de f i n e d f o r s e v e r a l well-known programming languages., language ALGOL 68 FORTRAN LISP 1.5 PL/I SNOBOL4 segment-generics PROCESS PROGRAM ROUTINE CLAUSE UNIT PROGRAM SUBROUTINE FUNCTION STATEMENT FORM FUNCTION TASK PROCEDURE BLOCK ON_UNIT STATEMENT FUNCTION PREDICATE OPERATOR ST AT EM ENT dat a-g e n e r i c s VARIABLE IDENTITY DENOTATION YIELD VARIABLE ARGUMENT ARRAY CONSTANT ATOM ARGUMENT PRO PERTY_ LIST VARIABLE PARAMETER RETURNED_V ALUE CONSTANT VARIABLE ARGUMENT LITERAL KEY80RD Table I I . Examples of P o s s i b l e G e n e r i c s f o r V a r i o u s Languages The reader may n o t i c e a s u b t l e b i a s of RAIDE which i s evidenced by the d i s t i n c t i o n between segment- and da t a — g e n e r i c s . Languages which make l i t t l e or no d i s t i n c t i o n between executable code and data (e.g.. Lisp) are not n a t u r a l candidates f o r i n c l u s i o n w i t h i n RAIDE even tho t h e i r i n c l u s i o n w i l l not neces-s a r i l y be precluded by the system design. Chapter I I . The Debugging System 16 Related to the concept of a ge n e r i c i s t h a t o f an i n c i d e n t . , An i n c i d e n t i s some a c t i v i t y which i s a s s o c i a t e d with a g e n e r i c . , The system d e f i n e s both segment-incidents and d a t a - i n c i d e n t s to correspond to segment^ and d a t a - g e n e r i c s . , The a c t i v i t i e s which can be a s s o c i a t e d with the segment-generics are ENTRY and EXIT., Thus, i t i s p o s s i b l e to speak of PROCEDURE ENTRY or STATEMENT EXIT. S i m i l a r l y , the a c t i v i t i e s a s s o c i a t e d with the data-g e n e r i c s are ACCESS and UPDATE f o r r e f e r e n c i n g and changing the value of an item of data. Note t h a t i t i s not necessary t h a t every d a t a - g e n e r i c possess both d a t a - i n c i d e n t s . I n p a r t i c u l a r , CONSTANTS cannot be UPDATEd. Unl i k e g e n e r i c s , i n c i d e n t s are f i x e d w i t h i n RAIDE and are not s p e c i f i e d by a host language i n t e r f a c e r . Another system concept i s that of an event. An e v e n t - i s any occurrence which can cause the user's program to stop e x e c u t i o n l e a v i n g RAIDE i n the i n t e r a c t i v e readiest mode. Examples of p o s s i b l e events a re p r e s s i n g the a t t e n t i o n i n t e r r u p t key on the keyboard, an attempt to access a no n e x i s t e n t element of an array i n a program, and changing the value of some program v a r i a b l e . An event which i s d e f i n e d independently of some p a r t i c u l a r source program (e.g., ATTENTION,.!NTERSUPT and OVERFLOW) i s c a l l e d an e x c e p t i o n . Other events are d e s c r i b e d by ex p r e s s i o n s (e.g., "when x>y" to represent the event o c c u r r i n g when the value of the v a r i a b l e * x* exceeds t h a t of the v a r i a b l e * y ' ) . A number of exceptions are p r e d e f i n e d , but language-dependent e x c e p t i o n s can a l s o be d e f i n e d . For example, a Chapter I I . The Debugging System 17 language i n t e r f a c e r f o r Snobol4 might d e f i n e ST ATE HENT_FAII»0 RE. When the user i s i n t e r a c t i n g d i r e c t l y with RAIDE, many p o s s i b l e a c t i o n s can be requested. An a c t i o n i s any p r i m i t i v e o p e r a t i o n which the system can perform. For example, d i s p l a y i s an a c t i o n which causes i n f o r m a t i o n to be d i s p l a y e d to the user, e x e c u t e i s another p r i m i t i v e a c t i o n ; i t i n i t i a t e s e x e c u t i o n of the user's proqram by l e a v i n q the i n t e r a c t i v e request mode. A d e f e r r e d a c t i o n i s any a c t i o n which does not occur immediately upon i t s s p e c i f i c a t i o n . Deferred a c t i o n s allow the user to s e t t r a p s {or demons) w i t h i n the program. Whenever the event a s s o c i a t e d with a d e f e r r e d a c t i o n occurs, the a c t i o n i s i n i t i a t e d by the system. Any a c t i o n which RAIDE can perform immediately can a l s o be d e f e r r e d . , The system maintains a l l d e f e r r e d a c t i o n s on the d e f e r r e d a c t i o n l i s t . . Normally, the user must e x p l i c i t l y remove an a c t i o n from t h i s l i s t u s i n g the c a n c e l a c t i o n ; nonetheless, some d e f e r r e d a c t i o n s are automati-c a l l y removed from the d e f e r r e d a c t i o n l i s t when the a s s o c i a t e d event occurs. Such an a c t i o n i s c a l l e d a t r a n s i g a i isJlglES^ a c t i o n . Altho the b a s i c a c t i o n s of the system are f i x e d , system e x t e n d a b i l i t y i s p r o v i d e d by debugging procedures. A debugging procedure i s a s u b r o u t i n e w r i t t e n u s i n q the p r i m i t i v e a c t i o n s of RAIDE. A debugging procedure can be c a l l e d i n any c o n t e x t i n which an a c t i o n can occur. Thus, i t i s p o s s i b l e to p rovide the user with a l i b r a r y o f debugging procedures which perform any s t a n d a r d debugging o p e r a t i o n s which are not provided as Chapter I I . The Debugging System 18 p r i m i t i v e a c t i o n s i n SAIDE. For example, there i s no p r i m i t i v e RAIDE a c t i o n t o cause a l l procedure i n v o c a t i o n s to be t r a c e d , a l t h o i t i s p o s s i b l e to w r i t e a debugging procedure to accomplish t h i s . The system maintains a l l debugging procedure (and v a r i a b l e ) d e c l a r a t i o n s on the d e c l a r a t i o n , l i s t . In a d d i t i o n to the debugging procedures p r o v i d e d by a standard l i b r a r y and those w r i t t e n by the user, the system i t s e l f p r o v i d e s s e v e r a l b u i l t - i n f u n c t i o n s . These f u n c t i o n s are p r i m a r i l y concerned with i n t e r r o g a t i n g the c u r r e n t s t a t e of the debugging system, such as o b t a i n i n g the name of the most r e c e n t l y executing user procedure. The b u i l t - i n system f u n c t i o n s are l i s t e d i n Appendix A., To allow the user g r e a t e r freedom i n i d e n t i f y i n g s p e c i f i c s and g e n e r i c s w i t h i n t h e e x e c u t i n g program, the system d e f i n e s a d e f a u l t r e f e r e n c e p o i n t . The r e f e r e n c e p o i n t always i n d i c a t e s the program segment c u r r e n t l y a c t i v e when a RAIDE a c t i o n i s i n i t i a t e d . Thus, the r e f e r e n c e point i s used to disambiguate g e n e r i c and s p e c i f i c r e f e r e n c e s . For example, i f the program c o n t a i n s t h r e e procedures, each o f which c o n t a i n s a d i s t i n c t v a r i a b l e named 'foo', the user would always have t o q u a l i f y a r e f e r e n c e t o *foo' t o i n d i c a t e which o f the »foo*s i s d e s i r e d i f t h e r e were no r e f e r e n c e p o i n t . . I f e x e c u t i o n of the program i s suspended, a r e f e r e n c e to •••fop* w i l l a u t o m a t i c a l l y (thru the r e f e r e n c e point) r e f e r to the *foo* i n the procedure i n which exe c u t i o n was suspended, or to the c l o s e s t one a c c e s s i b l e a t the p o i n t of suspension. A user can a l s o e s t a b l i s h a r e f e r e n c e Chapter I I . The Debugging System 19 p o i n t d i f f e r e n t from the d e f a u l t . F i n a l l y , the environment i s the s t a t e of the executing system at any p a r t i c u l a r time. An environment i n c l u d e s the values of a l l of the data i n the user's program, the d e f a u l t r e f e r e n c e p o i n t , and the d e f e r r e d a c t i o n l i s t . I t i s p o s s i b l e i n RAIDE to save the c u r r e n t environment by naming i t and p l a c i n g i t on the accessjLble environment l i s t . Using a p r i m i -t i v e system a c t i o n , the c u r r e n t environment can always be r e p l a c e d by one on the a c c e s s i b l e environment l i s t . T h i s f a c i l -i t y a llows the user to checkpoint the s t a t e of the system and to subseguently r e s t o r e i t . Once the b a s i c concepts d e s c r i b e d above are understood, the RAIDE user should be capable of l e a r n i n g the system debugging language. C, Overview of the Implementation Before proceeding with a d e s c r i p t i o n o f the debugging system language, i t i s d e s i r a b l e t o present an overview of the implementation of the debugging system t o i n s u r e an understand-in g of i t s components when they a r e presented i n d e t a i l . • , A complete d e s c r i p t i o n of the implementation i s c o n t a i n e d i n Chapter V. F i g u r e II-1 i l l u s t r a t e s the debugging environment provided by the system. In t h i s f i g u r e , the l i n e s connecting boxes i n d i c a t e intermodular communication. Each i n t e r f a c e i s assigned Chapter I I . The Debugging System 20 I L1 I I Ln | I T i I | T1 I i<-T RAIDE —i I Y I Tn | :. IF IG T T 1 i — 1 r~ • I I I I t r a n s l a t e d f - >| SPAM I program i —>| I I I I / / I I ->ll II I L -I user | /XXXXXXXX/ / ( ] / A r e q u e sts from the user ( w r i t t e n i n Dispel) B BAIDE*s responses to user r e q u e s t s C i n f o r m a t i o n s u p p l i e d t o RAIDE by the language i n t e r f a c e r s D i n f o r m a t i o n s u p p l i e d to RAIDE by the t r a n s l a t o r s E i n f o r m a t i o n s u p p l i e d to SPAM by the t r a n s l a t o r s F a n a l y s i s and m o d i f i c a t i o n o f the user program by RAIDE G i n t e r a c t i o n s of RAIDE and SPAM Fig u r e I I - 1 . Overview of the Implementation Chapter II. The Debugging System 21 a l e t t e r for i d e n t i f i c a t i o n . The boxes L 1 , .. ., Ln represent the languages which are interfaced to RAIDE. For each language using the debugging system, language inter f a c e r s must provide RAIDE with information that i s dependent on each host language <C). This information, which i s summarized i n Table I I I , | 1. d e f i n i t i o n s of the segment- and data-generics J J 2. run-time error messages I j 3. i d e n t i f i c a t i o n of any language-dependent exceptions I | 4. d e f i n i t i o n s of generic-related and language-dependent system I | functions I j Table I I I . Information Supplied to RAIDE by the Language I I Interfacers J I — — - ; . _ _ • — .— - , — _ _ _ _ _ — — — — J includes the d e f i n i t i o n s of the segment- and data-generics of each language, the set of language-oriented run-time error messages, i d e n t i f i c a t i o n of any language-dependent exceptions, and the d e f i n i t i o n s of any generic-related and language-dependent system functions. For each language L i interfaced to the system, there must exist at least one t r a n s l a t o r T i which has been constructed or modified to furnish RAIDE with information to f a c i l i t a t e run-time debugging. As stated previously, the system runs using translated source code to expedite implementation and to insure source language independence. To accomplish t h i s , a v i r t u a l Chapter I I . The Debugging System 22 debugging machine (which i s c a l l e d SPAM) has been d e f i n e d and i s de s c r i b e d i n Chapter IV. Each language t r a n s l a t o r i n t e r f a c e d to the system must supply i n f o r m a t i o n both to SPAM and d i r e c t l y t o RAIDE. Tab l e IV o u t l i n e s the i n f o r m a t i o n which the t r a n s l a t o r s r • : ~ ~ : « I 1. SPAM machine code f o r the user program J | 2. d e s c r i p t i o n s of a l l program code segments and data items I | 3. run-time type t a b l e J \ 4. run-time bounds t a b l e I | Table IV. Information S u p p l i e d to SPAM by the T r a n s l a t o r s \ L ; : . __ , : , — I must f u r n i s h t o SPAM (E). T r a n s l a t o r s using RAIDE must map the user's source program i n t o SPAM machine code. In a d d i t i o n , they must supply the v i r t u a l machine with a d e s c r i p t i o n of a l l program code segments and data items, a type t a b l e , and a bounds t a b l e f o r ar r a y s u b s c r i p t checking. The t r a n s l a t o r s must f u r n i s h RAIDE (D) with symbol t a b l e i n f o r m a t i o n , a d e s c r i p t i o n of the s t a t i c ( i . e . , t e x t u a l ) s t r u c t u r e of the source program, and the source program code i t s e l f . T h i s i n f o r m a t i o n i s o u t l i n e d i n Table V., The user d i r e c t s the debugging system (A) from an i n t e r a c -t i v e t e r m i n a l using the debugging system language, which i s c a l l e d D i s p e l . T h i s language i s d e s c r i b e d i n d e t a i l i n Chapter I I I . RAIDE * s responses t o user requests (B) are d i r e c t e d back Chapter I I . The Debugging System 23 i • — • — " ' — ~ : 1 J 1. run-time symbol t a b l e 1 | 2. s t a t i c s t r u c t u r e of the program i n terms of the segment- I | g e n e r i c s I j 3. source program code I | Table V. Information S u p p l i e d t o RAIDE by the T r a n s l a t o r s j L . . ; ; — _ _ 1 to the t e r m i n a l . To process the u s e r ' s r e q u e s t s , RAIDE uses the i n f o r m a t i o n s u p p l i e d to i t by t h e language i n t e r f a c e r s (C), the language t r a n s l a t o r s (D), the t r a n s l a t e d program ( F l , the v i r t u a l machine (G), and i t s own r e c o r d of program and system execution. To s e t program t r a p s , to obtain run-time a n a l y s i s i n f o r m a t i o n , and to modify the va l u e s o f program v a r i a b l e s , RAIDE must i n t e r a c t d i r e c t l y with the t r a n s l a t e d program (F). Nev e r t h e l e s s , the t r a n s l a t e d program i s p r i m a r i l y c o n t r o l l e d by the v i r t u a l machine. When SPAM d e t e c t s an e r r o r d u r i n g program ex e c u t i o n , i t s u p p l i e s RAIDE with i n f o r m a t i o n concerning the e r r o r and the s t a t e of the program (G). L i k e w i s e , RAIDE can i n t e r a c t d i r e c t l y with SPAM to i n q u i r e concerning the s t a t e of program execution and to make c e r t a i n m o d i f i c a t i o n s t o i t (G). System design c r i t e r i o n 6 s t a t e s that t r a n s l a t o r s should be allowed t o supply i n f o r m a t i o n i n su c c e s s i v e l a y e r s of complete-ness. The d i s c u s s i o n concerning the i n f o r m a t i o n which must be s u p p l i e d t o RAIDE, as o u t l i n e d i n T a b l e s I I I t h r u V, seems to imply t h a t f u l l y c o o p e r a t i n g t r a n s l a t o r s are necessary; however, t h i s i s not the case as the d i s c u s s i o n so f a r has centered Chapter I I . , The Debugging System 24 around the most complete debugging c o n f i g u r a t i o n . T a b l e 71 o u t l i n e s the l e v e l s of support at which the debugging system i s capable of running. Seven s u c c e s s i v e l y more complete l a y e r s of debugging sup-port are d e f i n e d . In the b a s i c machine l e v e l , RAIDE i s not a v a i l a b l e and the v i r t u a l machine runs with the minimum of overhead. At t h i s l e v e l the t r a n s l a t o r s are only r e q u i r e d to generate SPAM code and d e s c r i p t o r s , and to su p p l y the type and bounds t a b l e s . The b a s i c machine l e v e l corresponds t o a user program running on a bare machine t h a t i s more s o p h i s t i c a t e d than many c u r r e n t l y i n e x i s t e n c e . The next l e v e l of support i s the machine debugging l e v e l . , A l t h o RAIDE i s again not a v a i l a b l e , the v i r t u a l machine w i l l make a d d i t i o n a l run-time checks <e.g., scope v i o l a t i o n s and mismatched parameters) which are not performed i n the most b a s i c mode o f machine e x e c u t i o n . These a d d i t i o n a l checks are not r e q u i r e d f o r the machine to execute p r o p e r l y , but are intended t o f u r t h e r the debugging process. RAIDE i t s e l f i s not a proper component of the system u n t i l the t h i r d l e v e l of debugging support, the simple symbolic l e v e l . At t h i s l e v e l RAIDE i s only capable of r e p o r t i n g e r r o r s and executing simple i n t e r a c t i v e r e q u e s t s , such as i n s p e c t i n g the val u e of a v a r i a b l e . The lanquaqe i n t e r f a c e r s must supply RAIDE with enough i n f o r m a t i o n t o p r o p e r l y i n t e r p r e t and r e p o r t the e r r o r c o n d i t i o n s d e t e c t e d by SPAM. The t r a n s l a t o r s must supply some symbol t a b l e i n f o r m a t i o n so t h a t d e t a i l e d e r r o r messages Chapter I I . The Debugging System 25 l e v e l of support 1. b a s i c machine module t r a n s l a t o r SPAM R AIDE 2. machine debugging SPAM 3. simple symbolic RAIDE i n t e r f a c e r t r a n s l a t o r RAIDE 4. symbolic debugging i n t e r f a c e r t r a n s l a t o r RAIDE 5. f u l l debugging 6. f u l l a n a l y s i s 7. deluxe debugging t r a n s l a t o r RAIDE RAIDE t r a n s l a t o r RAIDE generates SPAM code and d e s c r i p t o r s , and s u p p l i e s type and bounds t a b l e s executes code normally checking f o r b a s i c run-time e r r o r s not a v a i l a b l e makes a d d i t i o n a l checks on operands and i n t e r r u p t f l a g s not a v a i l a b l e s u p p l i e s g e n e r i c i n f o r m a t i o n and e r r o r messages s u p p l i e s some symbol t a b l e i n f o r m a t i o n a v a i l a b l e f o r simple i n t e r a c t i v e reguests i d e n t i f i e s language-dependent ex c e p t i o n s and d e f i n e s g e n e r i c - r e l a t e d system f u n c t i o n s s u p p l i e s complete symbol t a b l e a v a i l a b l e f o r more complex i n t e r a c t i v e reguests d e s c r i b e s s t a t i c program s t r u c t u r e can respond to regue s t s i n v o l v i n g s t a t i c program s t r u c t u r e keeps run-time a n a l y s i s s t a t i s t i c s s u p p l i e s source program code can respond to re q u e s t s to d i s p l a y source code a t run-time Ta b l e VI. L e v e l s o f Debugging Support Chapter I I . The Debugging System 26 can be generated i n symbolic terras. I f the language i n t e r f a c e r s i d e n t i f y the language-dependent e x c e p t i o n s and d e f i n e the g e n e r i c - r e l a t e d system f u n c t i o n s , and the language t r a n s l a t o r s supply the complete symbol t a b l e , RAIDE i s capable of i n i t i a t i n g more complex i n t e r a c t i v e user r e g u e s t s , such as d i s p l a y i n g the c u r r e n t s t a t e of the e x e c u t i n g program. T h i s corresponds to the symbolic debugging l e v g l . I f the t r a n s l a t o r s supply a d e s c r i p t i o n o f the s t a t i c s t r u c t u r e of the user program (e.g., i n f o r m a t i o n concerning the n e s t i n g of s e g m e n t - s p e c i f i c s and the scope of v a r i a b l e s ) * the fail debugging l e v e l i s en t e r e d . , At t h i s l e v e l , RAIDE i s capable of i n i t i a t i n g r equests which i n v o l v e the s t a t i c s t r u c t u r e of the proqram (e.g., dynamic flow t r a c i n g , postmortem tra c e b a c k s , and the s e t t i n g of i n t r i c a t e t r a p s ) . In the f & l i a n a l y s i s l e v e l , RAIDE keeps run-time a n a l y s i s s t a t i s t i c s , such as how many times each program statement i s executed or each v a r i a b l e i s accessed. In the deluxe debugging l e v e l , t r a n s l a -t o r s supply the source program code. ; This enables RAIDE to respond to a user request t o d i s p l a y p o r t i o n s o f the source code a t run-time. For the most p a r t , the user w i l l not need t o be concerned with the l e v e l s o f debuqqing support, s i n c e the system w i l l always inform the user i f some reguested a c t i o n cannot be performed due to l a c k o f i n f o r m a t i o n . ; 27 Chapter I I I . , The Debugging System Language For the user t o communicate with RAIDE, i t i s necessary to provide a language embodying the p r i m i t i v e system a c t i o n s and s u p p o r t i n g f u t u r e e x t e n s i o n s to the debugging environment. The debugging language o f RAIDE i s c a l l e d D i s p e l (Debugging S p e c i f i c a t i o n Language), a name chosen more f o r i t s mnemonic than f o r i t s acronymic value. The f i r s t s e c t i o n of t h i s chapter d e s c r i b e s D i s p e l ' s d e s i g n c r i t e r i a . T h i s i s f o l l o w e d by a d e s c r i p t i o n of the syntax and semantics of the language i t s e l f , a s e c t i o n c o n t a i n i n g s e v e r a l examples of debugging requests coded u s i n g D i s p e l , and f i n a l l y a d i s c u s s i o n of how w e l l the language f u l f i l l s i t s g o a l s . A. Design C r i t e r i a The most obvious design c r i t e r i o n of D i s p e l i s t h a t i t should r e f l e c t the d e s i g n c r i t e r i a of RAIDE i t s e l f and should embody the b a s i c RAIDE concepts. In p a r t i c u l a r , the language must be i n t e r a c t i v e - o r i e n t e d and should only c o n t a i n a s m a l l number of p r i m i t i v e a c t i o n s . i t i s a l s o necessary, however, t h a t the language s a t i s f y other c r i t e r i a [Brad 68, G r i s 71a, Hann 73, Schw 71). D i s p e l should be uniform. U n i f o r m i t y i m p l i e s t h a t the syntax i s c l e a n and c o n s i s t e n t s i n c e i t connotes the e x i s t e n c e of few s y n t a c t i c e x c e p t i o n s and s p e c i a l cases. A c o n s t r u c t i s always used i n the same way r e g a r d l e s s of i t s c o n t e x t , Impor-Chapter I I I . The Debugging System Language 28 t a n t a t t r i b u t e s of a uniform language are t h a t i t can be d e s c r i b e d s u c c i n c t l y {cf. , the A l g o l 68 syntax c h a r t f Hatt 74]) and t h a t i t i s easy to l e a r n and to implement [VanW 76:sec. 0 . 1.2]. Altho the language should be uniform, i t must a l s o be reasonably simple t o use. U n i f o r m i t y must not i n t r o d u c e unnec-es s a r y semantic complexity {or d e l e t e r i o u s s u p e r f l u i t i e s , as the A l g o l 68 Revised Report [VanM 76] s a y s ) . . I f the language i s complex, the programmer may have to debug the debugging procedures! T h i s i s c l e a r l y u n d e s i r a b l e s i n c e the o v e r a l l i n t e n t of the system i s to reduce the t o t a l debugging e f f o r t . A complex system i s f r e q u e n t l y more of a l i a b i l i t y than an a s s e t . In a d d i t i o n t o s i m p l i c i t y , the lanquaqe must be r e a d a b l e and should appear to be a n a t u r a l e x t e n s i o n of the host source languages. But c a r e must be taken to i n s u r e t h a t the debugging language does not become e a s i l y confused with the host languages. To f u l f i l l system design c r i t e r i o n 8 ( v i z . , c o n c i s e n e s s and p e r t i n e n c e of the i n f o r m a t i o n s u p p l i e d by the system), the syntax of D i s p e l should discourage voluminous output. The user should be encouraged t o c a r r y out the debugging process thought-f u l l y and to a v o i d debugging by deluge. D e s i g n i n g a syntax which discourages e x c e s s i v e output may c o n f l i c t with the g o a l t h a t the language be c o n c i s e . I t i s not obvious where the compromise between these two c r i t e r i a should be made. Chapter I I I . The Debugging System Language 29 The f i n a l , important design c r i t e r i o n of D i s p e l i s t h a t the syntax should allow f o r p o s s i b l e extensions of the debugging environment t o meet new needs not c u r r e n t l y e n v i s i o n e d . Lan-guage e x t e n d a b i l i t y w i l l be provided t h r u debugging procedures. I f the debugging system and i t s language supply s u f f i c i e n t p r i m i t i v e a c t i o n s , debugging procedures w i l l a f f o r d the r e q u i s i t e language e x t e n d a b i l i t y . Thus, i t should not be neces-sary t o change the syntax of the l a n g u a g e i t s e l f to f u l f i l l f u t u r e reguirements. In summary, the design c r i t e r i a d i s c u s s e d above are l i s t e d i n T a b l e VII. A f t e r d e t a i l i n g the syntax and semantics of D i s p e l and g i v i n g a number of examples, a d i s c u s s i o n of how w e l l these c r i t e r i a are met w i l l be made. 1. The language should be i n t e r a c t i v e - o r i e n t e d . 2. Only a s m a l l s e t of p r i m i t i v e a c t i o n s s h o u l d be s u p p l i e d . 3. The language should embody the b a s i c debugging system concepts. 4. The syntax should be uniform. 5. The language should be simple t o use. 6. I t should be easy t o read and understand debugging programs. 7. The language should discourage voluminous output., 8. The language should be extendable., Table V l l . Debugging Language Design C r i t e r i a Chapter I I I . The Debugging System Language 30 B. Syntax and Semantics In the ensuing d i s c u s s i o n , an o u t l i n e of the syntax o f D i s p e l i s presented u s i n g a v a r i a t i o n of the s y n t a c t i c metalan-guage Backus-Naur Form (BNF) . Two extensions to BNF are used: sguare brackets (f ]) to d e l i m i t an o p t i o n a l c o n s t r u c t and braces (O) t o cj^oup together s e v e r a l c o n s t r u c t s which are t r e a t e d as a s i n g l e u n i t . A l s o , the keywords of D i s p e l ( i . e . , the t e r m i n a l symbols) are i n b o l d f a c e and nonterminal symbols are d e l i m i t e d by angle bra c k e t s (<>). A more complete s y n t a c t i c s p e c i f i c a t i o n of D i s p e l , using a syntax c h a r t , i s i n Appendix B. For l a c k of a l e s s p r o s a i c s u b s t i t u t e , the semantics of D i s p e l i s presented u s i n g the semantic metalanguage E n g l i s h . In the examples to f o l l o w , upper-case i d e n t i f i e r s r e p r e s e n t language-dependant e n t i t i e s (e.g., g e n e r i c names), i n c i d e n t s , e x c e p t i o n names, and the names of system f u n c t i o n s . Lower-case i d e n t i f i e r s r e p r e s e n t program-dependent e n t i t i e s (e.g., s p e c i f i c names) and the names of debugging v a r i a b l e s and procedures. The fundamental s y n t a c t i c e n t i t y i s an <utteranca>. <utterance> ::= <explanation> . | <inguiry> . J <declaration> . I < d e f i n i t i o n X . j <command> . The <utterance> i s the ba s i c u n i t of i n t e r a c t i v e input. U n t i l the f u l l - s t o p (.) i s encountered, the <utterance> i s checked only f o r s y n t a c t i c c o r r e c t n e s s ; the f u l l - s t o p i n i t i a t e s semantic i n t e r p r e t a t i o n . Chapter I I I . The Debugging System Language 3 1 The syntax of an <explanation> i s : <explanation> ::= e x p l a i n <keyphrase> An <explanation> f u r n i s h e s the user with an e x p l a n a t i o n of some component of the system, as s i g n i f i e d by the <keyphrase>. The p o s s i b l e <keyphrase>s w i l l not be l i s t e d , but they i n c l u d e such terms as "command", "break", " d i s p l a y " , " s p e c i f i c " , and " d e f e r r e d a c t i o n " . The <explanation> <utterance> p r o v i d e s the rudiments of an i n t e r a c t i v e document querying f a c i l i t y . An <inguiry> has the syntax: <inquiry> : : = • i n q u i r e :<sentence> An <inguiry> enables a l i n k i n t o a n a t u r a l language i n t e r r o g a -t i o n system which p r o v i d e s i n f o r m a t i o n concerning the debugging system and the s t a t e of program e x e c u t i o n by means other than t h r u D i s p e l <coamand>s. The f o l l o w i n g i s a sample <inguiry>. i n q u i r e "In the procedure F00, what i s the value of the v a r i a b l e Z the f i r s t time X i s greater than Y?". An <inguiry> can be used to e x t r a c t i n f o r m a t i o n which the user p r e f e r s t o express i n n a t u r a l language terms. The syntax of a <sentence> i s u n s p e c i f i e d as f a r as the debugging system i s concerned., A <declaration> s p e c i f i e s debugging v a r i a b l e s , as opposed t o user program v a r i a b l e s . <declaration> ::= < i n t e g e r - d e c l a r a t i o n > | < s p e c i f i c - d e c l a r a t i o n > < i n t e g e r - d e c l a r a t i o n > ::= i n t e g e r £ ( <expression> ) ] < i d - l i s t > < s p e c i f i c - d e c l a r a t i o n > ::= s p e c i f i c [ ( <expression> ) ] < i d - l i s t > < i d - l i s t > ::= < i d e n t i f i e r > [, < i d - l i s t > ] Chapter I I I , The Debugging System Language 32 As i n d i c a t e d above, the two types of debugging v a r i a b l e s are i n t e g e r s and s p e c i f i c s . The o p t i o n a l <expression> denotes the d e c l a r a t i o n of debugging a r r a y v a r i a b l e s ; i t must e v a l u a t e to an i n t e g e r value i n d i c a t i n g the s i z e of the a r r a y . Elements of debugging a r r a y v a r i a b l e s a re s e l e c t e d using s u b s c r i p t s . Examples of debugging v a r i a b l e s are given i n the l a s t s e c t i o n of t h i s chapter, at which time t h e i r u t i l i t y w i l l become more apparent. A < d e f i n i t i o n > i d e n t i f i e s a debugging procedure. < d e f i n i t i o n > : : = d e f i n e ;<procedure-id> [ ( <declarat i o n - l i s t > ) ) a s <command> < d e c l a r a t i o n - l i s t > ::= <declaration> T ; < d e c l a r a t i o n - l i s t > ] The o p t i o n a l < d e c l a r a t i o n - l i s t > s p e c i f i e s the f o r m a l parameters of the debugging procedure. Whenever i n i t i a t i o n of the proce-dure (as i d e n t i f i e d by i t s <procedure-id>) i s i n d i c a t e d , the <command> a s s o c i a t e d with the < d e f i n i t i o n > i s i n i t i a t e d . . The most important <utterance> of D i s p e l i s the <command>. <command> ::= [<when-clause>] <action> <when-clause> ::= [ < l a b e l - i d > ;] <when> <when> : : = w h e n <condition> ) o n < e x c e p t i o n - l i s t > | b e f o r e < s p e c i f i c - i n c i d e n t - l i s t > | a f t e r < s p e c i f i c - i n c i d e n t - l i s t > < e x c e p t i o n - l i s t > <exception> f , < e x c e p t i o n - l i s t > ] < s p e c i f i c - i n c i d e n t - l i s t > ::= < s p e c i f i c - i n c i d e n t > r , < s p e c i f i c - i n c i d e n t - l i s t > ] The <when-clause> o f a <command> causes the a s s o c i a t e d <action> to become a d e f e r r e d a c t i o n . The <label-id> of the <when-clause> i s used to remove the a c t i o n from the d e f e r r e d a c t i o n l i s t . For a d e f e r r e d a c t i o n , whenever the s p e c i f i e d event o c c u r s , the a s s o c i a t e d <action> i s i n i t i a t e d . <action>s which Chapter I I I . The Debugging System Language 33 are not d e f e r r e d are i n i t i a t e d immediately upon e n t r y by the user. I f a <when-clause> i s contained w i t h i n a debugging procedure, any a c t i o n s d e f e r r e d by execution o f the procedure are not canceled when the procedure i s e x i t e d . Thus, the establishment o f d e f e r r e d a c t i o n s i s independent of procedure scope. Furthermore, a l l <label-id>s are g l o b a l and can be ref e r e n c e d r e g a r d l e s s of t h e i r t e x t u a l scope. I f s e v e r a l <when^clause>s have been executed f o r the same event, o n l y the most r e c e n t l y d e f e r r e d a c t i o n w i l l be i n i t i a t e d when the event occurs. Deferred a c t i o n s f o r the same event are s t a c k e d ; the <cancel-action> i s used to remove an a c t i o n from the stack. There are f o u r forms of the <when-clause>^ The w h e n <condition> form s p e c i f i e s t h a t t he a s s o c i a t e d <action> i s to be i n i t i a t e d whenever the i n d i c a t e d <condition> becomes t r u e . <condition> can be any ex p r e s s i o n which y i e l d s a boolean value.. For example, " w h e n x>y b r e a k ' ! means that the i n t e r a c t i v e request mode i s to be entered ( i . e . , a break i s to occur) whenever the value of the v a r i a b l e 'x* i s g r e a t e r than t h a t of *y*. The means by which t h i s t r a p i s e s t a b l i s h e d i s implementation-dependent. The o n < e x c e p t i o n - l i s t > form of the <when-clause> s p e c i f i e s t h a t the a s s o c i a t e d <action> i s to be i n i t i a t e d whenever one of a s e t of p o s s i b l e <exception>s o c c u r s . The p o s s i b l e <exception>s are not l i s t e d here, but they i n c l u d e ATTEMTioN_INTERRUPT, OVERFLOW, and ZERODIVIDE. For example, " o n ATTENTION_INTERRUPT g a i t " w i l l cause RAIDE to be e x i t e d i f the Chapter I I I . The Debugging System Language 34 a t t e n t i o n i n t e r r u p t key i s pressed. The before and after forms of the <when-clause> cause the a s s o c i a t e d <actio.n> to be i n i t i a t e d b efore or a f t e r some p a r t i c u l a r i n c i d e n t o c c u r s . For example, after each STATEMENT in foo break. s e t s a t r a p a f t e r each executable statement i n the procedure • f o o 1 . "each STATEMENT in f o o " i s a <specif i c - i n c i d e n t > ; i t p i n p o i n t s the s e t t i n g o f a t r a p . The c o p p l e t e syntax of < s p e c i f i c - i n c i d e n t > f o l l o w s . < s p e c i f i c - i n c i d e n t > < s p e c i f i c > f < g e n e r i c - i n c i d e n t > ] < s p e c i f i c > <variable> | [each] <generic> f < s e g m e n t - g u a l i f i e r > ] < g e n e r i c - i n c i d e n t > <segment-incident> j <data-incident> <segment-incident> : := INT EX J EXIT <data-incident> :;= ACCESS | UPDATE <variable> ::= [<generic> : j < u n g u a l i f i e d - v a r i a b l e > [ <segfflent-qualifier> 3 < u n g u a l i f i e d - v a r i a b l e > < s u b s c r i p t e d - v a r i a b l e > [. < u n g u a l i f i e d - v a r i a b l e > ] S u b s c r i p t e d - v a r i a b l e > ;:= <v a r i a b l e - i d > f ( < e x p r e s s i o n - l i s t > ) ] <segment-gualifier> ::= in <vaciable> < e x p r e s s i o n - l i s t > <expression> [, < e x p r e s s i o n - l i s t > ] The each form of the < s p e c i f i c > i s used t o transform a <generic> i n t o a sequence of < s p e c i f i c > s . The p o s s i b l e <generic>s are languages-dependent. I t should be noted t h a t "each** generates a sequence o f < s p e c i f i c > s based on t h e i r t e x t u a l o r g a n i z a t i o n . For example, "each VARIABLE in f o o " i d e n t i f i e s a l l v a r i a b l e s d e c l a r e d i n the procedure »foo*, not those r e f e r e n c e d i n •foo'. L i k e w i s e , "each PROCEDURE in foo" i d e n t i f i e s the procedures d e c l a r e d l o c a l t o •foo', not those invoked from *foo*. Chapter I I I , The Debugging System Language 35 I t i s important t h a t the user understand a t what times < s p e c i f i c > s are evaluated s i n c e t h i s g r e a t l y a f f e c t s the s p e c i f i c a t i o n of <utterance>s. There ace three forms of < s p e c i f i c > e v a l u a t i o n : s t a t i c , dynamic, and c o n t i n u a l . During s t a t i c e v a l u a t i o n , < s p e c i f i c > s are evaluated once, upon s p e c i f i -c a t i o n of the <utterance> c o n t a i n i n g them. The < s p e c i f i c > s i n the b e f o r e and a f t e r forms of the <when?-clause> and a l l those not d e f e r r e d or c o n t a i n e d w i t h i n debugging procedures are e v a l u a t e d s t a t i c a l l y . During dynamic e v a l u a t i o n . < s p e c i f i c > s are evaluated once, upon i n i t i a t i o n o f the <command> c o n t a i n i n g them. The < s p e c i f i c > s contained w i t h i n d e f e r r e d a c t i o n s and w i t h i n the bodies of debugging procedures are evaluated dynami-c a l l y . During continual'•• evaluation,-. < s p e c i f i c > s are e v a l u a t e d r e p e a t e d l y u n t i l the d e f e r r e d a c t i o n s c o n t a i n i n g them are canceled. The < s p e c i f i c > s w i t h i n the when <condition> form of the <when-clause> are e v a l u a t e d c o n t i n u a l l y . The b a s i c a c t i o n s of RAIDE are s p e c i f i e d i n D i s p e l as f o l l o w s . <action> : = <compound-action> <break-action> < c a l l - a c t i o n > <cancel-action> < d i s p l a y- a c t i o n > <execute-action> <for-action> < i f - a c t i o n > <input-action> 1 <guit-action> j <reference-action> | <restore-action> I <save-action> \ <set-action> J <skip-action> J <system-action> I <while-action> These <action>s are d e s c r i b e d below i n a l p h a b e t i c order of the keyword which begins each. Chapter I I I . The Debugging System Language 36 The <compound-action> i s a s y n t a c t i c device to all o w the grouping of m u l t i p l e a c t i o n s i n t o one. <compound-action> : : = b e g i n [ < d e c l a r a t i o n - l i s t > ; ] <command-list> e n d <command-list> ::= <command> [ ; <command-list>]-< d e c l a r a t i o n s w i t h i n a <compound-action> have a scope and l i f e -time l o c a l to the d e f i n e d block. The <compound-action> allows an e n t i r e s e r i e s of <command>s t o be s p e c i f i e d wherever a s i n g l e <action> can be s p e c i f i e d . The <break-action> i n d i c a t e s that p r o c e s s i n g i s t o r e v e r t to the i n t e r a c t i v e request mode. The <break-action> i s designed f o r use with i n d e f e r r e d a c t i o n s and debugging procedures only. I t s syntax i s : <break-action> ::= b r e a k [<message> ] . When a <break-action> i s i n i t i a t e d , the d e f e r r e d a c t i o n or debuqqinq procedure - c o n t a i n i n q - t h e b r e a k i s terminated, the <message> i s d i s p l a y e d on the output d i s p l a y d e v i c e , and B&IDE e n t e r s the request mode wa i t i n g f o r the s p e c i f i c a t i o n of some <utterance>. The < c a l l - a c t i o n > causes a debugging procedure t o be c a l l e d a f t e r e v a l u a t i o n , of i t s arguments. < c a l l - a c t i o n > ::= c a l l <procedure-id> {{ < e x p r e s s i o n - l i s t > )••] Recursive debugging procedures are supported. The parameter passing mechanism i s c a l l by r e f e r e n c e , as i n PL/I [ IBM 70]. The <cancel-action> causes one or more d e f e r r e d a c t i o n s to be removed from the d e f e r r e d a c t i o n l i s t . Chapter I I I . The Debugging System Language 37 <cancel-action> ::= c a n c e l [ < c a n c e l - l i s t > ] < c a n c e l - l i s t > ::= {<label-id> | <variable>| (, < c a n c e l - l i s t > } c a n c e l without an argument i s used only w i t h i n d e f e r r e d a c t i o n s ; i t causes the d e f e r r e d a c t i o n which c o n t a i n s i t to be can c e l e d . D e f e r r e d a c t i o n s which were gi v e n <label-id>s can be c a n c e l e d by l i s t i n g the <label-id> (e.g., c a n c e l f o o ) . I f a d e f e r r e d a c t i o n was not l a b e l e d , the system. w i l l a u t o m a t i c a l l y a s s i g n a <label-id> t o i t ; t h i s l a b e l i s used t o c a n c e l i t . The system f u n c t i o n DEFEBRED_aCTION_LIST ( c f . , Appendix ft) can be used as a <variable> t o a l s o i d e n t i f y a c t i o n s t o be canceled. The < d i s p l a y - a c t i o n > causes one o r more p i e c e s of informa-t i o n to be d i s p l a y e d on the output d i s p l a y d e v i c e , or on some a u x i l i a r y f i l e or d e v i c e . < d i s p l a y - a c t i o n > ::= d i s p l a y <what-list> f o n <file-name>l <what-list> ::= <expression> f a s <type>] [, <what-list> ]| When the <dis p l a y - a c t i o n > i s i n i t i a t e d , the designated <expression>s are p r i n t e d on the f i l e <file-name>, which d e f a u l t s t o the output d i s p l a y d e v i c e . The syntax of <file-name> i s operating-system-dependent.,,. Unless i n d i c a t e d otherwise, an <expression> w i l l be d i s p l a y e d i n a format s u i t a b l e to i t s type a t t r i b u t e s ; the <type> c l a u s e can be used to o v e r r i d e t h i s d e f a u l t . Numerous examples of the <display-action> are g i v e n i n the next s e c t i o n . The <display-action> works by maintaining a d i s p l a y b u f f e r of a l l <expression>s to be d i s p l a y e d . T h i s b u f f e r i s presented t o the user e i t h e r when one of the format f u n c t i o n s PAGE or LINE i s d i s p l a y e d ( c f . , Appendix A) or when the i n t e r a c t i v e request mode i s entered. Chapter I I I . The Debugging System Language 38 The <execute-action> causes the user's program t o be execu-te d , l e a v i n g the i n t e r a c t i v e request mode of RAIDE. <execute-action> ::= e x e c u t e f <expression> [ <segment-generic> ~\ ] i e x e c u t e w h i l e <condition> e x e c u t e without an argument causes the program to be resumed a t i t s p o i n t of suspension ( i . e . , - t h e d e f a u l t r e f e r e n c e p o i n t ) , or at i t s beginning i f there i s no suspension p o i n t . The other forms o f the <execute-action> are the same except t h a t execution l i m i t s are imposed. These e x e c u t i o n l i m i t s can be thought of as t r a n s i e n t d e f e r r e d a c t i o n s which cause a b r e a k when the a p p r o p r i a t e event occurs. The f i r s t a l t e r n a t i v e of the <execute-action> causes a p a r t i c u l a r number of segment-generics t o be executed. For example, " e x e c u t e 3 STATEMENTS" causes the user's program to be resumed f o r the execution of e x a c t l y t h r e e s o u r c e - l e v e l statements o f the c u r r e n t procedure. <segment-generic> d e f a u l t s t o the l o w e s t - l e v e l seqment-qeneric d e f i n e d f o r the host source language. T h i s form allows the user t o step t h r u execution of the^ program. The other a l t e r n a t i v e of the <execute-action> causes the program t o be resumed u n t i l the i n d i c a t e d <condition> becomes f a l s e . I t should be noted t h a t resumption of the user's program at an a r b i t r a r y l o c a t i o n i s not allowed i n RAIDE. I t i s f e l t that such a f a c i l i t y i s not w e l l s t r u c t u r e d and i s e r r o r - p r o n e , and t h a t i t should be avoided i n the debugging phase j u s t as u n r e s t r i c t e d t r a n s f e r s of c o n t r o l s hould be avoided i n source language programs. With the a d d i t i o n of the <skip-action>, the user should f i n d t h i s c o n s t r a i n t t o l e r a b l e . Chapter I I I . , The Debugging System Language 39 The <for-action> i s a c o n t r o l s t r u c t u r e which a l l o w s r e p e t i t i v e i n i t i a t i o n o f some <a c t i o n > i <for-action> :: = f o r < s p e c i f i c - l i s t > -> < s p e c i f i c - i d > d o <action> The < s p e c i f i c - i d > i d e n t i f i e s a s p e c i f i c v a r i a b l e which has a scope encompassing the" r e p e t i t i v e <action>. I t i s i m p l i c i t l y d e f i n e d to be of type s p e c i f i c . The < s p e c i f i c - l i s t > i d e n t i f i e s a s e t of s p e c i f i c s , the members of which are s u c c e s s i v e l y assigned t o the < s p e c i f i c - i d > . Each time the r e p e t i t i v e <action> i s i n i t i a t e d , < s p e c i f i c - i d > w i l l i d e n t i f y a d i f f e r e n t member of the s e t . The programmer cannot e x p l i c i t l y change t h i s a s s o c i a t i o n w i t h i n the r e p e t i t i v e <action>. The < i f - a c t i o n > i s a c o n t r o l s t r u c t u r e which s e l e c t s one of two p o s s i b l e a c t i o n s f o r i n i t i a t i o n based on some c o n d i t i o n a l e x p r e s s i o n . < i f - a c t i o n > ::= i f <condition> t h e n <action> f e l s e : < a c t i o n > ] f i I f the i n d i c a t e d <condition> i s t r u e , the <action> f o l l o w i n g t h e n i s i n i t i a t e d ; otherwise the <action> f o l l o w i n g e l s e , i f present, i s i n i t i a t e d . , The <input-action> causes a s e r i e s o f <utterance>s to be read from some f i l e or de v i c e . I t s syntax i s : <input-action> ::= i n p u t [<file-name>] <file-name> i s the name of a f i l e which c o n t a i n s a c o l l e c t i o n of <utterance>s which are i n i t i a t e d . The syntax o f <file-name> i s operating-system-dependent, and i t d e f a u l t s t o some o p e r a t i n g -system-dependent v a l u e . . The <input-action> i s most u s e f u l f o r Chapter I I I . The Debugging System Language 40 s p e c i f y i n g l i b r a r i e s of canned debugging procedures. The <guit-action> causes the debugging system t o be e x i t e d and c o n t r o l r e t u r n e d to the o p e r a t i n g system. I t s syntax i s : <guit-action> ::= q u i t [<message> ] I f present, the <message> i s d i s p l a y e d on the output d i s p l a y d e v i c e before t e r m i n a t i o n of the debugging s e s s i o n . The <reference-action> e s t a b l i s h e s a r e f e r e n c e p o i n t which i s d i f f e r e n t from the d e f a u l t . <reference-action> : : = r e f e r e n c e r<variable> ] I f a <variable> i s i n d i c a t e d , i t i s used to disambiguate r e f e r e n c e s to s p e c i f i c s and g e n e r i c s u n t i l the next <reference-action> or <execute-action> i s i n i t i a t e d . r e f e r e n c e : without an argument causes the r e f e r e n c e p o i n t to r e v e r t t o the d e f a u l t r e f e r e n c e p o i n t ( i . e . , to the r e f e r e n c e p o i n t when the i n t e r a c t i v e request mode was entered most r e c e n t l y ) . The <restore-action> r e e s t a b l i s h e s an environment which was p r e v i o u s l y saved by a <save-action>. <restore-action> : : = r e s t o r e :<file-narae> [ s a v i n g <file-name>] <save-action> ::= s a v e <file-name> Once an environment has been named and saved i n a f i l e , B&IDE can r e s t o r e t h a t environment using the < r e s t o r e - a c t i o n > . The s a v i n g c l a u s e of the C r e s t o r e - a c t i o n > i s a shorthand f o r s p e c i f y i n g a <save-action> immediately preceding a X r e s t o r e -action>. The syntax of <file-name> i s operating-system-dependent. Chapter I I I . The Debugging System Language 41 The <set-action> changes the va l u e of some user program or debugging v a r i a b l e . <set-action> ::= set <variable> to <expression> I f a user program or debugging <variable> i s designated, i t s value i s changed t o t h a t of the <expression>. I f the <variable> d e s i g n a t e s a < s p e c i f i c - i d > (which must have been d e c l a r e d with a < s p e c i f i c - d e c l a r a t i o n > ) , t h e v a r i a b l e i s made to r e f e r e n c e the s p e c i f i c i n d i c a t e d by the <expression>. The <sfcip-action> causes the va l u e of the d e f a u l t r e f e r e n c e p o i n t t o change by s k i p p i n g e x e c u t i o n of the remainder of some segment of code. <skip-action> ::= skip [<segment-generic>] The <skip-action> a f f o r d s the user the o p p o r t u n i t y to abort e x e c u t i o n of a segment of the c u r r e n t l y suspended program. This i s e s p e c i a l l y u s e f u l when the user d i s c o v e r s a program e r r o r , but d e s i r e s t o continue execution to d i s c o v e r other p o s s i b l e e r r o r s . For example. Skip PROCEDURE, execute. w i l l cause the user's program t o resume execution i n the procedure which c a l l e d the one i n which e x e c u t i o n was o r i g i n a l l y suspended. Any d e f e r r e d a c t i o n s a s s o c i a t e d with the segment's e x i t w i l l be i n i t i a t e d as i f the segment terminated by normal program exec u t i o n . The <system-action> a l l o w s the e x e c u t i o n of RAIDE to be t e m p o r a r i l y suspended to allow c o n t r o l t o pass t o the o p e r a t i n g Chapter I I I . The Debugging System Language 42 system. <system-action> ;:= system f<system-command>] RAIDE w i l l subsequently be reentered with the environment i t had p r i o r t o i n i t i a t i o n o f the <system-actionX I f the host o p e r a t i n g system a l l o w s such a f a c i l i t y , the <system-command>, i f present, i s the s i n g l e command executed before RAIDE i s auto-m a t i c a l l y reentered.,. The <while-action> i s another c o n t r o l s t r u c t u r e which a l l o w s r e p e t i t i v e i n i t i a t i o n o f some <action>. <while-action> ::= w h i l e <condition> do <action> U n t i l the i n d i c a t e d <condition> becomes f a l s e , the s p e c i f i e d <action> w i l l be i n i t i a t e d r e p e a t e d l y . A l l of the p r i m i t i v e a c t i o n s o f RAIDE have now been o u t l i n e d . The omission of a t r a c e p r i m i t i v e a c t i o n , present i n v i r t u a l l y a l l p r e v i o u s debugging systems, should be noted. I n D i s p e l a t r a c e p r i m i t i v e i s unnecessary: t r a c i n g can be imple-mented using the <when-clause> and the <dispIay-action>. Examples of t r a c i n g debugging procedures are given i n the next s e c t i o n . C. Examples T h i s s e c t i o n c o n t a i n s numerous examples of RAIDE debugging re g u e s t s coded i n the debugging system language D i s p e l . The examples are designed t o show the extent and power of RAIDE as w e l l as to demonstrate D i s p e l . In the examples below, i t w i l l be assumed t h a t the host source language i s b l o c k - s t r u c t u r e d and Chapter I I I . The Debugging System Language 43 c o n t a i n s the segment-generics PROCEDURE, BLOCK, and STATEMENT and the da t a - g e n e r i c s VARIABLE, PARAMETER, and CONSTANT. Furthermore, the e x i s t e n c e of t h r e e segment-generic r e l a t e d system f u n c t i o n s i s assumed. They are CURRENT_PROCEDURE, CURRENT_BLOCK, and CURRENT_STATEMENT, y i e l d i n g s p e c i f i c s i n d i c a -t i n g the procedure, block, or statement most r e c e n t l y a c t i v e when the f u n c t i o n i s invoked. L i k e the g e n e r i c s , these g e n e r i c - r e l a t e d f u n c t i o n s a re language-dependent and must be s u p p l i e d f o r each language i n t e r f a c e d t o the system. The language^independent RAIDE system f u n c t i o n s a r e d e s c r i b e d as needed below, and are l i s t e d i n Appendix A. The remainder of t h i s s e c t i o n c o n t a i n s examples i n t h i s form: a d e s c r i p t i o n o f the debugging reguest d e s i r e d , the D i s p e l code corresponding t o the reguest, and an e x p l a n a t i o n and comments concerning the code. , 1. Change the value of the v a r i a b l e *var* i n the procedure •foo' to the value of ' n*. se t var i n foo t o n. T h i s command i s given when exe c u t i o n o f the program has been suspended and RAIDE i s i n the i n t e r a c t i v e reguest mode.. I f the program has been i n t e r r u p t e d d u r i n g e x e c u t i o n of *foo' ( i . e . , the r e f e r e n c e p o i n t i s * f o o * ) , then the s e g m e n t - q u a l i f i e r " i n f o o " i s o p t i o n a l s i n c e i t w i l l d e f a u l t . 2. L i s t the names and cu r r e n t v a l u e s ( i f any) of a l l v a r i a b l e s d e c l a r e d i n the c u r r e n t l y executing procedure which have not been accessed more than ' n' times. Chapter I I I . The Debugging System Language 44 f o r e a c h VARIABLE i n CU£RENT_PROCEDURE -> war ao i f (#ACCESSES (var) < n) t h e n d i s p l a y LINE, var, " = ", VALUE(var) f i . #ACCESSES i s a system f u n c t i o n y i e l d i n g the number of times which the i n d i c a t e d d a t a - s p e c i f i c has been accessed d u r i n g t o t a l program execution. LINE i s a system f u n c t i o n causing the items f o l l o w i n g to be d i s p l a y e d s t a r t i n g on a new l i n e o f the output d i s p l a y d e v i c e . N o t i c e that d i s p l a y i n g the s p e c i f i c v a r i a b l e •var* causes the s o u r c e - l e v e l name of the v a r i a b l e i n d i c a t e d by the s p e c i f i c t o be p r i n t e d . The c u r r e n t value of some s p e c i f i c i s o b t ained by the VALUE system f u n c t i o n . , The value of an u n i n i t i a l i z e d v a r i a b l e i s d i s p l a y e d as a gu e s t i o n mark. 3 . Set a breakpoint when statement •m» i n the c u r r e n t l y e x e c u t i n g procedure has been executed 1 n * times. a f t e r STATEMENT:m i n CURRENT_PROCEDURE i f (SENTRIES (m) = n) t h e n b e g i n c a n c e l ; b r e a k "n-th execution of statement m" e n d f i . T h i s i s an example of a d e f e r r e d a c t i o n . I t s e t s a t r a p a f t e r statement *m» i n the c u r r e n t l y e x e c u t i n g procedure. #ENTRIES i s a system f u n c t i o n which y i e l d s the number of times the i n d i c a t e d s e g m e n t - s p e c i f i c has been entered during program e x e c u t i o n . The p r e f i x "STATEMENT:" i s appended t o • m* i n the f i r s t l i n e s i n c e the g e n e r i c type of ' m' may be ambiguous. I t c o u l d be a VARIABLE or PROCEDURE, and the system may be unable t o determine which •m« i s being r e f e r e n c e d . Chapter I I I . The Debugging System Language 45 4. L i s t the source f o r statements * m* t h r u *n' o f the procedure Vfoo». f o r . e a c h STATEMENT i n RANGE(foo,m,n) ~> stmt d o d i s p l a y LINE, VALUE(stmt). "STATEMENT:" i s not necessary here u n l e s s the host language numbers segments other than STATEMENTS (e.g., BLOCKS). RANGE i s a system f u n c t i o n which y i e l d s a g e n e r i c value i d e n t i f y i n g some p a r t i c u l a r subrange of another g e n e r i c v a l u e . 5. L i s t the names of a l l procedures d e c l a r e d i n the procedure •main* which have not been executed more than •n 1 times. f o r e a c h PROCEDURE i n main -> proc d o i f (#ENTRIES(proc) < n) t h e n d i s p l a y LINE, #ENTRIES (proc), TAB (10), proc f i . TAB i s a system f u n c t i o n which causes the items f o l l o w i n g t o be d i s p l a y e d a t the i n d i c a t e d column on the output d i s p l a y d e v i c e . S i n c e the s p e c i f i c ' p r o c 1 w i l l i n d i c a t e only those procedures which are d e c l a r e d i n the procedure •main*, the reguest above a p p l i e s only to the t o p - l e v e l procedures i n 'main*. 6. Extend the preceding example to produce a complete procedure e x e c u t i o n p r o f i l e and indent the output t o r e f l e c t the l o g i c a l s t r u c t u r e of the program. d e f i n e e x e c u t i o n _ p r o f i l e ( s p e c i f i c major_proc ; i n t e g e r indent) a s f o r e a c h PROCEDURE i n raajor_proc -> proc d o b e g i n d i s p l a y LINE, T A B ( i n d e n t ) , #ENTRIES(proc), TAB (indent+10), proc ; c a l l e x e c u t i o n _ p r o f i l e ( p r o c , i n d e n t + 5 ) e n d . c a l l e x e c u t i o n _ p r o f i l e ( m a i n , 0 ) . T h i s i s the f i r s t example u s i n g a debugging procedure. Notice i n p a r t i c u l a r how the procedure i s c a l l e d r e c u r s i v e l y t o handle Chapter I I I . The Debugging System Language 46 the l o g i c a l n e s t i n g of the program.•, T h i s example demonstrates the u t i l i t y of debugging v a r i a b l e s ( v i z . , »major_proc«, •indent*, and • p r o c ' ) . 7 . B r i t e a debugging procedure t o t r a c e a l l c a l l s of a p a r t i c u l a r s ubroutine w i t h i n a procedure, i n d i c a t i n g the l o c a t i o n of the c a l l , the name of the subr o u t i n e c a l l e d , and the names and values of a l l o f i t s formal parameters. d e f i n e t r a c e _ p r o c _ c a l l s ( s p e c i f i c subr) a s b e g i n s u b r _ e n t r y _ t r a c e : b e f o r e subr ENTRY I d i s p l a y , LINE, "Trace a t statement ", CUfiRENT^STATEMENT, " i n ", CURE ENT_PJBOCED ORE ; s u b r _ e n t r y _ t r a c e ; a f t e r subr ENTRY b e g i n d i s p l a y LINE, CURRENT_PROCEDURE, " entered with the f o l l o w i n g parameters;" ; f o r e a c h PARAMETER i n CURRENT_PROCEDURE -> parm d o d i s p l a y LINE, TAB(10), parm, " = ", VALUE(parm) e n d e n d . T h i s example demonstrates another procedure o f s u f f i c i e n t u t i l i t y t o merit i n c l u s i o n w i t h i n a debugging procedure l i b r a r y . The d e f i n i t i o n e s t a b l i s h e s two d e f e r r e d a c t i o n s , one which i s i n i t i a t e d i n the environment of the c a l l i n g procedure ( b e f o r e subr ENTRY) and one which i s i n i t i a t e d i n the environment of the c a l l e d s ubroutine ( a f t e r subr ENTRY)., Notice how the procedure i s capable of s e t t i n g many t r a p s , a l l of which are i d e n t i f i e d by only one l a b e l . 8 . D i s a b l e a l l of the t r a c i n g d e s c r i b e d i n the preceding example. c a n c e l s u b r _ e n t r y _ t r a c e . T h i s one c a n c e l a c t i o n removes a l l of the traps s e t by the procedure • t r a c e _ p r o c _ c a l l s ' . Chapter I I I . The Debugging System Language 47 9. Write a debugging procedure t o produce a DO-trace of a GOTO-less s u b r o u t i n e [ F o u l 75]. d e f i n e do_trace ( s p e c i f i c subr) a s f o r e a c h BLOCK i n subr -> block d o d o _ b l o c k _ t r a c e : a f t e r block ENTRY d i s p l a y " CURRENT_STATEMENT. In a GOTO-less s u b r o u t i n e , t r a c i n g each block r a t h e r than each statement produces a more compact t r a c e . No e s s e n t i a l informa-t i o n i s l o s t because, once the block i s entered, i t i s guaranteed t h a t each statement i n t h a t block w i l l be executed s i n c e a r b i t r a r y GOTOs are not permitted. , d o _ t r a c e * works by simply p r i n t i n g the number of the f i r s t statement i n each block which i s entered. 10. Extend the preceding example to t r a c e a l l b l o c k s of a l l s u b r o u t i n e s d e c l a r e d w i t h i n some user procedure. d e f i n e d o _ t r a c e _ a l l ( s p e c i f i c proc) a s f o r e a c h PROCEDURE i n proc -> subr d o b e g i n do_proc_trace: a f t e r subr ENTRY d i s p l a y .LINE, CURRENT_PROCED0RE, «:» ; c a l l do_trace(subr) e n d . S i n c e statement numbering may be done at the procedure l e v e l , i t i s necessary to i d e n t i f y the name of the procedure entered before l i s t i n g statement numbers w i t h i n that procedure. 11. Define a mechanism f o r determining d y n a m i c a l l y the n e s t i n g depth o f an a c t i v e program block [Math 75]. d e f i n e block_depth_eounter ( s p e c i f i c proc) a s f o r e a c h PROCEDURE i n proc -> subr d o b e g i n f o r e a c h BLOCK i n subr -> block d o Chapter I I I . The Debugging System Language 48 b e g i n b l o c k _ d e p t h _ l e v e l : a f t e r b l o c k ENTHY s e t b l o c k_ l e ve 1 t o b 1 ock_. 1 e ve 1 + 1 ; block_depth_ l e v e l : b e f o r e block EXIT s e t b l o c k _ l e v e l t o b l o c k _ l e v e l - 1 e n d ; c a l l block_depth_counter(subr) e n d . ! % Define and i n i t i a l i z e the g l o b a l block l e v e l counter. % i n t e g e r b l o c k _ l e v e l . s e t b l o c k ^ l e v e l t o 0. Invoking 'block_depth_counter* with the name of the user's main r o u t i n e as an argument w i l l e s t a b l i s h breakpoints a t the begin-ning and ending of each block of the user' s e n t i r e program. The purpose o f these breakpoints i s t o increment and decrement the v a r i a b l e »block_level•, Thus once •block_depth_counter' i s invoked, the value of ' b l o c k ^ l e v e l * during e x e c u t i o n i n d i c a t e s the n e s t i n g depth o f t h e CURBENT_BLOCK. B i t h t h i s mechanism i t i s p o s s i b l e to e s t a b l i s h v a r i o u s b r e a k p o i n t s based on the dynamic depth of program e x e c u t i o n ; see the f o l l o w i n g two examples. 12. Using the mechanism d e s c r i b e d i n the preceding example, produce a DO-trace of a program only when the block n e s t i n g l e v e l i s g r e a t e r than some constant 'n'. w h e n (block l e v e l > n) d i s p l a y CURRENT,BLOCK. The <when-clause> w i l l be evaluated each time the value of ' b l o c k _ l e v e l ' i s changed, which occurs both at the beginning and ending o f each b l o c k . T h e r e f o r e , t r a c i n g w i l l occur twice f o r each block, at en t r y and e x i t . Chapter I I I . The Debugging System Language 49 13. Write a debugging procedure to break on the ' n ^ t h r e c u r -s i v e c a l l o f some user procedure. define r e c u r s i o n _ b r e a k ( s p e c i f i c proc ; integer n) as begin r e c u r s i o n _ b r e a k _ l a b e i : a f t e r proc ENTRY set r e c u r s i o n _ l e v e l to r e c u r s i o n _ l e v e l + 1 ; r e c u r s i o n _ b r e a k _ l a b e l : before proc EXIT set r e c u r s i o n _ l e v e l to r e c u r s i o n _ l e v e l - 1 ; r e c u r s i o n _ b r e a k _ l a b e i : when r e c u r s i o n _ l e v e i n begin cancel r e c u r s i o n _ b r e a k _ l a b e l ; set r e c u r s i o n _ l e v e l to 0 ; break end end. % Define and i n i t i a l i z e the g l o b a l r e c u r s i o n counter. % integer r e c u r s i o n _ l e v e l . set r e c u r s i o n _ l e v e l to 0. The a c t i o n " c a l l r e c u r s i o n _ b r e a k (foo, 10.) " causes a break when •foo* i s entered r e c u r s i v e l y f o r the tenth time. 14. Write a debugging procedure to produce the .A l g o l - 9 postmor-tem dump [ S i t e 71: 125-127 ]. define postmortem as begin s p e c i f i c segment, c a l l e r ; ! display PAGE, "=> Postmortem dump of a c t i v e segments" ; set segment to C0RRENT_BLOCK ; while DEFINED(segment) do begin display LINE(2) , "=> Segment name; ", segment, LINE(2), " value of l o c a l v a r i a b l e s : " , LINE ; for each PARAMETER i n segment -> parm do c a l l p r i n t _ p a r a m e t e r _ v a l u e (parmj: ; for each VARIABLE i n segment -> var do c a l l p r i n t _ v a r i a b l e _ v a l u e (var) set c a l l e r to CALLER (segment) ; Chapter I I I . The Debugging System Language 50 i f DEFINED(caller) t h e n d i s p l a y LINE{2), segment, " was a c t i v a t e d from c a l l e r , ", near c o o r d i n a t e CORHENT_STATEHENT i n c a l l e r f i ; s e t segment t o c a l l e r e n d ; d i s p l a y LINE(2), "=> End of postmortem dump" e n d . U n l i k e the previous debugging procedures,! •postmortem* i s con-cerned p r i m a r i l y with the dynamic execution s t r u c t u r e of the program. Using the w h i l e a c t i o n and a p p r o p r i a t e system f u n c t i o n s , i t i s p o s s i b l e t o t r a c e back t h r u e x e c u t i o n o f the program. The system f u n c t i o n DEFINED y i e l d s a t r u e value i f the v a r i a b l e i n d i c a t e d by the argument has a value and y i e l d s f a l s e otherwise. CALLER i s a system f u n c t i o n which a c c e p t s a s e g m e n t - s p e c i f i c as an argument and y i e l d s a s p e c i f i c i n d i c a t i n g the segment which c a l l e d the argument s p e c i f i c . The procedure above assumes two debugging procedures •print_parameter_value* and * p r i n t _ v a r i a b l e _ v a l u e * have been d e f i n e d elsewhere. They handle the s p e c i a l formats i n which the Alqol-W t r a n s l a t o r d i s p l a y s v a r i a b l e s and parameters, based on t h e i r a t t r i b u t e s . Any debugging system must provide a mechanism f o r i n t e r r o g a t i n g t h e c u r r e n t s t a t e of not only the executing host program, but of the debugging system i t s e l f . For example, the user may wish to know the names o f a l l debugging procedures which have been d e f i n e d , what breakpoints a r e c u r r e n t l y i n e f f e c t , and what the value of the c u r r e n t r e f e r e n c e p o i n t i s . In RAIDE, these reguests are f a c i l i t a t e d by i n t r o d u c i n g system Chapter I I I . The Debugging System Language 51 f u n c t i o n s t o e x t r a c t s t a t u s i n f o r m a t i o n and by viewing D i s p e l simply as another "host*' source language. Thus, i t i s p o s s i b l e t o d i s p l a y segments of D i s p e l procedures and t o w r i t e debugging procedures which a f f e c t other debugging procedures. I n the examples to f o l l o w , i t w i l l be assumed t h a t D i s p e l c o n t a i n s the segment-generics COMMAND and ACTION and the d a t a - g e n e r i c s VARIABLE and PROCEDURE. 15. Write a debugging procedure to p r i n t the names o f a l l a c t i o n s on the d e f e r r e d a c t i o n l i s t . d e f i n e - p r i n t _ d e f e r r e d _ a c t i o n s a s b e g i n i n t e g e r counter ; s p e c i f i c , d e f e r r e d _ a c t i o n ; s e t counter t o 1 ; s e t d e f e r r e d _ a c t i o n t o DEFERRED_ACTION_LIST(counter) ; d i s p l a y LINE ; w h i l e , D E F I N E D ( d e f e r r e d _ a c t i o n ) d o b e g i n d i s p l a y d e f e r r e d _ a c t i o n , SPACE (3) ; s e t counter t o counter••• 1 ; s e t d e f e r r e d _ a c t i o n t o DEFERRED_ACTION_LIST(counter) e n d e n d . T h i s example uses the system f u n c t i o n DEFERRED_ACTION_LIST to access the l a b e l s a s s o c i a t e d with each of the c u r r e n t l y d e f e r r e d a c t i o n s . Each l a b e l i s e i t h e r the one s p e c i f i e d , or the d e f a u l t l a b e l assigned t o i t by the system. N o t i c e that DEFERRED_ACTION_LIST r e t u r n s a s e g m e h t r s p e c i f i c j u s t as i f i t was a user program v a r i a b l e . By changing the p r i n c i p a l d i s p l a y a c t i o n of »print_deferred_actions' to a c a n c e l , a debugging procedure t o ' c a n c e l _ d e f e r r e d _ a c t i o n s ' can be d e f i n e d . Chapter I I I . The Debugging System Language 52 16. Write a debugging procedure to l i s t the source o f some debugging procedure. d e f i n e print_debug_proc { s p e c i f i c proc) a s f o r e a c h ACTION i n proc -> a c t i o n d o d i s p l a y LINE, VALUE(action). I n i t i a t i n g the a c t i o n " c a l l print_debug_proc(print„debug_proc)" w i l l cause the f o r a c t i o n which c o n s t i t u t e s the body of *print_debug_proc' to be p r i n t e d . D. D i s c u s s i o n The purpose o f t h i s s e c t i o n i s t o answer two g u e s t i o n s : "How w e l l does D i s p e l f u l f i l l i t s design c r i t e r i a ? " and "What are i t s shortcomings and how can i t be improved?". The f o l l o w i n g shows how each of the design c r i t e r i a of Table VII i s f u l f i l l e d : 1. That D i s p e l i s i n t e r a c t i v e - o r i e n t e d i s supported by i t s s i m i l a r i t y to other i n t e r a c t i v e command languages. For example, each <utterance> and <action> begins with a keyword and i s terminated by the f u l l - s t o p symbol (.). The f u l l - s t o p symbol i n i t i a t e s immediate i n c r e m e n t a l execution of the utter a n c e . Altho the c o n t r o l s t r u c t u r e s (e.g., f o r and w h i l e ) give D i s p e l the f l a v o r of a b a t c h - o r i e n t e d language, these c o n s t r u c t s are used p r i m a r i l y i n debugging s u b r o u t i n e s , which the o r d i n a r y user i s u n l i k e l y to d e f i n e o n l i n e . 2. The s e t of p r i m i t i v e D i s p e l <action>s i s s m a l l . Excluding the c o n t r o l s t r u c t u r e <action>s, t h e r e a r e only t h i r t e e n p r i m i t i v e s . Furthermore, t h e r e i s a one-to-one correspondence Chapter I I I . The Debugging System Language 53 between these <action>s and the p r i m i t i v e RAIDE a c t i o n s . 3. The b a s i c concepts of RAIDE ( c f . . S e c t i o n II.B) are a s s i m i -l a t e d i n t o D i s p e l , T h i s i s evidenced by the c l o s e correspond-ence between the s y n t a c t i c e n t i t i e s of the language and the b a s i c system concepts <e.g., s p e c i f i c v a r i a b l e s , the c o n s t r u c t < s p e c i f i c > , and the RAIDE concept of a s p e c i f i c ; the <when-clause> of a command and a RAIDE event; and the r e f e r e n c e <action> and the RAIDE r e f e r e n c e p o i n t ) . 4. The syntax c h a r t o f Appendix B a t t e s t s to the u n i f o r m i t y of D i s p e l . The complete syntax i s f o r m a l l y s p e c i f i a b l e i n j u s t a few pages. Fu r t h e r , t h e r e are no "semantic" g u a l i f i c a t i o n s ; a <variable> i s a v a r i a b l e i n any context. 5. The c l a i m t h a t D i s p e l i s simple t o use i s s u b j e c t i v e . U l t i m a t e l y , t h i s c l a i m must be s u b s t a n t i a t e d by each user i n d i v i d u a l l y . 6 . The language has been designed to be , , E n g l i s h - l i k e , , i n many r e s p e c t s and, t h e r e f o r e , easy to read and understand.. Pronouncing a debugging command should be the same as e x p l a i n i n g i t . For example, the <utterance>: b e f o r e each STATEHENT i n foo d i s p l a y CURRENT_STATEMENT, has the p r o n u n c i a t i o n : "Before e x e c u t i n g each statement i n the su b r o u t i n e '^ag*, display, i t s statement number." T h i s i n i t s e l f i s an e x p l a n a t i o n of the <utterance>. Chapter I I I . The Debugging System Language 54 7. The D i s p e l syntax d i s c o u r a g e s voluminous output by r e q u i r -i n g e x p l i c i t s p e c i f i c a t i o n s and assuming d e f a u l t s which r e s u l t i n the s m a l l e s t amount of i n f o r m a t i o n . For example: f o r e a c h VARIABLE i n main -> var d o d i s p l a y var, " = VALUE(var). d i s p l a y s only the v a r i a b l e s which are d e c l a r e d l o c a l l y to •main*, not a l l v a r i a b l e s a c c e s s i b l e t o i t . f To get a d i s p l a y of a l l user v a r i a b l e s r e q u i r e s a r e c u r s i v e debugging procedure, r a t h e r than extending the d i s p l a y a c t i o n t o " d i s p l a y A L L . " . 8. E x t e n d a b i l i t y i s a f f o r d e d i n D i s p e l thru the d e f i n i t i o n of debugging procedures by the user and thru the d e f i n i t i o n s of language-dependent e n t i t i e s under the c o n t r o l o f the language i n t e r f a c e r . . The numerous examples of the preceding s e c t i o n evidence t h i s . Provided the i n t e r f a c e r i d e n t i f i e s the proper g e n e r i c s f o r a p a r t i c u l a r language and the p r i m i t i v e RAIDE a c t i o n s are mathematically " s u f f i c i e n t " . D i s p e l * s procedures provide adequate e x t e n d a b i l i t y . Altho D i s p e l i s b e l i e v e d to be a reasonably good debugging language, experience with i t s use has shown where i t can be improved. S p e c i f i c a l l y : 1. I t would be convenient t o i n c l u d e ' i n i t i a l i z a t i o n as p a r t of the d e c l a r a t i o n s of debugging v a r i a b l e s . The sequence: i n t e g e r foobar. s e t foobar t o 0. i s so common as to suggest an ext e n s i o n s u ck a s : Chapter I I I . The Debugging System Language 55 i n t e g e r foobar i n i t i a l l y 0. . The problem with doing t h i s i s ma i n t a i n i n g u n i f o r m i t y with debugging procedure parameter d e c l a r a t i o n s . The phrase: d e f i n e foo ( i n t e g e r bar i n i t i a l l y 0 ) a s i s c l e a r l y to be avoided. 2. I t would be convenient t o l a b e l a group of d e f e r r e d a c t i o n s without r e p e a t i n g the l a b e l . The seguence: <label-id>: b e f o r e ... <action> ; <lab e l - i d > : a f t e r ... <action> i s common i n debugging procedures (e.g., example 7 of the preceding s e c t i o n ) . Having t h e same l a b e l on s e v e r a l d e f e r r e d a c t i o n s makes c a n c e l i n g them e a s i e r . . An extension such a s : <labe l - i d > : ( b e f o r e ... <action> ; a f t e r ... <action>.) may be c a l l e d f o r . 3 . Debugging procedures should be allowed to r e t u r n values ( i . e . , t here should be debugging f u n c t i o n s ) . F o r example, i t i s c u r r e n t l y i m p o s s i b l e to d e f i n e a procedure s i m i l a r t o the b u i l t - i n system f u n c t i o n CALLER which r e t u r n s the * n t - t h c a l l e r of some subroutine. The s t r a i g h t f o r w a r d d e f i n i t i o n would be as f o l l o w s . d e f i n e c a l l e r n ( s p e c i f i c proc ; i n t e g e r l e v e l ) : s p e c i f i c a s i f ( l e v e l < 1) t h e n r e t u r n CALLER(proc) e l s e : r e t u r n c a l l e r n (CALLER (proc) , l e v e l - 1 ) . 4. The c u r r e n t s t r u c t u r e o f D i s p e l p l a c e s too much dependence on g l o b a l debugging v a r i a b l e s . As an example, the procedure Chapter I I I . The Debugging System Language 56 •block_depth_Gounter» of the preceding s e c t i o n r e q u i r e s the g l o b a l v a r i a b l e ' b l o c k _ l e v e l • . A l t h o i t i s g e n e r a l l y t r a n s p a r e n t to the user (who should need only t o know about •block_depth_counter*), what i f t h e user i n a d v e r t e n t l y r e d e f i n e s 'block_level» i n some other context? C l e a r l y , debugginq v a r i a b l e and procedure names need t o be p r o t e c t e d a t times. 5. Having a l l d e f e r r e d a c t i o n l a b e l s known g l o b a l l y l i k e w i s e c r e a t e s problems. For example, i t might be u s e f u l t o have two i n v o c a t i o n s of ' t r a c e _ p r o c _ c a l l s ' (example 7) t o t r a c e procedure c a l l s of the user s u b r o u t i n e s 'foo' and 'bar'. T h i s can be done, but i t i s only p o s s i b l e to c a n c e l both o r n e i t h e r s i n c e ' s u b r _ e n t r y _ t r a c e ' i s a g l o b a l d e f e r r e d a c t i o n l a b e l . C l e a r l y , such l a b e l s should be a s s o c i a t e d with the i n v o c a t i o n p f the debugqinq v a r i a b l e , not i t s d e f i n i t i o n . T h i s suggests the a d d i t i o n o f debugging v a r i a b l e l a b e l s . Then the t r a c i n g r o u t i n e c o u l d be d e f i n e d as: d e f i n e t r a c e _ p r o c _ c a l l s ( s p e c i f i c proc ; l a b e l t r a c e . l a b e l ) a s • ' * • and invoked as " c a l l t r a c e _ p r o c _ c a l l s ( f o o , f o o _ t r a c e ) "... 6. Debugging v a r i a b l e s can c u r r e n t l y be of o n l y two types: s p e c i f i c and i n t e g e r . T h i s i s e x p r e s s i v e l y l i m i t i n q ; a t l e a s t b o o l e a n and c h a r a c t e r need to be added. But r a t h e r than adding more d e c l a r a t i o n t y p e s , what may be needed i s a t y p e l e s s debuqqinq v a r i a b l e d e c l a r a t i o n . For example, a general-purpose procedure t o scan a p a r t i c u l a r user subroutine f o r the names of a l l v a r i a b l e s with a c e r t a i n value c o u l d be de f i n e d as; Chapter I I I . The Debugging System Language 5 7 d e f i n e v a r i a b l e _ s c a n ( d e c l a r e proc, value) a s f o r e a c h VARIABLE i n proc -> var d o i f (var = value) t h e n d i s p l a y var. S i m i l a r l y , a debugging procedure which "remembers" a l l s e t ? a c t i o n s c o u l d be d e f i n e d as: d e f i n e s u p e r _ s e t ( d e c l a r e t a r g e t , source) a s b e g i n s e t m a x _ s e t _ l i s t _ i n d e x t o m a x _ s e t _ l i s t _ i n d e x + 1 ; s e t s e t _ t a r g e t s l m a x _ s e t _ l i s t _ i n d e x ) t o t a r g e t ; s e t s e t _ s o u r c e s (max_set__list_index) t o source ; s e t t a r g e t t o source e n d . Then procedures to p r i n t out the values of • s e t _ t a r g e t s • and • s e t _ s o u r c e s ' c o u l d be d e f i n e d . 7 . When d i s p l a y i n g a v a r i a b l e , i t would be more n a t u r a l f o r i t s value, r a t h e r than i t s name, to be p r i n t e d by d e f a u l t . T h i s i s s i m i l a r to s e t , which assumes that the right-rhand e x p r e s s i o n y i e l d s a value. Thus, i f 'foo' i s a program v a r i a b l e with the value 10, d i s p l a y foo. would d i s p l a y "10" r a t h e r than " f o o " . The VALUE system f u n c t i o n c o u l d then be d i s c a r d e d and a system f u n c t i o n NAME co u l d be added to handle those cases when the v a r i a b l e ' s name i s d e s i r e d . . 8 . The c h o i c e of the keyword i n p u t i s unfortunate; l i b r a r y would be more a c c u r a t e and l e s s c o n f u s i n g . 9. There i s need f o r a t l e a s t one new system f u n c t i o n , OFFENDER, which r e t u r n s a segment- or d a t a - s p e c i f i c value i d e n t i f y i n g the cause of an exception.,. For example, the d e f e r r e d a c t i o n : Chapter I I I . The Debugging System Language 58 on OVERFLOW begin d i s p l a y "Overflow detected a t statement ", CUSRENT_STATEMENT, " i n ", CURRENT.PROCEDURE, LINE, " V a r i a b l e ", OFFENDER, " has the value ", VALUE (OFFENDER) , LINE ; break , end. p i n p o i n t s p r e c i s e l y the l o c a t i o n o f an overflow exception. OFFENDER i s d e f i n e d only when there i s an outstanding e x c e p t i o n a l c o n d i t i o n . 59 Chapter IV. The V i r t u a l Debugging Machine The v i r t u a l machine oh which t r a n s l a t e d programs using the RAIDE debugging system run i s c a l l e d SPAM ( S p e c i a l i z e d Prodebugging A b s t r a c t Machine). U n l i k e the other canned product s h a r i n g i t s name, SPAM'S composition i s not of concern t o the user, due to i t s i m p e r c e p t i b i l i t y . The f i r s t s e c t i o n of t h i s chapter d e s c r i b e s SPAM's design c r i t e r i a . T h i s i s f o l l o w e d by a d e s c r i p t i o n of the major components of the v i r t u a l machine, i t s i n t e r n a l o p e r a t i o n , and an o u t l i n e of i t s i n s t r u c t i o n r e per-t o i r e . The chapter i s concluded with a d i s c u s s i o n of how SPAM a i d s the debugging process and how w e l l i t meets i t s design c r i t e r i a . A. Design C r i t e r i a /* R e g r e t t a b l y , most programs are r e q u i r e d t o execute with a maximum of speed and a minimum of c a u t i o n ; i t i s s m a l l wonder, t h e r e f o r e , that we c h a r a c t e r i z e the common r e s u l t as a " c r a s h " . — John R. Ehrman, [Ehrm 72:20] */ The primary purpose of SPAM i s to provide the user's program with a machine environment t h a t i s not h o s t i l e t o the debugging process [Ehrm 72, G l a s 68, Pyl e 71, Z e l k 71 ]. Most e x i s t i n g computers have been designed with l i t t l e c o n s i d e r a t i o n f o r how the machine i t s e l f might a i d i n the debugging of programs; execution speed and e f f i c i e n c y have always been the primary design c r i t e r i a . Chapter IV. The V i r t u a l Debugging Machine 60 The design of SPAM i s i n f l u e n c e d by the B6700 f Orga 73], s e v e r a l r e c e n t v i r t u a l machines designed t o a i d i n code ge n e r a t i o n [ Boul 72, Pask 73, Sor t 72], and a previous v i r t u a l machine o r i e n t e d toward debugging [ P u l l 69 ]. A l l o f these are h i g h - l e v e l machines d i r e c t e d toward A l g o l - l i k e languages. L i k e w i s e , SPAM i s o r i e n t e d toward b l o c k - s t r u c t u r e d , p r o c e d u r a l languages of the A l g o l f a m i l y . , I t i s s t a t e d i n previous c h a p t e r s t h a t the debugging system i s not i n h e r e n t l y d i r e c t e d toward one p a r t i c u l a r c l a s s of languages. N e v e r t h e l e s s , s i n c e SPAM i s r e s t r i c t e d to A l g o l - l i k e languages and s i n c e RAIDE can be used only t o debug programs which run on SPAM, the v i r t u a l machine e f f e c t i v e l y l i m i t s the scope of the e n t i r e debugging system. T h i s may at f i r s t appear to be a severe r e s t r i c t i o n of system design c r i t e r i a 1 and 3, which s t a t e t h a t the system should be source language independent and usable on m u l t i l i n g u a l c o l l e c t i o n s of programs. Nonetheless, the c l a s s o f A l g o l - l i k e languages i s l a r g e and diverse. 1 A debugging system which i s usable on any and a l l languages w i t h i n t h i s c l a s s deserves the a t t r i b u t e "language-in dependent". U n t i l the design and implementation of a t r u l y u n i v e r s a l computer (the machine e q u i v a l e n t of the p r o v e r b i a l UNCOL), a l l software systems w i l l o f n e c e s s i t y be l e s s than t o t a l l y language-independent., I t must be remembered t h a t SPAM i s a t o o l used i n the implementation of RAIDE. As such, the e x i s t e n c e o f SPAM i s not v i t a l t o the h e a l t h and w e l l - b e i n g of the debugging system. SPAM c o u l d , i n f a c t , be r e p l a c e d by some other machine, such as Chapter IV. The V i r t u a l Debugging Machine 61 the IBM System/360/370. T h i s was not done f o r two reasons, f i r s t , the use of a v i r t u a l machine should f a c i l i t a t e p o r t a b i l -i t y of the system. To move RAIDE t o another r e a l machine, the language t r a n s l a t o r s need not be r e m o d i f i e d ; only the SPAM i n t e r p r e t e r and RAIDE need be bootstraped over to the new machine. Also, s i n c e the v i r t u a l machine i s o r i e n t e d toward debugging, the t o t a l implementation e f f o r t should be l e s s s i n c e much of the e r r o r d e t e c t i o n w i l l be done at the machine l e v e l . T h i s reduces the implementation burden of both RAIDE, which needs not perform as much e r r o r checking, and any t r a n s l a t o r s i n t e r f a c e d t o RAIDE, s i n c e they need not generate as much run-time e r r o r checking code. Nevertheless, t h e r e are two disadvantages to the v i r t u a l machine approach. F i r s t , s i n c e the code generated during a debugging run w i l l l i k e l y be d i f f e r e n t from t h a t normally gener-ated, i t i s not p o s s i b l e to use RAIDE t o t r a c k down code generat i o n e r r o r s and other language t r a n s l a t o r bugs. Also, r e w r i t i n g or modifying the code genera t i o n phase of most t r a n s -l a t o r s i s a n o n t r i v i a l undertaking. But as a t r a n s l a t o r w r i t i n g system resource, RAIDE i s o r i e n t e d more toward f u t u r e t r a n s l a t o r implementations than c u r r e n t ones. B, Machine A r c h i t e c t u r e /* spam, Spam, SPAM, SPAM, Love l y Spam, Wonderful Spam! — M o n t y Python's F l y i n g C i r c u s */ The b a s i c a r c h i t e c t u r e o f SPAM i s i l l u s t r a t e d by F i g u r e IV-1. There are e i g h t major components i n the machine: Chapter IV. The V i r t u a l Debugging Machine i r - . : , , 62 r I I — ! - : I I I I I I type t a b l e j j bounds t a b l e | I I t I I 1 C_ ; 1 f i g u r e IV-1. B a s i c A r c h i t e c t u r e of SPAM Chapter IV.. The V i r t u a l Debugging Machine 63 1. The type t a b l e c o n t a i n s i n f o r m a t i o n concerning the types of v a r i a b l e s , the arguments of procedures and f u n c t i o n s , and the values y i e l d e d by f u n c t i o n s . T h i s i n f o r m a t i o n i s necessary t o c a r r y out complete run-time type-checking of v a r i a b l e a s s i g n -ments, and procedure and f u n c t i o n i n v o c a t i o n s . The type t a b l e i s s u p p l i e d to SPAM by the language t r a n s l a t o r s . ( 2. The bounds t a b l e c o n t a i n s t h e lower and upper bounds of a l l a r r a y s , and the bounds of i n t e g e r subranges (e.g., 1..10 i n Pascal) and s c a l a r v a r i a b l e s (e.g., c o l o r = (red, white, blue) i n Sue). T h i s i n f o r m a t i o n i s necessary t o c a r r y out run-time range checking of v a r i a b l e values. The bounds t a b l e i s s u p p l i e d by the language t r a n s l a t o r s . 3. The code area c o n t a i n s only SPAM machine code, which cannot be modified d u r i n g e x e c u t i o n . The b a s i c u n i t o f machine code i s a s e l l a b l e ; an i n s t r u c t i o n c o n s i s t s of one or more s y l l a b l e s . A u n i t of executable machine code r e l a t e d together by some common purpose i s c a l l e d a segment. SPAM segments are much l i k e the segments of RAIDE (e.g., procedures, loops, and assignment statements). A l l r e f e r e n c e s t o code are made t h r u the segment c o n t r o l s t a c k and segment d e s c r i p t o r s . The code area i s s u p p l i e d by the language t r a n s l a t o r s . 4. The e n t r i e s o f the segment c o n t r o l s t a c k i d e n t i f y a code segment and r e f e r e n c e the environment a c c e s s i b l e by t h a t segment. Since the complete s t a t e of an exe c u t i n g code segment i s c o n tained w i t h i n one segment c o n t r o l s t a c k e n t r y , a new Chapter IV., The V i r t u a l Debugging Machine 64 segment i s executed by merely pushing an entry onto t h i s s tack. L i k e w i s e , segment e x i t r e s u l t s i n an entry being popped from the s t a c k . The c u r r e n t l y a c t i v e segment i s p o i n t e d t o by the segment c o n t r o l s t a c k p o i n t e r (sc.spt.r) . 5. The e n t r i e s of the scope stack, i d e n t i f y the beginning of the range of v a r i a b l e s and values a c c e s s i b l e by each code segment. The top e n t r y of t h i s stack i s pointed t o by the scope stack p o i n t e r ( s s p t r ) . 6. The dxnamic s t o r a g e s t a c k c o n t a i n s the values of a l l v a r i a b l e s and c o n s t a n t s , except f o r those which a r e t o o long to f i t c o n v e n i e n t l y w i t h i n i t . Altho i t i s c a l l e d the dynamic storage stack, i t s f i r s t p a r t c o n t a i n s i n f o r m a t i o n which i s constant during e x e c u t i o n of the user program. T h i s s t a t i c part c o n t a i n s templates f o r a l l o f the code segments and data items of the program. I t must be s u p p l i e d by the language t r a n s l a -t o r s . A l l v a r i a b l e s and c o n s t a n t s are accessed by a ( l e v e l , o r d e r ) p a i r . The l e v e l i n d i c a t e s the l e x i c l e v e l of the item being r e f e r e n c e d and corresponds to the l o g i c a l n e s t i n g of procedures and b l o c k s w i t h i n the source program. The order i n d i c a t e s which item w i t h i n the l e v e l i s d e s i r e d . The order i s an o f f s e t i n t o the dynamic s t o r a g e s t a c k ; the l e v e l i d e n t i f i e s a scope stack e n t r y which r e f e r s i n t o the dynamic storage stack., The l a s t v a l i d e n t r y of the dynamic storage s t a c k i s pointed to by the dynamic st o r a g e stack p o i n t e r ( d s s p t r ) . Chapter IV. The V i r t u a l Debugging Machine 65 7. The e x p r e s s i o n s t a c k c o n t a i n s the v a l u e s o f a l l i n t e r m e d i -ate c a l c u l a t i o n s and i s the stack on which most of the a r i t h -metic machine i n s t r u c t i o n s operate. As with the dynamic storage s t a c k , ranges of a c c e s s i b l e v a l u e s w i t h i n the e x p r e s s i o n stack are d e l i m i t e d by e n t r i e s of the scope stack. The l a s t v a l i d e n t r y of t h i s stack i s p o i n t e d t o by the e x p r e s s i o n stack p o i n t e r (esp.tr) . 8. The f r e e storage area c o n t a i n s the values of a l l s t r i n g s , a l l values which w i l l not f i t c o n v e n i e n t l y w i t h i n the dynamic st o r a g e s t a c k , and a l l v a l u e s which are a l l o c a t e d o u t s i d e the normal scope co n v e n t i o n s . Garbage c o l l e c t i o n i s necessary o n l y w i t h i n t h i s area. The b a s i c u n i t of i n f o r m a t i o n w i t h i n SPAM i s the d e s c r i p t o r . , D e s c r i p t o r s c o n t a i n not only v a l u e s , but a l s o e x t e n s i v e i n f o r m a t i o n to a i d i n run-time debugging. There are f i v e kinds of d e s c r i p t o r s : segment, data, a r r a y , segment c o n t r o l s t a c k e n t r y , and scope stack entry. Each d e s c r i p t o r i s diagrammed i n d e t a i l i n Appendix C. Segment d e s c r i p t o r s d e l i m i t any s e c t i o n of machine code which the language t r a n s l a t o r s d e s i r e t o i d e n t i f y ; they model th e s e g m e n t - s p e c i f i c s of RAIDE. Data d e s c r i p t o r s d e s c r i b e a l l program v a r i a b l e s and c o n s t a n t s . Array d e s c r i p t o r s are s i m i l a r to data d e s c r i p t o r s except t h a t they c o n t a i n an o f f s e t i n t o the bounds t a b l e , A l t h o a r r a y s can only be one-dimensional, an element of an array can i t s e l f be another array. Thus, m u l t i d i m e n s i o n a l a r r a y s are p o s s i b l e . Chapter IV, The V i r t u a l Debugging Machine 66 The formats of the e n t r i e s i n the bounds and type t a b l e s are diagrammed i n d e t a i l i n Appendix D. The bounds t a b l e format i s s t r a i g h t f o r w a r d and should r e q u i r e no e x p l a n a t i o n . The type t a b l e i d e n t i f i e s e i g h t b a s i c c l a s s e s : p r i m i t i v e ( v i z . , v o i d , i n t e g e r , r e a l , boolean, and s t r i n g ) , subrange (e.g., 1 . . 1 0 ) , s c a l a r (e. g., (apples, o r a n g e s ) ) , r e f e r e n c e ( i . e . , p o i n t e r s ) , s t r u c t u r e , procedure, arr a y , and union ( i n the A l g o l 68 sense). Given the a r c h i t e c t u r e i l l u s t r a t e d by F i g u r e IV-T and the d e s c r i p t o r and t a b l e formats contained i n Appendixes C and D, i t i s p o s s i b l e to d e s c r i b e the a c t i o n s of the v i r t u a l machine and i t s i n s t r u c t i o n s using a microprogramming language c a l l e d Spamdol (SPAM D e s c r i p t i v e Object Language). Spamdol i s modeled a f t e r the machine d e s c r i p t i o n language of [Wort 72]. The n o t a t i o n below should be c l e a r ; the only unusual f e a t u r e i s t h a t Spamdol statement b r a c k e t i n g i s accomplished using paragraphing ( i . e . , program i n d e n t i n g ) r a t h e r than more s y n t a c t i c a l l y r e f i n e d d e v i c e s such as b e g i n - e n d or d o - o d p a i r s . As an example of Spamdol, the f o l l o w i n g i s the b a s i c i n s t r u c t i o n e x e c u t i o n c y c l e of SPAM: w h i l e ( s c s p t r # n a i l ) d o : l o c a l i n s t r _ l e n g t h , i n s t r _ o f f s e t w i t h s c s [ s c s p t r ] d o i f (segtype•= procedure) a n d ( l c = e x t e r n a l ) t h e n execute_external_procedure (addr) pop_scs e l s e i f ( o f f s e t > length) t h e n pop_scs e l s e i n s t r _ o f f s e t :- cao • o f f s e t i n s t r _ l e n g t h := ' e x e c u t e _ i n s t r u c t i o n ( i n s t r _ o f f s e t ) o f f s e t +:= i n s t r _ l e n g t h N o t i c e the d e c l a r a t i o n of l o c a l Spamdol v a r i a b l e s (e.g.. Chapter IV. The V i r t u a l Debugging Machine 67 i n s t r _ l e n g t h and i n s t r _ o f f s e t ) and the use o f Spamdol procedures (e.g., e x e c u t e _ i n s t r u c t i o n ) . As an example of a Spamdol proce-dure, the f o l l o w i n g i s the r o u t i n e which pops an e n t r y from the segment c o n t r o l stack; pop_scs: •, l o c a l o l d _ s c s e o l d _ s c s e := scsf s c s p t r ] i f old_scse.dm a n d o l d _ s c s e . i n t e r r u p t . b x t h e n i n t e r r u p t " b e f o r e segment e x i t " i f ( s c s p t r # n u l l ) a n d ( o l d _ s c s e . sso * scsf s c s p t r - 1 ]. sso) t h e n pop_ss d e e r s c s p t r i f ( s c s p t r # n u l l ) a n d (old_scse.segtype # procedure) t h e n scs[ s c s p t r ] . o f f s e t +:= ol d _ s c s e . l e n g t h i f old_scse.dm a n d o l d ^ s c s e . i n t e r r u p t , ax t h e n i n t e r r u p t " a f t e r segment e x i t " The i n s t r u c t i o n s e t of SPAM i s d e s c r i b e d i n Appendix E. A l l i n s t r u c t i o n s have e i t h e r z e r o , one, or two operands. Most i n s t r u c t i o n s r e f e r e n c e e i t h e r the top of t h e segment c o n t r o l or exp r e s s i o n s t a c k . The m a j o r i t y of these i n s t r u c t i o n s are s t r a i g h t f o r w a r d . S i n c e segment c o n t r o l i n s t r u c t i o n s a r e the only ones which d i f f e r s u b s t a n t i a l l y from those of other block-s t r u c t u r e d , A l g o l - l i k e machines, an o u t l i n e of the Spamdol code d e f i n i n g each of these i n s t r u c t i o n s i s con t a i n e d i n the appendix. Since the SPAM segment i s a g e n e r a l i z a t i o n of the c o n t r o l s t r u c t u r e s of p r e v i o u s language- d i r e c t e d machines, segment c o n t r o l i n s t r u c t i o n s have n e c e s s a r i l y been g e n e r a l i z e d . Thus, f o r example, t h e r e are no IF and FOR i n s t r u c t i o n s ; these can be c o n s t r u c t e d from the i n s t r u c t i o n s provided, along with the d e f i n i t i o n s of s u i t a b l e segment types. Owing t o the author's b i a s toward s t r u c t u r e d programming, SPAM does not Chapter IV. The V i r t u a l Debugging Machine c o n t a i n a GOTO i n s t r u c t i o n . 6 8 Appendix E c o n t a i n s a complete example of a SPAM o b j e c t program, i n c l u d i n g both the machine code and the d e s c r i p t o r s needed f o r i t s execution., By f o l l o w i n g t h r u t h i s example c a r e f u l l y and r e l a t i n g i t t o the i n f o r m a t i o n c o n t a i n e d i n Appendixes C thru E, the a s t u t e reader w i l l a p p r e c i a t e the ways i n which SPAM's design f a c i l i t a t e s the debugging process. C. D i s c u s s i o n T h i s s e c t i o n d i s c u s s e s the ways i n which SPAM's design a i d s the debugging process and i d e n t i f i e s some of the shortcomings of the design. The primary way i n which SPAM's de s i g n a i d s debugging i s t h r u the use of h i g h l y typed segments and data ( i . e . , a tagged a r c h i t e c t u r e ) . Each segment of SPAM code has an a s s o c i a t e d d e s c r i p t o r which i n d i c a t e s i t s segment type (e.g., procedure or statement) and i t s parameter types as an o f f s e t i n t o the type t a b l e . T h i s i n f o r m a t i o n i s used t o type-check segment i n v o c a -t i o n s : agreement i n number and type of a c t u a l and formal parameters, and the v a l i d i t y of va l u e s y i e l d e d by segments. Each data value has an a s s o c i a t e d d e s c r i p t o r which i n d i c a t e s i t s type as an o f f s e t i n t o the type t a b l e , whether or not i t i s a r e f e r e n c e value ( i . e . , p o i n t e r ) , whether or not i t s c u r r e n t value i s d e f i n e d , and whether or not i t s value i s a cons t a n t ( i . e . , u n a l t e r a b l e ) . , T h i s i n f o r m a t i o n i s used to type-check assignments, t o i n s u r e proper a c c e s s i n g and l o n g e v i t y of Chapter IV. The V i r t u a l Debugging Machine 69 p o i n t e r s , to prevent a c c e s s i n g undefined values, and t o prevent i n a d v e r t e n t l y changing co n s t a n t values. Array d e s c r i p t o r s are l i k e data d e s c r i p t o r s except they c o n t a i n an a d d i t i o n a l bounds t a b l e o f f s e t f i e l d which i s used f o r run-time a r r a y bounds checking. Another f e a t u r e of the SPAM d e s c r i p t o r s which a i d s debug-ging i s the i n t e r r u p t i n f o r m a t i o n f i e l d . F l a g s are used to implement the segment- and d a t a - i n c i d e n t s of RAIDE ( v i z . , e n t r y , e x i t , access, and update). The d e s c r i p t o r s thus provide a convenient method f o r p l a c i n g t r a p s at d e s i r e d segment l o c a t i o n s and data values. SPAM d e t e c t s an enabled i n t e r r u p t and s i g n a l s RAIDE, which f i n d s and executes the a p p r o p r i a t e d e f e r r e d a c t i o n . Some of the d e s c r i p t o r i n f o r m a t i o n i s d e f i n e d s o l e l y t o a i d i n i d e n t i f y i n g the s t a t e of program ex e c u t i o n (e.g., determining the name of the c u r r e n t procedure). The i d e n t i f i e r f i e l d of the segment d e s c r i p t o r , and the l e v e l and order f i e l d s of the data and a r r a y d e s c r i p t o r s serve t h i s purpose. S e v e r a l of the components of SPAM's a r c h i t e c t u r e are designed s p e c i f i c a l l y to a i d i n the d e t e c t i o n of run-time e r r o r s . The type t a b l e i s used t o type-check v a r i a b l e a s s i g n -ments and procedure and f u n c t i o n i n v o c a t i o n s . The bounds t a b l e i s used f o r a r r a y bounds checking and range checking of enumerated user types. The s e p a r a t i o n of the code area from the v a r i o u s data areas prevents the u b i q u i t o u s "executing d a t a " and "manipulating code" e r r o r s which are o f t e n d i f f i c u l t to d i a g -Chapter IV. The V i r t u a l Debugging Machine 70 nose. The segment c o n t r o l , scope, and dynamic storage s t a c k s and t h e i r a s s o c i a t e d p o i n t e r s a i d i n i n t e r r o g a t i n g the s t a t e of user program e x e c u t i o n : the i n v o c a t i o n h i s t o r y i s i n d i c a t e d by the segment c o n t r o l s t a c k , and a l l a c c e s s i b l e values are i n d i -cated by the scope and dynamic storage s t a c k s . SPAM's design has s e v e r a l i n h e r e n t shortcomings, and f u r -t h e r d e f i c i e n c i e s are evident from experiences with u s i n g the machine. The known f a i l i n g s and suggestions f o r overcoming them f o l l o w : 1 . Altho i t i s p o s s i b l e to have m u l t i p l e a l l o c a t i o n s of a p a r t i c u l a r a r r a y at any one time i n SPAM, i t i s not p o s s i b l e f o r each i n s t a n t i a t i o n to have d i f f e r e n t bounds. T h i s i s due to the bounds t a b l e being f i x e d i n s i z e at t r a n s l a t i o n - t i m e . The bound values themselves can be s e t at run-time (using the SETBT i n s t r u c t i o n ) , but there i s no mechanism f o r dynamically a l l o c a t i n g a bounds t a b l e e n t r y . Simply d e f i n i n g a new storage management i n s t r u c t i o n NEWBT which a l l o c a t e s and i n i t i a l i z e s a new bounds t a b l e e n t r y , and which a u t o m a t i c a l l y s e t s the bounds t a b l e o f f s e t of the a s s o c i a t e d a r r a y d e s c r i p t o r , should a l l e v i a t e t h i s problem. 2. S i m i l a r l y , an array component of a s t r u c t u r e cannot have f l e x i b l e bounds due to the c o n s t r a i n t s of the type t a b l e format. As with the bounds t a b l e problem, t h i s may be overcome by a l l o w i n g the type t a b l e t o grow at run-time. N e v e r t h e l e s s , problems with a r r a y bounds suggest p o s s i b l y t h a t the a c t u a l Chapter IV. The V i r t u a l Debugging Machine 71 bound values should be a s s o c i a t e d with the a r r a y i t s e l f (e.g., i n i t s d e s c r i p t o r ) r a t h e r than i n a separate bounds t a b l e . A l t h o t h i s would complicate the array d e s c r i p t o r format, the e l i m i n a t i o n of the bounds t a b l e may be adeguate compensation. 3. SPAM has no p r i m i t i v e b i t s or powerset types nor s e t o p e r a t o r s . T h e i r i n c l u s i o n i s necessary to c o n v e n i e n t l y imple-ment the corresponding f e a t u r e s i n languages such as P a s c a l and A l g o l 68. But r a t h e r than adding more p r i m i t i v e types and data c l a s s e s , i t may be more b e n e f i c i a l t o provide some means of dynamically extending the type f a c i l i t i e s of SPAM. I t i s not apparent how t h i s might be done, whether i t i s p o s s i b l e or even whether i t i s d e s i r a b l e . 4. In some ways SPAM i s t o o s t r o n g l y typed. Many a p p l i c a t i o n s v a l i d l y r e g u i r e t r e a t i n g something which was once data as code and v i c e versa (e.g., t r a n s l a t e - a n d - g o t r a n s l a t o r s such as S a t f i v , and d y n a m i c a l l y e v a l u a t a b l e languages such as L i s p and S n o b o l 4 ) . T h i s suggests combining the code and f r e e storage areas and tagg i n g each s y l l a b l e as e i t h e r data or code. Then a p r i v i l e g e d i n s t r u c t i o n can be added t o SPAM which e x p l i c i t l y r e s e t s these tags. I t must a l s o be p o s s i b l e then to c r e a t e segment and data d e s c r i p t o r s dynamically, which r e q u i r e s the a d d i t i o n of s e v e r a l other i n s t r u c t i o n s . 5. At times i t would be convenient t o t e m p o r a r i l y i g n o r e Or o v e r r i d e the type of some value (e.g., while performing b i n a r y t r a n s p u t , and f o r implementing t y p e l e s s o r weakly typed Chapter IV. The V i r t u a l Debugging Machine 72 languages such as BCPL). What may be needed i s a p r i v i l e g e d i n s t r u c t i o n ( l i k e the PL/I ONSPEC f u n c t i o n ) to e x p l i c i t l y o v e r r i d e type-checking or a s p e c i a l mode of exe c u t i o n during which type-checking i s not' performed. 73 Chapter V. The Implementation / * . L e t him choose out of my f i l e s , h i s p r o j e c t s to accomplish. — W i l l i a m Shakespeare, Coriolanus•-•*/ T h i s chapter w i l l d i s c u s s i n g e n e r a l terms the UBC imple-mentation of RAIDE, i n c l u d i n g i t s scope, the i n t e r n a l design of RAIDE, how languages and t r a n s l a t o r s are i n t e r f a c e d to i t , and some r e f l e c t i o n s on the v a r i o u s t o o l s used i n the implementa-t i o n . In an attempt to keep t h i s t h e s i s down to a manageable s i z e and to promote i t s l o n g e v i t y , the n i t t y - g r i t t y d e t a i l s of the implementation have been avoided here., The i n t e r e s t e d reader i s r e f e r r e d to [John 78] f o r the minutiae. A. Scope of the Implementation The preceding c h a p t e r s d e s c r i b e RAIDE as a complete system to a i d i n the run-time a n a l y s i s and debugging of computer programs. T h i s s e c t i o n d e s c r i b e s the pragmatic scope of the a c t u a l implementation undertaken. The e x p l a i n and i n q u i r e a c t i o n s have not been implemented. A l t h o they are important p a r t s of any debugging system, they d e a l with t o p i c s not o f primary r e l e v a n c e to t h i s t h e s i s . Implementation of the e x p l a i n a c t i o n i s a f a i r l y s t r a i g h t f o r -ward, but t e d i o u s , e x e r c i s e i n i n t e r a c t i v e documentation. I t i s b a s i c a l l y the o p e r a t i n g system's r e s p o n s i b i l i t y t o provide t h i s f a c i l i t y . The i n q u i r e a c t i o n i s i n the realm of a r t i f i c i a l i n t e l l i g e n c e and techniques f o r i t s implementation are a s u b j e c t Chapter V. The Implementation 74 of c o n t i n u i n g study i n t h a t s e c t o r o f computer s c i e n c e . Of the forms of the <when-clause> of a <command>, the when <condition> form has not been implemented due to i t s r a m i f i c a -t i o n s and s i n c e i t can be simulated using the b e f o r e : and a f t e r forms, a l t h o not as simply from the user's viewpoint. L i k e w i s e , the while ;<condition> form of the execute t a c t i o n has not been implemented. A l t h o the debugging language D i s p e l c o n s t i t u t e s a conven-i e n t and c l e a n i n t e r f a c e between the user and RAIDE, i t s implementation i s not of paramount importance to t h i s t h e s i s . Thus, user communication with RAIDE has been accomplished by extending the macroprocessor TOSI t^ene 7 6 1 t h r u t h e d e f i n i t i o n of macros and TOSI "events". Altho TOSI i s a f a i r l y c o n v e n t i o n a l macroprocessing language [ Brow 74 ], the important semantic e f f e c t s of f u n c t i o n i n v o c a t i o n s are not output s t r i n g s , but r a t h e r the a c t i v a t i o n o f "events". Each of the p r i m i t i v e RAIDE a c t i o n s i s a s s o c i a t e d with a TOSI event which implements t h a t a c t i o n . S ince i t i s p o s s i b l e using the TRUST t r a n s l a t o r w r i t i n g system [Vene 76] to t r a n s l a t e D i s p e l programs i n t o TOSI s t r i n g s , the c u r r e n t i n t e r f a c e can be considered a " l o w - l e v e l " implementation of the debugging language. To demonstrate the debugging system, i t i s necessary to modify or w r i t e at l e a s t one language t r a n s l a t o r to produce the r e g u i r e d SPAH code and RAIDE s p e c i f i c a t i o n s . Since w r i t i n g a t r a n s l a t o r or even changing the code generation phase of an Chapter V. The Implementation 75 e x i s t i n g one i s g e n e r a l l y a n o n t r i v i a l task, and s i n c e the t r a n s l a t o r i s necessary only to demonstrate RAIDE and i s not c e n t r a l to the implementation i t s e l f , i t i s d e s i r a b l e to choose a language which i s simple enough t h a t a reasonable t r a n s l a t o r can be provided, yet which i s complete enough t o be r e p r e s e n t a -t i v e o f e x i s t i n g " r e a l " languages. The language chosen which s u i t s these c r i t e r i a i s Asple [Marc 76]. Asple i s a bl o c k -s t r u c t u r e d , A l g o l - l i k e language c o n t a i n i n g i n t e g e r , boolean, and r e f e r e n c e v a r i a b l e s ; the c o n t r o l s t r u c t u r e s : assignment, i f - t h e n , i f - t h e n - e l s e , i n p u t , output, and while; and simple a r i t h m e t i c e x p r e s s i o n s . The p r i n c i p a l f e a t u r e s missing from Asple are procedure d e c l a r a t i o n s and i n v o c a t i o n s , and parameter passing. Since i t was f e l t these are necessary f o r a t r u l y r e p r e s e n t a t i v e language, a d i a l e c t of A s p l e c o n t a i n i n g proce-dures ( c a l l e d Aspro) was d e f i n e d . P r o v i d i n g a t r a n s l a t o r from Aspro to SPAM might e a s i l y have become a s u b s t a n t i a l p r o j e c t unto i t s e l f . F o r t u n a t e l y , a t r a n s l a t o r f o r Asple was a l r e a d y a v a i l a b l e [ Appe 78], I t t r a n s l a t e d Asple source programs i n t o an i n t e r m e d i a t e g r a p h i c r e p r e s e n t a t i o n ( c a l l e d GRAIL) which was then toured by a code generator t o produce IBM System/36 0/370 machine code., Thus, producing the r e q u i r e d Aspro t r a n s l a t o r i n v o l v e d extending the Asple t o GRAIL t r a n s l a t o r i n t o an Aspro to GRAIL t r a n s l a t o r , and modifying the graph t o u r e r t o produce SPAM code and the appro-p r i a t e RAIDE s p e c i f i c a t i o n s . Chapter V. The Implementation 76 To v e r i f y design c r i t e r i o n 1 ( v i z . , source language independence), i t i s necessary t o i n t e r f a c e more than one language t o RAIDE., The second language chosen was BCPL [ R i c h 69], The r e a d i l y a v a i l a b l e implementation of BCPL i s a l o c a l l y adapted v e r s i o n of the standard p o r t a b l e t r a n s l a t o r c a l l e d BCPL-V ( R i c h 77]. The o r i g i n a l t r a n s l a t o r produces a parse t r e e which i s toured by semantic r o u t i n e s t o output a symbolic assembler program f o r a mythical machine c a l l e d MINICODE. Code genera t i o n r o u t i n e s then t r a n s l a t e t h i s i n t e r m e d i a t e r e p r e s e n t a t i o n i n t o the machine code of the host computer. BCPL-V was modified t o i n t e r f a c e with RAIDE by w r i t i n g semantic r o u t i n e s which generate SPAM code and RAIDE s p e c i f i c a t i o n s d i r e c t l y from the parse t r e e . A l t h o not a l l c o n s t r u c t s of the o r i g i n a l language are implemented i n the modified t r a n s l a t o r , most of those which have not been are ex t e n s i o n s to the standard language anyway. B. I n t e r n a l Design of RAIDE The b a s i c i n f o r m a t i o n s t r u c t u r e o f RAIDE i s i l l u s t r a t e d by Fi g u r e V-1. I t has e i g h t major components: 1. The ty_P_e name t a b l e p a r a l l e l s SPAM*s type t a b l e , t h a t i s , an o f f s e t i n t o the type t a b l e a l s o indexes the type name t a b l e . , The value of a type name t a b l e e ntry i s an o f f s e t i n t o the s t r i n g index t a b l e . , Thus, g i v e n a type t a b l e o f f s e t , the name of that type as a c h a r a c t e r s t r i n g i s obtained by r e f e r e n c i n g i n d i r e c t l y t h r u the type name and s t r i n g index tables.„ r Chapter V. The Implementation 7 7 bounds name t a b l e r - > I i bounds name mapping t a b l e type name t a b l e s t r i n g index t a b l e I I I I I I T I I | s t r i n g t a b l e J I I ->l i \ symbol t a b l e 1 I 1 I . : ; . I 1 I H 1 «~->l debugging value stack F i g u r e V - 1 . B a s i c Information S t r u c t u r e of BAIDE Chapter V. The Implementation 78 2. The bounds name t a b l e p a r a l l e l s SPAM*s bounds t a b l e . U n l i k e the type name t a b l e , i t s values do not r e f e r e n c e the names of bounds, b u t r a t h e r the names of the valu e s o f bounds. For example, the s c a l a r (reel, white, blue) may be, store d i n t e r n a l l y as a subrange of i n t e g e r type (e.g., 0, 1, and 2). Ne v e r t h e l e s s , f o r p r i n t i n g purposes, the name of some bounds value must be output r a t h e r than i t s i n t e r n a l v alue (e.g., »red' r a t h e r than 0). 3. Since the mapping o f bounds t a b l e o f f s e t s and bounds names i s not one-to-one, the bounds nafe H B E i n f t a b l e i s needed to e f f e c t the proper mapping. For example, the s c a l a r (red, white, blue) occupies one en t r y i n both the bounds and the bounds name t a b l e s . ; But s i n c e t h r e e d i f f e r e n t names must be a c c e s s i b l e , the value of the bounds name t a b l e e n t r y i s an o f f s e t i n t o the f i r s t of t hree bounds name mapping t a b l e e n t r i e s which are used l i k e the type name t a b l e e n t r i e s t o r e f e r e n c e i n d i r e c t l y t h r u the s t r i n g index t a b l e . I f s c a l a r types a re not supported by the implementation, both the bounds name and bounds name mapping t a b l e s are s u p e r f l u o u s . 4. The e n t r i e s of the s t r i n g index t a b l e i d e n t i f y the s t r i n g s r e p r e s e n t i n g i d e n t i f i e r s and the s o u r c e - l e v e l code a s s o c i a t e d with each program segment. A l l i d e n t i f i e r s (e.g., type names, v a r i a b l e names, and the names of generics) are r e f e r e n c e d t h r u the s t r i n g index t a b l e . An entry c o n t a i n s two f i e l d s : the l e n g t h o f the s t r i n g and an o f f s e t i n t o the s t r i n g area t o the s t a r t of the c h a r a c t e r s t r i n g . Chapter V. The Implementation 79 5. The s t r i n g , area i s an a r r a y of c h a r a c t e r s c o n t a i n i n g the s t r i n g s r e p r e s e n t i n g a l l i d e n t i f i e r s as w e l l as the user source program code. 6 . The s_mbgl t a b l e c o n t a i n s e n t r i e s f o r a l l e n t i t i e s which are a c c e s s i b l e . b y RAIDE, i n c l u d i n g a l l user program data- and s e g m e n t - s p e c i f i c s , g e n e r i c s , events and d e f e r r e d a c t i o n s , system f u n c t i o n s , and debugging v a r i a b l e s and procedures. The formats of the e n t r i e s of the symbol t a b l e are diagrammed i n d e t a i l i n Appendix G. The l i n k a g e of symbol t a b l e e n t r i e s i s complex, owing t o the number of ways i n which the t a b l e must be accessed. Examples o f RAIDE symbol t a b l e e n t r i e s are t h e r e f o r e presented i n Appendix H. 7 . The debu^ginci value stack c o n t a i n s the val u e s o f a l l debugging v a r i a b l e s d u r i n g execution. An e n t r y o f t h i s s t a c k c o n t a i n s two f i e l d s : a v a l u e - d e f i n e d f l a g and the value i t s e l f . For an i n t e g e r v a r i a b l e , the stack c o n t a i n s i t s a c t u a l i n t e g r a l v a l u e ; f o r a s p e c i f i c v a r i a b l e , the s t a c k c o n t a i n s an o f f s e t i n t o the symbol t a b l e f o r the user program e n t i t y a s s o c i a t e d with the v a r i a b l e , 8. To access symbol t a b l e e n t r i e s by name, i t i s necessary to hash i d e n t i f i e r s t h r u the i d e n t i f i e r hash-•.____§.«. Since one i d e n t i f i e r can represent s e v e r a l d i f f e r e n t e n t i t i e s i n RAIDE (e.g., f f o o * may be a user program v a r i a b l e i n two d i f f e r e n t scopes and • l i n e * may be a user v a r i a b l e as w e l l as a system f u n c t i o n ) , the value of an i d e n t i f i e r hash t a b l e e n t r y i d e n t i -Chapter V, The Implementation 80 f i e s the f i r s t of a s e r i e s of Mhomonymic" symbol t a b l e e n t r i e s . A hoffiSHU £k§in i s then used t o determine the a p p r o p r i a t e e n t r y . Appendix I c o n t a i n s a complete example of a RAIDE program s p e c i f i c a t i o n , i n c l u d i n g both the data- and s e g m e n t - s p e c i f i c s o f the user source program. The next two s e c t i o n s below d i s c u s s how the i n f o r m a t i o n s u p p l i e d by a language i n t e r f a c e r and a t r a n s l a t o r are i n t e g r a t e d i n t o RAIDE*s t a b l e s . ; C. I n t e r f a c i n g a Language Table I I I summarizes the i n f o r m a t i o n which a language i n t e r f a c e r must supply f o r each language i n t e r f a c e d t o RAIDS. T h i s s e c t i o n w i l l d e s c r i b e i n g r e a t e r d e t a i l how the i n t e r f a c e i s accomplished. The f i r s t requirement of the language i n t e r f a c e r i s t o i d e n t i f y i t s e l f to RAIDE by s u p p l y i n g a p a i r of the form ( l c , i d ) , where * l c * i s the language code of the language named • i d ' . . ' I c ' i s used i n SPAM d e s c r i p t o r s {cf. , F i g u r e C-1) and i n BAIDE symbol t a b l e e n t r i e s ( c f . , F i g u r e G-5) to i d e n t i f y the source language i n which a p a r t i c u l a r program segment was w r i t t e n . RAIDE maintains a t a b l e of a l l language name p a i r s i n t e r n a l l y . For a p a r t i c u l a r host language, the segment- and data-g e n e r i c s are d e f i n e d as a s e r i e s of t r i p l e s of the form (gentype,code,id), where 'gentype' i s a f l a g i n d i c a t i n g whether the g e n e r i c name * i d ' i s a segment- or d a t a - g e n e r i c , and 'code' Chapter V. The Implementation 81 i s the type code a s s o c i a t e d with the g e n e r i c . For example, the t r i p l e s f o r a b l o c k - s t r u c t u r e d language might be: The d e f i n i t i o n of these t r i p l e s r e s u l t s i n the c o n s t r u c t i o n of g e n e r i c symbol t a b l e e n t r i e s ( c f . , F i g u r e G-3). •code' i s the segment- or d a t a - g e n e r i c type code used i n SPAM d e s c r i p t o r s (e.g., the 'segtype* f i e l d of F i g u r e C-1) and i n RAIDE symbol t a b l e e n t r i e s (e.g., the 'datatype* f i e l d of F i g u r e G-1). The language-oriented run-time e r r o r messages are s u p p l i e d to RAIDE as an indexed f i l e , where the indexes correspond to e r r o r numbers. SPAM and RAIDE d i c t a t e the o r d e r i n g of e r r o r numbers; the language i n t e r f a c e r must a s s o c i a t e a message with each e r r o r number. For example, when SPAM d e t e c t s an array s u b s c r i p t range e r r o r , i t r e p o r t s t h i s to RAIDE using a p a r t i c u l a r e r r o r number. RAIDE uses t h i s number t o l o c a t e the a p p r o p r i a t e e r r o r message f o r the language i n which the o f f e n d -i n g program was w r i t t e n . The i d e n t i f i c a t i o n of language-dependent e x c e p t i o n s i s accomplished as a s e r i e s o f p a i r s of the form ( c o d e , i d ) , where •code 1 i s the e x c e p t i o n number a s s o c i a t e d with the ex c e p t i o n named ' i d ' , . For example, (10,FAILURE) might be d e f i n e d f o r some language having statement f a i l u r e . 'code* i s the ex c e p t i o n number used i n the SPAM SIGNAL i n s t r u c t i o n ( c f . , Appendix E). For each language-dependent exception i d e n t i f i e d by the language i n t e r f a c e r , an event symbol t a b l e e n t r y {cf.. Figure G-H) i s (segment,1,PROCEDURE) (segment,2,BLOCK) (segment,3,STATEMENT) (da ta,1,VARIABLE) (data,2,CONSTANT) {data,3,PARAMETER) C h a p t e r V. The I m p l e m e n t a t i o n c r e a t e d . 82 G e n e r i c - r e l a t e d and l a n g u a g e - d e p e n d e n t s y s t e m f u n c t i o n s a r e s u p p l i e d a s a s e r i e s o f p a i r s o f t h e f o r m ( i d , r o u t i n e - n u m b e r ) , where » i d » i s t h e f u n c t i o n ' s name and • r o u t i n e - n u m b e r 1 i s a number wh i ch a s s o c i a t e s t h e f u n c t i o n w i t h an i n t e r n a l l i s t o f r o u t i n e s . F o r e a c h f u n c t i o n d e f i n e d by t h e l a n g u a g e i n t e r f a c e r , a s y s t e m f u n c t i o n s y m b o l t a b l e e n t r y ( c f . , F i g u r e G-5) i s c r e a t e d . D. I n t e r f a c i n g a T r a n s l a t o r T a b l e s IV and V s u m m a r i z e t h e i n f o r m a t i o n w h i c h a t r a n s l a t o r must s u p p l y f o r a s o u r c e p r o g r a m t o i n t e r f a c e t o RA IDE . T h i s s e c t i o n w i l l d e s c r i b e i n g r e a t e r d e t a i l how t h e i n t e r f a c e i s a c c o m p l i s h e d . An i n t e r f a c e d t r a n s l a t o r ' s most b a s i c r e q u i r e m e n t i s t o g e n e r a t e a SPAM c o d e v e r s i o n o f a u s e r s o u r c e p r o g r a m . As e x e m p l i f i e d by F i g u r e F - 2 , t h i s c o n s i s t s o f a s e q u e n c e o f o p e r a t i o n and o p e r a n d c o d e s , where e a c h c o d e o c c u p i e s one s y l l a b l e i n S PAM ' s c o d e a r e a . As p a r t o f t h e SPAH c o d e , t h e d e s c r i p t o r s a s s o c i a t e d w i t h a l l s egmen t- a n d d a t a - s p e c i f i c s r e f e r e n c e d i n t h e o b j e c t p r o g r a m must a l s o be s u p p l i e d . ; T h e s e d e s c r i p t o r s c o n s t i t u t e t h e i n i t i a l d y n a m i c s t o r a g e s t a c k . The o t h e r e s s e n t i a l i n f o r m a t i o n w h i c h a t r a n s l a t o r must a l w a y s p r o v i d e i s t h e i n i t i a l s t a t e o f t h e bounds and t y p e t a b l e s . A p p e n d i x D d i a g r a m s t h e r e q u i r e d f o r m a t s o f t h e s e t a b l e s . A t r a n s l a t o r must s u p p l y q u i n t u p l e s o f t h e f o r m ( t t o , d , c , l b , u b ) t o Chapter V. The Implementation 83 i d e f i n e the bounds t a b l e and must supply; t r i p l e s of the form ( c l a s s , a r g 1 , a r g 2 ) , where 'arg1» and *arg2* are dependent on the value of • c l a s s ' , to d e f i n e the type t a b l e . I f a t r a n s l a t o r only s u p p l i e s SPAM code, SPAM d e s c r i p t o r s , and the bounds and type t a b l e s , then RAIDE executes at the b a s i c machine l e v e l of debugging support. . To execute a t the simple symbolic l e v e l of support, a t r a n s l a t o r must supply enough t r a n s l a t i o n - t i m e symbol t a b l e i n f o r m a t i o n to enable RAIDE t o c o n s t r u c t a s k e l e t a l run-time symbol t a b l e f o r the purposes of r e p o r t i n g e r r o r s s y m b o l i c a l l y and e x e c u t i n g simple i n t e r a c t i v e commands. S p e c i f i c a l l y , p a i r s of the form (dsso,id) must be s u p p l i e d f o r a l l user data-s p e c i f i c s (e.g., v a r i a b l e s and symbolic c o n s t a n t s ) , where *dsso* i s the SPAM dynamic s t o r a g e stack o f f s e t to the template d e s c r i p t o r a s s o c i a t e d with the s p e c i f i c named • i d * . These p a i r s are used t o c o n s t r u c t d a t a - s p e c i f i c symbol t a b l e e n t r i e s ( c f . , F i g u r e G-1). A d d i t i o n a l l y , a t r a n s l a t o r must supply p a i r s of the form ( t t o , t y p e - i d ) , (bto/bnmto) , and (bnmto,bounds-id) to f a c i l i t a t e c o n s t r u c t i o n o f the type name t a b l e , the bounds name t a b l e , and the bounds name mapping t a b l e , r e s p e c t i v e l y . Since at the simple symbolic l e v e l o f debugging o n l y - i d e n t i f i e r s are s u p p l i e d , RAIDE can only r e p o r t e r r o r s s y m b o l i c a l l y and perform i n t e r a c t i v e r e g u e s t s which are dependent s o l e l y on i d e n t i f i e r names (e.g., " d i s p l a y x.", but not " d i s p l a y x i n f o o . " ) . I f a t r a n s l a t o r p r o v i d e s s u f f i c i e n t i n f o r m a t i o n to allow c o n s t r u c t i o n of complete d a t a - s p e c i f i c symbol t a b l e e n t r i e s Chapter V. The Implementation 84 ( v i z . , the ' l e v e l 1 , 'order*, 'datatype', and ' l i n k * f i e l d s of F i g u r e G-1), then RAIDE can operate at the symbolic debugging l e v e l . An example of a such a d e s c r i p t i o n i s presented by F i g u r e 1-1, I t i s then p o s s i b l e to respond to requests such as "set x i n foo to 10." and "display each VARIABLE,". Since no i n f o r m a t i o n i s yet a v a i l a b l e concerning the s t a t i c s t r u c t u r e of a user program, reguests such as "for each STATEHENT i n foo ...." cannot be honored. Se g m e n t - s p e c i f i c s are represented t o RAIDE as quadruples of the form ( i d , s e g t y p e , d s s o , l i n k ) , * as diagrammed i n F i g u r e G - 2 . They r e s u l t i n the c o n s t r u c t i o n of s e g m e n t - s p e c i f i c symbol t a b l e e n t r i e s , which are RAIDE'S way of s t o r i n g the d e s c r i p t i o n of the s t a t i c s t r u c t u r e of a user source program. T h i s corresponds to the f u l l debugging l e v e l of support. An example o f such a d e s c r i p t i o n i s presented by F i g u r e 1 - 2 . With such i n f o r m a t i o n i t i s p o s s i b l e t o respond t o i n t e r a c t i v e r e g u e s t s i n v o l v i n g the s t a t i c program s t r u c t u r e , such as the v a r i o u s t r a c e r o u t i n e s of S e c t i o n I I I . C . I f a t r a n s l a t o r a d d i t i o n a l l y s u p p l i e s RAIDE with the source program code ( v i z . , the 'phrases' f i e l d of Figure G - 2 ), then the deluxe debugging l e v e l of support i s entered. E. R e f l e c t i o n s on the Implementation T o o l s The f i r s t component of the system to be implemented was a s i m u l a t o r f o r SPAM. PL/I flBM 70] was i n i t i a l l y chosen as the implementation language, but was abandoned a f t e r a few weeks f o r the f o l l o w i n g reasons: Chapter V. The Implementation 85 1. In PL/I the d e f i n i t i o n of s t r u c t u r e d types and the d e c l a r a t i o n of v a r i a b l e s are combined. Thus, t o d e c l a r e two a r r a y s c o n t a i n i n g the same s t r u c t u r e s (e.g., the dynamic storage s t a c k and the e x p r e s s i o n s t a c k ) , e i t h e r the s t r u c t u r e elements must be w r i t t e n out twice or the LIKE d e c l a r a t i o n a t t r i b u t e must be used. The former i s c l e a r l y u n d e s i r a b l e s i n c e i t i s e r r o r -prone and makes program m o d i f i c a t i o n more d i f f i c u l t . The numer-ous r e s t r i c t i o n s on the use of LIKE [IBM 70:345 -346 ] make i t u n d e s i r a b l e as w e l l . Type d e f i n i t i o n s , i n the P a s c a l sense, can be s i m u l a t e d with a CONTROLLED " v a r i a b l e " d e c l a r a t i o n , but t h i s technique a l s o s u f f e r s from seemingly unnecessary r e s t r i c t i o n s b e s i d e s being an example of t r i c k y programming ( i . e . , say one t h i n g , but mean a n o t h e r ) . 2. S t r u c t u r e d e c l a r a t i o n s i n PL/I cannot c o n t a i n v a r i a n t p a r t s , i n the P a s c a l sense. The SPAM d e s c r i p t o r formats make c o n s i d e r a b l e use of t h i s f e a t u r e ( c f . , F i g u r e C-2). The DEFINED d e c l a r a t i o n a t t r i b u t e can be used to s i m u l a t e v a r i a n t s , but t h i s r e g u i r e s a l l o c a t i n g a l l space t o accommodate the l a r g e s t v a r i a t i o n and r e g u i r e s the programmmer to i n s u r e proper storage alignment of values. T h i s , too, i s both t r i c k y and e r r o r - p r o n e . 3. There i s no mechanism i n PL/I f o r d e c l a r i n g a r r a y s of heteroqeneous element types. T h i s i s needed, f o r example, with the dynamic st o r a g e stack, which i s composed of segment, data, and a r r a y d e s c r i p t o r s . As with v a r i a n t p a r t s , an a r r a y o f union type can be s i mulated with the DEFINED d e c l a r a t i o n a t t r i b u t e . T h i s o v e r l a y i n g r e s u l t e d i n numerous i n e x p l i c a b l e e r r o r s under Chapter V. The Implementation 86 the t r a n s l a t o r used [ M i l l 76a], which was the primary motivation f o r the abandonment of PL/I as the systems implementation language. 4. The implementation o f a machine s i m u l a t o r i n h e r e n t l y i n v o l v e s the use of case statement c o n s t r u c t s . Altho an indexed case statement can o f t e n be sim u l a t e d not too opaguely i n PL/I u s i n g a LABEL a r r a y and a GOTO, the need f o r an e l s e c l a u s e f o r c e s the use of strung out i f - t h e n - e l s e statements i n s t e a d . The l a t t e r c l e a r l y obscures the fundamental s t r u c t u r e o f the machine si m u l a t o r . 5. PL/I c o n t a i n s no p r o v i s i o n f o r "named" ( i . e. , manifest) constants. T h e i r use i n c r e a s e s the m o d i f i a b i l i t y of the system tremendously. Named constants can be i n t r o d u c e d u s i n g a pre p r o c e s s o r or can be simulated t h r u the d e c l a r a t i o n of STATIC INITIAL " v a r i a b l e s " . The l o c a l l y a v a i l a b l e PL/I preprocessor i s n o t o r i o u s f o r i t s expense and e s p e c i a l l y f o r i t s tendency to u n p r e t t y p r i n t ( u g l y p r i n t ? ) programs. Using c o n s t a n t s d i s g u i s e d as v a r i a b l e s can i n t r o d u c e needless run-time overhead, b e s i d e s being t r i c k y programming. A l l of the above c r i t i c i s m s of PL/I point t o the need f o r a language which handles types more e l e g a n t l y . Thus, PL/I was di s c a r d e d i n f a v o r of P a s c a l [Jens 74]. Both the machine s i m u l a t o r and B AIDE were implemented u s i n g the; l o c a l l y a v a i l a b l e P a s c a l t r a n s l a t o r [ P o l l 77], which accepts a somewhat d e v i a n t d i a l e c t of standard P a s c a l . A l t h o an attempt was made t o adhere Chapter V. The Implementation 87 to the standard language to f a c i l i t a t e p o r t a b i l i t y , the i n s i d i -ous l u r e of the b e l l and the w h i s t l e became overpowering. /* Temptation i s an i r r e s i s t i b l e f o r c e at work on a movable body, — Henry L o u i s Mencken */ O v e r a l l , P a s c a l proved to be a u s e f u l systems implementa-t i o n language. Nevertheless, i t s u f f e r s from numerous minor d e f e c t s and omissions which were a c o n t i n u a l source of f r u s t r a -t i o n . The d e f i c i e n c i e s o f P a s c a l have been w e l l documented i n the l i t e r a t u r e [Conr 76, Habe 73, Knob 75, Leca 75]. The f i r s t r e f e r e n c e r e l a t e s best the problems with u s i n g P a s c a l as a systems implementation language. Most of the problems d e s c r i b e d i n {Conr 76] were v e r i f i e d by the experiences of implementing BAIDE. Some of these shared experiences are presented here: 1. P a s c a l has been c r i t i c i z e d most s e v e r e l y f o r i t s l a c k of dynamic a r r a y a l l o c a t i o n and the d i f f i c u l t i e s a r i s i n g from i n c l u d i n g a r r a y dimensions d i r e c t l y i n t o t h e : a r r a y type d e f i n i t i o n [Conr 76: sec, 3. 2], SPAM'S t a b l e s and s e v e r a l of i t s s t a c k s would best be a l l o c a t e d e a r l y during e x e c u t i o n . Since t h i s simply was not p o s s i b l e , l a r g e chunks of memory were t i e d up n e e d l e s s l y to avoid r e t r a n s l a t i n g a l l s u b r o u t i n e s f r e g u e n t l y . 2. S y n t a c t i c a l l y , a P a s c a l c o n s t a n t cannot be a t r a n s l a t i o n -time e x p r e s s i o n [Conr 76:sec. 3. 3.1 ], In s e v e r a l i n s t a n c e s i t was found t h a t one c o n s t a n t ' s value was a f u n c t i o n of one or more others (e.g., length = max_index - min_index • 1). E i t h e r a v a r i a b l e had to be used or the constant d e f i n e d with a l i t e r a l Chapter V. The Implementation 88 value along with a comment e x p l a i n i n g the o r i g i n of the value. N e i t h e r s o l u t i o n i s s a t i s f a c t o r y . 3. Pascal l a c k s a u t h e n t i c b l o c k - s t r u c t u r e (Conr 76:sec, 4.3], a l l v a r i a b l e s must be d e c l a r e d a t the procedure l e v e l , not at the l e v e l to which they are most a p p r o p r i a t e l y l o c a l . Altho a minor annoyance, Sue's [ c l a r 74] s e p a r a t i o n of i d e n t i f i c a t i o n and s t o r a g e a l l o c a t i o n i s more d e s i r a b l e . 4. The a d d i t i o n of A l g o l 60 own (or PL/I STATIC) v a r i a b l e s would, i n some i n s t a n c e s , reduce parameter passing and b e t t e r f a c i l i t a t e i n f o r m a t i o n h i d i n g [Conr 76:sec. 3.7.1], Again, a s e p a r a t i o n of i d e n t i f i c a t i o n and storage l i f e t i m e i s d e s i r a b l e . 5. Procedure v a r i a b l e s (Conr 76:sec. 3.7.1] were needed i n the implementation of RAIDE s i n c e , f o r example, g e n e r i c - r e l a t e d f u n c t i o n s (e.g., C0RRENT_PROCED0RE) need not be s p e c i f i e d u n t i l run-time. T h i s had to be s i m u l a t e d using operating-system-dependent r o u t i n e s , thus re d u c i n g f u r t h e r the p o r t a b i l i t y of the implementation. 6. Programs would be more c o n c i s e and c l e a r e r i f values c o u l d be assigned to the f i e l d s o f a r e c o r d v a r i a b l e in;one statement, as i n Algol-W and A l g o l 68 [Conr 76:sec. 4. 2]. The next few c r i t i c i s m s are aimed s p e c i f i c a l l y a t standard P a s c a l s i n c e PASCAL/OBC has been extended to d e a l with them. 7. In P a s c a l a f u n c t i o n cannot y i e l d a value of r e c o r d type or an a r r a y [Conr 76:sec. 2.1], T h i s seemingly nonuniform Chapter V. The Implementation 89 r e s t r i c t i o n i n c r e a s e s the use of var parameters. 8. The case statement of standard P a s c a l does not c o n t a i n an e l s e c l a u s e [Conr 76:sec. 2.4], T h i s o f t e n l e a d s t o s t r u n g out i f _ t h e n _ e l s e statements, with a r e s u l t i n g l o s s o f c l a r i t y . An e l s e c l a u s e i n the case statement i s e s s e n t i a l f o r software which purports t o be f a i l - s a f e , as i s expected of a debugging system. 9. Nesting of i f - t h e n statements c o u l d be reduced i f boolean e x p r e s s i o n s are eva l u a t e d i n the McCarthy manner [Conr 76:sec. 2 . 3 J . 10. P r o v i s i o n should be made f o r i n i t i a l i z i n g a l l values s t a t i c a l l y , i n c l u d i n g a r r a y s [Conr 76: sec. 4.2]. A p p l i c a t i o n s u s i n g d e c i s i o n t a b l e s , which are o f t e n the clearest,means of s t r u c t u r i n g an a l g o r i t h m , r e q u i r e "constant", a r r a y s . 11. Separate c o m p i l a t i o n of procedures i s e s s e n t i a l f o r the implementation of a l a r g e software system such as BAIDE [Conr 76:sec, 3 .7. 1 ]. The expense of r e t r a n s l a t i o n becomes i n t o l e r a b l e otherwise. Even F o r t r a n i s more s o p h i s t i c a t e d than P a s c a l i n t h i s regard. , The f o l l o w i n g c r i t i c i s m s a r e presented i n more depth s i n c e they poi n t t o problems which have not been d e a l t with adequately i n the l i t e r a t u r e . 12. Assuming t h a t s e p a r a t e procedure c o m p i l a t i o n i s a v a i l a b l e , a r e l a t e d e x t e n s i o n which i s needed i s g l o b a l v a r i a b l e s ( i . e . . Chapter V. The Implementation 90 EXTERNAL i n the PL/I sense). A l t h o the e x t e n s i v e use of g l o b a l v a r i a b l e s i s c u r r e n t l y being c o n t e s t e d among language d e s i g n e r s [Wulf 73], t h e i r r e s t r a i n e d use does reduce the need f o r parameter passing and can a i d i n f o r m a t i o n h i d i n g . / A l t h o PASCAL/OBC has been extended t o provide g l o b a l v a r i a b l e s , t h e i r implementation i s p r i m i t i v e . To make even a minor change, i n the d e f i n i t i o n of one g l o b a l v a r i a b l e may r e g u i r e r e t r a n s l a t i c n of a l l procedures, even those which c o n t a i n no r e f e r e n c e s t o the modified v a r i a b l e . 13. S t r i n g h a n d l i n g i s very poor i n P a s c a l , p r i m a r i l y s i n c e s t r i n g s are t r e a t e d as arrays of c h a r a c t e r s . There are no v a r i a b l e l e n g t h s t r i n g s , no s u b s t r i n g pseudovariable t o a s s i g n c h a r a c t e r s to a segment of a s t r i n g , and no i n c o r e t r a n s p u t . A l t h o the RAIDE implementation i s not p a r t i c u l a r l y s t r i n g -o r i e n t e d , these f e a t u r e s are e s p e c i a l l y u s e f u l during debugging. Even a debugging system has to undergo debugging. 14. P a s c a l ' s transput f a q i l i t i e s are austere and d i f f i c u l t to extend. The p r o v i s i o n t h a t the f i r s t r e c o r d of a f i l e must be read when the f i l e i s opened may be a c c e p t a b l e i n a b a t c h - o r i e n t e d environment, but i t makes i n t e r a c t i v e processing u n n a t u r a l l y d i f f i c u l t . The handling o f n o n t e x t f i l e s i s l i k e w i s e too r e s t r i c t i v e . I t i s sometimes convenient to place r e c o r d s of v a r i o u s types together i n one f i l e or to e a s i l y read and write p o r t i o n s of ar r a y s {e.g., t o implement the save and restore a c t i o n s of RAIDE). The syntax o f the P a s c a l f i l e d e c l a r a t i o n makes doing so p a i n f u l l y arduous. Chapter V. The Implementation 91 15. P a s c a l should provide lower and upper bound f u n c t i o n s f o r a l l datatypes., Given the s c a l a r type " c o l o r = (blue, red, y e l l o w ) " , i t i s the programmer's r e s p o n s i b i l i t y t o remember t h a t the upper bound of ' c o l o r ' i s 'yellow'. The 'pred' and 'succ' f u n c t i o n s cannot even be a p p l i e d e f f e c t i v e l y t o s c a l a r types without knowing t h i s . I f constants are allowed t o be t r a n s l a t i o n - t i m e e x p r e s s i o n s , then bound f u n c t i o n s w i l l a l s o be e s s e n t i a l f o r subrange ty p e s , such as the bounds of an a r r a y , to reduce the number of constant d e f i n i t i o n s necessary. 16. In the PASCAL/OBC implementation, i d e n t i f i e r s are only s i g n i f i c a n t to the f i r s t ten c h a r a c t e r s . . Horse s t i l l , the language standard [ J e n s 74] suggests f o r p o r t a b i l i t y that i d e n t i f i e r s be unigue w i t h i n t h e i r f i r s t e i g h t c h a r a c t e r s . T h i s i s f a r too r e s t r i c t i v e f o r systems programming a p p l i c a t i o n s s i n c e i t encourages the use o f c r y p t i c a b b r e v i a t i o n s and can l e a d t o d i f f i c u l t - t o - d e t e c t e r r o r s i f two i d e n t i f i e r s are not unigue w i t h i n t h e i r f i r s t ten c h a r a c t e r s . A l i m i t of ten c h a r a c t e r s i s not a s i g n i f i c a n t improvement over s i x , as i n F o r t r a n . The l e n g t h of the above comments concerning P a s c a l may l e a d the reader to b e l i e v e t h a t i t s choice as the systems implementa-t i o n language was poor. The c r i t i c i s m s a r e meant to be complete, not s c a t h i n g . Altho P a s c a l was not designed f o r systems implementation, i t has proved to be a u s e f u l t o o l . Chapter V. The Implementation 92 Even tho both the SPAM s i m u l a t o r and RAIDE were implemented i n P a s c a l , D i s p e l was p r o v i s i o n a l l y implemented by embedding D i s p e l - l i k e commands i n the macroprocessor TOSI (Vene 761. For example, the D i s p e l u t t e r a n c e " d i s p l a y :,x i n tfoo.,•* has the TOSI t r a n s l i t e r a t i o n "(DISPLAY, (IN, (ID,x), (ID, foo));)••«• k TOSI macros were w r i t t e n f o r each of the p r i m i t i v e a c t i o n s of D i s p e l as w e l l as f o r most of D i s p e l * s nonterminal symbols. A l t h o not e l e g a n t from the user's p o i n t of view, t h i s method of i n t e r f a c i n g with RAIDE proved e x p e d i t i o u s . , Since the macroprocessor i n t e r p r e t s s t r i n g s d i r e c t l y , t h e r e i s no need t o t r a n s l a t e u t t e r a n c e s i n t o an i n t e r m e d i a t e form. Thus, r e i n v o c a t i o n of a debugging r o u t i n e merely i n v o l v e s r e i n t e r p r e t i n g i t s s t r i n g . d e f i n i t i o n s , \ F u r t h e r , TOSI a u t o m a t i c a l l y handles many of the l a b o r i o u s d e t a i l s , such as p r o v i d i n g the p r i m i t i v e a r i t h m e t i c o p e r a t o r s and r e p o r t i n g undeclared debugging v a r i a b l e s . . The primary d i f f i c u l t y with using TOSI was the incomplete-ness of i t s documentation f Vene 76]. S e v e r a l p r i m i t i v e f u n c t i o n s were not d e s c r i b e d , undocumented implementation l i m i t a t i o n s were unearthed p a i n f u l l y , and' there were some i n a c c u r a c i e s i n the documentation. Furthermore, due to l i m i t e d use and a low l e v e l of support, the implementation was somewhat shaky. Executing TOSI a l s o proved expensive, due t o i t s implementation using the TRUST t r a n s l a t o r w r i t i n g system. The Aspro t r a n s l a t o r was a l s o implemented using TRUST, together with an extension o f TRUST c a l l e d LANCE {Appe 78], Experiences using TRUST are d e s c r i b e d elsewhere £ Abra 77], The Chapter V. The Implementation 93 most s i g n i f i c a n t c r i t i c i s m of TRUST i s t h a t i t i s poorly documented, As with TOSI, implementation l i m i t a t i o n s were not documented, r e s u l t i n g i n many hours of f r u s t r a t i n g debugging. The best aspect o f the Aspro t r a n s l a t o r i s the code generator r o u t i n e . I t i s an Algol-W program which t o u r s an i n t e r m e d i a t e g r a p h i c r e p r e s e n t a t i o n of the user source program. Because of the convenience of the r e p r e s e n t a t i o n and s i n c e the t r e e t o u r e r i s a w e l l - w r i t t e n , readable program, modifying the Aspro t r a n s l a t o r to generate SPAM code was moderately easy, r e q u i r i n g o n l y about two weeks o f e f f o r t . The l a s t phase of the implementation was modifying the BCPL-V t r a n s l a t o r t o i n t e r f a c e with RAIDE. The t r a n s l a t o r , which i t s e l f i s w r i t t e n i n BCPL, i s w e l l s t r u c t u r e d i n terms of modular composition. U n f o r t u n a t e l y , i t s coding i s poor and implementation documentation i s n e a r l y n o n e x i s t e n t . ; Despite the bad example presented by the t r a n s l a t o r i t s e l f , BCPL proved a good systems implementation language.,• Altho s y n t a c t i c a l l y p e c u l i a r , the c o n t r o l s t r u c t u r e s are n a t u r a l and convenient f o r systems a p p l i c a t i o n s . The t y p e l e s s n e s s of BCPL was not a negative f e a t u r e (as had been expected)a but a r e c o r d type d e f i n i t i o n f a c i l i t y was missed. The moral i s t h a t the syntax of a language i s not as important a c o n s i d e r a t i o n i n i t s use f o r systems software as i s the way. i n which the language i s used. In other words, human f a c t o r s are more s i g n i f i c a n t than the c h o i c e of language. 94 Chapter 71. Summary and C o n c l u s i o n s The r e s e a r c h covered by t h i s t h e s i s i n v o l v e s many f a c e t s . The f o l l o w i n g are the major accomplishments of t h i s r e s e a r c h : 1. The c u r r e n t s t a t e of i n t e r a c t i v e , run-time program debug-ging was e x t e n s i v e l y surveyed. 2. A new debugging t o o l was conceived i n response to perceived d e f i c i e n c i e s with e x i s t i n g ones. The system, RAIDE, was based on the a b s t r a c t i o n of debugging concepts. Except f o r some minor f e a t u r e s , RAIDE was completely implemented. 3. A debugging command language, c a l l e d D i s p e l , f o r i n t e r a c t -i n g with RAIDE was designed and evaluated. Numerous examples of i t s use to express debugging r e q u e s t s were presented. Due to time c o n s t r a i n t s however, D i s p e l was not implemented as s p e c i -f i e d ; a l o w - l e v e l , t r a n s l i t e r a l implementation of D i s p e l using an i n t e r a c t i v e macroprocessor was s u b s t i t u t e d . 4. A v i r t u a l machine t o f a c i l i t a t e run-time debugging was designed and e v a l u a t e d . , A s i m u l a t o r f o r i t was implemented. 5. Two language t r a n s l a t o r s , f o r Aspro and BCPL, were modified to i n t e r f a c e with RAIDE to demonstrate i t s language-independence. 6. R e f l e c t i o n s on the t o o l s used i n the v a r i o u s phases o f the implementation were presented. Chapter VI. Summary and Con c l u s i o n s 95 T h i s chapter c o n t i n u e s with an e x p o s i t i o n of the importance of RAIDE, a d i s c u s s i o n o f i t s shortcomings, some thoughts on p o s s i b l e f u t u r e e x t e n s i o n s t o RAIDE and other areas i n debugging worthy of e x p l o r a t i o n , and some su g g e s t i o n s based on the e x p e r i -ences of the implementation f o r how t r a n s l a t o r s should be designed to f a c i l i t a t e run-time debugging. A. Importance The debugging system RAIDE and i t s language D i s p e l are o r i g i n a l and s i g n i f i c a n t c o n t r i b u t i o n s to the s t a t e of the a r t of program debugging f o r the f o l l o w i n g reasons: 1. The k e r n e l of RAIDE c o n t a i n s a smal l s e t of p r i m i t i v e s s u f f i c i e n t t o implement a l l the t r a d i t i o n a l debugging a c t i o n s . U n l i k e p r e v i o u s debugging systems which have been designed r a t h e r haphazardly, RAIDE's design i s based on the concept of minimum s u f f i c i e n c y . 2. The t r a d i t i o n a l debugging p r i m i t i v e s (e.g. , t r a c e s , dumps, and t r a p s ) , have been g e n e r a l i z e d i n RAIDE. An example o f t h i s g e n e r a l i z a t i o n i s the l a c k of a p r i m i t i v e t r a c e a c t i o n . A l l t r a d i t i o n a l debugging a i d s are a v a i l a b l e t o the user t h r u debugging procedures. T h i s g e n e r a l i z a t i o n of debugging concepts should allow f o r the easy i n c l u s i o n of f u t u r e debugging a i d s , and should allow the system to be extended t o deal with languages d i f f e r e n t from the a l g e b r a i c p r o c e d u r a l languages on which most pre v i o u s systems have been based.. RAIDE i s a f r e s h approach t o i n t e r a c t i v e , h i g h - l e v e l symbolic debugging. Chapter VI. Summary and C o n c l u s i o n s 96 3. RAIDE i s one of the few debugging systems t o have language independence as a primary design c r i t e r i o n . V i r t u a l l y a l l previous system have been language-dependent by design or imple-mentation, 4. The RAIDE debugging language I s more e x t e n s i v e and uniform than t h a t of any p r e v i o u s debugging system. D i s p e l r e p r e s e n t s a compromise between an i n t e r a c t i v e command language and a sp e c i a l - p u r p o s e programming language. T h i s compromise r e s u l t s from system design c r i t e r i o n 4 ( v i z . , that the system be usable both i n batch and i n t e r a c t i v e l y ) . 5. RAIDE i s the f i r s t i n t e r a c t i v e debugging system designed s p e c i f i c a l l y as a t r a n s l a t o r w r i t i n g system resource. Such o f f - t h e - s h e l f design should reduce the implementation burden of f u t u r e language implementors. 6., RAIDE p o t e n t i a l l y p r o v i d e s more run-time and a n a l y s i s debugging i n f o r m a t i o n than most previous systems. I t has been designed to f i l t e r , not mask, t h i s inf.orma.tion so t h a t the user can o b t a i n maximum b e n e f i t from the debugging environment. 7. RAIDE i s one of the few systems which can be used t o debug m u l t i l i n g u a l c o l l e c t i o n s of programs. S e v e r a l preceding systems have provided an i n t e r f a c e to machine-language s u b r o u t i n e s ; RAIDE enables s u b r o u t i n e s t o be w r i t t e n i n any h i g h - l e v e l language f o r which an i n t e r f a c e has been d e f i n e d . Chapter VI. Summary and C o n c l u s i o n s 97 8. Language t r a n s l a t o r s which are i n t e r f a c e d to BAIDE can supply i n f o r m a t i o n i n v a r y i n g l e v e l s of d e t a i l . P r e v i o u s debugging systems have g e n e r a l l y r e g u i r e d complete co o p e r a t i o n from t r a n s l a t o r s . B. Shortcomings /*. When the l e a r n e d man e r r s , he e r r s i n a l e a r n e d way. — Arabic proverb */ Nothing i s p e r f e c t , and s i n c e RAIDE i s something, i t must be imperfect. T h i s s e c t i o n w i l l d e s c r i b e l i m i t a t i o n s i n the design and implementation of RAIDE, and shortcomings which have become apparent during i t s development. 1. Whereas language-independence i s an advance over previous debugging systems, t h i s approach does have s e v e r a l disadvan-tages. Foremost among these i s t h a t run-time changes to c o r r e c t the source program are d i f f i c u l t i n a n o n i n t e r p r e t i v e environment. E i t h e r the t r a n s l a t o r s must be very c o o p e r a t i n g ( i . e . , a v a i l a b l e on demand at run-time), or temporary patches to the t r a n s l a t e d program c o u l d be made at run-time using some " u n i v e r s a l " programming language (for which RAIDE has access to a t r a n s l a t o r ) . N e v e r t h e l e s s , the value of nonsource-language changes i s dubious s i n c e the user i s u n l i k e l y to remember to modify the source program to r e f l e c t the run-time changes. , 2. Another disadvantage of the language-independent approach i s that using one or more of the host source languages t o s p e c i f y debugging a c t i o n s may f o s t e r c o n f u s i o n . I t i s thus Chapter VI., Summary and Co n c l u s i o n s 98 d e s i r a b l e to provide a separate debugging language which the user must l e a r n . Besides the i n i t i a l overhead i n l e a r n i n g a debugging language, many users appear t o i n h e r e n t l y p r e f e r debugging using the n o t a t i o n of the host source language. Nevertheless, no e x i s t i n g debugging system uses e x a c t l y the source language f o r debugging commands a t run-time. I n v a r i a b l y an extended subset i s used. Since t h e r e i s a l r e a d y d e v i a t i o n , some use r s ' d e s i r e f o r " c o m p a t i b i l i t y " must be seen as a s u b j e c t i v e b i a s . ,. 3. A t h i r d disadvantage, which i s in h e r e n t i n any language-independent system, i s t h a t i t may not always be p o s s i b l e to c a t e r to the p e c u l i a r i t i e s of p a r t i c u l a r source languages, e i t h e r e x i s t i n g or f u t u r e . I t appears impossible t o answer the c r i t i c i s m "How do you know th a t language X can r e a l l y be i n t e r f a c e d t o RAIDE?" without a c t u a l l y attempting t o d e f i n e the i n t e r f a c e . S 4. The implementation has e f f e c t i v e l y excluded i n t e r p r e t e d languages from the c l a s s of RAIDE debuggable languages. Osing a v i r t u a l machine thus l i m i t s t h e scope o f the e n t i r e implementa-t i o n . 5. The d e c i s i o n t o implement RAIDE using a v i r t u a l machine has l i m i t e d s l i g h t l y the c l a s s of bugs which the system can d e t e c t . S p e c i f i c a l l y , t r a n s l a t o r and loader e r r o r s cannot be detected with RAIDE. I t i s not c l e a r , however, t h a t e x i s t i n g systems based on " r e a l " machines address t h i s area adequately, o r even Chapter VI. Summary and C o n c l u s i o n s 99 t h a t such e r r o r s are s i g n i f i c a n t i n comparison t o user e r r o r s . The v i r t u a l machine implementation o f RAIDE may a l s o prevent i t s use i n d e t e c t i n g machine-dependent hugs, such as c h a r a c t e r c o l l a t i n g sequence dependencies, and i n d e t e c t i n g implementation dependencies, t h a t i s , the gray areas of a language's design which are l e f t f o r m a l l y undefined, 6. I n t e r f a c i n g an e x i s t i n g t r a n s l a t o r to RAIDE i s n o n t r i v i a l . In f a c t , i f the s t r u c t u r e o f the t r a n s l a t o r i s poor, i n t e r f a c i n g i t may be impossible or even more d i f f i c u l t than p r o v i d i n g a simple language-dependent run-time debugging package i n s t e a d . The t r a n s l a t o r s chosen f o r t h i s t h e s i s were s e l e c t e d p r i m a r i l y f o r t h e i r m o d i f l a b i l i t y . Such m o d i f i c a t i o n s are considered necessary, but not fundamental, f o r demonstrating the f e a s i b i l -i t y of the system.. N e v e r t h e l e s s , RAIDE i s not aimed a t e x i s t i n g t r a n s l a t o r s . I t has been designed p r i m a r i l y as a t o o l f o r use with implementing f u t u r e t r a n s l a t o r s . As such, i t i s much l i k e any other t r a n s l a t o r w r i t i n g system resource. When a new parser generator i s implemented, i t i s not c r i t i c i z e d f o r being d i f f i c u l t t o i n c o r p o r a t e i n t o e x i s t i n g t r a n s l a t o r s . 7 . There i s no obvious way of d e a l i n g with the qu e s t i o n "Can RAIDE do x?" without a c t u a l l y producing D i s p e l utterances t o accomplish the d e s i r e d goal.. In other words, how can i t be "proved" i n some r i g o r o u s way t h a t RAIDE*s p r i m i t i v e a c t i o n s are s u f f i c i e n t to c a r r y out a l l c o n c e i v a b l e debugging re q u e s t s ? Many of the t r a d i t i o n a l debugging r e q u e s t s have been shown doable by c o n s t r u c t i o n thru the examples of S e c t i o n I I I . C . Chapter VI. Summary and C o n c l u s i o n s 100 Thus, the question becomes one of provinq that the p r i m i t i v e s are s u f f i c i e n t l y g e n e r a l and extendable t o implement a l l "computable" debugging reguests., S i n c e no e x i s t i n g debugging system has been shown t o f u l f i l l t h i s theorem, i n some sense RAIDE i s at l e a s t as w e l l designed as other debugging systems. 8. The most s e r i o u s shortcoming of the work repo r t e d i n t h i s t h e s i s i s t h a t i t i s not user t e s t e d . , The implementation has been p r i m a r i l y undertaken t o demonstrate the f e a s i b i l i t y of the system design concepts. T h i s l e a v e s open guestions concerning how pleasant the system i s to use, which can be answered o n l y by f i e l d t e s t i n g and o b t a i n i n g the views of a c t u a l users. I n s u f f i c i e n t feedback has a l s o l e f t open the q u e s t i o n as to what i s the implementation overhead i n u s i n g the system ( L e s t 71a, L e s t 71b]. A l s o , i s i t p o s s i b l e to eva l u a t e the system apart from user s a t i s f a c t i o n and a e s t h e t h i c c o n s i d e r a t i o n s ? C. Future D i r e c t i o n s /* E x c e l s i o r l — motto of New York s t a t e .*/ The purpose of t h i s s e c t i o n i s t w o - f o l d : to d e s c r i b e p o s s i b l e extensions t o RAIDE and i t s implementation, and to suggest other d i r e c t i o n s i n h i g h - l e v e l debugging which might be f r u i t f u l areas f o r e x p l o r a t i o n . There are numerous ways i n which RAIDE can be:extended: 1. RAIDE can be extended t o handle p a r a l l e l p r o cessing ( H adj 76, V i c t 77]. The only l i m i t i n g f a c t o r at present i s Chapter VI. Summary and C o n c l u s i o n s 101 SPAM. By i n t r o d u c i n g a process c o n t r o l stack and a £_ogess d e s c r i p t o r , and by s p a g h e t t i - s t a c k i n g the segment c o n t r o l , scope, dynamic storage, and expression s t a c k s , SPAM can be extended t o support p a r a l l e l p r ocessing. I t should then be s t r a i g h t f o r w a r d to add a process segment-generic and a g e n e r i c -r e l a t e d system f u n c t i o n CURRENT_PROCESS t o BAIDE. 2. I t would be i n t e r e s t i n g t o produce a microprogrammed implementation of SPAM., T h i s might appease the c r i t i c i s m t h a t run-time debugging i s too expensive. Much o f the c u r r e n t system overhead i s i n the s i m u l a t i o n of SPAM, not w i t h i n BAIDE proper. 3. Producing an implementation of RAIDE which i s o p e r a t i n g -system- and machine-independent [ V i c t 77], but r e t a i n i n g RAIDE 'S h i g h - l e v e l and symbolic nature, would be worthwhile. A l t h o the design of RAIDE conforms with t h i s g o a l , the c u r r e n t implementa-t i o n i s both operating-system- and machine-dependent., 4. I t may be p o s s i b l e and d e s i r a b l e to extend RAIDE to i n c l u d e more program t e s t i n g a i d s [ I t o h 73, Panz 76], such as t e s t procedures. A t e s t procedure i s a r o u t i n e whose s o l e i n t e n t i s to v e r i f y the c o r r e c t n e s s of another r o u t i n e by e x e r c i s i n g a l l i t s c o n t r o l paths and t e s t i n g i t out on v a r i o u s i n p u t data values. Since t e s t i n g and debugging are c l o s e l y r e l a t e d a c t i v i t i e s , i t i s reasonable to expect that one software t o o l might be used to a i d both. 5. RAIDE i s a debugging a i d , not a d i a g n o s t i c system. I t makes no attempt to analyze the cause of an e r r o r . Some work Chapter VI. Summary and C o n c l u s i o n s 102 has been done on automating the process of t r a c i n g an e r r o r to i t s cause [ Davi 75 ]. I t may be p o s s i b l e to add such a c a p a b i l i t y t o RAIDE.,, 6. Adding an u n d o command to RAIDE, which r e v e r s e s the e f f e c t o f the p r e v i o u s l y entered command, may be a u s e f u l a d d i t i o n . The major problem with i t s implementation i s determining e x a c t l y how much and what i n f o r m a t i o n must be saved to enable an u n d o to be accomplished. 7. Transput i s an area i n which RAIDE c o u l d s u c c e s s f u l l y be expanded. The d i s p l a y a c t i o n i s d e f i c i e n t . There i s a need f o r r e a d i n g and w r i t i n g , not only user va'lues, but i n f o r m a t i o n concerning the s t a t e of the debugging system., With such f a c i l i t i e s , i t may be p o s s i b l e t o implement s a v e : a n d r e s t o r e as debugging procedures and thus to remove them from the l i s t of p r i m i t i v e system a c t i o n s . I t should a l s o be p o s s i b l e then to implement an u n e x e c a t e a c t i o n t o r e v e r s e execution of the user program. Such a c a p a b i l i t y has been shown to be v a l u a b l e f Z e l k 71, Zelk 73 ]. Beefing up the t r a n s p u t w i l l a l s o make i t p o s s i b l e t o keep program e x e c u t i o n s t a t i s t i c s between runs, thus e n a b l i n g cumulative s t a t i s t i c s t o be maintained. Besides v a r i o u s e x t e n s i o n s to the e x i s t i n g debugging system, t h i s work and r e l a t e d o b s e r v a t i o n s have pointed out other areas i n the realm of debugging which might be pursued: 1. There i s a d e f i n i t e need f o r e m p i r i c a l s t u d i e s to v a l i d a t e the c l a i m t h a t debugging systems a c t u a l l y do a i d s i g n i f i c a n t l y Chapter VI. Summary and C o n c l u s i o n s 103 i n the program development process.. Some work has been done i n t h i s area [ B i e r 75, Goul 75, Gran 66], but much more i s needed. 2. I t i s apparent t h a t debugging technigues are not being taught adequately to n o v i c e programmers. More re s e a r c h i s necessary on e f f e c t i v e ways of conveying debugging methods [Math 74], Debugging i s l a r g e l y an i n t u i t i v e process a t present. I t needs to be systematized more adeguately, 3. The EAIDE approach to debugging i s to provide one t o o l which i s u s e f u l t o users o f v a r i o u s source languages. Another approach i s t o design a debugger generator system which, given a language d e f i n i t i o n , produces a language-dependent debugger f o r programs w r i t t e n i n t h a t language. T h i s i s analogous to the t a b l e - d r i v e n parser versus p a r s e r generator approaches i n t r a n s l a t o r w r i t i n g systems r e s e a r c h . D. Suggestions f o r T r a n s l a t o r Design In l i g h t of the e x p e r i e n c e s gained i n the implementation of EAIDE, t h i s s e c t i o n w i l l d i s c u s s the v a r i o u s ways i n which t r a n s l a t o r implementors can f a c i l i t a t e run-time debugging. Whether the implementor i n t e n d s t o use EAIDE f o r debugging or to provide a language-dependent debugging package, or i f the imple-mentor wishes only t o p r o v i d e adequate hooks f o r someone e l s e to add such a f a c i l i t y , the f o l l o w i n q p o i n t s should be kept i n mind: 1., do not throw away t r a n s l a t i o n - t i m e i n f o r m a t i o n too r e a d i l y ; Chapter VI. Summary and C o n c l u s i o n s 104 2. s t r u c t u r e the t r a n s l a t o r such t h a t i n f o r m a t i o n i s easy to o b t a i n ; 3. code the t r a n s l a t o r so that i t i s easy to read and to modify; 4. i f p o s s i b l e , choose to generate code f o r a h o s p i t a b l e o b j e c t machine; 5. t r e a t run-time e r r o r c o n d i t i o n s i n a uniform manner; 6. write run-time l i b r a r y r o u t i n e s with debugging and e r r o r handling i n mind; 7. generate o b j e c t code which i s easy to understand and to modify; and 8. document! Some of these p o i n t s have been t r e a t e d p r e v i o u s l y to some extent i n f Ashb 73]. They w i l l a l l be d i s c u s s e d i n d e t a i l below* There i s a tendency among t r a n s l a t o r implementors to d i s -c a r d t r a n s l a t i o n - t i m e i n f o r m a t i o n as soon as there i s no f u r t h e r apparent need f o r i t s r e t e n t i o n . , For example, source program code i s g e n e r a l l y e l i m i n a t e d once i t has been s y n t a c t i c a l l y analyzed and, f o r b l o c k - s t r u c t u r e d languages, v a r i a b l e symbol t a b l e i n f o r m a t i o n i s o f t e n d i s c a r d e d once the scope block of the v a r i a b l e has been t r a n s l a t e d . Undoubtedly, i n f o r m a t i o n abandon-ment has been motivated by v a l i d implementation c o n s t r a i n t s : o f t e n there has been i n s u f f i c i e n t memory f o r t o t a l r e t e n t i o n . Nevertheless, the premature d i s c a r d i n g of t r a n s l a t i o n - t i m e i n f o r m a t i o n i s a major d i f f i c u l t y with i n t e r f a c i n g a t r a n s l a t o r t o a run-time debugging system. Fu r t h e r , e f f i c i e n c y and Chapter VI. Summary and C o n c l u s i o n s 105 resource c o n s t r a i n t arguments are becoming more d i f f i c u l t to s u s t a i n i n view of the "software c r i s i s " and c o n t i n u i n g advances i n hardware technology. Even on minicomputer systems, l i m i t e d memory i s r a p i d l y being r e l e g a t e d to the h i s t o r y hooks., A l s o , t r a n s l a t o r e x ecution speed i s becoming of l e s s concern i n view of the o v e r a l l e f f i c i e n c y o f the e n t i r e software development c y c l e . There are b a s i c a l l y t hree c l a s s e s of i n f o r m a t i o n which a t r a n s l a t o r should p r o v i d e to a debugging system: d e s c r i p t i o n s of each symbolic data item, d e s c r i p t i o n s of each important segment of o b j e c t code, and the source code broken i n t o l e x i c tokens. For each symbolic data item of the user source program, the t r a n s l a t o r should provide i t s : a. i d e n t i f i e r name; b. data type (e.g., v a r i a b l e or c o n s t a n t ) ; c. l e x i c ( l e v e l , order) p a i r , or other address s p e c i f i c a -t i o n ; d. scope with r e s p e c t to procedures and b l o c k s ; e. type, i n c l u d i n g range of v a l u e s f o r s c a l a r and enumer-ated t y p e s ; f. , dimension and s u b s c r i p t bounds i n f o r m a t i o n , where known, f o r an a r r a y ; and g. i n i t i a l o r constant value, i f known. For each important code segment of the user source program, the t r a n s l a t o r should provide i t s : Chapter VI. Summary and C o n c l u s i o n s 106 a. l a b e l name, i f present; b. segment type (e.g., statement or procedure); c. scope ( i . e . , i t s r e l a t i o n s h i p to other code segments); d. parameter and r e s u l t t y p e s , i f any; and e. bounds w i t h i n the o b j e c t code area or f i l e . I t i s convenient, a l t h o not e s s e n t i a l , f o r the t r a n s l a t o r to supply the debugging system with the user source program code.,. I t should be decomposed i n t o l e x i c tokens and a s s o c i a t e d with the c o r r e s p o n d i n g o b j e c t code segment d e s c r i p t i o n s . For RAIDE, the i n f o r m a t i o n l i s t e d above i s provided as p a r t of the SPAM d e s c r i p t o r s and the RAIDE program s p e c i f i c a t i o n s . , 8hen d e s i g n i n g the i n t e r n a l s t r u c t u r e of a language t r a n s l a t o r , i t i s important to bear i n mind how d i f f i c u l t i t w i l l be f o r the implementor, or someone e l s e , to provide the t r a n s l a t i o n - t i m e i n f o r m a t i o n which a debugging system w i l l need., Three areas of design are of s p e c i a l importance: the s t r u c t u r e of the symbol t a b l e , t r a n s l a t o r m o d u l a r i z a t i o n , and the interme-d i a t e user program r e p r e s e n t a t i o n . „. The t r a n s l a t o r symbol t a b l e s h o u l d c o n t a i n a l l symbol i n f o r m a t i o n i n a c e n t r a l i z e d , easy to access, and understandable format. I d e a l l y , i t should be p o s s i b l e to w r i t e one module which, given the symbol t a b l e as an argument, generates a f i l e d e s c r i b i n g a l l program data items i n a format a c c e p t a b l e to the run-time debugging system.; The d e c e n t r a l i z a t i o n of symbol t a b l e i n f o r m a t i o n was a problem encountered i n i n t e r f a c i n g the BCPL-V t r a n s l a t o r to RAIDE. Separate BCPL v e c t o r s are used to s t o r e Chapter VI. Summary and C o n c l u s i o n s 107 d i f f e r e n t symbol a t t r i b u t e s . Undoubtedly i t was done t h i s way due to the absence o f r e c o r d types i n BCPL, the language i n which the t r a n s l a t o r i t s e l f i s w r i t t e n . The decomposition o f the t r a n s l a t o r i n t o modules i s an important c o n s i d e r a t i o n . The t r a d i t i o n a l t r a n s l a t i o n phases ( v i z . , l e x i c scanning, s y n t a c t i c a n a l y s i s , semantic p r o c e s s i n g , and code generation) should be represented by separate t r a n s l a t o r r o u t i n e s . Such s e p a r a t i o n makes understanding the t r a n s l a t o r e a s i e r and, hence, makes modifying i t t o i n t e r f a c e to a debugging system e a s i e r . Both the BCPL and &sple t r a n s l a t o r s b e n e f i t g r e a t l y from t h i s o r g a n i z a t i o n . In f a c t , s e v e r a l other candidate t r a n s l a t o r s were r e j e c t e d because of t h e i r poor i n t e r -n a l o r g a n i z a t i o n . The l o c a l l y a v a i l a b l e P a s c a l t r a n s l a t o r , f o r i n s t a n c e , i s a one-pass t r a n s l a t o r whose s p a g h e t t i - l i k e i n t e r -m i n g l i n g of scanning, a n a l y s i s , semantic p r o c e s s i n g , and code genera t i o n make i t v i r t u a l l y u n i n t e l l i g i b l e to a l l but hearty s o u l s . C o n s t r u c t i n g an i n t e r m e d i a t e user program r e p r e s e n t a t i o n during t r a n s l a t i o n g r e a t l y f a c i l i t a t e s i n t e r f a c i n g to a debug-ging system. Both the BCPL and Asple t r a n s l a t o r s transform programs i n t o g r a p h i c i n t e r m e d i a t e r e p r e s e n t a t i o n s on which both semantic r o u t i n e s and code g e n e r a t o r s operate. I d e a l l y , i t should be p o s s i b l e t o w r i t e one module which, g i v e n the interme-d i a t e r e p r e s e n t a t i o n as an argument, generates a f i l e d e s c r i b i n g a l l important program code segments i n a format a c c e p t a b l e to the run-time debugging system., a nongraphic i n t e r m e d i a t e Chapter VI. Summary and C o n c l u s i o n s 108 i r e p r e s e n t a t i o n i s l e s s d e s i r a b l e s i n c e i t obscures the s t a t i c s t r u c t u r e of the source program. Altho i t should go without s a y i n g , a t r a n s l a t o r should be coded i n a readable and, t h e r e f o r e , easy-to-modify manner. In p a r t i c u l a r , v a r i a b l e names should be mnemonic, the code should be l o g i c a l l y i n d e n t e d , and adeguate i n t e r n a l documentation should e x i s t . I t i s lamentable indeed t h a t there are so many po o r l y coded t r a n s l a t o r s i n e x i s t e n c e s t i l l . I t i s i n d e f e n s i b l e t h a t the t r a n s l a t o r s f o r a systems implementation language ( v i z . , BCPL) and a s t u d e n t - o r i e n t e d , " s t r u c t u r e d " language ( v i z . , Pascal) should be poorly coded. R e g r e t t a b l y , such was found to be the case with the BCPL and P a s c a l t r a n s l a t o r s l o c a l l y a v a i l a b l e . In c o n t r a s t , the code generator f o r the Asple t r a n s l a t o r was w e l l coded, which e x p l a i n s why i t was p o s s i b l e to completely change the o b j e c t machine code generated i n only two weeks! I f at a l l p o s s i b l e , the t r a n s l a t o r implementor should generate o b j e c t code f o r a machine which i s h o s p i t a b l e to run-time debugging. SPAM was i n t r o d u c e d i n t o the implementation of RAIDE f o r j u s t t h i s reason ( c f . , S e c t i o n IV,C). I f the o b j e c t machine i s i n h o s p i t a b l e , the implementor should not h e s i t a t e t o simulate on the host machine a pseudomachine more concordant with the goals of debugging, i n p a r t i c u l a r the d e t e c t i o n of run-time e r r o r s . Arguments t h a t i n t e r p r e t i n g v i r t u a l machine code i s i n e f f i c i e n t are r a p i d l y l o s i n g ground with the advent of new hardware t e c h n o l o g i e s such as micropro-Chapter VI. Summary and C o n c l u s i o n s 109 gramming. A t r a n s l a t o r implementor*s b e s t e f f o r t s a t p r o v i d i n g run-time debugging a i d s can be thwarted by an o b j e c t machine which i s a n t a g o n i s t i c toward debugging. To f a c i l i t a t e run-time debugging, the implementor should t r e a t a l l run-time e r r o r s d e t e c t e d i n a uniform manner, f o r example, t h r u a common e r r o r handler. A d d i t i o n a l l y , a r e a s o n a b l e recovery s h o u l d be i n s t i t u t e d f o r each e r r o r c o n d i t i o n so t h a t e x e c u t i o n can proceed l o g i c a l l y once the e r r o r has been c o r r e c t e d or patched by the user at run-time. The presence of t e r m i n a l ( i . e . , nonrecoverable) e r r o r s should be avoided s i n c e they f r u s t r a t e run-time debugging. The implemen-t o r should a l s o i n s u r e t h a t an executing program i s never l e f t i n an unstable s t a t e due to a run-time e r r o r (e.g., p a r t i a l l y computed values should not be l e f t i n r e g i s t e r s ) . I t can be extremely d i f f i c u l t f o r a debugging system t o d e a l with an u n s t a b l e machine s t a t e . I d e a l l y , e r r o r breaks should occur o n l y at p o i n t s c o r r e s p o n d i n g t o breaks between statements i n the source program code. I t i s p r e f e r a b l e t h a t the machine s t a t e be such t h a t the o f f e n d i n g statement can be reexecuted a t run-time f o l l o w i n g e r r o r c o r r e c t i o n or r e c o v e r y . S i m i l a r l y , any run^-time l i b r a r y r o u t i n e s which the imple-mentor provides should i n t e r f a c e c l e a n l y with the debugging system. S p e c i f i c a l l y , l i b r a r y r o u t i n e s should d e t e c t and t r e a t run-time e r r o r s i n the same manner as e r r o r checks compiled d i r e c t l y i n t o the o b j e c t program., I t i s a l s o convenient i f the i n t e r f a c e between the o b j e c t code and l i b r a r y r o u t i n e s i s the Chapter VI. Summary and C o n c l u s i o n s 110 same as that between the o b j e c t code and user s u b r o u t i n e s . T h i s a v o i d s s p e c i a l cases which on l y complicate the debugging system. flow the code generators go about producing o b j e c t code a l s o a f f e c t s the ease of i n t e r f a c i n g with a debugging system. I t i s p r e f e r a b l e t h a t a l l data v a l u e s be accessed u n i f o r m l y to avoid having t o handle numerous s p e c i a l cases a t run-time. For example, the BCPL g l o b a l vector and F o r t r a n COMMON v a r i a b l e s may present d i f f i c u l t i e s i f code f o r them i s generated d i f f e r e n t l y from other program v a l u e s such as l o c a l v a r i a b l e s and c o n s t a n t s . The code ge n e r a t o r s should a l s o a v o i d o p t i m i z i n g the o b j e c t program such t h a t there i s no longer an obvious correspondence between the source and o b j e c t v e r s i o n s of the program. I f too much rearrangement o c c u r s , i t i s d i f f i c u l t f o r the user t o understand the behavior of the executing program.,, The g o a l s of run-time debugging and o p t i m i z a t i o n c o n f l i c t . To f a c i l i t a t e debugging, i t i s o f t e n necessary t o supply more i n f o r m a t i o n a t run-time than i s normally p r o v i d e d , whereas the goal of o p t i m i -z a t i o n i s t o provide l e s s i n f o r m a t i o n than u s u a l . L a s t , but c e r t a i n l y not l e a s t , a t r a n s l a t o r implementor should not underestimate the v a l u e of w e l l - w r i t t e n and a c c u r a t e implementation documentation. H i t h both the BCPL and Asple t r a n s l a t o r s , documentation was n o n e x i s t e n t a t best and i n a c c u -r a t e at worst! T h i s s o r r y s t a t e g r e a t l y hindered i n t e r f a c i n g the t r a n s l a t o r s to RAIDE. Any programmer who implements s o f t -ware and f a i l s t o adequately document i t should be shot ( i . e . , f i r e d i n an i n d u s t r i a l environment, or f a i l e d i n an academic Chapter VI. Summary and C o n c l u s i o n s 111 environment). No one should assume that a program w i l l never be modified, or a t l e a s t looked a t , by someone e l s e . I t i s hoped t h a t t h i s a d v i c e on how t r a n s l a t o r s should be c o n s t r u c t e d w i l l not only b e n e f i t run-time debugging, but a l s o b e n e f i t the o v e r a l l q u a l i t y o f u s e r - o r i e n t e d software. 1 1 2 G l o s s a r y For the convenience o f the reader, d e f i n i t i o n s are provided below f o r the debugging terminology used i n t h i s t h e s i s . A ltho an attempt has been made to conform t o the standard i n f o r m a t i o n p r o c e s s i n g d e f i n i t i o n s , i n e v i t a b l y some v a r i a t i o n s i n usage have a r i s e n . ANALYSIS INFORMATION: i n f o r m a t i o n used to examine the s t a t e of program e x e c u t i o n , f o r example, v a r i a b l e or ex e c u t i o n p r o f i l e s . BREAKPOINT: a p a r t i c u l a r l o c a t i o n i n a program or a p a r t i c u l a r time d u r i n g e x e c u t i o n a t which some debugging a c t i o n i s to be i n i t i a t e d . BOG: any e r r o r which i s a s s o c i a t e d d i r e c t l y or i n d i r e c t l y with a computer, a computer program, i n f o r m a t i o n e n t e r i n g or l e a v i n g a computer, a computer operator o r programmer, or anyone r e l a t e d t o or anything a s s o c i a t e d with any person engaged i n an occupation which uses computers. DEBUGGING: the process o f r e c o g n i z i n g , i s o l a t i n g , and c o r r e c t i n g mistakes i n some computer program. In t h i s t h e s i s the term i s r e s t r i c t e d to the d e t e c t i o n of l o g i c and semantic e r r o r s . The d e t e c t i o n of s y n t a c t i c e r r o r s i s not r e f e r r e d t o as debugging. DEBUGGING SYSTEM: a c o l l e c t i o n o f software t o o l s which a i d i n the debugging process., DUMP: a d i s p l a y of some aspect o f the s t a t e o f a program. The two c l a s s e s of dumps are: memory (or "core") dumps and v a r i a b l e dumps. The l a t t e r are of primary concern i n h i g h - l e v e l debugging systems and are of two types: snapshot and postmortem. ENTOMOLOGY: the study o f bugs by ob s e r v a t i o n fVanT 74:154 ]. EXECUTION PROFILE: a p r o f i l e of the freguency of execution of statements or procedures wi t h i n a program., FLOW TRACE: a t r a c e o f the program l a b e l s or s o u r c e - l e v e l statement numbers encountered during execution of a program. LOGIC ERROR: a d e f i c i e n t implementation of an a l g o r i t h m . POSTMORTEM DUMP: a dump o f a program at i t s p o i n t o f abnormal t e r m i n a t i o n . G l o s s a r y 113 PROFILE: a pos t e x e c u t i o n d i s p l a y of the a c t i v i t y of some aspect of a program, p r i m a r i l y b e n e f i c i a l f o r t e s t i n g and o p t i m i z a t i o n purposes. The two c l a s s e s of p r o f i l e s a re: v a r i a b l e p r o f i l e s and e x e c u t i o n (or flow) p r o f i l e s . P r o f i l e s can e i t h e r be complete f o r the e n t i r e program or s e l e c t i v e w i t h i n a p o r t i o n of the program, SEMANTIC ERROR: a misunderstanding i n the use of some c o n s t r u c t i n the source language. SNAPSHOT DUMP: a dump of an executing program at a s p e c i f i e d p o i n t or time. SUBROUTINE TRACE: a t r a c e of the subroutines invoked ( p o s s i b l y i n c l u d i n g t h e i r parameter and r e s u l t values) d u r i n g execu-t i o n of a program. SYMBOLIC DEBUGGING: the debugging of a program i n terms of the s o u r c e - l e v e l names and c o n s t r u c t s of t h a t program. TESTING: the process of v e r i f y i n g t h a t a computer program behaves a c c o r d i n g t o i t s s p e c i f i c a t i o n s . TRACE: a d i s p l a y of the e x e c u t i o n path of a program., The three c l a s s e s of t r a c e s are: fl o w t r a c e s , v a r i a b l e t r a c e s , and subr o u t i n e t r a c e s . Traces can e i t h e r be complete f o r the e n t i r e program or s e l e c t i v e w i t h i n a p o r t i o n of the program. TRACEBACK: a t r a c e of the procedure i n v o c a t i o n s t a t e of a program at a p a r t i c u l a r p o i n t i n time. VARIABLE PROFILE: a p r o f i l e o f the number of acc e s s e s of or changes t o the v a r i a b l e s i n a program. ; VARIABLE TRACE: a t r a c e o f the names and values of each v a r i a b l e accessed or changed d u r i n g e x ecution of a program. 114 References and Annotated B i b l i o g r a p h y Abramson, Harvey David; Appelbe, W i l l i a m F r e d e r i c k ; and Johnson, Hark S c o t t . " A s s a u l t i n g the Tower of Babel: Experiences with a T r a n s l a t o r W r i t i n g System". T e c h n i c a l Report 77-12, Department of Computer Scien c e , U n i v e r s i t y of B r i t i s h Columbia, 1977 November. 11pp. Appelbe, W i l l i a m F r e d e r i c k . , A S e m a n t i c R e p r e s e n t a -t i o n f o r T r a n s l a t i o n of Hiih^Li5jl~~;;'Alaii : ^ b f f l i G -Languages. D o c t o r a l D i s s e r t a t i o n : Department " o f Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1978 August. 144pp. Ashby, Gordon; Salmonson, Loren; and Heilman, Robert. Design of an i n t e r a c t i v e debugger f o r FORTRAN: MANTIS. Software — P r a c t i c e and Ex.Egrie.ncg, 3:1 (1973 January-March), 65-74." Descr i b e s an i n t e r a c t i v e debugging system i n t e r f a c e d t o the F o r t r a n language, i n which no m o d i f i c a t i o n s are needed to the source program a t t r a n s l a t i o n - t i m e ; a l l debugging code i s added by the debugging system at run-time. ; N e v e r t h e l e s s , the language t r a n s l a t o r was modified t o provide extensive run-time informa-t i o n . The authors g i v e some g u i d e l i n e s t o language implementors on what i n f o r m a t i o n i s needed by a debugging system,. [ B a i r 75] B a i r d , George N. Program debugging using COBOL »74. AFIPS Conference Proceedings, 44 (NCC 1975), 313-318. D e s c r i b e s the language-provided debugging f a c i l i t i e s i n c orpo-r a t e d i n t o the 1974 ANSI Cobol Standard. . These i n c l u d e the c a p a b i l i t y t o suppress the e f f e c t s of added debugging statements at e i t h e r t r a n s l a t i o n - or run-time, s p e c i a l debugging SECTIONS which a c t as i n t e r r u p t procedures, and a g l o b a l DEBUG-ITEM which c o n t a i n s i n f o r m a t i o n concerning the s t a t e of program e x e c u t i o n . [ B a l l 77] B a l l a r d , Alan John.. "UBC DEBUG: The Symbolic Debugging System". Computing Centre, U n i v e r s i t y of B r i t i s h Columbia, 1977 September., 126pp. De s c r i b e s the i n t e r a c t i v e Symbolic Debugging System (SDS) a v a i l a b l e under the MTS o p e r a t i n g system t o a i d i n the debugging of IBM System/360/370 machine-language programs./ I t has been extended t o handle F o r t r a n , PL/I, and PL360 source programs i n a somewhat symbolic manner. The usual machine-level f a c i l i t i e s , as w e l l as a rudimentary programmable breakpoint mechanism, are provided. [Abra 77] (Appe 78] [ Ashb 73] References ana Annotated B i b l i o g r a p h y [ B a l z 69] B a l z e r , Robert H. EXDAMS -- Extendable Debugging and Monitoring System, AFIPS Conference Proceedings, 34 (SJCC 1969) , 567-580. Describes the EXDAMS o n l i n e debugging system f o r PL/I programs. No m o d i f i c a t i o n s are made to the language t r a n s l a t o r ; i n s t e a d , a preprocessor i n s e r t s i n t o the source code c a l l s t o a run-time monitoring package. The run-time package keeps a h i s t o r y f i l e which enables reverse program execution., The package a l s o p r o v i d e s run-time d i s p l a y o f the source code, flow a n a l y s i s , and moti o n - p i c t u r e d i s p l a y of v a r i a b l e s . A l l these f a c i l i t i e s , however, are a v a i l a b l e only a f t e r the program has executed and the h i s t o r y f i l e has been c o n s t r u c t e d ; the system does not support i n t e r a c t i v e debugging. [ B a l z 74] B a l z e r , Robert M. A language-independent program-mer's i n t e r f a c e . AFIPS Conference Proceedings, 43 (NCC 1974), 365-370. De s c r i b e s a programmer's environment which can be i n t e r f a c e d t o any i n t e r p r e t i v e , i n t e r a c t i v e language which can perform s i n g l e statement e v a l u a t i o n (e.g., the EVAL f u n c t i o n of L i s p ) . The system provides an e d i t o r with p r e t t y p r i n t i n g and undoing c a p a b i l i t i e s , the a b i l i t y t o e d i t p r e v i o u s commands, and pro-grammable breakpoints. The system i s w r i t t e n i n INTERLISP, using the p r o t o c o l of the ARPANET t o i n i t i a l l y i n t e r f a c e with the ECL programming system. [ Baue 73] Bauer, F r i e d r i c h Ludwig ( e d i t o r ) . Advanced Course on Software Engineering. S p r i n g e r - V e r l a g , 1973? ~545pp. (ISBN 3-540-06185-1 ] [ Baye 67] Bayer, Rudolf; G r i e s , David; Paul, M.; and Wiehle, H.B. The ALCOR I l l i n o i s 7090/7094 post mortem dump. Communications o f the ACM, 10:12 (1967 December), 804-8087 Descr i b e s an A l g o l 60 postmortem dump f a c i l i t y which i n c u r s almost no run-time overhead unless a program f a i l u r e o ccurs. The language t r a n s l a t o r , however, has been changed s u b s t a n t i a l l y t o produce i n f o r m a t i o n a c c e s s i b l e t o the run-time dump system. [Bern 68] B e r n s t e i n , W i l l i a m A.; and Owens, James T. Debugging i n a t i m e - s h a r i n g environment. JLIIES £2Sference Proceedings, 33: 1 (FJCC 1968) , 7-14. Disc u s s e s the need f o r a "debugging support system" independent of an o p e r a t i n g system f o r use by systems programmers i n debugging an ex e c u t i n g t i m e - s h a r i n g o p e r a t i n g system. The authors a l s o d i s c u s s the p o s s i b i l i t y o f a debugging environment which i s h e u r i s t i c and, thereby, s e l f - d e b u g g i n g . References and Annotated B i b l i o g r a p h y 116 [ B i e r 75] Bierman, A.H.; Baum, R.I.; and Silverman, 8. Trace i n f o r m a t i o n as an a i d to debugging. SIGGSE B u l l e t i n , 7:3 (1975 September), 44-49. Reports the r e s u l t s of an experiment s u p p o r t i n g the c l a i m t h a t i n t e r p r e t i v e e x e c u t i o n of machine code which enables t r a c i n g i n f o r m a t i o n at abnormal t e r m i n a t i o n i s a b e t t e r t o o l f o r debug-gin g than normal ex e c u t i o n without t r a c e s . , [ B l a i 71] B l a i r , James C u r t i s . Extendable n o n - i n t e r a c t i v e debugging. In [ R u s t 71 ], 93-115. „ Describes the commands and i n t e r n a l o r g a n i z a t i o n of the PEBUG debugging system. The system c o n t a i n s three b a s i c components: a b r e a k p o i n t / i n t e r p r e t e r , a command scanner, and command proces-s i n g r o u t i n e s . [Bohr 72] Bobrow, D a n i e l Gureasko. Requirements f o r advanced programming systems f o r l i s t p r o c e s s i n q . Comf ftnlca-t i f i i i s of the ACM, 15:7 (1972 J u l y ) , 618-6277 Expounds the v i r t u e s of the f a c i l i t i e s p r ovided by t h e INTERLISP system {formally known as BBN-LISP) to provide the proqrammer with an environment conducive t o proqram c o n s t r u c t i o n , debuq-qinq, t e s t i n q , and e d i t i n g . [ B o u l 72] Boulton, Peter I. P.; and Jeanes, David L. The s t r u c t u r e and performance of PLUTO, a t e a c h i n g o r i -ented PL/I compiler system., INFOR, 10:2 (1972 June), 140-153. B r i e f l y d e s c r i b e s a s t u d e n t - o r i e n t e d PL/1 t r a n s l a t o r which generates code f o r a PL/I-compatible v i r t u a l machine whose ex e c u t i o n i s i n t e r p r e t e d . The authors s t r e s s the advantages f o r run-time debugging of i n t e r p r e t i n g such an i n t e r m e d i a t e code. [Brad 68] Brady, Paul T. W r i t i n g an o n l i n e debuqqinq proqram f o r the e x p e r i e n c e d user. Communications o£ the. ACM, 11:6 (1968 June) , 423*427. S t r e s s e s the d e s i r a b i l i t y o f minimizinq t y p i n q , c o r r e c t i n q e r r o r s , and producinq t e r s e e r r o r messaqes i n t y p e w r i t e r -o r i e n t e d , machine-language debugging systems. , [Brow 73 ] Brown, Arthur Robert; and Sampson, W.A. Program Debugging. Computer Monographs: Macdonald and Company L i m i t e d , and American E l s e v i e r P u b l i s h i n g , 1973. 166pp. [ISBN 0-356-04267-7 and 0-444-19565-3] Contains a s u p e r f i c i a l d e s c r i p t i o n of debugging techniques as r e l a t e d t o b u s i n e s s a p p l i c a t i o n s and environments. References and Annotated B i b l i o g r a p h y 117 [Brow 74] Brown, Peter J. Macrp P r o c e s s o r s and Technigues f o r ________ Software. -Hiley S e r i e s ~ i n Computing! ~John Wiley and Sons L i m i t e d , 1974, 244pp. [ISBN 0-471-11005-1] [ B u l l 72] B u l l , G.H. Dynamic debugging i n BASIC. Computer ______!/ 15:1 (1972 F e b r u a r y ) , 21-24. Describes a rudimentary debugging f a c i l i t y added to B a s i c on the ICL 803. [Chea 72] Cheatham, T.E., J r . ; and Wegbreit, Ben. A l a b o r a t o r y f o r the study of automating programming., AFIPS Conference Proceedings, 40 (SJCC 1972), 11-21. Di s c u s s e s the need f o r p r o v i d i n g programming-oriented systems which can a s s i s t s u b s t a n t i a l l y i n the development and mainte-nance of programs. [ C l a p 74] Clapp, J.A,; and S u l l i v a n , J. E. Automated monitoring of software g u a l i t y . MIES Conference Proceedings. 43 (NCC 1974) , 337-341. Describes Simon, an automated a i d i n t e g r a t e d i n t o an o p e r a t i n g system to monitor the o v e r a l l progress of a programming p r o j -e c t ' s development. The system a u t o m a t i c a l l y r e t a i n s a h i s t o r y of a l l programming bugs by category. [ C l a r 74] C l a r k , B. L. ; and Ham, F. J.B. "The P r o j e c t SUE System Language Reference Manual". T e c h n i c a l Report CSRG-42, Computer Systems Research Group, U n i v e r s i t y of Toronto, 1974 September. 97pp. [Conr 70] Conrow, Kenneth; and Smith, Ronald. G. NEATER2: a PL/I source statement re f or matter. Cora i_iaisati<aa_ S f the ACM, 13: 11 (1970 November), 669-675. D e s c r i b e s a PL/I p r e t t y p r i n t e r which has an o p t i o n t o i n s e r t code i n t o the source t o provide a run-time freguency count. [Conr 76] Conradi, Reidar. Further c r i t i c a l comments on PASCAL, p a r t i c u l a r l y as a systems programming language. SIGPLAN N o t i c e s , 11:11 (1976 November), 8-25. [Conw 73] Conway, R i c h a r d Walter; and Wilcox, Thomas R. Design and implementation of a d i a g n o s t i c c o m p i l e r f o r PL/I. Communications of the ACM, 16:3 (1973 March), 169-179. Beferences and Annotated B i b l i o g r a p h y 118 Presents an overview of the design c r i t e r i a and implementation s t r u c t u r e of the PL/C d i a g n o s t i c t r a n s l a t o r and b r i e f l y des-c r i b e s the d i a g n o s t i c extensions t o the PL/I language implemen-ted i n PL/C. [Conw 77] Conway, B i c h a r d Walter; Moore, C h a r l e s , J r . ; and Worona, Steven L. An i n t e r a c t i v e v e r s i o n of the PL/C compiler. Proceedings of the ACHAnnual Coaferenee, S e a t t l e , Washington (1977 October)7~308-3T4. Disc u s s e s the c o n c e p t u a l model of a t e r m i n a l as an " i n t e r n a l procedure" i n an i n t e r a c t i v e system f o r a b l o c k - s t r u c t u r e d language. S p e c i f i c a l l y , debugging commands are viewed as an extended subset of the host language, which i s PL/C i n t h i s case. PL/C procedures i l l u s t r a t e the a c t i o n s o f the debugging environment. [ C r e s 70] Cress, Paul H.; D i r k s e n , Paul H. ; and Graham, J . Wesley. £0STEAM J.V with WASfSI and WAJTf.IV. P r e n t i c e - B a l l , 1970. 447pp. flSBN 13-329433-1] [ C r i s 65] Crisman, P. A. ( e d i t o r ) . The S SS f i S i i s i S Sl;S§~Sh3rin§ System; A Programmer's Guide., The HIT~~Press, 1965. S e c t i o n AH.8, 39pp. [ C u f f 72] C u f f , E.N. A c o n v e r s a t i o n a l compiler f o r f u l l PL/I. Computer J o u r n a l , 15:2 (1972 May) , 99-104. , Describes some of the c a p a b i l i t i e s of the IBM PL/I Checkout Compiler and i t s implementation. I t i s i n t e r p r e t i v e , p r o v i d e s numerous run-time checks and d i a g n o s t i c s i n source language terms, can s e t checkpoints and r e s t a r t e x e c u t i o n , and a l l o w s s o u r c e - l e v e l program m o d i f i c a t i o n s a t run-time.. The system i s h i g h l y language-dependent. [ D a v i 75] Davis, Alan Mark; T i n d a l l , Michael H.; and Wilcox, Thomas B. I n t e r a c t i v e e r r o r d i a g n o s t i c s f o r an i n s t r u c t i o n a l programming system. SIGCSE B u l l e t i n , 7: 1 (1975 February) , 168-171. B r i e f l y d e s c r i b e s a d o c t o r a l p r o j e c t by Davis c o n s i s t i n g o f "an a n a l y s i s system f o r execution-time e r r o r s " . The system executes programs i n t e r p r e t i v e l y ; when an e r r o r i s d e t e c t e d , an a n a l y s i s system attempts t o diagnose the source of the e r r o r by r e v e r s e program e x e c u t i o n and i n t e r a c t i o n with the user. (Ehrm 72] Ehrman, John E. „, System design, machine a r c h i t e c t u r e , and debugging. SIGPLAN N o t i c e s , 7:8 (1972 August), 8-23. References and Annotated B i b l i o g r a p h y 119 P l a c e s much of the blame f o r the present "software c r i s i s " pn poor system designs and machine a r c h i t e c t u r e s which do not enhance program debugging. The author presents h i s i d e a s on how machines should be designed t o f a c i l i t a t e debugging. [Evan 65] Evans, Thomas G.; and Darley, D. L u c i l l e . DEBUG --an extension to c u r r e n t o n l i n e debugging technigues. Communications of the ACJS, 8:5 (1965 May) , 321-326. Descr i b e s the DEBUG t y p e w r i t e r - o r i e n t e d , machine-language debug-g i n g system f o r the Univac M-460. The system i s noteworthy f o r two reasons: patches cause dynamic run-time program r e l o c a t i o n and patches t o the machine code cause automatic updating of the source code. [Evan 66] Evans, Thomas G.; and Darley, D. L u c i l l e . O n - l i n e debugging technigues; a survey. , MIPS Conference Proceedings, 29 (FJCC 1966), 37-50. ~ Surveys c u r r e n t (1966) o n l i n e debugging technigues f o r both machine-language and h i g h - l e v e l language systems. The authors s t r e s s the importance of the user having f u l l f l e x i b i l i t y , the user being able to make m o d i f i c a t i o n s i n the n o t a t i o n of the language of the program, and automatic source program m o d i f i c a -t i o n i n p a r a l l e l to m o d i f i c a t i o n s of the t r a n s l a t e d program. [ F e r g 63] Ferguson, H. E a r l ; and Berner, E l i z a b e t h . Debugging systems a t the source language l e v e l . Communications of the ACM, 6:8 (1963 August), 430-432. Describes the BUGTRAN debugging system, a predecessor pf EXDAMS, which uses a preprocessor to make m o d i f i c a t i o n s t o F o r t r a n programs. [ F e r l 71] F e r l i n g , H.-D.; Schmitt, B.; S t r e l e n , Chr.; Thielmann, H.; and Haldschraidt, H. O b j e k t z e i t f e h l e r -prflfung b e i einem T e s t l a u f c o m p i l e r f fJr A l g o l 60. Angewandte I n f o r m a t i k . 4 (1971 A p r i l ) , 165-168, De s c r i b e s the te c h n i g u e s used i n the ALCOR A l g o l 60 t r a n s l a t o r t o d e t e c t at run-time s u b s c r i p t s out of range, undefined v a r i -a b l e s , r e c u r s i v e procedure, c a l l s , and incompatible parameters. The system uses both t r a n s l a t i o n - t i m e generated t a b l e s and i n f o r m a t i o n s t o r e d w i t h i n the machine code, and takes advantage of the p e c u l i a r i t i e s of the IBM 7090 hardware. [Fong 73a] Fong, E l i z a b e t h N. "A Set of Debugging and Monitor-ing F a c i l i t i e s t o Improve the D i a g n o s t i c C a p a b i l i t i e s of a Computer". T e c h n i c a l Bote TN-763, N a t i o n a l Bureau of Standards, Washington, D. C., 1973 March. 20pp. [ (NTIS) COM-73-50314] References and Annotated B i b l i o g r a p h y 120 L i s t s and d e s c r i b e s a number of d i a g n o s t i c f a c i l i t i e s which should be a v a i l a b l e a t t r a n s l a t i o n - t i m e , l i n k / l o a d - t i m e , and run-time to f a c i l i t a t e debugging. [Fong 73b] Fong, E l i z a b e t h N. Improving compiler d i a g n o s t i c s . Datamation, 19:4 (1973 A p r i l ) , 84-86. A condensation o f [Fong 73a]. [ F o u l 75] Fpulk, C l i n t o n R. The DO t r a c e : a simple and e f f e c -t i v e method f o r debugging GOTO-free programs. SIGPLAN N o t i c e s , 10:9 (1975 September), 11-18. De s c r i b e s a form of program t r a c i n g , c a l l e d the DO-t£ace, which i s claimed t o be s i m p l e r and more e f f e c t i v e than"* f u l l or s e l e c t i v e t r a c i n g of g o t o - l e s s programs. ( G a i n 69] Gaines, R. Stockton. The Debugging of Computer £ro-arams. D o c t o r a l D i s s e r t a t i o n : Department of E l e c t r i -c a l E n g i n e e r i n g , P r i n c e t o n U n i v e r s i t y , 1969 August. 170pp. [ UMI order number 70-14,.209] Gives a h i s t o r i c a l overview of debugging methods, p r i m a r i l y as r e l a t e d t o machine-language debugging systems.^ The author s t r e s s e s the importance of c e r t a i n methods and suggests new d i r e c t i o n s , most of which have now been implemented i n v a r i o u s systems. [ G a l l 74] G a l l e y , S.W. ; and Goldberg, Robert P. Software debugging: the v i r t u a l machine approach. Proceedings of the ACM Annual Conference, New York, New York TT974), 395-401." Discusses the use of v i r t u a l machines f o r debugging o p e r a t i n g systems and other p r i v i l e g e d software at the machine language l e v e l without the n e c e s s i t y of a dedicated p h y s i c a l machine. ( G e l l 75] G e l l e r , Dennis P. Debugging other languages i n APL. Software — P r a c t i c e and Experience, 5:2 (1975 A p r i l - J u n e ) , 139-145. Suggests t h a t debugging might f e a s i b l y be done u s i n g APL as a pseudocode. In t h i s process, a program w r i t t e n i n some source language i s t r a n s l a t e d manually i n t o APL and debugging i s c a r r i e d out using the APL i n t e r p r e t e r . [ G l a s 68] G l a s s , Robert L. S P L I N T E R — a PL/I i n t e r p r e t e r emphasising debugging c a p a b i l i t y . Computer B u l l e t i n . 12:5 (1968 September), 180- 185. Describes a n o n i n t e r a c t i v e i n t e r p r e t e r f o r a subset of PL/I w r i t t e n i n F o r t r a n on the Oniyac 1108 under EXEC I I . The system depends on language e x t e n s i o n s to provide flow and v a r i a b l e References and Annotated B i b l i o g r a p h y 121 t r a c e s . I n t e r p r e t a t i o n o f an i n t e r m e d i a t e code f a c i l i t a t e s e x t e n s i v e run-time e r r o r d e t e c t i o n and c o r r e c t i o n ; postmortem dumps and frequency counts are a l s o a v a i l a b l e . [ Goul 75] Gould, John D. Some p s y c h o l o g i c a l evidence on how people debug computer programs. I n t e r n a t i s n a l -J o u r n a l o f Man-Machine S t u d i e s , 7:2 (1975 March), 151-182. De s c r i b e s a c o n t r o l l e d experiment designed t o p r o v i d e evidence on how t r a i n e d programmers debug computer programs. I n t e r a c t i v e debugging a i d s were a v a i l a b l e to the s u b j e c t s , but few of them used the f a c i l i t i e s due, probably, to the a r t i f i c i a l c o n s t r a i n t s imposed on the experiment. [Gran 66] Grant, E.E. "An E m p i r i c a l Comparison of On-Line and O f f - L i n e Debugging". Report SP-2141, System Develop-ment C o r p o r a t i o n , Santa Monica, C a l i f o r n i a , 1966 May. 16pp. [ (NTIS) AD-633 907 ) Describes an experiment to compare o n l i n e and o f f l i n e program debugging with r e s p e c t t o person-hours and computer time./ The r e s u l t s are f a i r l y i n c o n c l u s i v e and h i g h l y dated. [ G r i s 70] Grishman, Ralph. The debugging system AIDS. „ AFIPS Conference Proceedings. 36 (SJCC 197 0), 59-64. De s c r i b e s an i n t e r a c t i v e debugginq system f o r use on the CDC 6600 with F o r t r a n and assembler proqrams. No m o d i f i c a t i o n s to the language t r a n s l a t o r s are necessary; the debugginq system a c c e p t s source l i s t i n g f i l e s as i n p u t and e x t r a c t s r e l e v a n t i n f o r m a t i o n from these. T r a n s l a t e d programs can be e i t h e r s i m u l a t e d or d i r e c t l y executed and t r a p s are not implemented by modifying the machine code. The system keeps a h i s t o r y f i l e and has backup c a p a b i l i t i e s . [ G r i s 71a] Grishman, Ralph. C r i t e r i a f o r a debugging language.. I n [ Rust 71 ], 57-75. Suggests that a debugging language c o n t a i n e v e n t - d r i v e n proce-dures and that the debugging language c l o s e l y resemble the host language. The author l i s t s c r i t e r i a f o r the I comparison of debuqqinq systems and b r i e f l y d e s c r i b e s the AIDS system, g i v i n g a sample t e r m i n a l s e s s i o n and an a n a l y s i s of the system from the user's viewpoint. [ G r i s 71b) Griswold, Ralph E.; Poage, J.F.; and Polonsky, I.P. The SNOBOL4 Programming !;§.______• P r e n t i c e - H a l l , 1971,"149-163. [ISBN 13-815373-6] Descr i b e s the language-provided debugging a i d s of the Snobol4 programming language, which i n c l u d e f u n c t i o n and v a r i a b l e t r a c i n g , and snap and postmortem dumping. References and Annotated B i b l i o g r a p h y 122 [ G r i s 75 ] Griswold, Ralph E. A portable d i a g n o s t i c f a c i l i t y f o r SN0BOL4. Software §.!<! Experience, 5:1 (1975 January-March), 93-104?" Desc r i b e s a language extension to the macro implementation of Snobol4 which a l l o w s the user to access the u n d e r l y i n g v i r t u a l machine. Such access can be used to a i d i n debugging the implementation, to w r i t e s u b r o u t i n e s t o analyze i n t e r n a l data s t r u c t u r e s f o r pedagogic reasons, and t o provide c a p a b i l i t i e s which are i l l e g a l under normal circumstances. (Habe 73] Habermann, A r i e N i c o l a s s . C r i t i c a l comments on the programming language P a s c a l . Agta I n f o r m a t i c a . 3 (1973), 47-57. [Hadj 76] Hadjioannou, Michael. Debugging of p a r a l l e l pro-grams. Proceedings o f l i n t i flasaii lalgrjaaMoaal Conference on System Sgienegs, Honolulu, Hawaii (1976 January) , 20-22, Proposes an extension to EXDAMS [ B a l z 69] s u p p o r t i n g the debugging of programs c o n t a i n i n g p a r a l l e l c o n t r o l s t r u c t u r e s . [ H a l l 75] H a l l , Wayne; and Davidson, James Edward. "The LISP L i b r a r y User's Manual". Department of Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1975 August, 35-56. Describes the debugging package a v a i l a b l e i n LISP/MTS a t the U n i v e r s i t y of B r i t i s h Columbia., The primary f a c i l i t i e s provided are c o n d i t i o n a l breakpoints on f u n c t i o n c a l l s , d i s p l a y and m o d i f i c a t i o n of the e v a l u a t i o n stack, the a b i l i t y to change the debugging r e f e r e n c e p o i n t , and the e v a l u a t i o n of any L i s p form i n c l u d i n g c a l l i n g the L i s p s t r u c t u r e e d i t o r . The package i s i n t e r a c t i v e and language-dependent., [ H a l p 65] Halpern, Mark. Computer programming: the debugging epoch opens. Computers and Automation, 14:11 (1965 November), 28-31. Discusses the need f o r bound checks on a l l numeric v a r i a b l e s , l i m i t s on t r a n s f e r s to prevent i n t e r r u p t s , checks on time c o n s t r a i n t s , and s o u r c e - l e v e l dumps. The author t h e o r i z e s t h a t debugging i s the next major h u r d l e to be surmounted i n computer s c i e n c e . [Hans 75] Hanson, David R. " A d d i t i o n s to the SITBOL Implemen-t a t i o n o f SNOBOL4 t o F a c i l i t a t e I n t e r a c t i v e Program Debugging".. T e c h n i c a l Report S4D51, Department of Computer S c i e n c e , U n i v e r s i t y of A r i z o n a , 1975 A p r i l . 26pp. References and Annotated B i b l i o g r a p h y 123 D e s c r i b e s e x t e n s i o n s to the S i t b o l implementation of Snobol4 which f a c i l i t a t e i n t e r a c t i v e debugging. Using these few language a d d i t i o n s , the author was able t o write an i n t e r a c t i v e debugging command package f o r Snobol4 i n Snobol4 i t s e l f . Great r e l i a n c e i s p l a c e d on t h e dynamic e v a l u a t i o n c a p a b i l i t i e s of the language (e.g., the CODE f u n c t i o n and computable b r a n c h i n g ) . (IBM 70] I n t e r n a t i o n a l Business Machines C o r p o r a t i o n . "IBM System/360 O p e r a t i n g System: PL/I (F) Language Refer-ence Manual". Order Number GC28-8201, Systems Refer-ence L i b r a r y , New York, NewYork, 1970 June. 445pp. [IBM 72] I n t e r n a t i o n a l B u s i n e s s Machines C o r p o r a t i o n . "IBM OS F u l l American N a t i o n a l Standard COBOL". Order Number GC28-6396-3, Systems Reference L i b r a r y , New York, New York, 1972 May, 326-330., De s c r i b e s extensions to ANSI standa r d c o b o l to allow programmers to i n c o r p o r a t e debugging statements d i r e c t l y i n t o t h e i r Cobol source programs. The f e a t u r e s provided i n c l u d e paragraph t r a c i n g , symbolic t r a c i n g of program i d e n t i f i e r s , and a p r i m i t i v e c o n d i t i o n a l breakpoint f a c i l i t y . . . . [ I nga 72] I n g a l l s , D a n i e l H.B. The execution time p r o f i l e as a programming t o o l . In (Rust 72], 107-128. S t r e s s e s the importance of p r o f i l e s t o a i d i n program debugging, t e s t i n g , and o p t i m i z a t i o n (with emphasis on the l a s t ) . The author l i s t s seven reasons why a l l language p r o c e s s o r s should c o n t a i n a p r o f i l e f a c i l i t y . [ I t o h 73 ] I t o h , D a i j u ; and I z u t a n i , Takao. FADEBUG-I, a new t o o l f o r program debugging, grocggdin.gs of the IEEE Symposium on Computer. Softwa£g SaliaMilitl# New, York, New York" (19*73 May)", 38-43. Descr i b e s a module-testing package which analyzes a l l l o g i c a l e x e c ution paths i n a program, accepts t e s t data and a n t i c i p a t e d r e s u l t s t o t e s t each path, and r e p o r t s any d i s c r e p a n c i e s between the a c t u a l and expected r e s u l t s . [ J ens 74] Jensen, Kathleen; and B i r t h , N i k l a u s . PASCAL User fianaai and Report. Lect u r e Notes i n Computer Science: S p r i n g e r - V e r l a g , 1974. 167pp. [ISBN 0-387-90144-2 and 3-540-90144-2] [John 78] Johnson, Mark S c o t t . "An Implementor»s Guide to RAIDE". T e c h n i c a l Manual TM-20, Department of Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1978 August. 46pp. References and Annotated B i b l i o g r a p h y 124 Contains d e t a i l s o f the OBC implementation o f RAIDE which are too t e c h n i c a l f o r t h i s t h e s i s . [J8ns 68] JOnsson, Sven Ingvar. O n - l i n e program debugging. BIT, 8 (1968), 122-127. Descr i b e s a g r a p h i c - d i s p l a y o n l i n e debugging system designed f o r machine-language programs using a d u a l - p r o c e s s o r d e d i c a t e d computer. The system can switch r e a d i l y from i n t e r p r e t i v e to n o n i n t e r p r e t i v e execution. [ J o s e 69] Josephs, W i l l i a m H. An o n - l i n e machine language debugger f o r OS/360. AFIPS Conference Proceedings, 35 (FJCC 1969), 179-186, D e s c r i b e s a r a t h e r standard machine-language debugging system named DYDE f o r use under OS/360 with an IBM 2260 g r a p h i c d i s p l a y t e r m i n a l . [Kemm 76] Kemmerer, Richard A. A SIMULA 67 debugging system. Proceedings of the Fourth I n t e r n a t i o n a l Confe t enee on the Design and Implementation of A l g o r i t h m i c Lan-guages? New York, New York l l 9 7 6 June) , 28-46?" Describes the design o f e x t e n s i o n s to the Simula 67 language t o f a c i l i t a t e debugging. , These i n c l u d e e x c e p t i o n h a n d l i n g , t r a c i n g , e x e c u t i o n p r o f i l e s , postmortem dumps, and run-time a s s e r t i o n s . [ K i r s 74] K i r s c h , Barry M. "An Improved E r r o r D i a g n o s t i c s System f o r , IBM System/360-370 Program Dumps". Master's T h e s i s : Department of Computer and Informa-t i o n S c i e n c e , Ohio State U n i v e r s i t y (Columbus), 1974 June. „. 60 pp. D e s c r i b e s a modified IBM System/360/370 core dump u s i n g ad hoc a n a l y s i s of program i n t e r r u p t s to suppress i r r e l e v a n t dump in f o r m a t i o n . [Knob 75] Knobe, Bruce S.; and Yuval, Gideon. Some steps towards a b e t t e r PASCAL. Computer Languages. 1:4 (1975) , 277-286. [Knut 71] Knuth, Donald E. An e m p i r i c a l study of FORTRAN programs. Software •— P r a c t i c e an4 E x g e r i e n c e . 1:2 (1971 A p r i l - J u n e ) , 10 5-133?" Presents the r e s u l t s of a study t o determine the programming h a b i t s of F o r t r a n programmers. The author uses the data obtained to s t r e s s the importance of program e x e c u t i o n p r o f i l e s i n debugging, t e s t i n g , and o p t i m i z a t i o n . References and Annotated B i b l i o g r a p h y 125 [Koch 69] Kocher, Wallace.. "A Survey of Current Debugging Concepts"* NASA C o n t r a c t o r Report CR-1397, Goddard Space F l i g h t Center, Greenbelt, Maryland, 1969 August. 91pp. [ (NTIS) N69-35613 ] Surveys the debugging a i d s a v a i l a b l e i n s e v e r a l systems, with only s h o r t mention of o n l i n e debugging technigues. [ K u l s 69] K u l s r u d , Helene E. HELPER: an i n t e r a c t i v e e x t e n s i b l e debugging system. Proceed incjs gf the Seco£d SlSfiosium on O perating Systems Principles« P r i n c e t o n U n i v e r s i t y (1969 October), 105-111. Describes HELPER, a machine-language i n t e r a c t i v e system used under the IDA CDC 6600 o p e r a t i n g system. The system i t s e l f c o n t a i n s f o u r p a r t s : an i n c r e m e n t a l command t r a n s l a t o r , a s i m u l a t o r , debugging r o u t i n e s , and a communicator. Language t r a n s l a t o r s must be modified to produce r e l e v a n t i n f o r m a t i o n . The system keeps a h i s t o r y f i l e and has backup c a p a b i l i t i e s . [ K u l s 71] Kulsrud, Helene E. Extending the i n t e r a c t i v e debug-gi n g system HELPER. In [Rust 71], 77-91. Reviews the m a t e r i a l presented i n [ K u l s 69] and d e s c r i b e s two r e c e n t improvements i n the system: an o n l i n e i n s t r u c t i o n system and an i n t e r f a c e e n a b l i n g F o r t r a n programs t o be debugged using the system. [Lamp 65] Lampson, B u t l e r W. , I n t e r a c t i v e machine language programming. AFIPS Conference Proceedings# 27:1 (FJCC 1965) , 473-481. [L e c a 75] Lecarme, O l i v i e r ; and D e s j a r d i n s , P i e r r e . More comments on the programming language P a s c a l . Acta I n f o r m a t i c a , 4 (1975) 4 231-243. [Ledg 75] Ledgard, Henry F., PE2_ramming Prove£bs. Hayden Book Company, 1975. 134pp. [ISBN 0-8^04-5522-6] Contains a s h o r t s e c t i o n on debugging t e c h n i g u e s : top-down debugging and language- and system-provided debugging a i d s . [Ledg 76) Ledgard, Henry F.; S i n g e r , Andrew; and Hueras, Jon. "A User's Guide to the PASCAL A s s i s t a n t " . T e c h n i c a l Report, U n i v e r s i t y of Massachusetts, 1976 June. 39pp. Describes an environment i n which P a s c a l programs can be d e v e l -oped, t e s t e d , and maintained. References and Annotated B i b l i o g r a p h y 126 [Leed 66] Leeds, Herbert D,; and Weinberg, Gerald M. Computer _ _ _ _ * _ i _ i _ 2 Fundamentals. McGraw-Hill Book Company, 1966, 358-395. Describes the machine-language and F o r t r a n debugging f a c i l i t i e s under the SHARE op e r a t i n g system f o r the IBM 7090. For both languages, the programmer must s p e c i f y debugging a c t i o n s a t t r a n s l a t i o n - t i m e t h r u language ex t e n s i o n s . [ L e s t 71a] L e s t e r , Bruce P. The c o s t of debugging. Proceedings _____ Fourth Hawaii I n t e r nat_2fl_I Conference on-System S c i e n c e s . Honolulu, Hawaii (1971 J a n u a r y ) , 713-715. A condensation of [ Lest 71b]. [ L e s t 71b] L e s t e r , Bruce P. "Cost A n a l y s i s of Debugging Systems". P r o j e c t MAC Report TR-90, Massachusetts I n s t i t u t e of Technology, 1971 September. 112pp. Develops a method f o r p r e d i c t i n g the c o s t of e i g h t i n t e r a c t i v e debugging system f e a t u r e s i n an implementation-independent manner. The author uses the Vienna D e f i n i t i o n Language to d e f i n e an a b s t r a c t machine on which the f e a t u r e s analyzed are run. To do t h i s he d e f i n e s a s e t of p r i m i t i v e a c t i o n s needed by an i n t e r a c t i v e debugging system. [Mann 73] Mann, George A. A survey of debug systems. H__ey_-_§11 Computer J o u r n a l , 7:3 (1973), 182-198. I d e n t i f i e s f i v e approaches to debugging: batch, i n t e r a c t i v e , i n t e r n a l , e x t e r n a l , and playback. The author l i s t s the d e s i r a b l e f e a t u r e s of a language-independent "debugging support system" and proposes a debugging language. A b r i e f d i s c u s s i o n of an implementation s t r a t e g y f o r such a system i s presented. [Marc 76 ] Marcotty, Michael; Ledgard, Henry F.; and Bochmann, Gregor V. A sampler of formal d e f i n i t i o n s . Comput-i n g Surveys, 8:2 (1976 June), 191-27 6. [Math 74] Mathis, Robert F. Teaching debugging. SIGCSJ B u l -l e t i n , 6:1 (1974 February), 59-63. Describes a course i n debugging technigues with a proposed s y l l a b u s , r e a d i n g l i s t , and p r o j e c t s l i s t . [Math 75] Mathis, Robert F. Flow t r a c e of a s t r u c t u r e d program, !SIGPLAN Noti c e s , 10:4 (1975 A p r i l ) , 33-37. Suggests that program e x e c u t i o n flow t r a c i n g f o r s t r u c t u r e d programs can be p r e t t y p r i n t e d to c l a r i f y the l o g i c a l flow of e x e c u t i o n and t h a t v a r i a b l e t r a c e s can be paragraphed t o d i s p l a y the scope of v a r i a b l e s . R e f e r e n c e s a n d A n n o t a t e d B i b l i o g r a p h y 127 [ M i l l 76a] M i l l e r , Alan. "OBC PL/1: Using PL/1 a t UBC". Computing Centre, U n i v e r s i t y of B r i t i s h Columbia, 1976 June. 80pp. [ M i l l 76b] M i l l s , Harlan D.„ Software Development. IEEE -; I r a n s -§Stigns on Software Snalneg.ring, SE-2:2 (1976 December) , 265-273. ~ [Moor 75] Moore, C.G., I I I ; Wqrona, Steven L.; and Conway, Richard g a i t e r . "PL/CT — A Terminal Ve r s i o n of PL/C". T e c h n i c a l Report 75-259, Department of Computer Science, C o r n e l l U n i v e r s i t y , 1975 September. 7pp. Describes a v e r s i o n of P L/C designed f o r use on an IBM 2741 t y p e w r i t e r t e r m i n a l running under the o p e r a t i n g system CMS. A l i m i t e d subset of P L / C - l i k e statements can be entered at run-time as commands; source program changes r e g u i r e r e t r a n s l a t i o n . [Morg 71] Morgan, Howard L.; and Wagner, Robert A. PL/C: the design o f a high-performance compiler f o r PL/I. AFIPS Conference £roceedings, 38 (SJCC 1971), 503-510. Describes the design c r i t e r i a and implementation of the diagnos-t i c PL/I t r a n s l a t o r PL/C. [ Moul 67] Moulton, P.G.; and M u l l e r , M. E. DITRAN — a compiler emphasizing d i a g n o s t i c s . Communications ojf tJig ACH, 10: 1 (1967 January) , 45-52. Describes the DITRAN n o n i n t e r a c t i v e debugging system, which aims t o d e t e c t a l l n o n l o g i c a l e r r o r s w i t h i n F o r t r a n programs. T h i s i s accomplished by m a i n t a i n i n g run-time c o n t r o l b l o cks f o r each v a r i a b l e to check i n i t i a l i z a t i o n , type e r r o r s , and range e r r o r s , and by maintaining run-time t a b l e s o f source program statement o f f s e t s and i d e n t i f i e r s . The system c o n t a i n s a use monitor and some f a c i l i t i e s t o enhance s t u d e n t - o r i e n t e d computing. [ORei 76] 0»Reilly, Dennis. "UBC IF: The I n t e r a c t i v e FORTRAN Manual". Computing Centre, U n i v e r s i t y of B r i t i s h Columbia, 1976 September. 121pp. De s c r i b e s an i n t e r a c t i v e , i n t e r p r e t i v e F o r t r a n language proces-sor a v a i l a b l e under the MTS o p e r a t i n g system on an IBM System/360/370. E x t e n s i v e language-dependent debugging a i d s are provided, i n c l u d i n g run-time source statement m o d i f i c a t i o n , v a r i a b l e and parameter checks, br e a k p o i n t s , and subroutine i n v o c a t i o n t r a c e s . Programmable breakpoints provide some degree of system e x t e n d a b i l i t y . References and Annotated B i b l i o g r a p h y 128 [Orga 73] Organick, E l l i o t I r v i n g . Com-puter System Organiza-t i o n : The B5700/B6700 S e r i e s . ACM Monograph S e r i e s : Academic P r e s s , 1973. 132pp. [ISBN 0- 12-528250-8 ] [Palm 77] Palme, Jacob. SIM DDT — f o r c o n v e r s a t i o n a l debugging of SIMULA programs. Simula _ej£sle_tte_£, 5:2 (1977 May) , 13-16. B r i e f l y d e s c r i b e s the DECsystem^-10 Simula debugging system (SIMDDT). Altho the system r e q u i r e s the t r a n s l a t o r to generate s p e c i a l t a b l e s , l i t t l e run-time overhead i s r e q u i r e d u n l e s s an e r r o r i s d e t e c t e d . , [Panz 76] P a n z l , David J . T e s t procedures: a new approach to software v e r i f i c a t i o n . Proceedings o f the Second I n t e r n a t i o n a l Conference on Software E n g i n e e r i n g , San F r a n c i s c o , C a l i f o r n i a (1976 Octoberf, 477-485." Presents the concept of a t e s t procedure, a formal s p e c i f i c a t i o n of t e s t cases to be a p p l i e d t o one or more t a r g e t program modules. A T e s t Procedure Language (TPL) i s d e f i n e d and an implemented system employing i t f o r F o r t r a n programs i s d e s c r i b e d . £Pask 73] Pasko, Henry John. "A Pseudo-Machine f o r Code Gen-e r a t i o n " . T e c h n i c a l Report CSRG-30, Computer Systems Research Group, U n i v e r s i t y of Toronto, 1973 December. 91pp. [Peck 75] Peck, John E.L. "The Essence of Computer Science". T e c h n i c a l Manual TM-7, Department of Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1975 October, 47pp. [ P i e r 74] P i e r c e , R.H. Source language debugging on a small computer. Computer J o u r n a l . 17:4 (1974 November), 3 1 3 - 3 1 7 . . , " " " " ' . Descr i b e s the DDS (Dynamic Debugging-Source) i n t e r a c t i v e system f o r the C o r a l 66 programming language on the Argus 700 s m a l l -s c a l e computer. Using t r a n s l a t e d code, the system can s e t b r e a k p o i n t s , resume ex e c u t i o n , examine and a l t e r v a r i a b l e s and a b s o l u t e l o c a t i o n s , and a l t e r the source program. A l t e r a t i o n s can be done using only a subset of C o r a l s i n c e the f u l l t r a n s l a t o r i s not a v a i l a b l e d u r i n g debugging. [ P o l l 77] P o l l a c k , Bary B i l l i a m ; and F r a l e y , Robert A. "PASCAL/UBC User's Guide". T e c h n i c a l Manual TM-2, Department of Computer Sci e n c e , U n i v e r s i t y of B r i t i s h Columbia, 1977 November. 54pp. References and Annotated B i b l i o g r a p h y 129 [ P o o l 73] P o o l e , P.C. Debugging and t e s t i n g . In [Baue 73], 278-318. Presents a s h o r t t u t o r i a l on program debugging and c u r r e n t debugging techniques. A l i s t of d e s i r a b l e f e a t u r e s of an i n t e r a c t i v e debuqqing system i s presented. [ P u l l 69] Pullam, John S. "An Object-time D i a g n o s t i c F a c i l i t y f o r H i g h - l e v e l Languages". Master's T h e s i s : Depart-ment of E l e c t r i c a l E n g i n e e r i n g , U n i v e r s i t y of Toronto, 1969. 155pp. Describes a n o n i n t e r a c t i v e debugging system f o r PL/I programs implemented by s i m u l a t i n g a debugging-oriented v i r t u a l machine named POODL, The system depends on language e x t e n s i o n s to provide flow and v a r i a b l e t r a c i n g . [ P y l e 7 1 ] P y l e , I . e . ; McLatchie, R.C.F.; and Gran da ge, B, A second-order bug with delayed e f f e c t . Software — P r a c t i c e and Experience, 1:3 ( 1 9 7 1 July^September), 2 3 1 - 2 3 3 7 R e l a t e s an e x p e r i e n c e demonstrating the d i f f i c u l t y of t r a c k i n g down a software bug when the u n d e r l y i n g machine a r c h i t e c t u r e does not provide s u f f i c i e n t b u i l t - i n operand e r r o r d e t e c t i o n . [ R a i n 73 ] Rain, Mark. Two unusual methods f o r debugging system software. Software -- P r a c t i c e and Experience, 3:1 (1973 January-March), 61-63. Describes two technigues f o r t e s t i n g software: the bug farm -- a program which accepts a, v a l i d program f o r the system being t e s t e d as input and which outputs t h i s program i n a randomly scrambled form, and the bug c o n t e s t -- paying users a bounty to d i s c o v e r and r e p o r t bugs i n a new system. [ R e i s 75] R e i s e r , John F. " B A I L — A Debugger f o r SAIL". T e c h n i c a l Report STAN-CS-75-523, Computer Science Department, S t a n f o r d U n i v e r s i t y , 1975 October. 24pp., Describes BAIL, a language-dependent, i n t e r a c t i v e debugging system f o r S a i l programs running under e i t h e r the TENEX or the TOPS-10 o p e r a t i n g system on a DECsystem-10. When a breakpoint occurs, any of the f o l l o w i n g a c t i o n s i s permitted: a simple S a i l e x p r e s s i o n can be e v a l u a t e d , a user or system procedure can be c a l l e d , an assignment can be made, or a BAIL command can be executed. Only a few system commands are supported; t r a c i n g and the s e t t i n g of breaks are handled by procedure c a l l s . A l t ho code generation changes are not r e g u i r e d , the t r a n s l a t o r must supply BAIL with d e s c r i p t i o n s o f a l l v a r i a b l e s , procedures, and statements. References and Annotated B i b l i o g r a p h y 130 Richards, Martin. BCPL; a t o o l f o r c o m p i l e r w r i t i n g and system programming. AFIPS Qonfe^ence Proceed-i n g s . 34 (SJCC 1969) , 557-566. Richards, Martin; Peck, John E.L.; and Manis, Vincent Stewart. "The BCPL Programming Manual". T e c h n i c a l Manual TM-10, Department of computer S c i e n c e , U n i v e r s i t y of B r i t i s h Columbia, 1977 December. 62pp. Ru s t i n , R a n d a l l {editor).,/ Debugging Techniques i n _____ Systems.: P r e n t i c e - H a l l , 1971. 148pp. f i s i N 0-13-197319-3) Contains a number o f papers r e l a t e d to debugging which were presented a t a Courant I n s t i t u t e symposium i n 1970. E s p e c i a l l y r e l e v a n t are [ G r i s 71a], [ K u l s 71], and [ B l a i 71]. [Rust 72] R u s t i n , R a n d a l l ( e d i t o r ) . Design and O p t i m i z a t i o n of Compilers. P r e n t i c e - H a l l , 1972. 141pp. [ISBH 0-13-200204-3] [Sack 68] Sackman, H. Time-sharing versus batch p r o c e s s i n g : the experimental evidence. AFIPS Conference Pro-ceed i n g s , 32 (SJCC 1968), 1-10. Summarizes the arguments f o r and a g a i n s t t i m e - s h a r i n g and batch p r o c e s s i n g . By comparing f i v e p r e v i o u s s t u d i e s , the author concludes t h a t time-shared p r o c e s s i n g r e s u l t s i n g r e a t e r programmer p r o d u c t i v i t y and program q u a l i t y . , [ S a t t 72] S a t t e r t h w a i t e , Edwin H a l l o w e l l , J r . Debugging t o o l s f o r hiqh l e v e l languages,, Software P r a c t i c e and Experience, 2:3 (1972 July-September) , 197-2V7, Des c r i b e s a m o d i f i c a t i o n to the A l g o l - B t r a n s l a t o r which pr o v i d e s run-time symbolic t r a c e s , frequency count i n f o r m a t i o n , and a postmortem dump. These f a c i l i t i e s must be requested a t t r a n s l a t i o n - t i m e and are language-dependent. The paper des-c r i b e s the implementation and c o n t a i n s s t a t i s t i c s concerning the overhead of the debugging f a c i l i t i e s . [ S a t t 75) S a t t e r t h w a i t e , Edwin H a l l o w e l l , J r . Source Language Debugging T o o l s . D o c t o r a l D i s s e r t a t i o n : Computer Science Department, S t a n f o r d U n i v e r s i t y , 1975 May. 338pp. [UMI order number 75-25,602 and T e c h n i c a l Report STAN-CS-75-494 ] E l a b o r a t e s on the m a t e r i a l presented i n [ S a t t 72] and provides e x c r u c i a t i n g d e t a i l s of the implementation. [ R i c h 69] [ R i c h 77] [Rust 71] References and Annotated B i b l i o g r a p h y 131 [Schw 71] Schwartz, Jacob T. An overview of bugs. In [Rust 71], 1-16. Gives a broad overview of program bugs and the debugging process. The author advocates debugging languages which are " e v e n t - o r i e n t e d " , t h a t i s , which c o n s i d e r time to be an important component of the debugging process (e.g.. What was the value of z the f i r s t time t h a t x was gr e a t e r than y?) . (Scow 72] Scowen, R.S. "Debugging Computer Programs •— A Survey with S p e c i a l Emphasis on ALGOL". Report NAC-21, N a t i o n a l P h y s i c a l Laboratory, Teddington, England, 1972 June. 36pp. [ (NTIS) N73-11189 ] B r i e f l y d i s c u s s e s p r i n c i p l e s of debugging, but i s p r i m a r i l y concerned with benchmarking the e r r o r d i a g n o s t i c f a c i l i t i e s of many A l g o l 60 t r a n s l a t o r s . The author d i s t i n g u i s h e s between a c t i v e debugging ( r e q u i r i n g user i n t e r v e n t i o n ) and passive debugging (automatic i n t e r v e n t i o n by the system). [ S e i d 68] S e i d e l , Kenneth P. Debugging past and present. Software Age, (1968 August), 22,24,26-28. Surveys the debugging c a p a b i l i t i e s under OS/360 f o r programs w r i t t e n i n assembly language, Cobol, F o r t r a n , and PL/I. ( S i t e 71] S i t e s , R i c h a r d L. "ALGOL-w Reference Manual". Tech-n i c a l Report STAN-CS-71-230, Computer Science Depart-ment, Stanford U n i v e r s i t y , 1971 August.,, 169pp. [Step 74] Stephens, P. D. The IMP language and compiler. Com-puter J o u r n a l , 17:3 (1974 August), 216-223. B r i e f l y mentions t h a t the EMAS t r a n s l a t o r f o r IMP c o n t a i n s a debugging o p t i o n which causes code to be generated t o check f o r such run-time c o n d i t i o n s as undefined v a r i a b l e s and assignment t r u n c a t i o n , and s p e c i a l code to f a c i l i t a t e a postmortem dump i n source language terms., [ S t o c 65] Stockham, Thomas G., J r . Some methods of g r a p h i c a l debugging. Proceedings of the J.BM S c i e n t i f i c Comput-i n g Sy.rapjDsium on Man,-Machine Commun.Isatisa# Yorktown Heights? New~York (1965~May)7 57-71." Desc r i b e s an e a r l y machine-language g r a p h i c d i s p l a y debugging system which can produce core dumps i n o c t a l and can d i s p l a y the dynamic e x e c u t i o n flow of programs as e i t h e r graphs or flow-c h a r t s . Nongraphic aspects o f the system are not d i s c u s s e d . [ S t o c 67] Stockham, Thomas G. , J r . Report on the working conference on o n l i n e debugging. Communications of the ACM, 10:9 (1967 September), 590-592. References and Annotated B i b l i o g r a p h y 132 Advocates the development o f " i n t e g r a t e d programming systems". The conference centered on how machine-language debugging t e c h -nigues can be a p p l i e d t o h i g h - l e v e l languages. [ S t r u 74] Strunk, W i l l i a m , J r . ; and White, E.B. Th.e Ilemejats 2_ ____§« Macmillan, 1959. 71pp. [ T e i t 69] Teitelman, Warren. Toward a programming l a b o r a t o r y . __________ of the I n t e r n a t i o n a l J o i n t Conference on A r t i f i c i a l I n t e l l i g e n c e . Washinqton, D.C. (1969 Hay), 1-8a. Describes the PILOT system at BBN which c o n t a i n s an automatic s p e l l i n g c o r r e c t i o n system (DWIM), an e d i t i n g package, a break-p o i n t package, and an " a d v i s i n g f a c i l i t y " which a l l o w s the i n t e r f a c e s between modules to be modified e a s i l y . The author s t r e s s e s the importance of keeping an execution h i s t o r y , pro-grammable b r e a k p o i n t s , and the user i n t e r f a c e . [Text 78] Texture Support Group. "Texture User's Manual". T e c h n i c a l Manual TM-8, Department of Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1978 Janu-ary. 59pp. [Thorn 76] Thomson, CM. E r r o r c h e c k i n g , t r a c i n g , and dumping i n an ALGOL 68 checkout compiler. Proceedings of t]je f o u r t h I n t e r n a t i o n a l Conference on the Design and Implementation of A l g o r i t h m i c Languages, New York, New~York (1976 June), 93-98. Descr i b e s the run-time checks r e g u i r e d of A l g o l 68 programs and the f a c i l i t i e s provided by the FLASC d i a g n o s t i c t r a n s l a t o r f o r f u l l - l a n g u a g e A l g o l 68, which i n c l u d e a l l of the standard c a p a b i l i t i e s except v a r i a b l e t r a c i n g . [OWM 73] U n i v e r s i t y o f Wisconsin at Madison. "OLDS Reference Manual f o r the 1110". Academic Computing Center, U n i v e r s i t y of Wisconsin at Madison, 1973 February. 20pp. De s c r i b e s an o n l i n e debugging system f o r the Univac 1110. Altho designed f o r debugging machine-language and F o r t r a n programs, the system i t s e l f p r o v i d e s a debugging language a l l o w i n g f o r f u n c t i o n d e f i n i t i o n s , l i s t m anipulations i n the s t y l e of L i s p , and the u s u a l b r e a k p o i n t and machine-level debugging f a c i l i t i e s . [Vand 74] van den Bosch, Peter Nico. "The Design and Implemen-t a t i o n of a Document Processor". Master's T h e s i s ; Department of Computer Science, U n i v e r s i t y of B r i t i s h Columbia, 1974 October. 157pp. R e f e r e n c e s a n d A n n o t a t e d B i b l i o g r a p h y 133 [VanT 74 ] Van T a s s e l , Dennie L. £rogram S t j l e , Design, E f f i c i e n c y . * Debugging* and T e s t i n g . P r e n t i c e - H a l l , 7974, 117-165. [ISBN 0-13-729939-7] Presents a g e n e r a l d i s c u s s i o n of debugging, ways of d e t e c t i n g and p r e v e n t i n g bugs, and a taxonomy of bugs and t h e i r causes. Only a s u p e r f i c i a l d i s c u s s i o n of automated debugging a i d s i s presented. van Wijngaarden, Aad; M a i l l o u x , Barry J • ; Peck, John E.L.; Ko s t e r , C o r n e l l s H.A.; S i n t z o f f , M i c h e l ; Lindsey, C.H.; Meertens, Lambert G.L•T.; and F i s k e r , R.G. ( e d i t o r s ) . Revised Report on the A l g o r i t h m i c Language A l g o l 68. S p r i n g e r - V e r l a g , 1976. 236pp. [ISBN 3-540-07592-5 and 0-387-07592-5 ] Venema, T j e e r d . "TRUST User's Guide". Department of Computer S c i e n c e , U n i v e r s i t y of B r i t i s h Columbia, 1976 August. 65pp. ver Steeg, R.L. TALK — a h i g h - l e v e l source language debugging technique with r e a l - t i m e data e x t r a c t i o n . Communications of the. ACM, 7:7 (1964 J u l y ) , 418-419. B r i e f l y d e s c r i b e s the TALK (Take A LooK) debugging system which i s executed as a f o u r step process: t r a n s l a t i o n of the user program, t r a n s l a t i o n o f TALK commands, program e x e c u t i o n , and TALK debugging output e d i t i n g . Implemented f o r the CS-1 pro-gramming language, no s p e c i a l code i s produced by the t r a n s l a t o r a l t h o a symbol t a b l e must be generated. The system a l l o w s o n l y f o r c o n d i t i o n a l v a r i a b l e t r a c e s . [ V i c t 76a] V i c t o r , Kenneth E. "The Design and Implementation of DAD, a M u l t i - P r o c e s s , Multi-Machine, Multi-Language, I n t e r a c t i v e Debugger 1'. Augmentation Research Center, SRI I n t e r n a t i o n a l , Menlo Park, C a l i f o r n i a , 1976 August. 51 pp. Describes a debugging system design which supports the debugging of multiprogrammed software, the components o f which may be w r i t t e n i n d i f f e r e n t h i g h - l e v e l languages and t r a n s l a t e d and running on machines of v a r y i n g a r c h i t e c t u r e s . , DAD i s being implemented i n the N a t i o n a l Software Sorks network environment. A l t h o designed as a h i g h - l e v e l , symbolic debugging system, the debugging commands themselves are f a i r l y l o w - l e v e l and resemble those of machine-language debugging systems. T h i s r e p o r t a l s o c o n t a i n s a b r i e f but u s e f u l h i s t o r y of debugging. ( V i c t 76b] V i c t o r , Kenneth E. "User's Guide to DAD". Augmenta-t i o n Research Center, SRI I n t e r n a t i o n a l , Menlo Park, C a l i f o r n i a , 1976 September. 74pp. [VanH 76 ] [Vene 76] [ V e r s 64] References and Annotated B i b l i o g r a p h y 134 E x p l a i n s the p r i m i t i v e commands o f DAD. The command language i s not uniform due t o the l a r g e number of o p t i o n s a p p l i c a b l e and s p e c i f i c t o each command. The language i s a l s o l o w - l e v e l i n t h a t i t makes e x t e n s i v e use of s p e c i a l symbols and uses a p o s i t i o n a l , a s s e m b l e r - l i k e command format. The a b i l i t y to "program" the s p e c i a l symbols a l l o w s the user t o t a i l o r somewhat the command language t o resemble a p a r t i c u l a r host source language,. [ V i c t 77] V i c t o r , Kenneth E. The design and implementation of DAD, a m u l t i p r o c e s s , multimachine, multilanguage i n t e r a c t i v e debugger. Proceedings of t h e Tenth ______ I n t e r n a t i o n a l Conference on System S c i e n c e s , Honolulu, Hawaii (1977 January),~196-199. A condensation of [ V i c t 76a], [Watt 74] Watt, J.M. ; Peck, John E.L. ; and S i n t z o f f , M ichel. Revised ALGOL 68 syntax c h a r t . SIGPLAN N o t i c e s , 9:7 (1974 Ju l y ) , 39. [ Wein 71] Weinberg, Gerald M. , The Psychology, of Computer Pro-gramming. Computer Science " s e r i e s : " Van ~ 5 ostrand Reinhold Company, 1971. 288pp. [ISBN 0-442-29264-3] [Wexe 76] Wexelblat, Richard L. Haxi e r s , or how to design l a n as d i f f i c u l t as p o s s i b l e . _____________ Conference on F r a n c i s c o , C a l i f o r n i a {1976 ms f o r malfeasant design-guages t o make programming £&_________ of the Second Software E n g i n e e r i n g , San October) , 3 31-336?" [ W i l e 74] Wilcox, Bruce; Hafner, C a r o l e ; Friedman, Paul; H a l l , Wayne; McDonald, David B l a i r ; and Davidson, James Edward. "The LISP/MTS User's Guide". T e c h n i c a l Manual TM-16, Department of Computer Sci e n c e , U n i v e r s i t y of B r i t i s h Columbia, 1974 September, 6 5-74. D e s c r i b e s the language-provided debugging a i d s of the LISP/MTS system a t the U n i v e r s i t y of B r i t i s h Columbia, which i n c l u d e an e v a l u a t i o n s t a c k dump, f u n c t i o n t r a c i n g , step e x e c u t i o n , a form of r everse program e x e c u t i o n , and the e v a l u a t i o n of a r b i t r a r y L i s p forms. [ W i l e 76] Wilcox, Thomas R.; Davis, Alan Mark; and T i n d a l l , Michael H. The design and implementation of a t a b l e d r i v e n , i n t e r a c t i v e d i a g n o s t i c programming system. Communications of the ACM, 19:11 (1976 November), 609-616. References and Annotated B i b l i o g r a p h y 135 P r o v i d e s an overview with examples of CAPS, an i n t e r a c t i v e d i a g n o s t i c t r a n s l a t o r / i n t e r p r e t e r t h a t a l l o w s beginning programmers to prepare, debug, and execute simple programs a t a PLATO IV d i s p l a y t e r m i n a l . CAPS a u t o m a t i c a l l y diagnoses (but does not c o r r e c t ) e r r o r s both at t r a n s l a t i o n - and run-time by reverse program e x e c u t i o n and i n t e r a c t i o n with the user. The system supports programs w r i t t e n i n F o r t r a n , c o b o l , and PL/I. [Wino 75] Hinograd, T e r r y . Breaking the complexity b a r r i e r again. S IG PL AW Hot i c e s, ,10:1 (1975 January), 13-30. Proposes t h a t what i s needed to break the present "complexity b a r r i e r " i n software development i s an i n t e g r a t e d programming system capable of r e l i e v i n g many of the programmer's t e d i o u s burdens, such as debugging. (Wolm 72 ] Wolman, B.L. Debugging PL/I programs i n t h e M u l t i c s environment. AFIPS Conference Proceedings, 41:1 (FJCC 1972), 507-5147 Mentions the language extensions and system f a c i l i t i e s of M u l t i c s PL/I f o r program debugging. The system provides, without the use of a s p e c i a l debugging t r a n s l a t o r , patching i n source language terms, c o n d i t i o n a l b r e a k p o i n t s , breakpoint s u b r o u t i n e s , t r a c i n g of procedure c a l l s , and p r o f i l e s of program execu t i o n . [Wort 72] Wortman, David Barkley. "A Study o f Language D i r e c -te d Computer Design". T e c h n i c a l Report CSBG-20, Computer Systems Research Group, U n i v e r s i t y of Toronto, 1972 December. 207pp. Wulf, W i l l i a m ; and Shaw, Mary. G l o b a l v a r i a b l e c o n s i d e r e d harmful. SIOPLAf t Q t i c e s , 8:2 (1973 F e b r u a r y ) , 28-34. Z e l k o w i t z , Marvin V. R e v e r s i b l e E x e c u t i o n as a D i a g n o s t i c T o o l . D o c t o r a l D i s s e r t a t i o n : Department of Computer Science, C o r n e l l U n i v e r s i t y , 1971 Janu-ary. 149pp. (UMI order number 71-17,676] Des c r i b e s an e x t e n s i o n to t h e PL/C language and t r a n s l a t o r which all o w s batch programs t o be executed i n reverse when an e r r o r i s detected, Altho the author summarily dismisses o n l i n e e n v i r o n -ments, he advocates the use o f e x t e n s i v e i n t e r r u p t f a c i l i t i e s t o a i d i n program debugging and proposes hardware e x t e n s i o n s to a i d debugging. [Wulf 73] [ Z e l k 71] References and Annotated B i b l i o g r a p h y 136 [ Z e l k 73] Z e l k o w i t z , Marvin 7. R e v e r s i b l e execution. Communi-c a t i o n s o f the ACM, 16:9 (1973 September) , 566. A condensation of f Zelk 71], [Zimm 67] Zimmerman, Luther L. O n - l i n e program debugging — a gr a p h i c approach. Computers and Automation, 16:10 (1967 November), 30-31,34. ~ B r i e f l y d e s c r i b e s GBUG, a gr a p h i c d i s p l a y o n l i n e debugging system f o r machine-language programs. The author c l a i m s that speed of i n f o r m a t i o n d i s p l a y i s the . primary advantage of a graphic debugging system. 137 Appendix A. RAIDE System F u n c t i o n s 1., Status Functions CALLER (foo) r e t u r n s a s p e c i f i c v alue i d e n t i f y i n g the segment which caused e n t r y i n t o the se g m e n t - s p e c i f i c 'foo'. COMMENT(n,foo) r e t u r n s the 'n'-th comment of the s e g m e n t - s p e c i f i c *foo» as a c h a r a c t e r s t r i n g . The n u l l s t r i n g i s re t u r n e d i f th e r e i s no 'n'-th comment. CURRENT_EXCEPTION r e t u r n s the name (as a c h a r a c t e r s t r i n g ) of the c u r r e n t l y a c t i v e e x c e p t i o n . The n u l l s t r i n g i s returned i f the r e i s no c u r r e n t l y a c t i v e e x c e p t i o n . DEBUG_LEVEL r e t u r n s an i n t e g e r i n d i c a t i n g the c u r r e n t l e v e l of debug-ging support i n e f f e c t . (See Table VI f o r the range of r e s u l t values.) DECLARATION_LIST(n) r e t u r n s a d a t a - s p e c i f i c value i d e n t i f y i n g the 'n'-th most r e c e n t l y d e c l a r e d t o p - l e v e l debugging v a r i a b l e or procedure. DEFERRED_ACTION_LIST (n) r e t u r n s a s e g m e n t - s p e c i f i c value i d e n t i f y i n g the ••"n'-th most r e c e n t l y d e f e r r e d a c t i o n . n=0 i d e n t i f i e s t he cu r -r e n t l y a c t i v e d e f e r r e d a c t i o n , i f the r e i s one. DEFINED (foo) r e t u r n s l o g i c a l t r u e i f the d a t a - s p e c i f i c <foo» c u r r e n t l y has a value; f a l s e i s returned otherwise. ENVIRONMENTALIST (n) r e t u r n s the name (as a c h a r a c t e r s t r i n g ) of the 'n'-th most r e c e n t l y saved environment. n=0 r e t u r n s the name of the c u r r e n t l y a c t i v e environment, i f t h e r e i s one. The n u l l s t r i n g i s returned i f there i s no 'n'-th a c c e s s i b l e environment. LANGUAGE (f OO) r e t u r n s the name (as a c h a r a c t e r s t r i n g ) of the source language i n which the segment-specific 'foo' was w r i t t e n . RANGE (foo, m, n) r e t u r n s a ge n e r i c value i d e n t i f y i n g a subrange o f the g e n e r i c 'foo' between 'm' and *n*. Appendix A. RAIDE System Functions 138 REFERENCE_POINT r e t u r n s a s e g m e n t - s p e c i f i c value i d e n t i f y i n g the c u r r e n t r e f e r e n c e point. TYPE (foo) r e t u r n s the type (as a c h a r a c t e r s t r i n g ) of the data-s p e c i f i c * foo'. VALUE (foo) r e t u r n s the c u r r e n t value of the segment- or d a t a - s p e c i f i c •foo'. A g u e s t i o n mark i s returned i f 'foo' i s c u r r e n t l y undefined. 2. D i s p l a y Format F u n c t i o n s LINE(n) causes the output d i s p l a y device t o be advanced *n* l i n e s , (The argument i s o p t i o n a l and d e f a u l t s t o 1.) PAGE causes the output d i s p l a y device to be advanced t o the beginning of a new page. SPACE(n) causes the output d i s p l a y device t o be spaced over 'n* spaces. I f spa c i n g f i l l s the d i s p l a y b u f f e r , i t i s d i s p l a y e d and the output d i s p l a y d e v i c e i s advanced one l i n e . (The argument i s o p t i o n a l and d e f a u l t s t o 1.) TAB (n) causes the output d i s p l a y device to be tabbed t o column •n' of the c u r r e n t (or subseguent) l i n e . 3. A n a l y s i s Functions #ACCESSES (foo) r e t u r n s the number of times the d a t a - s p e c i f i c 'foo' has been accessed s i n c e system i n i t i a l i z a t i o n . #ALLOCATIONS(type) r e t u r n s the number of times dynamic a l l o c a t i o n s of type 'type' have been made s i n c e system i n i t i a l i z a t i o n . , #ENTRIES(foo) r e t u r n s the number of times the se g m e n t - s p e c i f i c 'foo* has been entered s i n c e system i n i t i a l i z a t i o n . #EXITS(foo) r e t u r n s the number o f times the s e g m e n t - s p e c i f i c •foo* has been e x i t e d s i n c e system i n i t i a l i z a t i o n . Appendix A. EAIDE System F u n c t i o n s 139 #OPDATES ( f o o ) r e t u r n s the number of times the d a t a - s p e c i f i c *foo* has been updated s i n c e system i n i t i a l i z a t i o n . 4 . language-Dependent System F u n c t i o n s CDBEENT_segment-generic r e t u r n s a s p e c i f i c value i d e n t i f y i n g the c u r r e n t l y executing segment o f type 1 segment-generic*. 140 Appendix B. D i s p e l Syntax C h a r t Legend; t — I r—i ""™ " — T " 1 r i —» 1 I |AH> B A i s d e f i n e d as | |A| choose one of A, B, 1 I M e i t h e r B, c, or D | IB J or C J I 1—> C 1 |C| 1 1 * 1 .... D 1 _ „, ,. „ i i - J 1 — --—1 1 A | B A, ABA, ABABA,, . } abc abc i s o p t i o n a l 1 1 +- + J .„ - • ;, i . 1 (A B) t r e a t A and B as one c o n s t r u c t 1 J I u t t e r a n c e ! ' i — — ' i 1 f->|explanation J—> e x p l a i n keyphrase « 1 I — > l i n g u i r y l — > i n q u i r e sentence T~ ~9 r i J~-> ! d e c l a r a t i o n t—>I i n t e g e r I ( expression ) i d ! , L — , — — 1 j s p e c i f i c \ + — - ; + I—> I d e f i n i t i o n | ' i 1 I *—> d e f i n e i d ( d e c l a r a t i o n ! ; ) as command . +-—' —. -+ i 1 r — T ->!command H-> i d : IwhenJ a c t i o n 1 + — - + L — , — a — r i + f—+ |when c o n d i t i o n | ' ——>!on exception!, 1 |.before s p e c i f i c - i n c i d e n t ! >| ! a f t e r s p e c i f i c - i n c i d e n t ! , | appendix B. D i s p e l Syntax Chart 141 I a c t i o n ) » I H> begin d e c l a r a t i o n ! ; ; command!; end _ + + k~> break message + + H-> c a l l i d ( e x p r e s s i o n ! , ) + ; — *. H-> c a n c e l v a r i a b l e ! , •«•— + •—> display. {expression as type}!, on file-name r •» J e x p r e s s i o n segment-generic! k—> execute J *• — • j IsMlS c o n d i t i o n \ i. j + ' — . • _ _ + J~> f o r s p e c i f i c ! , -> i d do a c t i o n I i—> i f c o n d i t i o n then a c t i o n e l s e a c t i o n f i + . « — , + t—> i n p u t file-name + + H> suit message * v — + t — > r e f e r e n c e v a r i a b l e + *. H-> r e s t o r e file-name s a v i n g file-name + — _ _ -—+ H> save file-name I 1—> s e t v a r i a b l e t o e x p r e s s i o n I H> sk|.p segment-generic . — • . I—> system system-command + _ > -> while c o n d i t i o n do a c t i o n Appendix B. D i s p e l Syntax Chart 142 I s p e c i f i c - i n c i d e n t | J *—>| s p e c i f i c j g e n e r i c - i n c i d e n t i _ 1 + + I t—> v a r i a b l e *—> §.___ generic Isegment-gualifierj + - - + ~_——; ; i •—-> i n variab 1 e I ~ * — : : — I I g e n e r i c - i n c i d e n t J I rr. t I I en t ry. j *—>lexit | Jaccess) I update| I I v a r i a b l e | «—r- - — J i : : — — — a -> g e n e r i c : j u n g u a l i f l e d - v a r i a b l e | s e g m e n t - g u a l i f i e r .+ . _ + i — j — — _ _ j . — — ^ I ! *—> {id ( e x p r e s s i o n | , )H» • • — • • - - - + . nonterminals r e p r e s e n t e d by s t r i n g l i t e r a l s : f i le-name, keyphrase, message, sentence, system-command nonterminals r e p r e s e n t e d by i d e n t i f i e r s : e x c e p t i o n , g e n e r i c , segment-generic, type l e x i c a l l y p r i m i t i v e nonterminals: i d , i n t e g e r , r e a l , s t r i n g Appendix B. D i s p e l Syntax Chart 143 I c o n d i t i o n | — — i I * ~ > I l o g i c a l - t e r m | or c o n d i t i o n , r _ — i »~>| l o g i c a l - f a c t o r I and l o g i c a l - t e r m * i — » + I I 1 ; 1 1—> not ( l o g i c a l - p r i m a r y | +-+ i — r __ _—, 1 I r I K I I 1^1 «--> e x p r e s s i o n | = | l o g i c a l - p r i m a r y 1*1 l>l L J • ---r— ••—: "1 Iexpression| * ~ r --• I r - i h-> term |*| ex p r e s s i o n I. + l - l I «- J I I t -j t 1 r i «—>|termJ—>| f a c t o r | |*| i 1 » J/J term I «- J I + ' * I J—> v a r i a b l e I |~> i n t e g e r I I—> r e a l I i—> s t r i n g I 1—> { ex p r e s s i o n 144 A p p e n d i x C . SPAM D e s c r i p t o r F o r m a t s I : " — — ~ : 1 ' I SD i ^ 1 r - — I 1 ~ — i — r - — - — • :—I • -I t y p e I I | i n t e r r u p t j I a d d r I h- — ~ r r — » , s t o | d m > — r — , r — f l e v e l j - — T - - f | s e g t y p e J t t o | l c | | J b e | a e | b x | a x I | l e n g t h | c a o J i : -i 1 J 1 _ J J > i j j i j t y p e = t y p e i n f o r m a t i o n f i e l d s e g t y p e = segment t y p e c o d e ( e . g . , p r o c e d u r e o r b l o c k ) t t o = t h e t y p e t a b l e o f f s e t t o t h e t y p e d e s c r i b i n g t h e segment ( e . g . , proc (int) real) I c = i f s e g t y p e = p r o c e d u r e , a c o d e i n d i c a t i n g i n wh i ch s o u r c e l a n g u a g e t h e p r o c e d u r e was w r i t t e n (The s p e c i a l c o d e " e x t e r n a l " i n d i c a t e s t h a t t h e p r o c e d u r e i s d e f i n e d e x t e r n a l l y t o t h e m a c h i n e . ) s t o = t h e EA IDE s y m b o l t a b l e o f f s e t t o t h e e n t r y a s s o c i -a t e d w i t h t h i s i t e m dm = a f l a g t o i n d i c a t e t h a t t h i s s egmen t i s e x e c u t i n g i n debug mode i n t e r r u p t = i n t e r r u p t i n f o r m a t i o n f i e l d be = b e f o r e e n t r y i n t e r r u p t e n a b l e d f l a g ae = a f t e r e n t r y i n t e r r u p t e n a b l e d f l a g bx = b e f o r e e x i t i n t e r r u p t e n a b l e d f l a g ax = a f t e r e x i t i n t e r r u p t e n a b l e d f l a g l e v e l = t h e l e x i c l e v e l o f t h i s s egmen t a d d r = i f l c = e x t e r n a l , t h e a d d r e s s o f t h e e x t e r n a l r o u t i n e l e n g t h = i f l c * e x t e r n a l , t h e l e n g t h o f t h e s egmen t i n s y l l a b l e s c ao = i f l c # e x t e r n a l , t h e c o d e a r e a o f f s e t t o t h e f i r s t i n s t r u c t i o n o f t h e segment F i g u r e C-1. Segment D e s c r i p t o r F o r m a t Appendix C. SPAM D e s c r i p t o r Formats 145 DD j . — r - — - _ - _ _ _ . _ | type I I i n t e r r u p t | | 1 r — r — i — i — i — I s t o i 1 1 — - r - H value | t t o | r c | s | d | c | l | t | Jba|aa|bu|au| J J i _ _ J—X 1 1 I type t t o r c d c s t o i n t e r r u p t ba aa bu au = type i n f o r m a t i o n f i e l d = the type t a b l e o f f s e t t o the type d e s c r i b i n g the data item (e.g., i n t e g e r , r e a l , s c a l a r , or s t r u c t u r e ) = the number of l e v e l s of i n d i r e c t i o n a s s o c i a t e d with the data item (e.g., i f r c = 1, the item i s a r e f e r e n c e t o some other value) = subrange of i n t e g e r or s c a l a r f l a g ( i . e . , the bounds t a b l e c o n t a i n s the bounds f o r the i n t e g e r values which t h i s data item can possess) = value f i e l d d e f i n e d f l a g - constant value f l a g ( i . e . , the value of t h i s data item cannot be a l t e r e d ) = long value f l a g ( i . e . , the a c t u a l value of t h i s item i s i n the f r e e storage a r e a , the value f i e l d of t h i s d e s c r i p t o r c o n t a i n s an o f f s e t i n t o the f r e e s t o r a g e area) = temporary value f l a g {used t o f a c i l i t a t e garbage c o l l e c t i o n } = the RAIDE symbol t a b l e o f f s e t t o the entry a s s o c i -ated with t h i s item = i n t e r r u p t i n f o r m a t i o n f i e l d ~ before access i n t e r r u p t enabled f l a g = a f t e r access i n t e r r u p t enabled f l a g = before update i n t e r r u p t enabled f l a g = a f t e r update i n t e r r u p t enabled f l a g [ c o n t i n u e d on next page) F i g u r e C-2. Data D e s c r i p t o r Format Appendix C. SPAM D e s c r i p t o r Formats 146 value = value f i e l d {The format of t h i s f i e l d i s dependent on the type f i e l d , and i s d e f i n e d as follows;} a. i f r c > 0 ; i , I value I h T * I | o f f s e t | I area t-— r~ —I I J l e v e l l o r d e r | t 1 - i i area = a code f o r the area t o which the r e f e r e n c e r e f e r s (e.g., dynamic s t o r a g e s t a c k or f r e e s t o r a g e area) o f f s e t = the o f f s e t i n the i n d i c a t e d area t o the data item l e v e l = i f area ~ dynamic storage stack, the l e x i c l e v e l of the item order = i f area = dynamic storage s t a c k , the order of the item b. i f 1 = t r u e ; r 1 I value | r .j |length1fsao| t — , 1 J l e n g t h = the l e n g t h of the data item i n the f r e e storage area f s a o - t h e o f f s e t i n the f r e e storage area t o the f i r s t s y l l a b l e of the data item c. otherwise: value = the a c t u a l value of the data item Figure C-2. Data D e s c r i p t o r Format (continued) Appendix C. SPAM D e s c r i p t o r Formats 147 r AD T •: - i T type I ~i 1 — r — r — i — r - H s t o I i n t e r r u p t | bto J value J type d t sto i n t e r r u p t bto v a l u e :o|rc|s | d|c 11|11 |ba|aa|bu|au| I 1 x. a i i . i L i i J JL _i i . . . j i type i n f o r m a t i o n f i e l d (This f i e l d has the same format as that o f a data d e s c r i p t o r , but with s p e c i a l meaning f o r the f o l l o w i n g s u b f i e l d s : } = a f l a g t o i n d i c a t e that storage f o r the array has been a l l o c a t e d = a f l a g to i n d i c a t e t h a t the storage r e f e r e n c e d by t h i s d e s c r i p t o r i s a l s o r e f e r e n c e d by another d e s c r i p t o r and t h a t i t must n o t b e d e a l l o c a t e d t h e RAIDE symbol t a b l e o f f s e t t o the e n t r y a s s o c i -ated with t h i s item i n t e r r u p t Information f i e l d {This f i e l d has the same format as t h a t of a data d e s c r i p t o r . } the o f f s e t i n the bounds t a b l e to the bounds of the a r r a y value f i e l d ( This f i e l d has the same format as t h a t o f a data d e s c r i p t o r f o r a r e f e r e n c e ( i . e . , when rc > 0 ) . I f area = dynamic storage s t a c k , the ( l e v e l , o r d e r ) p a i r addresses the f i r s t element of t h e a r r a y . The subsequent elements are addressed (level,order+ 1), ( l e v e l , o r d e r * 2 ) , . , . , } F i g u r e C-3. Array D e s c r i p t o r Format Appendix C. SPAM D e s c r i p t o r Formats 148 1 — 1 1-SCSED 1 J I 1 1 SD I o f f s e t . j -• 1 .J sso - 1 f SD = a f i e l d c o n t a i n i n g the same s u b f i e l d s as t h a t of a segment d e s c r i p t o r o f f s e t = the o f f s e t i n the code area { r e l a t i v e t o the f i r s t i n s t r u c t i o n of t h i s segment) to the next i n s t r u c -t i o n t o be executed sso = the o f f s e t i n the scope stack t o the scope which i s l o c a l to t h i s segment F i g u r e C-4. Segment C o n t r o l Stack Entry D e s c r i p t o r Format SSED T " I eso dsso | eso = the o f f s e t i n the expression stack to the f i r s t e n t r y a v a i l a b l e to the segment (s) which index(es) t h i s scope s t a c k e n t r y dsso = the o f f s e t i n the dynamic storage stack to the f i r s t e n t r y a v a i l a b l e to the segment (s) which index(es) t h i s scope stack entry Figure C-5. Scope Stack Entry D e s c r i p t o r Format 1 49 Appendix D. SPAM Table Entry Formats | BTE t T -I type | | J I T—-r—I lb|ub| f t t o l d j c j | | type = type i n f o r m a t i o n f i e l d t t o = the type t a b l e o f f s e t to the subrange of i n t e g e r or s c a l a r type f o r which t h i s e n t r y d e f i n e s the bounds d = bounds f i e l d s d e f i n e d f l a g c = co n s t a n t bounds value f l a g l b = lower bound value ub = upper bound value F i g u r e D - 1 . Bounds Table Entry Format Appendix D. SPAM Table Entry Formats 150 TTE r T 1 r r •% i~ -\ I c l a s s j tto|bto|rc\comps J parmsIdim j t -1 J J 1 i . 4 , I c l a s s c l a s s code {The format of the remaining f i e l d s i s dependent on the c l a s s f i e l d , as follows;} a. p r i m i t i v e t t o a s e l f - r e f e r e n t type t a b l e o f f s e t b. subrange t t o bto = the type t a b l e o f f s e t to the base type o f the subrange = the bounds t a b l e o f f s e t d e f i n i n g the subrange c. s c a l a r t t o bto = the type t a b l e o f f s e t t o the base type used to implement the s c a l a r v a l u e s the bounds t a b l e o f f s e t d e f i n i n g the subrange used to implement the s c a l a r v a l u e s d. r e f e r e n c e t t o = r c = the type t a b l e o f f s e t t o the base type of the r e f e r e n c e the number o f l e v e l s of i n d i r e c t i o n a s s o c i a t e d with the r e f e r e n c e ( i . e., r e f e r e n c e count) e. s t r u c t u r e comps = the number of components c o n s t i t u t i n g the s t r u c -t u r e {The components themselves are d e s c r i b e d by the succeeding 'comps1 type t a b l e e n t r i e s * } ( c o n t i n u e d on next page] Fi g u r e D -2 . Type Table Entry Format Appendix D. SPAM Table Entry Formats 151 f . procedure t t o = the type t a b l e o f f s e t t o the type y i e l d e d by the procedure (which may, of course, be void) parms = the number of parameters which the procedure accepts {The parameters themselves are d e s c r i b e d by the succeeding 'parms* type t a b l e e n t r i e s . } g. array t t o = the type t a b l e o f f s e t to the base type of the a r r a y dim - the d i m e n s i o n a l i t y { i . e . , number of s u b s c r i p t s ) of the a r r a y {The s u b s c r i p t s themselves are d e s c r i b e d by t h e succeeding 'dim* type t a b l e e n t r i e s . } h. union comps = the number of components c o n s t i t u t i n g the union {The components themselves are d e s c r i b e d by the succeeding 'comps' type t a b l e e n t r i e s . } i . d e f e r r e d {to i n d i c a t e t h a t the a c t u a l entry d e s c r i p t i o n i s elsewhere i n the type table} t t o = the type t a b l e o f f s e t to the a c t u a l e ntry d e s c r i p t i o n Figure D-2. Type Ta b l e Entry Format (continued) 152 Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e /* Bloody i n s t r u c t i o n s which, being l e a r n e d , r e t u r n to plague the i n v e n t o r . — W i l l i a m Shakespeare, Macbeth */ The i n s t r u c t i o n s of SPAM have been d i v i d e d i n t o seven c l a s s e s based on t h e i r use. For each i n s t r u c t i o n , a mnemonic i s given. T h i s i s f o l l o w e d by a l i s t of i t s operand(s), i f any, and an e x p l a n a t i o n of i t s e x e c u t i o n , e n c l o s e d i n braces. A l s o , f o r some of the i n s t r u c t i o n s , the a s s o c i a t e d Spamdol code i s presented i n o u t l i n e form. Necessary c o n s i s t e n c y and e r r o r checks have been suppressed to improve o v e r a l l r e a d a b i l i t y . 1. Segment C o n t r o l I n s t r u c t i o n s MARKSS [Push a new e n t r y onto the scope stack to e s t a b l i s h a new scope.} push_ss (esptr*1,dssptr+1) DEFSEG l e v e l , order [Push a new e n t r y onto the segment c o n t r o l stack to d e f i n e a segment whose d e s c r i p t o r i s addressed by the p a i r ( l e v e l , o r d e r ) . } p u s h _ s c s ( d s s [ l e v e l , o r d e r ] , 0 , s s p t r ) DFFDATA n, l o c [Push n new e n t r i e s onto the dynamic storage stack and a l l o c a t e s t o r a g e i f necessary. The n d e s c r i p t o r s s t a r t i n g at l o c a t i o n (0,loc) are templates f o r the e n t r i e s to be made.) f o r i := l o c t o loc*n-1 do push_dss (dss[ 0, i ]) i f d s s [ d s s p t r ] i s a r r a y _ d e s c r i p t o r then a i l o c a t e _ a r r a y Appendix E. SPAH I n s t r u c t i o n R e p e r t o i r e 1 5 3 PARM l o c {The top of the e x p r e s s i o n stack must c o n t a i n a parameter t o the procedure whose segment d e s c r i p t o r must be second from the top. Type-check the parame-t e r , pop i t from the exp r e s s i o n stack, and push i t onto the dynamic storage s t a c k . , ( 0,loc) addresses the template f o r the procedure's f o r m a l parameter, which i s necessary t o p r o p e r l y a s s o c i a t e formal and a c t u a l parameters.} l o c a l parm_no parm_no := d s s p t r - ssf s s p t r ]. dsso * 2 i f - s c s [ s c s p t r ] . d m o r check_parameter_type(parm_no,loc) t h e n push_dss(es[ e s p t r ] ) dss[ d s s p t r ].sto := dssf 0 , l o c ]. s tp pop_es e l s e i n t e r r u p t "parameter type mismatch" CALL {The top of the ex p r e s s i o n stack must c o n t a i n the d e s c r i p t o r f o r a segment which i s t o be c a l l e d . The parameters to the segment are a l l on the dynamic storage stack and have been type-checked. The segment d e s c r i p t o r i s popped and a new en t r y i s pushed onto the segment c o n t r o l stack, thus i n i t i -a t i n g execution o f the segment,} l o c a l no_parms no_parms := d s s p t r - ssf s s p t r } . dsso + 1 i f -»scs[ s c s p t r ]. dm o r check_number_of_parameters(no_parms) t h e n push_scs ( e s [ e s p t r ] , 0 , s s p t r ) pop_es e l s e i n t e r r u p t "wrong number of a c t u a l parameters" EXITSEG segtype {Pop e n t r i e s from the segment c o n t r o l stack up th r u the f i r s t whose segment type i s segtype. I f the segment i s r e t u r n i n g a value, i t must be moved onto the top of the exp r e s s i o n stack. None of the i n t e r m e d i a t e segments popped can return a value.} l o c a l r e s u l t r e s u l t := es[ e s p t r ] w h i l e (scsf s c s p t r ] . s e g t y p e * segtype) d o pop_scs i f ( t t [ s c s [ s c s p t r ) . t t o ) , t t o * void) t h e n i f i s c s [ s c s p t r ] . d m o r c h e c k _ r e s u l t _ t y p e ( r e s u l t , type) t h e n push_es ( r e s u l t ) e l s e i n t e r r u p t " r e s u l t type mismatch" ' Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e 154 CYCLE segtype {Pop e n t r i e s from the segment c o n t r o l s t a c k u n t i l the f i r s t segment whose type i s segtype i s encountered. Reset t h i s segment so t h a t i t begins r e e x e c u t i n g from i t s beginning. None of the i n t e r m e d i a t e seg-ments popped can r e t u r n a value.} while {scs[ s c s p t r ] . segtype # segtype) do pop_scs s c s [ s c s p t r ] . o f f s e t := 0 SKIP segtype, o f f s e t {The top of the e x p r e s s i o n stack must c o n t a i n a boolean value. I f t h i s value i s f a l s e , the f i r s t segment whose segment type i s segtype c o n t i n u e s executing a t the s p e c i f i e d o f f s e t . .. The boolean i s popped from the e x p r e s s i o n s t a c k . SKIP cannot be used to e x i t t h r u a segment which r e t u r n s a value; EXITSEG must be used i n such circumstances.} i f es[ e s p t r ]. value then pop_es else pop_es while (scs[ s c s p t r ]. segtype * segtype) do pop_scs | scs[ s c s p t r ]. o f f s e t := o f f s e t CASE {The top of the e x p r e s s i o n s t a c k must c o n t a i n an i n t e g e r v a l u e and the next e n t r y must c o n t a i n an a r r a y d e s c r i p t o r . A f t e r popping the top two stack e n t r i e s , the array i s indexed to o b t a i n the o f f s e t from which the c u r r e n t segment i s t o continue executing.} i f c h e c k _ a r r a y _ s u b s c r i p t then scs[ s c s p t r ] . o f f s e t := index_array pop_es pop_es else interrupt "case range e r r o r " 2. Data Access I n s t r u c t i o n s posav l e v e l , order {Push the value addressed by the p a i r ( l e v e l , o r d e r ) onto the e x p r e s s i o n stack.} Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e 155 PUSHR l e v e l , order (Push a r e f e r e n c e t o the value addressed by the p a i r ( l e v e l , o r d e r ) onto the ex p r e s s i o n stack.} POP {Pop the top entry from the expression stack.} STORE {The top of the exp r e s s i o n stack must c o n t a i n a value which i s t o be s t o r e d i n t o the l o c a t i o n i n d i c a t e d by the r e f e r e n c e which i s next from the top. These two stack e n t r i e s are then popped. STORE must check f o r scope v i o l a t i o n s i n v o l v i n g r e f e r e n c e s : i t i s not allowed t o a s s i g n a value to a r e f e r e n c e v a r i a b l e whose l i f e t i m e exceeds t h a t of the value i t s e l f . STORE must a l s o check f o r s i z e e r r o r s , check f o r assignment to a constant, and process the before and a f t e r update i n t e r r u p t s . } COPy ( D u p l i c a t e the entry on the top of the ex p r e s s i o n stack.} SWAP (Swap the top two e n t r i e s on the exp r e s s i o n stack.} SLICE {The top of the expre s s i o n stack must c o n t a i n the value of a s u b s c r i p t i n t o the ar r a y d e s c r i b e d by the entry second from the top. (This entry must e i t h e r be an ar r a y d e s c r i p t o r or a r e f e r e n c e to an ar r a y d e s c r i p -t o r . ) A f t e r popping the top two stack e n t r i e s , SLICE r e t u r n s on top of the ex p r e s s i o n stack one of the f o l l o w i n g : 1. the value of an element of the a r r a y , 2. a r e f e r e n c e to an element of the a r r a y , 3. a d e s c r i p t o r f o r a subarray of the a r r a y , or 4 . a r e f e r e n c e t o a subarray d e s c r i p t o r s } SELECT n {The top of the e x p r e s s i o n stack must c o n t a i n a d e s c r i p t o r f o r a s t r u c t u r e d value o r a r e f e r e n c e t o such a val u e . T h i s d e s c r i p t o r i s r e p l a c e d by e i t h e r the value of the n-th s u b f i e l d of the s t r u c t u r e or by a r e f e r e n c e t o the same.} DEREF {The top of the ,expression stack must c o n t a i n a r e f e r e n c e v a l u e . T h i s entry i s r e p l a c e d by the value referenced.} Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e 156 3. A r i t h m e t i c and S t r i n g I n s t r u c t i o n s None of these i n s t r u c t i o n s operate on a r r a y s . A l s o , no automatic type c o n v e r s i o n s are performed on operands ( i . e . , the operand(s) must be of the c o r r e c t t y p e ) . a. b i n a r y i n s t r u c t i o n s {The top two e n t r i e s of the e x p r e s s i o n stack must c o n t a i n the operands.} i . i n t e g e r or subrange of i n t e g e r operands ADD SUB MUL DIV MOD LT LE EQ NE GE. fiT i i . r e a l operands ADD SUB MUL DIV LT LE EQ NE GE GT i i i . boolean operands AND OB i v . s t r i n g operands CONCAT v. r e f e r e n c e operands EQ NE b. unary i n s t r u c t i o n s {The top of the e x p r e s s i o n stack must c o n t a i n the operand.} i . i n t e g e r or subrange of i n t e g e r operand ABS NEG SUCC PR ED i i . r e a l operand ABS N EG i i i . boolean operand NOT SUBSTR [The top of the e x p r e s s i o n stack must c o n t a i n e i t h e r two or t h r e e operands. I f t h r e e operands are sup-p l i e d , the top two e n t r i e s must c o n t a i n i n t e g e r values which r e p r e s e n t the l e n g t h (top entry) and s t a r t i n g p o s i t i o n (next entry) of the s u b s t r i n g t o be obtained, and the t h i r d e n try from the top must c o n t a i n a s t r i n g value or a r e f e r e n c e to a s t r i n g from which the s u b s t r i n g w i l l be taken. I f o n l y two operands are s u p p l i e d , the l e n g t h i s assumed to be the remainder o f t h e s t r i n g and o n l y the s t a r t i n g p o s i t i o n and base s t r i n g need to be s p e c i f i e d . A f t e r popping i t s operands, SUBSTB r e t u r n s on top of the e x p r e s s i o n stack e i t h e r a s t r i n g or a r e f e r e n c e to a s t r i n g which i s the s u b s t r i n g desired.} 4. Transput I n s t r u c t i o n s PUT {The top of the e x p r e s s i o n s t a c k must c o n t a i n a s t r i n g value which i s output t o the primary output device. T h i s s t r i n g i s then popped from the expression Appendix E.... SPAM I n s t r u c t i o n : R e p e r t o i r e 157 stack. } {The next r e c o r d from the primary i n p u t d e v i c e i s r e a d i n t o a newly a l l o c a t e d s t r i n g i n the f r e e storage area and a d e s c r i p t o r of t h i s s t r i n g value i s pushed onto the e x p r e s s i o n s t a c k . A n u l l s t r i n g i n d i c a t e s t h a t the end of the f i l e has been encountered.) 5. Storage Management I n s t r u c t i o n s SETBT bto {The top two e n t r i e s of the e x p r e s s i o n stack must c o n t a i n i n t e g e r or subrange of i n t e g e r values. These two e n t r i e s are popped and t h e i r values placed i n t o the bounds t a b l e a t o f f s e t bto. The top entry d e f i n e s the dynamic upper bound which i s to be placed i n t o the t a b l e ; the next e n t r y d e f i n e s the lower bound.} ALLOC t t o {Storage f o r a s t r u c t u r e o f type t t o i s a l l o c a t e d i n the f r e e storage area and a data d e s c r i p t o r of t h i s type i s pushed onto the e x p r e s s i o n stack.} 6. Status I n s t r u c t i o n s TESTYPE mask {The type f i e l d of the d e s c r i p t o r on top o f the expression stack i s checked a g a i n s t the mask and the e n t r y i s r e p l a c e d by a boolean value which i n d i c a t e s whether or not the masked b i t s of the type f i e l d are set.} LENGTH {The top o f the e x p r e s s i o n stack must c o n t a i n a s t r i n g value. T h i s e n t r y i s r e p l a c e d by the l e n g t h of the s t r i n g . } LBOOND {The top of the e x p r e s s i o n stack must c o n t a i n an a r r a y d e s c r i p t o r or a value of s c a l a r type. T h i s e n t r y i s r e p l a c e d by the lower bound, obtained from the bounds t a b l e , f o r the item.} Appendix E. SPAM I n s t r u c t i o n R e p e r t o i r e 158 UBOUND [The top of the e x p r e s s i o n stack must c o n t a i n an a r r a y d e s c r i p t o r or a value of s c a l a r type. T h i s entry i s r e p l a c e d by the upper bound, obtained from the bounds t a b l e , f o r the item.} 7. M i s c e l l a n e o u s I n s t r u c t i o n s [Execution c o n t i n u e s with the next i n s t r u c t i o n . ) NOOP CONVERT t t o {The top of the ex p r e s s i o n stack must c o n t a i n a value of p r i m i t i v e , subrange of i n t e g e r , s c a l a r , or r e f e r -ence type. T h i s entry i s r e p l a c e d with the value converted to the p r i m i t i v e type tto.} ASSERT [The top o f the e x p r e s s i o n stack must c o n t a i n a boolean value. T h i s e n t r y i s popped and, i f i t s value i s f a l s e , an i n t e r r u p t i s generated.) SIGNAL e x c e p t i o n {A u s e r - s p e c i f i e d i n t e r r u p t i s generated, s i g n a l i n g the occurrence of some exception.} STOP [The machine i s abnormally terminated.} DUMP code {One of the machine areas, s t a c k s , o r t a b l e s ( c f . . F i g u r e IV-1) i s dumped. The code i n d i c a t e s which i s to be dumped.} 159 Appendix F. An Example SPAM Object Program /* A r e a l l y g r e a t t a l e n t f i n d s i t s happiness i n execution, — Johann Wolfgang yon Goethe */ T h i s appendix presents a complete example of a SPAM o b j e c t program, i n c l u d i n g both the machine code and the d e s c r i p t o r s needed f o r i t s e x e c u t i o n . The example chosen i s Towers of Hanoi [Peck 75:30-32]. A source program f o r i t w r i t t e n i n an A l g o l -l i k e language i s contained i n Fig u r e F-1, and i t s SPAM t r a n s l a -t i o n i s given i n F i g u r e F-2. The SPAM code i s presented i n an a s s e m b l e r - l i k e n o t a t i o n ; l i t e r a l and v a r i a b l e operands must be converted i n t o o f f s e t s i n t o the dynamic storage s t a c k . The l e f t - m o s t column of F i g u r e F-2 c o n t a i n s the machine code t r a n s l a t i o n o f the SPAM assembler code. The machine code i s o n l y presented here f o r completeness; no f u r t h e r e x p l a n a t i o n w i l l be given. fiefer t o Appendix E f o r e x p l a n a t i o n s of the SPAM i n s t r u c t i o n s . The i n i t i a l s t a t e s of the dynamic storage stack, the segment c o n t r o l stack, and the type t a b l e a re o u t l i n e d i n F i g u r e F-3; only important f i e l d s are mentioned. ,. The expression s t a c k and bounds t a b l e are i n i t i a l l y empty. Appendix F. An Example SPAH Object Program 160 stmt l e x i c number l e v e l source code main: 1 begin £roc hanoi ( i n t e g e r value n ; char valine me,de,ma) ; 1 2 i f n>0 then 2 hanoi (n- 1,me, ma,de) ; 3 p r i n t (" HOVE DISK ",n," FROM PEG ", me," TO PEG ",ma) ; 4 hanoi (n-1,de,me,ma) 2 f i ; 5 hanoi (4 ,"A", "B", "C") 1 end Fig u r e F-1. Towers of Hanoi Source Program Appendix F. An Example SPAM Object Program 161 machine code ass e m h i e r _ c o de comments 1 0 20 DEFSEG STMTS i n i t i a l c a l l to 'hanoi* 0 MARKSS 32 0 1 PUSHV HANOI 32 0 2 PUSHV 4 pass the f i r s t parameter 3 12 PARK N 32 0 3 PUSHV •A* pass the second parameter 3 13 PARM ME 32 0 4 PUSHV » B» pass the t h i r d parameter 3 14 PARM DE 32 0 5 PUSHV •C* pass the f o u r t h parameter 3 15 PARM MA 4 CALL now invoke 'hanoi* ORIGIN 51 s t a r t 'hanoi 1 a t o f f s e t 51 1 0 16 DEFSEG STMT1 i f statement 1 0 6 DEFSEG IF-STMT d e f i n e the bounds o f the i f statement 32 1 0 PUSHV N e v a l u a t e the i f e x p r e s s i o n 32 0 7 PUSHV 0 78 GT 7 64 103 SKIP ENDIF s k i p the then c l a u s e i f f a l s e 1 0 17 DEFSEG STMT 2 r e c u r s i v e c a l l t o »hanoi* 0 MARKSS 32 0 1 PUSHV HANOI 32 1 0 PUSHV N evaluate »n-1* and pass i t 32 0 8 PUSHV 1 65 SUB 3 12 PARM N 32 1 1 PUSHV ME pass the second parameter 3 13 PARM ME 32 1 3 PUSHV MA pass the t h i r d parameter 3 14 PARM DE 32 1 2 PUSHV DE pass the f o u r t h parameter 3 15 PARM MA 4 CALL [ c o n t i n u e d on next page] Figure F-2. Towers of Hanoi SPAM Code Appendix F. An Example SPAM Object Program 1 machine code assembler code com mentis 1 0 18 DEFSEG STMT3 tr a n s p u t code 32 0 9 POSHV ' MOVE DISK * 32 1 0 POSHV N 193 5 CONVERT STRING convert « n» t o type s t r i n g 82 CONCAT concatenate the s i x arguments 32 0 10 PUSHV ' FROM PEG ' o f ' p r i n t * i n t o 82 CONCAT one output s t r i n g 32 1 1 PUSHV ME 82 CONCAT 32 0 11 PUSHV ' TO PEG ' 82 CONCAT 32 1 3 PUSHV MA 82 CONCAT 96 PUT 1 0 19 DEFSEG STMT4 r e c u r s i v e c a l l to *hanoi» 0 MARKSS 32 0 1 PUSHV HANOI 32 1 0 PUSHV N eva l u a t e »n-1' and pass i t 32 0 8 PUSHV 1 65 SOB 3 12 PARM N 32 1 2 PUSHV DE pass the second parameter 3 13 PARM ME 32 1 1 PUSHV ME pass the t h i r d parameter 3 14 PARM DE 32 1 3 PUSHV MA pass the f o u r t h parameter 3 15 PARM MA 4 CALL F i g u r e F - 2 . T o w e r s o f H a n o i SPAM C o d e ( c o n t i n u e d ) Appendix F. An Example SPAM Object Program 1 The i n i t i a l dynamic storage stack e n t r i e s : o f f s e t tjrpe i f f i p o r t a n t _ f i e l d _ v a l u e s cojgmeilt 0 segment segtype=proc tto=1 level=0 length=28 cao=1 main 1 segment segtype=proc tto=6 level=1 length=109 cao=51 hanoi 2 data tto=2 1=F value=4 4 3 data tto=5 1=T length=1 fsao=1 »A» 4 data tto=5 1=T length=1 fsao=2 *B» 5 data tto=5 1=T length=1 fsao=3 »C» 6 segment segtype=if-stmt tto=1 level=1 length=103 cao=57 i f stmt 7 data tto=2 1=F value=0 0 8 data tto=2 1=F value=1 1 9 data tto=5 1=T length=11 fsao=4 « MOVE DISK 10 data tto=5 1=T length=10 fsao=15 » FBOM PEG 11 data tto=5 1=T length=8 fsao=25 * TO PEG • 12 data tto=2 d=F n 13 data tto=5 d=F me 14 data tto=5 d=F de 15 data tto=5 d=F ma 16 segment segtype=stmt length=106 cao=54 stmt 1 17 segment segtype=stmt length=29 cao=70 stmt 2 18 segment segtype=stmt length=26 cao=102 stmt 3 19 segment segtype=stmt length=29 cao=131 stmt 4 20 segment segtype=stmt length=25 cao=4 stmt 5 The i n i t i a l segment c o n t r o l s t a c k entry; segtype=proc tto=1 length=28 cao=1 offset=0 sso=1 The i n i t i a l type t a b l e e n t r i e s : F igure F-3.. Towers of Hanoi I n i t i a l SPAM Machine S t a t e 1 6 4 Appendix G. RAIDE Symbol Table Entry Formats I DSSTE | r — r 1 ; r T 1 1 I I ! type I l i n k I count| esto J | s i t o j hCo r ! T r + r 1 + — T + — T 1 r — i J j | l e v e l | o r d e r | d a t a t y p e i d s s o | p s t o | o s t o J s s t o | a| u|ba|aajbu|au| L L J i L 1 1 i J ; .J I J I i.. 1, - i s i t o = s t r i n g index t a b l e o f f s e t hco = homonym chain o f f s e t type = type i n f o r m a t i o n f i e l d l e v e l = the l e x i c l e v e l o f the item order = the l e x i c order of the item datatype = data type code (e.g., v a r i a b l e o r constant) dsso = the SPAM dynamic storage stack o f f s e t t o the "template d e s c r i p t o r " a s s o c i a t e d with t h i s item l i n k = l i n k a g e i n f o r m a t i o n f i e l d psto = the symbol t a b l e o f f s e t t o the parent a t t h i s l e v e l osto = the symbol t a b l e o f f s e t t o an o f f s p r i n g at t h i s l e v e l s s t o = the symbol t a b l e o f f s e t to a s i b l i n g a t t h i s l e v e l count = a count o f the number of times the a s s o c i a t e d d a t a - s p e c i f i c has been accessed (a) and updated (u) s i n c e system i n i t i a l i z a t i o n e s t o = the event symbol t a b l e o f f s e t f o r the d e f e r r e d a c t i o n ( i f any) a s s o c i a t e d with the d a t a - i n c i d e n t s b e f o r e access (ba), a f t e r a ccess (aa), before update (bu), and a f t e r update (au) Fig u r e G-1. D a t a - S p e c i f i c Symbol Table E n t r y Format Appendix G. BAIDE Symbol Ta b l e Entry Formats 165 r 1 I SSSTE J H r 1 1 T r 1 • — i I I I type | (count) esto i p h r a s e s j I s i t o | hco V — T r f l i n k | — n — - | — R — i 1 — r - — A I I I i d Jsegtype|dsso| I e| x|be|ae|bx|ax|ph1|ph2| I J 4 J X J J i 1 J I i L_ 1 _> s i t e = s t r i n g index t a b l e o f f s e t <may be n u l l ) hco = homonym cha i n o f f s e t (may be n u l l ) type = type i n f o r m a t i o n f i e l d i d = i d e n t i f i c a t i o n f i e l d (e.g., a statement number) segtype = segment type code (e.g., procedure or block) dsso = the SPAM dynamic storage s t a c k o f f s e t to the "template d e s c r i p t o r " a s s o c i a t e d with t h i s item l i n k = l i n k a g e i n f o r m a t i o n f i e l d {This f i e l d has the same format as t h a t of a d a t a - s p e c i f i c symbol t a b l e entry.} count - a count of the number of times the a s s o c i a t e d s e g m e n t - s p e c i f i c has been entered (e) and e x i t e d (x) s i n c e system i n i t i a l i z a t i o n e s t o = the event symbol t a b l e o f f s e t f o r the d e f e r r e d a c t i o n ( i f any) a s s o c i a t e d with the segment-i n c i d e n t s before e n t r y (be), a f t e r e n t r y (ae), before e x i t (bx) , and a f t e r e x i t Max) phrases = an o f f s e t i n t o the s t r i n g index t a b l e f o r the s t r i n g phrases which c o n s t i t u t e the source program code of the a s s o c i a t e d s e g m e n t - s p e c i f i c {The order f o r p r i n t i n g out t h e code o f some node i s : p h i , then the code a s s o c i a t e d with the o f f s p r i n g node, f o l l o w e d by ph2.} Figure G-2., Segment-Specific Symbol Table Entry Format appendix G. B A I D E S y m b o l T a b l e E n t r y F o r m a t s 1 6 6 r , I G S T E | j. , r __ 4 I I I type I Jsito |hco| 1 r — I I | |gentypelcodejlcj I I 1 I : I I sito = string index table offset hco = homonym chain offset type = type information field gentype = a flag to indicate whether the generic is a segment- or a data-generic code = the segment- or data-generic type code of this generic lc = a code indicating for which language this is a generic F i g u r e G -3 . G e n e r i c S y m b o l T a b l e E n t r y F o r m a t Appendix G. RAIDE Symbol Ta b l e Entry Formats 167 ESTE I ! 1 : 1 J 1 I I type I I | s i t o j hcoj r r r 1 |eco|lco J I | c l a s s l i e | c o d e | d e s t o | d a p t r | | | « J- 1 — J J 1—. i i J s i t o hco type c l a s s l c code desto daptr eco l c o s t r i n g index t a b l e o f f s e t (may be n u l l ) homonym chain o f f s e t (may be n u l l ) type i n f o r m a t i o n f i e l d = a code to i d e n t i f y the e n t r y as a system d e f a u l t , a language-dependent, or a user-s u p p l i e d event {The hie r a r c h y of s e l e c t i o n i s : u s e r - s u p p l i e d , language-dependent, and system,} = i f type = language-dependent, a code i n d i c a t i n g t o which language the e n t r y i s a s s o c i a t e d = the e r r o r code used by SPAM t o i d e n t i f y the event i f i t i s an ex c e p t i o n a symbol t a b l e o f f s e t t o the d e f e r r e d a c t i o n l a b e l ( i f present) a s s o c i a t e d with the event a p o i n t e r t o the d e f e r r e d a c t i o n ( i f any) asso-c i a t e d with the event the symbol t a b l e o f f s e t f o r the event c h a i n , which i s used to c h a i n together a l l event e n t r i e s i n ascending order of t h e i r 'code' f i e l d values the symbol t a b l e o f f s e t f o r the l a b e l c h a i n , which i s used t o chain t o g e t h e r a l l event e n t r i e s having the same d e f e r r e d a c t i o n l a b e l F i g u r e G-4. Event Symbol Table Entry Format Appendix G, EAIDE Symbol T a b l e Entry Formats 168 r 1 J SFSTE J j. , _ T __j I s i t o | h c o J l c | r o u t i n e _ n o J L 1 L 1 Z 1 s i t o = s t r i n g index t a b l e o f f s e t hco = homonym chain o f f s e t l c = a code i n d i c a t i n g f o r which language t h i s i s a language-dependent system f u n c t i o n {A s p e c i a l code i n d i c a t e s language-independent functions,} r o u t i n e _ n o = a number used to a s s o c i a t e the system f u n c t i o n with i t s i n t e r n a l r o u t i n e e g u i v a l e n t F i g u r e G-5. System F u n c t i o n Symbol Table Entry Format i — 1 1 | DDSSTE ) r- T i . » |dtype)ubldvsojDSSTEI i i x j I the type code ( v i z . , i n t e g e r or s p e c i f i c ) of the debugging e n t i t y d e f i n e d by t h i s e n t r y the upper bound v a l u e f o r debugging e n t i t i e s which are d e c l a r e d as a r r a y s {ub - 0 i n d i c a t e s a simple debugging v a r i a b l e . } the debugging value stack o f f s e t f o r the c u r r e n t value (or values, i f ub > 0) of the e n t i t y d e f i n e d by t h i s entry {dvso = n u l l i f the scope of the e n t i t y i s c u r r e n t l y i n a c c e s s i b l e . The value of a s p e c i f i c debugging v a r i a b l e i s the symbol t a b l e o f f s e t to the user program e n t i t y a s s o c i a t e d with the s p e c i f i c . } a f i e l d c o n t a i n i n g the same s u b f i e l d s as t h a t of a d a t a - s p e c i f i c symbol t a b l e e n t r y except t h a t the 'dsso* f i e l d i s unused {The 'datatype 1 values f o r D i s p e l are VARIABLE and PROCEDURE.} Figur e G-6. Debugging D a t a - S p e c i f i c Symbol Table E n t r y Format dtype ub dvso DSSTE A p p e n d i x G. E A I D E S y m b o l T a b l e E n t r y F o r m a t s 169 DSSSTE ] • x — i \ Jdtype|esto|SSSTE| dtype = the type code ( v i z . , d e f e r r e d a c t i o n l a b e l or debugging procedure) o f the debugging e n t i t y d e f i n e d by t h i s e n t r y esto = i f dtype = d e f e r r e d a c t i o n l a b e l , the symbol t a b l e o f f s e t to an event a s s o c i a t e d with the l a b e l ( A l l d e f e r r e d a c t i o n s s h a r i n g a l a b e l a r e chained together by the Mco' f i e l d of the event symbol t a b l e entry.} SSSTE = a f i e l d c o n t a i n i n g the same s u b f i e l d s as t h a t of a s e g m e n t - s p e c i f i c symbol t a b l e entry except t h a t the 'dsso' f i e l d c o n t a i n s the address o f the ob j e c t code a s s o c i a t e d w i t h t h i s e n t r y (The 'seg-type* values f o r D i s p e l are COMMAND and ACTION.} Fi g u r e G-7. Debugging Segment-Specific Symbol Table Entry Format 170 Appendix R. Example RAIDE Symbol Table E n t r i e s T h i s appendix presents s e v e r a l examples of RAIDE symbol t a b l e e n t r i e s , The f i r s t example demonstrates how user program d a t a - s p e c i f i c s are maintained by RAIDE. An o u t l i n e o f a program i n an A l g o l - l i k e language i s c o n t a i n e d i n F i g u r e H-1. Only v a r i a b l e and procedure d e c l a r a t i o n s are shown s i n c e executable statements are unimportant here. User program e n t i t i e s <e.g., v a r i a b l e s and procedures) must be a c c e s s i b l e i n two ways: by t h e i r names and by t h e i r ( l e v e l , order) p a i r s . The former i s necessary f o r i n t e r f a c i n g between the user and SPAM ( i . e . , f o r mapping between a name i n a D i s p e l u t t e r a n c e and i t s a c t u a l m a c h i n e - l e v e l v a l u e ) . The l a t t e r i s necessary f o r i n t e r f a c i n g between SPAM and RAIDE ( i . e . , when SPAM s i g n a l s an e r r o r , RAIDE must determine from the machine s t a t e what s o u r c e - l e v e l e n t i t i e s are involved) . Figure H-2 demonstrates how the v a r i a b l e s and procedures of F i g u r e H-1 are accessed by t h e i r i d e n t i f i e r names. Each i d e n t i f i e r i s u n i g u e l y hashed to an o f f s e t i n t o the i d e n t i f i e r hash t a b l e . A l l symbol t a b l e e n t r i e s with i d e n t i c a l i d e n t i f i e r s are chained t h r u the homonym ch a i n . I n the f i g u r e , each symbol t a b l e entry i s r e presented by a node showing only three of i t s f i e l d s : a s t r i n g index t a b l e o f f s e t (diagrammed f o r s i m p l i c i t y as a c h a r a c t e r s t r i n g r e f e r e n c e ) , a ( l e v e l , o r d e r ) p a i r , and the homonym ch a i n p o i n t e r . Appendix H. Example RAIDE Symbol Table E n t r i e s 171 F i g u r e H-3 demonstrates how user i d e n t i f i e r s are accessed by t h e i r ( l e v e l , o r d e r ) p a i r s . Each symbol t a b l e e n t r y i s r e p resented by a node showing only three of i t s f i e l d s : a s t r i n g index t a b l e o f f s e t (diagrammed f o r s i m p l i c i t y as a c h a r a c t e r s t r i n g r e f e r e n c e ) , an o f f s p r i n g symbol t a b l e o f f s e t , and a s i b l i n g symbol t a b l e o f f s e t . Given the symbol t a b l e o f f s e t of 'main 1 and the ( l e v e l , o r d e r ) p a i r s f o r a c c e s s i n g some d e s i r e d i d e n t i f i e r , i t s symbol t a b l e e n t r y i s l o c a t e d by c h a i n i n g t h r u the o f f s p r i n g and s i b l i n g symbol t a b l e entry f i e l d s . The f i r s t example presented i n t h i s appendix d e a l s o n l y with user program symbol t a b l e e n t r i e s . I t must be remembered t h a t the symbol t a b l e a l s o c o n t a i n s e n t r i e s f o r g e n e r i c s , events, system f u n c t i o n s , and debugging e n t i t i e s ( c f . , Appendix G). A l l of these types o f e n t r i e s are connected along the homonym chain f o r i d e n t i c a l i d e n t i f i e r s . To r e s o l v e a m b i g u i t i e s {e.g., the user can d e f i n e a procedure c a l l e d ' l i n e * which i s s y n t a c t i c a l l y e g u i v a l e n t to the system f u n c t i o n 'LINE*), a h i e r a r c h y of access i s d e f i n e d as f o l l o w s : 1. a l l user i d e n t i f i e r s i n order of t h e i r s t a t i c d e c l a r a t i o n s , 2. a g e n e r i c , 3. an event, 4. a system f u n c t i o n , and 5. a l l debugging v a r i a b l e s and procedures. Thus, i f a user has a procedure c a l l e d ' l i n e ' , i t supersedes the system f u n c t i o n 'LINE'. S i m i l a r l y , the user cannot d e f i n e a appendix H. Example BAIDE Symbol Table E n t r i e s 172 debugging procedure c a l l e d ' l i n e * s i n c e the system f u n c t i o n 'LINE* w i l l supersede i t . l e x i c l e x i c _____ order source code 0 0 main: begin 1 0 _ r o c foo 2 0 ( i n t b e l l ) ; begin 2 1 r e a l bar ; • end ; 1 1 _____<! b e l l ; 1 2 proc b a r b e l l ; begin 2 0 p o o l bar ; end ; end F i g u r e H-1. Program f o r Demonstrating the BAIDE Symbol Table Appendix H. Example BAIDE Symbol Table E n t r i e s 173 I I I I -I r I r-f m T — j • i -—i >m (i,<» I/J | J —J i—i—; J i I I H : r — > (foo) I I + r J I r ^ r ,—> ( b e l l ) I I i J I i I I —H 1 "f r + T 1 — i r + i 1 — i t 1 * h >m (1,1) I H > l t l (2,0) |/| i J L — I 1 I I I I J r + ,—> [main) I I I I I I f 1 ] — | r + T T — i t i *—i >m (0 ,0) i / j | i | i 1 i l r j — > ( b a r b e l l ) I I I I I I I + 3 -| r + T 1—i t I •» h >|4 I (1 ,2) | / | r + — — . _—> (bar) I I I I I I m 1—T I i I * + > i t I (2, 1) |*+-« • • <—J 1—i t x . _ _ J i d e n t i f i e r symbol t a b l e e n t r i e s hash t a b l e Fiqure H-2. A c c e s s i n g a Symbol Table Entry by I d e n t i f i e r Appendix H., Example RAIDE Symbol T a b l e E n t r i e s 174 l e v e l r-> [foo] Y 1 r — i I I 1 r-> {bell} Y 1 i t r ~ H r-> {main} r-> {bell} r-> {bar} 1 I t i J r i -> I / I / I • 1 i •> {barbell} > {bar} Access ( l e v e l , o r d e r ) seguencies: main (0,0) foo (0,0) (1,0) b e l l (0,0) ( U 0 ) (2,0) bar (0,0) (1,0) (2,1) b e l l (0,0) d , D b a r b e l l (0,0) (1.2) bar (0,0) (1,2) (2,0) F i g u r e H - 3 . Accessing a Symbol Table Entry by ( l e v e l , o r d e r ) Appendix H. Example RAIDE Symbol Table E n t r i e s 175 In a d d i t i o n to user program d a t a - s p e c i f i c s , the RAIDE symbol t a b l e a l s o c o n t a i n s the d e s c r i p t i o n o f t h e s t a t i c s t r u c -t u r e of a program. T h i s i s done by maint a i n i n g symbol t a b l e e n t r i e s f o r each of the s e g m e n t - s p e c i f i c s of the source program. F i g u r e H-U demonstrates the e n t r i e s f o r the Towers of Hanoi program of Figure F-1. In the f i g u r e , each symbol t a b l e entry i s represented by a node showing seven o f i t s f i e l d s : the i d e n t i f i c a t i o n f i e l d (which i s e i t h e r a number or a s t r i n g index t a b l e o f f s e t f o r l a b e l e d s e g m e n t - s p e c i f i c s such as procedures), a segment type code, the SPAM dynamic storage stack o f f s e t t o the segment's template d e s c r i p t o r , a s i b l i n g symbol t a b l e o f f s e t , an o f f s p r i n g symbol t a b l e o f f s e t , and two s t r i n g index t a b l e o f f s e t s (diagrammed f o r s i m p l i c i t y as c h a r a c t e r s t r i n g r e f e r e n c e s ) f o r the source code phrases. In g e n e r a l , the ' s i t o ' and *hco» f i e l d s o f s e g m e n t - s p e c i f i c symbol t a b l e e n t r i e s are not used s i n c e segments are g e n e r a l l y not accessed by name. The major exceptions a re procedures. S i n c e each procedure has both a d a t a - s p e c i f i c e n t r y (which l i n k s together a l l data v a l u e s a c c e s s i b l e t o the procedure) and a se g m e n t - s p e c i f i c e n t r y (which l i n k s together a l l segments subor-d i n a t e t o the procedure), the two e n t r i e s a r e connected along the homonym c h a i n . Thus, g i v e n a procedure name, i t i s p o s s i b l e to determine both the v a r i a b l e scope s t r u c t u r e and the s t a t i c program s t r u c t u r e of t h a t procedure. Appendix H. Example RAIDE Symbol Table E n t r i e s 176 r - > {main} i — r + T 1 1 — g — r + T — % I f l p r o c l . 0 | / | t m - M - > [end} 1 L. 1 -X L X J 1 I I -> {main: begin) I ,—> {hanoi} r  J T+-j T — — r — , — j - X ^ — , *~>| t l p r o c l 1 | f | t l t l / l I 1 1 l | J L | J J I -> {proc hanoi (.. .) ;} I I T r > { i f n>0 then} M l s t a t j 16|/jt l*-r-> [ f i :} I I T I — T T 1 1 1 1 J | 1 if | 6|/m/|/| _ J L - X | 1 1 I i f T i — r -r- > {hanoi {.,.)} |2jstmt| 1 7 H | / J f | f - > {;} J — J L X X J X 1 I I F •> {print {...)} I—"1 — — I 1 i T + 1 1 |3|stmt| 18 | t i / } f I - H ~ > {;} r > {hanoi (..,)} i — i 1 " — i — i — r t T — i I 4 | stmt | 19|/1 / | t|/J i — l 1 J JI I I i T r > {hanoi ( . . .)} 1 1—i—rf-i—i |5|stmt|20 | / | / | t l / | F i g u r e B>4. Example Segment-Specific Symbol Table E n t r i e s 177 Appendix I. An Example BAIDE Program S p e c i f i c a t i o n T h i s appendix pres e n t s the BAIDE program s p e c i f i c a t i o n s f o r the sample program of F i g u r e F-1, Towers of Hanoi. F i g u r e 1-1 o u t l i n e s the BAIDE s p e c i f i c a t i o n s of the program's data-s p e c i f i c s and F i g u r e 1-2 o u t l i n e s the same f o r i t s segment-s p e c i f i c s . , Befer t o Appendix G f o r d e s c r i p t i o n s of the f i e l d s o f the data- and s e g m e n t - s p e c i f i c symbol t a b l e e n t r i e s ; o n l y the important f i e l d s are mentioned here. See Figure H-4 f o r a graphic r e p r e s e n t a t i o n o f t h e i n f o r m a t i o n contained i n Fig u r e 1-2. There are two f u r t h e r components of a program s p e c i f i c a -t i o n not presented here: the i n i t i a l bounds name t a b l e and type name t a b l e e n t r i e s . The bounds name t a b l e i s empty f o r t h i s example and the type name t a b l e simply c o n t a i n s the i d e n t i f i e r names of the p r i m i t i v e types, s i n c e t h e r e are no u s e r - d e f i n e d types i n t h i s example. ______ _ l e v e l _ o r d e r _ ______££ dsso _ s i b _ o f f _ i d e n t i f i e r 1 0,0 constant 0 0,2 main 2 1,0 constant 1 0,3 hanoi 3 2,0 parameter 12 4,0 n 4 2,1 par amet er 13 5,0 me 5 2,2 parameter 14 6,0 de 6 2,3 parameter 15 0,0 ma F i g u r e 1-1. Towers of Hanoi Data S p e c i f i c a t i o n s Appendix I... An Example RAIDE Program S p e c i f i c a t i o n 178 2 l _ _ _ _ i d segtype dsso j s i b _ o f f _ phrases 1 main proc 0 0,2 {main: begin,end} 2 hanoi proc 1 8,3 fEEoc ...;,} 3 1 stmt 16 0,4 {_f n>0 t h e n , f i ;} 4 i f - s t m t 6 0,5 {,} 5 2 stmt 17 6,0 {hanoi (...) ,;} 6 3 stmt 18 7,0 {pri n t (...),;} 7 4 stmt 19 0,0 {hanoi {...),} 8 5 stmt 20 0,0 {hanoi (...) ,} F i g u r e 1-2. Towers of Hanoi Segment S p e c i f i c a t i o n s 179 B i b l i o g r a p h i c Reference Index Abra Halp 65 ...... ........... 1 Appe Hans 75 .. ..., . . .... .......... 5 Ashb IBM 70 . . . . . . . Ifi fill ftS B a i r IBM 72 ....... B a l l Inga 72 11 Balz Itoh 73 ...... i f i l B alz Jens 74 ...... . . . . . . . . . ac. q i Baue Jflns 6 8 .... ............ ii Baye Bern John 78 ..,«., . . . . . . . . . . 7 3 -. .. a B i e r s B l a i K i r s 74 ...... Bobr Knob 75 ...... . . . . . . . . . . ft7 Boul Knut 71 11 Brad Koch 6 9 ...... . . . . . _ . 1 Brow Kuls 69 ...... , . . . . . . . . . Ii 1 25 Brow Kuls 71 ...... ......... 1-10 B u l l ......... Q Che a Leca 75 ...... ............ 87 Cl a p Ledcj 75 . . . . . . . . 1 17 C l a r Ledg 76 ...... . . ......... 7 Conr ........ S Conr Lest 71a ...•. .......... inn Conw Lest 71b ..... ........ 10 0 1?fi Conw Mann 73 ...... . . . . . 3 Q 9 7 Cres Marc 76 ...... . . . . . . . . 7 S C r i s Math 74 ...... ....... . 1 C u f f Math 75 ...... . . . . . . . L. . . 47 Davi M i l l 76a ..... . . . . . . . . AfS Ehr m M i l l 76b ..... ... 1 Evan Moor 75 ........... . fi Evan Morg 71 . . . . 11 Ferq f e r l Moul 67 ...... • c. ORei 76 ...... Fong Fong F o u l Orga 73 .. ... . . . . . . . . . . 1 . . 60 Palm 77 ,. .... ........... fi Panz 76 ......... 101 Gain Pask 73 fio G a l l Peck 75 ........... 1SQ G e l l P i e r 74 & Glas P o l l 77 .. ... . . . . . fifi Goul Pool 73 ...... ... . . . . ..... 3 9 Gran P u l l 6 9 ...... ........ t; fio G r i s P y l e 71 S9 G r i s Rain 73 ...... ............. 3 G r i s Reis 75 .............. fi G r i s Rich 6 9 7 f i Habe Rich 77 ...... .. ... ....... 76 Had j H a l i Rust 71 .. ... - 116,121,125,131 B i b l i o g r a p h i c Reference Index 180 Sack 68 . . 10 S a t t 72 .. . 4,5,130 S a t t 75 3 Schw 71 3,27 Scow 72 3 S e i d 68 3 S i t e 71 ............... 4,5,49 Step 74 .................... 4 Stoc 65 .................... 4 Stoc 67 2 T e i t 69 2 Thorn 76 .................... 5 UWM 73 . . 4 VanT 74 3,112 VanH 76 ....... 28 Vene 76 ................ 74,92 Vers 64 6 V i c t 76a 8,134 V i c t 76b 8 V i c t 77 8, 100, 101 watt 74 28 Wein 71 4 wexe 76 12 Wile 74 6 Wile 76 .. . . ....... . 2 Wino 75 2 Wolm 72 .................. 5,6 Wort 72 ...... 60 Wulf 73 .... 90 Zelk 71 59,102,136 Ze l k 73 102 Zimm 67 .................... 4 181 General Index T h i s index uses a c o l l a t i n g seguence i n which s p e c i a l symbols precede a l p h a b e t i c c h a r a c t e r s and upper-case l e t t e r s precede lower-case l e t t e r s . • • • • • <action> <break-action> .., <c a l l - a c t i o n > .... <cancel-action> .. < c a n c e l - l i s t > .,,. <command> ........ <command-list> .,. <compound-action> <data-incident> .. <declaration> .... < d e c l a r a t i o n - l i s t > < d e f i n i t i o n > ..... <display-action> . < e x c e p t i o n - l i s t > . <execute-action> . <explanation> .... < e x p r e s s i o n - l i s t > <for-action> .. ... <generic-^incident> < i d - l i s t > > < i f - a c t i o n > .. <input-action> <inquiry> .... < i n t e g e r - d e c l a r a t i o n > <guit~action> .... <reference-action> <restore-action> . <save-action> .... <segment-incident> <segment-gualifier> <set-action> ...... <skip-action> ..... < s p e c i f i c > ........ < s p e c i f i c - d e c l a r a t i o n > . < s p e c i f i c - i n c i d e n t > .... < s p e c i f i c - i n c i d e n t - l i s t > < s u b s c r i p t e d - v a r i a b l e > . <system-action> ........ < u n g u a l i f i e d - v a r i a b l e > . <utterance> .. <variable> ... <what-list> .. <when> ....... <when-clause> <while-action> « • • • • • • • * • * • # * • • • • • • • • • * • • • • • • • • * *• * * '•*.'** • ' • '• •- * « • • '* • • • * • • * * a • • • # *' • » • • » • * • • • * * *" * • • • * • * * * * 35 36 36 37 37 32 36 36 34 31 32 32 37 32 38 31 34 39 34 31 39 39 31 31 40 40 40 40 .34 34 41 41 34 31 34 32 34 42 34 30 34 37 32 32 42 General Index 182 #ACCESSES system f u n c t i o n ...............«.....•.••..«•••••• 138 •ALLOCATIONS system f u n c t i o n • 138 #ENTBIES system f u n c t i o n ................ 138 •EXITS system f u n c t i o n • •. • • • 1 3 8 tOPDATES system f u n c t i o n ,.....,...,.,.....,..,.....,,.139 ABS i n s t r u c t i o n 156 ACCESS d a t a - i n c i d e n t .. •••».• 16 ACTION segment-generic ........................•.•*••.••••••« 51 ...... 156 . .. 6,121 4,115,119 • *'••'• . 15*7 156 ADD i n s t r u c t i o n AIDS system ..... ALCOR system .... ALLOC i n s t r u c t i o n AND i n s t r u c t i o n . APL language 120 ARPANET system ............................................. 115 ASSERT i n s t r u c t i o n 158 ATTENTION_INTERRUPT e x c e p t i o n .........................16,33 Abramson, Harvey David ..................................... 114 A l g o l 60 language 4,88,115,119,131 A l g o l 68 language .........,.,,.5,10,15,28,66,71,88,132,133,134 Algol-W language ....................... 4,5,49,50,88,93,130,131 Appelbe, W i l l i a m F r e d e r i c k .,.,.,.,...,,,,..114 Ara b i c proverb ....................... ...... •*.,..,*,,....... .97 Argus 700 machine * * ,......,•*.«, • ...................... 128 Ashby, Gordon ....«....................... 114 Asple language .................................. 75,107,108,110 Aspro language ., .............. 75,92,93,94 Aspro, implementation t o o l .................................. 93 BAIL system ..•,•»»,••••,..,,.,,...,«.,,..,.......,«......,6,129 BBN—LISP system .......................... •. . . . • . • • . 116 BCPL language .................. ,72,76,93,94,106,107,108,110,130 BCPL-V language ...................................... 76,93,106 BCPL-V, implementation t o o l 93 BLOCK segment-generic ....................................14,43 BNF. ».•..•..,'.•..•....,«,,.•....,..,.....,,,•...*,,,,,.,*,..,.•,* ,-30 BUGTRAN system ........................................... 6,119 Backus—Naur Form .............. .... . . . . . , ..... 30 B a i r d , George N 114 B a l l a r d , Alan John .........................................114 B a l z e r , Bobert M. •.....,.,,.<,.««,«., ..,,.,.9,115 Basic language ................................... .......... 117 Bauer, F r i e d r i c h Ludwig ....................................115 Baum, R.I. ................................................. 116 Bayer, Rudolf 115 Ber ner, E l i z a b e t h .. ....,.,,,.». •....,,.,.,,,.•,.••,*,,.,,., 119 B e r n s t e i n , W i l l i a m A. 115 Bierman, A.W. .. 116 B l a i r , James C u r t i s ........................................116 fiobrow, D a n i e l Gureasko .,....,.116 Bochmann, Gregor V. ,126 Boul ton , Peter I. P. .............................. ,. •..,, •', •, • 116 Brady, P a u l T.'» ,116 Brown, Arthur Robert • • 116 G e n e r a l I n d e x 183 Brown, Peter J . •..,»»•,.•»•,.,,•«»••»»..•«•»«•,«•»••.•«••»• 117 B u l l , G«M» ••••»»••••••••••••«•»•*»•»••••* ••••••••••»••••••• 117 B57 00/B6 700 machine ............. • ••• 128 B6700 machine . . 6 0 C A L L i n s t r uc t i o n ............. .......... •. .... .. ... • •... .. 153 CALLEB system f u n c t i o n •...•....*•..«<,•«,«.,.,.,137 CAPS sy s tem ... ........ ..... •••,,.«»»• ,... .. ... . •• ........••« 135 CASE i n s t r u c t i o n ................. •••<,•,•,,<.,.,,•« 154 CDC 6600 machine .......................................121,125 CMS operating system ...................., •. •.............., 127 COMMAND segment-generic .................... ................. ,51 COMMENT system f u n c t i o n 137 CONCAT i n s t r u c t i o n 156 CONSTANT d a t a - g e n e r i c ........................ 14,43 CONVEBT i n s t r u c t i o n ..................,.,............. ......,158 COPY i n s t r u c t i o n •... •. , •».. * • •, .... • .«. .... ,,...,,.,« ,. 155 CS-1 language ,.6,133 CTSS op e r a t i n g system .....,.,..,.,....,.,,,....,.,.........118 CUBBENT_BLOCK system f u n c t i o n 43 CUR RENT__ EXCEPTION system f u n c t i o n 137 CUBBENT_PROCEDUBE system f u n c t i o n 43 CUBBENT~PBOCESS system f u n c t i o n ............................ 101 CUBB EN T_ STATEMENT system f u n c t i o n 43 CUBBENT_segment-generic system f u n c t i o n .................... 139 CYCLE i n s t r u c t i o n ........ ..... ..............••...•••••••«•• 154 Cheatham, T.E., J r . ...........................117 Clapp, J.A 117 el-Uric^ B*Xi* • » • • » • • • • • • « • • • • • • • • • • • • • • • * * • • • • • * * • • • • .11*7 Cobol language ............................... 5, 114, 123,1.31,135 Conra d i , Beidar ...»•,,....,.,•,..,,,.,.,,,.......,»,»,.*,,, 117 Conrow, Kenneth ............................................ 117 Conway, Richard Walter 117,118,127 C o r a l language . ,.. , .......... ,«•*., ...., 6,128 Courant I n s t i t u t e • 130 Cr e s s , P a u l H. , ., ,,........ 118 Crisman, P.A. .............................................. 118 C u f f , R.N. ..... ... ..... ..... ... ,. 118 DAD system ••••••••«••,',•.»•«•,• .7 ,133,134 DDS system ••*••,••,••••«•..,,•,..«.>•,..,«.... . • • »• • • •...» ., 6,128 DEBUG system ....... 119 DEBUG_LEVEL system f u n c t i o n • 137 D E C L A I A T I O N _ L I S T system f u n c t i o n ...........................137 DECsystem-10 machine ................................ ... , 128,129 DEFDATA i n s t r u c t i o n ............................... ..... 152 DEFERRED_ACTION_LIST system f u n c t i o n .,.,..,......,......37,137 DEFINED system f u n c t i o n .,....,................... .......... 137 DEFSEG i n s t r u c t i o n ................................... ... ... 152 DEREF i n s t r u c t i o n 155 DITRAN system . .... .... ......... ...... •••.,,-*,,,•••,,,,.,, ,.5,127 DIV i n s t r u c t i o n ............................................ 1 56 DO— t r a c e ...... ........ ......... ,, . ,120 DUMP i n s t r u c t i o n ...........................................158 DWIM system ................................................ 132 General Index 184 DYDE system ............ Da r l e y , D. L u c i l l e ..... Davidson, James Edward . Davis, Alan Mark ....... Debugging S P E c i f i c a t i o n D e s j a r d i n s , P i e r r e ..... Dir k s e n , Paul H D i s p e l D i s p e l , design c r i t e r i a D i s p e l , examples ....... D i s p e l , semantics ...... D i s p e l , shortcomings ... D i s p e l , syntax ......... D i s p e l , syntax cha r t ... D o - A l l Debugger ........ Dynamic Debugging-Source ECL system ............. EMAS system ............ ENTRY segment-incident . ENVIRONMENTALIST system EQ i n s t r u c t i o n . EXDAMS system . f EXEC I I op e r a t i n g system EXIT segment-incident EXITSEG i n s t r u c t i o n . Ehrman, John R. En g l i s h Evans, Thomas G. FADEBOG-I system ..... FLASC system ......... FOR i n s t r u c t i o n ... ... Ferguson, H. E a r l F e r l i n g , H.-D. F i s k e r , R.G. ..... Fong, E l i z a b e t h N. F o r t r a n language . 5,6 Language • • • » * * » • • • • • • • • Foulk, C l i n t o n R. F r a l e y , Robert A. Friedman, Paul Froude, James Anthony GBDG system GE i n s t r u c t i o n ....... GET i n s t r u c t i o n ...... GOTO i n s t r u c t i o n ..... GRAIL system ......... GT i n s t r u c t i o n ....... Gaines, R. Stockton .. G a l l e y , S.W. ......... G e l l e r , Dennis P. ..., G l a s s , Robert L. ..... Goldberg, Robert P. .. Gould, John D. ....... f u n c t i o n .......... * • • • • * • • • * * • * • * • • • • * * • « • • • * • • • * • • * * • • * * * •' * » « • « • • * * * • • • * • • • • • • • • * * 1 *' * * ' • • * • • • • » • * * * * • • *. • * • • * * * *' • * • • • • • • • * • »: • • »• 15 • • • • ,89,9 1,110, • • • • * 114, • * • 118, • • « • • • • • 119, 120, • • i • * • • '* '•' .* J* .126 ,127,128 • • 4 ***** • * * • * * * • • * • • • • • « 4 • • • • • • • • • • • * • • • • • • • • • * • • • • * ' * * * * * • • « .......... 124 119 ...... 122,134 ...... 118,134 27 125 .......... 1 18 ... . . 22,27,74 27,29,52 ........... 42 ........... 30 54 ........... 30 .......... 140 .......... .7 ..........128 .......... 115 .......... 131 ... ........ 16 .......... 137 .......... 156 6,115,119,122 .......... 120 ... ........ 16 153 ... .... 59,118 30 .......... 119 .......... 123 5,132 ........... 67 • * * • * * • * * • • • • ••*••••••••• ./3 .......... 136 .......... 156 . 157 ........... 68 ........... 75 156 120 .......... 120 120 120 .......... 120 121 General Index 185 Graham, J. Wesley ,.......................... 118 Grandaqe, B. ............................... 129 Grant, E.E. 121 G r i e s , David 115 Grishman, Ralph ............................................ 121 Gr i s w o l d , Ralph E 121,122 HELPER system ............................................ 6,125 Habermann, A r i e N i c o l a s s ................................... 122 Hadjioannou, Michael ....................................... 122 Hafner, C a r o l e .............134 H a l l , Wayne ............. 122,134 Halpern, Mark .............................................. 122 Ham, F.J.B. ................................................ 117 Hanson, David R. ........................................... 122 Heilman, Robert 114 Hueras, Jon 125 IBM System/360/370 machine ...................61,75,114,124,127 IBM 2260 g r a p h i c d i s p l a y t e r m i n a l .......................... 124 IBM 2741 t y p e w r i t e r t e r m i n a l ............................... 127 IBM 7090 machine ......119,126 ICL 803 machine 117 IDA o p e r a t i n g system 125 IF i n s t r u c t i o n ............... • • • • 67 IF system ..................... . 6,1 27 IMP language 4,131 INTEELISP system ..... 6,115,116 I n g a l l s , D a niel H. H. 123 I n t e r n a t i o n a l Business Machines C o r p o r a t i o n 123 I t o h , D a i j u ....................... ......................... 123 I z u t a n i , Takao ............................................. 123 Jeanes, David L. ..............,, 116 Jensen, Kathleen ........................................... 123 JOnsson, Sven Ingvar ....................................... 124 Johnson, Mark Sc o t t ...,.....,,...,,..,.,.,.,,.....,...,,114,123 Josephs, W i l l i a m H. ., 124 kernmerer, R i c h a r d A. ....................................... 124 K i r s c h , Barry M. 124 Knobe, Bruce S. 124 Knuth, Donald E. 124 Kocher, Wallace ............................................ 125 Koster, C o r n e l l s H.A. ......................................133 Ku l s r u d , Helene E. 125 LANCE system 92 LANCE, implementation t o o l 92 LANGUAGE system f u n c t i o n 137 LBOUND i n s t r u c t i o n ......................................... 157 LE i n s t r u c t i o n ............. ................................. 156 LENGTH i n s t r u c t i o n . 1 57 LINE system f u n c t i o n ............................ ,,,,,.., 37, 138 LISP/MTS system ...................................... 6,122,134 LT i n s t r u c t i o n 156 Lampson, B u t l e r W. ....................................... 9,125 Lecarme, O l i v i e r 125 G e n e r a l I n d e x 186 Ledgard, Henry F. ,125,126 Leeds, Herbert D. .......................................... 126 L e s t e r , Bruce P, 126 Lindse y , C H .. 133 L i s p language ............................ 15,71,115,122,132,134 MANTIS system ., ....................................6,114 MARKSS i n s t r u c t i o n ......................................... 152 (UNICODE machine 76 HOD i n s t r u c t i o n ............................. 156 MTS o p e r a t i n g system ..,...,..........,.....,..,..,...,.,114,127 MUL i n s t r u c t i o n ....................................... 156 M a i l l o u x , Barry J . 133 Manis, V i n c e n t Stewart ..................................... 130 Mann, George A. ............................................126 Marcotty, Michael ... . . . . , . . , , . . . . . . . . . . . . . ,. 126 Mathis, Robert F. ...... 126 McDonald, David B l a i r ...................................... 134 McLatchie, B.C.F. .......................................... 129 Meertens, Lambert G.L.T. ................................... 133 Mencken, Henry L o u i s 87 M i l l e r , Alan 127 M i l l s , Harlan D. .............,......,,.,...,,.,..,..,.,,,1,127 Monty Python ................................................61 Moore, C G . , I I I 127 Moore, C h a r l e s , J r . ................................118 Morgan, Howard L. 127 Moulton, P.G. ........................ , . , . . . . , . 127 Mu l l e r , M,E. .......... . . . . . . . . , , . , . . . . . . . . . , . , . . . . , . 127 M u l t i c s o p e r a t i n g system ................................. 6,135 NAME system f u n c t i o n ........................................ 57 NE i n s t r u c t i o n ............................................. 156 NEATEB2 • ... .... 117 NEG i n s t r u c t i o n 156 NEHBT i n s t r u c t i o n 70 NOOP i n s t r u c t i o n ..........158 NOT i n s t r u c t i o n ....,..........,,.......,...,.........,.*.•• 156 Na t i o n a l Software Works .................................... 133 0« B e i l l y , Dennis ........................................... 127 OFFENDER 57 OLDS system 132 OR i n s t r u c t i o n 156 OS/360 o p e r a t i n g system 124,131 OVERFLOW exce p t i o n . ,., . ,. ... 16,33 Organick, E l l i o t I r v i n g 128 Owens, James T................, ,....,,,,. 115 PAGE system f u n c t i o n 37,138 PARAMETER d a t a - g e n e r i c ... 14,43 PARM i n s t r u c t i o n ...................,, ,.,, ,. ...... . •••,,.... 153 PASCAL/UBC system ................................. 88,90,91,128 PEBOG system . . . . . . . ....116 PILOT system .., 132 PL/C system ................4,5,118,127,135 PL/CT system , . . . . . 6,127 G e n e r a l I n d e x 187 PL/I Checkout Compiler 6 # 118 PL/I language . 5,6,15,36,72,84,85,86,88,90,114,115,116,117,118, ..... 120,123,127, 129,131,135 PL/I, r e f l e c t i o n s ................,...,,........,....•...... • 84 PLATO IV d i s p l a y t e r m i n a l .................................. 135 PLUTO system ,............................... 5,116 PL360 language ...........................................,. ,114 POODL machine 129 POP i n s t r u c t i o n 155 PEED i n s t r u c t i o n , 156 PROCEDURE dat a - g e n e r i c ............... ....................... 51 PROCEDURE segment-generic .............. .......... .,,..... 14, 43 PROCESS segment-generic ..................................... 14 PUSHR i n s t r u c t i o n .......................................... 155 PUSHV i n s t r u c t i o n .......................................... 154 PUT i n s t r u c t i o n 156 Palme, Jacob ........... ............,............. .......... 128 P a n z l , David J . ............................................ 128 P a s c a l language . 63,71,85,86,87,88,89,90,91,92,107,108,117,122, . ...... 123 ,124,125 P a s c a l , r e f l e c t i o n s 87 Pasko, Henry John .......................................... 128 Pau l , M 115 Peck, John E.L. ............. 128,130,133,134 P i e r c e , R.H. 128 Poage, J.F. ................................................ 121 P o l l a c k , Bary William 128 Polonsky, I. P. 121 Pomfret, John .............. 1 Poole, P.C. ................................................ 129 Pullam, John M. 129 . ,129 9,124 ..12 9,13 . 100 19,73 95 P y l e , I . e . RAIDE ................ RAIDE, concepts ....... BAIDE, design c r i t e r i a RAIDE, e x t e n s i o n s RAIDE, implementation . RAIDE, importance ..... BAIDE, i n t e r n a l design 76,77 RAI DE, overview 20 RAIDE, program s p e c i f i c a t i o n example ....,..,..........,..,.,177 BAIDE, shortcomings ......................................... 97 RAIDE, symbol t a b l e examples ................................170 RANGE system f u n c t i o n 137 REFERENCE_POINT system f u n c t i o n 138 Rain, Mark 129 B e i s e r , John F. 129 Ri c h a r d s , Martin .........»................................. 130 Bun-time A n a l y s i s and I n t e r a c t i v e Debugging Environment 9 R u s t i n , Randall • 130 SDS system .....................................114 SELECT i n s t r u c t i o n .........,, , 155 SETBT i n s t r u c t i o n .......................... ,. . , .. .... . . .... ,157 General Index •J88 SHARE op e r a t i n g system • 126 SIGNAL i n s t r u c t i o n ., . ., ... .... ... .158 SIMDDT system ...........................6,128 SKIP i n s t r u c t i o n ................. 154 SLICE i n s t r u c t i o n .......................................... 155 SPACE system f u n c t i o n 138 SPAM . . . , ................... ., 22, 59 SPAM D e s c r i p t i v e Object Language ............................ 66 SPAM t a b l e e n t r y formats 149 SPAM, a r c h i t e c t u r e ............................. 61,62 SPAM, d e s c r i p t o r formats ................................... 144 SPAM, design c r i t e r i a , 59,68 SPAM, ex t e n s i o n s ........................................... 100 SPAM, i n s t r u c t i o n s ................................,. . ,.... .. 1 52 SPAM, o b j e c t program example ...............................159 SPAM , shortcomings .......................................... 70 SPLINTER system .......................................... 5,120 STATEMENT segment-generic ...14,43 STATEMENT_FAILUBE e x c e p t i o n ................................. 17 STOP i n s t r u c t i o n ........................................... 158 STORE i n s t r u c t i o n .......................................... 155 SOB i n s t r u c t i o n ............................................ 156 SUBSTR i n s t r u c t i o n ......................................... 156 SOCC i n s t r u c t i o n ...,......,,.156 SWAP i n s t r u c t i o n ........................................... 155 Sackman, H. 130 S a i l language .6,129 Salmonson, Loren ..................... ...................... 114 Sampson, W.A. .....,...........,...,..,............••»••«.•« 116 S a t t e r t h w a i t e , Edwin H a l l o w e l l , J r . ........................ 130 Schmitt, H. 119 Schwartz, Jacob T. ..............................131 Scowen, R.S. ..131 S e i d e l , Kenneth P 131 Shakespeare, W i l l i a m .. ............... 73,152 Shaw, Mary 135 Silverman, M. 116 Simon 117 Simula language ...................... ................ 6,124,128 Si n g e r , Andrew 125 S i n t z o f f , Michel ....................................... 133,134 S i t b o l language ......................... 123 S i t e s , Richard L. .......................................... 131 Smith, Ronald. G. 117 Snobol4 language ............... ......... 4,15,17,71,121,122,123 Spamdol language ..................................... 66,67,152 Spamdol, examples 66,67 S p e c i a l i z e d Prodebugging A b s t r a c t Machine ................... 59 Stephens, P.D. ............................................. 131 Stockham, Thomas G. , J r 131 S t r e l e n , Chr. 119 Strunk, W i l l i a m , J r ..........,,.,,................. 132 Sue language ......................................... 63,88,117 General Index 189 Sul1ivan, J•E. •••<•••.•«<•<••....«..«.«>«<«...««<«.««.<«.«« 117 Symbolic Debugginq System .................................. 114 TAB system f u n c t i o n .......................138 TALK system . .. . ...... .. .. •. •«•«,. ,.».,. ,..*«>........ 6,133 TENEX o p e r a t i n g system ................................<.«.. 129 TESTYPE i n s t r u c t i o n ........................................ 157 TOPS-10 o p e r a t i n g system ,...,........,..,...129 TOSI system .................. ..... .................... 74 ,92,93 TOSI, i mplementation t o o l ................. . 92 TPL language •..•...,«,.,....,..,...,....,,,,..,..,...,.•,,. 128 TBUST system ...................................... 74,92,93,133 TRUST, implementation t o o l 92 TYPE system f u n c t i o n ....................................... 138 Teitelman, Warren . ......................................... 132 Test Procedure Language • 128 Texture ... ....,.,,.,»»..,,...,..,..,...,...,.....,.,..» 132 Texture Support Group ...................................... 132 Thielmann, H« ,,,•»•«•••»•.••,»,..,•,»,.«•,«»«»»*.».•••••••• 119 Thomson, C M 132 T i n d a l l , Michael H. ...........,,...,.,.,,...........,..,118,134 Towers of Hanoi SPAM code ........................161 Towers of Hanoi data s p e c i f i c a t i o n s ........................ 177 Towers of Hanoi i n i t i a l SPAM s t a t e ......................... 163 Towers of Hanoi segment s p e c i f i c a t i o n s ..................... 178 Towers of Hanoi source program ............................. 160 UBOUND i n s t r u c t i o n ......................................... 158 U NC OL language .... . ...... ...... ........... 60 U NSPEC f unction ,72 UPDATE d a t a - i n c i d e n t ................................. ....... 16 Univac M—460 machine • 119 Univac 1108 machine ........................................120 Univac 1110 machine ...132 U n i v e r s i t y of Wisconsin at Madison ......................... 132 VALUE system f u n c t i o n ........... 138 VARIABLE d a t a - g e n e r i c 14,43,51 VDL .... 126 Van T a s s e l , Dennie L. ...................................... 133 Venema, Tj e e r d •••,•«•««••»•••»,,«,•»•,••,,,»»•••,..••«••»••.133 V i c t o r , Kenneth E. .....................................,133,134 Vienna D e f i n i t i o n Language ................................. 126 Wagner, Robert A. 127 Waldschmidt, H. ....... , 119 Watbol 1 anguage .... ...,»v.,• •» • • • • •»• • • • • * * • • *• * * * • * 5 Watfiv language ...............,.,........ ............. 5,71,118 Wat f o r language .... .... , . . , . , , . . . . . . . ,. •118 Watt, J.M. ................................................ 134 Wegbreit, Ben 117 Weinberg, Gerald M. ..........................,....... 4,126,134 Wexelblat, Richard L. ...................................12,134 White, E.B. . 1 3 2 Wiehle, H.R. ... .•••••«•••••••••••••«••••• 115 Wilcox, Bruce .............................................. 134 Wilcox, Thomas R. 117,118,134 General Index 190 Winograd, Ter r y ............................................ 135 B i r t h , N i k l a u s ............................................. 123 Wolffian, B. L. ... . ..,, .. 135 Worcna, Steven L. ...................................... 118,127 Wortroan, David Barkley ................................135 Wulf, W i l l i a m , .. ,135 Yuval, Gideon 124 ZEEODIVIDE exception ........................................ 33 Zelk o w i t z , Marvin V 135,136 Zimmerman, Luther L. ....................................... 136 a c c e s s i b l e environment l i s t .................,..........,. ... 19 a c t i o n ........................ .....................17,141 a c t i v e debugging .............................,,.....,..,,.,131 a n a l y s i s 11 a n a l y s i s f u n c t i o n s ......................... ... ........... .. 138 a n a l y s i s i n f o r m a t i o n .. 112 angle b r a c k e t s ...... 30 a r c h i t e c t u r e , SPAM 61,62 a r i t h m e t i c and s t r i n g i n s t r u c t i o n s 156 a r r a y d e s c r i p t o r ........................................ 65,147 b a s i c machine l e v e l 24,83 batch p r o c e s s i n g ,. ., 3 b i b l i o g r a p h i c index ........................................ 179 b i b l i o g r a p h y , 114 bin a r y i n s t r u c t i o n s 156 block depth_counter debugging procedure 47 bo l d f a c e ........................... 30 bounds name mapping t a b l e .......................,..,,..,.,.. 78 bounds name t a b l e 78 bounds t a b l e ........... . ... ....»,, •... 63,66 bounds t a b l e e ntry 149 braces 30 breakpoint 44,112 bug 112 bug c o n t e s t ., 129 bug farm ................................................... 129 c a l l e r n debugging procedure 55 c a n c e l _ d e f e r r e d _ a c t i o n s debugging procedure ................. 51 code area 63 concepts, RAIDE ....................................... .,, . .. 12 c o n c l u s i o n s 94 c o n d i t i o n 143 c o n t i n u a l e v a l u a t i o n 35 data access i n s t r u c t i o n s ,154 data d e s c r i p t o r ...................... ................... 65,145 d a t a - g e n e r i c .................., ,..... .......,,,... 14 d a t a - s p e c i f i c symbol t a b l e entry 164 debugger generator system ...,..,,,.,,,.,,,.,...,.,.,...,,,.103 debugging . , 112 debugging d a t a - s p e c i f i c symbol t a b l e entry 168 debugging f u n c t i o n .......................................... 55 debugging procedure ................................ 17,32,36,40 debugging process ............................................ 2 General Index 191 debugging s e g m e n t - s p e c i f i c symbol t a b l e entry 169 debugging subroutine ......................................... 5 debugging support, l e v e l s .......................,.........,,25 debugging system .............. .,........................... 112 debugging tec h n i g u e s ................................... •...., 3 debugging value stack ....................................... 79 debugging v a r i a b l e .......................................,31,41 debugging v a r i a b l e l a b e l .................................... 56 d e c l a r a t i o n l i s t 18 d e f e r r e d a c t i o n 17,32 d e f e r r e d a c t i o n l i s t , 17, 32,36, 51 deluxe debugging l e v e l ........26,84 demon 17 d e s c r i p t o r 65 d e s c r i p t o r formats, SPAM 144 design c r i t e r i a , D i s p e l 27,29,52 design c r i t e r i a , BAIDE , 9,13 design c r i t e r i a , SPAM 59,68 dia gnos i s ..................... d i a g n o s t i c system ............. d i a g n o s t i c t r a n s l a t o r ......... d i s p l a y b u f f e r ................ d i s p l a y format f u n c t i o n s ...... ... 2 . 101 • • * .5 ,. 37 138 do_.tr ace debugging procedure ......... .... .. ......... ,....... 47 d o _ t r a c e _ a l l debugging procedure 47 d s s p t r ,.... .. ... ........ 64 dump ..................112 dynamic e v a l u a t i o n .......................... 35 dynamic storage stack ....................................... 64 each ............... ... 34 e m p i r i c a l s t u d i e s 102 entomology ..............................112 environment ...,..,...,......... 19,40 e s p t r ....................................................... 65 event ... ................. 16 event symbol t a b l e e n t r y ................................... 167 examples. D i s p e l .............................................,42 examples, Spamdol 66,67 examples, g e n e r i c s .......................................... 15 exception ...................... , 16 exe c u t i o n p r o f i l e .......... 112 e x e c u t i o n _ p r o f i l e debugging procedure 45 ex p r e s s i o n . ........... 143 expres s i o n stack .. 65 ex t e n s i o n s , RAIDE .............. ...... .................. •. 100 ex t e n s i o n s , SPAM ...........100 f i g u r e s .. 20,62,77,144,145,147,148,149,150,160,161,163,164,165, ......................... 166,167,168, 169, 172,17 3,174,176,177,178 flow t r a c e ....112 f r e e storage area ........................................... 65 f u l l a n a l y s i s l e v e l 26 f u l l debugging l e v e l ..................................... 26,84 f u l l - s t o p 30 General Index 192 f u t u r e d i r e c t i o n s ..,..................... .................. 100 gen e r i c »»«,««•».«»,••,*«•«•«»»».••«.,»•«»»»»••••»•••»••»«»•» 14 ge n e r i c symbol t a b l e entry ................................. ,166 g e n e r i c - i n c i d e n t ................................. ......,. .. 142 g e n e r i c - r e l a t e d system f u n c t i o n s ......... . , ,.............«• • 43 g e n e r i c s , examples ............. ............................. 15 g l o s s a r y ..................,. .................. •...»........ 112 homonym chain ........................ . . . , . . . . . . . . 80,170 human f a c t o r s * * , « . . , * , . , . * . . . . . . . . . . ... *..,*,,..••• •.,,,93 i d e n t i f i e r access h i e r a r c h y .......... ..........,. .......... 171 i d e n t i f i e r hash t a b l e ....................................... 79 implementation t o o l , Aspro ........... ............ ........... 93 implementation t o o l , BCPL-V ................................. 93 implementation t o o l , LANCE .................................. 92 implementation t o o l , TOSI 92 implementation t o o l , TRUST 92 implementation t o o l s , r e f l e c t i o n s ........................... 84 implementation, RAIDE ........... 19,73 imports nee , R AI D E .......................... ................. 95 i n c i d e n t ..... ... 16 index 181 i n s t r u c t i o n s , SPAM ............. *...........................152 i n t e g e r v a r i a b l e ., 31 i n t e r a c t i v e processing ............... ............ ...... ... ,.• 3 i n t e r a c t i v e request mode ................................. 16,36 i n t e r f a c i n g a language to RAIDE .......................... 21,80 i n t e r f a c i n g a t r a n s l a t o r t o RAIDE .......... v...y......... 23,82 i n t e r f a c i n g a t r a n s l a t o r t o SPAM 22 i n t e r n a l d e s i g n , RAIDE .......... ................. ......,. 76,77 i n t r o d u c t i o n 1 language-dependent system f u n c t i o n s 139 language-independent debugging .........,..................... 7 l e v e l 64 l e v e l s , debugging support ................................,.... 25 l o g i c e r r o r .......................................... ...... 112 lower-case i d e n t i f i e r s ............... ...... ,..,.....,,...... 30 machine debugging l e v e l f......................... .., 24 machine-language debugging 4 miscellaneous i n s t r u c t i o n s ................» .... ......... ... 158 motto of New York s t a t e 100 o b j e c t program example, SPAM ...............................159 order ......... ............ 64 output d i s p l a y d e v i c e .,...........,.,..................•.... 37 overview, RAIDE . . . . . . . . . . . . . . . . . . . . . . . 20 p a s s i v e debugging .................,,...,........••.,....... 131 pop_scs Spamdol procedure 67 postmortem debugging procedure ............................., 49 postmortem dump ..,...,......... ..........,. ... ......, . 4,49,112 print_debug_proc debugging procedure . . . . , . , . . . . . . . . . 5 2 p r i n t _ d e f e r r e d _ a c t i o n s debugging procedure .................. 51 process c o n t r o l stack ...................................... 101 process d e s c r i p t o r .... ............... .... ............,.,,.. 101 p r o f i l e ,....... 45,113 General Index 193 program , . ...... • • • « 1 3 program development c y c l e 1 program s p e c i f i c a t i o n example, RAIDE 177 gu e s t i o n mark .................»...... .... .. .............. ... 44 q u o t a t i o n s ......... ...... 1,3,4,9, 12,59,61, 73,87,97, 100,152,159 r e c o g n i t i o n .. ,.......,..... 2 rec u r s i o n _ b r e a k debugging procedure ......................... 49 r e f e r e n c e point ....... , ,,,. 18,40,41 r e f e r e n c e s 114 r e f l e c t i o n s , PL/I 84 r e f l e c t i o n s , P a s c a l ,................................ 87 r e f l e c t i o n s , implementation t o o l s 84 re v e r s e program e x e c u t i o n ............ ...................... 102 scope stack 64 scope s t a c k e n t r y d e s c r i p t o r ............................... 148 s c s p t r ,. 64 segment 63 seg ment c o n t r o l i n s t r u c t i o n s ................. . . . . . . . . . . , . 152 segment c o n t r o l stack ....................................... 63 segment c o n t r o l stack e n t r y d e s c r i p t o r .....................148 segment d e s c r i p t o r ............................,.....,... 65,144 segment-generic ,14 s e g m e n t - g u a l i f i e r ...................................... .... 142 se g m e n t - s p e c i f i c symbol t a b l e entry ........................ 165 semantic e r r o r ............................................. 113 semantics, D i s p e l , 30 shortcomings. D i s p e l ........................................ 54 shortcomings, RAIDE ...................................... . .. 97 shortcomings, SPAM ...,..., ..... 70 sim pie symbolic leve1 .................................... 24,83 snapshot dump . . .'',*"."." ......... 113 s p e c i f i c , ..,14,142 s p e c i f i c v a r i a b l e ... 31 s p e c i f i c - i n c i d e n t .......................................... 142 square brackets 30 s s p t r 64 s t a t i c e v a l u a t i o n ........................ 35 s t a t i c s t r u c t u r e ..............,,...................-,..... 26 s t a t u s f u n c t i o n s ........................................... 137 s t a t u s i n s t r u c t i o n s ,....,,.. . .. ,,.,,«. 157 storage management i n s t r u c t i o n s 157 s t r i n g area ..........., ,. , . • 79 s t r i n g index t a b l e .......................................... 78 student c o m p i l e r s ...................., 5 subr o u t i n e t r a c e ........................................... 113 su g g e s t i o n s , t r a n s l a t o r design ............................. 103 summary ................. 94 su p e r _ s e t debugging procedure ..........................,,.., 57 s y l l a b l e , . . 6 3 symbol t a b l e , 79,164 symbol t a b l e examples, RAIDE ............................... 170 symbolic debugging ......................................... 113 symbolic debugging l e v e l 26,84 General Index 194 syntax c h a r t , D i s p e l ....................................... 140 syntax, D i s p e l ..30 system f u n c t i o n symbol t a b l e e n t r y ......................... 168 system f u n c t i o n s 18,137 system of programs .......................13 t a b l e s 13, 15,21,22,23,25,29 tea c h i n g debugging . • •. *. .... 103 t e s t procedure ............. ...................,....... .....101 t e s t i n g 113 t r a c e .......... .............. ..................,42,113 t r a c e _ p r o c _ c a l l s debugging procedure ........................ 46 traceback ........ 5, 113 t r a n s i e n t d e f e r r e d a c t i o n ..............................,.,17,38 t r a n s l a t o r design, s u g g e s t i o n s 103 transput i n s t r u c t i o n s ...................... 156 t r a p 17 type name t a b l e .............................................,76 type t a b l e ............................................... 63,66 type t a b l e entry • • 150 u g l y p r i n t .................................. ..........••..... 86 unary i n s t r u c t i o n s ................................,.,...,,. 156 undo command ............................................... ,102 unexecute a c t i o n ............................... ......,.,,.*.102 u n g u a l i f i e d - v a r i a b l e ................................... ... .. 142 upper-case i d e n t i f i e r s ....................................,. ,30 utte r a n c e *. .................... 140 van den Bosch, P e t e r Nico .................................. 132 van Hijngaarden, Aad 133 v a r i a b l e ..............................................-..... 142 v a r i a b l e p r o f i l e ...................... 113 v a r i a b l e t r a c e 113 v a r i a b l e _ s c a n debugging procedure ........................... 57 ver Steeg, B.L. ........................................,.,. 133 v i r t u a l debugging machine (see a l s o SPAH) 59 von Goethe, Johann Wolfgang 159 w i t t i c i s m s ........ . . . . . . . . . . . . . . . . . . . ....y9,27,59,86,97,1 12,120 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051800/manifest

Comment

Related Items