DOCSLIB.ORG

IA-32 Intel® Architecture and Intel® Extended Memory 64 Technology

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
IA-32 Intel® Architecture and Intel® Extended Memory 64 Technology Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes August 2008 Notice: The Intel® 64 and IA-32 architectures may contain design defects or errors known as errata that may cause the product to deviate from published specifications. Current characterized errata are documented in the specification updates. Document Number: 252046-022 INFORMATIONLegal Lines and Disclaimers IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. 64-bit computing on Intel architecture requires a computer system with a processor, chipset, BIOS, operating system, device drivers and applications enabled for Intel® 64 architecture. Performance will vary depending on your hardware and software configurations. Consult with your system vendor for more information. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. I2C is a two-wire communications bus/protocol developed by Philips. SMBus is a subset of the I2C bus/protocol and was developed by Intel. Implementations of the I2C bus/protocol may require licenses from various entities, including Philips Electronics N.V. and North American Philips Corporation. Intel, Pentium, Intel Core, Intel Xeon, Intel 64, Intel NetBurst, and the Intel logo, and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Copyright © 2002–2008, Intel Corporation. All rights reserved.. 2Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes Contents Revision History . 4 Preface . 5 Summary Tables of Changes . 6 Documentation Changes. 7 Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes 3 Revision History Revision History Revision Description Date -001 • Initial release November 2002 • Added 1-10 Documentation Changes. -002 • Removed old Documentation Changes items that already have been December 2002 incorporated in the published Software Developer’s manual • Added 9 -17 Documentation Changes. • Removed Documentation Change #6 - References to bits Gen and Len -003 Deleted. February 2003 • Removed Documentation Change #4 - VIF Information Added to CLI Discussion • Removed Documentation changes 1-17. -004 June 2003 • Added Documentation changes 1-24. • Removed Documentation Changes 1-24. -005 September 2003 • Added Documentation Changes 1-15. -006 • Added Documentation Changes 16- 34. November 2003 • Updated Documentation changes 14, 16, 17, and 28. -007 January 2004 • Added Documentation Changes 35-45. • Removed Documentation Changes 1-45. -008 March 2004 • Added Documentation Changes 1-5. -009 • Added Documentation Changes 7-27. May 2004 • Removed Documentation Changes 1-27. -010 August 2004 • Added Documentation Changes 1. -011 • Added Documentation Changes 2-28. November 2004 • Removed Documentation Changes 1-28. -012 March 2005 • Added Documentation Changes 1-16. • Updated title. -013 • There are no Documentation Changes for this revision of the July 2005 document. -014 • Added Documentation Changes 1-21. September 2005 • Removed Documentation Changes 1-21. -015 March 9, 2006 • Added Documentation Changes 1-20. -016 • Added Documentation changes 21-23. March 27, 2006 • Removed Documentation Changes 1-23. -017 September 2006 • Added Documentation Changes 1-36. -018 • Added Documentation Changes 37-42. October 2006 • Removed Documentation Changes 1-42. -019 March 2007 • Added Documentation Changes 1-19. -020 • Added Documentation Changes 20-27. May 2007 • Removed Documentation Changes 1-27. -021 November 2007 • Added Documentation Changes 1-6 • Removed Documentation Changes 1-6 -022 August 2008 • Added Documentation Changes 1-6 4Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes Preface Preface This document is an update to the specifications contained in the Affected Documents table below. This document is a compilation of device and documentation errata, specification clarifications and changes. It is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. Affected Documents Document Document Title Number/Location Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic 253665 Architecture Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A: 253666 Instruction Set Reference, A-M Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B: 253667 Instruction Set Reference, N-Z Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: 253668 System Programming Guide. Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B: 253669 System Programming Guide Nomenclature Documentation Changes include typos, errors, or omissions from the current published specifications. These will be incorporated in any new release of the specification. Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes 5 Summary Tables of Changes Summary Tables of Changes The following table indicates documentation changes which apply to the Intel® 64 and IA-32 architectures. This table uses the following notations: Codes Used in Summary Tables Change bar to left of table row indicates this erratum is either new or modified from the previous version of the document. Documentation Changes No. DOCUMENTATION CHANGES 1 Extended Control Registers (Chapter 2, Vol 3A) 2 Various Updates Throughout Chapter to Reference MAXPHYADDR as an Address Width (Chapter 3, Vol 3A) 3 Page-Level Protection and Execute-Disable Bit (Chapter 4, Vol 3A) 4 Machine-Check Exceptions (Chapter 5, Vol 3A) 5 Various Updates Throughout Chapter (Chapter 7, Vol 3A) 6 Preventing Caching (Chapter 10, Vol 3A) 6Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes Documentation Changes Documentation Changes 1. Extended Control Registers (Chapter 2, Vol 3A) Change bars show changes to Chapter 2 of the Intel® 64 and IA-32 Architectures Soft- ware Developer’s Manual, Volume 3A: System Programming Guide. 2.6 Extended Control Registers (including the XFEATURE_ENABLED_MASK Register) If CPUID.01H:ECX.XSAVE[bit 26] is 1, the processor supports one or more extended control registers (XCRs). Currently, the only such register defined is XCR0, the XFEATURE_ENABLED_MASK register. This register specifies the set of processor states that the operating system enables on that processor, e.g. x87 FPU States, SSE states, and other processor extended states that Intel 64 architecture may introduce in the future. The OS programs XCR0 to reflect the features it supports. 63 2 1 0 1 Reserved for XCR0 bit vector expansion Reserved / Future processor extended states SSE state x87 FPU/MMX state (must be 1) Reserved (must be 0) Figure 2-7. XFEATURE_ENABLED_MASK Register (XCR0) Software can access XCR0 only if CR4.OSXSAVE[bit 18] = 1. (This bit is also readable as CPUID.01H:ECX.OSXSAVE[bit 27].) The layout of XCR0 is architected to allow software to use CPUID leaf function 0DH to enumerate the set of bits that the processor supports in XCR0 (see CPUID instruction in Intel® 64 and IA-32 Architectures Software Devel- oper’s Manual, Volume 2A). Each processor state (X87 FPU state, SSE state, or a future processor extended state) is represented by a bit in XCR0. The OS can enable future processor extended states in a forward manner by specifying the appropriate bit mask value using the XSETBV instruction according to the results of the CPUID leaf 0DH. With the exception of bit 63, each bit in the XFEATURE_ENABLED_MASK register (XCR0) corresponds to a subset of the processor states. XCR0 thus provides space for up to 63 Intel® 64 and IA-32 Architectures Software Developer’s Manual Documentation Changes 7 Documentation Changes sets of processor state extensions. Bit 63 of XCR0 is reserved for future expansion and will not represent a processor extended state. Currently, the XFEATURE_ENABLED_MASK register (XCR0) has two processor states defined, with up to 61 bits reserved for future processor extended states: • XCR0.X87 (bit 0): If 1, indicates x87 FPU state (including MMX register states) is supported in the processor. Bit 0 must be 1. An attempt to write 0 causes a #GP exception. • XCR0.SSE (bit 1): If 1, indicates MXCSR and XMM registers (XMM0-XMM15 in 64-bit mode, otherwise XMM0-XMM7) are supported by XSAVE/XRESTOR in the processor. Any attempt to set a reserved bit (as determined by the contents of EAX and EDX after executing CPUID with EAX=0DH,
Load more

Recommended publications
  • 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]
  • 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]
  • Chapter 3 Protected-Mode Memory Management
    CHAPTER 3 PROTECTED-MODE MEMORY MANAGEMENT This chapter describes the Intel 64 and IA-32 architecture’s protected-mode memory management facilities, including the physical memory requirements, segmentation mechanism, and paging mechanism. See also: Chapter 5, “Protection” (for a description of the processor’s protection mechanism) and Chapter 20, “8086 Emulation” (for a description of memory addressing protection in real-address and virtual-8086 modes). 3.1 MEMORY MANAGEMENT OVERVIEW The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging. Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mech- anism for implementing a conventional demand-paged, virtual-memory system where sections of a program’s execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional. These two mechanisms (segmentation and paging) can be configured to support simple single-program (or single- task) systems, multitasking systems, or multiple-processor systems that used shared memory. As shown in Figure 3-1, segmentation provides a mechanism for dividing the processor’s addressable memory space (called the linear address space) into smaller protected address spaces called segments. Segments can be used to hold the code, data, and stack for a program or to hold system data structures (such as a TSS or LDT).
    [Show full text]
  • IA-32 Intel Architecture Software Developer's
    IA-32 Intel Architecture Software Developer’s Manual Volume 3: System Programming Guide NOTE: The IA-32 Intel Architecture Developer’s Manual consists of three books: Basic Architecture, Order Number 245470; Instruction Set Reference Manual, Order Number 245471; and the System Programming Guide, Order Number 245472. Please refer to all three volumes when evaluating your design needs. 2001 Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. Except as provided in Intel’s Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. Intel’s IA-32 Intel® Architecture processors (e.g., Pentium® 4 and Pentium® III processors) may contain design defects or errors known as errata. Current characterized errata are available on request. Intel®, Intel386™, Intel486™, Pentium®, Intel® NetBurst™, MMX™, and Itanium™ are trademarks owned by Intel Corporation.
    [Show full text]
  • Intel® Architecture Instruction Set Extensions and Future Features
    Intel® Architecture Instruction Set Extensions and Future Features Programming Reference May 2021 319433-044 Intel technologies may require enabled hardware, software or service activation. No product or component can be absolutely secure. Your costs and results may vary. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. All product plans and roadmaps are subject to change without notice. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. Code names are used by Intel to identify products, technologies, or services that are in development and not publicly available. These are not “commercial” names and not intended to function as trademarks. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be ob- tained by calling 1-800-548-4725, or by visiting http://www.intel.com/design/literature.htm. Copyright © 2021, Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries.
    [Show full text]
  • Chapter 19: Translation Lookaside Buffer (Tlb)
    TCSS 422 A – Spring 2018 5/21/2018 Institute of Technology TCSS 422: OPERATING SYSTEMS OBJECTIVES Assignment 3 – Page Table Walker Three Easy Pieces: Review Quiz #5 –Memory Virtualization Translation Lookaside Buffer, Paging – Smaller Tables Memory Virtualization Wrap-up: Translation Lookaside Buffer – Ch. 19 Paging – Smaller Tables – Ch. 20 Wes J. Lloyd Beyond Physical Memory – Ch. 21/22 Institute of Technology University of Washington - Tacoma TCSS422: Operating Systems [Spring 2018] TCSS422: Operating Systems [Spring 2018] May 21, 2018 May 21, 2018 L14.2 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma FEEDBACK – 5/16 How to determine whether a cache lookup is a hit or a miss? For example: for a TLB lookup? CHAPTER 19: How do you get a miss or a hit in a page table? TRANSLATION LOOKASIDE BUFFER (TLB) TCSS422: Operating Systems [Spring 2018] TCSS422: Operating Systems [Spring 2018] May 21, 2018 L14.3 May 21, 2018 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma L14.4 OBJECTIVES TLB EXAMPLE - 3 Chapter 19 .TLB Algorithm For the accesses: a[0], a[1], a[2], a[3], a[4], .TLB Tradeoffs a[5], a[6], a[7], a[8], a[9] How many are hits? .TLB Context Switch How many are misses? What is the hit rate? (%) . 70% (3 misses one for each VP, 7 hits) TCSS422: Operating Systems [Spring 2018] TCSS422: Operating Systems [Spring 2018] May 21, 2018 L14.5 May 21, 2018 L14.6 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma Slides by Wes J.
    [Show full text]
  • Extended Page Table (EPT) Published October 5, 2018 by Sinaei
    + ! " # Sina & Shahriar's Blog An aggressive out-of-order blog... Hypervisor From Scratch – Part 4: Address Translation Using $ 0 Extended Page Table (EPT) Published October 5, 2018 by Sinaei Hello guys! Welcome to the fourth part of the “Hypervisor From Scratch”. This part is primarily about translating guest address through Extended Page Table (EPT) and its implementation. We also see how shadow tables work and other cool stuf. First of all, make sure to read the earlier parts before reading this topic as these parts are really dependent on each other also you should have a basic understanding of paging mechanism and how page tables work. A good article is here for paging tables. Most of this topic derived from Chapter 28 – (VMX SUPPORT FOR ADDRESS TRANSLATION) available at Intel 64 and IA-32 architectures sofware developer’s manual combined volumes 3. The full source code of this tutorial is available on GitHub : [https://github.com/SinaKarvandi/Hypervisor-From-Scratch] Before starting, I should give my thanks to Petr Beneš, as this part would never be completed without his help. IntroductionIntroduction Second Level Address Translation (SLAT) or nested paging, is an extended layer in the paging mechanism that is used to map hardware-based virtualization virtual addresses into the physical memory. AMD implemented SLAT through the Rapid Virtualization Indexing (RVI) technology known as Nested Page Tables (NPT) since the introduction of its third- generation Opteron processors and microarchitecture code name Barcelona. Intel also implemented SLAT in Intel® VT-x technologies since the introduction of microarchitecture code name Nehalem and its known as Extended Page Table (EPT) and is used in Core i9, Core i7, Core i5, and Core i3 processors.
    [Show 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.
    [Show full text]
  • Intel Processor Identification and the CPUID Instruction
    E AP-485 APPLICATION NOTE Intel Processor Identification and the CPUID Instruction January 1999 Order Number : 241618-012 1/14/99 2:13 PM CPUID INTEL CONFIDENTIAL (until publication date) Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. Except as provided in Intel’s Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked “reserved” or “undefined.” Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. Intel’s Intel Architecture processors (e.g., Pentium® processor, Pentium processor with MMX™ technology, Pentium Pro processor, Pentium II processor, Pentium II Xeon™ processor, Intel Celeron™ processor, Pentium III processor and Pentium III Xeon processor) may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
    [Show full text]
  • Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2D: Instruction Set Reference
    Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2D: Instruction Set Reference NOTE: The Intel® 64 and IA-32 Architectures Software Developer's Manual consists of ten volumes: Basic Architecture, Order Number 253665; Instruction Set Reference A-L, Order Number 253666; Instruction Set Reference M-U, Order Number 253667; Instruction Set Reference V-Z, Order Number 326018; Instruction Set Reference, Order Number 334569; System Programming Guide, Part 1, Order Number 253668; System Programming Guide, Part 2, Order Number 253669; System Programming Guide, Part 3, Order Number 326019; System Programming Guide, Part 4, Order Number 332831; Model-Specific Registers, Order Number 335592. Refer to all ten volumes when evaluating your design needs. Order Number: 334569-075US June 2021 Intel technologies features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Learn more at intel.com, or from the OEM or retailer. No computer system can be absolutely secure. Intel does not assume any liability for lost or stolen data or systems or any damages resulting from such losses. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifica- tions.
    [Show full text]
  • Operating Systems Memory Management: Paging
    Operating Systems Memory Management: Paging By Paul Krzyzanowski October 20, 2010 [updated March 23, 2011] The advantage of a bad memory is that one enjoys several times the same good things for the first time. — Friedrich Nietzsche Introduction/Review This is a continuation of our discussion on memory management. A memory management unit that supports paging causes every logical address (virtual address) to be translated to a physical address (real address) by translating the logical page number of the address to a physical page frame number. The page number comprises the high bits of the address address. The low bits of the address form the offset within the page (or page frame). For example, with a 64-bit address, if a page size is 1 MB, then the lowest 20 bits (which address 1 MB) form the offset and the top 44 bits form the page number. Thanks to a memory management unit, every process can have its own address space. The same virtual address may reside in two different page frames for two different processes because each process has its own page table. The operating system is responsible for managing the page table for each process. During a context switch, the operating system has to inform the processor's memory management unit that it has to use a different page table. It does this by changing the page table base register, a register that contains the starting address of the page table. Each page table entry, in addition to storing the corresponding page frame, may also store a variety of flags that indicate if the page is valid (is there a corresponding page frame), how the page may be accessed (read-only, execute, kernel-mode only), and whether the page has been accessed or modified.
    [Show full text]
  • Introduction to Paging Wes J
    TCSS 422 A – Winter 2018 2/28/2018 Institute of Technology TCSS 422: OPERATING SYSTEMS OBJECTIVES Quiz 4 – Active Reading Chapter 19 Homework 2 Questions Paging, Homework 3 Questions Translation Lookaside Buffer, and Smaller Tables Ch. 18 . Introduction to Paging Wes J. Lloyd Ch. 19 . Translation Lookaside Buffer (TLB) Institute of Technology Ch. 20 University of Washington - Tacoma . Smaller Tables TCSS422: Operating Systems [Winter 2018] TCSS422: Operating Systems [Winter 2018] February 28, 2018 February 28, 2018 L14.2 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma FEEDBACK FROM 2/23 There was no feedback !!! CHAPTER 18: INTRODUCTION TO PAGING TCSS422: Operating Systems [Winter 2018] TCSS422: Operating Systems [Winter 2018] February 28, 2018 L14.3 February 28, 2018 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma L14.4 PAGING DESIGN QUESTIONS WHERE ARE PAGE TABLES STORED? Where are page tables stored? Example: . Consider a 32-bit process address space (up to 4GB) What are the typical contents of the page table? . With 4 KB pages . 20 bits for VPN (220 pages) How big are page tables? . 12 bits for the page offset (212 unique bytes in a page) Page tables for each process are stored in RAM Does paging make the system too slow? . Support potential storage of 220 translations = 1,048,576 pages per process . Each page has a page table entry size of 4 bytes TCSS422: Operating Systems [Winter 2018] TCSS422: Operating Systems [Winter 2018] February 28, 2018 L14.5 February 28, 2018 L14.6 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma Slides by Wes J.
    [Show full text]