4 ms·

But in hardware at least, the x86 registers have been found quite limiting on software and performance. That's why AMD64 doubles the number of general purpose r

by maaku 15y ago

But in hardware at least, the x86 registers have been found quite limiting on software and performance. That's why AMD64 doubles the number of general purpose registers. Does anyone know if there is research into the effects of register counts on VMs?

carbonica 15y ago
> But in hardware at least, the x86 registers have been found quite limiting on software and performance. While the doubled register count makes a big difference - especially with the new x86-64 calling convention - register renaming and hidden registers do a lot on x86 to mitigate the lack of general purpose registers. You don't need more than 8 registers to get the benefits of having more than 8.
- maaku 15y ago
  Which basically amounts to the same thing. "x86" processors today are actually RISC(-like) processors with large register spaces and three-operand instructions, because that hardware can be made faster, even with the necessary silicon x86->RISC translator so software sees an x86 processor. But to my knowledge, compatibility with legacy compiled software is not a practical issue for VM's. And even if it were, this isn't a compatible implementation of x86 anyway. So what then is the reasoning for this choice?
  - carbonica 15y ago
    It's close to the same thing, but having more named registers does provide more optimization opportunities. It shouldn't be completely ignored as a good thing. I mentioned function calls because that's a boundary when an optimizer - either in-processor or in-compiler - is often forced to use memory and not registers. The big-N-register "register window" of RISC processors kicks this problem's ass. But with aggressive inlining already common, these boundaries don't come up as often as you'd think. So the x86-64 calling convention does a pretty damn good job too. Edit: by the way, I guess I haven't really commenting on TinyVM one way or the other when I responded to you. You're absolutely right and the compatibility is not necessary at all. I think the register count limitation especially is just silly. I pointed out in a different thread that they could double their register count and they'd still fit in a single cache line... they even already have a naming convention (r08-r15) they can hijack.
Someone 15y ago
If you can map all VM registers to CPU registers, the interpreter will be way simpler. If you have more VM registers than CPU registers, you have to write code to load and store your VM registers. If you have more CPU registers than VM registers, you will have to write code to undo some of the register spilling done by the compiler (if you want your VM to use the hardware to the fullest.) So, the optimum (from a viewpoint of 'makes implementation easier') depends on the target architecture. Of course, a generic VM cannot know how many registers (and what kinds; uniform register files are not universally present) the target CPU will have. That is a reason that choosing either zero (i.e. a stack machine) or infinitely many (i.e. SSA) are popular choices fo VMs: for the first, you know for sure your target will not have fewer registers than your VM, for the second, that it will not have more. If you choose any other number of VM registers, a fast generic VM will have to handle both cases. Alternatively, of course, one can target a specific architecture, and have the VM be fairly close to the target; Google's NaCl is (was? I think they changed things a bit) an extreme example. I have not checked the code, but this, I think, is similar.

by maaku 15y ago

carbonica 15y ago

> But in hardware at least, the x86 registers have been found quite limiting on software and performance. While the doubled register count makes a big difference - especially with the new x86-64 calling convention - register renaming and hidden registers do a lot on x86 to mitigate the lack of general purpose registers. You don't need more than 8 registers to get the benefits of having more than 8.

maaku 15y ago
Which basically amounts to the same thing. "x86" processors today are actually RISC(-like) processors with large register spaces and three-operand instructions, because that hardware can be made faster, even with the necessary silicon x86->RISC translator so software sees an x86 processor. But to my knowledge, compatibility with legacy compiled software is not a practical issue for VM's. And even if it were, this isn't a compatible implementation of x86 anyway. So what then is the reasoning for this choice?
- carbonica 15y ago
  It's close to the same thing, but having more named registers does provide more optimization opportunities. It shouldn't be completely ignored as a good thing. I mentioned function calls because that's a boundary when an optimizer - either in-processor or in-compiler - is often forced to use memory and not registers. The big-N-register "register window" of RISC processors kicks this problem's ass. But with aggressive inlining already common, these boundaries don't come up as often as you'd think. So the x86-64 calling convention does a pretty damn good job too. Edit: by the way, I guess I haven't really commenting on TinyVM one way or the other when I responded to you. You're absolutely right and the compatibility is not necessary at all. I think the register count limitation especially is just silly. I pointed out in a different thread that they could double their register count and they'd still fit in a single cache line... they even already have a naming convention (r08-r15) they can hijack.

Someone 15y ago

If you can map all VM registers to CPU registers, the interpreter will be way simpler. If you have more VM registers than CPU registers, you have to write code to load and store your VM registers. If you have more CPU registers than VM registers, you will have to write code to undo some of the register spilling done by the compiler (if you want your VM to use the hardware to the fullest.) So, the optimum (from a viewpoint of 'makes implementation easier') depends on the target architecture. Of course, a generic VM cannot know how many registers (and what kinds; uniform register files are not universally present) the target CPU will have. That is a reason that choosing either zero (i.e. a stack machine) or infinitely many (i.e. SSA) are popular choices fo VMs: for the first, you know for sure your target will not have fewer registers than your VM, for the second, that it will not have more. If you choose any other number of VM registers, a fast generic VM will have to handle both cases. Alternatively, of course, one can target a specific architecture, and have the VM be fairly close to the target; Google's NaCl is (was? I think they changed things a bit) an extreme example. I have not checked the code, but this, I think, is similar.