Skip to content
This repository has been archived by the owner on Oct 28, 2021. It is now read-only.

EVM-C v3 #3510

Merged
merged 15 commits into from
May 10, 2017
Merged

EVM-C v3 #3510

merged 15 commits into from
May 10, 2017

Conversation

chfast
Copy link
Member

@chfast chfast commented Jan 18, 2017

This implements EVM-C v3 on the cpp-ethereum side, specified ethereum/evmjit#110.

EVMJIT part: ethereum/evmjit#112.

@codecov-io
Copy link

codecov-io commented Apr 5, 2017

Codecov Report

Merging #3510 into develop will decrease coverage by 0.07%.
The diff coverage is 100%.

@@             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
Impacted Files Coverage Δ
libevm/JitVM.cpp 90.29% <100%> (+0.37%) ⬆️
libdevcore/FixedHash.h 93.81% <100%> (+0.13%) ⬆️
test/tools/fuzzTesting/fuzzHelper.cpp 33.33% <0%> (-5.4%) ⬇️
libp2p/Host.cpp 72.36% <0%> (-1.06%) ⬇️
libp2p/Common.cpp 52% <0%> (-0.8%) ⬇️
libp2p/NodeTable.cpp 39.52% <0%> (-0.6%) ⬇️

@axic
Copy link
Member

axic commented May 5, 2017

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)
Copy link
Member

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

Copy link
Member Author

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(
Copy link
Member

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

Copy link
Member Author

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?
Copy link
Member

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);
Copy link
Member

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); ?

Copy link
Member Author

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);
Copy link
Member

@gumb0 gumb0 May 8, 2017

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);
Copy link
Member

@gumb0 gumb0 May 8, 2017

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?

Copy link
Member Author

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.

@gumb0
Copy link
Member

gumb0 commented May 9, 2017

Windows build fails on std::copy(addr.begin(), addr.end(), _outputData)

@chfast
Copy link
Member Author

chfast commented May 9, 2017

Fixed. Fancy array iterator MSVC has :)

@gumb0
Copy link
Member

gumb0 commented May 9, 2017

GCC is not happy now :)

@gumb0
Copy link
Member

gumb0 commented May 9, 2017

Maybe something like just std::copy_n(addr.data(), Address::size, _outputData) ?

@chfast
Copy link
Member Author

chfast commented May 9, 2017

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(); }
Copy link
Member

@gumb0 gumb0 May 9, 2017

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 ?

Copy link
Member Author

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.

@chfast chfast merged commit db8a4a2 into develop May 10, 2017
@chfast chfast deleted the evmc-v3 branch May 10, 2017 22:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants