A tail calling interpreter for Python (already landed in CPython)

Post by 10000truths » Fri, Feb 21, 2025, 10:59 PM UTC

haberman wrote: post #90

10000truths wrote: post #86

Earlier quoted context omitted.

I feel like using calling conventions to massage the compiler's register allocation strategy is a hack. If the problem is manual control over register allocation, then the ideal solution should be... well, exactly that and no more? An annotation for local variables indicating "always spill this" (for cold-path locals) or "never spill this or else trigger a build error" (for hot-path locals). Isn't that literally why…

If the tail calling pattern made the code ugly, I would be more inclined to agree with this. But putting each opcode in its own function isn't so bad: it seems just as readable, if not more so, than a mondo function that implements every opcode. By contrast, a mondo function that also has a bunch of register allocation annotations seems less readable.

Post by haberman » Sun, Feb 23, 2025, 5:04 AM UTC

10000truths wrote: post #91

haberman wrote: post #90

Earlier quoted context omitted.

If the tail calling pattern made the code ugly, I would be more inclined to agree with this. But putting each opcode in its own function isn't so bad: it seems just as readable, if not more so, than a mondo function that implements every opcode. By contrast, a mondo function that also has a bunch of register allocation annotations seems less readable.

I don't see how a hypothetical __attribute__((never_spill)) annotation on local variables would preclude splitting opcode logic into separate functions. It just means those functions would have to be inlined into the interpreter loop to avoid conflicts with calling convention constraints.