-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Bitwise shifting instructions in EVM #215
Conversation
73cf336
to
4bab879
Compare
EIPS/eip-draft_bitwise_shifts.md
Outdated
The `ROL` instruction (rotate left) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the second popped value `arg2` circular shifted to the left by the number of bits in the first popped value `arg1`. | ||
|
||
``` | ||
(arg1 shl arg2) or (arg1 shr (256 - arg2) |
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.
The most interesting use-cases for rolling are hash functions and other cryptographic primitives. In most cases, those require rolling inside 32 or 64 bits but seldomly inside 256 bits. Would it make sense to give another argument that determines the "width" of the roll? As the shift amount only takes a single byte, we could even encode both values inside the second argument, although that would make it less easy to use for variable roll amounts.
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.
@chriseth A variable-width rotate instruction is interesting, though it might be better to wait for narrower data types.
@axic Are rotates really 4 times more expensive than a shift? Probably so. Most bigint libraries I've looked at, including Go, don't support them. So they will get implemented as you define them, e.g. (arg1 shl arg2) or (arg1 shr (256 - arg2)
. That also makes it tempting to leave them out, as the user can implement them that way for about the same performance and gas price. It's only for smaller data types where chips have native rotates that we really would need ROR and ROL.
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 tend to think that leaving it out is better since it is not supported by many underlying libraries, hence it will have to be implemented by hand in the VM. And when doing so we shouldn't give a subsidised gas cost - hence my suggested cost.
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.
As discussed offline, it makes no sense to include it in this form as 256-bit rotations are quite useless (= not used in any mainstream crypto algorithm).
Instead of having rotate which takes 3 parameters, the specific 32 or 64 bit rotates can be implemented with shifts in the code in question.
With the proposed SIMD operators rotate could be included.
Please renumber this as eip-215 and we will merge as a draft. |
I think it should be 145 based on the original issue id. |
EIPS/eip-145.md
Outdated
``` | ||
|
||
Notes: | ||
- `arg2` is interpreted as unsigned number. |
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 the case for all shifts, so let's move it somewhere up into any generic description.
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.
Are you happy for me to merge this? |
@Arachnid seems like we have to clarify one part of |
Can we define SAR Python-style like |
I think it wasn't specified in existing opcodes, |
Looks good to me. Still wish we had rotate, but it can wait. |
LGTM! |
But where did the rotates go? |
256-bit rotates are pretty much useless (at least today). Your SIMD proposal supports 32/64bit rotates, that is way more useful. |
Still would like them just for operational completeness, but I get what you are saying. |
@chfast added the comparison |
@chfast the operand order follows that of the other arithmetic opcodes, however I think we should reverse them, because I have a hunch it is a more natural usecase to shift a number already on the stack by a constant, than the other way around. The current version results in a lot of DUP/SWAP cases, just like it is with |
I would go for it. This would also remove |
Yes, the operand order for DIV and SDIV are broken. |
@axic As there are no more comments about this, can you revert the operand order? |
@chfast I can do it, but if I won't by Tuesday can you push a PR? 😉 Also need to get tests done as a next step. |
@chfast updated, please review |
EIPS/eip-145.md
Outdated
@@ -27,51 +27,51 @@ The following instructions are introduced: | |||
|
|||
### `0x1b`: `SHL` (shift left) | |||
|
|||
The `SHL` instruction (shift left) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the first popped value `arg1` shifted to the left by the number of bits in the second popped value `arg2`. The result is equal to | |||
The `SHL` instruction (shift left) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the second popped value `arg2` shifted to the left by the number of bits in the first popped value `arg1`. The result is equal to |
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 would skip "second popped" / "first popped". If the order is not clear, it should be clarified in the first part of the sentence.
How about
... pushes on the stack the result of the
arg2
shifted to the left by the number of bits inarg1
.
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.
Actually:
shifted to the left by
arg1
number of bits
wouldn't be more readable?
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.
@Souptacular @Arachnid @gcolvin this should be ready to merge ✨ |
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, merge when you are ready, Alex.
@gcolvin it has to be someone with merging rights :) |
Introduce bitwise shifting.
(Replaces the old issue #145.)