JimBoyd wrote:
... Notice 64Forth's WORD does not leave an address on the data stack.
Yes, that's a big difference between fig Forth and Forth-79/Forth-83 Forth's.
From
https://dwheeler.com/6502/fig-forth-glossary.txt:
Code:
ENCLOSE addr1 c -- addr1 n1 n2 n3
The text scanning primitive used by WORD. From the text address
addr1 and an ascii delimiting character c, is determined the byte
offset to the first non-delimiter character n1, the offset to the
first delimiter after the text n2, and the offset to the first
character not included.
This procedure will not process past an ascii 'null', treating it
as an unconditional delimiter.
IN --- addr L0
A user variable containing the byte offset within the current input
text buffer (terminal or disc) from which the next text will be
accepted. WORD uses and moves the value of IN.
WORD c --- L0
Read the next text characters from the input stream being
interpreted, until a delimiter c is found, storing the packed
character string beginning at the dictionary buffer HERE. WORD
leaves the character count in the first byte, the characters, and
ends with two or more blanks. Leading occurrences of c are ignored.
If BLK is zero text is taken from the terminal input buffer,
otherwise from the disc block stored in BLK.
See BLK, IN.
IamRob wrote:
I am starting to think the zero at the end of the line only refers to Forth's that deal with screens and not text files. Not only does Interpret end when interpreting a word, but screens also end when trying to list a screen if a zero is accidentally stored in the middle of a screen.
It's part of the fig-Forth model, and fig-Forth's did their file access with Blocks ... but Forth79 allowed using NUL as a delimiter to mark exhaustion of the input stream. In Forth-79, the delimiter is stored at the end of the word, so "DUP COUNT + C@" would get the delimiter or NIL back if you wanted to find out whether there was more text in the stream.
Code:
WORD char -- addr 181
Receive characters from the input stream until the non-zero
delimiting character is encountered or the input stream is
exhausted, ignoring leading delimiters. The characters are
stored as a packed string with the character count in the
first character position. The actual delimiter encountered
(char or null) is stored at the end of the text but not
included in the count. If the input stream was exhausted as
WORD is called, then a zero length will result. The address
of the beginning of this packed string is left on the stack.
Using "NUL or delimiter" as the end of parsing was a useful approach when a single word was used for both parsing for a word like "(" with ")" as the delimiter and a blank-delimited word.
In the 80's and 90's, when the approach of a separate word with white space that is anything from space down to NUL became more common, using a less than $21 comparison rather than an equality to $20 comparison, at the same time, it became more common to use text files and INCLUDE because the PC-DOS systems that Forth was running on had more capable text file editing systems.
Login
Register
FAQ
Search
