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.
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.
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.
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).
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.
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