DOCSLIB.ORG

Dynamic Re-Compilation of Binary RISC Code for CISC Architectures

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Dynamic Re-Compilation of Binary RISC Code for CISC Architectures d d d d d d d d d d d d d d d d d d d d Technische Universitat¨ Munchen¨ Institut fur¨ Informatik Diplomarbeit Dynamic Re-compilation of Binary RISC Code for CISC Architectures Verfasser: Michael Steil Betreuer: Dr. Georg Acher Aufgabensteller: Prof. Dr. A.Bode Abgabetermin: 15. September 2004 Ich versichere, daß ich diese Diplomarbeit selbstandig¨ verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Munchen,¨ den 15.09.2004 Abstract This thesis describes a dynamic binary translation system that has the following features: • RISC (PowerPC) machine code is translated into CISC (i386) code. Special prob- lems caused by this combination, such as register allocation and condition code con- version, are addressed. • A modified hotspot method is used to do recompilation in two translation passes in order to gain speed. • The first translation pass is optimized for maximum translation speed and designed to be only slightly slower than one interpretive run. • The system optimizes common cases found in compiled user mode code, such as certain stack operations. The idea of this system is not to develop a high-level decompiler/compiler combination, but to do translation on a very low level and on an instruction basis. The recompiler that has been developed contains • recompiler technology that only needs about 25% more time per instruction for trans- lation compared to a single interpretation, and produces code that is only 3 to 4 times slower than native code. • recompiler technology that only needs about double the time per instruction for trans- lation compared to a single interpretation, and produces code that only takes twice as long for execution as native code. • recompiler technology that, without using intermediate code, optimizes full functions and allocates registers dynamically; and achieves speed close to that of native code. I would like to thank Georg Acher (supervision), Christian Hessmann (discussions, proofreading), Melissa Mears (discussions, proofreading), Axel Auweter (discussions, support code). Daniel Lehmann (discussions, proofreading), Tobias Bratfisch (support code), Sebastian Biallas (discussions), Costis (discussions), Alexan- der Mayer (proofreading) and Wolfgang Zehtner (proofreading) for their support. Contents 1 Motivation 13 2 Introduction to Emulation, RISC and CISC 17 2.1 Introduction to Emulation and Recompilation . 17 2.1.1 CPU Emulation Accuracy . 19 2.1.2 System Emulation vs. User Mode/API Emulation . 20 2.1.2.1 System Emulation . 21 2.1.2.2 User Mode & API Emulation . 21 2.1.2.3 Advantages of the Respective Concepts . 22 2.1.3 Interpretation and Recompilation . 24 2.1.3.1 Interpretation . 24 2.1.3.2 Recompilation . 26 2.1.4 Static Recompilation vs. Dynamic Recompilation . 29 2.1.4.1 Static Recompilation . 29 2.1.4.2 Dynamic Recompilation . 31 2.1.5 Hotspot: Interpretation/Recompilation . 34 2.1.6 Liveness Analysis and Register Allocation . 35 2.1.6.1 Liveness Analysis . 36 2.1.6.2 Register Allocation . 38 2.2 Endianness . 40 2.3 Intel i386 . 41 2.3.1 CISC . 42 2.3.2 History . 43 2.3.3 AT&T and Intel Syntax . 46 2.3.4 Registers . 46 2.3.5 Addressing Modes . 47 2.3.5.1 Characteristics . 48 2.3.5.2 r/m Addressing . 48 2.3.6 Instruction Set . 49 2.3.7 Instruction Encoding . 50 2.3.8 Endianness . 50 2.3.9 Stack Frames and Calling Conventions . 50 2.4 PowerPC . 52 2.4.1 RISC . 52 2.4.2 History . 53 5 6 CONTENTS 2.4.3 Registers . 54 2.4.4 Instruction Set and Addressing Modes . 54 2.4.5 Instruction Encoding . 55 2.4.6 Endianness . 55 2.4.7 Stack Frames and Calling Conventions . 56 2.4.8 Unique PowerPC Characteristics . 57 3 Design 59 3.1 Differences between PowerPC and i386 . 59 3.1.1 Modern RISC and CISC CPUs . 59 3.1.2 Problems of RISC/CISC Recompilation . 60 3.2 Objectives and Design Fundamentals . 62 3.2.1 Possible Objectives . 62 3.2.2 How to Reconcile all Aims . 62 3.3 Design Details . 63 3.3.1 The Hotspot Principle Revisited . 64 3.3.2 Register Mapping . 68 3.3.2.1 Simple Candidates . 68 3.3.2.2 Details of Static Mapping . 74 3.3.3 Condition Code Mapping . 81 3.3.3.1 Parity Flag . 82 3.3.3.2 Conversion to Signed Using a Table . 83 3.3.3.3 Conversion to PowerPC Format . 84 3.3.3.4 Intermediate i386 Flags . 84 3.3.3.5 Memory Access Optimization . 84 3.3.3.6 The Final Code . 85 3.3.3.7 Compatibility Issues . 86 3.3.4 Endianness . 87 3.3.4.1 Do Nothing . 87 3.3.4.2 Byte Swap . 87 3.3.4.3 Swapped Memory . 89 3.3.4.4 Conclusion . 92 3.3.5 Instruction Recompiler . 93 3.3.5.1 Dispatcher . 93 3.3.5.2 Decoder . 93 3.3.5.3 i386 Converter . 94 3.3.5.4 Instruction Encoder . 95 3.3.5.5 Speed Considerations . 95 3.3.6 Basic Block Logic . 95 3.3.6.1 Basic Blocks . 95 3.3.6.2 Basic Block Cache . 96 3.3.6.3 Control Flow Instructions . 96 3.3.6.4 Basic Block Linking . 97 3.3.6.5 Interpreter Fallback . 98 3.3.7 Environment . 99 CONTENTS 7 3.3.7.1 Loader . 99 3.3.7.2 Memory Environment . 99 3.3.7.3 Disassembler . 100 3.3.7.4 Execution . 100 3.3.8 Pass 2 Design . 100 3.3.8.1 Register Mapping Problem . 101 3.3.8.2 Condition Code Optimization . 101 3.3.8.3 Link Register Inefficiency . 102 3.3.8.4 Intermediate Code . 102 3.3.8.5 Pass 2 Design Overview . 105 3.3.9 Dynamic Register Allocation . 105 3.3.9.1 Design Overview . 105 3.3.9.2 Finding Functions . 106 3.3.9.3 Gathering use/def/pred/succ Information . 106 3.3.9.4 Register Allocation . 107 3.3.9.5 Signature Reconstruction . 107 3.3.9.6 Retranslation . 108 3.3.9.7 Address Backpatching . 109 3.3.9.8 Condition Codes . 109 3.3.10 Function Call Convertion . 110 3.3.10.1 ”call” and ”ret” . 110 3.3.10.2 Stack Frame Size . 111 3.3.10.3 ”lr” Sequence Elimination . 111 4 Some Implementation Details 113 4.1 Objectives and Concepts of the Implementation . 113 4.2 Loader . 114 4.3 Disassembler . 114 4.4 Interpreter . 114 4.5 Basic Block Cache . 115 4.6 Basic Block Linking . 115 4.7 Instruction Recompiler . 116 4.7.1 Dispatcher . 116 4.7.2 Decoder . 116 4.7.3 Register Mapping . 117 4.7.4 i386 Converter . 118 4.7.5 Instruction Encoder . 119 4.7.6 Speed of the Translation in Four Steps . 120 4.7.7 Execution . 120 4.8 Dynamic Register Allocation . 121 5 Effective Code Quality and Code Speed 123 5.1 Pass 1 . 123 5.1.1 Code Quality . 124 5.1.2 Speed of the Recompiled Code . 128 8 CONTENTS 5.2 Pass 2 . ..
Load more

Recommended publications
  • How Do Fixes Become Bugs?
    How Do Fixes Become Bugs? A Comprehensive Characteristic Study on Incorrect Fixes in Commercial and Open Source Operating Systems Zuoning Yin‡, Ding Yuan‡, Yuanyuan Zhou†, Shankar Pasupathy∗, Lakshmi Bairavasundaram∗ ‡Department of Computer Science, Univ. of Illinois at Urbana-Champaign, Urbana, IL 61801, USA {zyin2, dyuan3}@cs.uiuc.edu †Department of Computer Science and Engineering, Univ. of California, San Diego, La Jolla , CA 92093, USA [email protected] ∗NetApp Inc., Sunnyvale, CA 94089, USA {pshankar, lakshmib}@netapp.com ABSTRACT Keywords: Incorrect fixes, software bugs, bug fixing, hu- Software bugs affect system reliability. When a bug is ex- man factor, testing posed in the field, developers need to fix them. Unfor- tunately, the bug-fixing process can also introduce errors, 1. INTRODUCTION which leads to buggy patches that further aggravate the damage to end users and erode software vendors’ reputa- 1.1 Motivation tion. As a man-made artifact, software suffers from various er- This paper presents a comprehensive characteristic study rors, referred to as software bugs, which cause crashes, hangs on incorrect bug-fixes from large operating system code bases or incorrect results and significantly threaten not only the including Linux, OpenSolaris, FreeBSD and also a mature reliability but also the security of computer systems. Bugs commercial OS developed and evolved over the last 12 years, are detected either during testing before release or in the investigating not only the mistake patterns during bug-fixing field by customers post-release. Once a bug is discovered, but also the possible human reasons in the development pro- developers usually need to fix it.
    [Show full text]
  • US 2002/0066086 A1 Linden (43) Pub
    US 2002O066086A1 (19) United States (12) Patent Application Publication (10) Pub. No.: US 2002/0066086 A1 Linden (43) Pub. Date: May 30, 2002 (54) DYNAMIC RECOMPLER (52) U.S. Cl. ............................................ 717/145; 717/151 (76) Inventor: Randal N. Linden, Los Angeles, CA (57) ABSTRACT (US) A method for dynamic recompilation of Source Software Correspondence Address: instructions for execution by a target processor, which LU & LIU LLP considers not only the Specific Source instructions, but also 811 WEST SEVENTH STREET, SUITE 1100 the intent and purpose of the instructions, to translate and LOS ANGELES, CA 90017 (US) optimize a set of equivalent code for the target processor. The dynamic recompiler determines what the Source opera (21) Appl. No.: 09/755,542 tion code is trying to accomplish and the optimum way of Filed: Jan. 5, 2001 doing it at the target processor, in an “interpolative' and (22) context Sensitive fashion. The Source instructions are pro Related U.S. Application Data cessed in blocks of varying Sizes by the dynamic recompiler, which considers the instructions that come before and after (63) Non-provisional of provisional application No. a current instruction to determine the most efficient approach 60/175,008, filed on Jan. 7, 2000. out of Several available approaches for encoding the opera tion code for the target processor to perform the equivalent Publication Classification tasks Specified by the Source instructions. The dynamic compiler comprises a decoding Stage, an optimization Stage (51) Int. Cl. ................................................. G06F 9/45 and an encoding Stage. Patent Application Publication May 30, 2002 Sheet 1 of 3 US 2002/0066086 A1 Patent Application Publication May 30, 2002 Sheet 2 of 3 US 2002/0066086 A1 - \O, 2 Patent Application Publication May 30, 2002 Sheet 3 of 3 US 2002/0066086 A1 fo, 3 US 2002/0066086 A1 May 30, 2002 DYNAMIC RECOMPLER more target instructions to be executed in response to a given Source instruction.
    [Show full text]
  • Virtual Machine Technologies and Their Application in the Delivery of ICT
    Virtual Machine Technologies and Their Application In The Delivery Of ICT William McEwan accq.ac.nz n Christchurch Polytechnic Institute of Technology Christchurch, New Zealand [email protected] ABSTRACT related areas - a virtual machine or network of virtual machines can be specially configured, allowing an Virtual Machine (VM) technology was first ordinary user supervisor rights, and it can be tested implemented and developed by IBM to destruction without any adverse effect on the corporation in the early 1960's as a underlying host system. mechanism for providing multi-user facilities This paper hopes to also illustrate how VM in a secure mainframe computing configurations can greatly reduce our dependency on environment. In recent years the power of special purpose, complex, and expensive laboratory personal computers has resulted in renewed setups. It also suggests the important additional role interest in the technology. This paper begins that VM and VNL is likely to play in offering hands-on by describing the development of VM. It practical experience to students in a distance e- discusses the different approaches by which learning environment. a VM can be implemented, and it briefly considers the advantages and disadvantages Keywords: Virtual Machines, operating systems, of each approach. VM technology has proven networks, e-learning, infrastructure, server hosting. to be extremely useful in facilitating the Annual NACCQ, Hamilton New Zealand July, 2002 www. Annual NACCQ, Hamilton New Zealand July, teaching of multiple operating systems. It th offers an alternative to the traditional 1. INTRODUCTION approaches of using complex combinations Virtual Machine (VM) technology is not new. It was of specially prepared and configured OS implemented on mainframe computing systems by the images installed via the network or installed IBM Corporation in the early 1960’s (Varian 1997 pp permanently on multiple partitions or on 3-25, Gribben 1989 p.2, Thornton 2000 p.3, Sugarman multiple physical hard drives.
    [Show full text]
  • OLD PRETENDER Lovrenc Gasparin, Fotolia
    COVER STORY Bochs Emulator Legacy emulator OLD PRETENDER Lovrenc Gasparin, Fotolia Gasparin, Lovrenc Bochs, the granddaddy of all emulators, is alive and kicking; thanks to regular vitamin jabs, the lively old pretender can even handle Windows XP. BY TIM SCHÜRMANN he PC emulator Bochs first saw the 2.2.6 version in the Universe reposi- box). This also applies if you want to the light of day in 1994. Bochs’ tory; you will additionally need to install run Bochs on a pre-Pentium CPU, such Tinventor, Kevin Lawton, distrib- the Bximage program. (Bximage is al- as a 486. uted the emulator under a commercial li- ready part of the Bochs RPM for open- After installation, the program will cense before selling to French Linux ven- SUSE.) If worst comes to worst, you can simulate a complete PC, including CPU, dor Mandriva (which was then known always build your own Bochs from the graphics, sound card, and network inter- as MandrakeSoft). Mandriva freed the source code (see the “Building Bochs” face. The virtual PC in a PC works so emulator from its commercial chains, re- leasing Bochs under the LGPL license. Building Bochs If you prefer to build your own Bochs, or an additional --enable-ne2000 parameter Installation if you have no alternative, you will first to configure. The extremely long list of Bochs has now found a new home at need to install the C++ compiler and de- parameters in the user manual [2] gives SourceForge.net [1] (Figure 1). You can veloper packages for the X11 system. you a list of available options.
    [Show full text]
  • A Dynamically Recompiling ARM Emulator POWERED
    POWERED TACARM A Dynamically Recompiling ARM Emulator 3rd year project report 2000-2001 University of Warwick Written by David Sharp Supervised by Graham Martin 2 Abstract Dynamically recompiling from one machine code to another can be used to emulate modern microprocessors at realistic speeds. This report is a discussion of the techniques used in implementing a dynamically recompiling emulator of an ARM processor for use in an emulation of a complete computer system. Keywords Emulation, Dynamic Recompilation, Binary Translation, Just-In-Time compilation, Virtual Machine, Microprocessor Simulation, Intermediate Code, ARM. 3 Contents 1. Introduction 7 1.1. What is emulation? 7 1.2. Applications of emulation 7 1.3. Processor emulation techniques 9 1.4. This Project 13 2. Analysis 16 2.1. Introduction to the ARM 16 2.2. Identifying the problem 18 2.3. Getting started 20 2.4. The System Design 21 3. Disassembler 23 3.1. Purpose 23 3.2. ARM decoding 23 3.3. Design 24 4. Interpreter 26 4.1. Purpose 26 4.2. The problem with JIT 26 4.3. The HotSpotTM alternative 26 4.4. Quantifying the JIT problem 27 4.5. Faster decoding 28 4.6. Interfaces 29 4.7. The emulation loop 30 4.8. Implementation 31 4.9. Debugging 32 4.10. Compatibility 33 5. Recompilation 35 5.1. Overview 35 5.2. Methods of generating native code 35 5.3. The use of intermediate code 36 6. Armlets – An Intermediate Code 38 6.1. Purpose 38 6.2. The ‘explicit-implicit problem’ 38 6.3. Options 39 6.4.
    [Show full text]
  • A Brief History of Just-In-Time Compilation
    A Brief History of Just-In-Time JOHN AYCOCK University of Calgary Software systems have been using “just-in-time” compilation (JIT) techniques since the 1960s. Broadly, JIT compilation includes any translation performed dynamically, after a program has started execution. We examine the motivation behind JIT compilation and constraints imposed on JIT compilation systems, and present a classification scheme for such systems. This classification emerges as we survey forty years of JIT work, from 1960–2000. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors; K.2 [History of Computing]: Software General Terms: Languages, Performance Additional Key Words and Phrases: Just-in-time compilation, dynamic compilation 1. INTRODUCTION into a form that is executable on a target platform. Those who cannot remember the past are con- What is translated? The scope and na- demned to repeat it. ture of programming languages that re- George Santayana, 1863–1952 [Bartlett 1992] quire translation into executable form covers a wide spectrum. Traditional pro- This oft-quoted line is all too applicable gramming languages like Ada, C, and in computer science. Ideas are generated, Java are included, as well as little lan- explored, set aside—only to be reinvented guages [Bentley 1988] such as regular years later. Such is the case with what expressions. is now called “just-in-time” (JIT) or dy- Traditionally, there are two approaches namic compilation, which refers to trans- to translation: compilation and interpreta- lation that occurs after a program begins tion. Compilation translates one language execution. into another—C to assembly language, for Strictly speaking, JIT compilation sys- example—with the implication that the tems (“JIT systems” for short) are com- translated form will be more amenable pletely unnecessary.
    [Show full text]
  • Introduction to Virtualization Virtualization
    Introduction to Virtualization Prashant Shenoy Computer Science CS691D: Hot-OS Lecture 2, page 1 Virtualization • Virtualization: extend or replace an existing interface to mimic the behavior of another system. – Introduced in 1970s: run legacy software on newer mainframe hardware • Handle platform diversity by running apps in VMs – Portability and flexibility Computer Science CS691D: Hot-OS Lecture 2, page 2 Types of Interfaces • Different types of interfaces – Assembly instructions – System calls – APIs • Depending on what is replaced /mimiced, we obtain different forms of virtualization Computer Science CS691D: Hot-OS Lecture 2, page 3 Types of Virtualization • Emulation – VM emulates/simulates complete hardware – Unmodified guest OS for a different PC can be run • Bochs, VirtualPC for Mac, QEMU • Full/native Virtualization – VM simulates “enough” hardware to allow an unmodified guest OS to be run in isolation • Same hardware CPU – IBM VM family, VMWare Workstation, Parallels,… Computer Science CS691D: Hot-OS Lecture 2, page 4 Types of virtualization • Para-virtualization – VM does not simulate hardware – Use special API that a modified guest OS must use – Hypercalls trapped by the Hypervisor and serviced – Xen, VMWare ESX Server • OS-level virtualization – OS allows multiple secure virtual servers to be run – Guest OS is the same as the host OS, but appears isolated • apps see an isolated OS – Solaris Containers, BSD Jails, Linux Vserver • Application level virtualization – Application is gives its own copy of components that are not shared • (E.g., own registry files, global objects) - VE prevents conflicts – JVM Computer Science CS691D: Hot-OS Lecture 2, page 5 Examples • Application-level virtualization: “process virtual machine” • VMM /hypervisor Computer Science CS691D: Hot-OS Lecture 2, page 6 The Architecture of Virtual Machines J Smith and R.
    [Show full text]
  • Virtual Alpha User Guide for Avanti, Avantiflex, & Freeaxp 05-JAN-2018 Version 3.0: This Manual Covers All Releases of Avanti™, Avantiflex™ and Freeaxp™
    Migration Specialties International, Inc. 217 West 2nd Street, Florence, CO 81226-1403 +1 719-784-9196 E-mail: [email protected] www.MigrationSpecialties.com Continuity in Computing Virtual Alpha User Guide for Avanti, AvantiFlex, & FreeAXP 05-JAN-2018 Version 3.0: This manual covers all releases of Avanti™, AvantiFlex™ and FreeAXP™. This manual describes how to install and use Avanti, AvantiFlex, and FreeAXP, Migration Specialties' AlphaServer 400 hardware emulators. AvantiFlex and Avanti are commercial products that require purchase of a product license. AvantiFlex and Avanti include 30 days of manufacturer support after purchase and the option to buy an extended support contract. FreeAXP can be used for personal and commercial purposes. FreeAXP is unsupported without purchase of a support contract. If you have questions or problems with FreeAXP and have not purchased a support contract, visit the FreeAXP forum at the OpenVMS Hobbyist web site. Avanti & Avanti Flex Links Product Info: http://www.migrationspecialties.com/Emulator-Alpha.html User Guide: http://www.migrationspecialties.com/pdf/VirtualAlpha_UserGuide.pdf Release Notes: http://www.migrationspecialties.com/pdf/VirtualAlpha_ReleaseNotes.pdf License: http://www.migrationspecialties.com/pdf/AvantiLicense.pdf SPD: http://www.migrationspecialties.com/pdf/Avanti_SPD.pdf Pricing Guide: http://www.migrationspecialties.com/pdf/VirtualAlphaPricingGuide.pdf FreeAXP Links Product Info: http://www.migrationspecialties.com/FreeAXP.html User Guide: http://www.migrationspecialties.com/pdf/VirtualAlpha_UserGuide.pdf Release Notes: http://www.migrationspecialties.com/pdf/VirtualAlpha_ReleaseNotes.pdf License: http://www.migrationspecialties.com/pdf/FreeAXP_License.pdf SPD: http://www.migrationspecialties.com/pdf/FreeAXP_SPD.pdf User Forum: http://www.vmshobbyist.com/forum/viewforum.php?forum_id=163 Download: http://www.migrationspecialties.com/FreeAXP.html Copyright 2018, Migration Specialties.
    [Show full text]
  • Openbsd Gaming Resource
    OPENBSD GAMING RESOURCE A continually updated resource for playing video games on OpenBSD. Mr. Satterly Updated August 7, 2021 P11U17A3B8 III Title: OpenBSD Gaming Resource Author: Mr. Satterly Publisher: Mr. Satterly Date: Updated August 7, 2021 Copyright: Creative Commons Zero 1.0 Universal Email: [email protected] Website: https://MrSatterly.com/ Contents 1 Introduction1 2 Ways to play the games2 2.1 Base system........................ 2 2.2 Ports/Editors........................ 3 2.3 Ports/Emulators...................... 3 Arcade emulation..................... 4 Computer emulation................... 4 Game console emulation................. 4 Operating system emulation .............. 7 2.4 Ports/Games........................ 8 Game engines....................... 8 Interactive fiction..................... 9 2.5 Ports/Math......................... 10 2.6 Ports/Net.......................... 10 2.7 Ports/Shells ........................ 12 2.8 Ports/WWW ........................ 12 3 Notable games 14 3.1 Free games ........................ 14 A-I.............................. 14 J-R.............................. 22 S-Z.............................. 26 3.2 Non-free games...................... 31 4 Getting the games 33 4.1 Games............................ 33 5 Former ways to play games 37 6 What next? 38 Appendices 39 A Clones, models, and variants 39 Index 51 IV 1 Introduction I use this document to help organize my thoughts, files, and links on how to play games on OpenBSD. It helps me to remember what I have gone through while finding new games. The biggest reason to read or at least skim this document is because how can you search for something you do not know exists? I will show you ways to play games, what free and non-free games are available, and give links to help you get started on downloading them.
    [Show full text]
  • Beyond MOV ADD XOR – the Unusual and Unexpected
    Beyond MOV ADD XOR the unusual and unexpected in x86 Mateusz "j00ru" Jurczyk, Gynvael Coldwind CONFidence 2013, Kraków Who • Mateusz Jurczyk o Information Security Engineer @ Google o http://j00ru.vexillium.org/ o @j00ru • Gynvael Coldwind o Information Security Engineer @ Google o http://gynvael.coldwind.pl/ o @gynvael Agenda • Getting you up to speed with new x86 research. • Highlighting interesting facts and tricks. • Both x86 and x86-64 discussed. Security relevance • Local vulnerabilities in CPU ↔ OS integration. • Subtle CPU-specific information disclosure. • Exploit mitigations on CPU level. • Loosely related considerations and quirks. x86 - introduction not required • Intel first ships 8086 in 1978 o 16-bit extension of the 8-bit 8085. • Only 80386 and later are used today. o first shipped in 1985 o fully 32-bit architecture o designed with security in mind . code and i/o privilege levels . memory protection . segmentation x86 - produced by... Intel, AMD, VIA - yeah, we all know these. • Chips and Technologies - left market after failed 386 compatible chip failed to boot the Windows operating system. • NEC - sold early Intel architecture compatibles such as NEC V20 and NEC V30; product line transitioned to NEC internal architecture http://www.cpu-collection.de/ x86 - other manufacturers Eastern Bloc KM1810BM86 (USSR) http://www.cpu-collection.de/ x86 - other manufacturers Transmeta, Rise Technology, IDT, National Semiconductor, Cyrix, NexGen, Chips and Technologies, IBM, UMC, DM&P Electronics, ZF Micro, Zet IA-32, RDC Semiconductors, Nvidia, ALi, SiS, GlobalFoundries, TSMC, Fujitsu, SGS-Thomson, Texas Instruments, ... (via Wikipedia) At first, a simple architecture... At first, a simple architecture... x86 bursted with new functions • No eXecute bit (W^X, DEP) o completely redefined exploit development, together with ASLR • Supervisor Mode Execution Prevention • RDRAND instruction o cryptographically secure prng • Related: TPM, VT-d, IOMMU Overall..
    [Show full text]
  • Computing :: Operatingsystems :: DOS Beyond 640K 2Nd
    DOS® Beyond 640K 2nd Edition DOS® Beyond 640K 2nd Edition James S. Forney Windcrest®/McGraw-Hill SECOND EDITION FIRST PRINTING © 1992 by James S. Forney. First Edition © 1989 by James S. Forney. Published by Windcrest Books, an imprint of TAB Books. TAB Books is a division of McGraw-Hill, Inc. The name "Windcrest" is a registered trademark of TAB Books. Printed in the United States of America. All rights reserved. The publisher takes no responsibility for the use of any of the materials or methods described in this book, nor for the products thereof. Library of Congress Cataloging-in-Publication Data Forney, James. DOS beyond 640K / by James S. Forney. - 2nd ed. p. cm. Rev. ed. of: MS-DOS beyond 640K. Includes index. ISBN 0-8306-9717-9 ISBN 0-8306-3744-3 (pbk.) 1. Operating systems (Computers) 2. MS-DOS (Computer file) 3. PC -DOS (Computer file) 4. Random access memory. I. Forney, James. MS-DOS beyond 640K. II. Title. QA76.76.063F644 1991 0058.4'3--dc20 91-24629 CIP TAB Books offers software for sale. For information and a catalog, please contact TAB Software Department, Blue Ridge Summit, PA 17294-0850. Acquisitions Editor: Stephen Moore Production: Katherine G. Brown Book Design: Jaclyn J. Boone Cover: Sandra Blair Design, Harrisburg, PA WTl To Sheila Contents Preface Xlll Acknowledgments xv Introduction xvii Chapter 1. The unexpanded system 1 Physical limits of the system 2 The physical machine 5 Life beyond 640K 7 The operating system 10 Evolution: a two-way street 12 What else is in there? 13 Out of hiding 13 Chapter 2.
    [Show full text]
  • How Do Fixes Become Bugs?
    How Do Fixes Become Bugs? A Comprehensive Characteristic Study on Incorrect Fixes in Commercial and Open Source Operating Systems Zuoning Yin‡, Ding Yuan‡, Yuanyuan Zhou†, Shankar Pasupathy∗, Lakshmi Bairavasundaram∗ ‡Department of Computer Science, Univ. of Illinois at Urbana-Champaign, Urbana, IL 61801, USA {zyin2, dyuan3}@cs.uiuc.edu †Department of Computer Science and Engineering, Univ. of California, San Diego, La Jolla , CA 92093, USA [email protected] ∗NetApp Inc., Sunnyvale, CA 94089, USA {pshankar, lakshmib}@netapp.com ABSTRACT Keywords: Incorrect fixes, software bugs, bug fixing, hu- Software bugs affect system reliability. When a bug is ex- man factor, testing posed in the field, developers need to fix them. Unfor- tunately, the bug-fixing process can also introduce errors, 1. INTRODUCTION which leads to buggy patches that further aggravate the damage to end users and erode software vendors’ reputa- 1.1 Motivation tion. As a man-made artifact, software suffers from various er- This paper presents a comprehensive characteristic study rors, referred to as software bugs, which cause crashes, hangs on incorrect bug-fixes from large operating system code bases or incorrect results and significantly threaten not only the including Linux, OpenSolaris, FreeBSD and also a mature reliability but also the security of computer systems. Bugs commercial OS developed and evolved over the last 12 years, are detected either during testing before release or in the investigating not only the mistake patterns during bug-fixing field by customers post-release. Once a bug is discovered, but also the possible human reasons in the development pro- developers usually need to fix it.
    [Show full text]