-
Notifications
You must be signed in to change notification settings - Fork 81
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
EVM-C update #108
EVM-C update #108
Conversation
b666038
to
acf60f7
Compare
/// The function has to be named as `<vm-name>_get_interface(void)`. | ||
/// Each EVM implementation is obligated to provided a function returning | ||
/// an EVM instance. | ||
/// The function has to be named as `<vm-name>_get_factory(void)`. |
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.
Why does the function have to have a particular form of name?
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.
This is more convention than strict requirement. I was also thinking about having a registry of VM implementation, where you could get one by name... But this is not worth the trouble.
Sorry, I didn't manage to look at this yet. |
The evm_result was planned to be used as the return struct of the call callback. The address was added to support CREATE, but it is never used and the union here confuses many languages like Go and Python.
Replace evm_interface with evm_factory. The factory provides ABI protection and the function for creating EVM instances. After the instance is create you can discard the factory as it is no longer needed.
We try to avoid C ABI complex rules like passing structs by value to increase portability.
In evm_query_fn, return result by explicit output parameter to avoid C ABI issues and inrease portability. C compiler would do the same implicitly.
Preview of proposed EVM-C changes. Currently, users have to carry 2 objects: EVM-C interface and instance. Interface describes ABI version and set of "virtual" functions to manage instances. This is inconvenient as users typically create single interface and single instance but need to have both to execute any code.
This PR propose a change to always create an EVM instance, "virtual" functions are included in the instance object. Still initialization must be perform in two steps (create and init), because we want (do we?) init step to be able to be changed in future ABI versions.
I have not updated any comments around the changes yet, sorry.