pushing and popping

[bithead]

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.

[timpart]

[bithead]

[timpart]

[bithead]

[notzed]

FWIW most of the C abi and the way LR works comes from the ARM - so you've been using it but just didn't need to know about it. I think adapteva could've done a bit better to suit the arch (and code-size constraints) such as r7 for sp but it's irrelevant if you're doing your own thing.

The ABI does modify the ARM stack convention so that it always has 8 bytes above SP free; which does let you get away without the need for the separate arithmetic for leaf functions (which can use that 8-bytes for scratch/storing something).

e.g.

strd r4,[sp],#-1
strd r6,[sp]
...
ldrd r6,[sp],#1
ldrd r4,[sp]
rts

May not be of use to forth though.

(been a looong time since i looked at forth so apologies if none of this matches modern forth or my memory).

Also your posts have stack going up, but stack growing downwards lets you pick 0 ... 7 with 16-bit instructions (for hard-coded picks), negative offsets require 32-bit instructions.

It may not fit with the forth idea of an argument stack but if you can keep an 8-byte aligned stack it's probably worth it otherwise you end up with 2x the code-size just on register save/restore. Or just have a different stack for register saves vs the forth argument stack.

On interrupts, a global flag polled in an inner loop could be placed into a reserved register to speed it up/save the need to use scratch. Since you have total control over the execution of the machine maybe you could re-direct the interpreter from the interrupt 'implicitly' and use this to avoid the need for the poll entirely.

Simple idea:
; r62 = interrupt/system stack pointer
; r63 = inner loop start address
mov r63,#inner_loop
inner_loop:
... do the inner loop
jr r63

Normal operation, it just loops. An ISR could then just redirect it:

isr_dma0done:
str r63,[r62],#-1
mov r63,#dma0done
rti

Save it so it can handle nested interrupts. This simple example loses any priority though.

dma0done:
.. does whatever it does (alternative or redirect of inner loop)
gid
sub r62,r62,#-4
ldr r63,[r62]
gie
jr r63

Well ... maybe something like that might work.

[timpart]