Continuing from https://uwu.social/@koakuma/109950625250284703

Actually hell, let's go even further with this thinking

Let's split the entire SP thing into two, SB (stack base) and ST (stack top), with some invariant enforced between them (e.g for stack-grows-down systems, SB >= ST).
Now add an instruction to adjust ST: `adjst [signed-immediate]`
Also, make all stack accesses ST-relative (i.e ldsp/stsp -> ldst/stst), and weaken the memory model even more; for this code:
```
adjst -WORD_SIZE
stst %r1 -> [%st+0]
adjst +WORD_SIZE
ldst [%st-WORD_SIZE] -> %r2
```
... make it so that %r1 is *NOT* guaranteed to be equal to %r2.

The intention is to make stack space creation/destruction explicit to the processor itself (and not coherent with heap accesses) so it can avoid actually writing anything to memory for short-term allocations.

(inb4 AArch64 already does this)

@koakuma

What _would_ allow one to read writes to the same mem loc done at a different ST in this model? I'd expect function arguments to require that.

@robryk Exactly, function calls is one of them, however that is not problematic because they are usually done in this manner:

caller:
stst %arg -> [%st+ARG_OFFSET]
call callee

callee:
adjst -EXTRA_SPACE
ldst [%st+EXTRA_SPACE+ARG_OFFSET] -> %arg

And this would still be legal since the callee load doesn't load any region past ST - the only problematic case is if you try to load anything past ST (i.e ST - something)

@koakuma

Aaah, I didn't realize that sign was important there.

@robryk I mean accessing memory past the end of stack (+ maybe a couple extra bytes in the red zone) is already illegal by the rules in most ABIs anyway no?

@koakuma so what's the additional weakening of the mem model here?