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
Currently, if core finds an opcode it cannot handle, it will Trap first, and then Runtime will attempt to eval it. This is rather inefficient.
Instead, core should expose the eval table (which is just 256-item fn pointers), to allow Runtime 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 for CALL/CREATE. Gasometer should be the only thing that wraps a Machine.
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:
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: