[carbonica]

> 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]

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]

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.