-
Notifications
You must be signed in to change notification settings - Fork 360
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
Tracking issue: flatten the eval stack #183
Comments
This was referenced Oct 29, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, if
core
finds an opcode it cannot handle, it willTrap
first, and thenRuntime
will attempt to eval it. This is rather inefficient.Instead,
core
should expose the eval table (which is just 256-item fn pointers), to allowRuntime
to customize it.Machine
would now take a generic parameter stateS
(with default()
), and then pass it as the final parameter to eval fns.Runtime
then should fully build with that, and only trap forCALL
/CREATE
.Gasometer
should be the only thing that wraps aMachine
.This should make it more predictable when reasoning about performance, while not losing much abstractions.
The text was updated successfully, but these errors were encountered: