DOCSLIB.ORG

A Machine-Independent Microprogram

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

A MACHINE-INDEPENDENT MICROPROGRAM DEVELOPMENT SYSTEM THESIS Submitted in Fulfillment of t he Requirements for the Degree of MASTER OF SCIENCE of Rhodes University by MICHAEL JOHN WARD December 1986 SYSMW ACKNOWLEDGEMENTS. I express my sincere gratitude to my supervisor, Peter Clayton for his help and encouragement during the development of this thesis. His assistance with all aspects of the project is truely appreciated. I thank my mother for her love and support and especially my late father, who persuaded me to tackle the degree but who is unfortunately unable to witness its completion. I am deeply endepted to my fiancee, Carry for her love and inspiration throughout the year. To fellow students John, Karen, Pete and Glenn, thanks for helping to make this project a truely memorable and enjoyable one. Finally I acknowledge the financial support of the Council for Scientific and Industrial Research and Rhodes University. (-i-J Acknowledgements SYSMW ABSTRACT The aims of this project are twofold. They are firstly, to implement a microprogram development system that allows the programmer to write microcode for any microprogrammable machine, and secondly, to build a micro programmable machine, incorporating the user friendliness of a simulator, while still providing the 'hands on' experience obtained from working with actual hardware. Microprogram development involves a two stage process. The first step is to describe the target machine, using format descriptions and mnemonic-based template definitions. The second stage involves using the defined mnemonics to write the microcodes for the target machine. This includes an assembly phase to translate the mnemonics into the binary microinstructions. Three main components constitute the microprogrammable machine. The Arithmetic and Logic Unit (ALU) is built using chips from Advanced Micro Devices' Am2900 bit-slice family, the action of the Microprogram Control Unit (MCU) is simulated by software running on an IBM Personal Computer, and a section of the IBM PC's main memory acts as the Control Store (CS) for the system. The ALU is built on a prototypi ng card that pl ugs into one of the slots on the IBM PC's mother board. A hardware simulator program, that produces the effect of the ALU, has also been developed. A small assembly language has been developed using the system, to test the various functions of the system. A mini-assembler has also been written to facilitate assembly of the above language. A group of honours students at Rhodes University tested the microprogram development system. Their ideas and suggestions have been tabulated in this report and some of them have been used to enhance the (-ii-) Abstract SYSMW system's performance. The concept of allowing 'inline' microinstructions in the macroprogram is also investigated in this report and a method of implementing this is shown. (-iii- ) Abstract SYSMW CONTENTS. 0..!tline PART 1 5 Section 1 Introduction 6 1.1 Introduction to Microprogramming ..................... 6 1.2 History and Perspective .....•......................•.. 8 1.3 Vertical Migration ................................... 12 1.4 Microprogramming Terminology ......................... 14 1.5 Microprogram Development Systems ..••••..............•. 16 1.6 The Design Objectives of SYSMW ...•.•••.....•.......••• 19 Section 2 General Concepts and Scope 23 2.1 Requirements of Development Systems ..•.•....•.•.....•• 23 2.2 SYSMW in the context of Table Driven Assemblers . 25 2.2 .1 Ml.chine Description . • . • . • . • . • . • • . 25 2.2.2 Micro-code Development . • • . • • • . • • . • . 27 2.3 SYSMW and Microprogrammable Ml.chines and Simulators 29 2.4 SYSMW testing and Inline Microcode ..........•••.....•. 30 Section 3 Comparisons with other Systems 33 3.1 Microprogramming languages and Simulators 33 3 .1.1 Microprogramming Languages . .. .. ...••..... .. ... 33 3.1.2 AMD's SYS 29 ..................................... 38 3 .1.3 Simulators . .. .• . .. .. 39 3.2 Survey and Recent Developments in Bit-Slice components 41 Section 4 Discussion and Conclusions 43 4. 1 Discussion 43 4.2 Conclusions 45 (-iv- ) Contents SYSMW PART 2 47 Section 1 Design details 48 1.1 Introduction 48 1.2 The Target Ml.chine definition Program 50 1.3 The Microcode definition Program 56 1.4 The Development $ystem in Use 62 1.5 The Microprogrammable Ml.chine .............•... ..•.•••• 67 1.6 The Arithmetic Logic Unit hardware .......•....... .. ... 73 1.7 The Microprogram Control Unit emulator .....•••........ 80 1.8 ALU Simulator ....••...•.••...•...•...•................ 87 Section 2 Example 89 2 .1 Introduction 89 2.2 The Ml.chine Language Instructions 92 2.3 The Mini-Assembler program 96 Section 3 A User's guide ....•.............................. 100 3.1 Introduction . • . • . • . • 100 3.2 Micro 1 Program . • . • . 100 3.2.1 (N)ewfile option ................................. 102 3.2.2 (U )pdate option . 105 3.2.3 (P)rint option 107 3.2.4 (S)etup option 108 3.2 .5 Error messages 109 3.3 Micro2 Program • . .. 110 3.3 .1 (W)orkfile option .. .. .. 111 3.3.2 (E)ditfile option 112 3.3.3 (P)rintfile option 115 3. 3.4 (A)ssemble option 116 3.3.5 Error messages 117 3 . 4 Elnula tor Program 118 3.4.1 (R)un option 119 (- v- ) Contents SYSMW 3.4.2 (S)ingle option 119 3.4.3 (E)dit option 120 3.4 .4 (D) -bus option 120 3.4.5 (T)race option 121 3.4.6 (L)ook option 121 3.4.7 (M)PC option 121 3.4.8 (P)eek option ....•..••......••••...••••..•••••.•. 121 3 .4 .9 Error messages .•..•..•...•.•.••••.••••.•.••.•..•. 122 3.5 AssemMW Program ..•......•.••....•.••.•••••••••...•.... 122 3.5.1 (E)dit option ..•••••••••...••• •• .• ••• . ••• ....•.•• 123 3.5.2 (A)ssemble option .•.••.•••••••.•••..••.•••....••• 123 3.5.3 (P)rint option ..••...•••• •• ••• • •..•.•..••.••....• 123 Bibliography 124 Appendices . • . • . •. • • . .• • . • • • . •• . •. • . •. •• • . • • . •• . • A.1 A : Micro 1 program • . • • . • . • • . • • . • . • • . • A. 1 A. 1 Micro 1 listing • . • • . • • • . • • . • . • . • . • . • • . • . A. 1 A.2 Micro 1. PRN include file . • . • . • . • •• . • . •• • A.34 B Micro2 pr ogram .......•.••...•.....•....••.....•.......• B.1 B.1 Micro2 listing .•....•..••....•.•..•.....••.•..•..•• B.1 B.2 Micro2.PRN include file .•..•......•.•..••.••....• • B.30 B.3 Micro2. ASM include file • . • . • . • • • . • . • • B.40 C Elnulator program ......•..•. • ......•..••••.....•.•.....• C.1 C.1 Elnulator listing •......•................••...•...•. C.1 C.2 Elnulator .SIM include file ........•....••.........• C.33 D AssemMW program .•.••....... •••. ..........••.•....•..... D.1 D. 1 AssemMW listing .....••.••.............•.••...•..... D.1 E Help files E.1 E.1 Micro 1 helpfile E.1 E.2 Micro2 helpfile E.5 E.3 Elnulator helpfile E.8 (-vi- ) Contents SYSMW F Micro-order function tables . F. 1 G Example file listings . G. 1 G.1 Format file ........................................ G.1 G.2 Definition file .........................•.......... G.3 G.3 Table file ......................................... G.16 G.4 Macroinstruction definition file ................... G.29 G.5 Decode file . • . • . • . G. 34 G.6 Instruction file ......•............ • ......•...•...• G.35 G.7 Control Store . • . • . • • . G. 38 H Circuit diagrams H.1 H.1 Decode Circuits H.2 H.2 Wire-wrapped Circuit H.4 (-vii- ) Contents SYSMW TABLE OF FIGURES. Part 1.1 Schematic diagram of a generalised computer 6 1.2 Schematic diagram of a microprogrammable CPU 7 1.3 Graph of richness of instruction set repertoire vs cost 11 Part 2 1 .1 The microcode development system 48 1.2 The microprogrammable machine ...................•••.••. 49 1.3 The Micro 1 program files ..•••••....................•... 50 1.4 The Micro2 program files •...•....................••..•• 56 1.5 Layout of the code and micro files .................•..• 58 1.6 Schematic diagram of the processor circuit ..••......... 63 1.7 Control path schematic of the Triple-M machine ........• 69 1.8 Data path schematic of the Triple-M machine 70 1.9 The microinstruction fields 73 1.10 Schematic diagram of the ALU . • . .. 74 1.11 Connections between the ALU and MCU ..••................ 75 1 .12 The bread board ALU 76 1. 13 The wire wrapped prototyping board 77 /8 1. 14 Port assignment diagram 79 1 .15 The Emulator program files 80 2.1 The inline instruction data paths 95 2.2 The AssemMW program files 97 3.1 Micro 1 menu hierarchy 101 3.2 Micro2 menu hierarchy 110 3.3 Emulator menu hierarchy 118 C-viii- ) Table of figures SYSMW OUTLINE. This thesis, presented in two parts, describes SYSMW, a micropr ogram development system. Part 1 looks at the field of microprogramming in general and the underlying motivations for designing this type of system. SYSMW is discussed in terms of its broad principles and comparisons are drawn with other similar systems. Part 1 concludes with a critical assessment of the project and a discussion of possible research projects for which SYSMW may be used. Part 2 deals with the design details of the system. The software and the hardware are discussed and an example architecture is presented. Part 2 also includes a user's guide for the system. The appendices contain listings of the 'TURBO' Pascal [TUR] code, circuit diagrams, further data pertaining to the hardware, and the example architecture files. PART 1 1 : Introduction This section describes microprogramming systems in general. It includes a short history of microprogramming and discusses why microprogramming has become a plausible design option for the systems engineer. Two main areas of research in this field are identified, namely
Recommended publications
  • Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences

    Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences

    Downloaded from orbit.dtu.dk on: Oct 02, 2021 Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Hindborg, Andreas Erik; Schleuniger, Pascal; Jensen, Nicklas Bo; Karlsson, Sven Published in: Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) Publication date: 2014 Link back to DTU Orbit Citation (APA): Hindborg, A. E., Schleuniger, P., Jensen, N. B., & Karlsson, S. (2014). Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences. In A. Morawiec, & J. Hinderscheit (Eds.), Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) IEEE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Andreas Erik Hindborg, Pascal Schleuniger Nicklas Bo Jensen, Sven Karlsson DTU Compute – Technical University of Denmark fahin,pass,nboa,[email protected] Abstract—Field-programmable gate arrays, FPGAs, are at- speedup of up to 64% over a Xilinx MicroBlaze based baseline tractive implementation platforms for low-volume signal and system.
  • System Design for a Computational-RAM Logic-In-Memory Parailel-Processing Machine

    System Design for a Computational-RAM Logic-In-Memory Parailel-Processing Machine

    System Design for a Computational-RAM Logic-In-Memory ParaIlel-Processing Machine Peter M. Nyasulu, B .Sc., M.Eng. A thesis submitted to the Faculty of Graduate Studies and Research in partial fulfillment of the requirements for the degree of Doctor of Philosophy Ottaw a-Carleton Ins titute for Eleceical and Computer Engineering, Department of Electronics, Faculty of Engineering, Carleton University, Ottawa, Ontario, Canada May, 1999 O Peter M. Nyasulu, 1999 National Library Biôiiothkque nationale du Canada Acquisitions and Acquisitions et Bibliographie Services services bibliographiques 39S Weiiington Street 395. nie WeUingtm OnawaON KlAW Ottawa ON K1A ON4 Canada Canada The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, ban, distribute or seU reproduire, prêter, distribuer ou copies of this thesis in microform, vendre des copies de cette thèse sous paper or electronic formats. la forme de microficbe/nlm, de reproduction sur papier ou sur format électronique. The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fkom it Ni la thèse ni des extraits substantiels may be printed or otherwise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation. Abstract Integrating several 1-bit processing elements at the sense amplifiers of a standard RAM improves the performance of massively-paralle1 applications because of the inherent parallelism and high data bandwidth inside the memory chip.
  • Dop – a Cpu Core for Teaching Basics of Computer Architecture

    Dop – a Cpu Core for Teaching Basics of Computer Architecture

    DOP – A CPU CORE FOR TEACHING BASICS OF COMPUTER ARCHITECTURE Milos Becvar, Alois Pluhacek and Jiri Danecek Department of Computer Science and Engineering Faculty of Electrical Engineering Czech Technical University in Prague, Abstract: A simple 16-bit processor core called DOP and its teaching environment is presented. The DOP processor illustrates the basic principles of computer organization and is therefore used in the introductory hardware course. Its major features are simplicity, availability of an FPGA implementation and a C compiler. This paper presents the description of the core, HW and SW tools and teaching methodology. computing performance. The DOP processor core was 1. INTRODUCTION developed at our department together with various SW and HW visualization tools (Danecek et al., 1994a). An introductory computer hardware course should teach students to the fundamental principles of computer The goal of this paper is to describe this processor core internal functionality. Students, who are familiar with and its learning environment for teaching basics of programming in high-level languages, are required to computer organization. The paper is organized as understand the interaction between a processor, a follows - section 2 outlines the introductory course and memory and I/O devices, an internal organization of characterizes the students, section 3 describes the DOP processor, computer arithmetic and basics of digital processor core, section 4 describes the SW and HW design. Our experience has shown that it is not an easy tools supporting this processor and finally section 5 task for most of them. The functionality of the processor outlines the use of the DOP in our introductory course.
  • Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation

    Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation

    12 Bringing Virtualization to the x86 Architecture with the Original VMware Workstation EDOUARD BUGNION, Stanford University SCOTT DEVINE, VMware Inc. MENDEL ROSENBLUM, Stanford University JEREMY SUGERMAN, Talaria Technologies, Inc. EDWARD Y. WANG, Cumulus Networks, Inc. This article describes the historical context, technical challenges, and main implementation techniques used by VMware Workstation to bring virtualization to the x86 architecture in 1999. Although virtual machine monitors (VMMs) had been around for decades, they were traditionally designed as part of monolithic, single-vendor architectures with explicit support for virtualization. In contrast, the x86 architecture lacked virtualization support, and the industry around it had disaggregated into an ecosystem, with different ven- dors controlling the computers, CPUs, peripherals, operating systems, and applications, none of them asking for virtualization. We chose to build our solution independently of these vendors. As a result, VMware Workstation had to deal with new challenges associated with (i) the lack of virtual- ization support in the x86 architecture, (ii) the daunting complexity of the architecture itself, (iii) the need to support a broad combination of peripherals, and (iv) the need to offer a simple user experience within existing environments. These new challenges led us to a novel combination of well-known virtualization techniques, techniques from other domains, and new techniques. VMware Workstation combined a hosted architecture with a VMM. The hosted architecture enabled a simple user experience and offered broad hardware compatibility. Rather than exposing I/O diversity to the virtual machines, VMware Workstation also relied on software emulation of I/O devices. The VMM combined a trap-and-emulate direct execution engine with a system-level dynamic binary translator to ef- ficiently virtualize the x86 architecture and support most commodity operating systems.
  • 10. Assembly Language, Models of Computation

    10. Assembly Language, Models of Computation

    10. Assembly Language, Models of Computation 6.004x Computation Structures Part 2 – Computer Architecture Copyright © 2015 MIT EECS 6.004 Computation Structures L10: Assembly Language, Models of Computation, Slide #1 Beta ISA Summary • Storage: – Processor: 32 registers (r31 hardwired to 0) and PC – Main memory: Up to 4 GB, 32-bit words, 32-bit byte addresses, 4-byte-aligned accesses OPCODE rc ra rb unused • Instruction formats: OPCODE rc ra 16-bit signed constant 32 bits • Instruction classes: – ALU: Two input registers, or register and constant – Loads and stores: access memory – Branches, Jumps: change program counter 6.004 Computation Structures L10: Assembly Language, Models of Computation, Slide #2 Programming Languages 32-bit (4-byte) ADD instruction: 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 opcode rc ra rb (unused) Means, to the BETA, Reg[4] ß Reg[2] + Reg[3] We’d rather write in assembly language: Today ADD(R2, R3, R4) or better yet a high-level language: Coming up a = b + c; 6.004 Computation Structures L10: Assembly Language, Models of Computation, Slide #3 Assembly Language Symbolic 01101101 11000110 Array of bytes representation Assembler 00101111 to be loaded of stream of bytes 10110001 into memory ..... Source Binary text file machine language • Abstracts bit-level representation of instructions and addresses • We’ll learn UASM (“microassembler”), built into BSim • Main elements: – Values – Symbols – Labels (symbols for addresses) – Macros 6.004 Computation Structures L10: Assembly Language, Models
  • Programmable Digital Microcircuits - a Survey with Examples of Use

    Programmable Digital Microcircuits - a Survey with Examples of Use

    - 237 - PROGRAMMABLE DIGITAL MICROCIRCUITS - A SURVEY WITH EXAMPLES OF USE C. Verkerk CERN, Geneva, Switzerland 1. Introduction For most readers the title of these lecture notes will evoke microprocessors. The fixed instruction set microprocessors are however not the only programmable digital mi• crocircuits and, although a number of pages will be dedicated to them, the aim of these notes is also to draw attention to other useful microcircuits. A complete survey of programmable circuits would fill several books and a selection had therefore to be made. The choice has rather been to treat a variety of devices than to give an in- depth treatment of a particular circuit. The selected devices have all found useful ap• plications in high-energy physics, or hold promise for future use. The microprocessor is very young : just over eleven years. An advertisement, an• nouncing a new era of integrated electronics, and which appeared in the November 15, 1971 issue of Electronics News, is generally considered its birth-certificate. The adver• tisement was for the Intel 4004 and its three support chips. The history leading to this announcement merits to be recalled. Intel, then a very young company, was working on the design of a chip-set for a high-performance calculator, for and in collaboration with a Japanese firm, Busicom. One of the Intel engineers found the Busicom design of 9 different chips too complicated and tried to find a more general and programmable solu• tion. His design, the 4004 microprocessor, was finally adapted by Busicom, and after further négociation, Intel acquired marketing rights for its new invention.
  • Static Fault Attack on Hardware DES Registers

    Static Fault Attack on Hardware DES Registers

    Static Fault Attack on Hardware DES Registers Philippe Loubet-Moundi, Francis Olivier, and David Vigilant Gemalto, Security Labs, France {philippe.loubet-moundi,david.vigilant,francis.olivier}@gemalto.com http://www.gemalto.com Abstract. In the late nineties, Eli Biham and Adi Shamir published the first paper on Differential Fault Analysis on symmetric key algorithms. More specifically they introduced a fault model where a key bit located in non-volatile memory is forced to 0=1 with a fault injection. In their scenario the fault was permanent, and could lead the attacker to full key recovery with low complexity. In this paper, another fault model is considered: forcing a key bit to 0=1 in the register of a hardware block implementing Data Encryption Stan- dard. Due to the specific location of the fault, the key modification is not permanent in the life of the embedded device, and this leads to apply a powerful safe-error like attack. This paper reports a practical validation of the fault model on two actual circuits, and discusses limitations and efficient countermeasures against this threat. Keywords: Hardware DES, fault attacks, safe-error, register attacks 1 Introduction Fault attacks against embedded systems exploit the disturbed execution of a given program to infer sensitive data, or to execute unauthorized parts of this program. Usually a distinction is made between permanent faults and transient faults.A permanent fault alters the behavior of the device from the moment it is injected, and even if the device is powered off [8]. On the other hand, a transient fault has an effect limited in time, only a few cycles of the process are affected.
  • The Hpc C Compiler 2.1 Introduction

    The Hpc C Compiler 2.1 Introduction

    ™ MICROCONTROLLER DEVELOPMENT SUPPORT ( MOLE HPC™ C COMPILER USER'S MANUAL ( ( ( ( ~ National Semiconductor Corporation Customer Order Number 424410883-001 NSC Publication Number 424410883-001C October 1988 HPC™ C Compiler User's Manual @l 1988 National Semiconductor Corporation 2900 Semiconductor Drive P.O. Box 58090 Santa Clara. California 95052-8090 CONTENTS Chapter 1 OVERVIEW 1.1 INTRODUCTION............................. 1-1 1.2 MANUAL ORGANIZATION. .. 1-2 1.3 DOCUMENTATION CONVENTIONS. .. 1-2 1.3.1 General Conventions . .. 1-2 1.3.2 Conventions in Syntax Descriptions ............. 1-2 1.3.3 Example Conventions. .. 1-3 1.3.4 Additional Conventions .................... 1-3 Chapter 2 THE HPC C COMPILER 2.1 INTRODUCTION............................. 2-1 2.2 COMPILER COMMAND SYNTAX 2-1 Chapter 3 BASIC DEFINITIONS 3.1 INTRODUCTION............................. 3-1 3.2 NAMES.................................. 3-1 3.3 CONSTANTS............................... 3-1 3.4 ESCAPE SEQUENCES . .. 3-2 3.5 COMMENTS............................... 3-3 3.6 DATA TYPES. .. 3-3 3.7 PREPROCESSOR DIRECTIVES . .. 3-4 3.8 PROGRAM ORGANIZATION. .. 3-4 3.9 INITIALIZATION OF VARIABLES . .. 3-4 3.10 OPERATORS . .. 3-5 3.11 IN-LINE MICROASSEMBLER CODE . .. 3-5 Chapter 4 IMPLEMENTATION-DEPENDENT CONSIDERATIONS 4.1 INTRODUCTION............................. 4-1 4.2 MEMORy................................. 4-1 4.3 STORAGE CLASSES . .. 4-1 4.3.1 Storage Class Modifiers. .. 4-1 4.4 C STACK FORMAT . .. 4-3 4.5 USING IN-LINE MICROASSEMBLER CODE. .. 4-4 4.6 EFFICIENCY CONSIDERATIONS . .. 4-6 4.6.1 Declaration Syntax . .. 4-9 4.7 STATEMENTS AND IMPLEMENTATION .............. 4-10 4.8 RUN-TIME NOTES ........................... 4-11 v Appendix A CCHPC SPECIFICATIONS Appendix B CONVERTING BETWEEN STANDARD C AND CCHPC Appendix C INVOCATION LINE SYNTAX C.l INTRODUCTION............................
  • Validating Register Allocation and Spilling

    Validating Register Allocation and Spilling

    Validating Register Allocation and Spilling Silvain Rideau1 and Xavier Leroy2 1 Ecole´ Normale Sup´erieure,45 rue d'Ulm, 75005 Paris, France [email protected] 2 INRIA Paris-Rocquencourt, BP 105, 78153 Le Chesnay, France [email protected] Abstract. Following the translation validation approach to high- assurance compilation, we describe a new algorithm for validating a posteriori the results of a run of register allocation. The algorithm is based on backward dataflow inference of equations between variables, registers and stack locations, and can cope with sophisticated forms of spilling and live range splitting, as well as many architectural irregular- ities such as overlapping registers. The soundness of the algorithm was mechanically proved using the Coq proof assistant. 1 Introduction To generate fast and compact machine code, it is crucial to make effective use of the limited number of registers provided by hardware architectures. Register allocation and its accompanying code transformations (spilling, reloading, coa- lescing, live range splitting, rematerialization, etc) therefore play a prominent role in optimizing compilers. As in the case of any advanced compiler pass, mistakes sometimes happen in the design or implementation of register allocators, possibly causing incorrect machine code to be generated from a correct source program. Such compiler- introduced bugs are uncommon but especially difficult to exhibit and track down. In the context of safety-critical software, they can also invalidate all the safety guarantees obtained by formal verification of the source code, which is a growing concern in the formal methods world. There exist two major approaches to rule out incorrect compilations. Com- piler verification proves, once and for all, the correctness of a compiler or compi- lation pass, preferably using mechanical assistance (proof assistants) to conduct the proof.
  • V810 Familytm 32-Bit Microprocessor

    V810 Familytm 32-Bit Microprocessor

    V810 FAMILYTM 32-BIT MICROPROCESSOR ARCHITECTURE V805TM V810TM V820TM V821TM Document No. U10082EJ1V0UM00 (1st edition) Date Published October 1995P © 11995 Printed in Japan NOTES FOR CMOS DEVICES 1 PRECAUTION AGAINST ESD FOR SEMICONDUCTORS Note: Strong electric field, when exposed to a MOS device, can cause destruction of the gate oxide and ultimately degrade the device operation. Steps must be taken to stop generation of static electricity as much as possible, and quickly dissipate it once it has occurred. Environmental control must be adequate. When it is dry, humidifier should be used. It is recommended to avoid using insulators that easily build static electricity. Semiconductor devices must be stored and transported in an anti- static container, static shielding bag or conductive material. All test and measurement tools including work bench and floor should be grounded. The operator should be grounded using wrist strap. Semiconductor devices must not be touched with bare hands. Similar precautions need to be taken for PW boards with semiconductor devices on it. 2 HANDLING OF UNUSED INPUT PINS FOR CMOS Note: No connection for CMOS device inputs can be cause of malfunction. If no connection is provided to the input pins, it is possible that an internal input level may be generated due to noise, etc., hence causing malfunction. CMOS devices behave differently than Bipolar or NMOS devices. Input levels of CMOS devices must be fixed high or low by using a pull-up or pull-down circuitry. Each unused pin should be connected to VDD or GND with a resistor, if it is considered to have a possibility of being an output pin.
  • THE INVARIANCE THESIS 1. Introduction in 1936, Turing [47

    THE INVARIANCE THESIS 1. Introduction in 1936, Turing [47

    THE INVARIANCE THESIS NACHUM DERSHOWITZ AND EVGENIA FALKOVICH-DERZHAVETZ School of Computer Science, Tel Aviv University, Ramat Aviv, Israel e-mail address:[email protected] School of Computer Science, Tel Aviv University, Ramat Aviv, Israel e-mail address:[email protected] Abstract. We demonstrate that the programs of any classical (sequential, non-interactive) computation model or programming language that satisfies natural postulates of effective- ness (which specialize Gurevich’s Sequential Postulates)—regardless of the data structures it employs—can be simulated by a random access machine (RAM) with only constant factor overhead. In essence, the postulates of algorithmicity and effectiveness assert the following: states can be represented as logical structures; transitions depend on a fixed finite set of terms (those referred to in the algorithm); all atomic operations can be pro- grammed from constructors; and transitions commute with isomorphisms. Complexity for any domain is measured in terms of constructor operations. It follows that any algorithmic lower bounds found for the RAM model also hold (up to a constant factor determined by the algorithm in question) for any and all effective classical models of computation, what- ever their control structures and data structures. This substantiates the Invariance Thesis of van Emde Boas, namely that every effective classical algorithm can be polynomially simulated by a RAM. Specifically, we show that the overhead is only a linear factor in either time or space (and a constant factor in the other dimension). The enormous number of animals in the world depends of their varied structure & complexity: — hence as the forms became complicated, they opened fresh means of adding to their complexity.
  • WCAE 2003 Workshop on Computer Architecture Education

    WCAE 2003 Workshop on Computer Architecture Education

    WCAE 2003 Proceedings of the Workshop on Computer Architecture Education in conjunction with The 30th International Symposium on Computer Architecture DQG 2003 Federated Computing Research Conference Town and Country Resort and Convention Center b San Diego, California June 8, 2003 Workshop on Computer Architecture Education Sunday, June 8, 2003 Session 1. Welcome and Keynote 8:45–10:00 8:45 Welcome Edward F. Gehringer, workshop organizer 8:50 Keynote address, “Teaching and teaching computer Architecture: Two very different topics (Some opinions about each),” Yale Patt, teacher, University of Texas at Austin 1 Break 10:00–10:30 Session 2. Teaching with New Architectures 10:30–11:20 10:30 “Intel Itanium floating-point architecture,” Marius Cornea, John Harrison, and Ping Tak Peter Tang, Intel Corp. ................................................................................................................................. 5 10:50 “DOP — A CPU core for teaching basics of computer architecture,” Miloš BeþváĜ, Alois Pluháþek and JiĜí DanƟþek, Czech Technical University in Prague ................................................................. 14 11:05 Discussion Break 11:20–11:30 Session 3. Class Projects 11:30–12:30 11:30 “Superscalar out-of-order demystified in four instructions,” James C. Hoe, Carnegie Mellon University ......................................................................................................................................... 22 11:50 “Bridging the gap between undergraduate and graduate experience in