-
Notifications
You must be signed in to change notification settings - Fork 751
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
Make list of opcodes property of VM instance #592
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't _opcode
rather be a property of the EVM
instead of the VM
? In the current implementation this is referencing back and forth between Interpreter
and the VM
object, introducing a new circular dependency.
So it's possible to have the list of opcodes as a property of The good thing about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's leave this "as is" for now - see there are good arguments in both directions. As long as we still have EVM and VM this tightly coupled this will do the job and if we decouple we'll likely have to do some further refactoring anyhow.
Will approve now.
Fixes #591, also related to #543
Instead of having a global list of opcodes in the
opcodes.ts
file, this PR sets this list as a property of the VM instance to avoid problems when two VM instances with different HFs are created.I also made each opcode to be an object instead of a list. Objects are typed easily and are more flexible.
Note: If the Common instance of a VM instance is modified after construction, the list of opcodes will be out-dated.