It's still work-in-progress for me with my 65m32 Forth, and I haven't finished exploring all of the dark corners of the defining words, but it seems that I can use s as DSP and x as RSP without any epic failures ... yet. I'm still JSRing to doCONST and doLIST:
Code:
\======================================================== doCON
\ .dw DOLIT-6, COMPO+5,'doCON'
DOCON: \ ( -- a ) \ Run time routine for CONSTANT
\ \ VARIABLE and CREATE
exa ,s \ swap TOS with jsr DOCON's tucked
bra AT \ return addr in NOS, then fetch
\
\======================================================= doLIST
\ .dw EMIT-5, 6,'doLIST'
DOLST: \ ( -- ) \ Process colon list
sly ,-x \ old IP to R:, new IP nipped from
$NEXT \ NOS (jsr DOLST's return addr)
\
Despite that comment copied from Dr. Ting's most recent eForth source), I don't think that CONSTANT VARIABLE and CREATE can all share doCONST ... that will need to be examined further. The "sly ,-x" instruction in doLIST pushes y (IP) on stack X: (RS) and pulls (actually NIPs) a fresh y from implied stack S: (DS). I will to see if I can come up with 65c816 equivalents tonight after work.
[Edit: Yeah, I think that CONSTANT needs the fetch at run-time, but VARIABLE doesn't ... I haven't investigated CREATE yet.
So, I think that doCONST is a
SWAP @ and doVARIABLE is just a
SWAP ... it works to a coding advantage when the address is tucked into NOS automagically by the JSR, at least for the 65m32 ... ]
[Edit #2: Thinking about it more, if TOS was in RAM at s, then doCONST could be reduced to
@ and doVARIABLE could be reduced to a
NOP, just like CELLS and ALIGN already are!! doLIST wouldn't change, but a lot of other primitives would, probably for a net loss ... my primitives are so short that even one added machine instruction blows up the percentage of increase ... ]
[Edit #3: I checked a CamelForth source, and rediscovered that doVARIABLE is supposed to end with a fetch ... the reason I was confused is that the JSR provides an address, but it's the address of an address, and the latter needs to be fetched in the same way that a constant would be ... still pondering the doCREATE mechanism ... ]
[Edit #4: Well, my brain is a bit mushy tonight (in case you haven't already noticed), but I think that if the 65c816 has TOS in RAM, it looks like : doCONST 1+ @ ; should work. The 1+ is due to the 65xx return address being one short of the return target. If TOS is in a register, then it seems to me that you would have : doCONST SWAP 1+ @ ; because the JSR return address would appear in NOS. I am most familiar with DTC ... I can't comment authoritatively on whether ITC or STC would be significantly different, so as usual, YMMV ... ]
[Edit #5: I slept on the ideas, and woke up with the undeniable opinion that you would have to be a brutal masochist to try implementing s as data stack pointer in a 65c816 STC Forth ... the threading technique and the data would constantly be locking horns, and I can't imagine any efficient way around it ... ITC and DTC are a different story, however ... ]