Bicameral LLC v. NXP USA, Inc. et al

Western District of Texas, txwd-6:2018-cv-00294

Exhibit Ex. 331EX6

Interested in this case?

Current View

Full Text

Exhibit 331EX6 COMPUTER ARCHITECTURE. .. - QUANTITATIVE A PP RO A CH. JOHN L HENNESSY DAVID A PATTERSON TJ 14 super RUMAH mente Computer Architecture Quantitative Approach David A. Patterson UNIVERSITY OF CALIFORNIA AT BERKELEY John L. Hennessy STANFORD UNIVERSITY With a Contribution by David Goldberg Xerox Palo Alto Research Center 2 MORGAN KAUFMANN PUBLISHERS, INC. SAN MATEO, CALIFORNIA Siccolto como Sponsoring Editor Bruce Spatz Production Manager Shirley Jowell Technical Writer Walker Cunningham Text Design Gary Head Cover Design David Lance Goines Copy Editor Linda Medoff Proofreader Paul Medoff Computer Typesetting and Graphics Fifth Street Computer Services 93 KOR ? NOT Library of Congress Cataloging-in-Publication Data Patterson, David A. Computer architecture: a quantitative approach / David A. Patterson, John L. Hennessy p. cm. Includes bibliographical references ISBN 1-55880-069-8 1. Computer architecture. 2. Electronic digital computers --Design and construction. I. Hennessy, John L. II. Title. QA76.9.A73P377 1990 004.2ʼ2--dc20 89-85227 СІР Morgan Kaufmann Publishers, Inc. Editorial Office: 2929 Campus Drive. San Mateo, CA 94403 Order from: P.O. Box 50490, Palo Alto, CA 94303-9953 ©1990 by Morgan Kaufmann Publishers, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means-electronic, mechanical, recording, or otherwise—without the prior permission of the publisher. 10 AM MOS All instruction sets and other design information of the DLX computer system contained herein is copyrighted by the publisher and may not be incorporated in other publications or distributed by media without formal acknowledgement and written consent from the publisher. Use of the DLX in other publications for educational purposes is encouraged and application for permission is welcomed. ADVICE, PRAISE, & ERRORS: Any correspondence related to this publication or intended for the authors should be addressed to the editorial offices of Morgan Kaufmann Publishers, Inc., Dept. P&H APE. Information regarding error sightings is encouraged. Any error sightings that are accepted for correction in subsequent printings will be rewarded by the authors with a payment of $1.00 (U.S.) per correction. Electronic mail can be sent to bugs@vsop.stanford.edu. INSTRUCTOR SUPPORT: For information on classroom software and other instructor materials available to adopters, please contact the editorial offices of Morgan Kaufmann Publishers, Inc. 5.5 Microprogrammed Control 214 stalls. A stall is where an instruction must pause one or more clock cycles waiting for some resource to be available. In this chapter stalls occur only when waiting for memory; in the next chapter we'll see other reasons for stalls. Many machines approach this problem by having the hardware stall a microinstruction that tries to access the memory-data register before the memory operation is completed. (This can be accomplished by freezing the microinstruction address so that the same microinstruction is executed until the condition is met.) The instant the memory reference is ready, the microinstruction that needs the data is allowed to complete, avoiding the extra clock delay to access control memory. Reducing CPI by Parallelism Sometimes CPI can be reduced with more operations per microinstruction. This technique, which usually requires a wider microinstruction, increases parallelism with more datapath operations. It is another characteristic of machines labeled horizontal. Examples of this performance gain can be seen in the fact that the fastest models of each family in Figure 5.8 also have the widest microin- structions. Making the microinstruction wider does not guarantee increased performance, however. An example where the potential gain was not realized is found in a microprocessor very similar to the 8086, except that another bus was added to the datapath, requiring six more bits in its microinstruction. This could have reduced the execution phase from three clock cycles to two for many popular 8086 instructions. Unfortunately, these popular macroinstructions were grouped with macroinstructions that couldn't take advantage of this optimization, so they all had to run at the slower rate. . 5.6 Interrupts and Other Entanglements Control is the hard part of processor design, and the hard part of control is interrupts—events other than branches that change the normal flow of instruction execution. Detecting interrupt conditions within an instruction can often be on the critical timing path of a machine, possibly affecting the clock cycle time, and thus performance. Without proper attention to interrupts during design, adding interrupts to a complicated implementation can even foul up the works so as to make the design impracticable. Invented to detect arithmetic errors and signal real-time events, interrupts have been handed a flock of difficult duties. Here are 11 examples: I/O device request Invoking an operating system service from a user program Tracing instruction execution Basic Processor Implementation Techniques 215 ck cycles only when ls. re stall a e memory -zing the Huntil the rady, the - the extra Breakpoint (programmer-requested interrupt) Arithmetic overflow or underflow Page fault (not in main memory) Misaligned memory accesses (if alignment is required) Memory-protection violation Using an undefined instruction Hardware malfunctions Power failure I/O device request ction. This arallelism nes labeled ct that the t microin- increased realized is er bus was This could for many tions were ce of this Invoking the operat- ing system service from a user program Tracing instruction execution Breakpoint NA Arithmetic overflow or underflow IBM 360 VAX Motorola 680x0 Intel 80x86 Input/output Device interrupt Exception (Level Vectored interrupt interruption 0...7 autovector) Supervisor call Exception (change Exception Interrupt interruption mode supervisor trap)| (unimplemented (INT instruction) instruction on Macintosh | ΝΑ Exception (trace Exception (trace) Interrupt (single-step fault) trap) Exception Exception (illegal Interrupt (breakpoint (breakpoint fault) instruction or trap) breakpoint) Program interruption Exception (integer Exception Interrupt (overflow (overflow or overflow trap or (floating-point trap or math unit underflow exception) floating underflow coprocessor errors) exception) fault) NA (only in 370) Exception Exception (memory- | Interrupt (translation not valid management unit (page fault) fault) errors | Program interruption NA Exception NA (specification (address error) exception) Program interruption | Exception (access Exception Interrupt (protection (protection control violation (bus error) exception) exception) fault) Program interruption Exception (opcode Exception (illegal | Interrupt (invalid (operation exception) privileged/ instruction or break- opcode) reserved fault) point/unimplemented instruction) Machine-check Exception (machine Exception NA interruption check abort) (bus error) Machine-check Urgent interrupt NA Nonmaskable interruption interrupt Page fault (not in main memory) Misaligned memory accesses Memory protection violations control is al flow of ruction can ? the clock ipts during foul up the Using undefined instructions interrupts Hardware malfunctions Power failure FIGURE 5.9 Names of 11 interrupt classes on four computers. Every event on the IBM 360 and 80x86 is called an interrupt, while every event on the 680x0 is called an exception. VAX divides events into interrupts or exceptions. Adjectives device, software, and urgent are used with VAX interrupts, while VAX exceptions are subdivided into faults, traps, and aborts. Gulbe 6:18-cv-00294-ADA Document 43-7 Filed 08/12/19 Page 7 of 8 216 5.6 Interrupts and Other Entanglements The enlarged responsibility of interrupts has led to the confusing situati each computer vendor inventing a different term for the same event, as F 5.9 on page 215 illustrates. Intel and IBM still call such events interrupts Motorola calls them exceptions; and, depending on the circumstances, DEC them exceptions, faults, aborts, traps, or interrupts. To give some idea of often interrupts occur, Figure 5.10 shows the frequency on the VAX 8800. Event Time between events I/O interrupt 2.7 ms Interval timer interrupt 10.0 ms Software interrupt 1.5 ms Any interrupt 0.9 ms Any hardware interrupt 2.1 ms FIGURE 5.10 Frequency of different interrupts on the VAX 8800 running a mult workload on the VMS timesharing system. Real-time operating systems used in embedded controllers may have a higher interrupt rate than a general-purpose timesh system. (Collected by Clark, Bannon, and Keller [1988].) Clearly, there is no consistent convention for naming these events. R than imposing one, then, let's review the reasons for the different names. events can be characterized on five independent axes: 1. Synchronous versus asynchronous. If the event occurs at the same every time the program is executed with the same data and me allocation, the event is synchronous. With the exception of hard malfunctions, asynchronous events are caused by devices external to processor and memory. 2. User request versus coerced. If the user task directly asks for it, it is a request event. 3. User maskable versus user nonmaskable. If it can be masked or disabled user task, the event is user maskable. 4. Within versus between instructions. This classification depends on wł the event prevents instruction completion by occurring in the midd execution--no matter how short—or whether it is recognized bet instructions. 5. Resume versus terminate. If the program's execution stops after the rupt, it is a terminating event. DOR Basic Processor Implementation Techniques 217 ing situation of event, as Figure interrupts, but nces, DEC calls me idea of how AX 8800. The difficult task is implementing interrupts occurring within instructions where the instruction must be resumed. Another program must be invoked to collect the state of the program, correct the cause of an interrupt, and then restore the state of the program before an instruction can be tried again. Figure 5.11 classifies the examples from Figure 5.9 according to these five categories. events Synchronous vs. asynchronous User request vs. coerced User maskable vs. nonmaskable Within vs. between instructions Resume vs. terminate I/O device request Asynchronous Coerced Nonmaskable Between Resume Synchronous User request Nonmaskable Between Resume Invoking operating system service Tracing instruction execution User request User maskable Between Resume Breakpoint User request User maskable Between Resume Synchronous Synchronous Synchronous Synchronous Coerced User maskable Within Terminate aning a multiuser is used in spose timesharing Integer arithmetic overflow Floating-point arithmetic overflow or underflow Coerced User maskable Within Resume Coerced Resume Page fault Misaligned memory accesses Synchronous Synchronous Coerced Terminate e events. Rather rent names. The Memory-protection violations Synchronous Coerced Terminate Nonmaskable User maskable Nonmaskable Nonmaskable Nonmaskable Nonmaskable Within Within Within Within Within Within Using undefined instructions Synchronous Terminate Hardware malfunctions Asynchronous Coerced Coerced Coerced Terminate Power failure Asynchronous Terminate the same place ta and memory on of hardware external to the FIGURE 5.11 The events of Figure 5.9 classified using five categories. or it, it is a user- How Control Checks for Interrupts or disabled by a inds on whether i the middle of nized between Integrating interrupts with control means modifying the finite-state diagram to check for interrupts. Interrupts that occur between instructions are checked either at the beginning of the finite-state diagram_before an instruction is decoded—or at the end-after the execution of an instruction is completed. Interrupts that can occur within an instruction are generally detected in the state that causes the action or in a state that follows it. For example, Figure 5.12 shows Figure 5.4 (page 207) modified to check for interrupts. We assume DLX transfers the return address into a new programmer-visible register, the interrupt return-address register. Control then loads PC with the address of the interrupt routine for that interrupt. after the inter-