DOCSLIB.ORG

A Survey of Current Debugging Concepts

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Survey of Current Debugging Concepts NASA CONTRACTOR REPORT h c14 m v I PL U 4 r/) 4 z A SURVEY OF CURRENT DEBUGGING CONCEPTS by WaZZace Kocher Prepared by WOLF RESEARCH AND DEVELOPMENTCORPORATION Bladensburg, Md. for Goddard Space Flight Center NATIONALAERONAUTICS AND SPACE ADMINISTRATION WASHINGTON, D. C. AUGUST 1969 TECH LIBRARY KAFB, Nhl 0060538 NASA CR-I397 A SURVEY OF CURRENT DEBUGGING CONCEPTS By Wallace Kocher Distribution of this report is provided in the interestof informationexchange. Responsibility for thecontents resides in the author or organization that prepared it. Prepared under Contract No. NAS 5-9756-99 by WOLF RESEARCH AND DEVELOPMENT CORPORATION Bladensburg, Md. for Goddard Space Flight Center NATIONAL AERONAUTICS AND SPACE ADMINISTRATION For sale by the Clearinghouse for Federal Scientific and Technical Information Springfield, Virginia 22151 - CFSTl price $3.00 TABLE OF CONTENTS Section Page I INTRODUCTION - - - - - - - - - - 1-1 1-1 Need for DebuggingDevelopment - 1-1 1-2 Scope of ThisReport - - - - - - 1-1 1-3 DebuggingAspects, Definitions - 1-2 1-4 Categories of Programming Errors 1-3 1-5 Phases of Debugging - - - - 1-4 1-6 Error Diagnostic Procedures 1-4 ._ I1 IMP-F PROGFAM DEBUSGING - - 2-1 2-1 Description of the Programs 2-1 2- 2 Programmer Comments - - - - 2-2 2-3 InterviewGuidelines - - - - 2-3 I11 CURRENT DEBUGGING CONCEPTS - 3-1 3- 1 CurrentConcepts - - - - - - 3- 1 3-2Preliminary Testing - .- 3-1 3-3 Checkingthe Flow Chart 3-1 I 3-4 Linkingthe Flow Chart to the Coding 3-3 3-5Concluding Steps 02 PreliminaryTesting 3-3 3-6 Assemblingand Coqillng L""""_ 3-4 3-7 AssemblerAids - - - - - - - - - - - - - 3-4 3-8Compiler Aids - - - - - - - - - - - - - 3-5 iii .... ". - ._._ TABLE OF CONTENTS (Continued) Section Page 3-9Macro-Instructions - - - - - - - - - - - - - - 3-7 3-10Debugging Macros - - - - - - - - - - - 3-7 3-11Advantages ofDebugging Macros - - - - 3-8 3-12 The SDC-SFARE DebuggingPackage - - - - 3-9 3-13Inserting' Diagnostic Instructions - - - - - - 3-11 3-14 B~~~ - - - - - - - - - - - - - - - - - - - - 3-12 3-15Postmortem Dumps - - - - - - - - - - - 3-12 3-16Snapshot Dumps - - - - - - - - - - - - 3-13 3-17Inconveniences of PresentTechniques - 3-13 3-18Efforts to Improve Dumping Techniques - 3-14 3-19 The ALCOR Illinois 7090./7094 Post Mortem Dump - - - - - - - - - - - 3-15 3-20 The UNIVAC 1108Executive Systems - - - 3-18 3-21 The Snapshot Dump - - - - - - - 3-19 3-22 The Postmortem Dump - - - - - - 3-20 3-23 Traces - - - - - - - - - - - - - - - - - - - - 3-20 3-24Possibilities for Limitingtke Trace - 3-21 3-25Trapping - - - - - - - - - - - - - - - 3-22 3-26 Static Trace - - - - - - - - - - - - - 3-22 3-27Improved Approach toTracing - - - - - 3-23 3-28 The SEFLO TracingTechnique - - - - - - 3-25 3-29Dynamic Debugging - - - - - - - - - - - - - - 3-25 3-30 FORTRAN DebuggingLanguages - - - - - - 3-27 iv TABLE OF CONTENTS (Continued) Section 3-32 DIAGNOSE, Another FORTRAN DebuggingLanguage - - - - - - - 3-28 3-33 BUGTRAN, Another FORTRAN DebuggingLanguage - - - - - - - 3-30 3-34 TESTRAN, for IBM System/360 - - - - - - 3-32 3-35 Introductionto TESTRAN - - - - 3-32 3-36 Procedure - - - - - - - - - - - 3-33 3-37 The "Rip Stopper" Method - - - - - - - 3-35 3-38 The WATCHR I11 System - - - - - - - - - 3-36 3-39 TIDY and EDIT for FORTRAN - - - - - - - - - - 3-40 3-40 The TIDY program - - - - - - - - - - - 3-40 3-41 The EDIT Program - - - - - - - - - - - 3-42 3-42 AutomaticFlowcharting - - - - - - - - - - - - 3-43 3-43 The AUTOFLOW System - - - - - - - - - - 3-43 3-44 Testing - - - - - - - - - - - - - - - - - - 3-44 3-45 Purposes - - - - - - - - - - - - - - - 3-44 3-46 Problems - - - - - - - - - - - - 3-45, 3-49 Satellite Test Data - - - - - - - - - - 3-46 TABLE OF CONTENTS (Continued) Page 4-1 On-Line Debugging Techniques - - - - - - - - - - - - 4-1 4-2 Criteria for an On-Line Debugging System - - - 4-2 4-3 The Programmer-Controlled Breakpoint - - - - - 4-2 4-4Assembler-Language Program Debugging: The DDT System - - - - - - - - - - - - - - - 4-3 4-5 Higher-Level Language Debugging - - - - - - - 4-7 4-6 The LISP System - - - - - - - - - - - - 4- 7 4-7 The QUIKTRAN System - - - - - - - - - - 4-9 4-8 The Incremental Compiler - - - - - - - - 4-9 vi SECTION I INTRODUCTION 1-1. NEED FOR DEBUGGING DEVELOPMENT Debugging is a general term that refers to the loca- tion and correction of errors that occur in computer pro- grams. The debuggingactivity may consume considerable portions of the total time required for the complete pro- gram development.However, the importance of thisarea of programdevelopment has often been minimized. The purpose of this report is toplace some emphasison this important area and to present some ofthe current debugging concepts which may beconsidered for implementation. Computers are continually becoming faster andmore complex,and applications becoming more extensive, more intricate, and more time-critical. Thus,the need for a greatereffort in the area of debugging is obvious. Two of the major €actors which make program errors both harder to find and harder to tolerate are time-constrained program- ming andclosed-loop applications. These are particularly applicable to many of the space-related programs. 1-2. SCOPE OF THIS REPORT The projectthat has famished impetus to this report is the IMP-F (InterplanetaryMonitoring Platform). Becausethe IMP-F computer program complex will form the basis for future IMP efforts, it was necessary to document the present version as fully as possible in order to reduce the lead time andcost of developing the follow-on IMP 1-1 complexes. One importantarea (and the subject of this paper) is debugging.This report includes, in addition to thedocumentation of the IMP-F debuggingeffort, a survey of currentdebugging concepts which may beconsidered for implementationin future programs. 1-3. DEBUGGING ASPECTS, DEFINITIONS For thepurposes of thisreport, debugging will be considered to includelogical and clericalerrors but not machinemalfunctions. To be more specific,debugging includesprevention, detection, diagnosis, recovery, and remedy ofprogram errors. It is anon-going process that lasts for theentire lifetime of theprogram. The following 1 definitionsclarify the above mentioned aspects: a. Prevention - protectiveaction taken against theoccurrence of errorsor omissions. b. Detection - determination of theoccurrence of anerror or ofan omission at the earliest pointpossible so as to limit theconsequences. C. Diagnosis - analysisof the error that was detected. d. Recovery - provision for ameans of bypassing anerror coniiition, especially one ofan intermittent nature, with a minimum loss of timeand effort. 1-2 e. Remedy - rapidremedial action employed to preventfurther occurrences of the same or similar errors andomissions. 1-4. CATEGORIES OF PROGRAMMING ERRORS Programming errors fall into two basiccategories - logical and clerical. Logicalerrors are those which involve problem analysis.Although they occur less frequently than 'clerical errors they are usually more serious andmore difficult to detect.Since they often occur early in theprogram writing process,they have a tendency to beoverlooked. Frequently they are a result of amisunderstanding of theproblem and requirements.Often, in very complex programs, errors result from failure to cover all possible alternatives that may arise, fromimprope-r identificationof storage areas, etc. Clericalerrors are those errors which involve the inputdeck or otherinput media; these errors are sometimes referred to asphysical errors, and errors made in writing symbolicinstructions. Numbers may betransposed, cards may beomitted or mispunched,a symbolic namemay be spelled more thanone way, to mentiona few types of these errors.Frequently these errors are the result of careless- ness. Onecommon source of sucherrors may beavoided by keepingprogram listings and decks up to date; old versions should be destroyed or at least marked. ._ . .. "" ~ __""""_""____"..__I __" . ~ T"" "" - 1-5. PHASES OF DEBUGGING The debuggingprocess is generallythought of as 2 consisting of several phases: a. Desk checking. b. Assembled or compiledprogram checking. C. Program-testingusing test data. d. Error diagnostic procedures. e. Runningof program using actual data. 1-6. ERROR DIAGNOSTIC PROCEDURES Inthis report, emphasis is placed on thephase dealingwith error diagnostic procedures. A number of programsand programming techniques are available for diagnosticpurposes. Their underlying principle is to provide information about a particular portion or portions of theprogram as control passes through the specified instructions. The amount arid location of theinformation will varydepending on thenature of theerror. Proposals havebeen EaGe fordeveloping software that will allow debugging to beconducted using the same languageas the sourceprogram; however, few of thesehave been implemented. Few if anycomputer systems or majorlanguages today.pro- videcomprehensive symbolic debugging software packages. 1-4 SECTION I1 IMP-F PROGRAM DEBUGGING 2-1. DESCRIPTION OF THE PROGRAMS Informationconcerning the debugging of time- correction anddecommutation programs for the IMP-F space- craft vas collected through a series of interviewswith programmersand project managers associated with the pro- ject. The IMP-F time-correctionand decommutation programs were written in FORTRAN andthe UNIVAC 1108 assemblerlangu- age, SLEUTH 11. a. The time-correctionprograms perform two basic operations: 1. Correctrange time data byremoving discontinuities and filling in missing timedata. 2. Establishfairly precise correlation
Load more

Recommended publications
  • A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)
    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop­ ment of the algorithmic language ALGOL. Nevertheless, it seems perti­ nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text.
    [Show full text]
  • The Advent of Recursion & Logic in Computer Science
    The Advent of Recursion & Logic in Computer Science MSc Thesis (Afstudeerscriptie) written by Karel Van Oudheusden –alias Edgar G. Daylight (born October 21st, 1977 in Antwerpen, Belgium) under the supervision of Dr Gerard Alberts, and submitted to the Board of Examiners in partial fulfillment of the requirements for the degree of MSc in Logic at the Universiteit van Amsterdam. Date of the public defense: Members of the Thesis Committee: November 17, 2009 Dr Gerard Alberts Prof Dr Krzysztof Apt Prof Dr Dick de Jongh Prof Dr Benedikt Löwe Dr Elizabeth de Mol Dr Leen Torenvliet 1 “We are reaching the stage of development where each new gener- ation of participants is unaware both of their overall technological ancestry and the history of the development of their speciality, and have no past to build upon.” J.A.N. Lee in 1996 [73, p.54] “To many of our colleagues, history is only the study of an irrele- vant past, with no redeeming modern value –a subject without useful scholarship.” J.A.N. Lee [73, p.55] “[E]ven when we can't know the answers, it is important to see the questions. They too form part of our understanding. If you cannot answer them now, you can alert future historians to them.” M.S. Mahoney [76, p.832] “Only do what only you can do.” E.W. Dijkstra [103, p.9] 2 Abstract The history of computer science can be viewed from a number of disciplinary perspectives, ranging from electrical engineering to linguistics. As stressed by the historian Michael Mahoney, different `communities of computing' had their own views towards what could be accomplished with a programmable comput- ing machine.
    [Show full text]
  • The Advent of Recursion in Programming, 1950S-1960S
    The Advent of Recursion in Programming, 1950s-1960s Edgar G. Daylight?? Institute of Logic, Language, and Computation, University of Amsterdam, The Netherlands [email protected] Abstract. The term `recursive' has had different meanings during the past two centuries among various communities of scholars. Its historical epistemology has already been described by Soare (1996) with respect to the mathematicians, logicians, and recursive-function theorists. The computer practitioners, on the other hand, are discussed in this paper by focusing on the definition and implementation of the ALGOL60 program- ming language. Recursion entered ALGOL60 in two novel ways: (i) syn- tactically with what we now call BNF notation, and (ii) dynamically by means of the recursive procedure. As is shown, both (i) and (ii) were in- troduced by linguistically-inclined programmers who were not versed in logic and who, rather unconventionally, abstracted away from the down- to-earth practicalities of their computing machines. By the end of the 1960s, some computer practitioners had become aware of the theoreti- cal insignificance of the recursive procedure in terms of computability, though without relying on recursive-function theory. The presented re- sults help us to better understand the technological ancestry of modern- day computer science, in the hope that contemporary researchers can more easily build upon its past. Keywords: recursion, recursive procedure, computability, syntax, BNF, ALGOL, logic, recursive-function theory 1 Introduction In his paper, Computability and Recursion [41], Soare explained the origin of computability, the origin of recursion, and how both concepts were brought to- gether in the 1930s by G¨odel, Church, Kleene, Turing, and others.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • User's Manual for the ALCR-ILLINIS-7090 ALGL-60
    •::../. ; '-> v.- V. -V.' skss Hi *lSn i'-fh B£H*wffi H HI BBfiffli? •LN. fln WW* WSMmm Ml H II B RAI^Y OF THE UN IVLRSITY Of ILLINOIS SlO.84 XSibus 1964 The person charging this material is re- sponsible for its return on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. University of Illinois Library i 1970 LI61— O-10Q6 Digitized by the Internet Archive in 2013 http://archive.org/details/usersmanualforalOOuniv »" DIGITAL COMPUTER LABORATORY GRADUATE COLLEGE UNIVERSITY OF ILLINOIS User's Manual for the ALCpR-ILLIN0IS-7O9O ALG0L-6O Translator University of Illinois 2nd Edition Manual Written and Revised by R. Bayer E. Murphree, Jr. D. Gries September 28, I96U . : Preface In June, 19^2, by arrangement between the University of Illinois and the ALCOR group in Europe, Dr. Manfred Paul, Johannes Gutenberg Universitat, Mainz, and Dr. Rudiger Wiehle, Munchen Technische Hochschule, Munich, began the design of the ALC0R-ILLIN0IS-7O9O ALGOL-60 Translator, the use of which is described in this Manual. They were joined in July, I962, by David Gries and the writer and later by Michael Rossin, Theresa Wang and Rudolf Bayer, all graduate students at the University of Illinois This manual is an effort to explain the differences which exist between publication ALGOL-60 as it is defined by the Revised Report on the Algorithmic Language ALGOL-60 (as published in the January I963 issue of Communications of the Association for Computing Machinery) and as it actually has been implemented by the group named above, Relatively few features of ALGOL-60 have not been implemented, so this manual consists mostly of an explanation of the "hardware" representation of true ALGOL rather than deviations from it.
    [Show full text]
  • The ALCOR-Illinois-7090 Post-Mortem Dump: Description And
    J] if fmy. J-- ,1 ;-fL-v:. 3 i 1 q<tttwtiKHmiuti«i»ni»!HH!?tHwn"'tffffT*"*'"'*— I'M ,1 L I B R.AR.Y OF THL U N IVERSiTY or ILLINOIS The person charging this material is re- sponsible for its return on or before the Latest Date stamped below. Theft, mutilation and underlining of books ore reasons for disciplinary action and may result in dismissal from the University. UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 197t AUG 1 2 AUG ' '^Rfc'o t^iti ^/^:n'Pttt^i 4DING 4 m2 L161— O-1096 "^Report No. I98 vO-^ THE ALCOR-ILLINOIS-7090 POST-MORTEM DUMP DESCRIPTION AND IMBEDDING INSTRUCTIONS by Rudolf Bayer Jerome Cohen Robert Penka J0i 2 8 ms February 10, I966 </.'-. .^.>- Report No. I98 THE ALCOR -ILLINOIS -7090 POST-MORTEM DUMP ',';;•' '^'X DESCRIPTION AND IMBEDDING INSTRUCTIONS "' '•'•'•X by Rudolf Bayer Jerome Cohen Robert Penka February 10, 1966 Department of Computer Science University of Illinois Urbana, Illinois PREFACE PrograTnming languages and compilers like ALG0L and the ALC^^R- ILLIN0IS-7O9O ALG0L-6O Translator are designed to make programining as convenient and as machine independent as possible. The purpose of an Algol program is simply to define an algorithm. From this point of view^ it is completely uninteresting whether this algorithm is executed by a human or an electronic computer^ how the representation of the algorithm in the internal language of a machine looks, or how the operating system of a specific computer is designed and organized. It is desirable to apply this philosophy not only to programming, but to the debugging of programs as well since the conventional dumps of machine conditions, storage areas and the object code are either entirely useless or provide mainly superfluous and irrelevant information which makes debugging a tedious task.
    [Show full text]
  • Die Gruncllehren Cler Mathematischen Wissenschaften
    Die Gruncllehren cler mathematischen Wissenschaften in Einzeldarstellungen mit besonderer Beriicksichtigung der Anwendungsgebiete Band 135 Herausgegeben von J. L. Doob . E. Heinz· F. Hirzebruch . E. Hopf . H. Hopf W. Maak . S. Mac Lane • W. Magnus. D. Mumford M. M. Postnikov . F. K. Schmidt· D. S. Scott· K. Stein Geschiiftsfiihrende Herausgeber B. Eckmann und B. L. van der Waerden Handbook for Automatic Computation Edited by F. L. Bauer· A. S. Householder· F. W. J. Olver H. Rutishauser . K. Samelson· E. Stiefel Volume I . Part a Heinz Rutishauser Description of ALGOL 60 Springer-Verlag New York Inc. 1967 Prof. Dr. H. Rutishauser Eidgenossische Technische Hochschule Zurich Geschaftsfuhrende Herausgeber: Prof. Dr. B. Eckmann Eidgenossische Tecbnische Hocbscbule Zurich Prof. Dr. B. L. van der Waerden Matbematisches Institut der Universitat ZUrich Aile Rechte, insbesondere das der Obersetzung in fremde Spracben, vorbebalten Ohne ausdriickliche Genehmigung des Verlages ist es auch nicht gestattet, dieses Buch oder Teile daraus auf photomechaniscbem Wege (Photokopie, Mikrokopie) oder auf andere Art zu vervielfaltigen ISBN-13: 978-3-642-86936-5 e-ISBN-13: 978-3-642-86934-1 DOl: 10.1007/978-3-642-86934-1 © by Springer-Verlag Berlin· Heidelberg 1967 Softcover reprint of the hardcover 1st edition 1%7 Library of Congress Catalog Card Number 67-13537 Titel-Nr. 5l1B Preface Automatic computing has undergone drastic changes since the pioneering days of the early Fifties, one of the most obvious being that today the majority of computer programs are no longer written in machine code but in some programming language like FORTRAN or ALGOL. However, as desirable as the time-saving achieved in this way may be, still a high proportion of the preparatory work must be attributed to activities such as error estimates, stability investigations and the like, and for these no programming aid whatsoever can be of help.
    [Show full text]
  • Education in Programming David Gries Dr. Rer. Nat., Munich Institute
    Education in Programming David Gries Dr. rer. nat., Munich Institute of Technology, 1966 Computer Science, Cornell University, Ithaca, NY 1 1 A Glimerick of Hope David Gries, 1995 Abstract Well I got my degree at that place The world is turning to C, And my ancestors came from that race Though at best it is taught awkwardly, Though Great New York C But we don’t have to mope, Was the Birthplace of me There’s a glimmer of hope, And CS at Cornell is my base. In the methods of formality President Mary of Eire So I don't have a real PhD. Was supposed to come to regale ya. It's the Dr. Rer. Nat. that's for me. But matters of State And it's from MIT Made her cancel that date --On your side of the sea So you’re stuck with this guy from Bavaria Munich Inst. of Technolology 2 2 In 1962–63, in Illinois writing the ALCOR-ILLINOIS 7090 ALGOL Compiler I came to Munich to get a PhD (and finish the compiler) Manfred Paul Rudiger Wiehle Elaine and David Gries 3 3 Instrumental in the development of programming languages and their implementation A early as 1952, Bauer: Keller principle Influential in development of Algol 60 Educate the next generation of computer scientists 1968 and 1969 NATO Conferences on Software Engineering (Garmisch and Rome) 4 4 1968 and 1969 NATO Conferences Software Engineering (Garmisch and Rome) 5 5 1968 and 1969 NATO Conferences Software Engineering (Garmisch and Rome) 6 6 Instrumental in the development of programming languages and their implementation Educate the next generation of computer scientists 1968 and 1969 NATO Conferences on Software Engineering (Garmisch and Rome) The Marktoberdorf Summer Schools now led ably by Manfred Broy 7 7 The teaching of programming simplicity elegance perfection intellectual honesty Edsger W.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Stan-(X-249-71 December 1971
    S U326 P23-17 AN ANNOTATED BIBLIOGRAPHY ON THE CONSTRUCTION OF COMPILERS . BY BARY W. POLLACK STAN-(X-249-71 DECEMBER 1971 - COMPUTER SCIENCE DEPARTMENT School of Humanities and Sciences STANFORD UNIVERS II-Y An Annotated Bibliography on the Construction of Compilers* 1971 Bary W. Pollack Computer Science Department Stanford University This bibliography is divided into 9 sections: 1. General Information on Compiling Techniques 2. Syntax- and Base-Directed Parsing c 30 Brsing in General 4. Resource Allocation 59 Errors - Detection and Correction 6. Compiler Implementation in General - 79 Details of Compiler Construction 8. Additional Topics 9* Miscellaneous Related References Within each section the entries are alphabetical by author. Keywords describing the entry will be found for each entry set off by pound signs (*#). Some amount of cross-referencing has been done; e.g., entries which fall into Section 3 as well as Section 7 will generally be found in both sections. However, entries will be found listed only under the principle or first author's name. Computing Review citations are given following the annotation when available. "this research was supported by the Atomic Energy Commission, Project ~~-326~23. Available from the Clearinghouse for Federal Scientific and Technical Information, Springfield, Virginia 22151. 0 l/03/72 16:44:58 COMPILER CONSTRUCTION TECHNIQUES PACFl 1, 1 ANNOTATED RTBLIOGRAPHY GENERAL INFORMATION ON COMP?LING TECHNIQOES Abrahams, P, W. Symbol manipulation languages. Advances in Computers, Vol 9 (196R), Sl-111, Academic Press, N. Y. ? languages Ic Anonymous. Philosophies for efficient processor construction. ICC Dull, I, 2 (July W62), 85-89. t processors t CR 4536.
    [Show full text]
  • Algorithms, Computation and Mathewics (Algol -SE102?
    ' DOCUMENT RESUME 'ID 143 509 -SE102? 986 . AUTHOR ' Charp, Sylvia; And Cthers TITLE Algorithms, Computation and MatheWics (Algol SApplement). Teacher's Commentary. ReViged Edition. / IATITUTION. Stanford Univ.., Calif. School ,Mathematics Study Group. , SPONS, AGENCY National Science Foundation-, Washington, D.C. PUB DATE 66 'NOTE 113p.;,For related docuuents, see SE 022 983-988; Not available in hard copy dug to marginal legibility off original doctiment TIDRS PRICE MF-$0,.83 Plus Postage. HC Not Available frOm SDRS. 1?'ESCRI2TORS Algorithms; *Computers; *Mathematics Education; *Programing Languages; Secondary Education; *Secondary School Mathematics; *Teaching Guides IDENTIFIERS *itGeL; *,School Mathematics Study Group I. ABSTRACT.- A is the teacher's guide and commentary for the SIISG textboot,Algorithms, Computation andMathematics' (Algol Supplement) .This teacher's commentary provides~ background inf8rmation for'the teacher, suggestions for activities fOund in the student's lgoI 'Supplement, and answers to exercises and activities: The course is ,designed for high school students in grades 11 and 12. Acdess to a computer is high recommended. (RH) f ******************************4**********#5*****i******Lii*************- '* Documents acquired by ERIC ittlUde many informal unPgablished *, * materials n'ot available from other, sources. ERIC makes every effort pic' * to obtain,the best copy available. NeVerfheless, items of 'marginal * reprodUcibillty'are often encountered and this, affects the quality * * of the microfiche and hardcopy reproductions ERIp_makes.available_ * * via the-.ERIC-DocumentReproduction. Service IEDR4.' lint is note * * respon-siile for the quality of the original.document.'Reproductions * supplied by EURS are the` best that can be. made ftom the original. ********,*****************************A********************************* 414 yt r r 4) ALGORITHMS, COMPUTATION AN D MATH EMATICS (Algol Supplement) Teacher's Commentary Revised Edition 1 6 The following is a' list of, ail thKeji'vho participated in thepreparation of this.
    [Show full text]
  • The History of the ALGOL Effort
    Technische Universiteit Eindhoven Department of Mathematics and Computer Science The History of the ALGOL Effort by HT de Beer supervisors: C. Hemerik L.M.M. Royakkers Eindhoven, August 2006 Abstract This report studies the importancy of the ALGOL effort for computer science. Therefore the history of the ALGOL effort is told, starting with the compu- tational context of the 1950s when the ALGOL effort was initiated. Second, the development from IAL to ALGOL 60 and the role the BNF played in this development are discussed. Third, the translation of ALGOL 60 and the establishment of the scientific field of translator writing are treated. Finally, the period of ALGOL 60 maintenance and the subsequent period of creating a successor to ALGOL 60 are described. ii Preface This history on the ALGOL effort was written as a Master thesis in Com- puter Science and Engineering (Technische Informatica) at the Eindhoven University of Technology, the Netherlands. iii Contents Abstract ii Preface iii Contents iv 0 Introduction 1 0.0 On the sources used ........................ 2 0.1 My own perspective ........................ 3 0.2 The ALGOL effort: a definition .................. 4 0.3 Notes ................................ 4 1 Creation 5 1.0 The start of the ALGOL effort ................... 5 1.1 The need for a universal algorithmic language ........... 7 1.1.0 The American field of computing ............. 7 1.1.1 The European field of computing ............. 9 1.1.2 The difference between Europe and the USA and the need for universalism ...................... 11 1.2 Why was IAL chosen over other algorithmic languages? ..... 11 1.2.0 IT ............................
    [Show full text]