I'd say the critical question really isn't around speed of an interpreter, since if you care about speed you're using something like a JIT compilation model to actual machine code anyway. A more important question, if you want the VM to become more widely useful, is to make the instruction set easy to compile to.
A big advantage of a stack-based architecture (in my experience) is that it's simpler to write a compiler for because you don't have to worry about register allocation. My compiler writing experience is a bit limited (I've done some work targeting the JVM, and some very limited MIPS assembly coding), but I've found that not having to track register state is a very helpful simplification.
Some VMs (LLVM and Parrot, that I know of) give you an arbitrary number of virtual registers, which are then mapped to physical registers by the compiler, so allocation is a not an issue.
Nearly ALL register-based IRs give you infinate number of registers. Register allocation is not done until absolutely the last minute. This alone is one good reason to favor register based stack machines. A register allocator along with basic dependence analysis phase can be tacked on the VM and you have an instant JIT "executor"; interpreter + compiler + runtime all in one convenient binary.
It's still harder to write compilers for them. Stack based forms are easy, you push the data onto the stack and pop it again when you need it, and the VM's compiler handles the heavy lifting. With a register form, specifically where you have an infinite number of registers, you are effectively doing SSA in your compiler to map onto 'registers' (SSA variables) and writing out the raw intermediary form. Stack based forms are simply easier to write front-end compilers for.
Comments
I'd say the critical question really isn't around speed of an interpreter, since if you care about speed you're using something like a JIT compilation model to actual machine code anyway. A more important question, if you want the VM to become more widely useful, is to make the instruction set easy to compile to.
A big advantage of a stack-based architecture (in my experience) is that it's simpler to write a compiler for because you don't have to worry about register allocation. My compiler writing experience is a bit limited (I've done some work targeting the JVM, and some very limited MIPS assembly coding), but I've found that not having to track register state is a very helpful simplification.
Some VMs (LLVM and Parrot, that I know of) give you an arbitrary number of virtual registers, which are then mapped to physical registers by the compiler, so allocation is a not an issue.
Nearly ALL register-based IRs give you infinate number of registers. Register allocation is not done until absolutely the last minute. This alone is one good reason to favor register based stack machines. A register allocator along with basic dependence analysis phase can be tacked on the VM and you have an instant JIT "executor"; interpreter + compiler + runtime all in one convenient binary.
It's still harder to write compilers for them. Stack based forms are easy, you push the data onto the stack and pop it again when you need it, and the VM's compiler handles the heavy lifting. With a register form, specifically where you have an infinite number of registers, you are effectively doing SSA in your compiler to map onto 'registers' (SSA variables) and writing out the raw intermediary form. Stack based forms are simply easier to write front-end compilers for.