pushing and popping
![Post Post](./styles/we_clearblue/imageset/icon_post_target.gif)
Looking over the Epiphany architecture reference, I see some things that confuse me.
There is a register that is designated as a stack pointer (r13). There are no instructions that are identified as "push" and or "pop," but that's not a big deal, we have some flexible addressing modes.
LDR and STR both feature a "post modify register offset" address mode that looks useful. If you wanted your stack pointer to always point at the next free spot, push and pop would look like this:
; pushing and popping r0
push: str r0,[r13], 0x1
pop: sub r13, r13, 0x2
ldr r0, [r13]
to do a stack, we want BOTH post and pre increment/decrement, or one of those operations becomes two instructions.
I could be wrong, I could be making a fool out of myself in front of everyone here, and it could also be that I'm expecting too much general-purposeness out of what is essentially a floating point hotrod, but I'm playing around with doing a Forth port to the Epiphany architecture, and ease of stack manipulation makes a big difference there.
ALSO:
The way I read the architecture document, the immediate value used for the increment or decrement is scaled according to the size of the data being moved. So if you were only moving one byte/word/double, you'd only ever use an inc/decrement of 1.
Is that correct? This means if we need to do math on the stack pointer directly, it's always being counted as bytes, but if we use the post inc/decrement address mode, the factor changes.
There is a register that is designated as a stack pointer (r13). There are no instructions that are identified as "push" and or "pop," but that's not a big deal, we have some flexible addressing modes.
LDR and STR both feature a "post modify register offset" address mode that looks useful. If you wanted your stack pointer to always point at the next free spot, push and pop would look like this:
; pushing and popping r0
push: str r0,[r13], 0x1
pop: sub r13, r13, 0x2
ldr r0, [r13]
to do a stack, we want BOTH post and pre increment/decrement, or one of those operations becomes two instructions.
I could be wrong, I could be making a fool out of myself in front of everyone here, and it could also be that I'm expecting too much general-purposeness out of what is essentially a floating point hotrod, but I'm playing around with doing a Forth port to the Epiphany architecture, and ease of stack manipulation makes a big difference there.
ALSO:
The way I read the architecture document, the immediate value used for the increment or decrement is scaled according to the size of the data being moved. So if you were only moving one byte/word/double, you'd only ever use an inc/decrement of 1.
Is that correct? This means if we need to do math on the stack pointer directly, it's always being counted as bytes, but if we use the post inc/decrement address mode, the factor changes.