If you build flattened a vector of them (as they argue), it can approach a byte code interpreter, though it won't be a very dense vector, if it holds "pointers" (that you need to chase) to the instructions instead of the instructions themselves.
replyA lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.
This doesn't move the needle there, at all.
So…you can transform it into a threaded interpreter?
replyThis seems like a ton of LLM verbiage making two simple and very standard techniques sound artificially profound.
> If you build flattened a vector of them
replyWell, yes, it's an old way to represent ASTs: allocate them all sequentially from a huge arena (worked especially nicely for BCPL). Except the author actually uses their home-grown vecte<Element*> which, as far as I can tell, uses malloc/realloc. And there are several pointer indirections inside the liste/ITEM/LIST classes so... yeah.
deleted
reply