Yes, you clearly see that when you implement a stack-based virtual machine (as in bytecode interpreter, not VMWare and the likes, although it is on the principl

Yes, you clearly see that when you implement a stack-based virtual machine (as in bytecode interpreter, not VMWare and the likes, although it is on the principle the same thing) : your bytecode (or whatever technique you are using except perhaps JIT) for push/pop/call/ret must agree on how to use the stack. It is particularly the case in a language like Forth, which has two stacks that can be manipulated directly by the user (actually the user has to if they want to get anything done...) : one for the parameters/arguments, and one for the return addresses. This deviates from the usual single hardware stack processors. Forth processors (there are still some in operation) fully support those two stacks. When you implement a Forth interpreter in assembler, you generally use the hardware stack for either the parameters or for the return addresses, while the other is managed manually (usually using another addressing-capable register such as EBP, ESI or EDI on x86). If for instance you dedicate one segment (either in the x86 sense or in the common meaning), you typically use the push down "hardware" stack that you initialize at the top of memory, while the return addresses stack is a "push up" software-managed stack and initialized at the bottom of the memory.