I think this is lawyering a bit. There might not be a "heap", per se, but there is stack allocation (which is embedded all the way into the ISA) and "everything else". You can, after all, build a simple "heap" on top of an adequately large static buffer.

Since this is a distinction that is very important both for performance in high-level languages and for correctness in C, and one C forces you to think about and makes plain without having to reason through escape analysis and closures, I think the previous comment's point is well taken.

The distinction is important for apartmented thread models, such as those found on Windows, where you do have multiple heaps, and pointers allocated on one are not valid in another.

Stack allocation of return addresses is embedded in most ISAs- but stack allocation of local variables isn't (because that's not A Thing at the ISA level).

Consider, say, shadow stacks- local variables might end up living on a totally separate "stack" from the one "call" pushes onto and "ret" pops from, and one which the ISA has no idea about.

In what sense is stack-relative addressing, PUSH, POP, and addition/subtraction on the stack pointer not ISA-level support for stack allocation of local variables?

Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right.

PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead of bp/sp-relative addressing? Most compilers seem to be much happier representing each stack frame as "a bunch of slots, some for things where the address is taken so it needs to be in memory, and others where I spill things into as needed".

On ARMv7 (i don't know enough about v8 / AARCH64), "push"/"pop" are just stores/loads with postdecrement / postincrement.

Is this lawyer-y? Sure. But I think it's still correct, and this being HN...

On x86, push/pop have dedicated hardware optimizations known as the stack engine which perform most of the rsp increments/decrements and passes those offsets into the decoder, instead of using executions slots on them. push/pop are also much smaller than the corresponding mov/add instructions.

It's much more optimal to use a series of push/pops for smaller operations like saving registers before a call than to manually adjust and store onto the stack.

While technically this is still incrementing/decrementing a register and storing, the amount of isa/hardware support for such things clearly demonstrates that the x86 isa and modern x86 hardware gives special treatment to the stack.

There's a reason 32-bit ARM has 'move base register down and then do some stores' and 'do loads and then move base register up' (stmdb and ldmia) rather than just plain old ldm and stm, and I'm pretty sure it's because it makes the entry and exit sequences for function calls with a stack shorter. (The ARM ISA doesn't privilege a downward growing stack, so you can use stmib and ldmda if you want your stack to grow upward; the Thumb ISA, however, does want a downward stack for push and pop.)

That's definitely a large part of it, but it also makes small memcpys nicer (load sizeof(foo)/4 registers from sourceptr with post increment, store them to destptr with post increment)

They may not be distinguished at the instruction level, but if you’re trying to argue it’s not a useful thing to teach you’ve lost me. Dynamic vs static vs scoped (stack) allocation is incredibly important to reasoning about basic programs.

Like I established in my opening comment, C tells you how software works, not how hardware works. Regardless, you're still wrong in several ways here. Making it out of several discontinuous regions of memory doesn't make your heap less of a heap. Most architectures also provide instructions for loading data from the stack and optimize for this purpose, using their caches more efficiently and making design decisions which have clearly been influenced by the C (or System V) ABI.

For your definition of 'computer', perhaps. Many microcontrollers have the stack defined by the hardware.

And some, such as RISC-V, have no predefined stack pointer at all. (Push and pop are implemented by doing them manually; call is implemented by the jump instruction optionally taking an argument for a register to use as the stack.) C, at best, teaches you the C abstract machine, which supports both of these concrete implementations equally well.

Leaning how microcontrollers work is not the same as 'learning how the computer works' in general, which is the subject at hand.