All my work is done with raw blocks, and more my simulator, I just have simple piece of block storage (mapped to a file by the simulator, naturally). It should also be noted that for BLOCK files, the lines of code are not terminated by any end of line markers. Historically, the 1024 bytes are mapped to 16 lines of 64 bytes each. Note in Forth, a "SCREEN" is ostensibly a BLOCK that represents source code, a BLOCK is just a BLOCK with a buffer, a SCREEN is actual code versus who-knows-what.

For your example using INCLUDED, this won't be a problem. The system will naturally skip the end of line markers of a text file.

But for BLOCK files, they simply don't exist. So if you type out a BLOCK file, you'll just see a big, run on stream of consciousness dump that looks like Forth.

I appreciate the criticisms of the Forth Screen model for source code, like the Genie in Aladdin: "Infinite power -- itty bitty living space."

But the BLOCK I/O words in Forth are really pretty elegant and give a lot of power to a simple system.

Yesterday I tried entering my Mandlebrot program into Tali Forth and it caused a reset. With some digging I found that the following code causes a reset:


I am embarrassed to admit that I ported it, got it working at a basic level, but failed to notice a major bug. I thought maybe it was a recent bug, but checking out an earlier base level of the code still has it. In fact the only base level that doesn't is the one before this fix in Tali-Forth.asm:



Which I added upthread to get the high level words working. But with this bug it causes an unknown word error for IF rather than a reset which isn't much better. My forked github repo is here: https://github.com/Martin-H1/TaliForth in case anyone has any ideas.

Martin

I just fired up py65mon and found something interesting: When I put the code all in one line, it works fine: This is the way I usually write stuff. But when I divide it up over various lines, it crashes right after I hit the ENTER button after DO: That fits with the STATE problem. Interestingly, though, a multi-line IF works fine: I'll try to get more testing done the next few days. (My, after all that coding with the 65816 this 8-bit stuff really makes your head hurt - or maybe that is a side effect of Christmas )

Thanks for reproducing my problem. The single line versus multiple lines makes perfect sense, as I was almost certain I tried a DO loop previously!

I learned C before FORTH, so I often block structure my code following C indent rules. It makes it easier for me to switch back to my day job writing Java and JavaScript code.

Update: By putting the Mandlebrot program's two main loops on one line the program works as expected in Tali Forth.

So, after getting the family to bed, a bit more detailed look.

1. LOOP (or +LOOP) prevent crashing if in the same line as DO. If there is no LOOP in that line, Tali will crash after whatever is the last entry in the line.

2. Everything up till then is correctly compiled, starting with (DO) and continuing until the end of the line. The crash occurs at the first address after the last byte of compiled code. Put differently, it crashes to the Compiler Pointer (CP), aka what HERE would give us. This makes sense, because in the py65mon emulator, the unused memory locations are all zero (BRK).

3. The crash happens before the "compiled" message can be printed.

4. DO and ?DO are both affected, which is to be expected, because they share the same code. No other words seem to have this problem.

5. The code after the DO is executed (!) once before the crash, even though it really, really shouldn't be. Take this small bit of code: If you hit ENTER after that, "frog" is printed once. A complete session: This also works with stuff like "1 1 + ." as well. This means that we're not jumping directly to the current CP, but futher back to at least after the compiled (DO) routine.

6. Possibly we're even entering before then. Compile-time DO actually does start off by saving HERE to the Return Stack, then compiles six dummy bytes $05 as placeholders (which unhelpfully compile to 3 x ORA $05), then compiles (DO), which calculates the "fudge factor" for the loop. None of that would cause a crash if it were to execute during compile-time, so the 00 (BRK) at the end of the compiled code would be the first stop.

The next step is to trace exactly where we're landing by inserting some breaks and whatnot, but that's all I have time for today. Ye gods, I forgot how complicated the loop machinery is ... I'm glad I wrote down how it works in plain text in a separate file back then.

Wow -- that is SO wrong . What a cool bug.

I agree, from a bug esthetics point of view it's neat.

What I think is neat is I wrote the Mandlebrot program on a 64 bit Linux system using gforth, and except for replacing the word 2* with 2 *, and the single line DO bug, the program works on a 16 bit system. The precision is a bit reduced, so a few points along the negative real axis that aren't in the set show up in the set, but it mostly works. Who says Forth isn't portable!

I plan to try it against the BASIC version using ehBasic to see how Forth stacks up in terms of speed.

Nice to hear, that was the aim: Programs should work on both gforth and Tali, or have a good reason not to.

I've confirmed that the bug originates in the logic around line 6678 of Tali-Forth.asm, when the CP is pushed to the Return Stack: Currently, the six $05 place holder bytes and the compiled (DO) code are executed during compile time (though they really, really shouldn't be). Now we have to figure out why that address gets left there if there is a linebreak.

(Obvious Hypothesis: Normally, at compile time LOOP pulls that address off the Return Stack in line 6380 so it knows where to put the address code. If, however, the line is terminated before we get to the loop, something consumes that address on the Return Stack during one of the RTS. This would seem to be a problem specific to a STC Forth.)

So, bug found and hopefully squashed: DO puts the address for LOOP on the Data Stack instead of the Return Stack. What it was doing there in the first place, I do not remember, but there you go. Did some testing with various loop constructs (see list of test words in docs/testwords.md for details), though only time will tell in absence of a formal test suite.

One test did completely fail, though: Wait, what? It turns out that EXIT is not coded, at all, AWOL, völlig verschwunden, gone, not in the Dictionary, though it's in the list of words that are marked as coded. So that's what I'll be doing next, I guess.

Martin, thanks again for pointing out the bug!

Glad to help. When you push it to github I can merge it with my source and give it a whirl.

Should be there now.

I pulled from upstream, rebuilt, reflashed, and DO now works when it spans multiple lines. So the bug is slain.

BTW I tried using FORGET and got an unknown word.

From ANSI-Forth 1994:

http://www.forth.org/svfig/Win32Forth/DPANS94.txt


I believe that some or all of the functionality of FORGET can be found in MARKER .

Mike B.

What Mike said: FORGET is not in ANSI Forth, and you're supposed to use MARKER instead.

I'm using REFILL for the first time for input with Liara Forth, which is the recommended way in ANSI. It seems like an extra step at first, but once you realize that it really, really wants to work with SOURCE-ID, it actually makes sense.

Thanks Mike and Scot. I will brush up on using Marker.