patternMinor
What happens at the decode phase of the instruction cycle?
Viewed 0 times
cyclephasethewhatinstructiondecodehappens
Problem
I am reading about the various phases of the Instruction Execution, I found out that we have three phases like below.
Now if the part I don't understand is why do we need a decode phase ? The instruction will already be stored in a binary format at some memory location, why not just fetch and execute it.
- Fectch
- Decode
- Execute
Now if the part I don't understand is why do we need a decode phase ? The instruction will already be stored in a binary format at some memory location, why not just fetch and execute it.
Solution
The name "decoding" is actually a bit misleading because more things take place in this stage. You can view it as a translation from the external, programmer-visible representation of the instruction, to the CPU's internal interpretation.
All CPU architecture have an encoding of instructions, usually involving the specification of a number of op-codes specifying the "action" of the instruction (as opposed to the arguments, which might be registers, memory locations etc.). Note that the op-code is just a number, often just a byte. For instance, the addition instruction might have byte value 0x01, the subtraction might be 0x02 and so on. However, note that the numbering is somewhat arbitrary. It doesn't in itself say what the instruction does - this is something you would have to look up in the instruction manual.
What the decoding stage does is to map these numbers to the actual action of the instruction. This often involves looking up the OP-code in a data-structure, for instance a ROM. You could compare the decode stage to you looking up the op-code in a manual, to see what the instruction actually is. Now, your instruction manual is written in a human-readable language. What is the computer's manual written in? One method used in many implementations is that the ROM maps the op-code to a value which specifies the control signals that must be sent further into the execution pipeline to cause the action that is to be executed. For instance, if the instruction involves looking up the values of registers, adding them, and storing the result in another register, the ROM will contain values for the control signals that commands the register banks into read mode and the ALU into addition mode. The details of what the control signals are, are of course implementation dependent, depending on how the CPU internally functions and what control signals its various internal units accepts. However, the point is that the decode stage maps the representation of the instruction (in the form of op-code) to the actual action, in the form of these control signals. Note that on many architectures, one instruction might actually be decoded into several such "micro-instructions" with each micro-instruction essentially being a long word of all these control signals. This allows the architecture to provide the application programmer with complex instructions with short encoding. This generating and sequencing of micro-instructions might also take place in the decode stage.
Now you could ask, why not just let the instruction op-code contain all these control signals? In that case, the decode stage might not be necessary. Only problem is, that execution of an instruction often involves a lot of control signals, meaning instructions would be very long, just got the op-code. Also, it would expose the internal workings of the CPU since the external representation of instructions would now be deeply tied to the internal workings.
By the way, some architecture have very complicated encoding scheme so here the decoding involves a lot more work than just a lookup in a ROM, but in fact rather complicated logic just to determine the length and the prefixes etc. of the instruction. Also, various tricks might be necessary to keep the ROM at an acceptable size and also to allow fast look-up. On superscalar instructions, it is even possible to do this for several instructions in parallel even for encodings with variable length instructions! So as you can see, decoders can be pretty busy!
All CPU architecture have an encoding of instructions, usually involving the specification of a number of op-codes specifying the "action" of the instruction (as opposed to the arguments, which might be registers, memory locations etc.). Note that the op-code is just a number, often just a byte. For instance, the addition instruction might have byte value 0x01, the subtraction might be 0x02 and so on. However, note that the numbering is somewhat arbitrary. It doesn't in itself say what the instruction does - this is something you would have to look up in the instruction manual.
What the decoding stage does is to map these numbers to the actual action of the instruction. This often involves looking up the OP-code in a data-structure, for instance a ROM. You could compare the decode stage to you looking up the op-code in a manual, to see what the instruction actually is. Now, your instruction manual is written in a human-readable language. What is the computer's manual written in? One method used in many implementations is that the ROM maps the op-code to a value which specifies the control signals that must be sent further into the execution pipeline to cause the action that is to be executed. For instance, if the instruction involves looking up the values of registers, adding them, and storing the result in another register, the ROM will contain values for the control signals that commands the register banks into read mode and the ALU into addition mode. The details of what the control signals are, are of course implementation dependent, depending on how the CPU internally functions and what control signals its various internal units accepts. However, the point is that the decode stage maps the representation of the instruction (in the form of op-code) to the actual action, in the form of these control signals. Note that on many architectures, one instruction might actually be decoded into several such "micro-instructions" with each micro-instruction essentially being a long word of all these control signals. This allows the architecture to provide the application programmer with complex instructions with short encoding. This generating and sequencing of micro-instructions might also take place in the decode stage.
Now you could ask, why not just let the instruction op-code contain all these control signals? In that case, the decode stage might not be necessary. Only problem is, that execution of an instruction often involves a lot of control signals, meaning instructions would be very long, just got the op-code. Also, it would expose the internal workings of the CPU since the external representation of instructions would now be deeply tied to the internal workings.
By the way, some architecture have very complicated encoding scheme so here the decoding involves a lot more work than just a lookup in a ROM, but in fact rather complicated logic just to determine the length and the prefixes etc. of the instruction. Also, various tricks might be necessary to keep the ROM at an acceptable size and also to allow fast look-up. On superscalar instructions, it is even possible to do this for several instructions in parallel even for encodings with variable length instructions! So as you can see, decoders can be pretty busy!
Context
StackExchange Computer Science Q#21895, answer score: 3
Revisions (0)
No revisions yet.