evmone
evmone copied to clipboard
execution: export the execute symbol
When building quick prototypes, I often find it useful to directly access the execute method, instead of having to bring up the whole EMVC environment.
Wouldn't you also want to export at least set_option too? I think it would be better to expose the same functionality the EVMC wrapper is covering.
I wonder however where is the big implementation overhead. The EVMC wrapper just puts all these into a struct.
This looks fine, but maybe it is better to start maintaining public API in public
evmone.hheader. Theexecution.hppis not being installed.It is also fine to merge this up front.
Nah it's ok I'll move it there.
I wonder however where is the big implementation overhead. The EVMC wrapper just puts all these into a struct.
In the binding code, I'm not using C/C++
Codecov Report
Merging #282 (ae8be1e) into master (1e739f4) will not change coverage. The diff coverage is
100.00%.
@@ Coverage Diff @@
## master #282 +/- ##
=======================================
Coverage 99.75% 99.75%
=======================================
Files 24 24
Lines 3634 3634
=======================================
Hits 3625 3625
Misses 9 9
| Flag | Coverage Δ | |
|---|---|---|
| unittests | 99.75% <100.00%> (ø) |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| lib/evmone/evmone.cpp | 100.00% <ø> (ø) |
|
| lib/evmone/execution.cpp | 100.00% <100.00%> (ø) |
set_option is part of evmc, and moving it to evmone will probably break stuff, right?
I wonder however where is the big implementation overhead. The EVMC wrapper just puts all these into a struct.
In the binding code, I'm not using C/C++
I meant all EVMC is doing is putting these function pointers into a struct. Which should not be such a terrible thing to deal with in other languages. What language are you using?
set_option is part of evmc, and moving it to evmone will probably break stuff, right?
Btw, are you sure you are using latest master? In latest master there's an O (optimiser) setting to select the baseline or the advanced evmone. The advanced is what existed first. It would make sense to expose this if we chose to expose execute.
I meant all EVMC is doing is putting these function pointers into a struct. Which should not be such a terrible thing to deal with in other languages. What language are you using?
And this is a big problem for languages who manage their memory differently: in short, the GC needs to keep tracking data even inside the callback. https://crystal-lang.org/reference/syntax_and_semantics/c_bindings/callbacks.html
There is a fairly complicated process involved, so it's more than just putting a function pointer inside a C function, something that isn't necessary if execute is public.
Btw, are you sure you are using latest master? In latest master there's an
O(optimiser) setting to select the baseline or the advanced evmone. The advanced is what existed first. It would make sense to expose this if we chose to exposeexecute.
I am not, but I went through the code and didn't see this setting. Where can I find it?
And this is a big problem for languages who manage their memory differently
I know the pain with Rust, at least it has boxes to solve it. We were also thinking how EVMC could be improved to avoid these problems or whether it still is relevant at all.
Btw, are you sure you are using latest master? In latest master there's an
O(optimiser) setting to select the baseline or the advanced evmone. The advanced is what existed first. It would make sense to expose this if we chose to exposeexecute.I am not, but I went through the code and didn't see this setting. Where can I find it?
Sorry for missing your response. It is here: https://github.com/ethereum/evmone/blob/master/lib/evmone/evmone.cpp#L28
@chfast so should just execute and baseline_execute be exported as the quick solution?