Refactor - Dynamic Stack #638
Conversation
|
|
||
| ### from v1 | ||
| - `add64 reg, imm` can use `r11` as destination register | ||
| - `add64 reg, imm` can also use `r10` as destination register |
There was a problem hiding this comment.
Perhaps a better wording here is "Only add64 reg, imm can use r10 as a destination register".
There was a problem hiding this comment.
But stores can still use R10 as dst, right?
There was a problem hiding this comment.
Maybe "Only add64 reg, imm can modify R10"?
There was a problem hiding this comment.
The semantics are in execution, the verifier can only decide what dst regs are allowed.
| /// Frame pointer register | ||
| pub const FRAME_PTR_REG: usize = 10; |
There was a problem hiding this comment.
Should we start calling it stack pointer for the new version?
There was a problem hiding this comment.
Maybe, but different PR. Also, v0 will continue to exist.
| call function_foo | ||
| mov r0, r10 | ||
| exit | ||
| function_foo: | ||
| add r10, -64 |
There was a problem hiding this comment.
Can we test stores and loads with positive offsets from R10? Just like test_string_stack.
Lichtso
force-pushed
the
refactor/dynamic_stack
branch
from
7a20be2 to
9afb4cf
Compare
Lichtso
force-pushed
the
refactor/dynamic_stack
branch
from
9afb4cf to
d517ed2
Compare
R11 is removed and instead R10 is modified directly and its changes visible immediately. This means that R10 is always the lower end of the currently executing functions stack frame and all stack accesses must be encoded relative to that.
Additionally, the verifier allows
add64 r10, immand checks that theimmis 64 byte aligned.