Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

X86 Register Encoding

eklitzke.org

Post reply on HN
Print view View original

21–30 of 54 posts

Re: X86 Register Encoding

#21

Post by bonzini »

pklausler wrote: post #4

The OP perpetuates the mistaken assumption that x86-64 looks as it does because it extends good ol' 32-bit x86 encodings, which one might assume still work so well that one could run 32-bit code in 64-bit mode and have it still work. Which is not the case at all. Those REX prefix bytes used to be perfectly good 32-bit x86 instructions that now simply don't work in 64-bit mode with their original encodings. So the "co…

Those instructions were hard to optimize because of partial flags stalls. In the end because of this and because of strength reduction compilers were not generating that many INC and DEC instructions.

Re: X86 Register Encoding

#22

Post by a-priori »

eloff wrote: post #16
kr7 wrote: post #13

Earlier quoted context omitted.

> In fact, the average size of each instruction is almost exactly 4 bytes I was curious about this claim so I wrote a quick and dirty perl script to test it out: vmlinuz-linux = 2.71957329365681 bash = 3.95324321387071 firefox = 3.56640365053712 geany = 3.44776119402985 gzip = 4.17925462998247 perl = 4.10894941634241 python = 3.82481751824818 tar = 3.93348845041101 thunar = 3.82471016115786 radeon_drv.so = 4.02697782…

The kernel is compiled with -Os for code size last I checked (which was long ago) so that might explain the difference.

It's been about ten years since I did any kernel work, but last I checked Linux doesn't use most of the fancy features of the CPU to avoid trashing more registers than necessary. If you know you don't do any floating point operations, for example, you know you don't need to save/restore the floating point registers on interrupts. The same might go for things like SSE.

Those instructions tend to be larger, so it may partly explain the difference in average instruction size. The same explanation would apply to why the Radeon driver has a higher average.

Re: X86 Register Encoding

#23

Post by bertr4nd »

pcwalton wrote: post #2

LLVM doesn't actually prefer the lower registers when doing register allocation. IIRC, sunfish told me that GCC doesn't either. It would be interesting to add features that try to minimize code size to the register allocator, but no compiler I know of actually does this. Partially as a consequence of this, the REX prefixes take up a lot of space in most x86-64 instruction streams. In fact, the average size of each in…

HHVM's register allocator has a few tricks to minimize code size. Among other things it tends to prefer the old regs to the new x64 ones. As you might imagine code size is a significant challenge for Facebook so these kind of optimizations tended to give nice wins.

Re: X86 Register Encoding

#24

Post by lisper »

ant6n wrote: post #6
pklausler wrote: post #4

The OP perpetuates the mistaken assumption that x86-64 looks as it does because it extends good ol' 32-bit x86 encodings, which one might assume still work so well that one could run 32-bit code in 64-bit mode and have it still work. Which is not the case at all. Those REX prefix bytes used to be perfectly good 32-bit x86 instructions that now simply don't work in 64-bit mode with their original encodings. So the "co…

They probably wanted to re-use most of the x86-32 decoder that they had on the chip anyway. Kind of strange, nowadays, an embedded armv8 cpu will come with multiple decoders (ARM32, thumb2, AARCH64).

This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for competition.

Re: X86 Register Encoding

#25

Post by munificent »

bertr4nd wrote: post #23
pcwalton wrote: post #2

LLVM doesn't actually prefer the lower registers when doing register allocation. IIRC, sunfish told me that GCC doesn't either. It would be interesting to add features that try to minimize code size to the register allocator, but no compiler I know of actually does this. Partially as a consequence of this, the REX prefixes take up a lot of space in most x86-64 instruction streams. In fact, the average size of each in…

HHVM's register allocator has a few tricks to minimize code size. Among other things it tends to prefer the old regs to the new x64 ones. As you might imagine code size is a significant challenge for Facebook so these kind of optimizations tended to give nice wins.

> As you might imagine code size is a significant challenge for Facebook

Maybe I'm missing something obvious, but why is code size a big concern for Facebook's server code?

Re: X86 Register Encoding

#26

Post by twic »

munificent wrote: post #25
bertr4nd wrote: post #23

Earlier quoted context omitted.

HHVM's register allocator has a few tricks to minimize code size. Among other things it tends to prefer the old regs to the new x64 ones. As you might imagine code size is a significant challenge for Facebook so these kind of optimizations tended to give nice wins.

> As you might imagine code size is a significant challenge for Facebook Maybe I'm missing something obvious, but why is code size a big concern for Facebook's server code?

"Because Facebook's entire code base is compiled down to a single binary executable, the company's deployment process is quite different from what you'd normally expect in a PHP environment. Rossi told me that the binary, which represents the entire Facebook application, is approximately 1.5GB in size."

http://arstechnica.com/business/2012/04/exclusive-a-behind-t...

Re: X86 Register Encoding

#27

Post by gsnedders »

lisper wrote: post #24
ant6n wrote: post #6

Earlier quoted context omitted.

They probably wanted to re-use most of the x86-32 decoder that they had on the chip anyway. Kind of strange, nowadays, an embedded armv8 cpu will come with multiple decoders (ARM32, thumb2, AARCH64).

This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for…

Related to this is the PPC615, an IBM project in the mid-90s, socket compatible with the original Pentium, and ran x86-32, PPC32, and PPC64 natively. (It got scrapped because all the signs looked like Intel was going to push IA-64 heavily, and rely on it's backwards compatibility for x86-32, hence an expectation x86-32 was soon to be legacy.)

Re: X86 Register Encoding

#28

Post by pcwalton »

lisper wrote: post #24
ant6n wrote: post #6

Earlier quoted context omitted.

They probably wanted to re-use most of the x86-32 decoder that they had on the chip anyway. Kind of strange, nowadays, an embedded armv8 cpu will come with multiple decoders (ARM32, thumb2, AARCH64).

This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for…

> It's all RISC under the hood anyway, why not give us access to it?

Presumably because it doesn't matter that much, so it isn't worth the investment for Intel.

It feels to me like people have trouble accepting that both of these are true: (1) RISC vs. x86 doesn't matter that much in practice; (2) technically speaking, RISC is a superior design to x86.

Re: X86 Register Encoding

#29

Post by nullc »

pcwalton wrote: post #28
lisper wrote: post #24

Earlier quoted context omitted.

This. In today's world it is easy to support multiple instruction sets in the same silicon using the same registers and ALU. So why in the name of all that is holy does the x86 not have a nice clean 64-bit instruction set that you can swap in? It's all RISC under the hood anyway, why not give us access to it? The only explanation I can think of is that Intel wants to keep things complicated as a barrier to entry for…

> It's all RISC under the hood anyway, why not give us access to it? Presumably because it doesn't matter that much, so it isn't worth the investment for Intel. It feels to me like people have trouble accepting that both of these are true: (1) RISC vs. x86 doesn't matter that much in practice; (2) technically speaking, RISC is a superior design to x86.

> Presumably because it doesn't matter that much, so it isn't worth the investment for Intel.

Intel invested in a new instruction set (IA64). AMD did not.

The market chose AMD's offering.

Re: X86 Register Encoding

#30

Post by pklausler »

bonzini wrote: post #17
mikeash wrote: post #9

Earlier quoted context omitted.

Wouldn't you also have to look at the average number of instructions, not just the average instruction size? x86 instructions tend to do more, too.

Not necessarily. For example except for LEA, they do 2-operand arithmetic. The only thing where x86 wins hands down is addressing modes and immediate moves.

I'll grant you immediate moves, but not addressing modes. It lacks the auto-increment/update possibilities that were in the pdp-11, vax, mc68k, and power(pc), and are great for cutting down on instruction counts in loops. (Hell, on the CDC6600, address register updates were the only way you could do loads and stores; many good ideas didn't survive into the impoverished x86 era.)
Post reply on HN