[jhgb]

> No, it doesn't. C does not even assume a stack. A platform where function call frames are allocated on the heap would not be incompatible with C.

The problem is not with call frames being on the stack or on the heap; even a spaghetti stack would be problematic. One of the problems is that return addresses and data are interleaved in C-style frames, whereas multiple stack machines require them to be separate. It's not that you couldn't write an implementation of C for a stack machine, it's just that it would be probably very primitive and slow. Yes, you can run C at the very least the way it was done on Lisp machines, by allocating a large byte array and treating it as your physical memory, but surely you would want to avoid it if you could. There really is a reason why stack machines historically ran somewhat exotic languages like Forth.

[cryptonector]

No, really, the C language makes no assumptions about this.

[jhgb]

You can't take an address of pretty much any input parameter, return value, or local variable of a function on a stack machine because they're all on the stack CPU core's hardware data stack which has no addresses for its elements. In C you should be able to take the address of these objects, using an ampersand. That's not making an assumption?

[cryptonector]

If it's addressable memory, you can address it. That does not assume a stack however. You don't get to assume that they are in some order, not if you want your code to be portable. On typical architectures that do use a stack, if you're very careful, you do get to use the addresses of automatics to figure out whether the stack grows up or down, but that's not specifically something in standard C.