Yet another strike against the current AA implementation

[Georg Wrede]

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


PS, on the 6502 (the C64 CPU), the stack was hard wired to 0100-01FF. 
This made the processor vastly simpler, which was essential for cost 
savings in an era where an additional transistor in the processor did 
cost an arm and a leg.

The area before the stack was used with 8-bit addressing, which was 
faster, and traditionally it was used more or less as an extension to 
processor registers, because the 6502 only had the X, Y, A, PC, and 
Flags registers. The area after the stack was free for the circuit board 
designer to use in any way he liked. On the C64 this was used for ROM, 
memory mapped peripherals, IO, the heap, and the program area. 
Interestingly, self-modifying code was used for keyboard input, to 
enhance speed and code size. This concept was copied from the VIC-20, 
which came with 3k of usable RAM.