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

Comienza rastreando la representación de los frames de CPython y el tratamiento del offset de instrucción expuesto como frame.f_lasti; después, revisa cómo mantiene actualmente el intérprete su Instruction Pointer. El cambio estará terminado cuando los JITs puedan mantener un offset mientras el intérprete puede seguir usando punteros, incluso con free-threading, sin perder la ubicación visible para la introspección de frames.