Hacker News Reader

Comment by worik | Hacker News Reader

I want infinite stack.

As I understand it the stack size limit is because a process's threads share the same address spaces so basically where would you put all their stacks? With one stack you just start it from the top of (virtual) memory and put the heap at the bottom and when they meet you've run out of memory. Infinite stack!

But with lots of threads there aren't enough spaces for them to start from. At least on 32-bit. On 64-bit I think you could have effectively infinite stack, or at least very very large (like 1 GB) stacks. But as far as I know nobody has bothered to do it.

I guess an alternative solution would be to put the stacks in different address spaces somehow, but that could get very complicated (now you have two kinds of pointers). Are there any old systems that had separate heap and stack address spaces?

Stack was really meant to save parameters for function calls and local variables for functions or in your terms sub-routines. In a well organized program, usually you would not need much stack space unless there was something went wrong, such as a recursive call without termination condition etc..

Even local variables of functions can take up a lot of room can take quite a lot of space. Especially when you minimize use of the heap. Using the stack instead of heap where possible makes for clean automatic free-ing of unused memory.

> In a well organized program, usually you would not need much stack space

But that's only because stack space is currently limited. If stack space were as unlimited as heap space then there would be absolutely nothing wrong with using as much stack space as you wanted. It would be better even - stack space is much quicker to allocate and free than heap space.

>I guess an alternative solution would be to put the stacks in different address spaces somehow, but that could get very complicated (now you have two kinds of pointers). Are there any old systems that had separate heap and stack address spaces?

On 16-bit x86, memory was divided into 64K segments and you could have separate ones for code, data and stack. Having effectively a different address space for code isn't a problem, but languages like C expect that you can pass around pointers to stack variables as well as global/heap ones. So now every data pointer needed to be a "far" one (32 bits, segment:offset), and to dereference it the segment portion would usually have to be loaded into the single "extra" segment register that isn't dedicated to code/data/stack.

With data and stack sharing the same segment, you could use 16 bit pointers for everything and the code was a lot more efficient.

I basically never want threads. (Processes can share some of their memory in a more limited way if they need to.)

I often want stack allocation without having to worry if it hits some arbitrary limit unrelated to actual memory available. Memory is fungible.

It's true that there are programmers with different values.

Then make sure all your calls are in tail-call positions, and use a compiler or interpreter with TCO.

So basically "program without subroutines" okay thanks.

Not necessarily. I recommend checking out forth :)

I really don't know what you mean. Forth has two stacks that can grow infinitely.

Trying to do everything with tail calls in Forth puts you in a position much like any other language: Okay, you can have a single overarching state machine with top-level routines, but you can't factor anything into subroutines because there's no way to 'return'.

I want Forth.

Progress: Fifth

Eventually N!

https://www.frathwiki.com/Fith

Reply on news.ycombinator.com