search

scotws / TaliForth2

A Subroutine Threaded Code (STC) ANS-like Forth for the 65c02
Other
86 stars 23 forks source link

REFILL doesn't check for BLK #231

Closed scotws closed 5 years ago

scotws commented 5 years ago

Oh, look what I found at the beginning of refill (about line 7900):

; Get input source from SOURCE-ID. We don't have blocks in this
; version, or else we would have to check BLK first.

Oops. All tests pass, so we can leave this for after Version 1.0, also because I have no idea any more what the problem with refill and blocks was.

scotws commented 5 years ago

source-id might also have to be changed because it is involved in blocks somehow, or at least we should mention it in the comment.

SamCoVT commented 5 years ago

REFILL is never used on blocks because Tali is able to EVALUATE the entire block as a 1024-byte string directly out of the block buffer. If there is a LOAD or THRU in a block, Tali is nice and puts the original block back when it's done so that EVALUATE doesn't have to know that we used the buffer for something else temporarily and can just continue EVALUATing away from wherever it left off.

Older Forths, like FIG Forth, had smaller blocks, so it might take four 256-byte blocks to LOAD an entire screen.

It might be safe to just remove the comment. I can give it a good looking at after Version 1.0 is released, just to be sure.

One side effect of the way we currently handle blocks is that you can't run any block buffer altering words (like BLOCK, for example) by putting them in a block and LOADing that block. Only the words LOAD and THRU are nice enough to put things back they way they found them (if BLK wasn't 0 initially) and ANS does require that. ANS doesn't really say much about this, from what I could find, but it does describe the exact action (interpreting directly out of the buffer) we are using for LOAD. It also mentions that the restricted operations (that may invalidate a block buffer) apply to the address returned by SOURCE when the input source is a block, so I suppose that vaguely indicates you shouldn't do that (and that we don't have to fix it).

As a side note, xt_source: around line 9480 has a comment "paranoid, should be zero" for the upper byte of the length of the source buffer, but that's no longer true as Tali can interpret directly from long strings and now blocks as well. The code is fine, but the comment should be removed.

SamCoVT commented 5 years ago

source-id shouldn't need anything more than a comment, as it's only valid when BLK is zero. Tali does the right thing with BLK and when Tali sets BLK back to 0 (because it's finally done evaluating a block) the source-id will be correct for wherever the load or thru command came from.

scotws commented 5 years ago

Thanks for the explanation, I've updated the comments, and that should be all we have to do, so I'll just close this again. Took out the "paranoid" line as well, thanks, I had actually missed that one.