I thought about the differences between the registry and stack machines, and compared the sequences of commands and ran the tests ...
Then I spent a couple of years using both types of machines while working on the Parrot VM, which was a registration machine. We started naively with a fixed set of registers in combination with data and registers, but in the end we came to the conclusion that this is an artificial limitation, so we changed to an infinite set of registers and a allocator. At some point, the Parrot accelerated core (GCC computed by goto) was superior to the Mono interpreter core and the JVM (non-JIT), but the difference decreased to JIT. Parrot JIT never matched the quality of others. JITTER quality makes a machine affordable and that’s what people care about. If all virtual machines played by the same rules (i.e., they had a restriction on starting in interpreted mode without JIT), then my data shows that the logging machine has a performance edge on an equivalent stack machine. Larger instructions, but the smaller one is higher throughput (IPC) and better link locality. JVM Dalvik actually supports my conclusions, Dalvik did not have JIT for several years and competed with its core interpreter.
Very few core virtual machines operate exclusively in interpretation mode (AFAIK), they are compiled by JIT, and this is what we are comparing. The core point of the interpreter is to establish a presence on the platform, perform a bytecode check, and provide a fail-safe kernel in the absence of JIT. Of course, this is not the rule. There are billions of devices with accelerated JMM with ARM without JIT, but in the absence of memory or processor restrictions, this applies.
I worked and worked on kernel tuning, testing and tuning, only to find that in the end we really need a fast JIT. I came to the conclusion that if you are going to end up with JIT, it does not matter if you implement a stack or a machine for registration, do what you like; but you will get to the market faster with a stack machine. Performing a large number of virtual optimizations of a pseudo-register machine to interpret bytecode using the virtual machine core is partly a costly endeavor because it is not a true native optimization. The soft core does not perform branch prediction, register renaming, instruction reordering, parallel execution or prefetching like a real processor. I feel that as soon as we have a high-quality JIT for the native binary, we arrive at the same destination.
For these reasons, I technically prefer a stack based machine for:
- Simplicity - much less code to support = fewer errors
- lead time
But visually and emotionally, I prefer the registration machine for:
- Visual-conceptual models more closely match the machine, and my brain
- Flexibility - compilers can evaluate their expression trees in different orders using SSA.
Note. I did not say that compilers can “easily” generate code. It seems that people who worked mainly with stacked machines like to argue. I do not believe in it and do not believe that it is true. I have seen many hobby compilers written in a short time both in Parrot and in the CLR, although I would admit that those in the CLR are of higher quality, but this is basically one of the ecosystem and the quality of the tools available. I myself wrote compilers on both platforms and found that there are trade-offs, but not enough to lose sleep.
This is a reasonable assumption because my actual experience does not include writing a full JITter, so I have no direct experience comparing the pros and cons of JITting different forms of opcodes, but, in my opinion, if you plan to enable JIT and then create extremely complex kernel code operations with a virtual machine - this is a premature optimization. Your time is best spent elsewhere.