Page 10 of 19
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Sun Nov 04, 2018 1:51 am
by dourish
When I did the blocks code for my own Forth, I put together a basic screen editor with emacs-ish keybindings. It just presumes that it's talking to an ANSI-compatible terminal or terminal emulator, but these days, that's pretty much everything. It also presumes 16 lines of 64 characters for 1K blocks. Happy to share if it would be useful.
--p.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Sun Nov 04, 2018 6:43 am
by nyef
My own (rampantly non-standard standalone x86 PC) Forth uses 16/64 block organization as well. It presumes something on the order of an 80x25 display and a PC-type keyboard for the editor, but a certain amount of that is hidden behind some fairly factorable interfaces (CLRSCR, GOTOXY, SKEY (could be EKEY?), a TEXTCOLOR variable, stuff like that). It's a "visual" type of editor, but I didn't go so far as emacs-ish keybindings.
One of the fun features of the third major revision of the editor is that you can ^Z to get to an interpreter prompt that appears below the editor area, and ^Z between the two without losing your place in either.
Looks like 11 blocks of source for versions 2 and 3 of the editor, plus 3 more for the interpreter prompt integration. Because why would your block editor not be distributed in source blocks?
If anyone is interested, I'd be happy to share the source. And at some point I may rebuild it for a more standard-compliant system and possibly for an ANSI-type terminal interface.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Sun Nov 04, 2018 9:42 pm
by scotws
I'd love to see how you guys handled the editor, there doesn't seem to be much code out about how they worked. Thank you! We have AT-XY working, and Sam says he knows how to do GET-XY, so that's the basis we have here as well.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Sun Nov 04, 2018 9:53 pm
by scotws
So here is some interesting information on 65c02 code in Tali: I wrote a small, throwaway program in Python 3 to find out which mnemonics are being used most, and some other information (see code_statistics in the tools folder). It goes through the program files (main python words, disassembler, ed editor, and main program) and counts stuff. This gives us:
Code: Select all
Lines read: 11709
Labels found: 979
Local labels found: 210
Comments found: 3382
Directives found: 347
Opcodes found: 4907
So yes, there is roughly one comment every 1.5 mnemonics, which I think qualifies as "rampantly over-commented". But more interesting is the frequency of mnemonics used. The top ten:
Code: Select all
lda: 933 19.0%
sta: 716 14.6%
jsr: 493 10.0%
inx: 258 5.3%
dex: 198 4.0%
jmp: 185 3.8%
bne: 162 3.3%
adc: 135 2.8%
stz: 123 2.5%
bmi: 116 2.4%
You can
really tell this is a SBC based Forth: The enormous number of JSRs, and all the INX/DEX stack manipulations. The BMI is from the code for underflow checking, which after seing this I'm wondering if should go into a subroutine after all, I hadn't really realized how many times we call that.
It's not really worth the trouble at the moment to try to break down the various mnemonics in their actual opcode variants (it would be trivial with my assembler notation, alas, this is Ophis). The rest of the list:
Code: Select all
cpx: 115 2.3%
inc: 111 2.3%
ldy: 111 2.3%
beq: 96 2.0%
pla: 89 1.8%
sbc: 85 1.7%
clc: 84 1.7%
ora: 83 1.7%
bra: 78 1.6%
iny: 74 1.5%
cmp: 71 1.4%
pha: 66 1.3%
dec: 55 1.1%
rts: 47 1.0%
sec: 44 0.9%
bcc: 39 0.8%
dey: 34 0.7%
sty: 28 0.6%
tya: 25 0.5%
ply: 24 0.5%
and: 23 0.5%
tay: 22 0.4%
bcs: 19 0.4%
phy: 17 0.3%
txa: 17 0.3%
tax: 16 0.3%
bpl: 16 0.3%
cpy: 12 0.2%
ror: 12 0.2%
asl: 10 0.2%
plx: 10 0.2%
eor: 9 0.2%
lsr: 8 0.2%
rol: 7 0.1%
ldx: 6 0.1%
bit: 4 0.1%
stx: 4 0.1%
bvs: 4 0.1%
tsx: 3 0.1%
bvc: 3 0.1%
phx: 2 0.0%
txs: 2 0.0%
cld: 1 0.0%
brk: 1 0.0%
clv: 1 0.0%
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Sun Nov 04, 2018 11:26 pm
by JimBoyd
The BMI is from the code for underflow checking, which after seing this I'm wondering if should go into a subroutine after all, I hadn't really realized how many times we call that.
? I'm curious, how did you implement underflow checking? My Forth also uses the lower part of zero page for the data stack. It's for a Commodore 64 so the stack can't grow as far down as locations 0 and 1 ( 6510 data direction register and data register built into the cpu ). It is also an ITC Forth.
I only implemented underflow checking in addition to
INTERPRET's stack checking where I could get it with zero overhead. The x-register = hex 7E when the stack is empty.
The code for
2DROP and
DROP checks for underflow just before jumping to
NEXT
Code: Select all
SCR# 7
// POPTWO POP
HEX
SUB 2DROP.BODY ( N1 N2 -- )
HERE TIS POPTWO
INX, INX, // 2DROP'S CFA POINTS HERE
HERE TIS POP
INX, INX, // DROP'S CFA POINTS HERE
NEXT 0< NOT BRAN,
80 # LDX,
NEXT JMP, END-CODE
The line with
BRAN, compiles a
BPL to
NEXT
If there is an underflow, set it to underflow by one cell ( 2 bytes ) to protect the Forth virtual machine registers (
XSAVE,
UP,
N scratchpad area etc ) while keeping an underflow condition that will be caught and delt with by
INTERPRET.
(DO) does something similar ( it doesn't jump to
NEXT ).
If you were wondering,
SUB compiles a constant in the host dictionary which points to the target's current free memory location, its version of
HERE in virtual memory ( the C64 REU ), and sets up the metacompiler assembler.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Mon Nov 05, 2018 10:36 am
by scotws
I'm curious, how did you implement underflow checking?
By comparing the minimally required depth of the Data Stack with the actual depth.
Code: Select all
cpx #dsp0-3
bmi +
jmp underflow
*
DSP0 is the Data Stack Pointer when the stack is empty, and -3 means four bytes (because of the zero etc), so we expect two entries. If there are less than two, the comparison turns negative and we jump to the underflow error routine. There is a longer explanation of this and how to strip off those checks for your own words at
https://github.com/scotws/TaliForth2/bl ... rnals.adoc .
This is a classic speed/size trade off at the moment (see
https://github.com/scotws/TaliForth2/issues/165): We could move this code to someplace as a subroutine, and then save 224 bytes, but at the cost of 12 cycles per underflow check for the subroutine jump. In a loop, that really ads up quick. At them moment, we have ROM to burn from the 24 KByte reserved for Tali, so we leave it like this. It would, however, be nicer to have something like this in hardware with an interrupt.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Mon Nov 05, 2018 10:07 pm
by JimBoyd
This is a classic speed/size trade off at the moment (see
https://github.com/scotws/TaliForth2/issues/165): We could move this code to someplace as a subroutine, and then save 224 bytes, but at the cost of 12 cycles per underflow check for the subroutine jump. In a loop, that really ads up quick.
Which is why I only add underflow checking ( other than that done in the interpreter loop ) if I can get it with zero overhead, although it's more like underflow limiting rather than checking since it limits the extent of the underflow and lets the interpreter handle it.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Tue Nov 06, 2018 1:21 am
by whartung
Which is why I only add underflow checking ( other than that done in the interpreter loop ) if I can get it with zero overhead, although it's more like underflow limiting rather than checking since it limits the extent of the underflow and lets the interpreter handle it.
How can you get underflow checking with zero overhead?
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Tue Nov 06, 2018 4:52 am
by GARTHWILSON
How can you get underflow checking with zero overhead?
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Tue Nov 06, 2018 10:45 am
by scotws
Yes, that's how Tali 1 did it. My problem was that my programs kept not working (cough) and it was hard to figure out why. The compromise here is to have it enabled by default for the core words and allow "underflow stripping" for new words where that code can be automatically removed once you sure it works.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Tue Nov 06, 2018 11:02 pm
by JimBoyd
Yes, that's how Tali 1 did it.
Was Tali originally indirect threaded code?
My problem was that my programs kept not working (cough) and it was hard to figure out why.
Did your underflow checking correct the underflow?
The compromise here is to have it enabled by default for the core words and allow "underflow stripping" for new words where that code can be automatically removed once you sure it works.
What my underflow checking does is leave the stack in a state of underflow but only one cell deep so
INTERPRET will abort with an error showing the line with the offending word when it checks the stack. There are six bytes between address hex 7E ( the stack empty position ) and address hex 84 (
N-1 ) so a one cell ( 2 byte ) underflow is harmless. As for the phantom values dredged up from an empty stack, just be careful with
CMOVE and friends.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Wed Nov 07, 2018 11:47 am
by scotws
Was Tali originally indirect threaded code?
Oh no, always subroutine threaded (SBC). I'm very happy with it because of the massive amount of inlining you can do.
Did your underflow checking correct the underflow?
No, error routine with reset -- if it blew up, I want to know why quickly. It's sort of an Erlang-Forth that way
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Wed Nov 07, 2018 8:54 pm
by JimBoyd
My problem was that my programs kept not working (cough) and it was hard to figure out why.
Did your underflow checking correct the underflow?
No, error routine with reset -- if it blew up, I want to know why quickly. It's sort of an Erlang-Forth that way
Did the underflow checking interfere with figuring out why your programs kept not working? When you say reset, it reset the processor? Maybe it would be better to abort in the outer interpreter.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Thu Nov 08, 2018 8:53 am
by scotws
No, sorry, I wasn't being clear there (I need to stop writing these things too late at night) - Tali 1 didn't have underflow checking, there was just a floodplain. I'm sure somebody who is better at Forth would have been fine, but I just kept having things going wrong and didn't know why. When I have achieved Forth enlightenment (or at least the Third Jhana) I'll rewrite a version without the checks
.
Re: Introducing Tali Forth for the 65c02 (ALPHA)
Posted: Fri Nov 09, 2018 10:11 pm
by JimBoyd
No, sorry, I wasn't being clear there (I need to stop writing these things too late at night) - Tali 1 didn't have underflow checking, there was just a floodplain. I'm sure somebody who is better at Forth would have been fine, but I just kept having things going wrong and didn't know why.
Understood.
When I have achieved Forth enlightenment (or at least the Third Jhana) I'll rewrite a version without the checks
.
The third what?