Hi Eliot:
On 16 Oct 2012, at 22:32, Eliot Miranda wrote:
StackInterpreter methods fetchNextBytecode "This method fetches the next instruction (bytecode)." currentBytecode := self fetchByte + bytecodeSetSelector
Thanks, that's what I was looking for.
I couldn't see much of an impact when I measured it, but I don't have my measurements handy. Modern processors cache the read so well that even in the interpreter impact is minimal (it was certainly less than 10%, probably less than 5%, in a pure interpreter), and of course in the JIT it matters not at all. But the impact was enough that I ended up conditionalizing the code so it reads
Hm, ok. Sounds better than the 5-30% hit I have for having a check inside the bytecodes to have different semantics.
I don't suppose its something people do a lot. Claus' VM is the only one I was aware of. I think its useful to support multiple languages and to support migrating the bytecode set using incremental development, but in a production VM if one didn't need the support I think one would end up disabling it.
The other example I found is the LuaJIT2 interpreter. It is used to enable and disable debugging hooks, as far as I understand. But since it is written in assembler, it is just patching the dispatch table and let's the bytecode jump to different code when the debugging hooks are enabled. But I didn't see any performance numbers for that. Would guess it would take some interaction with the OS to deactivate protection on executable memory pages to change the dispatch table.
Thanks Stefan