What does it mean that python is stack based?

Question

I have read how CPython is stack based. What does it mean? When I use the dis module, I see operations like LOAD_FAST etc, where the values are placed on a stack. But I have read that all values in python are objects and hence go in the heap. I guess I am confusing two different things here. I have also read that there is something called stackless python. Can someone clarify this?

Answer 1

The most popular python interpreter, CPython, can be viewed as a stack based virtual machine. It means that python code is compiled for an imaginary (virtual) computer with a stack architecture.

The other aspect is how this virtual machine is implemented. It's clearly not a piece of hardware (and attempts of processor manufacturers to add support for some virtual machines, for example JVM, are usually not successful). So, this stack machine is emulated by a program written in C and it is a part of the CPython interpreter.

Regarding how do stack and heap live together, it should be clear now - the virtual machine and the stack, both are placed in the heap memory. Using LOAD_FAST places an object on the top of the stack from the virtual machine point of view, and the very same instruction places object in the heap from an OS point of view.

Answer 2

Everything isn't black and white. The meaning of stack based shouldn't be taken as excluding the possibility of data being stored on the heap.

First of all it's only references to objects that lives on the stack in the VM, but still not all references lives there (there are references to other objects in the objects that lives on the heap too).

The stack here is that temporary data is being held on a stack instead of in registers. Which means that if you are to add two numbers you put them on the stack and then execute an addition instruction as opposed to in a register machine you put them into registers and add them together.

Now since the lifetime of objects are not limited in a way that makes it possible (or at least feasible) to have them live on a stack you have to complete this model with a heap for storing the actual objects.

In addition it's rather impractical to be a slave under the stack model. For example the VM must be able to access the global scope (which by definition is a dict-like object). While it could be solved by always having a reference to the global scope always lying around on the stack, it's rather impractical. Instead there's instructions to directly do lookups in the global scope. A similar reasoning applies to local scope, you could have all local variables lying around on the stack, but instead you have them in an array which is more like what would be the case in a register machine, that's where LOAD_FAST comes into the picture.

So the fact is that the CPython VM is more of a mix of a register machine and stack machine.

Then regarding stack-less python it's also somewhat confusing. The stack in that name doesn't refer to the same stack. Instead it refers to the C-stack, and it doesn't mean that it's free of a C-stack, but rather that the python interpreter doesn't use the C call-stack to keep track of python call-stack. What this actually means is that stack-less python has more of stack in the VM than CPython rather than less.

The difference is what happens when you call a function. In CPython the VM will simply call itself to execute the method which will mean that information on how to return to the caller is maintained on the C stack. In stack-less python on the other hand the return address is pushed onto the python stack and the VM continues executing the function directly and the information on how to return to the caller is maintained on the VM stack. One advantage of stack-less python is that each python thread does not have to be executed with a separate thread in C (which means that stack-less python can have thread even on platforms that doesn't support multithreading).

There are implementations of python that uses register machine instead, but then again it's not black and white there either. As you probably realized the calling of function will need the return information to be stored somewhere and it's basically required that it would be stored on a stack. So it too is kind of a mix of a stack machine and register machine. Of course it would possibly use the C stack for saving information for returning to the caller which could make the stack inaccessible for the VM.