DOCSLIB.ORG

Virtual Memory in Contemporary Microprocessors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Virtual Memory in Contemporary Microprocessors VIRTUAL MEMORY IN CONTEMPORARY MICROPROCESSORS THIS SURVEY OF SIX COMMERCIAL MEMORY-MANAGEMENT DESIGNS DESCRIBES HOW EACH PROCESSOR ARCHITECTURE SUPPORTS THE COMMON FEATURES OF VIRTUAL MEMORY: ADDRESS SPACE PROTECTION, SHARED MEMORY, AND LARGE ADDRESS SPACES. Virtual memory is a technique for from the most popular commercial microar- managing the resource of physical memory. It chitectures: the MIPS R10000, Alpha 21164, gives an application the illusion of a very large PowerPC 604, PA-8000, UltraSPARC-I, and amount of memory, typically much larger than Pentium II. Table 1 points out a few of their what is actually available. It protects the code similarities by comparing their support for and data of user-level applications from the some core virtual-memory functions. actions of other programs but also allows pro- grams to share portions of their address spaces Memory management if desired. It supports the execution of process- The classic MMU, as in the DEC VAX, GE es partially resident in memory. Only the most 645, and Intel Pentium architectures,2-4 recently used portions of a process’s address includes a translation look-aside buffer that Bruce Jacob space actually occupy physical memory—the translates addresses and a finite-state machine rest of the address space is stored on disk until that walks the page table. The TLB is an on- University of Maryland needed. For a primer on virtual memory, see chip memory structure that caches only page our companion article in Computer magazine.1 table entries (PTEs). If the necessary transla- Most contemporary general-purpose proces- tion information is in the TLB, the system can Trevor Mudge sors support virtual memory through a hard- translate a virtual address to a physical address ware memory management unit (MMU) that without accessing the page table. If the trans- University of Michigan translates virtual addresses to physical address- lation information is not found in the TLB es. Unfortunately, the various microarchitec- (called a TLB miss), one must search the page tures define the virtual-memory interface table for the mapping and insert it into the TLB differently, and, as explained in the next sec- before processing can continue. In early designs tion, this is becoming a significant problem. a hardware state machine performed this activ- Here, we consider the memory management ity; on a TLB miss, the state machine walked designs of a sampling of six recent processors, the page table, loaded the mapping, refilled the focusing primarily on their architectural dif- TLB, and restarted the computation. ferences, and hint at optimizations that some- TLBs usually have on the order of 100 one designing or porting system software entries, are often fully associative, and are typ- might want to consider. We selected examples ically accessed every clock cycle. They trans- 60 0272-1732/98/$10.00 1998 IEEE Table 1. Comparison of architectural support for virtual memory in six commercial MMUs. Item MIPS Alpha PowerPC PA-RISC UltraSPARC IA-32 Address space ASIDs ASIDs Segmentation Multiple ASIDs ASIDs Segmentation protection Shared memory GLOBAL bit GLOBAL bit Segmentation Multiple ASIDs; Indirect Segmentation in TLB entry in TLB entry segmentation specification of ASIDs Large address 64-bit 64-bit 52-/80-bit 96-bit 64-bit None spaces addressing addressing segmented segmented addressing addressing addressing Fine-grained In TLB entry In TLB entry In TLB entry In TLB entry In TLB entry In TLB entry; protection per segment Page table Software- Software- Hardware- Software- Software- Hardware- support managed managed managed managed managed managed TLB TLB TLB; inverted TLB TLB TLB/hierarchical page table page table Superpages Variable page Groupings of Block address Variable page Variable page Segmentation/ size set in TLB 8, 64, 512 translation: size set in TLB size set in variable page entry: 4 Kbyte pages (set 128 Kbytes entry:4 Kbytes TLB entry: size set in TLB to 16 Mbyte, by 4 in TLB entry) to 256 Mbytes, to 64 Mbytes, 8, 64, 512 entry: 4 Kbytes by 2 by 4 Kbytes, and or 4 Mbytes 4 Mbytes late both instruction and data stream address- primary disadvantage of the state machine is es. They can constrain the chip’s clock cycle that the page table organization is effectively as they tend to be fairly slow, and they are also etched in stone; the operating system (OS) has power-hungry—both are a consequence of little flexibility in tailoring a design. the TLB’s high degree of associativity. Today’s In response, recent memory management systems require both high clock speeds and designs have used a software-managed TLB, in low power; in response, two-way and four- which the OS handles TLB misses. MIPS was way set-associative TLB designs are popular, one of the earliest commercial architectures to as lower degrees of associativity have far less offer a software-managed TLB,5 though the impact on clock speed and power consump- Astronautics Corporation of America holds a tion than fully associative designs. To provide patent for a software-managed design.6 In a increased translation bandwidth, designers software-managed TLB miss, the hardware often use split TLB designs. interrupts the OS and vectors to a software rou- The state machine is an efficient design as tine that walks the page table. The OS thus it disturbs the processor pipeline only slightly. defines the page table organization, since hard- During a TLB miss, the instruction pipeline ware never directly manages the table. effectively freezes: in contrast to taking an The flexibility of the software-managed exception, the pipeline is not disturbed, and mechanism comes at a performance cost. The the reorder buffer need not be flushed. The TLB miss handler that walks the page table is instruction cache is not used, and the data an OS primitive usually 10 to 100 instruc- cache is used only if the page table is located in tions long. If the handler code is not in the cacheable space. At the worst, the execution of instruction cache at the time of the TLB miss, the state machine will replace a few lines in the the time to handle the miss can be much data cache. Many designs do not even freeze longer than in the hardware-walked scheme. the pipeline; for instance, the Intel Pentium In addition, the use of the interrupt mecha- Pro allows instructions that are independent nism adds a number of cycles to the cost by of the faulting instruction to continue pro- flushing the pipeline—possibly flushing a cessing while the TLB miss is serviced. The large number of instructions from the reorder JULY–AUGUST 1998 61 VIRTUAL MEMORY 64-bit virtual address concentrate on those mecha- Region (Sign-extended) 32-bit virtual page number 12-bit page offset nisms that are unique to each architecture. 8-bit ASID Cache index MIPS MIPS (Figure 1) defines Eight-entry one of the simplest memory instruction TLB, 32-Kbyte, 64-paired-entry, management architectures two-way set-associative among recent microproces- fully associative instruction or data cache main TLB sors. The OS handles TLB misses entirely in software: Tag the software fills in the TLB, 28-bit page frame number compare and the OS defines the TLB (cache hit/miss) Tag: page frame number replacement policy. Address space Cache data The R2000/R3000 virtual address is 32 bits wide; the Figure 1. MIPS R10000 address translation mechanism. The split instruction and data R10000 virtual address is 64 caches are virtually indexed, both requiring an index larger than the page offset. The TLB bits wide, though not all 64 lookup proceeds in parallel with the cache lookup. The earliest MIPS designs had physically bits are translated in the indexed caches, and if the cache was larger than the page size, the cache was accessed in R10000. The top “region” series with the TLB. ASID: address space identifier. bits divide the virtual space into areas of different behav- ior. The top two bits distin- buffer. This can add hundreds of cycles to the guish between user, supervisor, and kernel overhead of walking the page table. Nonethe- spaces (the R10000 offers three levels of exe- less, the flexibility afforded by the software- cution/access privileges). Further bits divide managed scheme can outweigh the potentially the kernel and supervisor regions into areas of higher per-miss cost of the design.7 different memory behavior (that is, cached/ Given the few details presented so far, one uncached, mapped/unmapped). can easily see that the use of different virtual- In the R2000/R3000, the top bit divides memory interface definitions in every the 4-Gbyte address space into user and ker- microarchitecture is becoming a significant nel regions, and the next two bits further problem. More often than not, the OS run- divide the kernel’s space into cached/uncached ning on a microprocessor was not initially and mapped/unmapped regions. In both designed for that processor: OSs often outlast architectures, virtual addresses are extended the hardware on which they were designed with an address space identifier (ASID) to dis- and built, and the more popular OSs are port- tinguish between contexts. The 6-bit-wide ed to many different architectures. Hardware ASID on the R2000/R3000 uniquely identi- abstraction layers (for example, see Rashid et fies 64 processes; the 8-bit-wide ASID on the al.8 and Custer9) hide hardware particulars R10000 uniquely identifies 256. from most of the OS, and they can prevent Since it is simpler, we describe the 32-bit system designers from fully optimizing their address space of the R2000/R3000. User space, software. These types of mismatches between called kuseg, occupies the bottom 2 Gbytes of OSs and microarchitectures cause significant the address space.
Load more

Recommended publications
  • Chapter 8 Instruction Set
    Chapter 8 Instruction Set 80 80 This chapter lists the PowerPC instruction set in alphabetical order by mnemonic. Note that each entry includes the instruction formats and a quick reference ‘legend’ that provides such information as the level(s) of the PowerPC architecture in which the instruction may be found—user instruction set architecture (UISA), virtual environment architecture U (VEA), and operating environment architecture (OEA); and the privilege level of the V instruction—user- or supervisor-level (an instruction is assumed to be user-level unless the O legend specifies that it is supervisor-level); and the instruction formats. The format diagrams show, horizontally, all valid combinations of instruction fields; for a graphical representation of these instruction formats, see Appendix A, “PowerPC Instruction Set Listings.” The legend also indicates if the instruction is 64-bit, , 64-bit bridge, and/or optional. A description of the instruction fields and pseudocode conventions are also provided. For more information on the PowerPC instruction set, refer to Chapter 4, “Addressing Modes and Instruction Set Summary.” Note that the architecture specification refers to user-level and supervisor-level as problem state and privileged state, respectively. 8.1 Instruction Formats Instructions are four bytes long and word-aligned, so when instruction addresses are U presented to the processor (as in branch instructions) the two low-order bits are ignored. Similarly, whenever the processor develops an instruction address, its two low-order bits are zero. Bits 0–5 always specify the primary opcode. Many instructions also have an extended opcode. The remaining bits of the instruction contain one or more fields for the different instruction formats.
    [Show full text]
  • Virtual Memory
    Chapter 4 Virtual Memory Linux processes execute in a virtual environment that makes it appear as if each process had the entire address space of the CPU available to itself. This virtual address space extends from address 0 all the way to the maximum address. On a 32-bit platform, such as IA-32, the maximum address is 232 − 1or0xffffffff. On a 64-bit platform, such as IA-64, this is 264 − 1or0xffffffffffffffff. While it is obviously convenient for a process to be able to access such a huge ad- dress space, there are really three distinct, but equally important, reasons for using virtual memory. 1. Resource virtualization. On a system with virtual memory, a process does not have to concern itself with the details of how much physical memory is available or which physical memory locations are already in use by some other process. In other words, virtual memory takes a limited physical resource (physical memory) and turns it into an infinite, or at least an abundant, resource (virtual memory). 2. Information isolation. Because each process runs in its own address space, it is not possible for one process to read data that belongs to another process. This improves security because it reduces the risk of one process being able to spy on another pro- cess and, e.g., steal a password. 3. Fault isolation. Processes with their own virtual address spaces cannot overwrite each other’s memory. This greatly reduces the risk of a failure in one process trig- gering a failure in another process. That is, when a process crashes, the problem is generally limited to that process alone and does not cause the entire machine to go down.
    [Show full text]
  • Mipspro C++ Programmer's Guide
    MIPSproTM C++ Programmer’s Guide 007–0704–150 CONTRIBUTORS Rewritten in 2002 by Jean Wilson with engineering support from John Wilkinson and editing support from Susan Wilkening. COPYRIGHT Copyright © 1995, 1999, 2002 - 2003 Silicon Graphics, Inc. All rights reserved; provided portions may be copyright in third parties, as indicated elsewhere herein. No permission is granted to copy, distribute, or create derivative works from the contents of this electronic documentation in any manner, in whole or in part, without the prior written permission of Silicon Graphics, Inc. LIMITED RIGHTS LEGEND The electronic (software) version of this document was developed at private expense; if acquired under an agreement with the USA government or any contractor thereto, it is acquired as "commercial computer software" subject to the provisions of its applicable license agreement, as specified in (a) 48 CFR 12.212 of the FAR; or, if acquired for Department of Defense units, (b) 48 CFR 227-7202 of the DoD FAR Supplement; or sections succeeding thereto. Contractor/manufacturer is Silicon Graphics, Inc., 1600 Amphitheatre Pkwy 2E, Mountain View, CA 94043-1351. TRADEMARKS AND ATTRIBUTIONS Silicon Graphics, SGI, the SGI logo, IRIX, O2, Octane, and Origin are registered trademarks and OpenMP and ProDev are trademarks of Silicon Graphics, Inc. in the United States and/or other countries worldwide. MIPS, MIPS I, MIPS II, MIPS III, MIPS IV, R2000, R3000, R4000, R4400, R4600, R5000, and R8000 are registered or unregistered trademarks and MIPSpro, R10000, R12000, R1400 are trademarks of MIPS Technologies, Inc., used under license by Silicon Graphics, Inc. Portions of this publication may have been derived from the OpenMP Language Application Program Interface Specification.
    [Show full text]
  • Book E: Enhanced Powerpc™ Architecture
    Book E: Enhanced PowerPC Architecture Version 1.0 May 7, 2002 Third Edition (Dec 2001) The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. IBM does not warrant that the use of the information herein shall be free from third party intellectual property claims. IBM does not warrant that the contents of this document will meet your requirements or that the document is error-free. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the document. IBM may make improvements and or changes in the product(s) and/or program(s) described in this document at any time. This document does not imply a commitment by IBM to supply or make generally available the product(s) described herein. No part of this document may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the written permission of IBM. Address comments about this document to: IBM Corporation Department B5H / Building 667 3039 Cornwallis Road P.O. Box 12195 Research Triangle Park, NC 27709 Portions of the information in this document may have been published previously in the following related documents: The PowerPC Architecture: A Specification for a New Family of RISC Processors, Second Edition (1994) The IBM PowerPC Embedded Environment: Architectural Specifications for IBM PowerPC Embedded Controllers, Second Edition (1998) IBM may have patents or pending patent applications covering the subject matter in this document.
    [Show full text]
  • The Case for Compressed Caching in Virtual Memory Systems
    THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the USENIX Annual Technical Conference Monterey, California, USA, June 6-11, 1999 The Case for Compressed Caching in Virtual Memory Systems _ Paul R. Wilson, Scott F. Kaplan, and Yannis Smaragdakis aUniversity of Texas at Austin © 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org The Case for Compressed Caching in Virtual Memory Systems Paul R. Wilson, Scott F. Kaplan, and Yannis Smaragdakis Dept. of Computer Sciences University of Texas at Austin Austin, Texas 78751-1182 g fwilson|sfkaplan|smaragd @cs.utexas.edu http://www.cs.utexas.edu/users/oops/ Abstract In [Wil90, Wil91b] we proposed compressed caching for virtual memory—storing pages in compressed form Compressed caching uses part of the available RAM to in a main memory compression cache to reduce disk pag- hold pages in compressed form, effectively adding a new ing. Appel also promoted this idea [AL91], and it was level to the virtual memory hierarchy. This level attempts evaluated empirically by Douglis [Dou93] and by Russi- to bridge the huge performance gap between normal (un- novich and Cogswell [RC96]. Unfortunately Douglis’s compressed) RAM and disk.
    [Show full text]
  • Memory Protection at Option
    Memory Protection at Option Application-Tailored Memory Safety in Safety-Critical Embedded Systems – Speicherschutz nach Wahl Auf die Anwendung zugeschnittene Speichersicherheit in sicherheitskritischen eingebetteten Systemen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades Doktor-Ingenieur vorgelegt von Michael Stilkerich Erlangen — 2012 Als Dissertation genehmigt von der Technischen Fakultät Universität Erlangen-Nürnberg Tag der Einreichung: 09.07.2012 Tag der Promotion: 30.11.2012 Dekan: Prof. Dr.-Ing. Marion Merklein Berichterstatter: Prof. Dr.-Ing. Wolfgang Schröder-Preikschat Prof. Dr. Michael Philippsen Abstract With the increasing capabilities and resources available on microcontrollers, there is a trend in the embedded industry to integrate multiple software functions on a single system to save cost, size, weight, and power. The integration raises new requirements, thereunder the need for spatial isolation, which is commonly established by using a memory protection unit (MPU) that can constrain access to the physical address space to a fixed set of address regions. MPU-based protection is limited in terms of available hardware, flexibility, granularity and ease of use. Software-based memory protection can provide an alternative or complement MPU-based protection, but has found little attention in the embedded domain. In this thesis, I evaluate qualitative and quantitative advantages and limitations of MPU-based memory protection and software-based protection based on a multi-JVM. I developed a framework composed of the AUTOSAR OS-like operating system CiAO and KESO, a Java implementation for deeply embedded systems. The framework allows choosing from no memory protection, MPU-based protection, software-based protection, and a combination of the two.
    [Show full text]
  • Using the GNU Compiler Collection (GCC)
    Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection by Richard M. Stallman and the GCC Developer Community Last updated 23 May 2004 for GCC 3.4.6 For GCC Version 3.4.6 Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 59 Temple Place Suite 330 Tel 617-542-5942 Boston, MA 02111-1307 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. 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 \GNU General Public License" and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ...................................... 1 1 Programming Languages Supported by GCC ............ 3 2 Language Standards Supported by GCC ............... 5 3 GCC Command Options .........................
    [Show full text]
  • Microprocessors History of Computing Nouf Assaid
    MICROPROCESSORS HISTORY OF COMPUTING NOUF ASSAID 1 Table of Contents Introduction 2 Brief History 2 Microprocessors 7 Instruction Set Architectures 8 Von Neumann Machine 9 Microprocessor Design 12 Superscalar 13 RISC 16 CISC 20 VLIW 23 Multiprocessor 24 Future Trends in Microprocessor Design 25 2 Introduction If we take a look around us, we would be sure to find a device that uses a microprocessor in some form or the other. Microprocessors have become a part of our daily lives and it would be difficult to imagine life without them today. From digital wrist watches, to pocket calculators, from microwaves, to cars, toys, security systems, navigation, to credit cards, microprocessors are ubiquitous. All this has been made possible by remarkable developments in semiconductor technology enabling in the last 30 years, enabling the implementation of ideas that were previously beyond the average computer architect’s grasp. In this paper, we discuss the various microprocessor technologies, starting with a brief history of computing. This is followed by an in-depth look at processor architecture, design philosophies, current design trends, RISC processors and CISC processors. Finally we discuss trends and directions in microprocessor design. Brief Historical Overview Mechanical Computers A French engineer by the name of Blaise Pascal built the first working mechanical computer. This device was made completely from gears and was operated using hand cranks. This machine was capable of simple addition and subtraction, but a few years later, a German mathematician by the name of Leibniz made a similar machine that could multiply and divide as well. After about 150 years, a mathematician at Cambridge, Charles Babbage made his Difference Engine.
    [Show full text]
  • Computer Organization and Architecture Designing for Performance Ninth Edition
    COMPUTER ORGANIZATION AND ARCHITECTURE DESIGNING FOR PERFORMANCE NINTH EDITION William Stallings Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Editorial Director: Marcia Horton Designer: Bruce Kenselaar Executive Editor: Tracy Dunkelberger Manager, Visual Research: Karen Sanatar Associate Editor: Carole Snyder Manager, Rights and Permissions: Mike Joyce Director of Marketing: Patrice Jones Text Permission Coordinator: Jen Roach Marketing Manager: Yez Alayan Cover Art: Charles Bowman/Robert Harding Marketing Coordinator: Kathryn Ferranti Lead Media Project Manager: Daniel Sandin Marketing Assistant: Emma Snider Full-Service Project Management: Shiny Rajesh/ Director of Production: Vince O’Brien Integra Software Services Pvt. Ltd. Managing Editor: Jeff Holcomb Composition: Integra Software Services Pvt. Ltd. Production Project Manager: Kayla Smith-Tarbox Printer/Binder: Edward Brothers Production Editor: Pat Brown Cover Printer: Lehigh-Phoenix Color/Hagerstown Manufacturing Buyer: Pat Brown Text Font: Times Ten-Roman Creative Director: Jayne Conte Credits: Figure 2.14: reprinted with permission from The Computer Language Company, Inc. Figure 17.10: Buyya, Rajkumar, High-Performance Cluster Computing: Architectures and Systems, Vol I, 1st edition, ©1999. Reprinted and Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey, Figure 17.11: Reprinted with permission from Ethernet Alliance. Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on the appropriate page within text. Copyright © 2013, 2010, 2006 by Pearson Education, Inc., publishing as Prentice Hall. All rights reserved. Manufactured in the United States of America.
    [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]
  • A Minimal Powerpc™ Boot Sequence for Executing Compiled C Programs
    Order Number: AN1809/D Rev. 0, 3/2000 Semiconductor Products Sector Application Note A Minimal PowerPCª Boot Sequence for Executing Compiled C Programs PowerPC Systems Architecture & Performance [email protected] This document describes the procedures necessary to successfully initialize a PowerPC processor and begin executing programs compiled using the PowerPC embedded application interface (EABI). The items discussed in this document have been tested for MPC603eª, MPC750, and MPC7400 microprocessors. The methods and source code presented in this document may work unmodiÞed on similar PowerPC platforms as well. This document contains the following topics: ¥ Part I, ÒOverview,Ó provides an overview of the conditions and exceptions for the procedures described in this document. ¥ Part II, ÒPowerPC Processor Initialization,Ó provides information on the general setup of the processor registers, caches, and MMU. ¥ Part III, ÒPowerPC EABI Compliance,Ó discusses aspects of the EABI that apply directly to preparing to jump into a compiled C program. ¥ Part IV, ÒSample Boot Sequence,Ó describes the basic operation of the boot sequence and the many options of conÞguration, explains in detail a sample conÞgurable boot and how the code may be modiÞed for use in different environments, and discusses the compilation procedure using the supporting GNU build environment. ¥ Part V, ÒSource Files,Ó contains the complete source code for the Þles ppcinit.S, ppcinit.h, reg_defs.h, ld.script, and MakeÞle. This document contains information on a new product under development by Motorola. Motorola reserves the right to change or discontinue this product without notice. © Motorola, Inc., 2000. All rights reserved. Overview Part I Overview The procedures discussed in this document perform only the minimum amount of work necessary to execute a user program.
    [Show full text]
  • Intermediate X86 Part 2
    Intermediate x86 Part 2 Xeno Kovah – 2010 xkovah at gmail All materials are licensed under a Creative Commons “Share Alike” license. • http://creativecommons.org/licenses/by-sa/3.0/ 2 Paging • Previously we discussed how segmentation translates a logical address (segment selector + offset) into a 32 bit linear address. • When paging is disabled, linear addresses map 1:1 to physical addresses. • When paging is enabled, a linear address must be translated to determine the physical address it corresponds to. • It’s called “paging” because physical memory is divided into fixed size chunks called pages. • The analogy is to books in a library. When you need to find some information first you go to the library where you look up the relevant book, then you select the book and look up a specific page, from there you maybe look for a specific specific sentence …or “word”? ;) • The internets ruined the analogy! 3 Notes and Terminology • All of the figures or references to the manual in this section refer to the Nov 2008 manual (available in the class materials). This is because I think the manuals <= 2008 organized and presented much clearer than >= 2009 manuals. • When I refer to a “frame” it means “a page- sized chunk of physical memory” • When paging is enabled, a “linear address” is the same thing as a “virtual memory ” “ ” address or virtual address 4 The terrifying truth revealed! And now you knowAHHHHHHHH!!!…the rest of the story.(Nah, Good it’s not so bad day. :)) 5 Virtual Memory • When paging is enabled, the 32 bit linear address space can be mapped to a physical address space less than 32 bits.
    [Show full text]