Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
2  
Don't confuse Encoding/Decoding with Encrypting/Decrypting. – user1008646 Mar 22 at 9:38
up vote 3 down vote accepted

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.

share|improve this answer

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

share|improve this answer
1  
You forgot a zero; 0x90 is 1001 0000 in binary. – Egon Olieux Mar 22 at 1:44
    
Your tldr; section is in the wrong place. It should be on the top, so peolpe just read it. Currently, you have it thrown somewhere in the middle, defeating the purpose of it. – Ismael Miguel Mar 22 at 9:15
    
@IsmaelMiguel: Is the purpose of 'tldr' in a seven sentence answer better served at the top? I fear you're writing it exclusively for no one at all. – Marcks Thomas Mar 22 at 11:49
    
Sometimes tldr is used to signify a summary. Yes, that's not what it literally meant when the phrase came into vogue. its a casual usage, not formal. Originally that tldr was the end of the answer, then I decided add an example – infixed Mar 22 at 12:16
    
@MarcksThomas The tldr; is a very very short form for those who don't want to read the whole content. Usually on the top. The sumary is where you get to a conclusion. They are not the same and aren't interchangable. I didn't edit it myself because it is a very minor edit. If infixed didn't wanted to change it, he wouldn't be forced. If he wanted to keep it there, it would be fine but an edit would be less useful and would probably be rolled back (in my opinion) – Ismael Miguel Mar 22 at 13:43

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.

share|improve this answer
    
Thank you for your response :) – Steve Mar 22 at 0:43

The opcode is just a number, packing n different possibilites in an enumeration. Besides separating out the operation code proper from the addressing modes and options, you really decode this operation id into a bunch of control bits that have actual meaning in the implementation hardware. Modern cpus are even more complex, expanding one assembly instruction possibly into several micro-ops.

You can find videos on youtube for building a cpu "from scratch".

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .