I see on some Forths that there is no zero being stored at the end of the input in the TIB. And that also the TIB is not zeroed out before any input is entered.

During Interpret, which calls WORD, I also don’t see where >IN is compared with SPAN, to end the interpretation.

On another Forth I am working on, Interpret will give strange results on the input line without the ending zero. On the other hand, the ending zero is undesirable when transferring text to a screen or to a text file from the input line.

I am wondering then, what am I not seeing?

If a shorter input is entered into TIB, and TIB has not been zeroed out, then it stands to reason that some existing text from a previous entry still exists in TIB. What is stopping Interpret from going beyond SPAN and trying to interpret old text?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

No, neither of the other Forths I am looking into use #TIB.

I have kind of isolated it down to ENCLOSE, which is part of WORD. It apparently copies each word from TIB to HERE, one at a time, then interprets from there. So to end the INTERPRET phase, ENCLOSE leaves a zero at HERE to signify the end of interpreting TIB.

ENCLOSE is obviously a primitive, so following it to see why it leaves that zero. It is not obvious at first glance.

Yes, this was a common WORD based approach to the outer-interpreter ... since WORD parsed a delimited string as a char-counted string, it needed a transient buffer to receive the parsed string, and in fig-Forth the transient buffer was arranged to be where the word name needed to be for a new dictionary entry if a new word was being defined, so a second copy was not needed when WORD was used to get the name of a word by the ":" word. Since that style of outer-intepreter is using BL as the delimiter handed to WORD, it would not be unusual for a TIB to be blank terminated rather than NUL terminated.

More modern Forths tend to do the outer-interpreter parsing returning a pointer into the original source, with the count in either a variable or on the stack. They don't use WORD in their outer-interpreter, though they might include it for compatibility with user code that relies on it. In many cases, the blank-delimited parser word accepts any character code $00-$1F as white space, in addition to the space character, which avoids problems with interspersed tabs and simplifies working with systems that deliver nul-delimited input strings.

So far I have collected 14 Forth's written for the Apple II computer, which most are early varieties based on '78 and '79 Forth's. There are 4 that would be considered more advanced, with 3 following FigForth, and a recent one I just came across, called UniForth, follows, or tries to follow the '83 Forth standard.

The one I had been working up til now is called ProForth, has a little more flexibility than the other 2 FigForth types, called Mad Apple Forth and QForth.

UniForth has a lot of potential, but too many words that handle the compiling, are created using the Forth language and not primitives. EXPECT is one of those words, and attempts at making it into a primitive seem to break. But there are also many words that are primitives, that seem to have a useless function. But UniForth does have some good ones. Like a fairly full featured Assembler. And, a not too bad screen editor written in Forth, but with poor Control key choices for functionality.

Back to the zero at the end of words, after EXPECT has input a word definition, then when following INTERPRET, it isn't clear how INTERPRET ends. I thought at first the semi-colon was ending a line, but variables and constants don't have semi-colons. There also doesn't seem to be an end with a RETURN char. And EXPECT doesn't store a zero at the end of its input, nor is the buffer cleared with zeroes before EXPECT is called.

I thought I had uploaded a disk image with UniForth on this forum as I think someone might be able to make use of either some of the Forth words or a pretty good Assembler written in 6502 assembly.

According to the fig Forth glossary I found online, INTERPRET is the fig Forth outer interpreter, so it follows from that, it would be an endless loop, like any normal Forth outer intepreter ... barring encountering a word that cannot be interpreted or an abort or crash, it would never end. You parse a word, depending on state and whether it is immediate you compile it or interpret it, if it is not in the dictionary you convert it into a number, then you get the next one. If along the way the text input buffer is emptied, you fill it again, including a prompt for more input if in interpret state.

";" finishes up the definition, compiling EXIT and clearing the smudge bit, and setting state to interpret, but then INTERPRET would continue with the next token encountered.

This is what doesn't make sense though. Variables and constants don't end with a ";", so when interpreting TIB, there needs to be something to indicate end of input.

All the Fig Forths have been programmed with a hidden NULL word to end the input, which is why a zero is put at the end of the TIB. None of the Fig Forths have the word "SPAN" in them nor #TIB. On Fig Forths, EXPECT actually copies the ending zero into the TIB. The problem is, I don't know of a way to program EXPECT to know if it is supposed to include the zero or not. EXPECT actually uses a separate buffer which then uses CMOVE to copy the input to the TIB or to a memory address (like when storing strings). Normally, screens are edited using an external screen editor to Forth and doesn't have this "zero" problem. I am hoping to use EXPECT to edit my screens, but a zero in the middle of a screen will end INTERPRET and disregard the rest of the screen.

UniForth, which is based on '83 Forth, is the first Forth that I have come across that has a Forth editor and has both SPAN and #TIB, but I am not seeing where INTERPRET comes across them to end interpreting in the TIB, nor is there a zero to end interpreting. I was hoping to understand how INTERPRET uses either of these words, so I can then hopefully eliminate the zero in my Fig Forths.

With this all being said, say a fairly long line has been entered into the TIB. And that line has been interpreted. Then the next line is shorter. Some of the remnants of the previous line would be left in the TIB. Without TIB first being cleared or a zero stored at the end of input, or a direct comparison is made to SPAN or #TIB for length of the input, like I said, I am not seeing where INTERPRET is ending.

I was hoping to understand how UniForth does its INTERPRET so that its TIB does not require the zero.

But the end of a definition has nothing to do with the end of a line.



... is perfectly well formed forth. Not including anything after the ";" on a line is just a convention, it is not syntax.

";" ends the definition and changes the state back to interpret mode. Variables, constants, ":" and other defining words need more input because they take the name they are defining from the input stream, but regular compiling words like ";" or "IF" don't care if anything is following them or not.



I'm more familiar with CamelForth than UniForth, so I'll say how it does it. I was wrong when I called INTERPRET an endless loop, it is QUIT that is an endless loop, and INTERPRET is the common factor for interpreting a single chunk of text, whether an input line in TIB, a Forth expression in a string to be evaluated with EVALUATE or in a BLOCK.

CamelForth INTERPRET works with a BEGIN / WHILE / REPEAT loop, where the loop control is:
... BEGIN BL WORD DUP C@ WHILE ... REPEAT ...

... which uses a Forth79/Forth83/ANSForth lineage "WORD" that returns the address of the transient buffer being used by WORD. It is WORD that detects that the TIB is exhausted when it returns a zero-length string.

Now, fig-Forth WORD does not return the address of the transient WORD buffer, but it does work by copying the parsed text into a transient buffer, so if you rewrite WORD so that it first checks whether there is nothing left to parse in the buffer, and in that case rather than parsing, you store a 16-bit zero into the WORD buffer -- one zero byte for the zero count, and one zero byte for the trailing NUL -- that might be enough for the fig-Forth INTERPRET, so that there doesn't have to be a NUL in the TIB itself.