I read this article (written about 7 years ago! - I wish I had spotted it sooner)

  https://nullprogram.com/blog/2014/12/23/

which explains how to use a DLL to update running code on the fly - the trick being
to store all state externally to the code module.

Turns out that the model of code that the author requires for this to work is *exactly*
what we already do in our static binary translators!

It would be relatively easy to add this mechanism to an SBT that already has a fallback-
interpreter, so that after interpreting a sufficient number of instructions and marking
the code with instruction addresses, so that we could then build a recompiler module for
the code that was now known.  Obviously you wouldn't rebuild the huge switch table on
every instruction, but it would make sense to do so every time you've discovered <N> more
code addresses.  You could also trigger a rebuild on, say, <x> time units having passed
since no more new code addresses have been discovered.

With at least a dual core processor there shouldn't be a performance hit while doing
the rebuild.

Switching from a previous DLL build to a rebuilt one should be easy as we have very
defined places where the switch statement is entered already. (between basic blocks
in recompiled code, or between instructions if running in the fallback emulator)

Emulation could be started with no recompiled code at all and 100% fallback emulator,
with recompilation happening after sufficient code has been run to be worth compiling.

Note that we don't need to do all accesses within the running SBT through this
external pointer - we can copy the relatively small machine state locally on entry
to the procedure that runs the loop and switch statement, then copy back out on
return from it.

It had always been the plan that the SBT would morph into dynamic recompilation, but
the path we had in mind had been to incrementally compile the generated C a statement or
a basic block at a time, and that this would require our own compiler (or maybe the
incremental mode of tcc) - and to that end we had put a lot of work into optimising
the generated C.  But if we can compile the entire switch statement with a traditional
compiler, then we don't need to perform those optimisations because they're done for
you by the compiler.

(Also see http://gtoal.com/SBTPROJECT/README-C-CODE.txt for some other recent developments)