You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi Matt. First of all, impressive work you're doing here :)
I suspect that performance could be improved considerably if each opcode was 32bit instead of 64bit. It seems like the reason they're 64bit is to encode immediate floats or jump positions. What about switching to 32bit opcodes and when an immediate value is expected, the interpreter steps one word forward and reads the immediate at that location, before continuing with the interpreter loop as usual?
I encourage you to try hacking on this, but let me save you a little time by telling you the tricky part right away 😄
We walk through the tape both forward and backwards: forwards during normal evaluation, backwards when constructing the shortened tape. This means we have to decode it unambiguously in both directions, which is tricky with variable-length instructions – is this u32 an instruction, or an immediate from the previous (next) item in the tape?
One potential strategy, which I just thought up (so it may be half-baked): Reserve the top bit in the opcode byte to mark whether the previous item in the tape (when reading forwards) is an immediate. This limits us to 128 opcodes, but we've only got ~30 so far, so that's not terrible.
(Jumps would need to use the same strategy, which would require modifying the opcode after the jump – this all sounds feasible-ish, but full of fun edge cases to discover in implementation 😃)
Oh, that complicates it a bit, thanks for the heads-up :)
I think your suggestion with the flag bit is a good one.
A simpler solution might be to always check if the "previous" instruction expects an immediate/jump while walking backwards through the tape but that might eliminate the performance improvement (depending on how often a backwards walk is performed).
Hi Matt. First of all, impressive work you're doing here :)
I suspect that performance could be improved considerably if each opcode was 32bit instead of 64bit. It seems like the reason they're 64bit is to encode immediate floats or jump positions. What about switching to 32bit opcodes and when an immediate value is expected, the interpreter steps one word forward and reads the immediate at that location, before continuing with the interpreter loop as usual?
mpr/inc/clause.hpp
Lines 22 to 23 in eb63def
I might try this out soon, but until then this issue can be a place for discussion..
The text was updated successfully, but these errors were encountered: