6502.org

And this was the only place I could think of to ( confess | brag about ) what I have done. Here's my 2ROT primitive, which rotates the stack from ABC -> BCA. All values are four-byte doubles. The data stack is indexed by X and divided between several bytes of stackl and an equally sized stackh region. Top of stack is special gets its own 2-byte zero page storage.

Waddya think, sirs?
It should also be noted that stackl = $00 and stackh = $30. (I have about 18 more bytes available for stack but this makes it easier to debug in xpet), otherwise I'd have to begin with:

I'm afraid I didn't try very hard to follow your code if you commented
it better (like explain what you're doing) I might.

It looks awfully convoluted.

Assuming I understand what you're trying to achieve,
my approach would be something like this:
Not sure I got that all correct, I just sort of banged it out for the
purpose of illustration .

What exactly does POP do?

I can see the utility of a subroutine that popped the top of the stack
(the position currently pointed to by x) to the tos* but it seems
to me you'll have to get stuff out of the way first any way if it's
something you can only jump to at the tail (ie if it's not a subroutine)
and so is likely to be redundant. (like I said I didn't try very hard to follow your code )


* maybe it would be less confusing to call the tos the accumulator or something

The thing I was proud of here was using LSR and a series of bits to manage a pair of nested loops. The inner loop executes twice on each pass through the outer loop, which also executes twice. It uses a single byte and shifting flags off the end to control everything, and it kind of reminded me of a Turing Machine. I stored the control bits in TOS not because it's part of the stack, but because TOS suddenly became an available zero page scratch location after pushing its contents onto the real stack. The POP at the end will overwrite TOS, and that's okay. The only reason it's here is to leave the same number of bytes (12) on the stack as we came in with (12)

Ultimately, this approach didn't save me any memory vs. just juggling the stack around or I would have left it in. I didn't really care about the clock cycles for this primitive, because I can't recall a single occasion when I've ever used 2ROT or done much with double precision in a Forth program. But I thought the LSR ... BCS thing was pretty nifty. Self-modifying code is usually a bad thing (like where I toggle L057 between being an INX and DEX instruction on alternating iterations through the loop) and my inner jury is still out on whether using EOR to toggle the X register between the STACKL and the STACKH area was ugly or slick.

Here's 2ROT now, same size, probably 1/2 the clocks, and I'll still never use it.
But back to your question, "What is POP?" Okay... on the PET, the kernel uses three zero page addresses from $8D - $8F for the 1/60th of a second 24-hour jiffy clock, and $90 - $FF for whatever. I'm just going to leave everything from $8D to the top of zero page alone, and content myself with the 141 bytes I get.
I do a few nontraditional things here, like having a NEXT that ignores moving across page boundaries. Instead I leave that up to the compiler to insert a call to PAGE at $xxFD or $xxFE. There's more too, like padding at compile time and skipping to the next page at runtime (when necessary) after a literal or string if it leaves me at $xxFF. This hardware is a real NMOS 6502 complete with the JMP ($xxFF) bug. The key benefit of this approach is getting NEXT down to 15 clocks.

It is typical to have an 8-byte region called "N" on the zeropage for primitive scratch space. It's also typical to have the parameter stack in zero page and index it with zp,X addressing mode.

I haven't seen a Forth that puts the innermost DO-LOOP index and limit on the zero page (ZI) but this one does. Usually DO LOOP counters and limits live on the return stack. Also for (I hope) an overall speed boost, I keep the topmost value on the parameter stack in a separate 2-byte area and split the rest of the stack into low-byte and high-byte areas. Instead of having a two-byte pointer to code stored at the code field address (CFA) there is always actual executable machine code instead. That saves one level of indirection and is called DTC (direct-threaded code) vs. the traditional ITC (indirect-threaded code)

The first word in the dictionary is (LIT), used for pushing 2-byte values that were embedded in the dictionary onto the stack. Down at the bottom of (LIT) we have a few useful ways to exit primitives, PUSHN, PUSH, and PUT. Both PUSH and PUT assume you've loaded Y:A with the two bytes you want to drop on the stack. A few definitions later, we run into (DO) which is the business end of setting up a DO LOOP. It's also got a couple useful ways to exit a primitive, POPTWO, and POP. I just have to make sure to slide the last thing off the bottom into TOS when I POP and also be sure to move TOS onto the real stack when I PUSH or PUT. To recap, POPTWO, POP, PUSHN, PUSH, PUT, NEXT and NEXTO are all ways to get out of a primitive and move the IP (instruction pointer) to the next word.

It could be but I don't think it is in this case
I think you can get by without it
I was thinking about that

I wonder how likely it would be that a word would cross two page
boundaries. My guess is that it wouldn't be too likely.

In that case I think I'd blow a couple bytes in zp and build the page
increment into NEXT and call it explicitly
Then if the code field is close enough to the page boundary, pad it by
prepending NOPs so that the code took you across the page boundary,
if not insert a NEXTPAGE and prepend a NOP if necessary to align.
Then have a work around for a subsequent page crossings that are
unaligned and hope you never needed it.
And get the compiler to skip over the prepended NOP's

Of course, it would complicate the compiler


Oh, and I take back what I said about pop I totally missed
the fact that you were using y