Page 2 of 3
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Sun Feb 05, 2017 3:52 pm
by whartung
How do you check for stack underflow? How is the empty stack indicated when TOS is in a register?
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Sun Feb 05, 2017 4:27 pm
by nyef
How do you check for stack underflow? How is the empty stack indicated when TOS is in a register?
The same way as when TOS is not in a register, just with a slight bias to the idea of where the stack starts.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Sun Feb 05, 2017 5:09 pm
by barrym95838
Yeah, what nyef said. The memory footprint is slightly different, but if (x == SP0), then the stack is empty. Period.
Mike B.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Sun Feb 05, 2017 7:45 pm
by whartung
so, X is still the stack pointer, and you INX and DEX it, but the TOS just happens to be in a register, so the "normal" TOS is essentially an under word of memory, is that it?
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Sun Feb 05, 2017 8:46 pm
by barrym95838
Yeah, here's what an empty stack looks like with TOS in RAM (higher numbered addresses on top for all examples):
Code: Select all
----------------
SP0-> nonsense <-sp
----------------
nonsense
----------------
nonsense
----------------
...
----------------
Here's what what a stack with two items looks like with TOS in RAM:
Code: Select all
----------------
SP0-> nonsense
----------------
NOS item
----------------
TOS item <-sp
----------------
...
----------------
Here's what an empty stack looks like with TOS in A:
Code: Select all
----------------
SP0-> nonsense <-sp A = register nonsense
----------------
nonsense
----------------
nonsense
----------------
...
----------------
Here's what what a stack with two items looks like with TOS in A:
Code: Select all
----------------
SP0-> nonsense
----------------
register nonsense
----------------
NOS item <-sp
----------------
nonsense A = TOS item
----------------
...
----------------
The memory cell at SP0 should never be touched in either method unless you under-flow the stack (assuming that you pre-decrement before a push and post-increment after a pull).
The register nonsense in the last example came from whatever happened to be in A when the stack was initialized, and can be safely ignored.
Mike B.
[@Scot: you appear to have a typo in line 496 of
https://github.com/scotws/LiaraForth/bl ... forth.tasm]
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Mon Feb 06, 2017 10:22 am
by scotws
The version online is still the TOS-Y, so the comment is in a bad place, but the actual code is (AFAIK) okay - first we make room on the stack, then TAY pushes the result on top.
Neat drawings - when this is all over, we should write some sort of document on this
.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Mon Feb 06, 2017 1:31 pm
by scotws
After actually recoding various parts of Liara to TOS-in-X, it turns it really doesn't change stuff much (which I think was Garth's position all along). It makes some things slightly clearer, but also requires adding lda.dx 00 (LDA $00,X) at some spots where before you could just use Y as TOS. So it's slightly slower.
Since I set out to make this a "speed first (within reason)" Forth, I'm going to take the "dude, stop whining and fix your damn code" path and stick with TOS-Y despite the added complexity. Going back did make stuff clearer (especially thanks to Mike), so this was worth the time to go over it again.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Mon Feb 06, 2017 4:38 pm
by barrym95838
I should have been more specific about the typo. Just search for the string "sty.d 00", and you should find it. It has drifted to line 507, as of this morning.
Mike B.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Mon Feb 06, 2017 4:42 pm
by scotws
Ah, got it now. Thank you!
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Mon Feb 06, 2017 6:33 pm
by GARTHWILSON
After actually recoding various parts of Liara to TOS-in-X, it turns it really doesn't change stuff much (which I think was Garth's position all along). It makes some things slightly clearer, but also requires adding lda.dx 00 (LDA $00,X) at some spots where before you could just use Y as TOS. So it's slightly slower.
My approach in my '816 (actually '802) IDT Forth was to reduce the number of times NEXT, nest, and unnest have to run by making a lot more of the standard words primitives (ie, code definitions), words that are usually written as secondaries (ie, colon definitions). Then there are the headerless optimizations like DUP >R which goes a lot faster if it is merged and made to be a single primitive.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Tue Feb 07, 2017 12:41 am
by barrym95838
I think that Scot is using a custom variety of STC, Garth.
@Scot: have you considered the possibility of changing:
Code: Select all
stx.d tmpdsp
lda.# dsp0
sec
sbc.d tmpdsp
bpl quit_ok
lda.# es_underflow
jmp error
quit_ok
...
to something like:
Code: Select all
cpx.# dsp0
bcc quit_ok
beq quit_ok
lda.# es_underflow
jmp error
quit_ok
...
???
Mike B.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Tue Feb 07, 2017 10:46 am
by scotws
My approach in my '816 (actually '802) IDT Forth was to reduce the number of times NEXT, nest, and unnest have to run by making a lot more of the standard words primitives (ie, code definitions), words that are usually written as secondaries (ie, colon definitions).
It's a STC Forth, so my influence on NEXT is limited ... however, I have been trying to make a lot more stuff primitives because with the 65816, you can really, really see the difference. I'm trying to be clever about it, though, since something like .S is interactive, and so can be slower, and I'm using more JSR/RTS in those situations where I was doing assembler with Tali. Which really,
really has to be rewritten when Liara is up and running ...
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Tue Feb 07, 2017 11:49 am
by scotws
@Scot: have you considered the possibility of changing: (...)
I have this bad tendency to brute-force all tests first and tell myself that I'll go back later and do the right thing. Thank you, definitely better, will include and test this evening.
Also, congratulations! You are now officially the second person on the planet to have written code in Typist's Assembler Notation. Amazing growth rate, right?
Next step is world domination,
bwuhahahaha ...
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Wed Feb 08, 2017 2:46 am
by barrym95838
... Thank you, definitely better, will include and test this evening ...
Well, if definitely better isn't quite good enough, how about definitely best (AFAIK)?
Code: Select all
cpx.# dsp0+1
bcc quit_ok
lda.# es_underflow
jmp error
quit_ok
...
You can shave a few cycles from MINUS by changing:
Code: Select all
lda.dx 00 ; NOS
sty.dx 00 ; TOS
sec
sbc.dx 00
to:
You can shave a few cycles and a few bytes from ABS by changing:
Code: Select all
...
sty.d tmp1
lda.# 0000
sec
sbc.d tmp1
tay
...
to:
You can shave a few cycles and a few bytes from REFILL by changing:
Code: Select all
...
cmp.# 0ffff
bne refill_source_is_not_string
; Simply return FALSE flag as per specification
dex
dex
sty.dx 00
ldy.# 0000
to:
Code: Select all
...
inc.a
bne refill_source_is_not_string
; Simply return FALSE flag as per specification
dex
dex
sty.dx 00
tay
You can eliminate the
and.# 00ff at the beginning of
byte_to_ascii.
You can eliminate the
jsr nibble_to_ascii rts at the end of
byte_to_ascii.
I can't find @ (FETCH) and ! (STORE) in your source ... did you really make it this far without using them, or am I just looking in the wrong places?
Mike B.
Re: Liara Forth, an "ANSI(ish) initial Forth" for the W65C26
Posted: Wed Feb 08, 2017 12:11 pm
by scotws
Thanks for all the improvements, though I am getting an headache for slapping my forehead with each one.
Won't get to implement the changes until this evening, so just theoretically -
I assume that's a CLC and not a SEC, or am I not doing the logic in my head right?
Not FETCH or STORE yet, you are right, which is kind of silly, I'll see about getting to that this evening (since I can't enter numbers other than 0, 1 and 2 yet, STORE is not that useful at the moment).
I've been trying to code Liara so that there is always some form of a working system after every step, starting the point where I got the main loop going, and so far, that has worked. With EVALUATE in place, I can get rid of most of the "scaffolding code" for printing the boot strings (need
.( before, of course, but that is now trivial). Next big steps will be CREATE so I can work my way to COLON and SEMICOLON after testing stuff with VARIABLE and CONSTANT. Then things should go faster.
Thanks again!