←back to thread

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

(blog.reverberate.org)
122 points phsilva | 1 comments | 17 Feb 25 07:12 UTC | HN request time: 0s | source
Show context
riffraff ◴[20 Feb 25 06:44 UTC] No.43111815[source]▶
How does this differ from direct threading interpreters?

It seems like it solves the same problem (saving the function call overhead) and has the same downsides (requires non-standard compiler extensions)

EDIT: it seems the answer is that compilers do not play well with direct-threaded interpreters and they are able to perform more/better optimizations when looking at normal-sized functions rather than massive blocks

http://lua-users.org/lists/lua-l/2011-02/msg00742.html

replies(3): >>43112497 #>>43112649 #>>43116851 #
1. noelwelsh ◴[20 Feb 25 08:44 UTC] No.43112497[source]▶
Unfortunately, most discussion of direct threaded interpreters confuses the implementation techniques (e.g. computed gotos) with the concepts (tail calls, or duality between calls and returns and data and codata, depending on your point of view). What is presented here is conceptually a direct threaded interpreter. It's just implemented in a way that is more amenable to optimization by the compiler technology in use.

(More here: https://noelwelsh.com/posts/understanding-vm-dispatch/)