-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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 in EVM #105
Comments
So now that I have some understanding for this...it makes sense why this was left out. Basically bit shifting could be implemented natively by the underlying client....they would simply take in the opcodes that acted like shifting and then use bit shifting underneath....so this kind of makes sense to leave out now...I think. |
@axic I agree that shifting and rotation should be included, as they are basic arithmetic that can be performed much more efficiently as one operation by the VM than as a sequence of operations by the programmer. |
this is especially true since the solidity ABI uses bit (well, byte) shifting, and every contract does this, but instead of being implemented as a shift, its a big int division by a massive number. shifts could be a major performance boon. it's a shame they've been left out. that said, maybe this is something the JITs can just do for us instead of fussing with new opcodes. |
this is potentially related to #101 , tho native contracts seem like overkill when all you're trying to do is shift bits/bytes |
Either static analysis is done or specific patterns need to be following for it to pick up. I don't think it is a good reason for leaving it out. |
I think the conclusion is that shifts in form of Providing there is strong interest in implementing some hash/crypto functions in EVM, I'm for including shift ops at some point. |
Proposal
Both shift operators take two stack elements, with the top element being the index to shift with. Both take stack elements are considered unsigned. It is aligned with the rest of EVM in case of overflows: they are ignored and the result is truncated. |
I'm still unsure about including rotation opcodes. They can be very useful when implementing hash functions in EVM (such as SHA* and BLAKE). |
Replaced by #145. |
Is there any reason bitwise shifting was omitted from the EVM? Other bitwise operators are present.
In the past few months in Solidity it was a challenge to deal with arbitrary data and even efficiently implement something like hex to string or string to hex conversion.
Rudimentary shift alternatives are:
a * (2 ** b)
for shl anda / (2 ** b)
for shr. One can useSIGNEXTEND
to implement arithmetic right shift. (Using this to implement shift in Solidity: ethereum/solidity#527. Having a progression path to native shifting would make sense.)While there are some alternative opcodes in certain cases (such as the
BYTE
andMSTORE8
) I still think it would be a very useful addition to have native logical shifts (SHL and SHR). I am not fully convinced about the necessity of arithmetic right shift (SAR). Additionally bit rotation (ROR/ROL) might make sense.@chfast @gcolvin I know you were discussing the option to have 64 bit arithmetic. Did you think about including bit shifting?
The text was updated successfully, but these errors were encountered: