[mrugiero]

I don't think this counts as threading, though it makes use of it. Threading mostly removes the dispatch overhead, but you still have a general function per instruction, a function call, and an inability to inline constants. Copy and patch could be thought of as a generalization of threading in the sense that you still precompile code for your instructions, but instead of calling that code you poke holes in it to replace constants you only know at runtime, then make a single callable program out of those instead of jumping around for every instruction.

There is a prior, very similar approach in GNU Jitter, but it uses only the compiler and some magic rather than the linker for marking spots to replace. I read about it by mention of moonchild in a thread[0] linked by foota here.

[0]: https://news.ycombinator.com/item?id=40410420

[MaxBarraclough]

Threading doesn't necessarily mean following the full function-call convention on every transition. A switch/case approach is one way, but it's also possible to jump intra-function without following the calling convention, i.e. a goto with a pointer-based target.

I say possible in the sense that hardware supports it. The standard C language doesn't support this, but GCC's GNU C does support it as one of its extensions.

The GNU Jitter author wrote about this, see page 48, referred to as page '17', of this PDF: https://ageinghacker.net/talks/jitter-slides--saiu--ghm2017-...

See also Gforth writing about the same technique: https://gforth.org/manual/Threading.html

[mrugiero]

That is not the point though. I know threading allows using a custom convention and just jumping. What it doesn't, IIUC, is allow specializing your code for runtime data. Copy-and-patch and Jitter do. It's essentially static vs dynamic. I'm new to this so I may very well be misunderstanding threading, but I don't think it allows for modifying the functions on runtime by itself.

[MaxBarraclough]

There's bit of a mushy terminology problem here. Generally when we say threading we mean schemes that don't rely on generation of new native-code sequences, sure, but people who are serious about efficient threading don't necessarily view it that way.

The term context threading refers to generation of native code that behaves much like conventional threaded-code interpretation, except specialised to the particular input code. [0][1]

See also dynamic superinstructions, a term used by gforth to refer to its runtime generation of native code for input Forth code. [2]

Disclaimer: I'm no Forth expert. I should give [1] a proper read, it looks interesting.

[0] https://webkit.org/blog/214/introducing-squirrelfish-extreme...

[1] (PDF) https://csng.cs.toronto.edu/publication_files/0000/0162/demk...

[2] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html-his...

[mrugiero]

I see. I'll try to read the links over the weekend, they seem really interesting. It's sad that the terms are so overloaded though, as it makes it hard to reach preexisting approaches and leads to rediscoveries of the same idea (I see that both Jitter and C&P seem to implement this very same idea, except maybe in the way the templates are created, and both seem to believe their invention is novel).

[MaxBarraclough]

Regarding threaded-code strategies I think the terminology is reasonable. There's a real sense in which context threading is just another kind of threaded code, although it does make it awkward to describe conventional direct or indirect threading.

The creator of Jitter has read a lot about Gforth, as evidenced in [0][1].

You're not the only one to suspect there's some reinvention going on here somewhere though. [2] I'm not familiar enough with these topics (copy-and-patch and Jitter) to weigh in.

[0] (PDF) https://ageinghacker.net/talks/jitter-slides--saiu--ghm2017-...

[1] (PDF) https://ageinghacker.net/talks/jitter-slides--saiu--bts-2022...

[2] https://news.ycombinator.com/item?id=40410420

[sitkack]

They are both super close in the latent space. I think you could design for threading, but then copy into place and NOP out what you don't need, or wire in the right constants, etc.

[mrugiero]

That's true. But it's still a stretch to say they are the same thing. That's why I said it can be seen as generalizing the approach.