After a bit more experience with the assembler, I'll be reverting to the old "<b" and "<jl" format for forward references instead of "<?". Here's the problem, illustrated with the PEA example on page 188 of the manual. In Typist's Notation, this would be:
Code:
<? return 1- phe.# \ phe.# is PEA in WDC notation
string1 phe.#
string2 phe.#
compare jmp
-> return
(...)
This is a method to pass parameters to a subroutine, in this case for string comparisons; "compare" ends with a RTS.
For this to work, phe.# would have to be "futureproofed" like the jmp and bra instructions, which means lots and lots of complicated code to figure out what kind of unresolved forward reference we are dealing with. In fact, we end up with pretty much every non-single byte instruction futureproofed. We could factor it out with something like
Code:
<? return ?> 1- phe.#
but that would mean
four chacters for a simple foward reference. Also, futureproofing is ugly in itself on a code level, because it involves things like passing a flag foward. You will remember that
Thinking in Forth actually memtions that as an example of bad coding. Ahem.
If this were a program for some normal user, it might be worth it, but since I'm the only one using it now (and probably forever, grin), I'm just going back to
Code:
<j return 1- phe.# \ phe.# is PEA in WDC notation
string1 phe.#
string2 phe.#
compare jmp
-> return
(...)
as an absolute reference, probably with "<a" as a synonym for "<j". That way, the 65816 instructions themselves don't need to know jack about future references, and the code is far simpler and cleaner all around. Repeating the kind of reference we have is the lesser to two evils, it turns out.
In the end, this was a very instructional dead end, because I learned a lot about tradeoffs in the code, not to mention that the Forth routines themselves are the most complicated I have written to date. Which should have probably been a warning sign
.