3 ms·

> the stack is maintained separately per each function object Can someone elaborate on this? Having separate stacks makes sense for coroutines, but does this m

> the stack is maintained separately per each function object Can someone elaborate on this? Having separate stacks makes sense for coroutines, but does this mean that a normal Python function call allocates a private stack for that function?

woodruffw 5y ago
I thought that was a typo on their part, but it sounds like Python really does maintain a separate stack for each function[1]. Very strange! [1]: https://github.com/MoserMichael/pyasmtool/blob/master/bytecode_disasm.md#learning-about-expression-evaluation https://github.com/MoserMichael/pyasmtool/blob/master/byteco...
- masklinn 5y ago
  It probably makes a bit more sense if you consider that the “per-function stack” is really the tail of the call frame. That also means the bytecode works solely within its own stack segment.
- Karliss 5y ago
  It refers to operand stack not call stack. All it means is that python bytecode is stack based where most instructions pop arguments and push results on operand stack. In contrast with register based VMs. When implementing a VM it makes sense to store call stack and operand stack separately so that you don't have to mix types. You probably don't want to allow function to uncontrollably modify operands in lower frames as in most cases that would be either a bug or vulnerability. Having separate operand stack for each frame also makes any kind of analysis much easier. Call instruction can be viewed as a fat instruction which pops some amount of arguments and pushes single result back. Once you restrict cross frame operand stack access, whether it's stored in single or multiple arrays becomes an implementation detail. Many other VMs do more or less the same JVM, AVM2(flash), CIL(C#). It doesn't necesarily mean that the stacks are separate after JIT but from the perspective of bytecode instructions operand stacks are separate.

woodruffw 5y ago

I thought that was a typo on their part, but it sounds like Python really does maintain a separate stack for each function[1]. Very strange! [1]: https://github.com/MoserMichael/pyasmtool/blob/master/bytecode_disasm.md#learning-about-expression-evaluation https://github.com/MoserMichael/pyasmtool/blob/master/byteco...

masklinn 5y ago
It probably makes a bit more sense if you consider that the “per-function stack” is really the tail of the call frame. That also means the bytecode works solely within its own stack segment.
Karliss 5y ago
It refers to operand stack not call stack. All it means is that python bytecode is stack based where most instructions pop arguments and push results on operand stack. In contrast with register based VMs. When implementing a VM it makes sense to store call stack and operand stack separately so that you don't have to mix types. You probably don't want to allow function to uncontrollably modify operands in lower frames as in most cases that would be either a bug or vulnerability. Having separate operand stack for each frame also makes any kind of analysis much easier. Call instruction can be viewed as a fat instruction which pops some amount of arguments and pushes single result back. Once you restrict cross frame operand stack access, whether it's stored in single or multiple arrays becomes an implementation detail. Many other VMs do more or less the same JVM, AVM2(flash), CIL(C#). It doesn't necesarily mean that the stacks are separate after JIT but from the perspective of bytecode instructions operand stacks are separate.