DOCSLIB.ORG

Intel® Itanium™ Processor Microarchitecture Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Intel® Itanium™ Processor Microarchitecture Overview Itanium™ Processor Microarchitecture Overview Intel® Itanium™ Processor Microarchitecture Overview Harsh Sharangpani Principal Engineer and IA-64 Microarchitecture Manager Intel Corporation ® Microprocessor Forum October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Unveiling the Intel® Itanium™ Processor Design l Leading-edge implementation of IA-64 architecture for world-class performance l New capabilities for systems that fuel the Internet Economy l Strong progress on initial silicon ® Microprocessor Forum 2 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Itanium™ Processor Goals l World-class performance on high-end applications – High performance for commercial servers – Supercomputer-level floating point for technical workstations l Large memory management with 64-bit addressing l Robust support for mission critical environments – Enhanced error correction, detection & containment l Full IA-32 instruction set compatibility in hardware l Deliver across a broad range of industry requirements – Flexible for a variety of OEM designs and operating systems Deliver world-class performance and features for servers & workstations and emerging internet applications ® Microprocessor Forum 3 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview EPIC Design Philosophy ì Maximize performance via EPICEPIC hardware & software synergy ì Advanced features enhance instruction level parallelism ìPredication, Speculation, ... ì Massive hardware resources for parallel execution VLIW OOO / SuperScalar ì High performance EPIC building block RISC CISC Performance Time Achieving performance at the most fundamental level ® Microprocessor Forum 4 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Itanium™ EPIC Design Maximizes SW-HW Synergy Architecture Features programmed by compiler: Register Branch Explicit Data & Control Memory Stack Predication Hints Parallelism Speculation Hints & Rotation Micro-architecture Features in hardware: Fetch Issue Register Control Parallel Resources Memory Handling Bypasses & Dependencies Subsystem 4 Integer + Fast, Simple 6-Issue Simple Fast, 4 MMX Units 128 GR & Instruction 128 FR, 2 FMACs Three Cache Register (4 for SSE) levels of & Branch Remap cache: & Predictors 2 LD/ST units L1, L2, L3 Stack Engine 32 entry ALAT ® Speculation Deferral Management Microprocessor Forum 5 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Breakthrough Levels of Parallelism M F I M F I 6 instructions provides 12 parallel ops/clock (SP: 20 parallel ops/clock) •Load 4 DP (8 SP) 2 ALU ops for digital content creation ops via 2 ld-pair & scientific computing •2 ALU oper 4 DP FLOPS (post incr) (8 SP FLOPS) 6 instructions M I B M I B provides 8 parallel ops / clock for enterprise & Internet applications 2 Loads + 1 Branch Hint + 2 ALU ops 2 ALU ops 1 Branch instr (post incr) Itanium™ delivers greater instruction level ® parallelism than any contemporary processor Microprocessor Forum 6 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Highlights of the Itanium™ Pipeline l 6-Wide EPIC hardware under precise compiler control – Parallel hardware and control for predication & speculation – Efficient mechanism for enabling register stacking & rotation – Software-enhanced branch prediction l 10-stage in-order pipeline with cycle time designed for: – Single cycle ALU (4 ALUs globally bypassed) – Low latency from data cache l Dynamic support for run-time optimization – Decoupled front end with prefetch to hide fetch latency – Aggressive branch prediction to reduce branch penalty – Non-blocking caches and register scoreboard to hide load latency Parallel, deep, and dynamic pipeline ® designed for maximum throughput Microprocessor Forum 7 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview 10 Stage In-Order Core Pipeline Front End Execution •Pre-fetch/Fetch of up • 4 single cycle ALUs, 2 ld/str to 6 instructions/cycle • Advanced load control •Hierarchy of branch • Predicate delivery & branch predictors • Nat/Exception//Retirement •Decoupling buffer WORD-LINE EXPAND RENAME DECODE REGISTER READ IPG FET ROT EXP RENWLD REG EXE DET WRB INST POINTER FETCH ROTATE EXECUTEEXCEPTION WRITE-BACK GENERATION DETECT Instruction Delivery Operand Delivery •Dispersal of up to 6 • Reg read + Bypasses instructions on 9 ports • Register scoreboard •Reg. remapping • Predicated •Reg. stack engine dependencies ® Microprocessor Forum 8 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Frontend: Prefetch & Fetch IPG FET ROT l SW-triggered prefetch loads target code early using br hints l Streaming prefetch of large blocks via hint on branch l Early prefetch of small blocks via BRP instruction l I-Fetch of 32 Bytes/clock feeds an 8-bundle decoupling buffer l Buffer allows front-end to fetch even when back-end is stalled l Hides instruction cache misses and branch bubbles 8 bundle buffer IP IP MUX I-Cache & ITLB Fetch bubble Feed Branch Predictor Structures & Resteers IPG FET ROT EXP Aggressive instruction fetch hardware to feed a ® highly parallel, high performance machine Microprocessor Forum 9 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Front End: Branch Prediction IPG FET ROT l Branch hints combine with predictor hierarchy to improve branch prediction: four progressive resteers l 4 TARs programmed by “importance” hints l 512-entry 2-level predictor provides dynamic direction prediction l 64-entry BTAC contains footprint of upcoming branch targets (programmed by branch hints, and allocated dynamically) IP IP I-Cache & ITLB 8 bundle buffer MUX Loop Exit Return Stack Buffer Corrector Target Adaptive Br Target Branch Branch Address 2-Level Address Address Address Registers Predictor Cache Calc 1 Calc 2 IPG FET ROT EXP Intelligent branch prediction improves ® performance across all workloads Microprocessor Forum 10 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Instruction Delivery: Dispersal EXP l Stop bits eliminate dependency checking l Templates simplify routing l 1st available dispersal from 6 syllables to 9 issue ports – Keep issuing until stop bit, resource oversubscription, or asymmetry M0 S0 M1 S1 S2 I0 I1 Dispersal Network F0 F1 S3 S4 S5 B0 B1 B2 ROT EXP ®Achieves highly parallel execution with simple hardware Microprocessor Forum 11 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Instruction Delivery: Stacking REN l Massive 128 register file accommodates multiple variable sized procedures via stacking l Eliminates most register spill / fill at procedure interfaces l Achieved transparently to the compiler l Using register remapping via parallel adders l Stack engine performs the few required spill/fills Stall Stack Engine M0 Spill/Fill Injection M1 Integer, FP, I0 & Predicate I1 Renamers F0 EXP F1 REN WLD Unique register model enables faster ® execution of object-oriented code Microprocessor Forum 12 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Operand Delivery WLD REG l Multiported register file + mux hierarchy delivers operands in REG l Unique “Delayed Stall” mechanism used for register dependencies l Avoids pipeline flush or replay on unavailable data l Stall computed in REG, but core pipeline stalls in EXE l Special Operand Latch Manipulation (OLM) captures data returns into operand latches, to mimic register file read Bypass Muxes 128 Entry Integer ALUs Src Register File 8R / 6W WLD REG EXE Src Src Dependency Control OLM comparators Scoreboard Comparators Delayed Stall Dst Preds Avoids pipeline flush to enable a more ® effective, higher throughput pipeline Microprocessor Forum 13 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Predicate Delivery EXE l All instructions read operands and execute l Canceled at retirement if predicates off l Predicates generated in EXE (by cmps), delivered in DET, & feed into: retirement, branch execution and dependency detection l Smart control network cancels false stalls on predicated dependencies l Dependency detection for cancelled producer/consumer (REG) REG EXE DET Bypass Muxes Predicate To Dependency Detect (x6) Register To Branch Execution (x3) File Read To Retirement (x6) I-Cmps F-Cmps Higher performance through removal of branch ® penalties in server and workstation applications Microprocessor Forum 14 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Parallel Branch Execution DET WRB l Speculation + predication result in clusters of branches l Execution of 3 branches/clock optimizes for clustered branches l Branch execution in DET allows cmps-->branches in same issue group REG EXE DET WRB 3 BR Read Pred. Delivery Retirement of branch bundle IP relative Address Direction Resteer Validation Validation IP Most recent branch prediction info Parallel branch hardware extends performance ® benefits of EPIC technology Microprocessor Forum 15 October 5-6, 1999 Itanium™ Processor Microarchitecture Overview Speculation Hardware DET WRB l Control Speculation support requires minimal hardware l Computed memory exception delivered with data as tokens (NaTs) l NaTs propagate through subsequent executions like source data l Data Speculation enabled efficiently via ALAT structure l 32 outstanding advanced loads l Indexed by reg-ids, keeps partial physical address tag l 0 clk checks: dependent use can be issued in parallel with check EXE DET Physical WRB Address 32-entry Adv Ld Status Exception Address Logic TLB ALAT Check & Exception Memory Spec. Ld. Status (NaT) Subsystem Check Instruction ® Efficient elimination of memory
Load more

Recommended publications
  • Branch Prediction Side Channel Attacks
    Predicting Secret Keys via Branch Prediction Onur Ac³i»cmez1, Jean-Pierre Seifert2;3, and C»etin Kaya Ko»c1;4 1 Oregon State University School of Electrical Engineering and Computer Science Corvallis, OR 97331, USA 2 Applied Security Research Group The Center for Computational Mathematics and Scienti¯c Computation Faculty of Science and Science Education University of Haifa Haifa 31905, Israel 3 Institute for Computer Science University of Innsbruck 6020 Innsbruck, Austria 4 Information Security Research Center Istanbul Commerce University EminÄonÄu,Istanbul 34112, Turkey [email protected], [email protected], [email protected] Abstract. This paper presents a new software side-channel attack | enabled by the branch prediction capability common to all modern high-performance CPUs. The penalty payed (extra clock cycles) for a mispredicted branch can be used for cryptanalysis of cryptographic primitives that employ a data-dependent program flow. Analogous to the recently described cache-based side-channel attacks our attacks also allow an unprivileged process to attack other processes running in parallel on the same processor, despite sophisticated partitioning methods such as memory protection, sandboxing or even virtualization. We will discuss in detail several such attacks for the example of RSA, and experimentally show their applicability to real systems, such as OpenSSL and Linux. More speci¯cally, we will present four di®erent types of attacks, which are all derived from the basic idea underlying our novel side-channel attack. Moreover, we also demonstrate the strength of the branch prediction side-channel attack by rendering the obvious countermeasure in this context (Montgomery Multiplication with dummy-reduction) as useless.
    [Show full text]
  • BRANCH PREDICTORS Mahdi Nazm Bojnordi Assistant Professor School of Computing University of Utah
    BRANCH PREDICTORS Mahdi Nazm Bojnordi Assistant Professor School of Computing University of Utah CS/ECE 6810: Computer Architecture Overview ¨ Announcements ¤ Homework 2 release: Sept. 26th ¨ This lecture ¤ Dynamic branch prediction ¤ Counter based branch predictor ¤ Correlating branch predictor ¤ Global vs. local branch predictors Big Picture: Why Branch Prediction? ¨ Problem: performance is mainly limited by the number of instructions fetched per second ¨ Solution: deeper and wider frontend ¨ Challenge: handling branch instructions Big Picture: How to Predict Branch? ¨ Static prediction (based on direction or profile) ¨ Always not-taken ¨ Target = next PC ¨ Always taken ¨ Target = unknown clk direction target ¨ Dynamic prediction clk PC + ¨ Special hardware using PC NPC 4 Inst. Memory Instruction Recall: Dynamic Branch Prediction ¨ Hardware unit capable of learning at runtime ¤ 1. Prediction logic n Direction (taken or not-taken) n Target address (where to fetch next) ¤ 2. Outcome validation and training n Outcome is computed regardless of prediction ¤ 3. Recovery from misprediction n Nullify the effect of instructions on the wrong path Branch Prediction ¨ Goal: avoiding stall cycles caused by branches ¨ Solution: static or dynamic branch predictor ¤ 1. prediction ¤ 2. validation and training ¤ 3. recovery from misprediction ¨ Performance is influenced by the frequency of branches (b), prediction accuracy (a), and misprediction cost (c) Branch Prediction ¨ Goal: avoiding stall cycles caused by branches ¨ Solution: static or dynamic branch predictor ¤ 1. prediction ¤ 2. validation and training ¤ 3. recovery from misprediction ¨ Performance is influenced by the frequency of branches (b), prediction accuracy (a), and misprediction cost (c) ��� ���� ��� 1 + �� ������� = = 234 = ��� ���� ���567 1 + 1 − � �� Problem ¨ A pipelined processor requires 3 stall cycles to compute the outcome of every branch before fetching next instruction; due to perfect forwarding/bypassing, no stall cycles are required for data/structural hazards; every 5th instruction is a branch.
    [Show full text]
  • 18-741 Advanced Computer Architecture Lecture 1: Intro And
    Computer Architecture Lecture 10: Branch Prediction Prof. Onur Mutlu ETH Zürich Fall 2017 25 October 2017 Mid-Semester Exam November 30 In class Questions similar to homework questions 2 High-Level Summary of Last Week SIMD Processing Array Processors Vector Processors SIMD Extensions Graphics Processing Units GPU Architecture GPU Programming 3 Agenda for Today & Tomorrow Control Dependence Handling Problem Six solutions Branch Prediction Other Methods of Control Dependence Handling 4 Required Readings McFarling, “Combining Branch Predictors,” DEC WRL Technical Report, 1993. Required T. Yeh and Y. Patt, “Two-Level Adaptive Training Branch Prediction,” Intl. Symposium on Microarchitecture, November 1991. MICRO Test of Time Award Winner (after 24 years) Required 5 Recommended Readings Smith and Sohi, “The Microarchitecture of Superscalar Processors,” Proceedings of the IEEE, 1995 More advanced pipelining Interrupt and exception handling Out-of-order and superscalar execution concepts Recommended Kessler, “The Alpha 21264 Microprocessor,” IEEE Micro 1999. Recommended 6 Control Dependence Handling 7 Control Dependence Question: What should the fetch PC be in the next cycle? Answer: The address of the next instruction All instructions are control dependent on previous ones. Why? If the fetched instruction is a non-control-flow instruction: Next Fetch PC is the address of the next-sequential instruction Easy to determine if we know the size of the fetched instruction If the instruction that is fetched is a control-flow
    [Show full text]
  • State of the Art Regarding Both Compiler Optimizations for Instruction Fetch, and the Fetch Architectures for Which We Try to Optimize Our Applications
    ¢¡¤£¥¡§¦ ¨ © ¡§ ¦ £ ¡ In this work we are trying to increase fetch performance using both software and hardware tech- niques, combining them to obtain maximum performance at the minimum cost and complexity. In this chapter we introduce the state of the art regarding both compiler optimizations for instruction fetch, and the fetch architectures for which we try to optimize our applications. The first section introduces code layout optimizations. The compiler can influence instruction fetch performance by selecting the layout of instructions in memory. This determines both the conflict rate of the instruction cache, and the behavior (taken or not taken) of conditional branches. We present an overview of the different layout algorithms proposed in the literature, and how our own algorithm relates to them. The second section shows how instruction fetch architectures have evolved from pipelined processors to the more aggressive wide issue superscalars. This implies increasing fetch perfor- mance from a single instruction every few cycles, to one instruction per cycle, to a full basic block per cycle, and finally to multiple basic blocks per cycle. We emphasize the description of the trace cache, as it will be the reference architecture in most of our work. 2.1 Code layout optimizations The mapping of instruction to memory is determined by the compiler. This mapping determines not only the code page where an instruction is found, but also the cache line (or which set in a set associative cache) it will map to. Furthermore, a branch will be taken or not taken depending on the placement of the successor basic blocks. By mapping instructions in a different order, the compiler has a direct impact on the fetch engine performance.
    [Show full text]
  • Virtual Memory - Paging
    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
    [Show full text]
  • Branch Prediction for Network Processors
    BRANCH PREDICTION FOR NETWORK PROCESSORS by David Bermingham, B.Eng Submitted in partial fulfilment of the requirements for the Degree of Doctor of Philosophy Dublin City University School of School of Electronic Engineering Supervisors: Dr. Xiaojun Wang Prof. Lingling Sun September 2010 I hereby certify that this material, which I now submit for assessment on the programme of study leading to the award of Doctor of Philosophy is entirely my own work, that I have exercised reasonable care to ensure that the work is original, and does not to the best of my knowledge breach any law of copy- right, and has not been taken from the work of others save and to the extent that such work has been cited and acknowledged within the text of my work. Signed: David Bermingham (Candidate) ID: Date: TABLE OF CONTENTS Abstract vii List of Figures ix List of Tables xii List of Acronyms xiv List of Peer-Reviewed Publications xvi Acknowledgements xviii 1 Introduction 1 1.1 Network Processors . 1 1.2 Trends Within Networks . 2 1.2.1 Bandwidth Growth . 2 1.2.2 Network Technologies . 3 1.2.3 Application and Service Demands . 3 1.3 Network Trends and Network Processors . 6 1.3.1 The Motivation for This Thesis . 7 1.4 Research Objectives . 9 1.5 Thesis Structure . 10 iii 2 Technical Background 12 2.1 Overview . 12 2.2 Networks . 13 2.2.1 Network Protocols . 13 2.2.2 Network Technologies . 14 2.2.3 Router Architecture . 17 2.3 Network Processors . 19 2.3.1 Intel IXP-28XX Network Processor .
    [Show full text]
  • X86 Memory Protection and Translation
    2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory x86 Memory Protection and Threads Formats Allocators Translation User System Calls Kernel Don Porter RCU File System Networking Sync Memory Device CPU Today’s Management Drivers Scheduler Lecture Hardware Interrupts Disk Net Consistency 1 Today’s Lecture: Focus on Hardware ABI 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Lecture Goal Undergrad Review • Understand the hardware tools available on a • What is: modern x86 processor for manipulating and – Virtual memory? protecting memory – Segmentation? • Lab 2: You will program this hardware – Paging? • Apologies: Material can be a bit dry, but important – Plus, slides will be good reference • But, cool tech tricks: – How does thread-local storage (TLS) work? – An actual (and tough) Microsoft interview question 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Memory Mapping Two System Goals 1) Provide an abstraction of contiguous, isolated virtual Process 1 Process 2 memory to a program Virtual Memory Virtual Memory 2) Prevent illegal operations // Program expects (*x) – Prevent access to other application or OS memory 0x1000 Only one physical 0x1000 address 0x1000!! // to always be at – Detect failures early (e.g., segfault on address 0) // address 0x1000 – More recently, prevent exploits that try to execute int *x = 0x1000; program data 0x1000 Physical Memory 5 6 5 6 1 2/5/20 COMP 790: OS Implementation COMP 790: OS Implementation Outline x86 Processor Modes • x86
    [Show full text]
  • Virtual Memory in X86
    Fall 2017 :: CSE 306 Virtual Memory in x86 Nima Honarmand Fall 2017 :: CSE 306 x86 Processor Modes • Real mode – walks and talks like a really old x86 chip • State at boot • 20-bit address space, direct physical memory access • 1 MB of usable memory • No paging • No user mode; processor has only one protection level • Protected mode – Standard 32-bit x86 mode • Combination of segmentation and paging • Privilege levels (separate user and kernel) • 32-bit virtual address • 32-bit physical address • 36-bit if Physical Address Extension (PAE) feature enabled Fall 2017 :: CSE 306 x86 Processor Modes • Long mode – 64-bit mode (aka amd64, x86_64, etc.) • Very similar to 32-bit mode (protected mode), but bigger address space • 48-bit virtual address space • 52-bit physical address space • Restricted segmentation use • Even more obscure modes we won’t discuss today xv6 uses protected mode w/o PAE (i.e., 32-bit virtual and physical addresses) Fall 2017 :: CSE 306 Virt. & Phys. Addr. Spaces in x86 Processor • Both RAM hand hardware devices (disk, Core NIC, etc.) connected to system bus • Mapped to different parts of the physical Virtual Addr address space by the BIOS MMU Data • You can talk to a device by performing Physical Addr read/write operations on its physical addresses Cache • Devices are free to interpret reads/writes in any way they want (driver knows) System Interconnect (Bus) : all addrs virtual DRAM Network … Disk (Memory) Card : all addrs physical Fall 2017 :: CSE 306 Virt-to-Phys Translation in x86 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only • Segmentation cannot be disabled! • But can be made a no-op (a.k.a.
    [Show full text]
  • Operating Systems
    UC Santa Barbara Operating Systems Christopher Kruegel Department of Computer Science UC Santa Barbara http://www.cs.ucsb.edu/~chris/ Virtual Memory and Paging UC Santa Barbara • What if a program is too big to be loaded in memory • What if a higher degree of multiprogramming is desirable • Physical memory is split in page frames • Virtual memory is split in pages • OS (with help from the hardware) manages the mapping between pages and page frames 2 Mapping Pages to Page Frames UC Santa Barbara • Virtual memory: 64KB • Physical memory: 32KB • Page size: 4KB • Virtual memory pages: 16 • Physical memory pages: 8 3 Memory Management Unit UC Santa Barbara • Automatically performs the mapping from virtual addresses into physical addresses 4 Memory Management Unit UC Santa Barbara • Addresses are split into a page number and an offset • Page numbers are used to look up a table in the MMU with as many entries as the number of virtual pages • Each entry in the table contains a bit that states if the virtual page is actually mapped to a physical one • If it is so, the entry contains the number of physical page used • If not, a page fault is generated and the OS has to deal with it 5 Page Tables UC Santa Barbara • Page tables contain an entry for each virtual table • If virtual memory is big (e.g., 32 bit and 64 bit addresses) the table can become of unmanageable size • Solution: instead of keeping them in the MMU move them to main memory • Problem: page tables are used each time an access to memory is performed.
    [Show full text]
  • Trends in Processor Architecture
    A. González Trends in Processor Architecture Trends in Processor Architecture Antonio González Universitat Politècnica de Catalunya, Barcelona, Spain 1. Past Trends Processors have undergone a tremendous evolution throughout their history. A key milestone in this evolution was the introduction of the microprocessor, term that refers to a processor that is implemented in a single chip. The first microprocessor was introduced by Intel under the name of Intel 4004 in 1971. It contained about 2,300 transistors, was clocked at 740 KHz and delivered 92,000 instructions per second while dissipating around 0.5 watts. Since then, practically every year we have witnessed the launch of a new microprocessor, delivering significant performance improvements over previous ones. Some studies have estimated this growth to be exponential, in the order of about 50% per year, which results in a cumulative growth of over three orders of magnitude in a time span of two decades [12]. These improvements have been fueled by advances in the manufacturing process and innovations in processor architecture. According to several studies [4][6], both aspects contributed in a similar amount to the global gains. The manufacturing process technology has tried to follow the scaling recipe laid down by Robert N. Dennard in the early 1970s [7]. The basics of this technology scaling consists of reducing transistor dimensions by a factor of 30% every generation (typically 2 years) while keeping electric fields constant. The 30% scaling in the dimensions results in doubling the transistor density (doubling transistor density every two years was predicted in 1975 by Gordon Moore and is normally referred to as Moore’s Law [21][22]).
    [Show full text]
  • Lecture 15 15.1 Paging
    CMPSCI 377 Operating Systems Fall 2009 Lecture 15 Lecturer: Emery Berger Scribe: Bruno Silva,Jim Partan 15.1 Paging In recent lectures, we have been discussing virtual memory. The valid addresses in a process' virtual address space correspond to actual data or code somewhere in the system, either in physical memory or on the disk. Since physical memory is fast and is a limited resource, we use the physical memory as a cache for the disk (another way of saying this is that the physical memory is \backed by" the disk, just as the L1 cache is \backed by" the L2 cache). Just as with any cache, we need to specify our policies for when to read a page into physical memory, when to evict a page from physical memory, and when to write a page from physical memory back to the disk. 15.1.1 Reading Pages into Physical Memory For reading, most operating systems use demand paging. This means that pages are only read from the disk into physical memory when they are needed. In the page table, there is a resident status bit, which says whether or not a valid page resides in physical memory. If the MMU tries to get a physical page number for a valid page which is not resident in physical memory, it issues a pagefault to the operating system. The OS then loads that page from disk, and then returns to the MMU to finish the translation.1 In addition, many operating systems make some use of pre-fetching, which is called pre-paging when used for pages.
    [Show full text]
  • X86 Memory Protection and Translation
    x86 Memory Protection and Translation Don Porter CSE 506 Lecture Goal ò Understand the hardware tools available on a modern x86 processor for manipulating and protecting memory ò Lab 2: You will program this hardware ò Apologies: Material can be a bit dry, but important ò Plus, slides will be good reference ò But, cool tech tricks: ò How does thread-local storage (TLS) work? ò An actual (and tough) Microsoft interview question Undergrad Review ò What is: ò Virtual memory? ò Segmentation? ò Paging? Two System Goals 1) Provide an abstraction of contiguous, isolated virtual memory to a program 2) Prevent illegal operations ò Prevent access to other application or OS memory ò Detect failures early (e.g., segfault on address 0) ò More recently, prevent exploits that try to execute program data Outline ò x86 processor modes ò x86 segmentation ò x86 page tables ò Software vs. Hardware mechanisms ò Advanced Features ò Interesting applications/problems x86 Processor Modes ò Real mode – walks and talks like a really old x86 chip ò State at boot ò 20-bit address space, direct physical memory access ò Segmentation available (no paging) ò Protected mode – Standard 32-bit x86 mode ò Segmentation and paging ò Privilege levels (separate user and kernel) x86 Processor Modes ò Long mode – 64-bit mode (aka amd64, x86_64, etc.) ò Very similar to 32-bit mode (protected mode), but bigger ò Restrict segmentation use ò Garbage collect deprecated instructions ò Chips can still run in protected mode with old instructions Translation Overview 0xdeadbeef Segmentation 0x0eadbeef Paging 0x6eadbeef Virtual Address Linear Address Physical Address Protected/Long mode only ò Segmentation cannot be disabled! ò But can be a no-op (aka flat mode) x86 Segmentation ò A segment has: ò Base address (linear address) ò Length ò Type (code, data, etc).
    [Show full text]