DOCSLIB.ORG

ECA-STUDENT-NOTES.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ECA-STUDENT-NOTES.Pdf Essentials Of Computer Architecture Prof. Douglas Comer Computer Science And ECE Purdue University http://www.cs.purdue.edu/people/comer Copyright 2017 by Douglas Comer. All rights reserved Module I Course Introduction And Overview Computer Architecture ± Module 1 1 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved The Big Questions d Most CS programs require an architecture course, but you might ask: Is knowledge of computer organization and the underlying hardware relevant these days? Should we take this course seriously? Computer Architecture ± Module 1 2 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved The Answers d Companies (such as Google, IBM, Microsoft, Apple, Cisco,...) look for knowledge of architecture when hiring (i.e., understanding computer architecture can help you land a job) d The most successful software engineers understand the underlying hardware (i.e., knowing about architecture can help you earn promotions) d As a practical matter: knowledge of computer architecture is needed for later courses, such as systems programming, compilers, operating systems, and embedded systems Computer Architecture ± Module 1 3 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved A Word About Future Employment d Traditional software engineering jobs are saturated d The future lies in embedded systems ± Cell phones ± Video games ± MP3 players ± Set-top boxes ± Smart sensor systems d Understanding architecture is key for programming embedded systems Computer Architecture ± Module 1 4 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Some Bad News About Architecture d Hardware is ugly ± Lots of low-level details ± Can be counterintuitive d Hardware is tricky ± Timing is important ± A small addition in functionality can require many pieces of hardware d The subject is so large that we cannot hope to cover it in one course d You will need to think in new ways Computer Architecture ± Module 1 5 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Some Good News About Architecture d You will learn to think in new ways d It is possible to understand basics without knowing all low-level technical details d Programmers only need to learn the essentials ± Characteristics of major components ± Role in overall system ± Consequences for software Computer Architecture ± Module 1 6 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved The Four Main Topics d Basics of digital hardware ± You will build a few simple circuits d Processors ± You will program RISC and CISC processors in lab d Memories ± You will learn about memory organization and caching d I/O operates ± You will explore buffering and learn about interrupts Computer Architecture ± Module 1 7 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Organization Of The Course d Basics ± A taste of digital logic ± Data paths and execution ± Data representations d Processors ± Instruction sets and operands ± Assembly languages and programming d Memories ± Physical and virtual memories ± Addressing and caching Computer Architecture ± Module 1 8 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Organization Of The Course (continued) d Input/Output ± Devices and interfaces ± Buses and bus address spaces ± Role of device drivers d Advanced topics ± Parallelism and data pipelining ± Power and energy ± Performance and performance assessment ± Architectural hierarchies Computer Architecture ± Module 1 9 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved What We Will Not Cover d The course emphasizes breadth over depth d Omissions ± Most low-level details (e.g., discussion of electrical properties of resistance, voltage, current and semiconductor physics) ± Quantitative analysis that engineers use to design hardware circuits ± Design rules that specify how logic gates may be interconnected ± Circuit design and design tools ± VLSI chip design and languages such as Verilog Computer Architecture ± Module 1 10 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Terminology Used With Digital Systems d Three key ideas ± Architecture ± Design ± Implementation Computer Architecture ± Module 1 11 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Architecture d Refers to the overall organization of a computer system d Analogous to a blueprint d Speci®es ± Functionality of major components ± Interconnections among components d Abstracts away details Computer Architecture ± Module 1 12 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Design d Needed before a digital system can be built d Translates architecture into components d Fills in details that the architectural speci®cation omits d Speci®es items such as ± How components are grouped onto boards ± How power is distributed to boards d Many designs can satisfy a given architecture Computer Architecture ± Module 1 13 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Implementation d All details necessary to build a system d Includes ± Speci®c part numbers to be used ± Mechanical speci®cations of chassis and cases ± Layout of components on boards ± Power supplies and power distribution ± Signal wiring and connectors Computer Architecture ± Module 1 14 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Summary d Architecture is required because understanding computer organization leads to programming excellence d This course covers the four essential aspects of computer architecture ± Digital logic ± Processors ± Memory ± I / O d You will have fun with hardware in the lab Computer Architecture ± Module 1 15 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Module II Fundamentals Of Digital Logic Computer Architecture ± Module 2 1 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Our Goals d Understand the basics ± Concepts ± How computers work at the lowest level d Avoid whenever possible ± Device physics ± Engineering design rules ± Implementation details Computer Architecture ± Module 2 2 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Electrical Terminology d Voltage ± Quanti®able property of electricity ± Measure of potential force ± Unit of measure: volt d Current ± Quanti®able property of electricity ± Measure of electron ¯ow along a path ± Unit of measure: ampere (amp) Computer Architecture ± Module 2 3 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Analogy d Voltage is analogous to water pressure d Current is analogous to ¯owing water d Can have ± High pressure with little ¯ow ± Large ¯ow with little pressure Computer Architecture ± Module 2 4 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Measuring Voltage d Device used is called voltmeter d Note: can only be measured as difference between two points d We will ± Assume one point represents zero volts (known as ground) ± Express voltage of second point with respect to ground Computer Architecture ± Module 2 5 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved In Practice d In lab, chips will operate on ®ve volts d Two wires connect each chip to power supply ± Ground (zero volts) ± Power (®ve volts) d Every chip needs power and ground connections d Notes ± Logic diagrams do not show power and ground ± Raspberry Pi operates on 3.3 volts, so conversion is required to connect the Pi to other chips Computer Architecture ± Module 2 6 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Transistor d Basic building block of electronic circuits d Operates on electrical current d Traditional transistor ± Has three external connections * Emitter * Base (control) * Collector ± Acts like an amplifier Ð a small current between base and emitter controls large current between collector and emitter Computer Architecture ± Module 2 7 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Illustration Of A Traditional Transistor C large current flows B from point C to point E small current flows from point B to E E d Amplification means the large output current varies exactly like the small input current Computer Architecture ± Module 2 8 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Field Effect Transistor d Called a Metal Oxide Semiconductor FET (MOSFET) when used on a CMOS chip d Three external connections ± Source ± Gate ± Drain d Designed to act as a switch (on or off) ± When the input reaches a threshold (i.e., becomes logic 1), the transistor turns on and passes full current ± When the input falls below a threshold (i.e., becomes logic 0), the transistor turns off and passes no current Computer Architecture ± Module 2 9 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Illustration Of A Field Effect Transistor (Used For Switching) source gate turns on current flowing from point S to point D non-zero current flowing from point G to D drain d Input arrives at the gate d Logic zero (zero volts) means the transistor is off; logic 1 (positive voltage) turns the transistor on Computer Architecture ± Module 2 10 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Alternative Field Effect Transistor (Also Used For Switching) source gate turns on current flowing from point S to point D no current flowing from point G to D drain d Circle on the gate indicates an inversion d Logic 0 (zero volts) turns the transistor on, and logic 1 (positive voltage) turns the transistor off Computer Architecture ± Module 2 11 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Boolean Logic d Mathematical basis for digital circuits d Three basic functions: and, or, and not A B A and B A B A or B A not A 0 0 0 0 0 0 0 1 0 1 0 0 1 1 1 0 1 0 0 1 0 1 1 1 1 1 1 1 Computer Architecture ± Module 2 12 Fall, 2016 Copyright 2016 by Douglas Comer. All rights reserved Digital Logic d Can implement Boolean functions with transistors d Five volts represents Boolean 1 (true) d Zero volts represents Boolean 0 (false) Computer Architecture ± Module 2 13 Fall, 2016 Copyright 2016 by Douglas Comer.
Load more

Recommended publications
  • Pdp11-40.Pdf
    processor handbook digital equipment corporation Copyright© 1972, by Digital Equipment Corporation DEC, PDP, UNIBUS are registered trademarks of Digital Equipment Corporation. ii TABLE OF CONTENTS CHAPTER 1 INTRODUCTION 1·1 1.1 GENERAL ............................................. 1·1 1.2 GENERAL CHARACTERISTICS . 1·2 1.2.1 The UNIBUS ..... 1·2 1.2.2 Central Processor 1·3 1.2.3 Memories ........... 1·5 1.2.4 Floating Point ... 1·5 1.2.5 Memory Management .............................. .. 1·5 1.3 PERIPHERALS/OPTIONS ......................................... 1·5 1.3.1 1/0 Devices .......... .................................. 1·6 1.3.2 Storage Devices ...................................... .. 1·6 1.3.3 Bus Options .............................................. 1·6 1.4 SOFTWARE ..... .... ........................................... ............. 1·6 1.4.1 Paper Tape Software .......................................... 1·7 1.4.2 Disk Operating System Software ........................ 1·7 1.4.3 Higher Level Languages ................................... .. 1·7 1.5 NUMBER SYSTEMS ..................................... 1-7 CHAPTER 2 SYSTEM ARCHITECTURE. 2-1 2.1 SYSTEM DEFINITION .............. 2·1 2.2 UNIBUS ......................................... 2-1 2.2.1 Bidirectional Lines ...... 2-1 2.2.2 Master-Slave Relation .. 2-2 2.2.3 Interlocked Communication 2-2 2.3 CENTRAL PROCESSOR .......... 2-2 2.3.1 General Registers ... 2-3 2.3.2 Processor Status Word ....... 2-4 2.3.3 Stack Limit Register 2-5 2.4 EXTENDED INSTRUCTION SET & FLOATING POINT .. 2-5 2.5 CORE MEMORY . .... 2-6 2.6 AUTOMATIC PRIORITY INTERRUPTS .... 2-7 2.6.1 Using the Interrupts . 2-9 2.6.2 Interrupt Procedure 2-9 2.6.3 Interrupt Servicing ............ .. 2-10 2.7 PROCESSOR TRAPS ............ 2-10 2.7.1 Power Failure ..............
    [Show full text]
  • Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences
    Downloaded from orbit.dtu.dk on: Oct 02, 2021 Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Hindborg, Andreas Erik; Schleuniger, Pascal; Jensen, Nicklas Bo; Karlsson, Sven Published in: Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) Publication date: 2014 Link back to DTU Orbit Citation (APA): Hindborg, A. E., Schleuniger, P., Jensen, N. B., & Karlsson, S. (2014). Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences. In A. Morawiec, & J. Hinderscheit (Eds.), Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) IEEE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Andreas Erik Hindborg, Pascal Schleuniger Nicklas Bo Jensen, Sven Karlsson DTU Compute – Technical University of Denmark fahin,pass,nboa,[email protected] Abstract—Field-programmable gate arrays, FPGAs, are at- speedup of up to 64% over a Xilinx MicroBlaze based baseline tractive implementation platforms for low-volume signal and system.
    [Show full text]
  • PDP-11 Handbook
    alMml digihl equipmentcorpomtion Copyright 1969 by Digital Equipment Corporation PDP is a registered trademark of Digital Equipment, Corporation The material in this handbook is for information pur- poses only and is subject to change without notice. TABLE OF CONTENTS CHAPIER 1 lNTRODUCTlOR PDP-11 SYSTEMS . .:.. 1 UNIBUS . , . 1 KAl 1 PROCESSOR . .?. 1 Priority Interrupts ,...............,..... 1 Reentrant Code . General Registers . :... 2 Instruction Set . .._........................................................ Addressing . ..~...............................................~........,...,......... z Asynchronous Operation . L 2 PACKAGJNG . ..I . 2 SOmARE ........................ .: ........................................................ 3 CHAPTER 2 SYSTEM INTRODUCTION SYSTEM DEFINITION .................................................................. 5 SYSTEM COMPONENTS ............................................................... 5 UNIBUS ................................................... .................................. 5 Single Bus ................................................................. .......... 5 Bidirectional Lines ............ .......................................... ..* .... 5 Master-Slave Relation ........................... .............................. 5 Interlocked .Communication ................................................ Dynamic Master-Slave Relation ........................................... : KAll CENTRAL PROCESSOR ...................................................... 6 General Registers
    [Show full text]
  • Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation
    12 Bringing Virtualization to the x86 Architecture with the Original VMware Workstation EDOUARD BUGNION, Stanford University SCOTT DEVINE, VMware Inc. MENDEL ROSENBLUM, Stanford University JEREMY SUGERMAN, Talaria Technologies, Inc. EDWARD Y. WANG, Cumulus Networks, Inc. This article describes the historical context, technical challenges, and main implementation techniques used by VMware Workstation to bring virtualization to the x86 architecture in 1999. Although virtual machine monitors (VMMs) had been around for decades, they were traditionally designed as part of monolithic, single-vendor architectures with explicit support for virtualization. In contrast, the x86 architecture lacked virtualization support, and the industry around it had disaggregated into an ecosystem, with different ven- dors controlling the computers, CPUs, peripherals, operating systems, and applications, none of them asking for virtualization. We chose to build our solution independently of these vendors. As a result, VMware Workstation had to deal with new challenges associated with (i) the lack of virtual- ization support in the x86 architecture, (ii) the daunting complexity of the architecture itself, (iii) the need to support a broad combination of peripherals, and (iv) the need to offer a simple user experience within existing environments. These new challenges led us to a novel combination of well-known virtualization techniques, techniques from other domains, and new techniques. VMware Workstation combined a hosted architecture with a VMM. The hosted architecture enabled a simple user experience and offered broad hardware compatibility. Rather than exposing I/O diversity to the virtual machines, VMware Workstation also relied on software emulation of I/O devices. The VMM combined a trap-and-emulate direct execution engine with a system-level dynamic binary translator to ef- ficiently virtualize the x86 architecture and support most commodity operating systems.
    [Show full text]
  • Static Fault Attack on Hardware DES Registers
    Static Fault Attack on Hardware DES Registers Philippe Loubet-Moundi, Francis Olivier, and David Vigilant Gemalto, Security Labs, France {philippe.loubet-moundi,david.vigilant,francis.olivier}@gemalto.com http://www.gemalto.com Abstract. In the late nineties, Eli Biham and Adi Shamir published the first paper on Differential Fault Analysis on symmetric key algorithms. More specifically they introduced a fault model where a key bit located in non-volatile memory is forced to 0=1 with a fault injection. In their scenario the fault was permanent, and could lead the attacker to full key recovery with low complexity. In this paper, another fault model is considered: forcing a key bit to 0=1 in the register of a hardware block implementing Data Encryption Stan- dard. Due to the specific location of the fault, the key modification is not permanent in the life of the embedded device, and this leads to apply a powerful safe-error like attack. This paper reports a practical validation of the fault model on two actual circuits, and discusses limitations and efficient countermeasures against this threat. Keywords: Hardware DES, fault attacks, safe-error, register attacks 1 Introduction Fault attacks against embedded systems exploit the disturbed execution of a given program to infer sensitive data, or to execute unauthorized parts of this program. Usually a distinction is made between permanent faults and transient faults.A permanent fault alters the behavior of the device from the moment it is injected, and even if the device is powered off [8]. On the other hand, a transient fault has an effect limited in time, only a few cycles of the process are affected.
    [Show full text]
  • Validating Register Allocation and Spilling
    Validating Register Allocation and Spilling Silvain Rideau1 and Xavier Leroy2 1 Ecole´ Normale Sup´erieure,45 rue d'Ulm, 75005 Paris, France [email protected] 2 INRIA Paris-Rocquencourt, BP 105, 78153 Le Chesnay, France [email protected] Abstract. Following the translation validation approach to high- assurance compilation, we describe a new algorithm for validating a posteriori the results of a run of register allocation. The algorithm is based on backward dataflow inference of equations between variables, registers and stack locations, and can cope with sophisticated forms of spilling and live range splitting, as well as many architectural irregular- ities such as overlapping registers. The soundness of the algorithm was mechanically proved using the Coq proof assistant. 1 Introduction To generate fast and compact machine code, it is crucial to make effective use of the limited number of registers provided by hardware architectures. Register allocation and its accompanying code transformations (spilling, reloading, coa- lescing, live range splitting, rematerialization, etc) therefore play a prominent role in optimizing compilers. As in the case of any advanced compiler pass, mistakes sometimes happen in the design or implementation of register allocators, possibly causing incorrect machine code to be generated from a correct source program. Such compiler- introduced bugs are uncommon but especially difficult to exhibit and track down. In the context of safety-critical software, they can also invalidate all the safety guarantees obtained by formal verification of the source code, which is a growing concern in the formal methods world. There exist two major approaches to rule out incorrect compilations. Com- piler verification proves, once and for all, the correctness of a compiler or compi- lation pass, preferably using mechanical assistance (proof assistants) to conduct the proof.
    [Show full text]
  • V810 Familytm 32-Bit Microprocessor
    V810 FAMILYTM 32-BIT MICROPROCESSOR ARCHITECTURE V805TM V810TM V820TM V821TM Document No. U10082EJ1V0UM00 (1st edition) Date Published October 1995P © 11995 Printed in Japan NOTES FOR CMOS DEVICES 1 PRECAUTION AGAINST ESD FOR SEMICONDUCTORS Note: Strong electric field, when exposed to a MOS device, can cause destruction of the gate oxide and ultimately degrade the device operation. Steps must be taken to stop generation of static electricity as much as possible, and quickly dissipate it once it has occurred. Environmental control must be adequate. When it is dry, humidifier should be used. It is recommended to avoid using insulators that easily build static electricity. Semiconductor devices must be stored and transported in an anti- static container, static shielding bag or conductive material. All test and measurement tools including work bench and floor should be grounded. The operator should be grounded using wrist strap. Semiconductor devices must not be touched with bare hands. Similar precautions need to be taken for PW boards with semiconductor devices on it. 2 HANDLING OF UNUSED INPUT PINS FOR CMOS Note: No connection for CMOS device inputs can be cause of malfunction. If no connection is provided to the input pins, it is possible that an internal input level may be generated due to noise, etc., hence causing malfunction. CMOS devices behave differently than Bipolar or NMOS devices. Input levels of CMOS devices must be fixed high or low by using a pull-up or pull-down circuitry. Each unused pin should be connected to VDD or GND with a resistor, if it is considered to have a possibility of being an output pin.
    [Show full text]
  • Main Memory Organisation – Learning Objectives
    17/10/2011 Main Memory Organisation – Learning Objectives" !# At the end of this lecture you will:" !# Understand the main concepts of memory organisation" Main Memory Organisation !# Know the different memory hardware options" " !# Registers, cache, RAM, Disk" !# Understand the relationship between cost and speed of access" !# Understand byte ordering in words" !# Understand the concept of addressing" Eddie Edwards" !# Understand word and byte addressing" [email protected]" !# Understand how RAM memory is organised into chips and modules" " !# Comprehend high order and low order interleaving and their uses" http://www.doc.ic.ac.uk/~eedwards/compsys" Computer Systems – Architecture E Edwards Main Memory Organisation (2.1) ! Computer Systems – Architecture E Edwards Main Memory Organisation (2.2) ! Question" Memories" !# Memories hold binary values. These can be:! !# Do you have a laptop or internet device here?" ! A yes B no C what$s a laptop D where is here? " Data (e.g. Integers, Reals, Characters)%" ! E none of the above" CPU Instructions (i.e. Computer Programs)! ! Memory Addresses (“Pointers” to data or instructions)%" " "" !# The contents of a memory remain unchanged unless overwritten with a new binary value. For some memories the contents are "lost" when power to the memory is turned off.! ! " Computer Systems – Architecture E Edwards Main Memory Organisation (2.3) ! Computer Systems – Architecture E Edwards Main Memory Organisation (2.4) ! 1 17/10/2011 Examples" CPU Organisation" !# CPU " Registers! " CPU Main Memory Caches
    [Show full text]
  • Register Allocation Deconstructed
    Register Allocation Deconstructed David Ryan Koes Seth Copen Goldstein Carnegie Mellon University Carnegie Mellon University Pittsburgh, PA Pittsburgh, PA [email protected] [email protected] Abstract assignment. The coalescing component of register allocation Register allocation is a fundamental part of any optimiz- attempts to eliminate existing move instructions by allocat- ing compiler. Effectively managing the limited register re- ing the operands of the move instruction to identical loca- sources of the constrained architectures commonly found in tions. The spilling component attempts to minimize the im- embedded systems is essential in order to maximize code pact of accessing variables in memory. The move insertion quality. In this paper we deconstruct the register allocation component attempts to insert move instructions, splitting the problem into distinct components: coalescing, spilling, move live ranges of variables, with the goal of achieving a net im- insertion, and assignment. Using an optimal register alloca- provement in code quality by improving the results of the tion framework, we empirically evaluate the importance of other components. The assignment component assigns those each of the components, the impact of component integra- program variables that aren’t in memory to specific hard- tion, and the effectiveness of existing heuristics. We evalu- ware registers. Existing register allocators take different ap- ate code quality both in terms of code performance and code proaches in solving these various components. For example, size and consider four distinct instruction set architectures: the central focus of a graph-coloring based register allocator ARM, Thumb, x86, and x86-64. The results of our investiga- is to solve the assignment problem, while the spilling and tion reveal general principles for register allocation design.
    [Show full text]
  • Machine Instructions and Programs
    Hamacher-38086 book June 28, 2001 11:31 CHAPTER 2 MACHINE INSTRUCTIONS AND PROGRAMS CHAPTER OBJECTIVES In this chapter you will learn about: • Machine instructions and program execution, including branching and subroutine call and return operations • Number representation and addition/subtraction in the 2’s-complement system • Addressing methods for accessing register and memory operands • Assembly language for representing machine instructions, data, and programs • Program-controlled Input/Output operations • Operations on stack, queue, list, linked-list, and array data structures 25 Hamacher-38086 book June 28, 2001 11:31 26 CHAPTER 2 • MACHINE INSTRUCTIONS AND PROGRAMS This chapter considers the way programs are executed in a computer from the ma- chine instruction set viewpoint. Chapter 1 introduced the general concept that both program instructions and data operands are stored in the memory. In this chapter, we study the ways in which sequences of instructions are brought from the memory into the processor and executed to perform a given task. The addressing methods com- monly used for accessing operands in memory locations and processor registers are presented. The emphasis here is on basic concepts. We use a generic style to describe ma- chine instructions and operand addressing methods that are typical of those found in commercial processors. A sufficient number of instructions and addressing methods are introduced to enable us to present complete, realistic programs for simple tasks. These generic programs are specified at the assembly language level. In assembly lan- guage, machine instructions and operand addressing information are represented by symbolic names. A complete instruction set is often referred to as the instruction set architecture (ISA) of a processor.
    [Show full text]
  • Instruction Set Architecture
    UNIT - 5 Instruction Set Architecture Lesson Structure 5.0 Objective 5.1 Introduction 5.2 Instruction Set Characteristics 5.3 Instruction Set Design Considerations 5.3.1 Operand Data Types 5.3.2 Types of Instructions 5.3.3 Number of Addresses in an Instruction 5.4 Addressing Schemes 5.4.1 Types of Addressing Schemes 5.4.1.1 Implicit Addressing 5.4.1.2 Immediate Addressing 5.4.1.3 Direct Addressing 5.4.1.4 Indirect Addressing 5.4.1.5 Register Addressing 5.4.1.6 Register Indirect Addressing 5.4.1.7 Indexed Addressing 5.4.1.8 Base Addressing 5.4.1.9 Register Relative Addressing 5.4.1.10 Relative Based Indexed Addressing 5.4.1.11 Stack Addressing Instruction Set Architecture 5.5 Instruction Set and Format Design Issues 5.5.1 Instruction Length 5.5.2 Allocation of Bits Among Opcode and Operand 5.5.3 Variable Length of Instructions 5.6 Example of Instruction Format 5.7 Summary 5.8 Questions for Exercise 5.9 Suggested Readings 5.0 Objectives After going through this unit we should be able to: define instruction set and the characteristics of instruction set; describe the element of an instruction and differentiate various types of operands; distinguish between types of instructions and operations performed by the instructions; differentiate types of instructions set on the basis of addresses in instruction sets; identity various addressing schemes and discuss instruction format design issues. 5.1 Introduction The internal organization of a digital system is defined by the registers it employs and the sequence of micro-operations it performs on data stated in the registers.
    [Show full text]
  • Using and Porting the GNU Compiler Collection
    Using and Porting the GNU Compiler Collection Richard M. Stallman Last updated 28 July 1999 for gcc-2.95 Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998, 1999 Free Software Foundation, Inc. For GCC Version 2.95 Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307, USA Last printed April, 1998. Printed copies are available for $50 each. ISBN 1-882114-37-X Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the sections entitled \GNU General Public License" and \Funding for Free Software" are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that the sections entitled \GNU General Public License" and \Funding for Free Software", and this permission no- tice, may be included in translations approved by the Free Software Foundation instead of in the original English. Chapter 1: Compile C, C++, Objective C, or Fortran 1 1 Compile C, C++, Objective C, or Fortran The C, C++, and Objective C, and Fortran versions of the compiler are integrated; this is why we use the name \GNU Compiler Collection". GCC can compile programs written in C, C++, Objective C, or Fortran.
    [Show full text]