Clarification of some instructions related to LEA and MOV

Question

Why does following occur?

*abbreviating r= register, c = immediate value, byte value

1. lea r, [r+c] ;correct as expected
2. mov r, r+c ;error
3. mov r, r+r ;error
4. mov r, [r+c] ;correct
5. mov r, [r+r] ;correct
6. mov r, [c+c] ;correct
7. mov r, c+c ;correct
8. lea r, [c] equals mov r, c

More info:

line 2 - It is just simple calculation, right? But it can't be compiled. Also, at line 3 same problem. But at lines 4, 5, 6 and 7 MOV instruction does calculations nicely and compiler returns no error. So why does MOV fail at line 2 & 3 considering the fact that instructions at lines 2, 3 simpler than lines 4, 5 because no dereferencing done(in lines 2 and 3)?

line 8 - LEA (Load Effective Address) is supposed to calculate memory address so it should look for the address of where constant "c" stored as defined(reserved) in "section .data" and if we assume, for the sake of the scope of this question, it isn't defined or reserved there, then LEA should give a compilation error. But actually, what happens is it acts identically to MOV in this context. So, I am asking a explanation for the reason behind this strange behaviour of LEA instruction.

*I have read similar questions on "StackOverflow" regarding "difference" between "MOV" and "LEA" but they don't quite answer the situations described in this question.

Answer 1

x86 instructions support operands that can have an addressing mode — because the designers considered them useful enough to merit encoding.

For most instructions, the addressing mode computes an effective address that is used to access memory.  If the effective address involves an addition, the processor does that, uses the effective address, then discards the addition.

For lea, however, the effective address is computed the same (i.e. according to the addressing mode) but rather than being used for a memory access, the effective address itself is the value (put into the target register).  This gives us a way to capture an address computed by an addressing mode that would have been discarded if it were it used in another instruction like mov or add.

1. lea r, [r+c] — there's an addressing mode for [r+c].  Computes r+c and makes that the answer.  No memory access performed.  Syntactically, the addressing mode is meant to appear the same as a memory reference in another instruction, so the []s would be kept despite not being an actual memory reference.

2. mov r, r+c — this is a dynamic calculation because of r but there's no "addressing mode" for r+c.  Have to use add or lea to accomplish this addition.

3. mov r, r+r — this is also a dynamic calculation, and there's also no addressing mode for r+r; Have to use add or lea for that.

4. mov r, [r+c] — a dynamic computation that loads from memory at r+c.  There's an addressing mode for [r+c].  r+c is computed and discarded after using it for memory address.

5. mov r, [r+r] — also a dynamic computation, for which there is an addressing mode.  Loads from memory; r+r is computed and then discarded after use for memory access.

6. mov r, [c+c] — there's no encoding for this but there is an encoding for [c], which the assembler will use once it has computed c+c at build time.

7. mov r, c+c — there's no encoding for this but there is an encoding for c, which the assembler will use after computing c+c during the build.

8. lea r, [c] equals mov r, c — yes, two different ways to encode the same operation.

mov and add instructions require a size to be specified in the encoding (1-, 2-, 4- or 8-bytes) — this is sometimes done by naming a target register (e.g. al, ax, eax, rax), which will inform the assembler of the size.  When addressing mode specifies a memory access, that size is also used for the memory access.

lea always targets a pointer sized register as the result is the effective address itself.