-
Notifications
You must be signed in to change notification settings - Fork 506
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
Refactor call and create opcodes and frame call. #996
Comments
Brainstormed around this and what i concluded is that call stack needs to be generic over Frame. For the frame to look something like this
This means that Instructions for CALL/CREATE need to be set from This can be a pair of handlers that With the implementation of EOF I hope this will become clearer as we would need this kind of abstraction. |
Handler was partially refactored to have more simpler call flow. To close this PR sub calls should be able to be generalised in trait and specified in the Handler. |
We should override instructions from
This would make the current The default impl of those host instructions should act as dummy (empty,fail) replacements in Interpreter. For this PR we should have a trait Frame {
/// New or init of the frame, it pops values from interpreter and created dyn Box over itself
/// Called from instruction
fn new(interpreter, evm) -> Option<Box<dyn Frame>>
/// Run interpreter with all needed data.
/// Called from main loop.
fn run(evm, shared_memory,instruction_table) -> ReturnOrExtCall
/// Called by child frame to returns the output
fn interpreter(&mut self) -> &mut Interpreter;
/// That this Frame output and set it to parent Interpreter
fn return_to_parent(self, parent: &mut Interpreter)
}
/// Implemented for `Call` and `Crate` as those are the only ones that can be called from transaction.
trait FirstFrame {
fn output(self) -> ...
} |
Please look into how this can be simplified and where the cutting point between the Instruction and sub call inside Evm should be, it is a little blurry now.
Try to consolidate both Create and calls into one structure, intention for both of them is to create a new call frame and execute some bytecode, pre and post interpreter logic is different but the flow is the same.
Try to make the frame stack more uniform, to be able to introduce new generic calls, this part is rigid in the Handler.
The text was updated successfully, but these errors were encountered: