DOCSLIB.ORG

RTEMS CPU Supplement Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (Built 10Th July 2017)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
RTEMS CPU Supplement Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (Built 10Th July 2017) RTEMS CPU Supplement Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (built 10th July 2017) CONTENTS I RTEMS CPU Architecture Supplement1 1 Preface 3 2 Port Specific Information5 2.1 CPU Model Dependent Features...........................6 2.1.1 CPU Model Name...............................6 2.1.2 Floating Point Unit..............................6 2.2 Multilibs........................................8 2.3 Calling Conventions..................................9 2.3.1 Calling Mechanism..............................9 2.3.2 Register Usage.................................9 2.3.3 Parameter Passing...............................9 2.3.4 User-Provided Routines............................9 2.4 Memory Model..................................... 10 2.4.1 Flat Memory Model.............................. 10 2.5 Interrupt Processing.................................. 11 2.5.1 Vectoring of an Interrupt Handler...................... 11 2.5.2 Interrupt Levels................................ 11 2.5.3 Disabling of Interrupts by RTEMS...................... 12 2.6 Default Fatal Error Processing............................. 13 2.7 Symmetric Multiprocessing.............................. 14 2.8 Thread-Local Storage................................. 15 2.9 CPU counter...................................... 16 2.10 Interrupt Profiling................................... 17 2.11 Board Support Packages................................ 18 2.11.1 System Reset................................. 18 3 ARM Specific Information 19 3.1 CPU Model Dependent Features........................... 20 3.1.1 CPU Model Name............................... 20 3.1.2 Count Leading Zeroes Instruction...................... 20 3.1.3 Floating Point Unit.............................. 20 3.2 Multilibs........................................ 21 3.3 Calling Conventions.................................. 22 3.4 Memory Model..................................... 23 3.5 Interrupt Processing.................................. 24 3.5.1 Interrupt Levels................................ 24 3.5.2 Interrupt Stack................................ 24 i 3.6 Default Fatal Error Processing............................. 25 3.7 Symmetric Multiprocessing.............................. 26 3.8 Thread-Local Storage................................. 27 4 Atmel AVR Specific Information 29 4.1 CPU Model Dependent Features........................... 30 4.1.1 Count Leading Zeroes Instruction...................... 30 4.2 Calling Conventions.................................. 31 4.2.1 Processor Background............................ 31 4.2.2 Register Usage................................. 31 4.2.3 Parameter Passing............................... 31 4.3 Memory Model..................................... 32 4.4 Interrupt Processing.................................. 33 4.4.1 Vectoring of an Interrupt Handler...................... 33 4.4.2 Disabling of Interrupts by RTEMS...................... 33 4.4.3 Interrupt Stack................................ 33 4.5 Default Fatal Error Processing............................. 34 4.6 Symmetric Multiprocessing.............................. 35 4.7 Thread-Local Storage................................. 36 4.8 Board Support Packages................................ 37 4.8.1 System Reset................................. 37 5 Blackfin Specific Information 39 5.1 CPU Model Dependent Features........................... 40 5.1.1 Count Leading Zeroes Instruction...................... 40 5.2 Calling Conventions.................................. 41 5.2.1 Processor Background............................ 41 5.2.2 Register Usage................................. 41 5.2.3 Parameter Passing............................... 41 5.3 Memory Model..................................... 42 5.4 Interrupt Processing.................................. 43 5.4.1 Vectoring of an Interrupt Handler...................... 43 5.4.2 Disabling of Interrupts by RTEMS...................... 43 5.4.3 Interrupt Stack................................ 43 5.5 Default Fatal Error Processing............................. 44 5.6 Symmetric Multiprocessing.............................. 45 5.7 Thread-Local Storage................................. 46 5.8 Board Support Packages................................ 47 5.8.1 System Reset................................. 47 6 Epiphany Specific Information 49 6.1 Calling Conventions.................................. 50 6.1.1 Floating Point Unit.............................. 50 6.2 Memory Model..................................... 51 6.3 Interrupt Processing.................................. 52 6.3.1 Interrupt Levels................................ 52 6.3.2 Interrupt Stack................................ 52 6.4 Default Fatal Error Processing............................. 53 6.5 Symmetric Multiprocessing.............................. 54 7 Intel/AMD x86 Specific Information 55 7.1 CPU Model Dependent Features........................... 56 ii 7.1.1 bswap Instruction............................... 56 7.2 Calling Conventions.................................. 57 7.2.1 Processor Background............................ 57 7.2.2 Calling Mechanism.............................. 57 7.2.3 Register Usage................................. 57 7.2.4 Parameter Passing............................... 57 7.3 Memory Model..................................... 58 7.3.1 Flat Memory Model.............................. 58 7.4 Interrupt Processing.................................. 59 7.4.1 Vectoring of Interrupt Handler........................ 59 7.4.2 Interrupt Stack Frame............................ 59 7.4.3 Interrupt Levels................................ 59 7.4.4 Interrupt Stack................................ 59 7.5 Default Fatal Error Processing............................. 60 7.6 Symmetric Multiprocessing.............................. 61 7.7 Thread-Local Storage................................. 62 7.8 Board Support Packages................................ 63 7.8.1 System Reset................................. 63 7.8.2 Processor Initialization............................ 63 8 Lattice Mico32 Specific Information 65 8.1 CPU Model Dependent Features........................... 66 8.2 Register Architecture................................. 67 8.3 Calling Conventions.................................. 68 8.3.1 Calling Mechanism.............................. 68 8.3.2 Register Usage................................. 68 8.3.3 Parameter Passing............................... 68 8.4 Memory Model..................................... 69 8.5 Interrupt Processing.................................. 70 8.6 Default Fatal Error Processing............................. 71 8.7 Symmetric Multiprocessing.............................. 72 8.8 Thread-Local Storage................................. 73 8.9 Board Support Packages................................ 74 8.9.1 System Reset................................. 74 9 Renesas M32C Specific Information 75 9.1 Symmetric Multiprocessing.............................. 76 9.2 Thread-Local Storage................................. 77 10 M68xxx and Coldfire Specific Information 79 10.1 CPU Model Dependent Features........................... 80 10.1.1 BFFFO Instruction.............................. 80 10.1.2 Vector Base Register............................. 80 10.1.3 Separate Stacks................................ 80 10.1.4 Pre-Indexing Address Mode......................... 80 10.1.5 Extend Byte to Long Instruction....................... 80 10.2 Calling Conventions.................................. 81 10.2.1 Calling Mechanism.............................. 81 10.2.2 Register Usage................................. 81 10.2.3 Parameter Passing............................... 81 10.3 Memory Model..................................... 82 10.4 Interrupt Processing.................................. 83 iii 10.4.1 Vectoring of an Interrupt Handler...................... 83 10.4.1.1 Models Without Separate Interrupt Stacks............. 83 10.4.1.2 Models With Separate Interrupt Stacks............... 83 10.4.2 CPU Models Without VBR and RAM at 0.................. 84 10.4.3 Interrupt Levels................................ 85 10.5 Default Fatal Error Processing............................. 86 10.6 Symmetric Multiprocessing.............................. 87 10.7 Thread-Local Storage................................. 88 10.8 Board Support Packages................................ 89 10.8.1 System Reset................................. 89 10.8.2 Processor Initialization............................ 89 11 Xilinx MicroBlaze Specific Information 91 11.1 Symmetric Multiprocessing.............................. 92 11.2 Thread-Local Storage................................. 93 12 MIPS Specific Information 95 12.1 CPU Model Dependent Features........................... 96 12.1.1 Another Optional Feature.......................... 96 12.2 Calling Conventions.................................. 97 12.2.1 Processor Background............................ 97 12.2.2 Calling Mechanism.............................. 97 12.2.3 Register Usage................................. 97 12.2.4 Parameter Passing............................... 97 12.3 Memory Model..................................... 98 12.3.1 Flat Memory Model.............................. 98 12.4 Interrupt Processing.................................. 99 12.4.1 Vectoring of an Interrupt Handler...................... 99 12.4.2 Interrupt Levels................................ 99 12.5 Default Fatal Error Processing............................. 100 12.6 Symmetric Multiprocessing.............................. 101 12.7 Thread-Local
Load more

Recommended publications
  • MIPS Architecture
    Introduction to the MIPS Architecture January 14–16, 2013 1 / 24 Unofficial textbook MIPS Assembly Language Programming by Robert Britton A beta version of this book (2003) is available free online 2 / 24 Exercise 1 clarification This is a question about converting between bases • bit – base-2 (states: 0 and 1) • flash cell – base-4 (states: 0–3) • hex digit – base-16 (states: 0–9, A–F) • Each hex digit represents 4 bits of information: 0xE ) 1110 • It takes two hex digits to represent one byte: 1010 0111 ) 0xA7 3 / 24 Outline Overview of the MIPS architecture What is a computer architecture? Fetch-decode-execute cycle Datapath and control unit Components of the MIPS architecture Memory Other components of the datapath Control unit 4 / 24 What is a computer architecture? One view: The machine language the CPU implements Instruction set architecture (ISA) • Built in data types (integers, floating point numbers) • Fixed set of instructions • Fixed set of on-processor variables (registers) • Interface for reading/writing memory • Mechanisms to do input/output 5 / 24 What is a computer architecture? Another view: How the ISA is implemented Microarchitecture 6 / 24 How a computer executes a program Fetch-decode-execute cycle (FDX) 1. fetch the next instruction from memory 2. decode the instruction 3. execute the instruction Decode determines: • operation to execute • arguments to use • where the result will be stored Execute: • performs the operation • determines next instruction to fetch (by default, next one) 7 / 24 Datapath and control unit
    [Show full text]
  • Vxworks Architecture Supplement, 6.2
    VxWorks Architecture Supplement VxWorks® ARCHITECTURE SUPPLEMENT 6.2 Copyright © 2005 Wind River Systems, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc. Wind River, the Wind River logo, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see: http://www.windriver.com/company/terms/trademark.html This product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at the following location: installDir/product_name/3rd_party_licensor_notice.pdf. Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation. Corporate Headquarters Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501-1153 U.S.A. toll free (U.S.): (800) 545-WIND telephone: (510) 748-4100 facsimile: (510) 749-2010 For additional contact information, please visit the Wind River URL: http://www.windriver.com For information on how to contact Customer Support, please visit the following URL: http://www.windriver.com/support VxWorks Architecture Supplement, 6.2 11 Oct 05 Part #: DOC-15660-ND-00 Contents 1 Introduction
    [Show full text]
  • Risc I: a Reduced Instruction Set Vlsi Computer
    RISC I: A REDUCED INSTRUCTION SET VLSI COMPUTER DAVID A. PATTERSON and CARLO H. SEQUIN Computer Science Division University of California Berkeley, California ABSTRACT to implement CISC is the best way to use this “scarce” resource. The Reduced Instruction Set Computer (RISC) Project investigates an alternatrve to the general trend toward computers wrth increasingly complex instruction sets: With a The above findings led to the Reduced Instruction Set proper set of instructions and a corresponding architectural Computer (RISC) Project. The purpose of the project is design, a machine wrth a high effective throughput can be to explore alternatives to the general trend toward achieved. The simplicity of the instruction set and addressing architectural complexity. The hypothesis is that by modes allows most Instructions to execute in a single machine cycle, and the srmplicity of each instruction guarantees a short reducing the instruction set, VLSI architecture can be cycle time. In addition, such a machine should have a much designed that uses the scarce resources more effectively shorter design trme. than CISC. We also expect this approach to reduce design time, the number of design errors, and the This paper presents the architecture of RISC I and its novel execution time of individual instructions. hardware support scheme for procedure call/return. Overlapprng sets of regrster banks that can pass parameters directly to subrouttnes are largely responsible for the excellent Our initial version of such a computer is called RISC I. performance of RISC I. Static and dynamtc comparisons To meet our goals of simplicity and effective single-chip between this new architecture and more traditional machines implementation, we placed the following “constraints” are given.
    [Show full text]
  • Computer Architecture and Assembly Language
    Computer Architecture and Assembly Language Gabriel Laskar EPITA 2015 License I Copyright c 2004-2005, ACU, Benoit Perrot I Copyright c 2004-2008, Alexandre Becoulet I Copyright c 2009-2013, Nicolas Pouillon I Copyright c 2014, Joël Porquet I Copyright c 2015, Gabriel Laskar Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being just ‘‘Copying this document’’, no Front-Cover Texts, and no Back-Cover Texts. Introduction Part I Introduction Gabriel Laskar (EPITA) CAAL 2015 3 / 378 Introduction Problem definition 1: Introduction Problem definition Outline Gabriel Laskar (EPITA) CAAL 2015 4 / 378 Introduction Problem definition What are we trying to learn? Computer Architecture What is in the hardware? I A bit of history of computers, current machines I Concepts and conventions: processing, memory, communication, optimization How does a machine run code? I Program execution model I Memory mapping, OS support Gabriel Laskar (EPITA) CAAL 2015 5 / 378 Introduction Problem definition What are we trying to learn? Assembly Language How to “talk” with the machine directly? I Mechanisms involved I Assembly language structure and usage I Low-level assembly language features I C inline assembly Gabriel Laskar (EPITA) CAAL 2015 6 / 378 I Programmers I Wise managers Introduction Problem definition Who do I talk to? I System gurus I Low-level enthusiasts Gabriel Laskar (EPITA) CAAL
    [Show full text]
  • SIMD Extensions
    SIMD Extensions PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 12 May 2012 17:14:46 UTC Contents Articles SIMD 1 MMX (instruction set) 6 3DNow! 8 Streaming SIMD Extensions 12 SSE2 16 SSE3 18 SSSE3 20 SSE4 22 SSE5 26 Advanced Vector Extensions 28 CVT16 instruction set 31 XOP instruction set 31 References Article Sources and Contributors 33 Image Sources, Licenses and Contributors 34 Article Licenses License 35 SIMD 1 SIMD Single instruction Multiple instruction Single data SISD MISD Multiple data SIMD MIMD Single instruction, multiple data (SIMD), is a class of parallel computers in Flynn's taxonomy. It describes computers with multiple processing elements that perform the same operation on multiple data simultaneously. Thus, such machines exploit data level parallelism. History The first use of SIMD instructions was in vector supercomputers of the early 1970s such as the CDC Star-100 and the Texas Instruments ASC, which could operate on a vector of data with a single instruction. Vector processing was especially popularized by Cray in the 1970s and 1980s. Vector-processing architectures are now considered separate from SIMD machines, based on the fact that vector machines processed the vectors one word at a time through pipelined processors (though still based on a single instruction), whereas modern SIMD machines process all elements of the vector simultaneously.[1] The first era of modern SIMD machines was characterized by massively parallel processing-style supercomputers such as the Thinking Machines CM-1 and CM-2. These machines had many limited-functionality processors that would work in parallel.
    [Show full text]
  • MIPS IV Instruction Set
    MIPS IV Instruction Set Revision 3.2 September, 1995 Charles Price MIPS Technologies, Inc. All Right Reserved RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure of the technical data contained in this document by the Government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013 and / or in similar or successor clauses in the FAR, or in the DOD or NASA FAR Supplement. Unpublished rights reserved under the Copyright Laws of the United States. Contractor / manufacturer is MIPS Technologies, Inc., 2011 N. Shoreline Blvd., Mountain View, CA 94039-7311. R2000, R3000, R6000, R4000, R4400, R4200, R8000, R4300 and R10000 are trademarks of MIPS Technologies, Inc. MIPS and R3000 are registered trademarks of MIPS Technologies, Inc. The information in this document is preliminary and subject to change without notice. MIPS Technologies, Inc. (MTI) reserves the right to change any portion of the product described herein to improve function or design. MTI does not assume liability arising out of the application or use of any product or circuit described herein. Information on MIPS products is available electronically: (a) Through the World Wide Web. Point your WWW client to: http://www.mips.com (b) Through ftp from the internet site “sgigate.sgi.com”. Login as “ftp” or “anonymous” and then cd to the directory “pub/doc”. (c) Through an automated FAX service: Inside the USA toll free: (800) 446-6477 (800-IGO-MIPS) Outside the USA: (415) 688-4321 (call from a FAX machine) MIPS Technologies, Inc.
    [Show full text]
  • I386-Engine™ Technical Manual
    i386-Engine™ C/C++ Programmable, 32-bit Microprocessor Module Based on the Intel386EX Technical Manual 1950 5 th Street, Davis, CA 95616, USA Tel: 530-758-0180 Fax: 530-758-0181 Email: [email protected] http://www.tern.com Internet Email: [email protected] http://www.tern.com COPYRIGHT i386-Engine, VE232, A-Engine, A-Core, C-Engine, V25-Engine, MotionC, BirdBox, PowerDrive, SensorWatch, Pc-Co, LittleDrive, MemCard, ACTF, and NT-Kit are trademarks of TERN, Inc. Intel386EX and Intel386SX are trademarks of Intel Coporation. Borland C/C++ are trademarks of Borland International. Microsoft, MS-DOS, Windows, and Windows 95 are trademarks of Microsoft Corporation. IBM is a trademark of International Business Machines Corporation. Version 2.00 October 28, 2010 No part of this document may be copied or reproduced in any form or by any means without the prior written consent of TERN, Inc. © 1998-2010 1950 5 th Street, Davis, CA 95616, USA Tel: 530-758-0180 Fax: 530-758-0181 Email: [email protected] http://www.tern.com Important Notice TERN is developing complex, high technology integration systems. These systems are integrated with software and hardware that are not 100% defect free. TERN products are not designed, intended, authorized, or warranted to be suitable for use in life-support applications, devices, or systems, or in other critical applications. TERN and the Buyer agree that TERN will not be liable for incidental or consequential damages arising from the use of TERN products. It is the Buyer's responsibility to protect life and property against incidental failure. TERN reserves the right to make changes and improvements to its products without providing notice.
    [Show full text]
  • Design and VHDL Implementation of an Application-Specific Instruction Set Processor
    Design and VHDL Implementation of an Application-Specific Instruction Set Processor Lauri Isola School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 19.12.2019 Supervisor Prof. Jussi Ryynänen Advisor D.Sc. (Tech.) Marko Kosunen Copyright © 2019 Lauri Isola Aalto University, P.O. BOX 11000, 00076 AALTO www.aalto.fi Abstract of the master’s thesis Author Lauri Isola Title Design and VHDL Implementation of an Application-Specific Instruction Set Processor Degree programme Computer, Communication and Information Sciences Major Signal, Speech and Language Processing Code of major ELEC3031 Supervisor Prof. Jussi Ryynänen Advisor D.Sc. (Tech.) Marko Kosunen Date 19.12.2019 Number of pages 66+45 Language English Abstract Open source processors are becoming more popular. They are a cost-effective option in hardware designs, because using the processor does not require an expensive license. However, a limited number of open source processors are still available. This is especially true for Application-Specific Instruction Set Processors (ASIPs). In this work, an ASIP processor was designed and implemented in VHDL hardware description language. The design was based on goals that make the processor easily customizable, and to have a low resource consumption in a System- on-Chip (SoC) design. Finally, the processor was implemented on an FPGA circuit, where it was tested with a specially designed VGA graphics controller. Necessary software tools, such as an assembler were also implemented for the processor. The assembler was used to write comprehensive test programs for testing and verifying the functionality of the processor. This work also examined some future upgrades of the designed processor.
    [Show full text]
  • Xv6 Booting: Transitioning from 16 to 32 Bit Mode
    238P Operating Systems, Fall 2018 xv6 Boot Recap: Transitioning from 16 bit mode to 32 bit mode 3 November 2018 Aftab Hussain University of California, Irvine BIOS xv6 Boot loader what it does Sets up the hardware. Transfers control to the Boot Loader. BIOS xv6 Boot loader what it does Sets up the hardware. Transfers control to the Boot Loader. how it transfers control to the Boot Loader Boot loader is loaded from the 1st 512-byte sector of the boot disk. This 512-byte sector is known as the boot sector. Boot loader is loaded at 0x7c00. Sets processor’s ip register to 0x7c00. BIOS xv6 Boot loader 2 source source files bootasm.S - 16 and 32 bit assembly code. bootmain.c - C code. BIOS xv6 Boot loader 2 source source files bootasm.S - 16 and 32 bit assembly code. bootmain.c - C code. executing bootasm.S 1. Disable interrupts using cli instruction. (Code). > Done in case BIOS has initialized any of its interrupt handlers while setting up the hardware. Also, BIOS is not running anymore, so better to disable them. > Clear segment registers. Use xor for %ax, and copy it to the rest (Code). 2. Switch from real mode to protected mode. (References: a, b). > Note the difference between processor modes and kernel privilege modes > We do the above switch to increase the size of the memory we can address. BIOS xv6 Boot loader 2 source source file executing bootasm.S m. Let’s 2. Switch from real mode to protected mode. expand on this a little bit Addressing in Real Mode In real mode, the processor sends 20-bit addresses to the memory.
    [Show full text]
  • DOS Virtualized in the Linux Kernel
    DOS Virtualized in the Linux Kernel Robert T. Johnson, III Abstract Due to the heavy dominance of Microsoft Windows® in the desktop market, some members of the software industry believe that new operating systems must be able to run Windows® applications to compete in the marketplace. However, running applications not native to the operating system generally causes their performance to degrade significantly. When the application and the operating system were written to run on the same machine architecture, all of the instructions in the application can still be directly executed under the new operating system. Some will only need to be interpreted differently to provide the required functionality. This paper investigates the feasibility and potential to speed up the performance of such applications by including the support needed to run them directly in the kernel. In order to avoid the impact to the kernel when these applications are not running, the needed support was built as a loadable kernel module. 1 Introduction New operating systems face significant challenges in gaining consumer acceptance in the desktop marketplace. One of the first realizations that must be made is that the majority of this market consists of non-technical users who are unlikely to either understand or have the desire to understand various technical details about why the new operating system is “better” than a competitor’s. This means that such details are extremely unlikely to sway a large amount of users towards the operating system by themselves. The incentive for a consumer to continue using their existing operating system or only upgrade to one that is backwards compatible is also very strong due to the importance of application software.
    [Show full text]
  • Overview of the MIPS Architecture: Part I
    Overview of the MIPS Architecture: Part I CS 161: Lecture 0 1/24/17 Looking Behind the Curtain of Software • The OS sits between hardware and user-level software, providing: • Isolation (e.g., to give each process a separate memory region) • Fairness (e.g., via CPU scheduling) • Higher-level abstractions for low-level resources like IO devices • To really understand how software works, you have to understand how the hardware works! • Despite OS abstractions, low-level hardware behavior is often still visible to user-level applications • Ex: Disk thrashing Processors: From the View of a Terrible Programmer Letter “m” Drawing of bird ANSWERS Source code Compilation add t0, t1, t2 lw t3, 16(t0) slt t0, t1, 0x6eb21 Machine instructions A HARDWARE MAGIC OCCURS Processors: From the View of a Mediocre Programmer • Program instructions live Registers in RAM • PC register points to the memory address of the instruction to fetch and execute next • Arithmetic logic unit (ALU) performs operations on PC registers, writes new RAM values to registers or Instruction memory, generates ALU to execute outputs which determine whether to branches should be taken • Some instructions cause Devices devices to perform actions Processors: From the View of a Mediocre Programmer • Registers versus RAM Registers • Registers are orders of magnitude faster for ALU to access (0.3ns versus 120ns) • RAM is orders of magnitude larger (a PC few dozen 32-bit or RAM 64-bit registers versus Instruction GBs of RAM) ALU to execute Devices Instruction Set Architectures (ISAs)
    [Show full text]
  • Protected Mode - Wikipedia
    2/12/2019 Protected mode - Wikipedia Protected mode In computing, protected mode, also called protected virtual address mode,[1] is an operational mode of x86- compatible central processing units (CPUs). It allows system software to use features such as virtual memory, paging and safe multi-tasking designed to increase an operating system's control over application software.[2][3] When a processor that supports x86 protected mode is powered on, it begins executing instructions in real mode, in order to maintain backward compatibility with earlier x86 processors.[4] Protected mode may only be entered after the system software sets up one descriptor table and enables the Protection Enable (PE) bit in the control register 0 (CR0).[5] Protected mode was first added to the x86 architecture in 1982,[6] with the release of Intel's 80286 (286) processor, and later extended with the release of the 80386 (386) in 1985.[7] Due to the enhancements added by protected mode, it has become widely adopted and has become the foundation for all subsequent enhancements to the x86 architecture,[8] although many of those enhancements, such as added instructions and new registers, also brought benefits to the real mode. Contents History The 286 The 386 386 additions to protected mode Entering and exiting protected mode Features Privilege levels Real mode application compatibility Virtual 8086 mode Segment addressing Protected mode 286 386 Structure of segment descriptor entry Paging Multitasking Operating systems See also References External links History https://en.wikipedia.org/wiki/Protected_mode
    [Show full text]