Yet another even worse ISA fanfiction from yours truly
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)
Yet another even worse ISA fanfiction from yours truly
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.
Yet another even worse ISA fanfiction from yours truly
@koakuma so what's the additional weakening of the mem model here?
Yet another even worse ISA fanfiction from yours truly
@robryk In traditional processors, if you were to do something like
SP -= something
store XX -> [SP]
SP += something
load [SP-something] -> YY
Even though it is formally illegal, it is still guaranteed that XX = YY; in my model that guarantee would be lost
Yet another even worse ISA fanfiction from yours truly
@koakuma ah, so raising the stack pointer in some sense invalidates the part of the stack that's not legal to access. Thanks, that makes sense.
Yet another even worse ISA fanfiction from yours truly
@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?