What does it mean (to decode) in the execution cycle

In a typical instruction cycle, fetching, decoding, executing together form one cycle. My question is about the decoding step: What is the part that gets decoded, is it the instruction's opcode? If so, why it is encoded then?

In fact, I understand decoding here in similar way as what you decode a message given a key in the field of security, which is what confuses me a bit.

Solution 1:

Decode means to parse the instruction to determine its meaning.

A typical instruction consists of an opcode and (usually) one or more arguments. These arguments may refer to specific registers or memory addresses or can be immediate values to be used directly during execution. In addition, some instructions may have prefixes (such as LOCK in x86) or function codes (such as the funct field for some MIPS instructions) that alter their functionality.

During decoding, the processor needs to:

• determine what instruction is represented by the opcode so that the instruction can be issued to the correct execution unit and that the correct operation is performed
• correctly interpret the arguments, prefixes, and other values attached to the instruction and pass the relevant information to the relevant circuitry
• (in most modern processor designs) break the instruction down into its corresponding micro-operations

With modern processors, this can be a complex operation that requires multiple stages in the pipeline. To speed this process up, a dedicated cache may be used to store micro-operations for frequently-executed instructions.

For more on the techniques used to deliver high performance in modern processors, you might want to read this answer.

Solution 2:

Assembly instructions, besides an opcode, often have bit fields that indicate registers and addressing modes (absolute, relative, auto-increment and more).

Decoding is the cycle that interprets the opcode and those other bitfields to determine what the instruction will operate on, or otherwise do.

Summary: it figures out the optional details of an instruction

Example: 0x90 ( 10010000 binary ) is usually considered a NOP, no operation, for the 8086 instruction set.

But there is a XCHG instruction, represented as binary 10010reg (reg=3 bits), (0x90 + reg) that is an 16 bit exchange register with AX instruction. the 3 bits denoted 'reg' define what register to exchange with.

'reg' of binary 000, means 'with register AX'. So 0x90 decodes as "exchange AX with AX", which doesn't do much, AKA No Operation NOP

Solution 3:

Instructions and adressing modes are what is decoded. Instructions + addressing modes consist of an opcode and any immediate data (operands) following the opcode.

If so, why it is encoded then?

Because we are using values in RAM to "stand for" instructions and addressing modes. A scheme has to exist whereby X = whatever instruction + whatever addressing mode. Similar to how ASCII/Unicode is a scheme that "stands for" numbers, letters, and terminal control codes.

The decode step would not be necessary if you had a machine that had 1 switch for each possible instruction. The "RAM equivalent" of this would be 1 instruction per bit in an 8-bit (or other) byte, and if multiple bits were on, all instructions (and yes you would be limited to 8 of them) would "fire" at that step. I believe PDP assembly from the late 60's/early 70's isn't too far from this.

In fact, I understand decoding here in similar way as what you decode a message given a key in the field of security, which is what confuses me a bit.

No, it's more like decoding MPEG data into raw video data - the raw MPEG data can't be painted on the screen directly, it has to be processed and "unpacked" to find out what it means exactly.