Loading an x64 register, how hard could it be?(c9x.me)
c9x.me
Loading an x64 register, how hard could it be?
http://c9x.me/art/notes.html?9/19/2015
7 comments
It's not crazy at all. This sort of shuffling is pretty standard for RISC ISAs, where it's typical to have fixed-length instructions that are no larger than the registers.
For example, MIPS has no actual "load immediate" instruction. Instead, say you want to load the value 0x12345678 into register t0. You can go ahead and tell your MIPS assembler:
For example, MIPS has no actual "load immediate" instruction. Instead, say you want to load the value 0x12345678 into register t0. You can go ahead and tell your MIPS assembler:
li $t0, 0x12345678
lui $t0, 0x1234
ori $t0, $t0, 0x5678
ori $t0, $zero 0xabcdSPARC does something similar, with a special "sethi" instruction to set the high 22 bits of a register, using more space for an argument than any other instruction does.
Some architectures manage to do something more clever than that, as well. See http://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ for instance.
Some architectures manage to do something more clever than that, as well. See http://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ for instance.
The SPARC call instruction beats that with a 30 bit immediate, sacrificing a huge chunk of the encoding space for being able to reach any target in a 32 bit address space with a single instruction.
I think the author is saying what's crazy is the lack of 64-bit immediates in a machine that contains 64-bit registers. There's an instruction to add a 32-bit immediate (and I believe 8 and 16 as well), but not a 64-bit one.
It's rare for programs to contain integer constants that don't fit in 32 bits, and they aren't needed for 64-bit code/global memory references due to the introduction of addressing relative to the instruction pointer.
Also there is a 15 bytes instruction length limit that would have to be extended if 64-bit immediates were allowed on all instructions.
Also there is a 15 bytes instruction length limit that would have to be extended if 64-bit immediates were allowed on all instructions.
No processor out there has 64-bit arithmetic immediates - it's not useful enough in practice that you'd want it, and most other architectures have fixed-length 4-byte instructions anyway so it's not practical.
It's not crazy: it's just standard operating procedure for RISC-like architectures. In fact, anything that brings the x86 architecture closer to RISC is nice in my book.
Alpha had all sorts of exotic load intermediate and shift instructions to help with this. 64bit registers, 32bit instructions, I forget the exact number but you only had 20ish bits of immediate value.
It seemed like slightly more of a chore then, with x8664 you can use memory with a lot of instructions..
It seemed like slightly more of a chore then, with x8664 you can use memory with a lot of instructions..
Populating x86-64 floating point registers is also an amusing subject.
The obvious instruction for loading a (64-bit) float into an xmm register is movsd. With a memory source operand, the higher part of the register is zeroed, which is what you want. No problem.
Now the fun part: if the source is not memory but another xmm register, the higher part of the register is not zeroed. This induces a false dependency on the previous value of the destination register that can cause performance issues. To avoid this problem, such register-register copies should be done with a packed move instruction. (Or vmovsd, but that was added much later.)
The obvious packed move instruction for 64-bit floats is movapd, but we can do better than that by using movaps - it is still a float domain instruction but is a byte smaller.
So the optimal way to move a single double from one register to another is to use a vector move of the wrong type.
The obvious instruction for loading a (64-bit) float into an xmm register is movsd. With a memory source operand, the higher part of the register is zeroed, which is what you want. No problem.
Now the fun part: if the source is not memory but another xmm register, the higher part of the register is not zeroed. This induces a false dependency on the previous value of the destination register that can cause performance issues. To avoid this problem, such register-register copies should be done with a packed move instruction. (Or vmovsd, but that was added much later.)
The obvious packed move instruction for 64-bit floats is movapd, but we can do better than that by using movaps - it is still a float domain instruction but is a byte smaller.
So the optimal way to move a single double from one register to another is to use a vector move of the wrong type.
> "it is impossible to add 2^33 to rax using one instruction only."
This can in fact be done, with a memory operand. I'm not sure about the performance compared to a 64-bit load immediate followed by an add, but this will do it (NASM syntax):
This can in fact be done, with a memory operand. I'm not sure about the performance compared to a 64-bit load immediate followed by an add, but this will do it (NASM syntax):
add rax, [rel the_constant]
...
the_constant:
dq 8589934592This is the right answer.
This is what ARM does a lot of times (their 'immediate' value ops allow you to pick an 8 bit number and rotate it a bit)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
This is what ARM does a lot of times (their 'immediate' value ops allow you to pick an 8 bit number and rotate it a bit)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
For those wondering what he meant by the "data dependency" issue that zeroing out the upper 32 bits avoids, the first answer to this SO question does a decent job of explaining it: https://stackoverflow.com/questions/11177137/why-do-most-x64...
It's actually 7 bytes, not 6, to load a sign extended value into a register.
48 C7 C0 FF FF FF FF mov RAX,0FFFFFFFFhThank you, I fixed that. In my head I knew a REX prefix was necessary and thought it was sufficient, but i386 has shortcuts to load an immediate into a register that are not available in 64 bits version!
Thanks for mentioning that.
Thanks for mentioning that.
I don't really think this is as crazy as the article is implying.