Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Use uint32_t instead of uint64_t for opcodes #2

Open
gustavolsson opened this issue Sep 4, 2020 · 2 comments
Open

Idea: Use uint32_t instead of uint64_t for opcodes #2

gustavolsson opened this issue Sep 4, 2020 · 2 comments

Comments

@gustavolsson
Copy link

gustavolsson commented Sep 4, 2020

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

#define IMM(d) (((float*)(d))[1])
#define JUMP_TARGET(d) (((int32_t*)(d))[1])

I might try this out soon, but until then this issue can be a place for discussion..

@mkeeter
Copy link
Owner

mkeeter commented Sep 5, 2020

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 😃)

@gustavolsson
Copy link
Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants