Re: segfault with large-ish array with GNAT

[Warren <ve3wwg@gmail.com>]

Jerry expounded in news:ac4bed10-f655-4fa5-8891-2967ba4388a0
@k6g2000prg.googlegroups.com:
..
> So here's me being naive: I would have thought that Ada (or GNAT
> specifically) would be smart enough to allocate memory for large
> objects such as my long array in a transparent way so that I don't
> have to worry about it, thus (in the Ada spirit) making it harder to
> screw up. 

Programmer's do still have some responsibility in
design, Ada or otherwise. ;-)

> But it seems that I will have to allocate memory for large objects
> using pointers (and thus take the memory from the heap). Is that
> right?
..
> Jerry

The stack is a valuable resource and sometimes you need to
be careful with allocation.  I forget how gnat implements
tasks (threads) precisely, but they too require a stack. So 
your virtual address space for stack must also be carved up 
for each additional task. A 2G address space seemed huge 20 
years ago, but it seems rather small these days.

With the new focus on parallel cores etc., I've often pondered 
what a future CPU without a stack might look like. Imagine 
a CPU that somehow in microcode was able to do a fast-malloc 
of a stack frame (as part of a call), linking the new 
frame back to the calling frame. Then you could eliminate
the need for a "linear virtual stack region" altogether. This 
would allow code to freely fork into many parallel 
threads without the issue of pre-allocating stack [address]
space to each new thread. When the called procedure executed
a "return", it would (in microcode) free the current stack
frame and return to the prior one.  The "call" allocate/free's
could be constrained to one general "stack heap".

[..back from the day-dream..]

Generally speaking, large objects are best allocated
from the heap. But don't forget to release them once
finished. Otherwise you'll only feed from that trough 
a few times also. ;-)

Warren