News for hackers. Stuff that matters.
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by pcwalton on Saturday June 10, 2017 @06:00PM (#14529424)
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.

Re:Intel fires warning shots at Microsoft, says x86 emulatio... by gsg on Sunday June 11, 2017 @12:32AM (#14530647)
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.

Re:Intel fires warning shots at Microsoft, says x86 emulatio... by kccqzy on Saturday June 10, 2017 @06:22PM (#14529519)
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.
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by besselheim on Saturday June 10, 2017 @08:28PM (#14529971)
MOV RAX, 1 is seven bytes: 48 C7 C0 01 00 00 00
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by pcwalton on Saturday June 10, 2017 @08:47PM (#14530041)
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.

Re:Intel fires warning shots at Microsoft, says x86 emulatio... by kccqzy on Saturday June 10, 2017 @11:18PM (#14530431)
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).
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by gsg on Sunday June 11, 2017 @12:35AM (#14530655)
push $1/pop %eax (6a 01 58) is shorter, but perhaps not the best idea.
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by nayuki on Sunday June 11, 2017 @12:16PM (#14532522)
Actually, there is no 32-bit pop instruction in x86-64 mode. Your code won't work.
Re:Intel fires warning shots at Microsoft, says x86 emulatio... by gsg on Sunday June 11, 2017 @01:24PM (#14532795)
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).