Here's '
C@X', written using the split stack (sans 16-bit TOS z.p. register) and incorporating Hugh's idea of overwriting the half-stack to use (zp,X) addressing. '
@X' would be similar, with the aforementioned penalty of doing a 16-bit increment (of stackl,x and stackl+1,x in this model). It comes out to 15 bytes, the same as '
C@' in the code Mike posted below.
The advantage of this method is I don't spend clock cycles copying things in and out of TOS.
To me this feels cumbersome vs. using the (zp),Y addressing mode I get, along with Sweet-16's sixteen 16-bit registers in 00..1F (PETTIL's TOS overlaps R1 at 02..03). PETTIL also lets primitives use this 32-byte area for my version of local variables.
I looked at a few different ways of doing the data stack in PETTIL before picking the way I did, probably because
reading this article sold me on the split stack with a unified TOS.
Code:
;--------------------------------------------------------------
#if 0
name=C@X
stack=( addr -- byte )
Like `C@`, but uses (zp,X) addressing mode in an imaginary
PETTIL environment where I rewrite everything else too
#endif
cfetchx
ldy stackl+1,x
lda stackh,x
sta stackl+1,x
lda (stackl,x)
sty stackl+1,x
ldy #0
jmp put
barrym95838 wrote:
IMO, Charlie is doing some very nice work with only NMOS instructions in his PETTIL project. Here's a sample from
here:
Code:
;--------------------------------------------------------------
#if 0
name=@
stack=( addr -- 16b )
tags=forth-79,nucleus,memory,fig,forth-83
Leave the 16 bit contents of address.
!!! pronounced:"fetch"
16b is the value at addr.
#endif
fetch
sec
.byt $29 ; AND #
;--------------------------------------------------------------
#if 0
name=C@
stack=( addr -- 8b )
tags=forth-79,nucleus,memory
!!! pronounced: "c-fetch"
8b is the contents of the byte at addr.
#endif
cfetch
clc
cfetch01
ldy #0
lda (tos),y
bcc put
pha
iny
lda (tos),y
tay
pla
bcs put
;--------------------------------------------------------------
I believe he has spent quality time making the split-dictionary and split-stack with separate TOS work ... he's a very good NMOS coder, IMO. If you have carnal knowledge of your system, you can even do things to make it more efficient, like doing a NIP DROP instead of a DROP DROP (Charlie's NIP is INX).
My 65m32 DTC Forth has a single machine instruction NEXT, and a whole bunch of primitives ( enter branch + 0< 1+ 1- 2* 2/ >R @ AND DROP DUP EXIT INVERT NEGATE OR R> SWAP UNLOOP XOR [ ] NIP RDROP 2RDROP ... I'm sure that I'm forgetting a few others) that are one machine instruction plus NEXT. That kind of screams out for a change to STC with in-lining, but I am floundering in an endless sea of incomplete projects, so this one will have to get pushed back at least until my house is ready for winter. I estimate that I have a couple of hundred man-hours of work to do on the house, and I only have Sundays to do it (my six-day-a-week job exhausts me to the point that I can't do much at night, and I can only afford to hire amateur help). I also estimate that I have a couple of hundred hours of work to do on the 65m32 simulator, assembler, and minimal operating system (probably Forth) before I can even consider trying to implement it on an FPGA board. It most certainly doesn't matter how slick my system software is with no processor on which to run it. Ay, Chihuahua ...
Mike B.
Login
Register
FAQ
Search
