Most primitives are unfolded into assembler.  There's a DUP>R word  ( lda tos+1; pha; lda tos; pha; jmp next ).  I adapted the Blazin' Forth/Ragsdale assembler.  I also did some tail call optimization here and there for speed/size savings. For the most part, I use Ubuntu + Geany + xa65 with a Makefile and a Ruby script or two to do development on VICE.  My old hardware is working, and I have run PETTIL on a real PET.

The NEXT routine lives in zero page.  It's 7 bytes/15 clocks:
next
    inc nexto+1
    inc nexto+2
nexto
    jmp ($cafe)        ; $cafe is the self-modified instruction pointer (IP)

I don't remember if we talked about this on 6502.org, but something that makes fig-Forth a lot slower than it needed to be was that it had a minimum of code definitions (ie, primitives), probably to get it written faster by porting other words as colon definitions (ie, secondaries) from the fig-Forths for other processors.  What you can do then to accelerate it far more than streamlining NEXT is to take a lot of the secondaries and re-write them as primitives.  Take for example -ROT, which is often defined as

: -ROT ROT ROT ;

so running it involves:

nest

NEXT

ROT

NEXT

ROT

NEXT

unnest

NEXT

whereas if it were defined as a primitive, it would take the same number of machine-language instructions as ROT, just rotating the opposite direction, and would execute

-ROT

NEXT

which goes about four times as fast.  There are a lot of these that can be dramatically sped up, gaining far more than you can gain by going to DTC or STC.  There are combinations that get used over and over like DUP >R which can be made a single primitive that's much faster because you don't actually have to DUP it--just push a copy onto the return stack, without affecting the data stack.  The more you look, the more of these you find.

However, the '02 has a lot of overhead in handling 16-bit quantities, so code space will grow if you do re-define these things as primitives.  When I wrote my 65816 Forth, I found that converting words to primitives to prevent having to run NEXT, nest, and unnest so many times to get a job done not only made them a lot faster, but contrary to the '02, it actually made them _shorter_ too (and even quicker to write).

As I write in this box, the line spacing is not coming out right, so we'll see what happens when I click "Post comment".  I don't know if there will be an "Edit" option if it's messed up.  Edit: Yes, there is an "Edit" option.  Is html allowed?

Edit #2:  Include an assembler.  I have the word INLINE too, which allows breaking into assembly where max performance or control of the machine is required, and then return to  high-level Forth, all inside a colon definition.   I rarely use INLINE, but I do use the assembler a lot to write primitives and ISRs, and to a lesser extent, runtimes and subroutines. You might find that you can effectively get 95% of max performance by writing only a tiny portion of the code in assembly, provided it's the speed-critical portion.