Prevent ALLOT from releasing too much memory about taliforth2 HOT 6 CLOSED

A negative value for ALLOT can currently overwrite parts of the original Dictionary.

from taliforth2.

I never realized you could give allot negative values.
I have a bunch of questions:

When you say ALLOT can overwrite parts of the original dictionary, are you talking about the words in forth-words.asc that are compiled into ram on startup?

I see some code checking against cp0, but that's where the transition between the RAM dictionary and the ROM dictionary takes place. Losing that first word with the link seems bad. Does it make any sense to have an empty word there, just to maintain the link, and have allot stop at that word (fixed offset beyond cp0) rather than at cp0?

Do you think adding something like the FENCE variable from fig-forth makes sense?

What is supposed to happen if you allot negative too far? You'll be in the middle of a previous word/variable and writing new stuff will trash things. I'm looking at the standard and it doesn't seem there is any safety on this word. Is the goal, then, to just have Tali attempt to survive and keep going the best it can with a possibly damaged dictionary?

from taliforth2.

Yeah, negative ALLOT threw me as well, but it's in the standard -- https://forth-standard.org/standard/core/ALLOT -- amusingly, though, it says "( MISSING TEST: NEGATIVE ALLOT )" as well. The ANSI Forth standard is rather rough around the edges in some places, which could partially be because a lot of people didn't like the whole idea of a standard version of the language. Also, since there is no traditional lexer and parser, nobody is forced to sit down and really map everything out.

I've handled those cases by a) seeing what Gforth does, because they give the impression they know what they are doing, and if that doesn't work, b) do what seems sane and document it.

The definition of ALLOT in Gforth is

: allot here + dup 1- usable-dictionary-end forthstart within -8 and throw dp ! ;

which I figure means: add the number given to HERE, see if it is still between the end of the "usable dictionary" and the beginning of the Forth area, and if not, throw an error.

In our case, I had thought about using a MARKER, say "Forth", as the last high-level word defined at boot. That way, ALLOT would only be allowed to go back to where the "Forth" mark lives in the Dictionary. That would be our version of "usable-dictionary-end", and for "forthstart" we'd use where the buffers for the command line history start. However, I haven't tested MARKER yet, and the one time I used it, it exploded in my face, but that was early days.

from taliforth2.

A bit of experimenting with Gforth gives the following behavior for negative ALLOT if the freed space is still above the original Compiler Pointer (cp0): Any word defined in that space will work as long as nothing new is added, but then if you do store something at the new CP, those words affected will crash. In other words, the Dictionary Pointer is not changed.

from taliforth2.

Interestingly, Gforth lets you free all kinds of space beyond the initial HERE address with no apparent ill effects to the Dictionary -- right off the bat you can do -1000 ALLOT and it won't phase Gforth the least. Huh.

from taliforth2.

So. My first instinct was to say, this is Forth, the users are supposed to be adults, and if they want to free memory all the way into the Dictionary, who are we to tell them not to?

However, the problem is that we're going to have people using Tali to test stuff on an emulator before the move to their own hardware. Since py65 (for example) does not protect the ROM parts of memory from overwriting, we could cause hard-to-explain differences between emulation and hardware. Also, I'd like the system to be stable enough to survive something like this at least in a minimal usable state (enough to run COLD maybe).

My suggestion therefore: We let the user crash and burn in the RAM area that is assigned to the Dictionary (up to CP0, which is $0300). If the user goes beyond that, we set the new CP to CP0 (which we already do), have DP point to the last word defined in ROM (DROP), and print an error. And document all of this.

from taliforth2.