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

core/vm: implement metropolis static call opcode #14978

Merged
merged 2 commits into from Aug 16, 2017

Conversation

Projects
None yet
3 participants
@karalabe
Member

karalabe commented Aug 15, 2017

Implements ethereum/EIPs#214

@karalabe karalabe requested a review from holiman Aug 15, 2017

@karalabe karalabe added the metropolis label Aug 15, 2017

@karalabe karalabe added this to the 1.7.0 milestone Aug 15, 2017

obscuren and others added some commits Aug 15, 2017

core/vm: minor polishes, fix STATICCALL for precompiles
 * Fix STATICCALL so it is able to call precompiles too
 * Fix write detection to use the correct value argument of CALL
 * Fix write protection to ignore the value in CALLCODE

@karalabe karalabe referenced this pull request Aug 15, 2017

Closed

Metropolis aggregate PR #14726

7 of 8 tasks complete
}
contract.Gas += returnGas
evm.interpreter.intPool.put(addr, inOffset, inSize, retOffset, retSize)

This comment has been minimized.

@holiman

holiman Aug 15, 2017

Contributor

Instead of allocating a new bigint, and returning e.g. addr to the intpool, you could do

addr.setUint64(0 or 1)
stack.push(addr)
@holiman

holiman Aug 15, 2017

Contributor

Instead of allocating a new bigint, and returning e.g. addr to the intpool, you could do

addr.setUint64(0 or 1)
stack.push(addr)

This comment has been minimized.

@karalabe

karalabe Aug 15, 2017

Member

Looking through the other instructions, similar tricks could be done throughout the code. Also there are a lot of stack.pop().Uint64() invocations which don't even return the big int into the pool, just silently discard it.

All in all I think it would be wiser to do a whole refactor for all the opcode and do that in a separate PR where we can review the optimization changes without metro additions in there.

@karalabe

karalabe Aug 15, 2017

Member

Looking through the other instructions, similar tricks could be done throughout the code. Also there are a lot of stack.pop().Uint64() invocations which don't even return the big int into the pool, just silently discard it.

All in all I think it would be wiser to do a whole refactor for all the opcode and do that in a separate PR where we can review the optimization changes without metro additions in there.

This comment has been minimized.

@holiman

holiman Aug 15, 2017

Contributor

Yeah, I have one such laying around, which also uses peek instead of pop, so you just make sure that the result winds up there and everything is dandy.

@holiman

holiman Aug 15, 2017

Contributor

Yeah, I have one such laying around, which also uses peek instead of pop, so you just make sure that the result winds up there and everything is dandy.

@karalabe karalabe merged commit 76069ee into ethereum:master Aug 16, 2017

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
commit-message-check/gitcop All commit messages are valid
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment