You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CLR is a kind of Virtual Machine(VM), which is stack-based. I think that register-based VM is more effective, that is why android use it. So why not rewrite CLR to make it register-based?
Changing the VM to be register-based would be an extremely breaking change, considering that all code assemblies contains CIL and the CIL spec right now dictates the stack-based format. It's so breaking that I think this is very unrealistic, regardless of performance differences.
Also remember that CIL is not executed directly on a VM. The JIT turns it into (register-based) machine code, which is executed by the CPU. So the question is not "is a register-based VM more efficient to run than a stack-based VM?", it's "can a JIT turn a register-based intermediate language into machine code more efficiently than it can a stack-based intermediate language?". My strong suspicion is that no, no it can't.
This would also break so much compatibility that I can't even begin to comprehend it all...
Also remember that CIL is not executed directly on a VM.
Indeed, that's why I was hoping to see some relevant test results. Register base representations are more likely to help interpreters rather than compilers. This is because register based representations tend to use fewer instructions and thus an interpreter has less work to do.
For compilers the situation isn't as clear cut. A register based representation may make reading the representation faster (for the same reason it helps interpreters) but it may introduce issues in later compilation stages.
Android's VM isn't really representative in this regard, AFAIK it started life as an interpreter. Besides, most Android devices run on ARM and that may help a register based implementation because the number of hardware registers is known in advance.
Activity
mikedn commentedon Dec 11, 2015
Why?
Why rewrite the CLR instead of improving what's already there?
ygc369 commentedon Dec 11, 2015
Many tests show that register-based VM is more effective.
mikedn commentedon Dec 11, 2015
Well, show some of those test results here. And be sure that they're not taken out of context.
jakobbotsch commentedon Dec 11, 2015
Changing the VM to be register-based would be an extremely breaking change, considering that all code assemblies contains CIL and the CIL spec right now dictates the stack-based format. It's so breaking that I think this is very unrealistic, regardless of performance differences.
canton7 commentedon Dec 11, 2015
Also remember that CIL is not executed directly on a VM. The JIT turns it into (register-based) machine code, which is executed by the CPU. So the question is not "is a register-based VM more efficient to run than a stack-based VM?", it's "can a JIT turn a register-based intermediate language into machine code more efficiently than it can a stack-based intermediate language?". My strong suspicion is that no, no it can't.
This would also break so much compatibility that I can't even begin to comprehend it all...
mikedn commentedon Dec 11, 2015
Indeed, that's why I was hoping to see some relevant test results. Register base representations are more likely to help interpreters rather than compilers. This is because register based representations tend to use fewer instructions and thus an interpreter has less work to do.
For compilers the situation isn't as clear cut. A register based representation may make reading the representation faster (for the same reason it helps interpreters) but it may introduce issues in later compilation stages.
Android's VM isn't really representative in this regard, AFAIK it started life as an interpreter. Besides, most Android devices run on ARM and that may help a register based implementation because the number of hardware registers is known in advance.