Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Continuations
Date: Tue, 16 Jul 2024 05:54:44 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <v751v4$1523o$1@dont-email.me>
References: <v6tbki$3g9rg$1@dont-email.me> <xUwkO.39824$BYv6.12019@fx09.iad>
 <v6v3em$3povk$9@dont-email.me> <7celO.30630$sE%9.24251@fx14.iad>
 <v73re2$qohp$1@dont-email.me> <NIelO.87031$z2Mf.49281@fx16.iad>
 <v7440p$sgca$1@dont-email.me> <SHilO.43656$q2da.30009@fx18.iad>
Injection-Date: Tue, 16 Jul 2024 07:54:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="06375f50c042620a9075edf16601c778";
	logging-data="1214584"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ObSvhTY87GbMLTd0hYuRVhYNnvFZCeCo="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:0fCPp0ugBEi3h4SIeQCD9LW5uf8=

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...