The real original copy and patch paper [0] used gcc's addressable gotos to get the addresses of the "patches" and pointers for the operands which can be replaced at jit-time as opposed to the referenced paper which uses llmv tomfoolery to create a database of code patches as part of the building process.<p>IIRC, there may be another "original" paper.<p>To help with the author's confusion, they use function arguments to manage the registers. If you have a simple operand like 'add' you pass the left and right arguments as function arguments but if you have some values you want to keep in registers you pass those as additional arguments to the functions and just pass them through to the continuation hoping the compiler does the right thing (i.e. not spill the arguments during the function call).<p>Of course this leads to a combinatorial explosion of functions as you need one specialized for every register you want to pass through:<p><pre><code> void add0(int l, int r, kont c);
void add1(int l, int r, int r0, kont c);
void add2(int l, int r, int r0, int r1, kont c);
</code></pre>
and also need to track in your jitifier who's doing what and how many intermediate results are needed at which program point &etc.<p>I believe both ways share the same method of generating a shitton of functions as a linked library and using that to create a database of code patches at compile time which the runtime uses to patch it all together. One does it using llvm tooling and the other uses 'extern int <i>add_l, </i>add_r, *add_r0' to get the locations of the operands to replace at runtime with the the actual value because C doesn't care one bit what you do with pointers.<p>I'm probably wrong on some of the details but that's the basics of what's happening.<p>__edit__
Reading the part on how extern variables are used and the example function definitions doesn't match perfectly with what is actually happening but the concept is the same -- use the locations the pointers point to to find the places to replace with actual values at runtime. The function defs are more like what a 'musttail interpreter' would use. Not sure this 'correction' is any clearer...<p>[0] <a href="http://ieeexplore.ieee.org/document/1342540/" rel="nofollow">http://ieeexplore.ieee.org/document/1342540/</a>