Allow storing the instruction offset as an alternative to the instruction pointer in the frame.

Feature or enhancement

Proposal:

The CPython JIT compiler, and other compilers like CinderX, need to keep the current frame's instruction pointer up-to-date so that code introspecting the frame can determine the location that is currently being executed.

Before 3.11, the instruction offset was stored in the frame and this is still the value that Python code sees, frame.f_lasti, but it is inefficient to repeatedly calculate an offset in the interpreter, so internally we store the pointer and calculate the offset lazily when needed.

A JIT, however, does not want to maintain an instruction pointer, as it has to store the pointer every time that a call can escape. Instead or storing a 64 bit pointer, it is more efficient to store a 16 bit offset.
Also, with free-threading, it is impossible for the JIT to store a pointer, as it depends on the thread local bytecode.

Given that the interpreter wants to store pointers, and the JIT needs offsets, we can either:

1. Use offsets everywhere
2. Use a mix of offsets and pointers

(1) would slow down the interpreter significantly, so is undesirable
(2) gets us the best of both, in terms of performance, but is a bit more complex.

I think option 2, is the best.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Beginne damit, die Frame-Darstellung von CPython und die Behandlung des als frame.f_lasti offengelegten Instruktions-Offsets nachzuverfolgen, und prüfe anschließend, wie der Interpreter derzeit seinen Instruction Pointer verwaltet. Die Änderung ist abgeschlossen, wenn JITs einen Offset verwalten können, während der Interpreter weiterhin Pointer verwenden kann, auch beim free-threading, ohne die für die Frame-Introspektion sichtbare Position zu verlieren.