What's the difference between the x86-64 AT&T instructions movq and movabsq?

.section .rodata str: .string "0x%lx\n" .text .globl main main: pushq %rbp movq %rsp, %rbp movl $str, %edi movq $0xFFFFFFFF, %rsi xorl %eax, %eax call printf xorl %eax, %eax popq %rbp ret

There are three kind of moves to fill a 64-bit register:

Moving to the low 32-bit part: B8 +rd id , 5 bytes
Example: mov eax, 241 / mov[l] $241, %eax
Moving to the low 32-bit part will zero the upper part.
Moving with a 64-bit immediate: 48 B8 +rd io, 10 bytes
Example: mov rax, 0xf1f1f1f1f1f1f1f1 / mov[abs][q] $0xf1f1f1f1f1f1f1f1, %rax
Moving a full 64-bit immediate.
Moving with a sign-extended 32-bit immediate: 48 C7 /0 id, 7 bytes
Example: mov rax, 0xffffffffffffffff / mov[q] $0xffffffffffffffff, %rax Moving a signed 32-bit immediate to full 64-bit register.

Notice how at the assembly level there is room for ambiguity, movq is used for the second and third case.

For each immediate value we have:

(a) Values in [0, 0x7fff_ffff] can be encoded with (1), (2) and (3).
(b) Values in [0x8000_0000, 0xffff_ffff] can be encoded with (1) and (2).
(c) Values in [0x1_0000_0000, 0xffff_ffff_7fff_ffff] can be encoded with (2)
(d) Values in [0xffff_ffff_8000_0000, 0xffff_ffff_ffff_ffff] can be encoded with (2) and (3).

All the cases but the third have at least two possible encoding.
The assembler picks up the shortest one usually if more than one encoding is available but that's not always the case.

For GAS:
movabs[q] always correspond to (2).
mov[q] corresponds to (3) for the cases (a) and (d), to (2) for the other cases.
It never generate (1) for a move to a 64-bit register.

To make it pick up (1) we have to use mov[l] $0xffffffff, %edi which is equivalent (I believe GAS won't convert a move to a 64-bit register to one to its lower 32-bit register even when this is equivalent).

In the 16/32-bit era distinguishing between (1) and (3) was not considered really important (yet in GAS it's possible to pick one specific form) since it was not a sign-extend operation but an artefact of the original encoding in the 8086.

The mov instruction was never split into two forms to account for (1) and (3), instead a single mov was being used with the assembler almost always picking (1) over (3).

With the new 64-bit registers having 64-bit immediates would make the code far too sparse (and would easily violate the current maximum instruction length of 16 bytes) so it was not worth it to extend (1) to always take 64-bit immediate.
Instead (1) still have 32-bit immediate and zero-extends (to break any false data dependency) and (2) was introduced for the rare case where a 64-bit immediate operand is actually needed.
Taking the chance, (3) was also changed to still take a 32-bit immediate but to also sign-extend it.
(1) and (3) should suffice for the most common immediates (like 1 or -1).

However the difference between (1)/(3) and (2) is deeper than the past difference between (1) and (3) because while (1) and (3) both have an operand of the same size, 32-bit, (3) has a 64-bit immediate operand.

Why would one want an artificially lengthened instruction?
As described in the linked answer, one use case could be padding so that the top of the next loop is at a multiple of 16/32 bytes, without needing any NOP instructions.
This sacrifices code density (more space in the instruction cache) and decode efficiency outside the loop for better front-end efficiency for each loop iteration. But longer instructions are still generally cheaper for the front-end than having to decode some NOPs as well.

Another, and more frequent, use case is when one only need to generate a machine code template.
For example in a JIT one may want to prepare the sequence of instructions to use and fill the immediates values only at runtime.
In that case using (2) will greatly simplify the handling since there is always enough room for all the possible values.

Another case is for some patching functionality, in a debug version of a software specific calls could be made indirectly with an address in a register that has just been loaded with (2) so that the debugger can hijack the call easily to any new target.

Recommended topics

Hot tags