Re: Stacks, was Segments

On 18/01/2025 09:59, Niklas Holsti wrote:

On 2025-01-18 5:08, John Levine wrote:

According to MitchAlsup1 <mitchalsup@aol.com>:

Stacks are small because OS people make them small, not because of
a valid technical reason that has ever been explained to me.
"To avoid infinite recursion" is not a valid reason, IMHO.

>
Algol 60 only had stack allocation for dynamically sized arrays,
so stacks had to be as big as the data are.

>
Huh?  Algol 60 routines could be mutually recursive so unless it was
a leaf procedure or the outer block, everything not declared "own"
went on the stack.

  Mitch's point AIUI was that Algol 60 had no heap allocation (and no explicit pointer types), so indeed all data were either on the stack or statically allocated.
 I'm not an English native speaker, but it seems to me that Mitch should have written "Algol 60 had only stack allocation" instead of "Algol 60 only had stack allocation".
 The most-used Ada compiler, GNAT, uses a "secondary stack" to reduce the need for heap. Dynamically sized local data are placed on the secondary stack, and dynamically sized return values of functions are returned on the secondary stack. So a function can return "by value" an array sized 1..N, with N a function parameter, without needing the heap.
 Of course the programmer then has the problem of setting sufficient sizes for /two/ stacks, the primary and the secondary. For embedded-systems programs one usually avoids constructs that would need a secondary stack.
 

A two-stack setup can be used in C too.  (The C standards don't require a stack at all.)  On the AVR microcontroller, it is not uncommon for C implementations to work with a dual stack, since it does not have any kind of "[SP + n]" or "[SP + r]" addressing modes, but it /does/ have an "[Y + n]" addressing mode using an index register.
Two stacks are also pretty much required for FORTH.
The use of a dual stack could also significantly improve the security of systems by separating call/return addresses from data.