DOCSLIB.ORG

Data General Extended Algol 60 Compiler

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Data General Extended Algol 60 Compiler DATA GENERAL EXTENDED ALGOL 60 COMPILER, Data General's Extended ALGOL is a powerful language tial I/O with optional formatting. These extensions comple­ which allows systems programmers to develop programs ment the basic structure of ALGOL and significantly in­ on mini computers that would otherwise require the use of crease the convenience of ALGOL programming without much larger, more expensive computers. No other mini making the language unwieldy. computer offers a language with the programming features and general applicability of Data General's Extended FEATURES OF DATA GENERAL'S EXTENDED ALGOL Character strings are implemented as an extended data ALGOL. type to allow easy manipulation of character data. The ALGOL 60 is the most widely used language for describ­ program may, for example, read in character strings, search ing programming algorithms. It has a flexible, generalized, for substrings, replace characters, and maintain character arithmetic organization and a modular, "building block" string tables efficiently. structure that provides clear, easily readable documentation. Multi-precision arithmetic allows up to 60 decimal digits The language is powerful and concise, allowing the systems of precision in integer or floating point calculations. programmer to state algorithms without resorting to "tricks" Device-independent I/O provides for reading and writ­ to bypass the language. ing in line mode, sequential mode, or random mode.' Free These characteristics of ALGOL are especially important form reading and writing is permitted for all data types, or in the development of working prototype systems. The output can be formatted according to a "picture" of the clear documentation makes it easy for the programmer to output line or lines. recognize and correct program deficiencies and, because of Dynamic conversion of parameter types allows one pro­ ALGOL's modular structure, the programmer may work gram to process data of several types. Expressions of mixed independently on separate parts of the prototype program. type or precision are allowed. Data General's Extended ALGOL is a full implemen­ Recursive and reentrant object code is generated by the tation of ALGOL 60: recursive procedures are allowed, Extended ALGOL compiler. This is particularly important array declarations may be any arithmetic expression includ­ in real-time applications for fast context-switching among ing function calls, and integer labels and conditional ex­ programs.,,d, pressions may be used. Programs written in standard Dynamic storage allocation frees the programmer ,from ALGOL 60 are completely compatible with Data General's many details of data layout and storage assignment, ',:' Extended ALGO L. N-dimensional arrays may be allocated dynamically' at Data General's Extended ALGOL includes facilities for run time. Subscripts and array bounds in the array declara­ character manipulation, list processing, arithmetic with tion may be any expression, including function references, up to 60 decimal digits of precision, and random or sequen- negative numbers, and subscripted variables. Copyright © DATA GENERAL CORPORATION 1971 Direct addressing capabilities are provided by drawing class declaration. The storage classes that are declared are upon some of the powerful addressing features of PUI, in­ own, external, and based. cluding based and pointer variables_ This extended address­ A based variable is merely a template of a program vari­ ing capability provides more efficient code and more easily able, used as described in the section on "Extended Address­ understood source language notation. ing." own and external variables are held in storage through­ Subscripted labels provide for direct branching to a given out an ALGOL program, instead of being dynamically label upon evaluation of the subscript expression. stored. Bit manipulation is provided, using logical operators, Some examples of declarations are: octal and binary literals, and built-in functions. Character- istic Example Description Named constants may be explicitly declared to aid pro­ Data Type integer I, J; and J have integer nu­ gram readability and to simplify program modification. meric values. Condition signalling allows the programmer to set condi­ real K; K has a real numeric tions for interrupting normal execution and switching to value. an interrupt procedure. complex C; C has a complex numer­ Object code optimization is performed for efficient regis­ ic value. ter usage, in-line generation of literals, sub-expression elimi­ boolean done; done has a value true nation, optimal use of machine instructions, and efficient or false. storage allocation. A commented assembly listing is pro­ pointer P; P has an address as a vided. value. Straightforward subprogram linkage conventions, which string measure; measure can contain up are well documented, simplify interfacing to assembly lan­ to 32 characters. guage subprograms. Shape real array MAT is a 5x5 floating­ Explicit diagnostics aid debugging at the source level. MAT[0:4,1 :5]; point array whose first Compatibility with the Data General symbolic debugger element is MAT [0,1] aids run-time debugging. and last element is MAT [4,5]. ELEMENTS OF EXTENDED ALGOL string procedure X is a function that re­ Declarations X(a,b); turns a string value. Its A wide range of characteristics is possible for ALGOL formal parameters are a program variables, making them easily adaptable to specific and b. usages. Each program variable has the characteristics of Storage Class based integer I ,J; I and J are template shape, size, data type, and storage class. variables. For each program variable a declaration of desired char­ own real K; K has a value which is acteristics is given. Data type is always declared. Other char­ preserved between calls. acteristics have default values if not declared. external x is a separately com­ procedure x; piled procedure. The data types are integer, real, complex, boolean, pointer, string, and label. Data types can be converted to Precision real (9) array each of the 8 elements other data types, provided that the shape, size, and storage RAY [7]; of RAY has 9 word class are compatible. I nteger, real, boolean and pointer data precision. can be converted to and from strings. string (2000) s; s can have up to 2000 The shape of a program variable is scalar, array, literal, characters. switCh, procedure or operator. Scalar is the default shape of Statements a variable. If another shape is to be used, the shape must be Statements define program action. I n ALGa L, there are defined in a declaration. relatively few different types of statements, but each type The precision of a program variable represents size in is extremely flexible. For example, the basic assignment words for numeric data (from one to 15 words) and maxi­ statement resembles that of most compiler languages: mum number of characters for string data (maximum of V := expression; 16,283 characters). Precision is only declared for numeric and string data. Other data types have a fixed length for all The expression on the righthand side of the assignment cases. symbol is evaluated, converted if necessary to the data type of variable V, and assigned to variable V. Most ALGOL program variables are allocated and freed dynamically on entry and exit from a portion of the pro­ However, the programmer could have written: gram, called a block. Such variables do not need a storage CHAR := A := V := expression; 2 I n this case, the expression is evaluated and assigned to each Expressions of the variables V, A, and CHAR, and, in each case, the ex­ An expression is a rule for computing a value. In Ex­ pression is converted to the data type of the location, each tended ALGOL, this rule may result in a value which is of which might have a different data type. If the expression numeric, a character string, the address of a computer word, evaluates to a real number, it might simply be assigned to a label, or a truth value. Expressions may contain variables real V, then truncated and assigned to integer A, and con­ of various precisions and data types; code will be generated verted to string format and assigned to string CHAR. to convert variables to a common type and precision when­ The general forms of ALGOL statements are shown be­ ever necessary. For example, a real number could be multi­ low with some examples. In the statement formats follow­ plied by a character string which contained the ASCII repre­ ing, X is an expression, V is a variable, and S is a statement, sentation of a number. The number in the string would be compound statement, or block. converted to type real at execution time. Similarly, a sub­ script or for statement variable could be a real, string or Statement Format Description integer variable. Expressions can also be used as values for V: = X" ... , Xn do S; Statements providing loops passed on procedure calls, and as the dynamic dimensions of an array. for V: = X, step X2 until X3 do S; for V: = X, while X2 do S; Examples Description cos (y + Z X 3) Simple expressions. Variables V: = X; Assignment of expression to (a - 3/y + vu t 8) y, Z, a and vu may be integers, variable(s) . reals, or strings. x[sin(n X pi/21. 0[3, n, 4]] Subscript expressions. The if X then S; Conditional statements. subscripts of the 2-dimension­ if X then S, else S2; X is boolean expression. al array x are the result of go to X; Unconditional transfer, X is a the function sine and an ele­ label expression or label. ment of the 3-dimensional array O. NAME; Call to a procedure NAME. NAME (X" X2, ... , Xn); Each X is a parameter. s := prO] := n := n + , + S The value n + , + s is stored in the order n, p[O], s. The type Represents the null statement. of the value will be converted on each step if required.
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]
  • Security Applications of Formal Language Theory
    Dartmouth College Dartmouth Digital Commons Computer Science Technical Reports Computer Science 11-25-2011 Security Applications of Formal Language Theory Len Sassaman Dartmouth College Meredith L. Patterson Dartmouth College Sergey Bratus Dartmouth College Michael E. Locasto Dartmouth College Anna Shubina Dartmouth College Follow this and additional works at: https://digitalcommons.dartmouth.edu/cs_tr Part of the Computer Sciences Commons Dartmouth Digital Commons Citation Sassaman, Len; Patterson, Meredith L.; Bratus, Sergey; Locasto, Michael E.; and Shubina, Anna, "Security Applications of Formal Language Theory" (2011). Computer Science Technical Report TR2011-709. https://digitalcommons.dartmouth.edu/cs_tr/335 This Technical Report is brought to you for free and open access by the Computer Science at Dartmouth Digital Commons. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Dartmouth Digital Commons. For more information, please contact [email protected]. Security Applications of Formal Language Theory Dartmouth Computer Science Technical Report TR2011-709 Len Sassaman, Meredith L. Patterson, Sergey Bratus, Michael E. Locasto, Anna Shubina November 25, 2011 Abstract We present an approach to improving the security of complex, composed systems based on formal language theory, and show how this approach leads to advances in input validation, security modeling, attack surface reduction, and ultimately, software design and programming methodology. We cite examples based on real-world security flaws in common protocols representing different classes of protocol complexity. We also introduce a formalization of an exploit development technique, the parse tree differential attack, made possible by our conception of the role of formal grammars in security. These insights make possible future advances in software auditing techniques applicable to static and dynamic binary analysis, fuzzing, and general reverse-engineering and exploit development.
    [Show full text]
  • Using the Unibasic Debugger
    C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\DEBUGGER\BASBTITL.fm March 8, 2010 10:30 am Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta UniData Using the UniBasic Debugger UDT-720-UDEB-1 C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\DEBUGGER\BASBTITL.fm March 8, 2010 10:30 am Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Notices Edition Publication date: July 2008 Book number: UDT-720-UDEB-1 Product version: UniData 7.2 Copyright © Rocket Software, Inc. 1988-2008. All Rights Reserved. Trademarks The following trademarks appear in this publication: Trademark Trademark Owner Rocket Software™ Rocket Software, Inc. Dynamic Connect® Rocket Software, Inc. RedBack® Rocket Software, Inc. SystemBuilder™ Rocket Software, Inc. UniData® Rocket Software, Inc. UniVerse™ Rocket Software, Inc. U2™ Rocket Software, Inc. U2.NET™ Rocket Software, Inc. U2 Web Development Environment™ Rocket Software, Inc. wIntegrate® Rocket Software, Inc. Microsoft® .NET Microsoft Corporation Microsoft® Office Excel®, Outlook®, Word Microsoft Corporation Windows® Microsoft Corporation Windows® 7 Microsoft Corporation Windows Vista® Microsoft Corporation Java™ and all Java-based trademarks and logos Sun Microsystems, Inc. UNIX® X/Open Company Limited ii Using the UniBasic Debugger The above trademarks are property of the specified companies in the United States, other countries, or both. All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names as designated by the companies who own or market them. License agreement This software and the associated documentation are proprietary and confidential to Rocket Software, Inc., are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice.
    [Show full text]
  • Kednos PL/I for Openvms Systems User Manual
    ) Kednos PL/I for OpenVMS Systems User Manual Order Number: AA-H951E-TM November 2003 This manual provides an overview of the PL/I programming language. It explains programming with Kednos PL/I on OpenVMS VAX Systems and OpenVMS Alpha Systems. It also describes the operation of the Kednos PL/I compilers and the features of the operating systems that are important to the PL/I programmer. Revision/Update Information: This revised manual supersedes the PL/I User’s Manual for VAX VMS, Order Number AA-H951D-TL. Operating System and Version: For Kednos PL/I for OpenVMS VAX: OpenVMS VAX Version 5.5 or higher For Kednos PL/I for OpenVMS Alpha: OpenVMS Alpha Version 6.2 or higher Software Version: Kednos PL/I Version 3.8 for OpenVMS VAX Kednos PL/I Version 4.4 for OpenVMS Alpha Published by: Kednos Corporation, Pebble Beach, CA, www.Kednos.com First Printing, August 1980 Revised, November 1983 Updated, April 1985 Revised, April 1987 Revised, January 1992 Revised, May 1992 Revised, November 1993 Revised, April 1995 Revised, October 1995 Revised, November 2003 Kednos Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Kednos Corporation or an anthorized sublicensor.
    [Show full text]
  • Enhancing Reliability of RTL Controller-Datapath Circuits Via Invariant-Based Concurrent Test Yiorgos Makris, Ismet Bayraktaroglu, and Alex Orailoglu
    IEEE TRANSACTIONS ON RELIABILITY, VOL. 53, NO. 2, JUNE 2004 269 Enhancing Reliability of RTL Controller-Datapath Circuits via Invariant-Based Concurrent Test Yiorgos Makris, Ismet Bayraktaroglu, and Alex Orailoglu Abstract—We present a low-cost concurrent test methodology controller states for enhancing the reliability of RTL controller-datapath circuits, , , control signals based on the notion of path invariance. The fundamental obser- , environment signals vation supporting the proposed methodology is that the inherent transparency behavior of RTL components, typically utilized for hierarchical off-line test, renders rich sources of invariance I. INTRODUCTION within a circuit. Furthermore, additional sources of invariance are obtained by examining the algorithmic interaction between the HE ability to test the functionality of a circuit during usual controller, and the datapath of the circuit. A judicious selection T operation is becoming an increasingly desirable property & combination of modular transparency functions, based on the of modern designs. Identifying & discarding faulty results be- algorithm implemented by the controller-datapath pair, yields a powerful set of invariant paths in a design. Compliance to the in- fore they are further used constitutes a powerful design attribute variant behavior is checked whenever the latter is activated. Thus, of ASIC performing critical computations, such as DSP, and such paths enable a simple, yet very efficient concurrent test capa- ALU. While this capability can be provided by hardware dupli- bility, achieving fault security in excess of 90% while keeping the cation schemes, such methods incur considerable cost in terms hardware overhead below 40% on complicated, difficult-to-test, sequential benchmark circuits. By exploiting fine-grained design of area overhead, and possible performance degradation.
    [Show full text]
  • Supplementary Materials
    Contents 2 Programming Language Syntax C 1 2.3.5 Syntax Errors C 1 2.4 Theoretical Foundations C 13 2.4.1 Finite Automata C 13 2.4.2 Push-Down Automata C 18 2.4.3 Grammar and Language Classes C 19 2.6 Exercises C 24 2.7 Explorations C 25 3 Names, Scopes, and Bindings C 26 3.4 Implementing Scope C 26 3.4.1 Symbol Tables C 26 3.4.2 Association Lists and Central Reference Tables C 31 3.8 Separate Compilation C 36 3.8.1 Separate Compilation in C C 37 3.8.2 Packages and Automatic Header Inference C 40 3.8.3 Module Hierarchies C 41 3.10 Exercises C 42 3.11 Explorations C 44 4SemanticAnalysis C 45 4.5 Space Management for Attributes C 45 4.5.1 Bottom-Up Evaluation C 45 4.5.2 Top-Down Evaluation C 50 C ii Contents 4.8 Exercises C 57 4.9 Explorations C 59 5 Target Machine Architecture C 60 5.1 The Memory Hierarchy C 61 5.2 Data Representation C 63 5.2.1 Integer Arithmetic C 65 5.2.2 Floating-Point Arithmetic C 67 5.3 Instruction Set Architecture (ISA) C 70 5.3.1 Addressing Modes C 71 5.3.2 Conditions and Branches C 72 5.4 Architecture and Implementation C 75 5.4.1 Microprogramming C 76 5.4.2 Microprocessors C 77 5.4.3 RISC C 77 5.4.4 Multithreading and Multicore C 78 5.4.5 Two Example Architectures: The x86 and ARM C 80 5.5 Compiling for Modern Processors C 88 5.5.1 Keeping the Pipeline Full C 89 5.5.2 Register Allocation C 93 5.6 Summary and Concluding Remarks C 98 5.7 Exercises C 100 5.8 Explorations C 104 5.9 Bibliographic Notes C 105 6 Control Flow C 107 6.5.4 Generators in Icon C 107 6.7 Nondeterminacy C 110 6.9 Exercises C 116 6.10 Explorations
    [Show full text]
  • FPGA-Accelerated Evaluation and Verification of RTL Designs
    FPGA-Accelerated Evaluation and Verification of RTL Designs Donggyu Kim Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2019-57 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-57.html May 17, 2019 Copyright © 2019, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. FPGA-Accelerated Evaluation and Verification of RTL Designs by Donggyu Kim A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Krste Asanovi´c,Chair Adjunct Assistant Professor Jonathan Bachrach Professor Rhonda Righter Spring 2019 FPGA-Accelerated Evaluation and Verification of RTL Designs Copyright c 2019 by Donggyu Kim 1 Abstract FPGA-Accelerated Evaluation and Verification of RTL Designs by Donggyu Kim Doctor of Philosophy in Computer Science University of California, Berkeley Professor Krste Asanovi´c,Chair This thesis presents fast and accurate RTL simulation methodologies for performance, power, and energy evaluation as well as verification and debugging using FPGAs in the hardware/software co-design flow. Cycle-level microarchitectural software simulation is the bottleneck of the hard- ware/software co-design cycle due to its slow speed and the difficulty of simulator validation.
    [Show full text]
  • CS412/CS413 Introduction to Compilers Tim Teitelbaum Lecture 12
    CS412/CS413 Introduction to Compilers Tim Teitelbaum Lecture 12: Symbol Tables February 15, 2008 CS 412/413 Spring 2008 Introduction to Compilers 1 Where We Are Source code if (b == 0) a = b; (character stream) Lexical Analysis Token if ( b == 0 ) a = b ; stream Syntax Analysis if (Parsing) == = Abstract syntax tree (AST) b0ab if Semantic Analysis boolean int Decorated == = AST int b int 0 int a int b Errors lvalue (incorrect program) CS 412/413 Spring 2008 Introduction to Compilers 2 Non-Context-Free Syntax • Programs that are correct with respect to the language’s lexical and context-free syntactic rules may still contain other syntactic errors • Lexical analysis and context-free syntax analysis are not powerful enough to ensure the correct usage of variables, objects, functions, statements, etc. • Non-context-free syntactic analysis is known as semantic analysis CS 412/413 Spring 2008 Introduction to Compilers 3 Incorrect Programs •Example 1: lexical analysis does not distinguish between different variable or function identifiers (it returns the same token for all identifiers) int a; int a; a = 1; b = 1; •Example 2: syntax analysis does not correlate the declarations with the uses of variables in the program: int a; a = 1; a = 1; •Example3: syntax analysis does not correlate the types from the declarations with the uses of variables: int a; int a; a = 1; a = 1.0; CS 412/413 Spring 2008 Introduction to Compilers 4 Goals of Semantic Analysis • Semantic analysis ensures that the program satisfies a set of additional rules regarding the
    [Show full text]
  • Behavioral Types in Programming Languages
    Foundations and Trends R in Programming Languages Vol. 3, No. 2-3 (2016) 95–230 c 2016 D. Ancona et al. DOI: 10.1561/2500000031 Behavioral Types in Programming Languages Davide Ancona, DIBRIS, Università di Genova, Italy Viviana Bono, Dipartimento di Informatica, Università di Torino, Italy Mario Bravetti, Università di Bologna, Italy / INRIA, France Joana Campos, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Giuseppe Castagna, CNRS, IRIF, Univ Paris Diderot, Sorbonne Paris Cité, France Pierre-Malo Deniélou, Royal Holloway, University of London, UK Simon J. Gay, School of Computing Science, University of Glasgow, UK Nils Gesbert, Université Grenoble Alpes, France Elena Giachino, Università di Bologna, Italy / INRIA, France Raymond Hu, Department of Computing, Imperial College London, UK Einar Broch Johnsen, Institutt for informatikk, Universitetet i Oslo, Norway Francisco Martins, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Viviana Mascardi, DIBRIS, Università di Genova, Italy Fabrizio Montesi, University of Southern Denmark Rumyana Neykova, Department of Computing, Imperial College London, UK Nicholas Ng, Department of Computing, Imperial College London, UK Luca Padovani, Dipartimento di Informatica, Università di Torino, Italy Vasco T. Vasconcelos, LaSIGE, Faculdade de Ciências, Univ de Lisboa, Portugal Nobuko Yoshida, Department of Computing, Imperial College London, UK Contents 1 Introduction 96 2 Object-Oriented Languages 105 2.1 Session Types in Core Object-Oriented Languages . 106 2.2 Behavioral Types in Java-like Languages . 121 2.3 Typestate . 134 2.4 Related Work . 139 3 Functional Languages 140 3.1 Effects for Session Type Checking . 141 3.2 Sessions and Explicit Continuations . 143 3.3 Monadic Approaches to Session Type Checking .
    [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]
  • Design and Implementation of the GNU Prolog System Abstract 1 Introduction
    Design and Implementation of the GNU Prolog System Daniel Diaz Philippe Codognet University of Paris 1 University of Paris 6 CRI, bureau C1407 LIP6, case 169 90, rue de Tolbiac 8, rue du Capitaine Scott 75013 Paris, FRANCE 75015 Paris, FRANCE and INRIA-Rocquencourt and INRIA-Rocquencourt [email protected] [email protected] Abstract In this paper we describe the design and the implementation of the GNU Pro- log system. This system draws on our previous experience of compiling Prolog to C in the wamcc system and of compiling finite domain constraints in the clp(FD) system. The compilation scheme has however been redesigned in or- der to overcome the drawbacks of compiling to C. In particular, GNU-Prolog is based on a low-level mini-assembly platform-independent language that makes it possible to avoid compiling C code, and thus drastically reduces compilation time. It also makes it possible to produce small stand-alone executable files as the result of the compilation process. Interestingly, GNU Prolog is now com- pliant to the ISO standard, includes several extensions (OS interface, sockets, global variables, etc) and integrates a powerful constraint solver over finite domains. The system is efficient and in terms of performance is comparable with commercial systems for both the Prolog and constraint aspects. 1 Introduction GNU Prolog is a free Prolog compiler supported by the GNU organization (http://www.gnu.org/software/prolog). It is a complete system which in- cludes: floating point numbers, streams, dynamic code, DCG, operating sys- tem interface, sockets, a Prolog debugger, a low-level WAM debugger, line editing facilities with completion on atoms, etc.
    [Show full text]
  • Interpreters Machine Interpreters
    Interpreters There are two different kinds of interpreters that support execution of programs, machine interpreters and language interpreters. Machine Interpreters A machine interpreter simulates the execution of a program compiled for a particular machine architecture. Java uses a bytecode interpreter to simulate the effects of programs compiled for the JVM. Programs like SPIM simulate the execution of a MIPS program on a non-MIPS computer. © CS 536 Spring 2006 43 Language Interpreters A language interpreter simulates the effect of executing a program without compiling it to any particular instruction set (real or virtual). Instead some IR form (perhaps an AST) is used to drive execution. Interpreters provide a number of capabilities not found in compilers: • Programs may be modified as execution proceeds. This provides a straightforward interactive debugging capability. Depending on program structure, program modifications may require reparsing or repeated semantic analysis. In Python, for example, any string variable may be interpreted as a Python expression or statement and executed. © CS 536 Spring 2006 44 • Interpreters readily support languages in which the type of a variable denotes may change dynamically (e.g., Python or Scheme). The user program is continuously reexamined as execution proceeds, so symbols need not have a fixed type. Fluid bindings are much more troublesome for compilers, since dynamic changes in the type of a symbol make direct translation into machine code difficult or impossible. • Interpreters provide better diagnostics. Source text analysis is intermixed with program execution, so especially good diagnostics are available, along with interactive debugging. • Interpreters support machine independence. All operations are performed within the interpreter.
    [Show full text]