You have to use the stack for procedure calls on x86/x86-64 CPUs, where the hardware enforces this.

In most other surviving CPU ISAs the return address is saved in a register and it is easy to arrange in a compiler to use only procedure arguments that are passed in registers, the only price being paid for this being a reasonable upper limit for the number of parameters of a function, e.g. 12 or 24, depending on the number of general-purpose registers (e.g. 16 or 32). For the very rare case when a programmer would want more parameters, some of them should be grouped into a structure.

With this convention, which normally should not be a problem, there is no need for a call stack. There can be software managed stacks, which can be used even for implementing recursion, when that is desired.

The use of static memory for passing function arguments was necessary only in the very early computers, which were starved in registers.

▲ RealityVoid 2 days ago | parent | next [-]

I believe it's possible to do what you've described, but I am not aware of any compiler that does this.

What do you get by doing it like this?

Also, in your described structure, how do you handle nested function calls? I'm sure there exists a convoluted scheme that does this, but not sure with the current call assumptions.

You also lose ABI compatibility with a bunch of stuff.

And regardless, I mostly program in Risc-v and ARM -most compiles like to pass arguments on the registers, but use the stack anyway for local context.

	▲	jcalvinowens 2 days ago \| parent [-]
		You can do it on x86 too, just use jmp instead of call and invent your own arbitrary register scheme for it. This x86 program has no stack: https://github.com/jcalvinowens/asmhttpd I don't think it's too hard to imagine a compiler that does that, although it would obviously be very limited in functionality (nesting would be disallowed as you note, or I guess limited to the number of registers you're willing to waste on it...).

▲ 0xffff2 2 days ago | parent | prev [-]

I honestly can't tell if you know a lot more than me or a lot less than me about how computers work... A couple of honest questions:

1. Where do you save the current value of the return address register before calling a function?

2. When parameters are "grouped into a structure" and the structure is passed as an argument to a function, where do you store that structure?

▲ RealityVoid 2 days ago | parent | next [-]

Not OP, but presumably, the answers are:

1) You don't... hence, my question about no nested function calls. If you push it anywhere else, you can call it whatever you want, but you just re-invented the stack. I _guess_ you could do some wierd stuff to technically not get a stack, but... again, it's wierd. And for what, again?

2) Some fixed address. If you have for example:

```c

typeRealBigStructure foo;

void baz(typeRealBigStructure * struct){

    // Do whatever to struct

}

void bar(void){

  baz(&foo);

}

```

The foo will probably end up in the BSS and will take up that space for the whole lifetime of the program. That's not the heap, not the stack, just... a fixed location in memory where the linker placed it.

I guess on big PC's stuff is very dynamic and you use malloc for a lot of stuff, but in embedded C, it's a very common pattern.

	▲	0xffff2 2 days ago \| parent [-]
		Ah, you're right, the struct case is actually pretty straightforward (especially since recursion is likely forbidden anyway), I just have trouble contorting my brain to such a different viewpoint.

▲ quietbritishjim 2 days ago | parent | prev [-]

The sibling comment already answered your question, but just to add: As I mentioned earlier, this was actually how old programming languages worked. Famously(ish), Dijkstra secretly snuck recursive functions into the ALGOL 60 standard, thus forcing compiler authors to use a stack!

https://news.ycombinator.com/item?id=10131664