Re: Stacks, was Segments

On 19/01/2025 22:37, Niklas Holsti wrote:

On 2025-01-19 18:33, David Brown wrote:

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

     [...]
 

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.

  Yes. Other C compilers use a single stack but use Y as a frame pointer so they can use "[Y + n]" to access stack-frame locations.
 

gcc for the AVR does that.  I assume that it would be a massive effort to introduce a secondary data stack to gcc, whereas the original AVR port of gcc was much simpler at the cost of inefficiencies (basically the 32 8-bit registers were paired up and viewed as 16 16-bit registers, making the AVR appear like 16-bit RISC processors already well supported, with peephole optimisations to reduce redundant operations after code generation).
Other AVR compilers that were made from scratch, or from compilers that already had complicated stack setups (such as ones for the 8051 you mention below), were more likely to use a separate data stack.
The efficiency advantages and disadvantages of these two arrangements are not clear-cut for the AVR - it depends a lot on the way the code is written.

The issue is more acute for 8051/MCS-51 systems where the call/return stack is in the very small "internal" RAM, so C compilers often allocate a larger "SW stack" for stack data in the larger "external" RAM. But they do so only for potentially recursive or reentrant functions, and instead use statically allocated space for the call-frames of other functions (with smart whole-program analysis to share such space for functions that can never be active at the same time).
 

Yes.  This also applies to several other "brain-dead" 8-bit CISC architectures.