Re: Continuations

Scott Lurndal <scott@slp53.sl.home> schrieb:

Thomas Koenig <tkoenig@netcologne.de> writes:

Scott Lurndal <scott@slp53.sl.home> schrieb:

Thomas Koenig <tkoenig@netcologne.de> writes:

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>

Anyway, at the time I made a mental note about the relative cost of
heap allocation of stack space in an ABI.

>
I wonder if I might mention my dislike of arbitrary limits on
stack size that are imposed on modern 64-bit systems.

>
$ ulimit -s unlimited
>
Should handle the default stack.

>
Some operating systems put a hard limit on this, for example MacOS,
and some an absurdly low limit on per-thread stack size (512 K
or something like that).

>
MacOS has been obsolete for a decade now.

Sorry for messing up my terminology.

OSX has an initial
size of 8MB and a default configured hard limit of 64GB.

The former leads to segfaults on otherwise fine programs, and
makes using gfortran's -fstack-arrays (which really brings speed
improvements) unsuitable for a lot of problems because it puts
local arrays on the stack...

Of course, it still needs to fit into whatever address space
the target processor offers, but even with a 48-bit VA,
there should be enuf VA space for several terabytes of
stack.

>

In any case, one can mmap an arbitrarily large region of
memory and assign it to the stack pointer in (or even before)
main().

>
Changing the standard startup sequence of programs (i.e. replacing
_start) - that would be heavy messing, and be no longer compatible
with standard startup sequences.

>
That depends on the program, I guess.

In this case, a general approach.

A little inline assembler
in main should suffice;

Not possible in Fortran, for example, unless the compiler does
so itself.  And, of course, it should be platform-independent,
especially on systems that the maintainers of the Fortran compiler
have no access to, and no special knowledge of, plus it would
require platform-specific assembly in the startup code.

An mmap'ed region will automatically
allocate on first touch, so the stack can grow as necessary.

Slightly different topic: Unfortunately, Apple decided in their
wisdom that an mmapped region cannot grow, so you have to make a
guess at the needed size.  As to why, I have no idea; they probably
wanted to follow the example of Windows.  Learning from Microsoft
is learning to win!

This makes dynamic memory management for shared memory much harder
than it needs to be (been there, been bitten by it).

And for threads, this would get even messier.

>
pthreads already get their own stack, and have standard functions
to specify stack pointer and stack size (e.g. pthread_attr_setstack(2)).

Life would be so much easier if defaults were reasonable...