DOCSLIB.ORG

A Trustworthy Monadic Formalization of the Armv7 Instruction Set Architecture

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Trustworthy Monadic Formalization of the Armv7 Instruction Set Architecture A Trustworthy Monadic Formalization of the ARMv7 Instruction Set Architecture Anthony Fox and Magnus O. Myreen Computer Laboratory, University of Cambridge, UK Abstract. This paper presents a new HOL4 formalization of the cur- rent ARM instruction set architecture, ARMv7. This is a modern RISC architecture with many advanced features. The formalization is detailed and extensive. Considerable tool support has been developed, with the goal of making the model accessible and easy to work with. The model and supporting tools are publicly available { we wish to encourage others to make use of this resource. This paper explains our monadic specifica- tion approach and gives some details of the endeavours that have been made to ensure that the sizeable model is valid and trustworthy. A novel and efficient testing approach has been developed, based on automated forward proof and communication with ARM development boards. 1 Introduction Instruction set architectures (ISAs) provide a precise interface between hard- ware (microprocessors) and software (high-level code). Formal models of instruc- tion sets are pivotal when verifying computer micro-architectures and compilers. There are also areas where it is appropriate to reason directly about low-level machine code, e.g. in verifying operating systems, embedded code and device drivers. Detailed architecture models have also been used in formalizing multi- processor memory models, see [15]. In the past, academic work has frequently examined the pedagogical DLX architecture, see [6]. When compared to commercial architectures, DLX is rela- tively uncomplicated { being a simplified version of the MIPS RISC architecture. Consequently, it is rarely cumbersome to work with the entire DLX instruction set. More recently there has been a move to modelling, and working with, com- mercial instruction sets (possibly in a reduced form). This has been motivated by a desire to carry out demonstrably realistic case studies, showing that various techniques scale and are not purely \academic" in nature. Common commercial architectures include: IA-32, x86-64, PowerPC, Sparc and ARM. The ARM architecture is ubiquitous in low-powered (mobile and embedded) computing devices { the latest version of the architecture, dubbed ARMv7, is implemented by, for example, the Cortex-A8 processor. There are many challenges when working with full-blown ISAs, these in- clude: (i) official reference manuals are large, stretching to many hundreds of pages { one can easily overlook subtle details or become bogged down with \un- interesting" background information; (ii) official descriptions are semi-formal (ambiguous); (iii) many details are implementation dependent or unpredictable; (iv) architectures frequently have multiple generations, versions and optional ex- tensions; and (v) large formalizations can stretch the capabilities of interactive theorem provers. Most importantly: how can one be sure that the formalization does not contain bugs? The scale and complexity is such that it is not possi- ble to eradicate all errors by simply eyeballing the specification or examining a few instructions. This paper discusses our experiences with constructing and validating a complete model of the ARMv7 architecture using the HOL4 proof system [16]. 2 Approach Some key aspects of the work presented here are: { The ARM instruction set architecture has been modelled in HOL using a monadic style. This approach has a number of advantages, which are dis- cussed in Section 3. { The model is extensive and detailed { it covers all architecture versions cur- rently supported by ARM, including full support for Thumb-2 instructions.1 { A collection of tools have been built around the model, making it accessible and easy to work with. This includes an assembler and disassembler, both of which are implemented in Standard ML. There is also a tool for auto- matically extracting the semantics of a single instruction from the model: this is implemented through evaluation (forward proof) and is discussed in Section 4. { A distinction is made between entities that are defined or derived inside of the HOL logic and those that reside outside { this is illustrated in Figure 1. It is important that everything defined inside of the logic is valid. On the other hand, although it is advantageous that the other tools (e.g. the parser and encoder) are bug free, these are not fundamentally relied upon in formal verification work. { The model operates at the machine code level, as opposed to a more abstract assembly code level. In particular, the model does not provide assembly level \pseudo instructions" and instruction decoding is explicitly modelled inside the logic. This means that the the model can be directly validated by comparing results against the behaviour of hardware employing ARM processors { this is discussed in Section 5. Through the use of extensive validation, trust in the model is progressively es- tablished. An efficient testing framework has been developed, which is based on a HOL session communicating with an ARM development board (via a serial port). This set-up is required because most PCs are based on x86 processors and cannot natively run ARM code. The results from this testing are discussed in Section 5.3. Due to space constraints, precise details of the ARM architecture are not provided here, readers are instead referred to [4] and [11]. 1 It does not cover the ARMv7-M profile (which has a slightly different programmer's model) or the ThumbEE, Jazelle, VFP and Advanced SIMD extensions. Outside HOL Logic Assembly Code (ML string or quotation) parse disassemble Machine Code Abstract Syntax encode (Hexadecimal string) (HOL terms) validation Next Step Machine Code Abstract Syntax decode next state Theorem (HOL n-bit word) (HOL instruction type) (HOL theorem) Evaluation Inside HOL Logic code verification Fig. 1. Overall structure of the formalization. 3 Monadic Specification The HOL4 system provides built-in support for defining recursive, total functions (see [17]). Consequently, formal specifications can be written in a functional programming style using syntax roughly similar to that of ML. For example, in the HOL4 model of the ARMv4 architecture (see [3]), a typical definition is of the following form: f(v1; : : : ; vm) = let x1 = g1(::: ) in ::: let xn = gn(::: ) in (w1; : : : ; wm) If f defines the semantics of a machine code instruction then the vector v would represent the components of the programmer's model state space (for example, machine registers) and w specifies the next state. The variables xi are intermedi- ate computations; typically the result of accessing, updating and manipulating state components. There are a few problems with this particular style of speci- fication: { Explicitly naming state component (splitting the state into a vector) can make it harder to make global changes to sizeable specifications, e.g. adding, removing or changing the type of state components. { The semantics is rigidly fixed to that of a state transformer. In particular, it is not possible to reason about the order of intermediate computations, observing whether or not they were performed sequentially or in parallel. { For those more familiar with imperative code, the specification is not espe- cially readable. { It is not obvious how to handle memory I/O, non-determinism or \error states". All of these factors motivate the use of a monadic programming style (see [18]), where computations themselves are represented with an abstract data type. Let M represent a monad type constructor. The two fundamental monad operations are return and bind, represented by: return : α ! α M and = : α M ! (α ! β M) ! β M respectively. The return operation gives a value to a computation. The bind operation composes computations: it takes the result of one computation and passes it on to another. The type variables α and β represent the types for working values in a computation: these roughly correspond with the variables and arguments of procedures and functions in an imperative language. The monad type constructor M, and associated primitive operations, can be defined in any number of ways, implementing various underlying computational models { this can loosely correspond with defining a semantics (and run-time environment) for a given programming language. In addition to the two primitive monad operations, our specifications also makes use of a parallel operation: : α M ! β M ! (α × β) M : 9 This performs two operations, but without imposing an order of evaluation. 3.1 Sequential Monad It is possible to define monads in HOL without considering concrete implemen- tations: one could, for example, provide an axiomatic formalization. However, there are advantages to being able to actually carry out computations with the model (see Section 4). This section presents a sequential monad { this has formed the primary basis for working with the ARM specification. The monad provides a simple operational semantics in a shallow embedding style { this is suited to evaluation and code verification with a Hoare style logic. The overall HOL specification is split into two parts: the monad specification and the instruction set specification. This means that the instruction set specification part can be interpreted by any other monad with the same interface. The type constructor for the sequential monad is as follows: α Mseq ≡ state ! (α × state) MaybeError where state is the programmer's model state space and β MaybeError = Okay of β j Error of string : This is essentially a state-transformer monad with error states. The monad type can be viewed as a partial map, representing a state transition with a return value. When the map is “undefined”, the result is a tagged string { this can be used to identify where an error occurred. The basic monad operations are defined as follows: return (v) = λs. Okay (v; s) ; " # case f(s) of Error e ! Error e (f = g) = λs. j Okay (v; s0) ! g(v)(s0) and (f g) = (f = (λv1: g = (λv2: return (v1; v2)))) : 9 Note that errors are terminal (no further next state computation is performed) and the parallel operation simply performs computations in a left to right order.
Load more

Recommended publications
  • The Compcert C Verified Compiler: Documentation and User's Manual
    The CompCert C verified compiler: Documentation and user’s manual Xavier Leroy To cite this version: Xavier Leroy. The CompCert C verified compiler: Documentation and user’s manual: Version 2.4. [Intern report] Inria. 2014. hal-01091802v1 HAL Id: hal-01091802 https://hal.inria.fr/hal-01091802v1 Submitted on 6 Dec 2014 (v1), last revised 9 Dec 2020 (v8) HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The CompCert C verified compiler Documentation and user’s manual Version 2.4 Xavier Leroy INRIA Paris-Rocquencourt September 17, 2014 Copyright 2014 Xavier Leroy. This text is distributed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. The text of the license is available at http://creativecommons.org/ licenses/by-nc-sa/4.0/ Contents 1 CompCert C: a trustworthy compiler 5 1.1 Can you trust your compiler? .................................. 5 1.2 Formal verification of compilers ................................ 6 1.3 Structure of the CompCert C compiler ............................. 9 1.4 CompCert C in practice ..................................... 11 1.4.1 Supported target platforms ............................... 11 1.4.2 The supported C dialect ................................ 12 1.4.3 Performance of the generated code ..........................
    [Show full text]
  • ESC-470: ARM 9 Instruction Set Architecture with Performance
    ARM 9 Instruction Set Architecture Introduction with Performance Perspective Joe-Ming Cheng, Ph.D. ARM-family processors are positioned among the leaders in key embedded applications. Many presentations and short lectures have already addressed the ARM’s applications and capabilities. In this introduction, we intend to discuss the ARM’s instruction set uniqueness from the performance prospective. This introduction is also trying to follow the approaches established by two outstanding textbooks of David Patterson and John Hennessey [PetHen00] [HenPet02]. 1.0 ARM Instruction Set Architecture Processor instruction set architecture (ISA) choices have evolved from accumulator, stack, register-to- memory, to register-register (load-store) organization. ARM 9 ISA is a load-store machine. ARM 9 ISA takes advantage of its smaller set of registers (16 vs. many 32-register processors) to incorporate more direct controls and achieve high encoding density. ARM’s load or store multiple register instruction, for example , allows enlisting of all possible registers and conditional execution in one instruction. The Thumb mode instruction set is another exa mple of how ARM ISA facilitates higher encode density. Rather than compressing the code, Thumb -mode instructions are two 16-bit instructions packed in a 32-bit ARM-mode instruction space. The Thumb -mode instructions are a subset of ARM instructions. When executing in Thumb mode, a single 32-bit instruction fetch cycle effectively brings in two instructions. Thumb code reduces access bandwidth, code size, and improves instruction cache hit rate. Another way ARM achieves cycle time reduction is by using Harvard architecture. The architecture facilitates independent data and instruction buses.
    [Show full text]
  • RISC-V Geneology
    RISC-V Geneology Tony Chen David A. Patterson Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2016-6 http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-6.html January 24, 2016 Copyright © 2016, 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. Introduction RISC-V is an open instruction set designed along RISC principles developed originally at UC Berkeley1 and is now set to become an open industry standard under the governance of the RISC-V Foundation (www.riscv.org). Since the instruction set architecture (ISA) is unrestricted, organizations can share implementations as well as open source compilers and operating systems. Designed for use in custom systems on a chip, RISC-V consists of a base set of instructions called RV32I along with optional extensions for multiply and divide (RV32M), atomic operations (RV32A), single-precision floating point (RV32F), and double-precision floating point (RV32D). The base and these four extensions are collectively called RV32G. This report discusses the historical precedents of RV32G. We look at 18 prior instruction set architectures, chosen primarily from earlier UC Berkeley RISC architectures and major proprietary RISC instruction sets. Among the 122 instructions in RV32G: ● 6 instructions do not have precedents among the selected instruction sets, ● 98 instructions of the 116 with precedents appear in at least three different instruction sets.
    [Show full text]
  • A CAD Tool for Synthesizing Optimized Variants of Altera's Nios II Soft-Core Processor
    A CAD Tool for Synthesizing Optimized Variants of Altera's Nios II Soft-Core Processor By Omar Al Rayahi A Thesis Submitted to the Faculty of Graduate Studies through Electrical and Computer Engineering in Partial Fulfillment of the Requirements for the Degree of Master of Applied Science at the University of Windsor Windsor, Ontario, Canada 2008 Library and Bibliotheque et 1*1 Archives Canada Archives Canada Published Heritage Direction du Branch Patrimoine de I'edition 395 Wellington Street 395, rue Wellington Ottawa ON K1A0N4 Ottawa ON K1A0N4 Canada Canada Your file Votre reference ISBN: 978-0-494-47050-3 Our file Notre reference ISBN: 978-0-494-47050-3 NOTICE: AVIS: The author has granted a non­ L'auteur a accorde une licence non exclusive exclusive license allowing Library permettant a la Bibliotheque et Archives and Archives Canada to reproduce, Canada de reproduire, publier, archiver, publish, archive, preserve, conserve, sauvegarder, conserver, transmettre au public communicate to the public by par telecommunication ou par Plntemet, prefer, telecommunication or on the Internet, distribuer et vendre des theses partout dans loan, distribute and sell theses le monde, a des fins commerciales ou autres, worldwide, for commercial or non­ sur support microforme, papier, electronique commercial purposes, in microform, et/ou autres formats. paper, electronic and/or any other formats. The author retains copyright L'auteur conserve la propriete du droit d'auteur ownership and moral rights in et des droits moraux qui protege cette these. this thesis. Neither the thesis Ni la these ni des extraits substantiels de nor substantial extracts from it celle-ci ne doivent etre imprimes ou autrement may be printed or otherwise reproduits sans son autorisation.
    [Show full text]
  • Small Soft Core up Inventory ©2019 James Brakefield Opencore and Other Soft Core Processors Reverse-U16 A.T
    tool pip _uP_all_soft opencores or style / data inst repor com LUTs blk F tool MIPS clks/ KIPS ven src #src fltg max max byte adr # start last secondary web status author FPGA top file chai e note worthy comments doc SOC date LUT? # inst # folder prmary link clone size size ter ents ALUT mults ram max ver /inst inst /LUT dor code files pt Hav'd dat inst adrs mod reg year revis link n len Small soft core uP Inventory ©2019 James Brakefield Opencore and other soft core processors reverse-u16 https://github.com/programmerby/ReVerSE-U16stable A.T. Z80 8 8 cylcone-4 James Brakefield11224 4 60 ## 14.7 0.33 4.0 X Y vhdl 29 zxpoly Y yes N N 64K 64K Y 2015 SOC project using T80, HDMI generatorretro Z80 based on T80 by Daniel Wallner copyblaze https://opencores.org/project,copyblazestable Abdallah ElIbrahimi picoBlaze 8 18 kintex-7-3 James Brakefieldmissing block622 ROM6 217 ## 14.7 0.33 2.0 57.5 IX vhdl 16 cp_copyblazeY asm N 256 2K Y 2011 2016 wishbone extras sap https://opencores.org/project,sapstable Ahmed Shahein accum 8 8 kintex-7-3 James Brakefieldno LUT RAM48 or block6 RAM 200 ## 14.7 0.10 4.0 104.2 X vhdl 15 mp_struct N 16 16 Y 5 2012 2017 https://shirishkoirala.blogspot.com/2017/01/sap-1simple-as-possible-1-computer.htmlSimple as Possible Computer from Malvinohttps://www.youtube.com/watch?v=prpyEFxZCMw & Brown "Digital computer electronics" blue https://opencores.org/project,bluestable Al Williams accum 16 16 spartan-3-5 James Brakefieldremoved clock1025 constraint4 63 ## 14.7 0.67 1.0 41.1 X verilog 16 topbox web N 4K 4K N 16 2 2009
    [Show full text]
  • Design of the RISC-V Instruction Set Architecture
    Design of the RISC-V Instruction Set Architecture Andrew Waterman Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2016-1 http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html January 3, 2016 Copyright © 2016, 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. Design of the RISC-V Instruction Set Architecture by Andrew Shell Waterman 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 David Patterson, Chair Professor Krste Asanovi´c Associate Professor Per-Olof Persson Spring 2016 Design of the RISC-V Instruction Set Architecture Copyright 2016 by Andrew Shell Waterman 1 Abstract Design of the RISC-V Instruction Set Architecture by Andrew Shell Waterman Doctor of Philosophy in Computer Science University of California, Berkeley Professor David Patterson, Chair The hardware-software interface, embodied in the instruction set architecture (ISA), is arguably the most important interface in a computer system. Yet, in contrast to nearly all other interfaces in a modern computer system, all commercially popular ISAs are proprietary.
    [Show full text]
  • An Executable Semantics for Compcert C⋆
    An Executable Semantics for CompCert C? Brian Campbell LFCS, University of Edinburgh, [email protected] Abstract. CompCert is a C compiler developed by Leroy et al, the ma- jority of which is formalised and verified in the Coq proof assistant. The correctness theorem is defined in terms of a semantics for the `CompCert C' language, but how can we gain faith in those semantics? We explore one approach: building an equivalent executable semantics that we can check test suites of code against. Flaws in a compiler are often reflected in the output they produce: buggy compilers produce buggy code. Moreover, bugs can evade testing when they only manifest themselves on source code of a particular shape, when particular opti- misations are used. This has made compilers an appealing target for mechanized verification, from early work such as Milner and Weyhrauch's simple compiler in LCF [15] to modern work on practical compilers, such as the Verisoft C0 compiler [10] which is used as a key component of a larger verified software system. The CompCert project [11] has become a nexus of activity in recent years, in- cluding the project members' own efforts to refine the compiler and add certified optimisations [22,18,8], and external projects such as an extensible optimisation framework [20] and compiling concurrent programs [23]. The main result of the project is a C compiler which targets the assembly languages for a number of popular processor architectures. Most of the compiler is formalised in the Coq proof assistant and accompanied by correctness results, most notably proving that any behaviour given to the assembly output must be an acceptable be- haviour for the C source program.
    [Show full text]
  • A VHDL Model of a Superscalar Implementation of the DLX Instruction Set Architcture
    Rochester Institute of Technology RIT Scholar Works Theses 10-1-1996 A VHDL model of a superscalar implementation of the DLX instruction set architcture Paul Ferno Follow this and additional works at: https://scholarworks.rit.edu/theses Recommended Citation Ferno, Paul, "A VHDL model of a superscalar implementation of the DLX instruction set architcture" (1996). Thesis. Rochester Institute of Technology. Accessed from This Thesis is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. A VHDL MODEL OF A SUPERSCALAR IMPLEMENTATION OF THE DLX INSTRUCTION SET ARCHITECTURE by Paul A. Femo A thesis submitted in partial fulfillment ofthe requirements for the degree of Masters ofScience in Computer Engineering Department ofComputer Engineering College ofEngineering Rochester Institute ofTechnology Rochester, New York October, 1996 Approvedby _ Dr. Kevin Shank, Assistant Professor Dr. Tony Chang, Professor Dr. Roy Czemikowski, Dept. Head and Professor THESIS RELEASE PERMISSION FORM ROCHESTER INSTITUTE OF TECHNOLOGY COLLEGE OF ENGINEERING Title: A VHDL Model ofa Superscalar Implementation ofthe DLX Instruction Set Architecture I, Paul A. Femo, hereby grant permission to the Wallace Memorial Library to reproduce my thesis in whole or part. Signature: _ Date: I(t-?£ ii Abstract The complexity of today's microprocessors demands that designers have an extensive knowledge of superscalar design techniques; this knowledge is difficult to acquire outside of a professional design team. Presently, there are a limited number of adequate resources available for the student, both in textual and model form.
    [Show full text]
  • Open-Source 32-Bit RISC Soft-Core Processors
    IOSR Journal of VLSI and Signal Processing (IOSR-JVSP) Volume 2, Issue 4 (May. – Jun. 2013), PP 43-46 e-ISSN: 2319 – 4200, p-ISSN No. : 2319 – 4197 www.iosrjournals.org Open-Source 32-Bit RISC Soft-Core Processors Rahul R.Balwaik, Shailja R.Nayak, Prof. Amutha Jeyakumar Department of Electrical Engineering, VJTI, Mumbai-19, INDIA Abstract: A soft-core processor build using a Field-Programmable Gate Array (FPGA)’s general-purpose logic represents an embedded processor commonly used for implementation. In a large number of applications; soft-core processors play a vital role due to their ease of usage. Soft-core processors are more advantageous than their hard-core counterparts due to their reduced cost, flexibility, platform independence and greater immunity to obsolescence. This paper presents a survey of a considerable number of soft core processors available from the open-source communities. Some real world applications of these soft-core processors are also discussed followed by the comparison of their several features and characteristics. The increasing popularity of these soft-core processors will inevitably lead to more widespread usage in embedded system design. This is due to the number of significant advantages that soft-core processors hold over their hard-core counterparts. Keywords: Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), open- source, soft-core processors. I. INTRODUCTION Field-Programmable Gate Array (FPGA) has grown in capacity and performance, and is now one of the main implementation fabrics for designs, particularly where the products do not demand for custom integrated circuits. And in recent past due to the increased capacity and falling cost of the FPGA’s relatively fast and high density devices are today becoming available to the general public.
    [Show full text]
  • Computer Architecture Instruction Set Architecture
    Computer Architecture Instruction Set Architecture Virendra Singh Associate Professor Computer Architecture and Dependable Systems Lab Department of Electrical Engineering Indian Institute of Technology Bombay http://www.ee.iitb.ac.in/~viren/ E-mail: [email protected] CS-683: Advanced Computr Architcture Lecture 2 (26 July 2013) CADSL What Are the Components of an ISA? • Some&mes known as The Programmer’s Model of the machine • Storage cells Ø General and special purpose registers in the CPU Ø Many general purpose cells of same size in memory Ø Storage associated with I/O devices • The machine instruc&on set Ø The instruc&on set is the en&re repertoire of machine operaons Ø Makes use of storage cells, formats, and results of the fetch/ execute cycle Ø i.e., register transfers 26 July 2013 CS683@IITB 2 CADSL What Are the Components of an ISA? • The instruc&on format Ø Size and meaning of fields within the instruc&on • The nature of the fetch-execute cycle Ø Things that are done before the operaon code is known 26 July 2013 CS683@IITB 3 CADSL Instruction • C Statement f = (g+h) – (i+j) Ø Assembly instruc&ons add t0, g, h add t1, I, j sub f, t0, t1 • Opcode/mnemonic, operand , source/ des&naon 26 July 2013 CS683@IITB 4 CADSL Why not Bigger Instructions? • Why not “f = (g+h) – (i+j)” as one instruc&on? • Church’s thesis: A very primi&ve computer can compute anything that a fancy computer can compute – you need only logical func&ons, read and write to memory, and data dependent decisions • Therefore, ISA selec&on is for prac&cal reasons – Performance and cost not computability • Regularity tends to improve both – E.g, H/W to handle arbitrary number of operands is complex and slow, and UNNECESSARY 26 July 2013 CS683@IITB 5 CADSL What Must an Instruction Specify?(I) Data Flow • Which operaon to perform add r0, r1, r3 – Ans: Op code: add, load, branch, etc.
    [Show full text]
  • RISC + Pipelines.Pdf
    RISC AND PIPELINING RISC vs CISC • Reduced Instruction Set Computer vs Complex Instruction Set Computers • for a given benchmark the performance of a particular computer: where P = time to execute 1 I = number of instructions executed P = 1 퐼∗퐶∗ 푆 C = clock cycles per instruction S = clock speed • RISC approach attempts to reduce C • CISC approach attempts to reduce I • assuming identical clock speeds: CRISC < CCISC [both < 1 with superscalar designs] a RISC will execute more instructions for a given benchmark than a CISC [10..30%] CSU34021 © 2019 [email protected] School of Computer Science and Statistics, Trinity College Dublin 31-Oct-19 1 RISC AND PIPELINING RISC-I • history • RISC-1 designed by MSc students under the direction of David Patterson and Carlo H. Séquin at UCLA Berkeley • released in 1982 • first RISC now accepted to be the IBM 801 [1980], but design not made public at the time • John Cocke later won both the Turing award and the Presidential Medal of Science for his work on the 801 • RISC-1 similar to SPARC [Sun, Oracle] and DLX/MIPS [discussing its pipeline later] • http://www.eecs.berkeley.edu/Pubs/TechRpts/1982/CSD-82-106.pdf CSU34021 © 2019 [email protected] School of Computer Science and Statistics, Trinity College Dublin 31-Oct-19 2 RISC AND PIPELINING RISC-I Design Criteria For an effective single chip solution artificially placed the following design constraints: • execute one instruction per cycle [instructions must be simple to be executed in one clock cycle] • make all instructions the same size [simplifies instruction decoding] • access main memory with load and store instructions [load/store architecture] • ONLY one addressing mode [indexed] • limited support for high level languages [which means C and hence Unix] procedure calling, local variables, constants, … CSU34021 © 2019 [email protected] School of Computer Science and Statistics, Trinity College Dublin 31-Oct-19 3 RISC AND PIPELINING RISC-I architecture • 32 x 32 bit registers r0 .
    [Show full text]
  • A Multipurpose Formal RISC-V Specification Without Creating New Tools
    A Multipurpose Formal RISC-V Specification Without Creating New Tools Thomas Bourgeat, Ian Clester, Andres Erbsen, Samuel Gruetter, Andrew Wright, Adam Chlipala MIT CSAIL Abstract experimentation in basic research, progressively extensible RISC-V is a relatively new, open instruction set architecture to full-fledged realistic systems. with a mature ecosystem and an official formal machine- readable specification. It is therefore a promising playground 1.2 From a golden standard to formal-methods for formal-methods research. infrastructure However, we observe that different formal-methods re- There is the potential for a mutually beneficial relationship search projects are interested in different aspects of RISC-V between the community of formal methods and the RISC-V and want to simplify, abstract, approximate, or ignore the community. other aspects. Often, they also require different encoding On the one hand, the RISC-V Foundation already adopted a styles, resulting in each project starting a new formalization golden standard in the form of an ISA specification in the Sail from-scratch. We set out to identify the commonalities be- language [6]. There is now an agreed-on, machine-processed tween projects and to represent the RISC-V specification as description of authorized behaviors for a significant portion a program with holes that can be instantiated differently by of the spec, beyond the usual natural-language description. different projects. On the other hand, the formal-methods community can Our formalization of the RISC-V specification is written leverage RISC-V as a great laboratory to prototype ideas, in Haskell and leverages existing tools rather than requiring where researchers will be able to get mature compilation new domain-specific tools, contrary to other approaches.
    [Show full text]