Yes it is really cool. And the interrupt problem can be fixed with some extra circuitry -- I posted about that here.

(There's also careful explanation of dclxvi's rather unusual technique.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Note that if roughly 1/4 of all primitive executions are ENTER or EXIT and almost all execute NEXT, clock cycles saved in nesting covers a lot of register preservation in those operations needing them.

However, if it is close to a wash, I would lean toward leaving the return stack index register free and preserving the return stack register value in the zero/direct page, because it is just easier to write the primitives with a free register available. That is straightforward with "INX : INX : JMP ($0000,X)" using Y for the rack.


Costs 8 cycles in each, so adds on average 2 clocks to the NEXT / ENTER / EXIT overhead per primitive executed. Similar overhead applies to R@ and crew.

This is only half the picture though. Almost every word also uses the data stack. The Y-reg being the free register here would be the logical choice to use with the data stack but requires 3 byte instructions and a stack pointer for the Y-reg must also be kept. If we try to use the X-reg for the data stack, it is even worse as it must be saved first, load the data stack pointer, then both save the data stack pointer and restore the X-reg. There are a lot of words that require PUSH, PUT, POP, POP2 & POP3.

We won't be saving anything if we are constantly saving and restoring a data stack register, and at the cost of a bit more code. I don't have the full picture yet, and haven't got around to counting cycles yet. But this is definitely worth coming back to.

I am also having trouble following ENTER. The PLX is pulling the return address off the stack from whatever is calling with a JSR ENTER. This doesn't make sense to me if every word definition starts with JSR ENTER.

But if the stack is not being used for the return stack or for the IP, it can be used for the data stack.



In the 65C02 version, the "JMP ($0000,X)" has to be self-modifying code in the zero page, so saving the three clocks of "JMP NEXT" is not an option ... in the 65C02 version, the IP IS the spot in the zero page occupied by the $0000 ... and so using the hardware stack as the data stack while allowing most operations to avoid "STX TX : TSX : ... : LDX TX" benefits from a top-of-stack location in the zero page.

With the stack relative addressing in the 65816, the hardware stack makes a fine data stack on its own.

Of course, there is no such thing as a free lunch ... saving the three clocks of the "JMP NEXT" or "BRA NEXT" also means each primitive ends with a five byte NEXT rather than a two byte branch or three byte jump to NEXT.

Dr. Bruce, if you keep TOS in A your examples improve thusly:Store is slightly bigger, and all the others are slightly smaller, for a net win.
And if JMP (abs,X) wraps in the program bank, you could even change to JMP ($FFFE,X) to keep your IP pointed in the traditional manner, I think.

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

Very Nice!

Not only is it built for speed, there is still the option to reduce the size of some of the lesser called words and still do a BRA to a word that is used a lot and still has the INX INX JMP ($0000,X), to save 3 bytes each time. And not even have to worry if we are still within the 128 byte limit of a branch.

This might be a really good trade-off between size and speed, and even versatility.

Yes, but optimizing the dyadic and monadic stack operators will come at a cost somewhere else{+}, so given a 65816 system like the Feonix256 or a 65816 board in the nascent Commander X16, it might be something I might like to implement both ways and profile to see which one shakes out the best.

OTOH, it may be that the 65816 equivalent of the TOS in the zero page in the 65C02 is indeed keeping TOS in A -- the fact that JMP ($0000,X) related ENTER and EXIT can be implemented without requiring using of the A register does encourage that thought.

Since my focus is on the 65C02 at present, these 65816 concepts are just sketches, but if I get enough progress on the 65C02 version of xForth this coming summer, I might flesh out the 65816 version.

{+ Note: So far I only see some small clock penalties in ROT BRANCH and the double-cell words between data stack and the Rack, and bigger clock gains for TOS in A with FETCH and DOVAR/DOCON.}

It just seems appealing to me when I see the common words like DUP, DROP and NIP turn into a single machine instruction plus NEXT (PHA, PLA, PLY). In my 65m32 DTC FORTH, literally dozens of primitives reduce to a single machine instruction, making optimized STC the proper performance-oriented solution. I need to stop trying to prematurely optimize everything about the architecture and get something working first, but my obsessive compulsivity combined with a fair amount of laziness refuse to allow it.

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

Note that for the two operand words, the 65816 hardware data stack version is shorter, but the X indexed stack for the SRT is faster, and the SRT has a one byte RTS instead of five byte INX : INX : JMP ($0000,X)


But before I try my hand at a subroutine threaded implementation, I want to be sure I can implement one closer to the eForth v1.0 and CamelForth gor the Z80 models I am using for reference.