I don't understand why stacks are still so small. On nice operating systems memory is only needed when it's touched, not when it's asked for, so making the stack large doesn't cost anything unless you need a large stack. On 64-bit systems you could make the stack a billion gigabytes and still have 95% of your process' virtual address space available for the heap.
On Windows the stack is one megabyte by default. We live in the future and we're still afraid of recursion without tail-call optimisation and arrays on the stack. Ridiculous.
The stack is only contiguous in the virtual address space. The physical address space is a different beast. The operating system allocates a big chunk of virtual address space for the stack but doesn't allocate the physical memory to fill that. When an app wants to read or write from the unallocated part of the stack, a page fault interrupt is generated and the operating system allocates physical memory frames and assigns them to the virtual memory addresses of the stack. When the thread/process is interrupted for servicing, the operating system checks the value of the stack pointer register (rsp in x86_64) and frees the physical memory corresponding to the virtual addresses above that in the stack.
So having a large stack will only consume virtual address space which we have plenty of (2^48 bytes in most x86_64's) but will not consume physical memory, which is a more limited resource.
You would keep a frame pointer, which would tell you where to find the caller's stack frame. Most systems already do this, to aid debugging and tracing tools, to support variable-length stack allocations, or for any number of other reasons.
On Windows the stack is one megabyte by default. We live in the future and we're still afraid of recursion without tail-call optimisation and arrays on the stack. Ridiculous.