5 ms·
Yes, that's very odd. At least they could have used a case statement, which a C compiler will be able to optimize into an efficient jump table. I remember read
by lobster_johnson 15y ago
Yes, that's very odd. At least they could have used a case statement, which a C compiler will be able to optimize into an efficient jump table.
I remember reading about a VM (I remember it as being Google's V8, but that one compiles directly to machine code so probably I'm misremembering; maybe it was Strongtalk?) which basically ditched the classic bytecode loop (grab next instruction, check what it is, evaluate it, repeat) and instead implemented each bytecode type as a function and somehow munged the instruction pointer or modified the VM's machine code itself so that the CPU would move directly to the next instruction's function without jumping. Damn, I wish I could remember the idea. Anyone know what I'm talking about?
- anon_comenter9 15y agoYou are probably talking about threaded code which is described in "The Structure and Performance of Efficient Interpreters" http://www.jilp.org/vol5/v5paper12.pdf http://www.jilp.org/vol5/v5paper12.pdf With real code examples
- lobster_johnson 15y agoThanks, that's an interesting paper. I have never heard of that paper, I'm thinking specifically of a VM that implemented the feature. Not sure if we are talking about the same algorithm, either, although it sounds similar.
- anon_comenter9 15y agoThinking about it, that sounds like inline threading http://blog.mozilla.com/dmandelin/2008/08/27/inline-threading-tracemonkey-etc/ http://blog.mozilla.com/dmandelin/2008/08/27/inline-threadin...
- jws 15y agoThe bodies of these opcodes are only single machine instruction or two themselves and are inlined. This changes the game.