CS 152 Computer Architecture and Engineering Lecture 9 Multiprogramming and Exceptions February 25, 2004 John Kubiatowicz (www.cs.berkeley.edu/~kubitron)

Slides:



Advertisements
Similar presentations
ELEN 350 Multi-Cycle Datapath Adapted from the lecture notes of John Kubiatowicz (UCB) and Hank Walker (TAMU)
Advertisements

361 multicontroller.1 ECE 361 Computer Architecture Lecture 11: Designing a Multiple Cycle Controller.
EECC550 - Shaaban #1 Lec # 5 Winter Major CPU Design Steps 1. Analyze instruction set operations using independent RTN ISA => RTN => datapath.
CS152 / Kubiatowicz Lec11.1 3/05/03©UCB Spring 2003 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design March 5, 2003.
CS152 / Kubiatowicz Lec10.1 3/1/99©UCB Spring 1999 Alternative datapath (book): Multiple Cycle Datapath °Miminizes Hardware: 1 memory, 1 adder Ideal Memory.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent ISA => RTN => datapath requirements.
Savio Chau Single Cycle Controller Design Last Time: Discussed the Designing of a Single Cycle Datapath Control Datapath Memory Processor (CPU) Input Output.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
Adapted from the lecture notes of John Kubiatowicz (UCB)
ECE 232 L15.Miulticycle.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 15 Multi-cycle.
Pipeline Exceptions & ControlCSCE430/830 Pipeline: Exceptions & Control CSCE430/830 Computer Architecture Lecturer: Prof. Hong Jiang Courtesy of Yifeng.
CS152 / Kubiatowicz Lec9.1 2/26/03©UCB Spring 2003 CS 152 Computer Architecture and Engineering Lecture 9 Designing a Multicycle Processor February 26,
Preparation for Midterm Binary Data Storage (integer, char, float pt) and Operations, Logic, Flip Flops, Switch Debouncing, Timing, Synchronous / Asynchronous.
ECE 232 L13. Control.1 ©UCB, DAP’ 97 ECE 232 Hardware Organization and Design Lecture 13 Control Design
ECE 232 L16.Microprog.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 16 Microprogrammed.
CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 CS 152 Computer Architecture and Engineering Lecture 10 Multicycle Controller Design (Continued) October.
CS 61C L17 Control (1) A Carle, Summer 2006 © UCB inst.eecs.berkeley.edu/~cs61c/su06 CS61C : Machine Structures Lecture #17: CPU Design II – Control
CS152 Lec11.1 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design (Continued)
CS61C L26 CPU Design : Designing a Single-Cycle CPU II (1) Garcia, Fall 2006 © UCB Lecturer SOE Dan Garcia inst.eecs.berkeley.edu/~cs61c.
361 control Computer Architecture Lecture 9: Designing Single Cycle Control.
EECC550 - Shaaban #1 Lec # 5 Winter Major CPU Design Steps 1. Analyze instruction set operations using independent RTN ISA => RTN => datapath.
Class 9.1 Computer Architecture - HUJI Computer Architecture Class 9 Microprogramming.
EECC550 - Shaaban #1 Lec # 6 Winter Control may be designed using one of several initial representations. The choice of sequence control,
CS152 / Kubiatowicz Lec /05/01©UCB Fall 2001 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design October 5, 2001.
EECC550 - Shaaban #1 Lec # 6 Spring Control may be designed using one of several initial representations. The choice of sequence control,
EECC550 - Shaaban #1 Lec # 5 Spring CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
CPSC 321 Computer Architecture and Engineering Lecture 8 Designing a Multicycle Processor Instructor: Rabi Mahapatra & Hank Walker Adapted from the lecture.
Major CPU Design Steps 1. Analyze instruction set operations using independent RTN ISA => RTN => datapath requirements. This provides the the required.
EECC550 - Shaaban #1 Lec # 5 Spring CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
CASE STUDY OF A MULTYCYCLE DATAPATH. Alternative Multiple Cycle Datapath (In Textbook) Minimizes Hardware: 1 memory, 1 ALU Ideal Memory Din Address 32.
CPE 442 µprog..1 Intro. To Computer Architecture CpE 442 Microprogramming and Exceptions.
CS/EE 362 multicontroller..1 ©DAP & SIK 1995 CS/EE 362 Hardware Fundamentals Lecture 15: Designing a Multi-Cycle Controller (Chapter 5: Hennessy and Patterson)
ECS154B Computer Architecture Multicycle Controller Design
CS 152 L09 Multicycle (1)Patterson Fall 2003 © UCB CS152 – Computer Architecture and Engineering Lecture 9 – Multicycle Design Dave Patterson.
CPE232 Basic MIPS Architecture1 Computer Organization Multi-cycle Approach Dr. Iyad Jafar Adapted from Dr. Gheith Abandah slides
EEM 486: Computer Architecture Designing a Single Cycle Datapath.
Exam 2 Review Two’s Complement Arithmetic Ripple carry ALU logic and performance Look-ahead techniques Basic multiplication and division ( non- restoring)
CPE 442 single-cycle datapath.1 Intro. To Computer Architecture CpE242 Computer Architecture and Engineering Designing a Single Cycle Datapath.
CS152 Lec12.1 CS 152 Computer Architecture and Engineering Lecture 12 Multicycle Controller Design Exceptions.
Overview of Control Hardware Development
EEM 486: Computer Architecture Lecture 3 Designing Single Cycle Control.
Single Cycle Controller Design
CDA 3101 Spring 2016 Introduction to Computer Organization Microprogramming and Exceptions 08 March 2016.
Chapter 4 From: Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
Design a MIPS Processor (II)
Problem with Single Cycle Processor Design
CS 152: Computer Architecture and Engineering Lecture 11 Multicycle Controller Design Exceptions Randy H. Katz, Instructor Satrajit Chatterjee, Teaching.
IT 251 Computer Organization and Architecture
Designing a Multicycle Processor
Designing a Multicycle Processor
CS/COE0447 Computer Organization & Assembly Language
CS 704 Advanced Computer Architecture
CS 704 Advanced Computer Architecture
The Multicycle Implementation
John Lazzaro ( CS152 – Computer Architecture and Engineering Lecture 8 – Multicycle Design and Microcode John.
The Multicycle Implementation
Systems Architecture I
CpE 442 Microprogramming and Exceptions
COMS 361 Computer Organization
Multi-Cycle Datapath Lecture notes from MKP, H. H. Lee and S. Yalamanchili.
Instructors: Randy H. Katz David A. Patterson
Systems Architecture I
Alternative datapath (book): Multiple Cycle Datapath
Control Implementation Alternatives For Multi-Cycle CPUs
COMS 361 Computer Organization
What You Will Learn In Next Few Sets of Lectures
Processor: Datapath and Control
CS161 – Design and Architecture of Computer Systems
Presentation transcript:

CS 152 Computer Architecture and Engineering Lecture 9 Multiprogramming and Exceptions February 25, 2004 John Kubiatowicz ( lecture slides:

CS152 / Kubiatowicz Lec9.2 2/25/04©UCB Spring 2004 The Big Picture: Where are We Now? °The Five Classic Components of a Computer °Today’s Topics: Microprogramed control Administrivia; Courses Microprogram it yourself Exceptions Intro to Pipelining (if time permits) Control Datapath Memory Processor Input Output

CS152 / Kubiatowicz Lec9.3 2/25/04©UCB Spring 2004 Review: Multicycle Datapath °Critical Path ? PC Next PC Operand Fetch Instruction Fetch nPC_sel IR Reg File Ext ALU Reg. File Mem Acces s Data Mem Result Store RegDst RegWr MemWr MemRd S M MemToReg Equal ALUctr ALUSrc ExtOp A B E

CS152 / Kubiatowicz Lec9.4 2/25/04©UCB Spring 2004 Review: Control Specification as State Machine IR <= MEM[PC] R-type A <= R[rs] B <= R[rt] S <= A fun B R[rd] <= S PC <= PC + 4 S <= A or ZX R[rt] <= S PC <= PC + 4 ORi S <= A + SX R[rt] <= M PC <= PC + 4 M <= MEM[S] LW S <= A + SX MEM[S] <= B PC <= PC + 4 BEQ PC <= Next(PC,Equal) SW “instruction fetch” “decode / operand fetch” Execute Memory Write-back

CS152 / Kubiatowicz Lec9.5 2/25/04©UCB Spring 2004 Review: Performance Evaluation °What is the average CPI? state diagram gives CPI for each instruction type workload gives frequency of each type TypeCPI i for typeFrequency CPI i x freqI i Arith/Logic440%1.6 Load530%1.5 Store410%0.4 branch320%0.6 Average CPI:4.1

CS152 / Kubiatowicz Lec9.6 2/25/04©UCB Spring 2004 Review: Micro-Controller Design °The state digrams that arise define the controller for an instruction set processor are highly structured °Use this structure to construct a simple “microsequencer” °Control reduces to programming this very simple device  microprogramming sequencer control datapath control micro-PC sequencer microinstruction

CS152 / Kubiatowicz Lec9.7 2/25/04©UCB Spring 2004 Example: Jump-Counter op-code Map ROM Counter zero inc load 0000 i i+1 i None of above: Do nothing (for wait states) “Zero”“Increment”“Load”

CS152 / Kubiatowicz Lec9.8 2/25/04©UCB Spring 2004 Using a Jump Counter IR <= MEM[PC] R-type A <= R[rs] B <= R[rt] S <= A fun B R[rd] <= S PC <= PC + 4 S <= A or ZX R[rt] <= S PC <= PC + 4 ORi S <= A + SX R[rt] <= M PC <= PC + 4 M <= MEM[S] LW S <= A + SX MEM[S] <= B PC <= PC + 4 BEQ PC <= Next(PC) SW “instruction fetch” “decode” inc load zero inc Execute Memory Write-back

CS152 / Kubiatowicz Lec9.9 2/25/04©UCB Spring 2004 Our Microsequencer op-code Map ROM Micro-PC Z I L datapath control Equal

CS152 / Kubiatowicz Lec9.10 2/25/04©UCB Spring 2004 Microprogram Control Specification: Logic? ROM? 0000xinc1 0001xload zero zero xinc0 1 fun xzero xinc0 0 or xzero xinc1 0 add xinc xzero xinc1 0 add xzero µPC EqualNext IRPCOpsExecMemWrite-Back en selA B Ex Sr ALU S R W MM-R Wr Dst R: ORi: LW: SW: BEQ: InputsOutputs

CS152 / Kubiatowicz Lec9.11 2/25/04©UCB Spring 2004 Alternative multicycle datapath (book) °Miminizes Hardware: 1 memory, 1 adder Ideal Memory WrAdr Din RAdr 32 Dout MemWr 32 ALU 32 ALUOp ALU Control 32 IRWr Instruction Reg 32 Reg File Ra Rw busW Rb busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux PC MemtoReg Extend ExtOp Mux Imm 32 << 2 ALUSelB Mux Equal Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

CS152 / Kubiatowicz Lec9.12 2/25/04©UCB Spring 2004 New Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” Execute Memory Write-back BEQ If A = B then PC <= ALUout ALUout <= PC +SX Q: How improve to do something in state 0001?

CS152 / Kubiatowicz Lec9.13 2/25/04©UCB Spring 2004 Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

CS152 / Kubiatowicz Lec9.14 2/25/04©UCB Spring 2004 sequencer control micro-PC  -sequencer: fetch,dispatch, sequential Dispatch ROM Opcode Inputs Microprogramming °Microprogramming is a fundamental concept implement an instruction set by building a very simple processor and interpreting the instructions essential for very complex instructions and when few register transfers are possible overkill when ISA matches datapath 1-1  -Code ROM To DataPath Decode datapath control microinstruction (  )

CS152 / Kubiatowicz Lec9.15 2/25/04©UCB Spring 2004 Microprogramming °Microprogramming is a convenient method for implementing structured control state diagrams: Random logic replaced by microPC sequencer and ROM Each line of ROM called a  instruction: contains sequencer control + values for control points limited state transitions: branch to zero, next sequential, branch to  instruction address from displatch ROM °Horizontal  Code: one control bit in  Instruction for every control line in datapath °Vertical  Code: groups of control-lines coded together in  Instruction (e.g. possible ALU dest) °Control design reduces to Microprogramming Part of the design process is to develop a “language” that describes control and is easy for humans to understand

CS152 / Kubiatowicz Lec9.16 2/25/04©UCB Spring 2004 “Macroinstruction” Interpretation Main Memory execution unit control memory CPU ADD SUB AND DATA User program plus Data this can change! AND microsequence e.g., Fetch Calc Operand Addr Fetch Operand(s) Calculate Save Answer(s) one of these is mapped into one of these

CS152 / Kubiatowicz Lec9.17 2/25/04©UCB Spring 2004 Administrivia °Lab 3 design document to go over in section preliminary design document to TA by 9pm tonight final version to TA by midnight Thursday Sections back in normal rooms This is a complicated lab – may need to give updates as we get the boards installed °Change to Lab specification Your ChipScope should be set up to trigger on a PC entered from board switches (8-switches  10-bit PC) °Homework quiz still next Wednesday Homework is shorter this time Make sure to check on assigned problems °Midterm I, Wednesday March 10 th (Two Weeks) 5:30 - 8:30 in 306 Soda Hall Bring a Calculator! One 8 1/2 by 11 page (both sides) of notes Make up exam?

CS152 / Kubiatowicz Lec9.18 2/25/04©UCB Spring 2004 Review: Testing: Make sure that things work °Testing methodologies Understand what correct behavior is when you design things -Collect vectors for later use Build monitor modules to check assertions of correct values Produce a regression test -Set of tests to run each time something changes °Types of test (Doug Clark): Directed Vectors – test explicit behavior Random Vectors – apply random values or orderings to device Daemons – continuous error insertion °Monitor modules: Check to see if invariants are maintained during long running simulations Alewife Numbers

CS152 / Kubiatowicz Lec9.19 2/25/04©UCB Spring 2004 module monitorsum32(carry,sum,A,B ); input [31:0] A,B; output [31:0] sum; output carry; reg [31:0] predsum; reg precarry; // The “real” adder sum32 mysum (carry,sum,A,B); `ifndef synthesis // This checker code only for simulation or B) begin #100 //wait for output to settle (don’t make too long!) {predcarry,predsum} = A + B; if ((carry != predcarry) || (sum != predsum)) $display(“>>> Mismatch: 0x%x+0x%x->0x%x carry %x”, A,B,sum,carry); end `endif endmodule Review: Monitor Modules: Passthrough testing

CS152 / Kubiatowicz Lec9.20 2/25/04©UCB Spring 2004 Lab3 version: monitors and benches °Important design idea: Set up your processor so that you can take the same design and both simulate and push it to board °Testing Ideas: wrap testing infrastructure around devices under test (DUT) Include test vectors that are supposed to detect errors in implementation. Even strange ones… Can (and probably should in later labs) include assert statements to check for “things that should never happen” Test Bench Device Under Test Inline vectors Assert Statements File IO (either for patterns or output diagnostics) Inline Monitor Output in readable format (disassembly) Assert Statements Complete Top-Level Design

CS152 / Kubiatowicz Lec9.21 2/25/04©UCB Spring 2004 Designing a Microinstruction Set 1) Start with list of control signals 2) Group signals together that make sense (vs. random): called “fields” 3) Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4) To minimize the width, encode operations that will never be used at the same time 5) Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals Use computers to design computers

CS152 / Kubiatowicz Lec9.22 2/25/04©UCB Spring 2004 Recap: Multicycle datapath (book)

CS152 / Kubiatowicz Lec9.23 2/25/04©UCB Spring 2004 Step 1  Start with List of control signals Signal nameEffect when deassertedEffect when asserted ALUSelA1st ALU operand = PC1st ALU operand = Reg[rs] RegWriteNoneReg. is written MemtoRegReg. write data input = ALUReg. write data input = memory RegDstReg. dest. no. = rtReg. dest. no. = rd MemReadNoneMemory at address is read, MDR <= Mem[addr] MemWriteNoneMemory at address is written IorDMemory address = PCMemory address = S IRWriteNoneIR <= Memory PCWriteNonePC <= PCSource PCWriteCond NoneIF ALUzero then PC <= PCSource PCSource PCSource = ALU PCSource = ALUout ExtOpZero ExtendedSign Extended Single Bit Control Signal nameValueEffect ALUOp00ALU adds 01ALU subtracts 10ALU does function code 11ALU does logical OR ALUSelB002nd ALU input = 4 012nd ALU input = Reg[rt] 102nd ALU input = extended,shift left 2 112nd ALU input = extended Multiple Bit Control

CS152 / Kubiatowicz Lec9.24 2/25/04©UCB Spring 2004 Step 2  Group together related signals ALU SRC1 SRC2 Destination Memory PCWrite

CS152 / Kubiatowicz Lec9.25 2/25/04©UCB Spring &4) Microinstruction Format: unencoded vs. encoded fields Field NameWidthControl Signals Set wide narrow ALU Control42ALUOp SRC121ALUSelA SRC253ALUSelB, ExtOp ALU Destination32RegWrite, MemtoReg, RegDst Memory32MemRead, MemWrite, IorD Memory Register11IRWrite PCWrite Control32PCWrite, PCWriteCond, PCSource Sequencing32AddrCtl Total width2415bits

CS152 / Kubiatowicz Lec9.26 2/25/04©UCB Spring 2004 Step 5  Group into Fields, Order and Assign Names Field NameValues for FieldFunction of Field with Specific Value ALUAddALU adds Subt. ALU subtracts FuncALU does function code OrALU does logical OR SRC1PC1st ALU input <= PC rs1st ALU input <= Reg[rs] SRC242nd ALU input <= 4 Extend2nd ALU input <= sign ext. IR[15-0] Extend02nd ALU input <= zero ext. IR[15-0] Extshft2nd ALU input <= sign ex., sl IR[15-0] rt2nd ALU input <= Reg[rt] dest(ination)rd ALUReg[rd] <= ALUout rt ALUReg[rt] <= ALUout rt Mem Reg[rt] <= Mem Mem(ory)Read PCRead memory using PC Read ALURead memory using ALUout for addr Write ALUWrite memory using ALUout for addr MemregIRIR <= Mem PCwritePCwrPC <= PCSource PCSrc IF Zero then PCSource <= ALUout else ALU PCWrCond I F Zero then PC <= PCSource Seq(uencing)SeqGo to next sequential µinstruction FetchGo to the first microinstruction DispatchDispatch using ROM. ALUSRC 1 SRC 2 DestMemMemregPCwriteSeq

CS152 / Kubiatowicz Lec9.27 2/25/04©UCB Spring 2004 Quick check: what do these fieldnames mean? CodeNameRegWriteMemToRegRegDest XX 01rd ALU101 10rt ALU100 11rt MEM110 CodeNameALUSelBExtOp XX X 010rt01X 011ExtShft Extend Extend0110 Destination: SRC2:

CS152 / Kubiatowicz Lec9.28 2/25/04©UCB Spring 2004 Specific Sequencer for our Microcoding Sequencer-based control unit from last lecture Called “microPC” or “µPC” vs. state register Code NameEffect 00 fetchNext µaddress = 0 01dispatchNext µaddress = dispatch ROM 10 seqNext µaddress = µaddress + 1 ROM: Opcode microPC 1 µAddress Select Logic Adder ROM Mux Opcode: Dispatch state :Rtype (0100)  :BEQ (0010)  :ORI (0110)  :LW (1000)  :SW(1011) 

CS152 / Kubiatowicz Lec9.29 2/25/04©UCB Spring 2004 Recap: Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

CS152 / Kubiatowicz Lec9.30 2/25/04©UCB Spring 2004 Microprogram it yourself! AddrALU SRC1SRC2Dest.MemoryMem. Reg. PC Write Sequencing Fetch: 0000:AddPC4Read PCIRALUSeq Decode: 0001:AddPCExtshftDispatch BEQ: 0010:Subt.rsrt ALUoutCond.Fetch Rtype: 0100:FuncrsrtSeq 0101:rd ALUFetch ORI: 0110:Orrs Extend0 Seq 0111:rt ALUFetch LW: 1000:AddrsExtend Seq 1001:Read ALU Seq 1010: rt MEM Fetch SW: 1011:AddrsExtendSeq 1100:Write ALUFetch

CS152 / Kubiatowicz Lec9.31 2/25/04©UCB Spring 2004 Overview of Control °Control may be designed using one of several initial representations. The choice of sequence control, and how logic is represented, can then be determined independently; the control can then be implemented with one of several methods using a structured logic technique. Initial Representation Finite State Diagram Microprogram Sequencing ControlExplicit Next State Microprogram counter Function + Dispatch ROMs Logic RepresentationLogic EquationsTruth Tables Implementation PLAROM Technique “hardwired control”“microprogrammed control”

CS152 / Kubiatowicz Lec9.32 2/25/04©UCB Spring 2004 Exceptions °Exception = unprogrammed control transfer system takes action to handle the exception -must record the address of the offending instruction -record any other information necessary to return afterwards returns control to user must save & restore user state °Allows constuction of a “user virtual machine” normal control flow: sequential, jumps, branches, calls, returns user program System Exception Handler Exception: return from exception

CS152 / Kubiatowicz Lec9.33 2/25/04©UCB Spring 2004 Two Types of Exceptions: Interrupts and Traps °Interrupts caused by external events: -Network, Keyboard, Disk I/O, Timer asynchronous to program execution -Most interrupts can be disabled for brief periods of time -Some (like “Power Failing”) are non-maskable (NMI) may be handled between instructions simply suspend and resume user program °Traps caused by internal events -exceptional conditions (overflow) -errors (parity) -faults (non-resident page) synchronous to program execution condition must be remedied by the handler instruction may be retried or simulated and program continued or program may be aborted

CS152 / Kubiatowicz Lec9.34 2/25/04©UCB Spring 2004 Precise Exceptions °Precise  state of the machine is preserved as if program executed up to the offending instruction All previous instructions completed Offending instruction and all following instructions act as if they have not even started Same system code will work on different implementations Position clearly established by IBM Difficult in the presence of pipelining, out-ot-order execution,... MIPS takes this position °Imprecise  system software has to figure out what is where and put it all back together °Performance goals often lead designers to forsake precise interrupts system software developers, user, markets etc. usually wish they had not done this °Modern techniques for out-of-order execution and branch prediction help implement precise interrupts

CS152 / Kubiatowicz Lec9.35 2/25/04©UCB Spring 2004 Summary °Microprogramming is a fundamental concept implement an instruction set by building a very simple processor and interpreting the instructions essential for very complex instructions and when few register transfers are possible Control design reduces to Microprogramming °Design of a Microprogramming language 1.Start with list of control signals 2.Group signals together that make sense (vs. random): called “fields” 3.Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4.To minimize the width, encode operations that will never be used at the same time 5.Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals °Sophisticated microcontrollers lead to complete micro- machine language! Branches, jumps, etc Old MIT course: many levels: Machine language, Microcode, nanocode