On 8/16/23 2:06 PM, Jerry Coffin via Std-Proposals wrote:
> > To my knowledge, there has never been a C++ compiler for a processor
> > that doesn't have a stack.
>
> What do you mean by "stack"?
>
> There are certainly C++ compilers for IBM mainframes, which don't have
> a stack as a thing that's supported by the hardware.
>
> Their C++ compiler uses their Language Environment™. They have 31-bit
> and 64-bit addressing modes.I'm not sure exactly how it works in
> 64-bit mode, but in 31-bit mode, the "stack" is basically a linked
> list of separate chunks of memory.

z/OS executables built with xplink, use both an upward growing stack
(for traditional non-xplink enabled code) and a downward growing stack
(for xplink enabled code). As function calls occur, state is
pushed/popped on the relevant stack for the callee. xplink uses a biased
stack pointer to enable end of stack probing and to facilitate
allocation of, and transition between, stack segments.

Tom.

>
>
> On Mon, Aug 14, 2023 at 4:45 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> To my knowledge, there has never been a C++ compiler for a processor
> that doesn't have a stack.
>
> You can find some C compilers for some very small microcontrollers
> that don't have a stack, but not C++.
>
> So how about we have a function to get the stack pointer, which would
> look something like:
>
> __asm__ (
> ".text\n"
> "stack_ptr:\n"
> #if defined(__i386__) // x86 (32-bit)
> "mo4v %esp, %eax\n"
> "ret"
> #elif defined(__x86_64__) // x86_64 (64-bit)
> "mov %rsp, %rax\n"
> "ret"
> #elif defined(__aarch64__) || defined(__aarch64__) // AArch64
> (ARM 64-bit)
> "mov x0, sp\n"
> "ret"
> #elif defined(__arm__) // ARM (32-bit)
> "mov r0, sp\n"
> "bx lr"
> #elif defined(__mips__) // MIPS
> "move $v0, $sp\n"
> "jr $ra"
> #endif
> );
>
> And also how about we standardise the function "alloca" which allows
> us to allocate bytes on the stack? For those not familiar with
> 'alloca', here's the Linux manual entry:
>
> https://man7.org/linux/man-pages/man3/alloca.3.html
>
> And here's a quick excerpt from that manual page
>
> The alloca() function allocates size bytes of space in the
> stack
> frame of the caller. This temporary space is automatically
> freed
> when the function that called alloca() returns to its caller.
> Because it allocates from the stack, it's faster than malloc
> and free. In certain cases, it can also simplify memory
> deallocation in applications that use longjmp or siglongjmp.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>