While some architectures have some special instructions/registers for handling stacks I still wouldn't say it's built into CPUs. The direction in which a stack

While some architectures have some special instructions/registers for handling stacks I still wouldn't say it's built into CPUs. The direction in which a stack grows depends on the architecture. Some programming languages don't have one stack and one heap that grow into each other but instead several memory areas while still being single threaded (I think prolog or some logic oriented languages have such a more complicated concept). Management of the stack is done by the program, not by the OS. How the program does it depends on the language and unless you use assembler it is hidden by the compiler. There is a calling convention, not one single way a call works. Some C compilers expose ways to define a different than the standard calling convention for a function. You might say that how a function call works is to much detail and not what you understand about how the stack works. Anyway, some languages have segmented stacks, meaning if a stack is used up a new stack is allocated and referred to by the old one (rust supported this at some point). There are also languages that have different heaps per thread (rust for gc-ed objects). Per-thread heaps are a good idea because otherwise you would need to use some sort of synchronization for malloc and free, which defeats the purpose of threads. Usually this is done by reserving a memory area for a thread and only when this is exhausted and a new memory area needs to be allocated some sort of potentially blocking call (I think usually mmap?) for another area is called.