TOS in zero page?

[larsbrinkhoff]

Hello,

Have you considered putting the top element of the data stack in the zero page? I have a vague sense this would be a win.

[larsbrinkhoff]

Paging @chitselb. Pettil does use a zero page TOS.

[chitselb]

TOS is at $02..03 (on the PET and VIC20), overlapping Sweet16's R1. On machines that use $00..01 as an I/O port, this gets shifted upward by two bytes. The remainder of the data stack is split int low bytes at $20..4F and high bytes at $50..7F.

[jkotlinski]

Hi! Yes I considered it, but lda nn is only one cycle faster than lda nn,x so it's hard to see where any huge wins would come from. It feels like one would gain some, lose some, and in the end it would be about the same.

[larsbrinkhoff]

Right, in many words the size comes out the same. A few words take a hit, but I believe there are more cases where it's a win. In particular, memory fetches and stores benefit a lot from being able to use the address TOS in zero page indirect mode.

I'm coding up both versions for a new Forth, so I'll get back with actual code samples and total size for the kernel.

[jkotlinski]

Indeed @ gets faster but since typical use is addr @, and addr will be slower, my impression is that this might not really be much of a win. Especially since you will later use the fetched value and then again will need to refresh the TOS.
I look forward to your code samples and measurements!

[larsbrinkhoff]

My ephasis is on small size, not speed. It turns out I was able to optimize the no-TOS version quite a bit by sharing code between primitives. I haven't been able to share as much code in the TOS version.

Here's a detailed listing of primitives, with code size in bytes.

	No TOS	TOS
dup	10	10
drop	2	8
2drop	1	1
swap	17	17
over	7	10
>r	18	19
r>	13	10
r@	16	21
+	15	15
1+	7	7
and, or, xor	12	13
invert	13	13
2*	5	5
2/	8	8
@	24	17
c@	6	7
!	15	6
c!	8	6
branch?	6	10
Total	203	203

[jkotlinski]

Hi! Ok, so I take it then that it is better to keep things as is and not have a dedicated TOS element in zp. Thanks for sharing!

On Tue, 5 Sep 2017 at 07:38, Lars Brinkhoff ***@***.***> wrote: My ephasis is on small size, not speed. It turns out I were able to optimize the no-TOS version quite a bit by sharing code between primitives. I hasn't been able to share as much code in the TOS version. Here's a detailed listing of primitives, with code size in bytes. No TOS TOS dup 10 10 drop 2 10 2drop 3 4 swap 17 17 over 7 10 >r 18 19 r> 13 21 r@ 16 19 + 15 15 1+ 7 7 and, or, xor 12 13 invert 13 13 2* 5 5 2/ 8 8 @ 24 17 c@ 6 7 ! 15 10 c! 8 9 branch? 6 10 *Total* 205 224 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#199 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADG-O9vMQ01YMwpP-H14v_j8fs5L7C7Tks5sfN5wgaJpZM4PKCBl> .

-- --- http://www.littlesounddj.com

[larsbrinkhoff]

Ok, so I take it then that it is better to keep things as is and not have a dedicated TOS element in zp.

Not if you go for the smallest code size. I'm not sure if you want to optimize for speed.

Here are some code samples. They're in my own Forth assembler syntax.

No TOS	TOS
code dup stack-lo ,x lda, stack-hi ,x ldy, dex, stack-lo ,x sta, stack-hi ,x sty, rts, end-code	code dup tos lda, tos 1+ ,x ldy, dex, stack-lo ,x sta, stack-hi ,x sty, rts, end-code
code drop inx, rts, end-code	code drop inx, stack-lo ,x lda, stack-hi ,x ldy, tos sta, tos 1+ sty, rts, end-code
code c@ stack-lo ,x lda, w sta, stack-hi ,x lda, w 1+ sta, 0 # ldy, w ),y lda, stack-lo ,x sta, stack-hi ,x sty, rts, end-code	code c@ 0 # ldy, tos ),y lda, tos sta, tos 1+ sty, rts, end-code
code ! stack-lo ,x lda, w sta, stack-hi ,x lda, w 1+ sta, 0 # ldy, stack-lo 1+ ,x lda, w ),y sta, iny, stack-hi 1+ ,x lda, w ),y sta, inx, inx, rts, end-code	code ! 0 # ldy, stack-lo ,x lda, tos ),y sta, iny, stack-hi ,x lda, tos ),y sta, ' 2drop jmp, end-code

[jkotlinski]

For Durexforth I came to think that speed is more important than size. C64 anyway has "a lot" of RAM and so far I haven't gotten complaints that people run out. Speed improvements are more noticeable. I am not sure if that is an argument in either direction for the TOS. But anyway.

[larsbrinkhoff]

Update! I have now managed to squeeze down the TOS version to the exact same size as the no-TOS version.

I'm not sure what this means for speed. Zero page addressing is one cycle faster than indexed addressing, but the need to copy data in and out of TOS may make it come out the same or slower anyway.

[jkotlinski]

A thing that would weigh slightly in favor of "classic" approach then is that DROP/2DROP can be an inlined inx.

On Tue, 5 Sep 2017 at 10:13, Lars Brinkhoff ***@***.***> wrote: Update! I have now managed to squeeze down the TOS version to the exact same size as the no-TOS version.

I'm not sure what this means for speed. Zero page addressing is one cycle

faster than indexed addressing, but the need to copy data in and out of TOS may make it come out the same or.

—

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#199 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADG-O9kkXcvSH2LmSs-Uuv-BYkYBYIG1ks5sfQKOgaJpZM4PKCBl> .

-- --- http://www.littlesounddj.com

[chitselb]

Sorry for being late. I just saw this in my gmail. One of the main reasons for isolated standalone separated TOS is so it could be used as a (tos),y pointer without having to create a pointer from stackl+stackh. Another big reason is that unindexed z.p. operations are a clock or two faster than using zp,x for everything. But it would probably speed things up a bit. Trading off speed vs. size isn't always fun. Garth Wilson thinks the PETTIL approach to the data stack was a bad idea, and he's usually right about these things.

[larsbrinkhoff]

Thanks @chitselb. What did Garth think was right, just a plain stack with no special TOS treatment?

[chitselb]

At this point I don't even remember. It was a couple years ago at least, somewhere on forum.6502.org Forth section, in a thread I participated in (if you're in a mood to go searching I'd be curious to see what he said again, please drop a link here?)

[chitselb]

well. that was easy. http://forum.6502.org/viewtopic.php?f=9&t=3280

[larsbrinkhoff]

Looks like this thread:
http://forum.6502.org/viewtopic.php?f=9&t=3280

[chitselb]

I concur. That is the thread, http://forum.6502.org/viewtopic.php?p=11215#p11215 and that is the message I refer to. We're both going on gut-feel here, it seems, with few solid metrics. I have done some small amount of experimenting with benchmarking PETTIL vs. Blazin' Forth in side-by-side emulators, and PETTIL beats the pants off of it. Probably that's more the direct-threaded vs. indirect-threaded thing, and the attention I try to pay to speed/size tradeoffs throughout

[larsbrinkhoff]

It looks to me like Garth is also objecting against a split stack, i.e. low bytes separated from high bytes.

[jkotlinski]

[Reopening this issue to preserve the interesting discussion]

[jkotlinski]

FWIW, this Forth went from plain to split zeropage stack in v1.32. The change was mentioned in the changelog as a "nice optimization" :)

[chitselb]

With a split-stack-separated-TOS setup, it's cumbersome to copy the 2OS to and from the TOS. But burying stuff just underneath in the stackl,x stackh,x memory is pretty cheap and convenient, and primitives could take advantage of that. Consider the following, that pops y bytes from the machine stack and stores on the data stack:

machinestack_to_datastack
    ldy #3    ; # of bytes to `pla`
loop
    dex
    pla
    sta stackl,x
    dey
    beq ciao
    pla
    sta stackh,x
    dey
    bne loop
    rts
ciao
    sty stackh,x
    rts

I have similar routines, harvests and plants to move data back and forth between 2os -- xos and n0..n8 (z.p. area overlaying the Sweet16 registers r2..r10). A word like cmove that takes a few arguments on the stack can jsr harvests to pull things and jsr plants to push them back. I think of them as potatoes because it all happens just below tos

harvests
    lda stackh,x
    dey             
    sta n,y        
    lda stackl,x 
    inx              
    dey             
    sta n,y        
    bne harvests
    rts

pass
* Y = how many words *2 to push to the stack, e.g. Y=6 pushes 3 words
returns
* Y = 0
* TOS unchanged
* Z flag set
* C flag unchanged
plants
    dex
    lda n,y
    sta stackh,x
    lda n-1,y
    sta stackl,x
    dey
    dey
    bne plants
    rts

The idea is to have single reusable chunks of code to move small blocks of data among the various entities: memory; machine stack; data stack; N-area

[jkotlinski]

FYI, I did some soul searching, trying to figure out the reason why I did not put TOS as a separate zp register already.
I think in the end it comes down to how fun it will be to write assembler code for the Forth.
Currently it's very simple to push and pop values to the stack - just read/write the value and inc/dec x as needed.
With a non-contiguous stack, there is the extra book-keeping of juggling things between TOS and stack, which I'd rather not have to deal with. I think it's as simple as that!
If I only wrote pure Forth code, the trade-off would maybe be a bit different. But on the C64, I think mixing Forth with assembler is healthy.

[kghultland]

Interesting topic, I should really spend some time reading the issue-graveyard to get insights from the main development of Durexforth :D