Yet another strike against the current AA implementation

[Andrei Alexandrescu]

Georg Wrede wrote:
> downs wrote:
>> Joel C. Salomon wrote:
>>> grauzone wrote:
>>>> downs wrote:
>>>>> Daniel Keep wrote:
>>>>>> Here's an excellent reason to use ranges over opApply: you
>>>>>> can't define zip with opApply.  Because opApply uses inversion of
>>>>>> control, you can't use more than one without bringing threads into 
>>>>>> the
>>>>>> equation.
>>>>> Your point stands, of course, but I just wanted to mention that
>>>>> stackthreads/fibers work too and have far less overhead.
>>>> First, don't they have LOTS of memory overhead, because each fiber 
>>>> needs
>>>> a new/separate stack?
>>> A fiber-specific stack needn’t be very large. A few KB is often enough
>>> even for long-running threads; if the call stack is only going to be a
>>> few levels deep you might get away with a few hundred bytes each.
> 
> The Commodore-64 had a stack of 0.25kB shared between your Basic 
> program, subroutine calls, and the operating system. While not unheard 
> of, it still was unusual to have to make amendments to program design 
> because of stack limitations, even in large programs.
> 
> *If* we had a convenient way to record the high-water mark of stack 
> usage for functions (and maybe also threads), then people could have new 
> insights on how little stack space is needed.
> 
> This would be /very/ convenient once we start using thread specific 
> stacks, because the stack space has to be allocated in advance, 
> hopefully not wasting huge amounts of space "just in case".
> 
> Andrei, Walter???

Since C64 programs have gotten a lot bigger, programming style favors 
deeper call stacks, and (mutually) recursive functions are not a rarity.

Computing the stack depth even for non-recursive functions is an 
interprocedural analysis so it's difficult to do modularly. The stack is 
also unchecked so going with a "good enough" approximation is bound to 
be risky.


Andrei