LC-3 Assembly Lab Manual

Total Page:16

File Type:pdf, Size:1020Kb

LC-3 Assembly Lab Manual 111110001001110010010110100000101100100000011011000101000101100011111110110111101010001100101111000000010001001000011101000010 011000100111000101110000101100100010010100001110101110001010111100010111011001111001101001011010111000100011000011010111110000 000011001100010101001010010011010011010000110110100100111011011001011110001111001010011101001000101001010011101111001110010001 111001001110000110001101111101101101101111100000001100010000001001001010100111010111000010110100110001000011000100110111100101 100111101111010110101111101101010101110011111111100110101101101000000110101110101100100010101010111111101111010111100000110001 101000011011001101001000000010011000001101011010100000010010001111110111110001010110111010011100101000111111101111010111111111 001011000011100010001001110101110000100011111110000100011010101011001000001110110110001100001101101001110110011110000000011001 001000011000001001101011110100110001100000100100011011011100001011100000010011110000010001000010000100000100001001000000111101 000101100101111010101011010000101101110011010110111001010010011010011010111111101000111010001010110100111110110111111000011101 001100001010011111011100111110101001010111001110001001100000000001111101100001000101010111110100111101110010100101000100000100 100011101011001101000101101100100110100001110010101110110101011110110100010110001011000000000100100111000011100011101011111111 110100011010110111001000101000101111001010111100111100111100011011110101100100110100010101010110011111010001000011110100111110 111100111100111101000000010010100111001100101011000110101001010001010001111001110000010010001110010000000110110011000011000101 001111111111100011000101100011011100110110000111010000110101010100001111101101101100010110110110111001110000101001100111001001 011111011101011101110110010101000101111101011011000101110111010001100110001001011001001000000011110001110010110011110100100001 George M. Georgiou and Brian Strader California State University, San Bernardino August 2005 CONTENTS Contents ii List of Code Listings v List of Figures vi Programming in LC-3 vii LC-3 Quick Reference Guide x 1 ALU Operations 1–1 1.1 Problem Statement .................................. 1–1 1.1.1 Inputs ..................................... 1–1 1.1.2 Outputs .................................... 1–1 1.2 Instructions in LC-3 .................................. 1–2 1.2.1 Addition ................................... 1–2 1.2.2 Bitwise AND ................................. 1–2 1.2.3 Bitwise NOT ................................. 1–2 1.2.4 Bitwise OR .................................. 1–3 1.2.5 Loading and storing with LDR and STR ................... 1–3 1.3 How to determine whether an integer is even or odd ................. 1–3 1.4 Testing ......................................... 1–3 1.5 What to turn in .................................... 1–4 2 Arithmetic functions 2–1 2.1 Problem Statement .................................. 2–1 2.1.1 Inputs ..................................... 2–1 2.1.2 Outputs .................................... 2–1 2.2 Operations in LC-3 .................................. 2–2 2.2.1 Loading and storing with LDI and STI .................... 2–2 2.2.2 Subtraction .................................. 2–2 2.2.3 Branches ................................... 2–3 2.2.4 Absolute value ................................ 2–3 2.3 Example ........................................ 2–4 2.4 Testing ......................................... 2–4 2.5 What to turn in .................................... 2–4 Revision: 1.17, January 20, 2007 ii CONTENTS CONTENTS 3 Days of the week 3–1 3.1 Problem Statement .................................. 3–1 3.1.1 Inputs ..................................... 3–1 3.1.2 Outputs .................................... 3–1 3.2 The lab ........................................ 3–1 3.2.1 Strings in LC-3 ................................ 3–1 3.2.2 How to output a string on the display .................... 3–2 3.2.3 How to read an input value .......................... 3–2 3.2.4 Defining the days of the week ........................ 3–3 3.3 Testing ......................................... 3–4 3.4 What to turn in .................................... 3–4 4 Fibonacci Numbers 4–1 4.1 Problem Statement .................................. 4–1 4.1.1 Inputs ..................................... 4–1 4.1.2 Outputs .................................... 4–1 4.2 Example ........................................ 4–1 4.3 Fibonacci Numbers .................................. 4–1 4.4 Pseudo-code ...................................... 4–2 4.5 Notes ......................................... 4–2 4.6 Testing ......................................... 4–3 4.7 What to turn in .................................... 4–3 5 Subroutines: multiplication, division, modulus 5–1 5.1 Problem Statement .................................. 5–1 5.1.1 Inputs ..................................... 5–1 5.1.2 Outputs .................................... 5–1 5.2 The program ...................................... 5–1 5.2.1 Subroutines .................................. 5–1 5.2.2 Saving and restoring registers ........................ 5–2 5.2.3 Structure of the assembly program ...................... 5–2 5.2.4 Multiplication ................................. 5–3 5.2.5 Division and modulus ............................ 5–3 5.3 Testing ......................................... 5–5 5.4 What to turn in .................................... 5–5 6 Faster Multiplication 6–1 6.1 Problem Statement .................................. 6–1 6.1.1 Inputs ..................................... 6–1 6.1.2 Outputs .................................... 6–1 6.2 The program ...................................... 6–1 6.2.1 The shift-and-add algorithm ......................... 6–1 6.2.2 Examining a single bit in LC-3 ........................ 6–2 6.2.3 The MULT1 subroutine ........................... 6–2 6.3 Testing ......................................... 6–2 6.4 What to turn in .................................... 6–2 7 Compute Day of the Week 7–1 7.1 Problem Statement .................................. 7–1 7.1.1 Inputs ..................................... 7–1 7.1.2 Outputs .................................... 7–1 7.1.3 Example ................................... 7–1 7.2 Zeller’s formula .................................... 7–2 7.3 Subroutines ...................................... 7–2 7.3.1 Structure of program ............................. 7–2 iii CONTENTS CONTENTS 7.4 Testing: some example dates ............................. 7–3 7.5 What to turn in .................................... 7–3 8 Random Number Generator 8–1 8.1 Problem Statement .................................. 8–1 8.1.1 Inputs and Outputs .............................. 8–1 8.2 Linear Congruential Random Number Generators .................. 8–1 8.3 How to output numbers in decimal .......................... 8–2 8.3.1 A rudimentary stack ............................. 8–3 8.4 Testing ......................................... 8–3 8.5 What to turn in .................................... 8–3 9 Recursive subroutines 9–1 9.1 Problem Statement .................................. 9–1 9.1.1 Inputs ..................................... 9–1 9.1.2 Output .................................... 9–1 9.2 Recursive Subroutines ................................ 9–1 9.2.1 The Fibonacci numbers ............................ 9–1 9.2.2 Factorial ................................... 9–1 9.2.3 Catalan numbers ............................... 9–2 9.2.4 The recursive square function. ........................ 9–2 9.3 Stack Frames ..................................... 9–3 9.4 The McCarthy 91 function: an example in LC-3 ................... 9–5 9.4.1 Definition ................................... 9–5 9.4.2 Some facts about the McCarthy 91 function ................. 9–5 9.4.3 Implementation of McCarthy 91 in LC-3 .................. 9–5 9.5 Testing ......................................... 9–7 9.6 What to turn in .................................... 9–7 iv LIST OF CODE LISTINGS 1 “Hello World!” in LC-3. ............................... vii 1.1 The ADD instruction. ................................. 1–2 1.2 The AND instruction. ................................. 1–3 1.3 The NOT instruction. ................................. 1–3 1.4 Implementing the OR operation. ........................... 1–3 1.5 Loading and storing examples. ............................ 1–4 1.6 Determining whether a number is even or odd. .................... 1–4 2.1 Loading into a register. ................................ 2–2 2.2 Storing a register. ................................... 2–2 2.3 Subtraction: 5 − 3 = 2. ................................ 2–2 2.4 Condition bits are set. ................................. 2–3 2.5 Branch if result was zero. ............................... 2–3 2.6 Absolute value. .................................... 2–4 3.1 Days of the week data. ................................ 3–3 3.2 Display the day. .................................... 3–3 4.1 Pseudo-code for computing the Fibonacci number Fn iteratively .......... 4–2 4.2 Pseudo-code for computing the largest n = N such that FN can be held in 16 bits .. 4–3 5.1 A subroutine for the function f (n) = 2n + 3. ..................... 5–2 5.2 Saving and restoring registers R5 and R6. ...................... 5–3 5.3 General structure of assembly program. ....................... 5–3 5.4 Pseudo-code for multiplication. ............................ 5–4 5.5 Pseudo-code for integer division and modulus. .................... 5–4 6.1 The shift-and-add multiplication.
Recommended publications
  • PML2: Integrated Program Verification in ML
    PML2: Integrated Program Verification in ML Rodolphe Lepigre LAMA, CNRS, Université Savoie Mont Blanc, France and Inria, LSV, CNRS, Université Paris-Saclay, France [email protected] https://orcid.org/0000-0002-2849-5338 Abstract We present the PML2 language, which provides a uniform environment for programming, and for proving properties of programs in an ML-like setting. The language is Curry-style and call-by-value, it provides a control operator (interpreted in terms of classical logic), it supports general recursion and a very general form of (implicit, non-coercive) subtyping. In the system, equational properties of programs are expressed using two new type formers, and they are proved by constructing terminating programs. Although proofs rely heavily on equational reasoning, equalities are exclusively managed by the type-checker. This means that the user only has to choose which equality to use, and not where to use it, as is usually done in mathematical proofs. In the system, writing proofs mostly amounts to applying lemmas (possibly recursive function calls), and to perform case analyses (pattern matchings). 2012 ACM Subject Classification Software and its engineering → Software verification Keywords and phrases program verification, classical logic, ML-like language, termination check- ing, Curry-style quantification, implicit subtyping Digital Object Identifier 10.4230/LIPIcs.TYPES.2017.5 1 Introduction: joining programming and proving In the last thirty years, significant progress has been made in the application of type theory to computer languages. The Curry-Howard correspondence, which links the type systems of functional programming languages to mathematical logic, has been explored in two main directions.
    [Show full text]
  • A Survey on Teaching and Learning Recursive Programming
    Informatics in Education, 2014, Vol. 13, No. 1, 87–119 87 © 2014 Vilnius University A Survey on Teaching and Learning Recursive Programming Christian RINDERKNECHT Department of Programming Languages and Compilers, Eötvös Loránd University Budapest, Hungary E-mail: [email protected] Received: July 2013 Abstract. We survey the literature about the teaching and learning of recursive programming. After a short history of the advent of recursion in programming languages and its adoption by programmers, we present curricular approaches to recursion, including a review of textbooks and some programming methodology, as well as the functional and imperative paradigms and the distinction between control flow vs. data flow. We follow the researchers in stating the problem with base cases, noting the similarity with induction in mathematics, making concrete analogies for recursion, using games, visualizations, animations, multimedia environments, intelligent tutor- ing systems and visual programming. We cover the usage in schools of the Logo programming language and the associated theoretical didactics, including a brief overview of the constructivist and constructionist theories of learning; we also sketch the learners’ mental models which have been identified so far, and non-classical remedial strategies, such as kinesthesis and syntonicity. We append an extensive and carefully collated bibliography, which we hope will facilitate new research. Key words: computer science education, didactics of programming, recursion, tail recursion, em- bedded recursion, iteration, loop, mental models. Foreword In this article, we survey how practitioners and educators have been teaching recursion, both as a concept and a programming technique, and how pupils have been learning it. After a brief historical account, we opt for a thematic presentation with cross-references, and we append an extensive bibliography which was very carefully collated.
    [Show full text]
  • Etude on Recursion Elimination by Program Manipulation and Problem Analysis
    Etude on Recursion Elimination by Program Manipulation and Problem Analysis Nikolay V. Shilov Innopolis University Russia [email protected] Transformation-based program verification was a very important research topic in early years of theory of programming. Great computer scientists contributed to these studies: John McCarthy, Amir Pnueli, Donald Knuth ... Many fascinating examples were examined and resulted in recursion elimination techniques known as tail-recursion and as co-recursion. In the present paper we examine another (new we believe) example of recursion elimination via program manipulations and problem analysis. The recursion pattern of the study example matches neither tail-recursion nor co-recursion pattern. 1 Introduction 1.1 McCarthy 91 function Let us start with a short story [7] about the McCarthy 91 function M : N ! N, defined by John McCarthy1 as a test case for formal verification. The function is defined recursively as n − 10, if n > 100; M(n) = M(M(n + 11)), if n ≤ 100. The result of evaluating the function are given by n − 10, if n > 101; M(n) = (1) 91, if n ≤ 101. The function was introduced in papers published by Zohar Manna, Amir Pnueli and John McCarthy in 1970 [15, 16]. These papers represented early developments towards the application of formal methods to program verification. The function has a “complex” recursion pattern (contrasted with simple patterns, such as recurrence, tail-recursion or co-recursion). Nevertheless the McCarthy 91 function can be computed by an iterative algorithm/program. Really, let us consider an auxiliary recursive function Maux : N × N ! N 8 n m < , if = 0; Maux(n;m) = Maux(n − 10; m − 1), if n > 100 and m > 0; : Maux(n + 11; m + 1), if n < 100 and m > 0.
    [Show full text]
  • Classical Themes of Computer Science Functional Programming (Part 1/2)
    Institute for Software Technology tugraz Classical Themes of Computer Science Functional Programming (Part 1/2) Bernhard K. Aichernig Institute for Software Technology Graz University of Technology Austria Winter Term 2014/15 Version: October 15, 2014 B.K. Aichernig Classical Themes of Computer Science 1 / 49 Institute for Software Technology tugraz Agenda I Functional Programming? I Elements of Functional Programming I Recursive Functions I Higher-Order Functions I Lists B.K. Aichernig Classical Themes of Computer Science 2 / 49 Institute for Software Technology tugraz Programming Paradigms Paradigm: In science, a paradigm describes distinct concepts or thought patterns in some scientific discipline. Main programming paradigms: I imperative programming I functional programming I logic programming Orthogonal to it: I object-oriented programming B.K. Aichernig Classical Themes of Computer Science 3 / 49 Institute for Software Technology tugraz History of Functional Programming Languages 1959 Lisp 1975-77 ML, FP, Scheme 1978 Smalltalk 1986 Standard ML 1988 Erlang 1990 Haskell 1999 XSLT 2000 OCaml 2003 Scala, XQuery 2005 F# 2007 Clojure B.K. Aichernig Classical Themes of Computer Science 4 / 49 Institute for Software Technology tugraz Functional Programs What is a Functional Program? I A Functional Program (FP) is an expression (syntax). I This expression denotes a Value (semantics). I To run a program has the same meaning as evaluating the expression. Functions are values, too! B.K. Aichernig Classical Themes of Computer Science 5 / 49 Institute for Software Technology tugraz Expressions An expression is I a constant, or I a variable, or I a term of the form e1(e2), with e1 and e2 being expressions.
    [Show full text]
  • Recursive Programs As Definitions in First-Order Logic
    SIAM J. COMPUT. 1984 Society for Industrial and Applied Mathematics Vol. 13, No. 2, May 1984 011 RECURSIVE PROGRAMS AS DEFINITIONS IN FIRST ORDER LOGIC* ROBERT CARTWRIGHT? Abstract. Despite the reputed limitations of first order logic, it is easy to state and prove almost all interesting properties of recursive programs within a simple first order theory, by using an approach we call "first order programming logic". Unlike higher order logics based on fixed-point induction, first order programming logic is founded on deductive principles that are familiar to most programmers. Informal structural induction arguments (such as termination proofs for LISP append, McCarthy's 91-function, and Ackermann's function) have direct formalizations within the system. The essential elements of first order programming logic are: (1) The data domain D must be a finitely generated set that explicitly includes the "undefined" object 3_ (representing nontermination) as well as ordinary data objects. (2) Recursive programs over D are treated as logical definitions augmenting a first order theory of the data domain. (3) The interpretation of a recursive program is the least fixed-point of the functional corresponding to the program. Since the data domain D is a finitely generated set, the first order axiomatization of D includes a structural induction axiom scheme. This axiom scheme serves as the fundamental "proof rule" of first order program- ming logic. The major limitation of first order programming logic is that every fixed-point of the functional corresponding to a recursive program is an acceptable interpretation for the program. The logic fails to capture the notion of least fixed-point.
    [Show full text]
  • PART VI: Appendices
    PART VI: Appendices This part complements the main material of the book by providing an introduction to four important programming languages: Java, C#, C++ and (briefly) C. The presentations are specifically designed for the readers of this book: they do not describe the four languages from scratch, but assume you are familiar with the concepts developed in the preceding chapters, and emphasize the differences with the Eiffel notation that they use. The descriptions do not cover the languages in their entirety, but include enough to enable you to start programming in these languages if you have mastered the concepts of the rest of this book. For practical use of a language system (compiler, interpreter, integrated development environment) you will of course need the corresponding reference information, from books or online. Since not every reader will want to learn every one of the languages, each of the first three appendices can be read independently; this also means, since Java, C# and C++ share a number of characteristics (due to the influence of C and, for the first two, C++), that if you do read all three you will encounter some repetitions. The fourth appendix is a short overview of C presented as a subset of C++, and hence assumes that you have read the C++ appendix. The last appendix presents basic information about using the EiffelStudio environment, to help with the examples of this book and the Traffic software. The appendices are followed by the list of picture credits and the index. A An introduction to Java (from material by Marco Piccioni) A.1 LANGUAGE BACKGROUND AND STYLE Java was introduced in 1995, the result of an internal research project at Sun Microsystems led by James Gosling (other key contributors include Bill Joy, Guy Steele and Gilad Bracha).
    [Show full text]
  • Tool Support for Termination Proofs
    Tool Support for Termination Proofs Bachelor’s Thesis Fabio Streun May 2019 Advisors: Prof. Dr. Peter Müller, Dr. Malte Schwerhoff Department of Computer Science, ETH Zürich Contents Contents1 1 Introduction1 1.1 Introduction to Viper ....................... 1 1.1.1 Proving Termination.................... 3 1.2 Chapter Overview ......................... 4 2 Proving Termination of Functions5 2.1 Variant ............................... 5 2.1.1 Proof Encoding....................... 7 2.1.2 Limitations of the Variant Termination Proof Approach 11 2.1.3 Function Inlining Transformation............. 12 2.1.4 Unsoundness of Previous Work.............. 13 2.1.5 Limitations of FIT..................... 14 2.2 Transition Invariants........................ 15 2.2.1 Definitions and Theorems................. 16 2.2.2 Notation for Transition Invariants ............ 18 2.2.3 Proof Encoding in Viper.................. 20 2.2.4 Advantage over Variant Termination Proof Approach . 22 2.2.5 Mutually Recursive Functions............... 24 3 Termination Plugin 29 3.1 Decreases Clause.......................... 29 3.2 Plugin Overview .......................... 30 3.3 Modifying PAST.......................... 32 3.4 Generating Decreases Nodes.................... 32 3.5 Termination Proof Encoding.................... 33 3.5.1 Proof Method Generation................. 33 3.5.2 Termination Check..................... 34 3.5.3 Predicates.......................... 36 1 Contents 3.5.4 Implementation of Function Inlining Transformation . 38 3.6 Errors Reporting.......................... 40 3.6.1 Viper Error Structure ................... 40 3.6.2 Error Transformation ................... 41 3.6.3 Termination Error ..................... 42 3.6.4 Further Errors ....................... 44 3.6.5 Improvements to Previous Implementation . 45 4 Proving Termination of Methods 47 4.1 Termination Check Adjustments ................. 48 4.1.1 Fields ............................ 48 4.1.2 Predicates.......................... 49 4.2 FIT for Methods .........................
    [Show full text]
  • Mccarthy 91 Function 1 Mccarthy 91 Function
    McCarthy 91 function 1 McCarthy 91 function The McCarthy 91 function is a recursive function, defined by computer scientist John McCarthy as a test case for formal verification within computer science. The McCarthy 91 function is defined as The results of evaluating the function are given by M(n) = 91 for all integer arguments n ≤ 101, and M(n) = n − 10 for n > 101. History The 91 function was introduced in papers published by Zohar Manna, Amir Pnueli and John McCarthy in 1970. These papers represented early developments towards the application of formal methods to program verification. The 91 function was chosen for having a complex recursion pattern (contrasted with simple patterns, such as defining by means of ). The example was popularized by Manna's book, Mathematical Theory of Computation (1974). As the field of Formal Methods advanced, this example appeared repetitively in the research literature. In particular, it is viewed as a "challenge problem" for automated program verification. Often, it is easier to reason about non-recursive computation. As one of the examples used to demonstrate such reasoning, Manna's book includes a non-recursive algorithm that simulates the original (recursive) 91 function. Many of the papers that report an "automated verification" (or termination proof) of the 91 function only handle the non-recursive version. A formal derivation of the non-recursive version from the recursive one was given in a 1980 article by Mitchell Wand, based on the use of continuations. Examples Example A: M(99) = M(M(110)) since 99 ≤ 100 = M(100) since 110 > 100 = M(M(111)) since 100 ≤ 100 = M(101) since 111 > 100 = 91 since 101 > 100 Example B: M(87) = M(M(98)) = M(M(M(109))) = M(M(99)) = M(M(M(110))) = M(M(100)) = M(M(M(111))) = M(M(101)) = M(91) = M(M(102)) = M(92) = M(M(103)) Source URL: http://en.wikipedia.org/wiki/McCarthy_91_function Saylor URL: http://www.saylor.org/courses/cs202/ Saylor.org Attributed to: Wikipedia Page 1 of 4 McCarthy 91 function 2 = M(93) ...
    [Show full text]
  • Introduction to Programming in Python This Page Intentionally Left Blank Introduction to Programming in Python
    Introduction to Programming in Python This page intentionally left blank Introduction to Programming in Python An Interdisciplinary Approach Robert Sedgewick Kevin Wayne Robert Dondero Princeton University New York • Boston • Indianapolis • San Francisco Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trade- mark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, train- ing goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the United States, please contact [email protected]. Visit us on the Web: informit.com/aw Library of Cataloging-in-Publication Data Sedgewick, Robert, 1946- Introduction to programming in Python : an interdisciplinary approach / Robert Sedgewick, Kevin Wayne, Robert Dondero. pages cm Includes indexes. ISBN 978-0-13-407643-0 (hardcover : alk.
    [Show full text]
  • Mccarthy 91 Function 1 Mccarthy 91 Function
    McCarthy 91 function 1 McCarthy 91 function The McCarthy 91 function is a recursive function, defined by computer scientist John McCarthy as a test case for formal verification within computer science. The McCarthy 91 function is defined as The results of evaluating the function are given by M(n) = 91 for all integer arguments n ≤ 101, and M(n) = n − 10 for n > 101. History The 91 function was introduced in papers published by Zohar Manna, Amir Pnueli and John McCarthy in 1970. These papers represented early developments towards the application of formal methods to program verification. The 91 function was chosen for having a complex recursion pattern (contrasted with simple patterns, such as defining by means of ). The example was popularized by Manna's book, Mathematical Theory of Computation (1974). As the field of Formal Methods advanced, this example appeared repetitively in the research literature. In particular, it is viewed as a "challenge problem" for automated program verification. Often, it is easier to reason about non-recursive computation. As one of the examples used to demonstrate such reasoning, Manna's book includes a non-recursive algorithm that simulates the original (recursive) 91 function. Many of the papers that report an "automated verification" (or termination proof) of the 91 function only handle the non-recursive version. A formal derivation of the non-recursive version from the recursive one was given in a 1980 article by Mitchell Wand, based on the use of continuations. Examples Example A: M(99) = M(M(110)) since 99 ≤ 100 = M(100) since 110 > 100 = M(M(111)) since 100 ≤ 100 = M(101) since 111 > 100 = 91 since 101 > 100 Example B: M(87) = M(M(98)) = M(M(M(109))) = M(M(99)) = M(M(M(110))) = M(M(100)) = M(M(M(111))) = M(M(101)) = M(91) = M(M(102)) = M(92) = M(M(103)) McCarthy 91 function 2 = M(93) ...
    [Show full text]