-
Notifications
You must be signed in to change notification settings - Fork 2.2k
EVM-C v3 #3510
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #3510 +/- ##
===========================================
- Coverage 66.1% 66.03% -0.08%
===========================================
Files 308 308
Lines 22896 22903 +7
===========================================
- Hits 15135 15123 -12
- Misses 7761 7780 +19
|
I'm not really familiar with cpp-ethereum internals so cannot comment much on this. |
libevm/JitVM.cpp
Outdated
@@ -21,9 +21,9 @@ inline evm_uint160be toEvmC(Address _addr) | |||
return *reinterpret_cast<evm_uint160be*>(&_addr); | |||
} | |||
|
|||
inline Address fromEvmC(evm_uint160be _addr) | |||
inline Address fromEvmC(evm_uint160be const* _addr) |
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.
Could we pass the const reference here (and in asUint
) and reinterpret_cast the reference?
I think it'd be cleaner to dereference the pointer on the calling side, the thing like asUint(ptr)
gave me a microsecond of confusion, it's not immediately clear that the function converts the value pointed to and not the pointer
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.
Yes, that make sense. I recently have noticed they look bad. I will also try to use std::copy
instead of reinterpret_cast
if proven to generate the same code.
} | ||
|
||
void evm_update( | ||
void updateState( |
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 do you rename this but not evm_query
?
and also evm_call
& evm_get_tx_context
are snake_case, while updateState
& getBlockHash
are camelCase
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.
With this PR I renamed some changed function to match our naming convention. I will do the same for the rest.
libevm/JitVM.cpp
Outdated
{ | ||
assert(_outputSize == 20); | ||
u256 gas = _gas; | ||
u256 gas = _msg->gas; | ||
// TODO: How it knows who the sender is? |
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.
for create
ExtVM gets it from myAddress
member initialized in constructor
libevm/JitVM.cpp
Outdated
{ | ||
return *reinterpret_cast<evm_uint160be*>(&_addr); | ||
return *reinterpret_cast<evm_uint160be const*>(&_addr); |
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.
Can we do just return reinterpret_cast<evm_uint160be const&>(_addr);
?
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.
I was so long in C world, I forgot this is possible. I've changed that, however it feels a bit awkward.
libevm/JitVM.cpp
Outdated
switch (_key) | ||
{ | ||
case EVM_SSTORE: | ||
{ | ||
auto index = asUint(_arg1->uint256be); | ||
auto value = asUint(_arg2->uint256be); | ||
auto index = fromEvmC(_arg1->uint256be); |
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.
auto
& fromEvmC
name combination is a little confusing here, it's not clear to what we convert
params.gas = _msg->gas; | ||
params.apparentValue = value; | ||
params.valueTransfer = _msg->kind == EVM_DELEGATECALL ? 0 : params.apparentValue; | ||
params.senderAddress = fromEvmC(_msg->sender); |
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 did we get rid of conditional here and in apparentValue
?
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.
Because it is now VM responsibility to prepare correct message object. E.g. VM has to set correct sender depending on it is executing DELEGATECALL or CALL. At the moment EVMJIT handles that similarly in https://github.com/ethereum/evmjit/pull/112/files#diff-0ee981fc82c3fceb0467c22ad927823cR166. But it can be done better.
Windows build fails on |
Fixed. Fancy array iterator MSVC has :) |
GCC is not happy now :) |
Maybe something like just |
I will fix it :) |
@@ -141,6 +141,12 @@ class FixedHash | |||
/// @returns a constant byte pointer to the object's data. | |||
byte const* data() const { return m_data.data(); } | |||
|
|||
/// @returns begin iterator. | |||
auto begin() const -> typename std::array<byte, N>::const_iterator { return m_data.begin(); } |
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.
Shouldn't we call these cbegin
& cend
?
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.
I don't think some, cbegin()
is only useful when you have a non-const object, with begin() const
and begin()
and you want to enforce getting const iterator.
This implements EVM-C v3 on the cpp-ethereum side, specified ethereum/evmjit#110.
EVMJIT part: ethereum/evmjit#112.