Devlog 7 Reverting Code
November 22, 2022
It seems I may have made a few mistakes in my previous session. I’ll need to revert some code.
I knew I had read about the
TOS register somewhere else.. it was in Brad Rodriguez: Moving Forth pt.1, where he mentions the major downside of a
a push becomes a push followed by a move
I’ll revert to only using a
TOS (as per my original design) and once more review my primitives.
The review will start from the top. I’ll remove my new
DUALPOP macro. I’ll also remove
PUSH because I don’t think they’ll be needed anymore. In the future if I notice some repetitive code then I’ll convert them to macros, but for now I think we can live without them. I’ll also remove the
RCALL macro because I honestly have no idea what it’s for.
Reviewing primitives pt2
We’ll start with
FETCH only uses the
TOS and is confirmed working as expected:
# ! ( x addr -- ) Store x at addr defcode "!", 0x0102b5c6, STORE, FETCH lw t0, 0(sp) # load the DSP value (x) into temporary sw t0, 0(s3) # store temporary into address stored in TOS (addr) lw s3, CELL(sp) # load second value in DSP to TOS addi sp, sp, 2*CELL # move DSP up by 2 cells NEXT
It was changed to load the value of
x at the top of the
DSP, into a temporary register
t0. It then stores that value into the memory address
addr pointed by the value stored in the
s3). Finally, it moves the next value in the
DSP over to the
TOS and adjusts the stack size to reflect the two values that were removed.
Next, for the
DSPFETCH primitive, we want to place the current address of the stack pointer
DSP into the
TOS. Then we’ll copy the
DSP into the
TOS, and move the stack pointer down by 1 cell:
# sp@ ( -- addr ) Get current data stack pointer defcode "sp@", 0x0388aac8, DSPFETCH, STORE sw s3, -CELL(sp) # store the value in the TOS to the top of the DSP mv s3, sp # copy DSP to TOS addi sp, sp, -CELL # move the DSP down by 1 cell to make room for the TOS NEXT
I’m assuming we want to store the current stack pointer address in the
TOS before moving the pointer to a new address.. so technically if we run this twice in a row we’ll get consecutive addresses (off by 4).
We do something similar for the
RSPFETCH primitive except we’re copying
# rp@ ( -- addr ) Get current return stack pointer defcode "rp@", 0x0388a687, RSPFETCH, DSPFETCH sw s3, -CELL(sp) # store the value in the TOS to the top of the DSP mv s3, s2 # copy RSP to TOS addi sp, sp, -CELL # move the DSP down by 1 cell to make room for the TOS NEXT
I’m already noticing a pattern between
rp@, so let’s see if I can reorganize those into a macro which moves the
TOS value into the
DSP and the moves the stack pointer down by 1 cell. I can probably call it, oh.. let’s see… how about
# push register to top of stack .macro PUSH reg sw s3, -CELL(sp) # store the value in the TOS to the top of the DSP mv s3, \reg # copy reg to TOS addi sp, sp, -CELL # move the DSP down by 1 cell to make room for the TOS .endm
This simplifies our
defcode "sp@", 0x0388aac8, DSPFETCH, STORE PUSH sp NEXT defcode "rp@", 0x0388a687, RSPFETCH, DSPFETCH PUSH s2 NEXT
Haha. I had a feeling I would end up needing
PUSH once more. Of course, the above code is almost identical to the sectorforth implementation, so I’ll assuming i’m on the right track.
There’s still a few more primitives to review and adjust, but I’ll take a break for now and let these changes sink in before continuing in the next sesssion.