Words after a ?do ... loop don't run if the ?do ... loop never runs. about taliforth2 HOT 4 CLOSED

I'm trying to understand this bug, but I don't have a super clear picture of how do ... loop works.

It looks like your version copies a chunk of assembly directly into the dictionary (rather than jsr this and jsr that) to actually perform the work needed to make do and ?do work, and it looks like ?do has its own version of this assembly (which makes sense to me so far.)

Original Flawed Understanding

I believe the issue is that the current code uses an rts at the end of question_do_runtime (line 2363 in native_words.asm). In my current understanding, this rts will end the currently-being-compiled word because we never jsr'd into another word.

What should happen is a jump to some later point in this same dictionary definition where the word LOOP (or +LOOP) shows up, but that location isn't available yet, so some assembly-fu will be required to make it work. The reference to LDA/PHA and dummy bytes back up in the do_common code sounds like such assembly-fu. Perhaps a push-push-rts is used as a jump?

New Understanding

I've read your loops.txt from Tali1 (still referenced in the assembly for Tali2, and I believe still relevant.)

It looks like question_do_runtime is trying to do the right thing. The address of the top of the loop and the address of the end of the loop should be on the RETURN stack. I had originally missed the fact that these were held on the RETURN stack. You do two PLA instructions to remove the address of the top of the loop, and then use RTS to jump to the address of the end of the loop.

Conclusion

It looks like this will take some time in the simulator tracing step by step to figure out. It's quite mind-bending (in a good way) because some of the code is being run during compilation (when forward addresses are not known yet), but some of the code runs at runtime (where the forward addresses have already sneakily been filled in by the compile-time code run at the end of the loop). If/when I have some free time, I may check this out in the simulator, but I don't think I know enough yet to figure out the bug.

from taliforth2.

I believe the runtime for ?do was pulling off the return stack the very address it should be going to when it discovers the start/end values are equal. I've commented out the two PLA instructions and it seems to be working now. See #41 for my solution.

from taliforth2.

I can confirm the bug, and that it was already present in Tali Forth 1 (always depressing). Running your test snippet in Gforth produces the correct behavior. Will try to get to the fix later on, thx!

from taliforth2.

You fix, ah, seems to have fixed it. Thanks!

from taliforth2.