2 ms·

1. Yeah, ARM has one nasty architectural optimization leaking out: the program counter register being 8 bytes ahead of where it should be due to pipelining. Tha

1. Yeah, ARM has one nasty architectural optimization leaking out: the program counter register being 8 bytes ahead of where it should be due to pipelining. Thankfully that got fixed up in AArch64, and if 32-bit mode gets dropped down the line (which is allowed by the architecture) it'll be a thing of the past. x86 has some architectural leaks too, though: the aliasing of the MMX and FP stacks as a hack for compatibility with early versions of Windows comes to mind. This one hasn't been fixed. 2. The REX prefixes are a nightmare: most instructions have one and this tremendously bloats up the instruction stream size. For this reason, the i-cache efficiency is not good compared to actual compressed instruction sets such as Thumb-2 (not that Thumb-2 is wonderful either). Note that if you do extreme hand-optimization of binary size, you can get x86-64 down pretty far, but so few people do that that it doesn't matter in practice. 3. Two address code isn't necessarily a win, especially since it doubles the number of REX prefixes. In AArch64 "and x9,x10,x11" is 4 bytes; in x86-64 "mov r9,r10; and r9,r11" is 6 bytes (and clobbers the condition codes). There's a reason compilers love to emit the three-address LEA... 4. Memory operands are nice, though I think the squeeze on instruction space makes them not worth it in practice. I'd rather use that opcode space for more registers. 5. Immediate encoding on x86-64 is crazy inefficient. "mov rax,1" is a whopping 7 bytes.

kccqzy 9y ago
Regarding 5, no, it's five bytes (b8 01 00 00 00) for movl $1,%eax. If you actually have a 64-bit immediate, just the immediate itself would be 8 bytes, and the actual instruction is 10 bytes.
- besselheim 9y ago
  MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00
  - pcwalton 9y ago
    The parent has a good point actually, because "mov eax,1" automatically zero-extends in 64-bit mode. It's still one byte longer than the equivalent AArch64 instruction, though.
    - kccqzy 9y ago
      Fine. If you are really into getting the shortest instruction, try "xorl %eax,%eax" then "incl %eax" which is four bytes (31 c0 ff c0).
      - gsg 9y ago
        push $1/pop %eax (6a 01 58) is shorter, but perhaps not the best idea.
        nayuki 9y ago
        Actually, there is no 32-bit pop instruction in x86-64 mode. Your code won't work.
        gsg 9y ago
        You're right: it should be pushq $1/pop %rax (which is also three bytes, although there will be a prefix byte for registers r8 through r15).
gsg 9y ago
Immediates are a bit of a mix. mov doesn't have very nice encodings, but many instructions do: push $1 is 2 bytes, addl $2, %eax is only 3 bytes. There's no question that x86-64 could be improved on in terms of code density.

kccqzy 9y ago

Regarding 5, no, it's five bytes (b8 01 00 00 00) for movl $1,%eax. If you actually have a 64-bit immediate, just the immediate itself would be 8 bytes, and the actual instruction is 10 bytes.

besselheim 9y ago
MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00
- pcwalton 9y ago
  The parent has a good point actually, because "mov eax,1" automatically zero-extends in 64-bit mode. It's still one byte longer than the equivalent AArch64 instruction, though.
  - kccqzy 9y ago
    Fine. If you are really into getting the shortest instruction, try "xorl %eax,%eax" then "incl %eax" which is four bytes (31 c0 ff c0).
    - gsg 9y ago
      push $1/pop %eax (6a 01 58) is shorter, but perhaps not the best idea.
      - nayuki 9y ago
        Actually, there is no 32-bit pop instruction in x86-64 mode. Your code won't work.
        gsg 9y ago
        You're right: it should be pushq $1/pop %rax (which is also three bytes, although there will be a prefix byte for registers r8 through r15).

gsg 9y ago

Immediates are a bit of a mix. mov doesn't have very nice encodings, but many instructions do: push $1 is 2 bytes, addl $2, %eax is only 3 bytes. There's no question that x86-64 could be improved on in terms of code density.