Although Garth seems to avoid the main question, he does bring up a really good point of buffers and arrays being put in available memory between PAD and LIMIT.

I think we can all agree that the space between HERE and PAD is basically strictly for creating numeric expressions and has nothing to do with WORD copying entire lines at HERE. From what I can see, ." only puts text at HERE during compiling, and <# #> only puts a numeric string below PAD during Run time, there should be no conflict. For personal use I think the space between HERE and PAD can be safely reduced to about 32 as that more than covers the longest DATE/TIME string most will ever create, or more if the need requires it. Maybe the space separation between HERE and PAD should be put into a variable to make it easier to adjust.

As for PAD itself, which is mostly used for temporary strings being compared to text within a buffer, should itself have a restricted cap on it. And that restriction would be the C/L line length. So then a check should be made when using PAD so that PAD + C/L, does not interfere with the buffers or array storage.

I took a use-case from Applesoft which uses a HIMEM pointer. Whenever I assign a buffer or array, I move HIMEM pointer to the beginning of that memory to protect it, and if I use PAD, I compare PAD + C/L with HIMEM for an Out-of-Memory condition.

These are my words for testing for Out-of-Memory. All values given in HEX

73 constant himem ( Applesoft uses $73.74 of zero-page and I use $73.74 of Direct Page )
first himem !
: addbufr ( -- bufadr ) himem @ 400 - dup himem ! ;
: rmvbufr himem @ 400 + first max himem ! ;
: mem himem @ pad c/l + - dup u. ." (" decimal u. hex 8 emit ." ) bytes free" cr ;

Notice I left the new bufadr on the stack when adding a buffer. This helps when I need that value to know where to store arrays or copy data to be protected. But removing a buffer does not require that value.

As I was converting WORD to a primitive, I noticed it only clears 34 bytes to spaces at HERE. I think this is all the room it thinks it will need.

_________________
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?

From what I gather WORD only moves the text to HERE only for temporary use for printing a line or skipping a comment or compiling a word, which does not affect either the numeric data area or PAD at that time, as they are only temporary storage spaces.

For the most part from what I can see, it is ok if WORD tramps on the numerical data area or PAD if the space were smaller, as they are never used at the same time. WORD can still move a 64 or 128 character line to HERE with the gap between HERE and PAD set to 32 bytes and still not hurt anything.

When I was asking, Why, I was looking for a response that showed me a way that WORD was being used that might interfere or conflict with the numerical data area or PAD. I still don't see any conflict, because I still have not seen WORD being used at the same time as the numeric data constructs and/or PAD.

About the only way I can see WORD trouncing on the numeric data area while it is being used is if there is a comment or print statement between the numeric construct statements <# and #>. Of all the examples using the numeric constructs, I have not seen any on their own line with a comment following them. But I suppose it is possible, and it would have to be a long comment to do any damage.

_________________
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?

After some testing and a few memory dumps later, I have come to the conclusion that the max space between HERE and PAD need only be 24 bytes and has nothing to do with a word being defined, but has to do with the longest decimal number that can be entered. A word definition that is copied to HERE that is 25-31 characters is compiled separately and does not interfere with the numeric data area or PAD.

As for numeric expressions, the longest entered number is a 32-bit hex "FFFF 7FFF" or its decimal equivalent (-2147483648) which is only 11 characters for the decimal word. To print the decimal number requires it to be entered as a word to HERE, then NUMBER deciphers it. Then 13 characters at HERE (1 for the length byte and 1 for the space at the end of the word) and 11 for the numeric output only uses 24 characters.

If your Forth can handle 64-bit, then the largest 64-bit decimal number is -9223372036854780000 requires 22 + 20 = 42 space gap required at HERE. My Forth doesn't do that.

The only test I haven't done much with is building a numeric expression as the only example I have to go off of is the one at D.R. But for the most part, doing a DUMP of the memory at HERE definitely shows what is going on.


On another note, during testing I found a bug in which a 32 character word will crash my FigForth.

I wrote a better description for WORD for FigForth. Instead of it clearing 34 spaces after HERE every time, it just stores one space after the enclosing the word and copying it to HERE, whether it be a definition word or a number

Change from this:
to this:
This one also does some error checking if no word or number is copied to HERE but stores a zero instead. INTERPRET could then read the zero at HERE to see if there is a valid word or number at HERE and exit cleanly if not.

[1] The size of the region identified by Word shall be at least 33 characters.
[2] The size of the PNO string buffer shall be at least (2*n)+2 where n is the number of bits per cell (double number when BASE=2, plus . plus sign).

For a 16bit Forth, that is 34+33=67.

You are close. 67 is almost 68. So I have to commend you for that.

But in what computer world does a bit equal 2 bytes? Even in binary, a 0 or 1, would still only need 1 byte per bit to make a printable character to screen. 32-bits + length byte + space char. But your example does give me some more testing ideas.

As for step [1], identifying a Word is still only done during compiling and will not conflict with any numerical expressions be done as they are only done during run-time. For me, allotting any space for a word during compiling is still redundant.

I am now convinced a minimum of 34 bytes are needed as a buffer between HERE and PAD for Forths that can print a 32-bit binary number and 66 bytes would be needed for Forths that can print a 64-bit binary number. A Forth that can print a binary number of 128 bits would need 130 bytes between HERE and PAD.

We are getting there. Some things are starting to make more sense.

It doesn't ... if you have a 16bit forth, than a double number in binary has 32bits, which can be 32 characters.

Yep, gotcha. You were talking printable double binary numbers.

And WORD can be used in command line utility words as well as being used by the interpreter (as long as it's done with the text by the time the next word is interpreted), so the WORD buffer shouldn't overlap the PNO buffer. So allow two characters to be added to the pictured numeric buffer ( , $ . - etc.), the chars that WORD needs, there's the required space.

It's been a while since I programmed in fig Forth ... is the WORD count byte at HERE, or two bytes above HERE? If the WORD count byte is two chars above HERE, WORD might need 34 spaces (two plus count byte plus up to 31 chars).

Thanks for bringing some new light to how Forth can be used. This is in uncharted territory for me.

But still looking from the perspective of creating a numeric string. The only words in FigForth that use the PNO buffer are (. D. D.R and ?), which use the <# #> constructs to form a numeric output in the PNO buffer. This is a closed command loop which means the numeric output is formed, closed and printed before moving on to interpreting the next word. And since the PNO buffer is no longer needed after the numeric print out, it should be available for use again even when the next word comes along for interpreting, whether by the interpreter or by a command line utility. Therefore, it still shouldn't be necessary to reserve that space for a WORD that is copied to HERE, since it would not harm anything if it over-lapped into the PNO buffer.

From what I can see, the only time that the PNO buffer would be used at the same time as any type of word interpretation is if something was being created between the <# #> constructs. D.R uses the TYPE command to immediately print the contents of the buffer, and like I have said before, I haven't done much with the numeric constructs to know if something might be created in the buffer, but held there for a later printing or handling of it, and then might possibly interfere with a word being interpreted.

I am still convinced, for the most part, that words being copied to HERE have nothing to do with the gap space between HERE and [b]PAD[/b], mostly because I have not seen any examples showing both areas used at the same time, where they might interfere with each other.

And I am still wondering if anyone came across any use case that might require a larger PNO buffer. Printing a double binary number is the largest use-case I have been shown so far at 34 bytes for a 16-bit printed double word (66 bytes for 32-bit dbl words and 130 bytes for 64-bit dbl words). FigForth is based on 16-bit, so all calculations are done with that in mind. I also mentioned one earlier where a newspaper prints the date line in long format, could be pretty long. I don't think I have ever seen any real-world examples where numeric output would need to span a full line of 64 characters, like a newspaper or book.

Are there any others?