Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Horizontal and Vertical Microcode - Computer Architecture - Notes | CPSC 5155G, Study notes of Computer Architecture and Organization

Material Type: Notes; Professor: Bosworth; Class: Computer Architecture; Subject: Computer Science; University: Columbus State University; Term: Unknown 1989;

Typology: Study notes

Pre 2010

Uploaded on 08/04/2009

koofers-user-sgi
koofers-user-sgi 🇺🇸

10 documents

1 / 24

Toggle sidebar

Related documents


Partial preview of the text

Download Horizontal and Vertical Microcode - Computer Architecture - Notes | CPSC 5155G and more Study notes Computer Architecture and Organization in PDF only on Docsity! Horizontal vs. Vertical Micro–Code The micro–programming strategy called “horizontal microcode” allows one bit in the micro–memory for each control signal generated. We have illustrated this with a small memory to issue control signals for bus B1. There are five control signals associated with this bus, so this part of the micro–memory would comprise five–bit numbers. A quick count from the table of control signals shows that there are thirty–four discrete control signals associated with this control unit. A full horizontal implementation of the microcode would thus require 34 bits in each micro–word just to issue the control signals. The memory width is not a big issue; indeed there are commercial computers with much wider micro–memories. We just note the width requirement. In vertical microcoding, each signal is assigned a numeric code that is unique for its function. Thus, each of the five signals for control of bus B1 would be assigned a numeric code. The following table illustrates the codes actually used in the design of the Boz–5. Code Signal 000 001 PC  B1 010 MAR  B1 011 R  B1 100 IR  B1 101 SP  B1 It is particularly important that a vertical microcoding scheme allow for the option that no signal is being placed on the bus. In this design we reserve the code 0 for “nothing on bus” or “ALU does nothing”, etc. The three bits in this design are placed into a 3–to–8 decoder, as shown in the figure below. Admittedly, this design is slower than the horizontal microcode in that it incurs the time penalty associated with the decoder. Figure: Sample of Vertical Microcoding In this revised example, word 105 generates MAR  B1 and word 106 generates R  B1. One advantage of encoding the control signals is the unique definition of the signal for each function. As an example, consider both the horizontal and vertical encodings for bus B1. In the five–bit horizontal encoding, we were required to have at most one 1 per micro–word. An examination of that figure will show that the micro–word “10100” would assert the two control signals PC  B1 and R  B1 simultaneously, causing considerable difficulties. In the vertical microcoding example, the three–bit micro–word with contents “011” causes the control signal R  B1, and only that control signal, to be asserted. To be repetitive, the code “000” is reserved for not specifying any source for bus B1; in which case the contents of the bus are not specified. In such a case, the ALU cannot accept input from bus B1. The design chosen for the microcode will be based on the fact that four of the CPU units (bus B1, bus B2, bus B3, and the ALU) can each have only one “function”. For this reason, the control signals for these units will be encoded. There are seven additional control signals that could be asserted in any combination. These signals will be represented in horizontal microcode, with one bit for each signal. Structure of the Boz–5 Microcode As indicated above, the Boz–5 microcode will be a mix of horizontal and vertical microcode. The reader will note that some of the encoded fields require 3–bit codes and some require 4–bit codes. For uniformity of notation we shall require that each field be encoded in 4 bits. The requirement that each field be encoded by a 4–bit binary number has no justification in engineering practice. Rather it is a convenience to the student, designed to remove at least one minor nuisance from the tedium of writing binary microcode and converting it to hex. Consider the following example, taken from the common fetch sequence. MBR  B2, tra2, B3  IR. A minimal–width encoding of this sequence of control signals would yield the following. 0 000 110 100 010 000 0000 0000 0000 0000 0000. Conversion of this to hexadecimal requires regrouping the bits and then rewriting. 0000 1101 0001 0000 0000 0000 0000 0000 0000 or 0x0 D100 0000 The four–bit constant width coding of this sequence yields the following. 0000 0000 0110 0100 0010 0000 0000 0000 0000 0000 0000 This is immediately converted to 0x006 4200 0000 without shuffling any bits. Dispatching the Microcode In addition to micro–words that cause control signals to be emitted, we need micro–words to sequence the execution of the microcode. This is seen most obviously in the requirement for a dispatch based on the assembly language op–code. Let’s begin with an observation that is immediately obvious. If the microprogrammed control unit is to handle each distinct assembly language opcode differently, it must have sections of microprogram that are unique to each of the assembly language instructions. The solution to this will be a dispatch microoperation, one which invokes a section of the microprogram that is selected based on the 5–bit opcode that is currently in the Instruction Register. But what is called and how does it return? At this point in the design of the microprogrammed control unit, we have two distinct types of microoperations: a type that issues control signals and a type that dispatches based on the assembly language opcode. To handle this distinction, we introduce the idea of a micro– opcode with the following values at present. Micro–Op Function 0000 Issue control signals 0001 Dispatch based on the assembly language opcode. We have stated that there are conditions under which the dispatch will not be taken. There is only one condition that will not be dispatched: the assembly–language opcode is 0x0F and the branch condition is not met. Before we consider how to handle this situation, we must first address another design issue, that presented by indirect addressing. Handling Defer Consider the control signals for the LDR (Load Register) assembly language instruction. LDR Op-Code = 01100 (Hexadecimal 0x0C) F, T0: PC  B1, tra1, B3  MAR, READ. // MAR  (PC) F, T1: PC  B1, 1  B2, add, B3  PC. // PC  (PC) + 1 F, T2: MBR  B2, tra2, B3  IR. // IR  (MBR) F, T3: IR  B1, R  B2, add, B3  MAR. // Do the indexing. Here the major state register takes control. 1) If the I–bit (bit 26) is 1, then the Defer state is entered. 2) If the I–bit is 0, then the E state is entered. D, T0: READ. // Address is already in the MAR. D, T1: WAIT. // Cannot access the MBR just now. D, T2: MBR  B2, tra2, B3  MAR. // MAR  (MBR) D, T3: WAIT. Here the transition is automatic from the D state to the E state. E, T0: READ. // Again, address is already in the MAR. E, T1: WAIT. E, T2: MBR  B2, tra2, B3  R. E, T3: WAIT. The issue here is that we no longer have an explicit major state register to handle the sequencing of major states. The microprogram itself must handle the sequencing; it must do something different for each of the two possibilities: indirect addressing is used and indirect addressing is not used. Assuming a dispatch to address 0x0C for LDR (as it will be done in the final design), the current design calls for the following microinstruction at that address. Address Control Signals Next address 0x0C IR  B1, R  B2, add, B3  MAR. Depends on IR26. Suddenly we need two “next addresses”, one if the defer phase is to be entered and one to be used if that phase is not to be entered. This last observation determines the final form of the microprogram; each micro–word has length 44 bits with structure as shown below. In this representation of the microprogram words, we use “D = 0” to indicate that the defer phase is not to be entered and “D = 1” to indicate that it should be entered. This notation will be made more precise after we explore the new set of signals used to control the sequencing of the microprogram. Here we assume no more than 256 micro–words in the control store. Micro–Op B1 B2 B3 ALU M1 M2 D = 0 D = 1 4 bit 4 bit 4 bit 4 bit 4 bit 4 bit 4 bit 8 bit 8 bit Notes: 1. The width of each field is either four or eight bits. The main reason for this is to facilitate the use of hexadecimal notation in writing the microcode. 2. The use of four bits to encode only two options for the micro–opcode may appear extravagant. This follows our desire for a very regular structure. 3. The use of “D = 0” and “D = 1” is not exactly appropriate for the dispatch instruction with micro–opcode = 0001. We shall explain this later. 4. The bits associated with the M1 field are those specifying the shift parameters Bit 3 L / R (1 for a left shift, 0 for a right shift) Bit 2 A (1 for an arithmetic shift) Bit 1 C (1 for circular shift) Bit 0 Not used 5. The bits associated with the M2 field are Bit 3 READ (Indicates a memory reference) Bit 2 WRITE (Unless READ = 1) Bit 1 extend (Sign–extend contents of IR when copying to B1) Bit 0 0  RUN (Stop the computer) 6. For almost every micro–instruction, the two “next addresses” are identical. For these, we cannot predict the value of the generated control signal “branch” and do not care, since the next address will be independent of that value. 7. The values for next addresses will each be two hexadecimal digits. It is here that we have made the explicit assumption on the maximum size of the micromemory. Sequencing the Boz–5 Microprogrammed Control Unit In addition to the assembly language opcode, we shall need two new signals in order to sequence the microprogrammed control unit correctly. We call these two control signals “S1” and “S2”, because they resemble the control signals S1 and S2 used in the hardwired control unit but are not exactly identical. In the hardwired control unit, the signal S1 was used to determine whether or not the state following Fetch would again be Fetch. This allowed completion of the execution of 14 of the 22 assembly language instructions in the Fetch phase. In the microprogrammed control unit, the signal S1 will be used to determine whether or not the dispatch microinstruction is executed. The only condition under which it is not executed is that in which the assembly language calls for a conditional branch and the branch condition is not met. This leads to a simple statement defining this sequencing signal. S1 = 0 if and only if the assembly language opcode = 0x0F and branch = 0, where branch = 1 if and only if the branch condition is met. The sequencing signal S2 is used to control the entering of the defer code for those instructions that can use indirect addressing. Recall that the assignment of opcodes to the assembly language instructions has been structured so that only instructions beginning with “011” can enter the defer phase. Even these enter the defer phase only when IR26 = 1. Thus, we have the following definition of this signal. S2 = 1 if and only if (IR31 = 0, IR30 = 1, IR29 = 1, and IR26 = 1) In a way, this is exactly the definition of the sequencing control signal S2 as used in the hardwired control unit. The only difference is that in this design the signal S2 must be used independently of the signal S1, so we must use the full definition. The figure below illustrates the circuitry to generate the two sequencing signals S1 and S2. Given these circuits, we have the final form and labeling of the micro–words in the micro– memory. Note that there are no “micro–data” words, only microinstructions. Micro–Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 4 bit 4 bit 4 bit 4 bit 4 bit 4 bit 4 bit 8 bit 8 bit The form of the type 1 instruction is completely defined and can be given as follows. Micro–Op B1 B2 B3 ALU M1 M2 D = 0 D = 1 0001 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x20 But what exactly does this dispatch instruction do? The question becomes one of defining the dispatch table, which is used to determine the address of the microcode that is invoked explicitly by this dispatch. We now address that issue. Assignment of Numeric Codes to Control Signals We now start writing the microcode. This step begins with the assignment of numeric values to the control signals that the control unit emits. The next table shows the numeric codes that this author has elected to assign to the encoded control signals; these being the controls for bus B1, bus B2, bus B3, and the ALU. While the assignment may appear almost random, it does have some logic. The basic rule is that code 0 does nothing. The bus codes have been adjusted to have the greatest commonality; thus code 6 is the code for both MBR  B2 and B3  MBR. Code Bus 1 Bus 2 Bus 3 ALU 0 1 PC  B1 1  B2 B3 PC tra1 2 MAR  B1 – 1 B2 B3  MAR tra2 3 R  B1 R  B2 B3 R shift 4 IR  B1 B3  IR not 5 SP  B1 B3  SP add 6 MBR  B2 B3  MBR sub 7 IOD B2 B3  IOD and 8 B3  IOA or 9 xor 10 Other assignments may be legitimately defended, but this is the one we use. Example: Common Fetch Sequence We begin our discussion of microprogramming by listing the control signals for the first three minor cycles in the Fetch major cycle and translating these to microcode. We shall mention here, and frequently, that the major and minor cycles are present in the microcode only implicitly. It is better to think that major cycles map into sections of microcode. For this example, we do the work explicitly. Location 0x20 F, T0: PC  B1 B1 code is 1 tra1 ALU code is 1 B3  MAR B3 code is 2 READ M2(Bit 3) = 1, so M2 = 8 Micro–Op = 0. B2 code and M1 code are both 0. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x20 0 1 0 2 1 0 8 0x21 0x21 Location 0x21 F, T1: PC  B1 B1 code is 1 1  B2 B2 code is 1 add ALU code is 5 B3  PC. B3 code is 1 Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x21 0 1 1 1 5 0 0 0x22 0x22 Location 0x22 F, T2: MBR  B2 B2 code is 6 tra2 ALU code is 2 B3  IR B3 code is 4 Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x22 0 0 6 4 2 0 0 0x23 0x23 Location 0x23 Dispatch on the op–code in the machine language instruction For this we assume that the Micro–Op is 1 and that none of the other fields are used. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x23 1 0 0 0 0 0 0 0x20 0x20 Here is the microprogram for the common fetch sequence. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x20 0 1 0 2 1 0 8 0x21 0x21 0x21 0 1 1 1 5 0 0 0x22 0x22 0x22 0 0 6 4 2 0 0 0x23 0x23 0x23 1 0 0 0 0 0 0 0x20 0x20 Here is the section of microprogram for the common fetch sequence, written in the form that would be seen in a utility used for debugging the microcode. Address Contents 0x20 0x010 2108 2121 0x21 0x011 1500 2222 0x22 0x006 4200 2323 0x23 0x100 0000 2020 We now have assembled all of the design tricks required to write microcode and have examined some microcode in detail. It is time to finish the microprogramming. The Execution of Op–Codes 0x00 through 0x07 The first four of these machine instructions (0x00 –0x00) use immediate addressing and execute in a single cycle, while the last four (0x04 –0x07) are NOP’s, also executing in a single cycle. The microcode for these goes in addresses 0x00 through 0x07 of the micro–memory. The next step for each of these is Fetch for the next instruction, so the next address for all of them is 0x20. HLT Op-Code = 00000 0  RUN. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x00 0 0 0 0 0 0 1 0x20 0x20 LDI Op-Code = 00001 IR  B1, extend, tra1, B3  R. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x01 0 4 0 3 1 0 2 0x20 0x20 ANDI Op-Code = 00010 IR  B1, R  B2, and, B3  R. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x02 0 4 3 3 7 0 0 0x20 0x20 ADDI Op-Code = 00011 IR  B1, R  B2, extend, add, B3  R. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x03 0 1 3 3 5 0 2 0x20 0x20 We are now in a position to specify the first eight micro–words. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x00 0 0 0 0 0 0 1 0x20 0x20 0x01 0 4 0 3 1 0 2 0x20 0x20 0x02 0 4 3 3 7 0 0 0x20 0x20 0x03 0 1 3 3 5 0 2 0x20 0x20 0x04 0 0 0 0 0 0 0 0x20 0x20 0x05 0 0 0 0 0 0 0 0x20 0x20 0x06 0 0 0 0 0 0 0 0x20 0x20 0x07 0 0 0 0 0 0 0 0x20 0x20 Based on the tables above, we state the contents of the first eight micro–words. Address Contents 0x00 0x 000 0001 2020 0x01 0x 040 3102 2020 0x02 0x 043 3700 2020 0x03 0x 013 3502 2020 0x04 0x 000 0000 2020 0x05 0x 000 0000 2020 0x06 0x 000 0000 2020 0x07 0x 000 0000 2020 GET Op-Code = 01000 (Hexadecimal 0x08) F, T3: WAIT. E, T0: IR  B1, tra1, B3  IOA. // Send out the I/O address E, T1: WAIT. E, T2: IOD  B2, tra2, B3  R. // Get the results. E, T3: WAIT. As noted above, we can ignore any WAIT signal that is not required by considerations of memory timing. The first of two microoperations is associated with the dispatch address for the GET instruction and the second one at the first available micromemory word. IR  B1, tra1, B3  IOA. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x08 0 4 0 8 1 0 0 0x24 0x24 IOD  B2, tra2, B3  R. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x24 0 0 7 7 2 0 0 0x20 0x20 PUT Op-Code = 01001 (Hexadecimal 0x09) F, T3: WAIT. E, T0: R  B2, tra2, B3  IOD // Get the data ready E, T1: WAIT. E, T2: IR  B1, tra1, B3  IOA. // Sending out the address E, T3: WAIT. // causes the output of data. R  B2, tra2, B3  IOD Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x09 0 0 3 7 2 0 0 0x25 0x25 IR  B1, tra1, B3  IOA. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x25 0 4 0 8 1 0 0 0x20 0x20 RET Op-Code = 01010 (Hexadecimal 0x0A) F, T3: WAIT E, T0: SP  B1, – 1  B2, add, B3  SP. // Decrement the SP E, T1: SP  B1, tra1, B3  MAR, READ. // Get the return address E, T2: WAIT. E, T3: MBR  B2, tra2, B3  PC. // Put return address into PC Here we have three non–waiting instructions plus a WAIT that is necessary for the memory access. As a result, we must allocate four micro–memory words to the execution. SP  B1, – 1  B2, add, B3  SP Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x0A 0 5 2 5 5 0 0 0x26 0x26 SP  B1, tra1, B3  MAR, READ. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x26 0 5 0 2 1 0 8 0x27 0x27 WAIT Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x27 0 0 0 0 0 0 0 0x28 0x28 MBR  B2, tra2, B3  PC Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x28 0 0 6 1 2 0 0 0x20 0x20 RTI Op-Code = 01011 (Hexadecimal 0x0B) Not yet implemented. This is encoded as another NOP, until time to develop the details of interrupt handling. The “link” Address Micro-Op B1 B2 B3 ALU M1 M2 B = 0 B = 1 0x0B 0 0 0 0 0 0 0 0x20 0x20 We now turn to the four instructions that use both Defer and Execute. One might be tempted to write a common Defer “subroutine” to be “called” by each of the Execute sections. While this would reduce duplication of micro–code, we opt for in–line coding. In each of the following four instructions, the step corresponding to (F, T3) issues control signals. These will be issued by the “link” micro–operation. We must also introduce a new micro–op to account for conditionally entering or not entering the Defer section. The next four assembly language instructions (LDR, STR, JSR, and BR) are the only that possibly use indirect addressing. As discussed in our presentation of the sequencing control signals for the microprogram, the defer phase will be entered if and only if S2 = 1. The template for the DEFER state is shown below. It has one essential WAIT state. X READ X + 1 WAIT X + 2 MBR  B2, tra2, B3  MAR X + 3 Code for E, T0 Due to this structure, the address for (S2 = = 0) will be 3 more than that for (S2 = = 1). LDR Op-Code = 01100 (Hexadecimal 0x0C) F, T3: IR  B1, R  B2, add, B3  MAR. // Do the indexing. D, T0: READ. // Address is already in the MAR. D, T1: WAIT. // Cannot access the MBR just now. D, T2: MBR  B2, tra2, B3  MAR. // MAR  (MBR) D, T3: WAIT. E, T0: READ. // Again, address is already in the MAR. E, T1: WAIT. E, T2; MBR  B2, tra2, B3  R. E, T3: WAIT. IR  B1, R  B2, add, B3  MAR Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x0C 0 4 3 2 5 0 0 0x2C 0x29 READ Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x29 0 0 0 0 0 0 8 0x2A 0x2A WAIT Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x2A 0 0 0 0 0 0 0 0x2B 0x2B MBR  B2, tra2, B3  MAR Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x2B 0 0 6 2 2 0 0 0x2C 0x2C READ. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x2C 0 0 0 0 0 0 8 0x2D 0x2D WAIT. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x2D 0 0 0 0 0 0 0 0x2E 0x2E MBR  B2, tra2, B3  MAR Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x2E 0 0 6 2 2 0 0 0x20 0x20 BR Op-Code = 01111 (Hexadecimal 0x0F) F, T3: IR  B1, R  B2, add, B3  MAR. // Do the indexing. D, T0: READ. // Address is already in the MAR. D, T1: WAIT. // Cannot access the MBR just now. D, T2: MBR  B2, tra2, B3  MAR. // MAR  (MBR) D, T3: WAIT. E, T0: WAIT. E, T1: WAIT. E, T2: WAIT. E, T3: MAR  B1, tra1, B3  PC. Remember that the microcode at address 0x23 will not dispatch to address 0x0F if the branch condition is not true. This avoids wasted time and incorrect execution. IR  B1, R  B2, add, B3  MAR Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x0F 0 4 3 2 5 0 0 0x3E 0x3B READ Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x3B 0 0 0 0 0 0 8 0x3C 0x3C WAIT Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x3C 0 0 0 0 0 0 0 0x3D 0x3D MBR  B2, tra2, B3  MAR Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x3D 0 0 6 2 2 0 0 0x3E 0x3E MAR  B1, tra1, B3  PC Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x3E 0 2 0 1 1 0 0 0x20 0x20 This completes the derivation of the microprogram for the Boz–5. Here now is the complete microprogram of the Boz–5, shown in two pages of tables. Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x00 0 0 0 0 0 0 1 0x20 0x20 0x01 0 4 0 3 1 0 2 0x20 0x20 0x02 0 4 3 3 7 0 0 0x20 0x20 0x03 0 1 3 3 5 0 2 0x20 0x20 0x04 0 0 0 0 0 0 0 0x20 0x20 0x05 0 0 0 0 0 0 0 0x20 0x20 0x06 0 0 0 0 0 0 0 0x20 0x20 0x07 0 0 0 0 0 0 0 0x20 0x20 0x08 0 4 0 8 1 0 0 0x24 0x24 0x09 0 0 3 7 2 0 0 0x25 0x25 0x0A 0 5 2 5 5 0 0 0x26 0x26 0x0B 0 0 0 0 0 0 0 0x20 0x20 0x0C 0 4 3 2 5 0 0 0x2C 0x29 0x0D 0 4 3 2 5 0 0 0x32 0x2F 0x0E 0 4 3 2 5 0 0 0x37 0x34 0x0F 0 4 3 2 5 0 0 0x3E 0x3B 0x10 0 0 3 3 3 8 0 0x20 0x20 0x11 0 0 3 3 3 9 0 0x20 0x20 0x12 0 0 3 3 3 0 0 0x20 0x20 0x13 0 0 3 3 3 4 0 0x20 0x20 0x14 0 0 3 3 4 0 0 0x20 0x20 0x15 0 3 3 3 5 0 0 0x20 0x20 0x16 0 3 3 3 6 0 0 0x20 0x20 0x17 0 3 3 3 7 0 0 0x20 0x20 0x18 0 3 3 3 8 0 0 0x20 0x20 0x19 0 3 3 3 9 0 0 0x20 0x20 0x1A 0 0 0 0 0 0 0 0x20 0x20 0x1B 0 0 0 0 0 0 0 0x20 0x20 0x1C 0 0 0 0 0 0 0 0x20 0x20 0x1D 0 0 0 0 0 0 0 0x20 0x20 0x1E 0 0 0 0 0 0 0 0x20 0x20 0x1F 0 0 0 0 0 0 0 0x20 0x20 0x20 0 1 0 2 1 0 8 0x21 0x21 0x21 0 1 1 1 5 0 0 0x22 0x22 0x22 0 0 6 4 2 0 0 0x23 0x23 0x23 1 0 0 0 0 0 0 0x00 0x00 Address Micro-Op B1 B2 B3 ALU M1 M2 S2 = 0 S2 = 1 0x24 0 0 7 7 2 0 0 0x20 0x20 0x25 0 4 0 8 1 0 0 0x20 0x20 0x26 0 5 0 2 1 0 8 0x27 0x27 0x27 0 0 0 0 0 0 0 0x28 0x28 0x28 0 0 6 1 2 0 0 0x20 0x20 0x29 0 0 0 0 0 0 8 0x2A 0x2A 0x2A 0 0 0 0 0 0 0 0x2B 0x2B 0x2B 0 0 6 2 2 0 0 0x2C 0x2C 0x2C 0 0 0 0 0 0 8 0x2D 0x2D 0x2D 0 0 0 0 0 0 0 0x2E 0x2E 0x2E 0 0 6 2 2 0 0 0x20 0x20 0x2F 0 0 0 0 0 0 8 0x30 0x30 0x30 0 0 0 0 0 0 0 0x31 0x31 0x31 0 0 6 2 2 0 0 0x32 0x32 0x32 0 3 0 6 1 0 4 0x33 0x33 0x33 0 0 0 0 0 0 0 0x20 0x20 0x34 0 0 0 0 0 0 8 0x35 0x35 0x35 0 0 0 0 0 0 0 0x36 0x36 0x36 0 0 6 2 2 0 0 0x37 0x37 0x37 0 1 0 6 1 0 0 0x38 0x38 0x38 0 2 0 1 1 0 0 0x39 0x39 0x39 0 5 0 2 1 0 0 0x3A 0x3A 0x3A 0 5 1 5 5 0 0 0x20 0x20 0x3B 0 0 0 0 0 0 8 0x3C 0x3C 0x3C 0 0 0 0 0 0 0 0x3D 0x3D 0x3D 0 0 6 2 2 0 0 0x3E 0x3E 0x3E 0 2 0 1 1 0 0 0x20 0x20 The last address is 0x3E = 62 (in decimal). The microprogram has used 63 of the available 256 addresses (it is an 8–bit address) for a 25% usage. With 63 addresses used, we could have opted for a 6–bit address. We chose an 8–bit address for the sake of simplicity. The reader will note that this leaves plenty of unused microprogram space for possible implementation of any new instructions.
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved