The TIER_ONE and TIER_TWO macros cause a few problems:
Their presence in the bytecode definitions means that anyone maintaining the interpreter or adding new instructions needs to understand the internals of the multiple execution layers and how they differ.
This makes the entry barrier for contribution, which is already high for these components, even higher.
It makes reasoning about the correctness of optimizations harder.
It prevents the addition of new execution tiers, or changing the design of the current tiers much harder.
We can remove the TIER_ONE and TIER_TWO macros by making modifications to internal execution engine state explicit, without describing how that state is implemented.
For example, rather than modifying next_instr in the tier 1 interpreter, we can use JUMP_BY or SAVE_IP macros.
See faster-cpython/ideas#618
Linked PRs
The
TIER_ONEandTIER_TWOmacros cause a few problems:Their presence in the bytecode definitions means that anyone maintaining the interpreter or adding new instructions needs to understand the internals of the multiple execution layers and how they differ.
This makes the entry barrier for contribution, which is already high for these components, even higher.
It makes reasoning about the correctness of optimizations harder.
It prevents the addition of new execution tiers, or changing the design of the current tiers much harder.
We can remove the
TIER_ONEandTIER_TWOmacros by making modifications to internal execution engine state explicit, without describing how that state is implemented.For example, rather than modifying
next_instrin the tier 1 interpreter, we can useJUMP_BYorSAVE_IPmacros.See faster-cpython/ideas#618
Linked PRs
RESUME_CHECKinstruction #108630#if TIER_ONEand#if TIER_TWOfrom_POP_FRAMEop. #108685TIER_ONEandTIER_TWOfrom_PUSH_FRAME#108725