-
Notifications
You must be signed in to change notification settings - Fork 772
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
Implement bitwise shifting #251
Conversation
Fails because of the |
@holgerd77 @cdetrio @jwasinger this would be enabled for constantinople only. How to do it? |
@axic Do you want to have this already implemented for testing purposes or anything? Or can't we just leave the PR open until Constantinople is more in sight? |
No need to merge yet until there are some state tests for it and it is fully implemented. Not sure even at that point how can we merge it since there's only one version supported: the last. But if you want you can implement the |
Just rebased this. |
Using #304 features here now. |
@holgerd77 do you want to check if the API is used correctly? |
This isn't prepared to work with block numbers yet (also since in a simulated environment (Truffle,...) block numbers are not correctly corresponding to the desired HF behaviour), this is something for later down the road once this becomes relevant for the client. For now this compares against the hardfork set in the if (runState._common.gteHardfork('constantinople') {
// Do the constantinople stuff here
} I generally had the idea to refactor the
With this we would have a cleaner structure and separation and could add the opcodes for the HF selected in if (runState._common.gteHardfork('constantinople') {
opFns = Object.assign({}, require('lib/opFns/constantinople.js'))
} (First shot, not thoroughly thought through) What do you think? |
Regarding the test setup we can also now running at least the state tests for both hardforks in parallel (especially with the now fast-running Circle tests) and keep the So we don't have to change the hardfork setting in the tester file directly, but we can introduce another {
"testState": "npm run build:dist && node ./tests/tester -s --dist --fork='byzantium'",
"testStateDev": "npm run build:dist && node ./tests/tester -s --dist --fork='constantinople"",
} ...plus a new Circle job |
I think that idea makes sense from an optimisation perspective, but right now I would think that adding single conditions achieve the goal, in terms of both readability and speed of implementing the new features. |
In that case I'd think a helper on |
@axic I think there should be currently no needs for something to be hidden if we use the API methods I describe above, like if (runState._common.gteHardfork('constantinople') {
// Do the constantinople stuff here
} Or am I missing your point? |
The block number question could be solved (and decided) by the caller in that case. |
Atm I don't really see a "block number question"? Or do you already want to start integrating dynamic fork switch support depending on block number? At the moment I would envision this for just statically instantiate the VM with Byzantium or Constantinople, and then everything is set. Or am I targeting too low? |
Didn't know |
24751c6
to
76da77d
Compare
Since SAR was not implemented and wasn't returning a stack item, the stack check code in
|
This passes the constantinople tests now, woohoo! |
Reason for coverage decrease: coveralls is only running on |
Congrats! 👍 Just double checked that all the relevant tests are passing, these should be We should really change the test summary behavior so that skipped tests are not displayed as passed ones - which currently is the case. Will see if I can make a PR here, shouldn't be that much of a change. |
Should that be part of this PR? |
Ah, just checked this manually, changing I was actually wrong on this, skipped tests are atm not counted or reported at all. This is an open (for a long time) issue on tape: tape-testing/tape#197 So we would have to manually add a counter or something, seems not worth it for the moment, this should better be added on |
So can this be merged? |
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.
Looks good.
if (a.gten(256)) { | ||
return new BN(0) | ||
} | ||
return b.shln(a.toNumber()).iand(utils.MAX_INTEGER) |
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.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md#0x1b-shl-shift-left
I am not super-fluent on bit operations, but I think I have found all conditions from the EIP in the implementation.
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.
(always a bit shaky on this signed/unsigned stuff)
if (a.gten(256)) { | ||
return new BN(0) | ||
} | ||
return b.shrn(a.toNumber()) |
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.
} else { | ||
return c | ||
} | ||
}, |
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.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md#0x1d-sar-arithmetic-shift-right
I also think I can roughly follow what is going on here and think all EIP conditions are covered and can also place all - this to me appearing a bit esoteric - mask stuff to the places in the EIP. Would have to do an extra hour of bit operation reading though for a better understanding.
Since tests are passing I will approve.
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.
Here the point is to fill the top with set bits, that is achieved by ORing the mask. The mask is then created by taking an all bits set input (MAX_INTEGER
) and making sure the bottom part where actual data remainded is 0.
Ah, just saw your question, did the review before. If you rebase, I can do a quick re-approval and we can merge if you want. |
@holgerd77 Rebased. |
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.
Renewed approval.
Based on https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md