Not strictly 6502-related, but this place is the best collection of brains I have to pick on the subject I have a running project to develop a stack-oriented homebrew CPU (details here and here, if you want 'em,) and now that I have a mostly-functional simulator for the architecture, naturally enough I'm trying to develop a Forth implementation for it. Figure I may as well create a standing thread for this; I only have the one real question at the moment, but I'm sure I'll have others down the line...

So I've browsed over Brad Rodriguez's "Moving Forth" a few times in the past as I try to wrap my head around how Forth works on an internal level, and I'm back to working through it as I try to roll up some sample code for this project to evaluate my own design decisions. I'm currently looking at the part where he explains DOES> - he makes a fair production out of it, and it seems to me like it's maybe not as complicated as all that, but on the other hand I'm not 100% sure I've got it, either. Seems to me, if I'm following it all correctly, that all the DODOES routine really is is a way for a common "handler" routine invoked by a class of words to get the "return address" - in other words, the address of the parameter field for any specific word invoking that handler - pushed onto the parameter stack, no?

Because if that's all it is, this becomes fairly trivial. I'm using an STC model, since the CPU architecture is designed around that, and based on Rodriguez's example, the DODOES subroutine could be implemented like so:

Better yet, if I'm understanding it correctly, it could be inlined as a single CTD instruction (popping the parameter-field address to the parameter stack and leaving only the parent-thread return address on the return stack.) But, as I said, I'm not 100% clear on whether I am understanding this all correctly, plus I've seen some comments 'round here about the whole DOES> thing being both simpler and yet a little trickier than it looks in STC models since there's no distinction between the code and parameter fields...? Curious to know if I've grasped this properly or not; I've looked at the standard documentation, but it gives a whole lot of what and not a lot of why.

Dr. Brad's Moving Forth Part 3 hints that once you fully understand defining words, the rest is a walk in the park. I don't understand your assembly language example, so I'll just whip out my own foreign example, from my imaginary DTC FORTH for my imaginary 65m32 (a=dTOS, y=IP, x=rSP, s=dSP):I used Dr. Brad's article to make this, but I have no way to test it because I'm a FORTH novice and my simulator still hasn't made it through its first compile. Maybe an advanced FORTHer here can provide a relatively simple but free-standing example use case that we can hand-simulate to see if either, both or neither of us are on the right track.

I can't find it at the moment, but I recently read somewhere [edit: here] that Dr. Bruce had a broken dodoes that he hadn't fixed yet, so there's some deceptive trickiness in the concept.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

Yes, DODOES is not so tricky in a subroutine threaded Forth in a system with normal return vectors... you should enter DODOES with ( R: ... PFA XT_Created_Word ) on the return stack, so get the PDA to the top of the data stack and branch to the DOES> compiled code and you are good.

Where debugging a broken CREATE DOES> system is sometimes harder is sorting out whether you have messed up the DOES> compilation or the DODOES code. The CREATE part can be tested incrementally, but DOES> and DODOES are a system, and so it helps to know how the compiled DOES> should look so you can be sure the problem is not somewhere in the DOES> compilation process itself.

Or at least, when I have time to debug xForth's broken DOES> system, that's the plan.