What is decoded instruction form?
I'm reading What Every Computer Scientist Should Know About Memory by Ulrich Drapper.
In section 6.2.2 it states:
[...] instructions must be decoded before they can be executed and to speed this up (important on x86 and x86-64), instructions are actually cached in decoded form, not in byte / word form read from memory.
What does the author mean for the "decoded" form for the instruction? Don't the instructions mean what they mean by themselves? "Add" is "add", for example ...
What would be the representation of its "decoded" form? Why should they cache it? Wouldn't it be deterministic? Does it take time to "decode" an instruction in the pipeline, and why?
source to share
Modern Intel processors actually implement many instructions using what is called microcode . Microcode consists of code written in a simpler low-level instruction set used to implement high-level instructions (for example, the rep
-prefixed command can be implemented as microcode). Since this actually requires the processor to "compile" your input stream to microcode itself, you can imagine that this particular microcode is cached (to avoid the overhead of compiling it many times).
Of course, the exact details of caching "decoded" instructions vary greatly by processor, so there is no general statement.
source to share
What you think of as a single instruction actually corresponds to (potentially) a whole set of different circuits on a processor. "Decoded" means the machine code is being read and there is now some metadata or processor state that picks the correct scheme. Caching is more efficient than code caching.
For example, a load instruction might use one implementation for offset-addressing and a completely different scheme for immediate addressing ...
source to share
This is not the decoding step you see in the classic RISC pipeline. In modern x86 processors, instructions go through several stages of decoding before finally moving to the stage of generating control signals. They are "pre-encoded" (identify command boundaries), decoded into μops, then buffered, cached, and queued until they finally reach the "RISC-like core" where they are scheduled and placed in backup stations, and only after they finally reach ALU (if applicable). On most of this route, they probably have not yet been decoded in the classic RISC sense, "turned into actual control signals" which would make them too wide to reasonably put 1.5K of them in L1C. Anyway, these microcircuitsgenerated by the front end are a set of "RISC-like kernel" instructions, they are not true microcode in the old-fashioned sense of a state machine that generates a bunch of control signals in sequence. It's comparable though.
As for what μops actually looks like, it's very difficult to get specifics. Some conclusions can be drawn from the number of μops (and the ports they go to) generated by the instructions, the table is found here . For example, read and write and read-modify-write instructions are broken up. Some instructions generate a huge number of ICs, such as floating point transceivers, which makes these instructions look more like built-in functions that are likely implemented on top of other instructions. Instructions that do variable work will also generate a variable μops, for example rep movs
. So μops looks like RISC instructions, but we already knew that.
source to share
The three stages that the central processor always performs:
-
fetch (instruction from memory);
-
decode (instruction is your question);
-
execute (enable electrical signal in COU depending on decoding stage).
Decoding an instruction means that the "decoder" of the CPU (which is a hardware component inside the CPU) decodes the binary instruction and decides how to handle the electrical signal (instruction) based on the instruction.
In other words: the instruction is converted into signals that control other parts of the CPU.
source to share