I'd like to move all instruction code (the code inside a TARGET(NAME) block) from Python/ceval.c to a new file, Python/instructions.h. The new file will contain only instruction bodies (prefixed by related helper functions/macros).

Eval-context macros (e.g. TARGET, DISPATCH, TOP, PUSH, POP, etc) will not be moved to instructions.h, but will be expected to be available (defined by the #includer).

ceval.c will define the eval-context macros in the same way, and #include "instructions.h", inside the body of _PyEval_EvalFrameDefault. The code emitted should remain exactly the same.

The benefit of this change, is that it becomes easy to produce alternative implementations of EvalFrame which reuse the same instruction code, but with changes to the evaluation context or dispatch mechanism. In particular, after this change, I hope to experiment with adding a cross-platform subroutine-threading code evaluator. (for performance testing)

While I can see the utility for experimentation, I think the proposed change would make our lives more difficult.  The body inside the instruction blocks is central to the understanding of ceval.c and somewhat tightly coupled with it.  I would find it more difficult to maintain that code, switching back and forth between ceval.c and instructions.h.   We've already hit a level of complexity that presents a challenge to newcomers.

rhettinger, helper functions used by the instruction code would also be moved into instructions.h (e.g. call_function, do_call_core, cmp_outcome, etc). Done properly, there should be very little need to move between instructions.h and ceval.c to understand what is happening.

The contract between the two files has to be very explicit. The only dependencies instructions.h would have on ceval.c would be to receive the evaluator macros (for manipulating the stack & locals, flow control, triggering error condition, etc). A strict (non-leaky) abstraction interface is necessary for being able to re-use the instruction code in an alternate evaluator.

> A strict (non-leaky) abstraction interface is necessary 
> for being able to re-use the instruction code in an
> alternate evaluator.

The problem is that we don't have a strict (non-leaky) abstraction and I don't think we should impose one.

> Done properly, there should be very little need to move
> between instructions.h and ceval.c to understand what is happening.

I believe that is just wishful thinking and the separation will make it harder to learn and reason ceval.c.   Also, I really don't like putting the essential core of instruction code in a .h file rather than a .c file.

FWIW, when I've done my own experiments with alternative evaluation techniques (such as subroutine threading), it always required changes to the instruction bodies (in part because interesting variants use different argument passing techniques and in part because of a need to change state external to the instruction body for tracing and whatnot).

Overall, I think the proposal would be a net detriment to future maintenance and would not have a recurring payoff beyond your present experiments.

No one has spoken up for this feature request, so I'm marking it as closed.  Thank you for the suggestion, but I think it is prudent to decline.