I'm not clear on why there is `ip++` in the RECORD_INST handler. We've already moved to the next instruction by running `ip++` at the end of the handler in the normal dispatch table. In the RECORD_INST handler we do the work to record the instruction but don't do the actual work of that instruction. We can't, because we only have the one handler that has to work for all instructions. Shouldn't we jump to DISPATCHER_TABLE_NORMAL without incrementing ip again?
This way you could directly swap `dispatch_var` with an array populated with the
`RECORD_INST_*` labels, and remove one step at runtime.
Or maybe this is what you are trying to avoid to reduce the binary size ?
evomassiny
A `bool profile` branch stays expensive even when it predicts perfectly, because it bloats every opcode handler, and on a computed goto interpreter that extra code messes with the branch predictor history each dispatch site builds up, which is the whole reason dispatch is fast. Swapping the entire table dodges that. The part I like is fanning every opcode into one recording instruction and then back out through the real table, which is what keeps the second table from turning into a whole second interpreter like the earlier approach did.
comments (4)
abbeyj
NeutralForest
```
```becomes: ```
```This way you could directly swap `dispatch_var` with an array populated with the `RECORD_INST_*` labels, and remove one step at runtime.
Or maybe this is what you are trying to avoid to reduce the binary size ?
evomassiny
haeseong