20,741
edits
m (Update forum links) |
|||
Line 30: | Line 30: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Which basically means that we only need to worry about a single place when it comes to extending opcodes (and checking in run() that these invalid opcodes aren't used), which also translates into | Which basically means that we only need to worry about a single place when it comes to extending opcodes (and checking in run() that these invalid opcodes aren't used), which also translates into fewer assembly instructions that are actually run (2 CMP vs. ~12 per insn). Also, the bytecode interpreter routine itself could be simplified that way, too. In addition, it would make sense to augment the list of opcode enums by adding an OP_VERSION field that is incremented once opcodes are added/removed (which would be a prerequisite for any caching/serialization schemes too): | ||
<syntaxhighlight lang="c"> | <syntaxhighlight lang="c"> |