It would be interesting to see how well PyPy optimizes the code generated by the Phorth compiler, but it looks like this needs some hacks via the CPython C API to work. Even if it could be made to work, I doubt the PyPy JIT would like some of the odd things Phorth does to the internal interpreter state.
I don't think that it will ever work on PyPy. The data stored in the `co_code` field is a super set of the instructions python understands. The `co_code` data starts with a prelude which is the repl and builtin words, then there is a large chunk of unallocated data (starting as `NOP`) followed by a suffix except block. Once you define a new word from within the interpreted phorth code you will write the address of each word called into the code object at the HERE marker, which starts at the beginning of the `NOP` segment. Basically if you write a word like: `: square dup * ;` then you will be writing the address of `dup` over the first two `NOP`s, then the address of `*` over the next two `NOP`s, finally you write the address of a return procedure over the next two `NOP`s after that. These are not valid instructions for the interpreter loop but the normal interpreter never hits them.