DOCSLIB.ORG

Machines and Virtualization Memory Protection Architectural

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Machines and Virtualization Memory Protection Architectural Memory Protection Paging Virtual memory provides protection by: • Each process (user or OS) has different virtual memory space. Machines and Virtualization • The OS maintain the page tables for all processes. • A reference outside the process allocated space cause an exception that lets the OS decide what to do. Systems and Networks • Memory sharing between processes is done via different Jeff Chase Virtual spaces but common physical frames. Spring 2006 [Kedem, CPS 104, Fall05] Architectural Foundations of OS Kernels Memory and the CPU 0 • One or more privileged execution modes (e.g., kernel mode) OS code protected device control registers CPU OS data privileged instructions to control basic machine functions • System call trap instruction and protected fault handling Program A User processes safely enter the kernel to access shared OS services. Datadata R0 • Virtual memory mapping x Program B OS controls virtual-physical translations for each address space. Rn Data • Device interrupts to notify the kernel of I/O completion etc. PC x Includes timer hardware and clock interrupts to periodically return registers control to the kernel as user code executes. code library 2n • Atomic instructions for coordination on multiprocessors main memory Kernel Mode Introduction to Virtual Addressing 0 CPU OS code virtual physical CPU mode (a field memory User processes memory The kernel controls in some status OS data address memory (big?) (small?) the virtual-physical register) indicates through virtual translations in effect whether the CPU is text Program A addresses. for each space. running in a user physical data data program or in the mode Data address BSS protected kernel. R0 space The kernel and the user stack The machine does not x Program B machine collude to Some instructions or translate virtual args/env allow a user process Rn register accesses are Data addresses to kernel to access memory unless the kernel only legal when the PC x physical addresses. CPU is executing in “says it’s OK”. registers kernel mode. code library virtual-to-physical The specific mechanisms for 2n translations main memory implementing virtual address translation are machine-dependent. 1 Processes and the Kernel The Kernel • Today, all “real” operating systems have protected kernels. The kernel resides in a well-known file: the “machine” processes The kernel sets automatically loads it into memory (boots) on power-on/reset. in private data data up process virtual execution Our “kernel” is called the executive in some systems (e.g., XP). address contexts to spaces “virtualize” the • The kernel is (mostly) a library of service procedures shared machine. by all user programs, but the kernel is protected: ...and upcalls (e.g., system call traps User code cannot access internal kernel data structures directly, signals) and it can invoke the kernel only at well-defined entry points (system calls). shared kernel Threads or processes code and data • Kernel code is like user code, but the kernel is privileged: in shared enter the address space kernel for services. The kernel has direct access to all hardware functions, and defines the machine entry points for interrupts and exceptions. CPU and devices force entry to the kernel to handle exceptional events. Protecting Entry to the Kernel Example: System Call Traps Protected events and kernel mode are the architectural User code invokes kernel services by initiating system call traps. foundations of kernel-based OS (Unix, XP, etc). • Programs in C, C++, etc. invoke system calls by linking to a • The machine defines a small set of exceptional event types. standard library of procedures written in assembly language. • The machine defines what conditions raise each event. the library defines a stub or wrapper routine for each syscall • The kernel installs handlers for each event at boot time. stub executes a special trap instruction (e.g., chmk or callsys or int) e.g., a table in kernel memory read by the machine syscall arguments/results passed in registers or user stack Alpha CPU architecture The machine transitions to kernel mode user read() in Unix libc.a library (executes in user mode): only on an exceptional event. interrupt or #define SYSCALL_READ 27 # code for a read system call The kernel defines the event handlers. trap/return exception move arg0…argn, a0…an # syscall args in registers A0..AN move SYSCALL_READ, v0 # syscall dispatch code in V0 callsys # kernel trap Therefore the kernel chooses what code kernel move r1, _errno # errno = return status will execute in kernel mode, and when. return Faults The Role of Events Faults are similar to system calls in some respects: A CPU event is an “unnatural” change in control flow. • Faults occur as a result of a process executing an instruction. Like a procedure call, an event changes the PC. Fault handlers execute on the process kernel stack; the fault handler may block (sleep) in the kernel. Also changes mode or context (current stack), or both. Events do not change the current space! • The completed fault handler may return to the faulted context. But faults are different from syscall traps in other respects: The kernel defines a handler routine for each event type. Event handlers always execute in kernel mode. • Syscalls are deliberate, but faults are “accidents”. The specific types of events are defined by the machine. divide-by-zero, dereference invalid pointer, memory page fault • Not every execution of the faulting instruction results in a fault. Once the system is booted, every entry to the kernel occurs as a result of an event. may depend on memory state or register contents In some sense, the whole kernel is a big event handler. 2 CPU Events: Interrupts and Exceptions Mode, Space, and Context An interrupt is caused by an external event. At any time, the state of each processor is defined by: device requests attention, timer expires, etc. 1. mode: given by the mode bit An exception is caused by an executing instruction. Is the CPU executing in the protected kernel or a user program? CPU requires software intervention to handle a fault or trap. 2. space: defined by V->P translations currently in effect control flow unplanned deliberate What address space is the CPU running in? Once the system is sync fault syscall trap exception.cc booted, it always runs in some virtual address space. async interrupt AST 3. context: given by register state and execution stream AST: Asynchronous System Trap Also called a software interrupt or an Is the CPU executing a thread/process, or an interrupt handler? Asynchronous or Deferred Procedure Call event handler (e.g., (APC or DPC) ISR: Interrupt Service Where is the stack? Routine) Note: different “cultures” may use some of these terms (e.g., These are important because the mode/space/context trap, fault, exception, event, interrupt) slightly differently. determines the meaning and validity of key operations. The Virtual Address Space Process and Kernel Address Spaces 0 0x0 text A typical process VAS space includes: data • user regions in the lower half 0 0x0 BSS sbrk() n-bit virtual data data jsr V->P mappings specific to each process 32-bit virtual user stack address accessible to user or kernel code address args/env space space • kernel regions in upper half 2n-1 shared by all processes, but accessible only to 2n-1-1 0x7FFFFFFF kernel code kernel text and • NT (XP?) on x86 subdivides kernel region into an kernel data unpaged half and a (mostly) paged upper half at n-1 0xC0000000 for page tables and I/O cache. 2 0x80000000 • Win95/98 uses the lower half of system space as a 2n-1 0xffffffff system-wide shared region. 2n-1 0xFFFFFFFF A VAS for a private address space system (e.g., Unix, NT/XP) executing on a typical 32-bit system (e.g., x86). The OS Directs the MMU Virtual Address Translation 29 virtual address 0 The OS controls the operation of the MMU to select: 13 Example: typical 32-bit 00 VPN offset (1) the subset of possible virtual addresses that are valid for architecture with 8KB pages. each process (the process virtual address space); Virtual address translation maps a (2) the physical translations for those virtual addresses; virtual page number (VPN) to a (3) the modes of permissible access to those virtual addresses; physical page frame number (PFN): the rest is easy. address read/write/execute translation (4) the specific set of translations in effect at any instant. Deliver exception to OS if translation is not need rapid context switch from one address space to another valid and accessible in MMU completes a reference only if the OS “says it’s OK”. requested mode. MMU raises an exception if the reference is “not OK”. physical address PFN + { offset 3 Completing a VM Reference Virtual Memory as a Cache virtual physical MMU access executable backing start probe load memory memory page table TLB physical file storage here memory (big) (small) header text pageout/eviction text data probe access raise idatadata BSS TLB valid? exception wdata symbol user stack table, etc. args/env load page fetch zero-fill program kernel TLB OS sections process physical segments page frames fetch page on allocate page signal virtual-to-physical from disk disk? frame fault? process translations Wrapping Up What did we just do? There is lots more to say about address translation, but we We used special machine features to “virtualize” a core don’t want to spend too much time on it now. resource: memory. • On NT/x86, each address space has a page directory • Each process/space only gets some of the memory. • One page: 4K bytes, 1024 4-byte entries (PTEs) • The OS decides how much you get. • The OS decides what parts of the program and its data are in • Each PDIR entry points to a “page table” memory, and what parts you will have to wait for.
Load more

Recommended publications
  • Openvms Record Management Services Reference Manual
    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
    [Show full text]
  • Overcoming Traditional Problems with OS Huge Page Management
    MEGA: Overcoming Traditional Problems with OS Huge Page Management Theodore Michailidis Alex Delis Mema Roussopoulos University of Athens University of Athens University of Athens Athens, Greece Athens, Greece Athens, Greece [email protected] [email protected] [email protected] ABSTRACT KEYWORDS Modern computer systems now feature memory banks whose Huge pages, Address Translation, Memory Compaction aggregate size ranges from tens to hundreds of GBs. In this context, contemporary workloads can and do often consume ACM Reference Format: Theodore Michailidis, Alex Delis, and Mema Roussopoulos. 2019. vast amounts of main memory. This upsurge in memory con- MEGA: Overcoming Traditional Problems with OS Huge Page Man- sumption routinely results in increased virtual-to-physical agement. In The 12th ACM International Systems and Storage Con- address translations, and consequently and more importantly, ference (SYSTOR ’19), June 3–5, 2019, Haifa, Israel. ACM, New York, more translation misses. Both of these aspects collectively NY, USA, 11 pages. https://doi.org/10.1145/3319647.3325839 do hamper the performance of workload execution. A solu- tion aimed at dramatically reducing the number of address translation misses has been to provide hardware support for 1 INTRODUCTION pages with bigger sizes, termed huge pages. In this paper, we Computer memory capacities have been increasing sig- empirically demonstrate the benefits and drawbacks of using nificantly over the past decades, leading to the development such huge pages. In particular, we show that it is essential of memory hungry workloads that consume vast amounts for modern OS to refine their software mechanisms to more of main memory. This upsurge in memory consumption rou- effectively manage huge pages.
    [Show full text]
  • Asynchronous Page Faults Aix Did It Red Hat Author Gleb Natapov August 10, 2010
    Asynchronous page faults Aix did it Red Hat Author Gleb Natapov August 10, 2010 Abstract Host memory overcommit may cause guest memory to be swapped. When guest vcpu access memory swapped out by a host its execution is suspended until memory is swapped back. Asynchronous page fault is a way to try and use guest vcpu more efficiently by allowing it to execute other tasks while page is brought back into memory. Part I How KVM Handles Guest Memory and What Inefficiency it Has With Regards to Host Swapping Mapping guest memory into host memory But we do it on demand Page fault happens on first guest access What happens on a page fault? 1 VMEXIT 2 kvm mmu page fault() 3 gfn to pfn() 4 get user pages fast() no previously mapped page and no swap entry found empty page is allocated 5 page is added into shadow/nested page table What happens on a page fault? 1 VMEXIT 2 kvm mmu page fault() 3 gfn to pfn() 4 get user pages fast() no previously mapped page and no swap entry found empty page is allocated 5 page is added into shadow/nested page table What happens on a page fault? 1 VMEXIT 2 kvm mmu page fault() 3 gfn to pfn() 4 get user pages fast() no previously mapped page and no swap entry found empty page is allocated 5 page is added into shadow/nested page table What happens on a page fault? 1 VMEXIT 2 kvm mmu page fault() 3 gfn to pfn() 4 get user pages fast() no previously mapped page and no swap entry found empty page is allocated 5 page is added into shadow/nested page table What happens on a page fault? 1 VMEXIT 2 kvm mmu page fault() 3 gfn to pfn()
    [Show full text]
  • What Is an Operating System III 2.1 Compnents II an Operating System
    Page 1 of 6 What is an Operating System III 2.1 Compnents II An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Memory management Among other things, a multiprogramming operating system kernel must be responsible for managing all system memory which is currently in use by programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory. Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the kernel's memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen any more, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to crash the system. Memory protection enables the kernel to limit a process' access to the computer's memory. Various methods of memory protection exist, including memory segmentation and paging. All methods require some level of hardware support (such as the 80286 MMU), which doesn't exist in all computers.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Measuring Software Performance on Linux Technical Report
    Measuring Software Performance on Linux Technical Report November 21, 2018 Martin Becker Samarjit Chakraborty Chair of Real-Time Computer Systems Chair of Real-Time Computer Systems Technical University of Munich Technical University of Munich Munich, Germany Munich, Germany [email protected] [email protected] OS program program CPU .text .bss + + .data +/- + instructions cache branch + coherency scheduler misprediction core + pollution + migrations data + + interrupt L1i$ miss access + + + + + + context mode + + (TLB flush) TLB + switch data switch miss L1d$ +/- + (KPTI TLB flush) miss prefetch +/- + + + higher-level readahead + page cache miss walk + + multicore + + (TLB shootdown) TLB coherency page DRAM + page fault + cache miss + + + disk + major minor I/O Figure 1. Event interaction map for a program running on an Intel Core processor on Linux. Each event itself may cause processor cycles, and inhibit (−), enable (+), or modulate (⊗) others. Abstract that our measurement setup has a large impact on the results. Measuring and analyzing the performance of software has More surprisingly, however, they also suggest that the setup reached a high complexity, caused by more advanced pro- can be negligible for certain analysis methods. Furthermore, cessor designs and the intricate interaction between user we found that our setup maintains significantly better per- formance under background load conditions, which means arXiv:1811.01412v2 [cs.PF] 20 Nov 2018 programs, the operating system, and the processor’s microar- chitecture. In this report, we summarize our experience on it can be used to improve high-performance applications. how performance characteristics of software should be mea- CCS Concepts • Software and its engineering → Soft- sured when running on a Linux operating system and a ware performance; modern processor.
    [Show full text]
  • Guide to Openvms Performance Management
    Guide to OpenVMS Performance Management Order Number: AA–PV5XA–TE May 1993 This manual is a conceptual and tutorial guide for experienced users responsible for optimizing performance on OpenVMS systems. Revision/Update Information: This manual supersedes the Guide to VMS Performance Management, Version 5.2. Software Version: OpenVMS VAX Version 6.0 Digital Equipment Corporation Maynard, Massachusetts May 1993 Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. © Digital Equipment Corporation 1993. All rights reserved. The postpaid Reader’s Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corporation: ACMS, ALL–IN–1, Bookreader, CI, DBMS, DECnet, DECwindows, Digital, MicroVAX, OpenVMS, PDP–11, VAX, VAXcluster, VAX DOCUMENT, VMS, and the DIGITAL logo. All other trademarks and registered trademarks are the property of their respective holders. ZK4521 This document was prepared using VAX DOCUMENT Version 2.1. Contents Preface ............................................................ ix 1 Introduction to Performance Management 1.1 Knowing Your Workload ....................................... 1–2 1.1.1 Workload Management .................................... 1–3 1.1.2 Workload Distribution ..................................... 1–4 1.1.3 Code Sharing ............................................ 1–4 1.2 Evaluating User Complaints .
    [Show full text]
  • Virtual Memory §5.4 Virt Virtual Memory U Al Memo Use Main Memory As a “Cache” For
    Chapter 5 Large and Fast: Exppgloiting Memory Hierarchy Part II Virtual Memory §5.4 Virt Virtual Memory u al Memo Use main memory as a “cache” for secondary (disk) storage r y Managed jointly by CPU hardware and the operating system (OS) Programs share main memory Each gets a private virtual address space holdinggqy its frequently used code and data Protected from other programs CPU and OS translate virtual addresses to physical addresses VM “block” is called a page VM translation “miss” is called a page fault Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 2 Address Translation Fixed-size pages (e.g., 4K) Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 3 Page Fault Penalty On page fault, the page must be fetched from disk Takes millions of clock cycles Handled by OS code Try to minimize page fault rate Fully associative placement Smart replacement algorithms Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 4 Page Tables Stores placement information Array of page table entries, indexed by virtual page number Page table register in CPU points to page table in physical memory If page is present in memory PTE stores the physical page number Plus other status bits (referenced, dirty, …) If page is not present PTE can refer to location in swap space on dis k Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 5 Translation Using a Page Table Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 6 Mapping Pages to Storage Chapter 5 — Large and Fast: Exploiting Memory Hierarchy — 7 Replacement and Writes
    [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]
  • An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K
    An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K. Qureshi, and Karsten Schwan, Georgia Institute of Technology https://www.usenix.org/conference/atc16/technical-sessions/presentation/huang This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0 Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. An Evolutionary Study of inu emory anagement for Fun and rofit Jian Huang, Moinuddin K. ureshi, Karsten Schwan Georgia Institute of Technology Astract the patches committed over the last five years from 2009 to 2015. The study covers 4587 patches across Linux We present a comprehensive and uantitative study on versions from 2.6.32.1 to 4.0-rc4. We manually label the development of the Linux memory manager. The each patch after carefully checking the patch, its descrip- study examines 4587 committed patches over the last tions, and follow-up discussions posted by developers. five years (2009-2015) since Linux version 2.6.32. In- To further understand patch distribution over memory se- sights derived from this study concern the development mantics, we build a tool called MChecker to identify the process of the virtual memory system, including its patch changes to the key functions in mm. MChecker matches distribution and patterns, and techniues for memory op- the patches with the source code to track the hot func- timizations and semantics. Specifically, we find that tions that have been updated intensively.
    [Show full text]
  • The Evolution of the Unix Time-Sharing System*
    The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier.
    [Show full text]
  • I.T.S.O. Powerpc an Inside View
    SG24-4299-00 PowerPC An Inside View IBM SG24-4299-00 PowerPC An Inside View Take Note! Before using this information and the product it supports, be sure to read the general information under “Special Notices” on page xiii. First Edition (September 1995) This edition applies to the IBM PC PowerPC hardware and software products currently announced at the date of publication. Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address given below. An ITSO Technical Bulletin Evaluation Form for reader′s feedback appears facing Chapter 1. If the form has been removed, comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JLPC Building 014 Internal Zip 5220 1000 NW 51st Street Boca Raton, Florida 33431-1328 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1995. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Abstract This document provides technical details on the PowerPC technology. It focuses on the features and advantages of the PowerPC Architecture and includes an historical overview of the development of the reduced instruction set computer (RISC) technology. It also describes in detail the IBM Power Series product family based on PowerPC technology, including IBM Personal Computer Power Series 830 and 850 and IBM ThinkPad Power Series 820 and 850.
    [Show full text]