-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Merged
+94
−0
Merged
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
4bab879
Draft of bitwise shifting opcodes
axic a63aef3
Remove ROR/ROL
axic 0b34616
Add link to client support (cpp-ethereum)
axic 7bc4477
Swap shift operands (value is the top item)
axic 27847a8
Rename to EIP145
axic d4f5382
Clarify shift amount (arg2)
axic e5ca919
Use floor and not udiv/sdiv
axic 4218665
Explain sign of arg1/arg2
axic 0b08d11
Add comparison with current opcodes
axic 9464fa7
Clarify text (user -> use)
axic d01c9af
Swapp operand order for bitwise shifting
axic 74d9a17
Clarify wording about arg1/arg2
axic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,108 @@ | ||
## Preamble | ||
|
||
EIP: <to be assigned> | ||
Title: Bitwise shifting instructions in EVM | ||
Author: Alex Beregszaszi, Paweł Bylica | ||
Type: Standard Track | ||
Category Core | ||
Status: Draft | ||
Created: 2017-02-13 | ||
|
||
|
||
## Simple Summary | ||
|
||
To provide native bitwise shifting with cost on par with other arithmetic operations. | ||
|
||
## Abstract | ||
|
||
Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to user by a contract. | ||
|
||
## Motivation | ||
|
||
EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetics cost each 35 gas, while the proposed instructions take 3 gas. | ||
|
||
## Specification | ||
|
||
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 second popped value `arg2` shifted to the left by the number of bits in the first popped value `arg1`. The result is equal to | ||
|
||
``` | ||
(arg2 * 2^arg1) mod 2^256 | ||
``` | ||
|
||
Notes: | ||
- If the shift amount is greater or equal 256 the result is 0. | ||
|
||
### `0x1c`: `SHR` (logical shift right) | ||
|
||
The `SHR` instruction (logical shift right) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the second popped value `arg2` shifted to the right by the number of bits in the first popped value `arg1` with zero fill. The result is equal to | ||
|
||
``` | ||
arg2 udiv 2^arg1 | ||
``` | ||
|
||
Notes: | ||
- If the shift amount is greater or equal 256 the result is 0. | ||
|
||
### `0x1d`: `SAR` (arithmetic shift right) | ||
|
||
The `SAR` instruction (arithmetic shift right) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the second popped value `arg2` shifted to the right by the number of bits in the first popped value `arg1` with sign extension. The result is equal to | ||
|
||
``` | ||
arg2 sdiv 2^arg1 | ||
``` | ||
|
||
Notes: | ||
- `arg1` is interpreted as unsigned number. | ||
- If the shift amount is greater or equal 256 the result is 0 if `arg2` is non-negative or -1 if `arg2` is negative. | ||
|
||
### `0x1e`: `ROL` (rotate left) | ||
|
||
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) | ||
``` | ||
|
||
Notes: | ||
- `arg2 rol arg1` is equivalent of `arg2 rol (arg1 mod 2^256)` | ||
|
||
### `0x1f`: `ROR` (rotate right) | ||
|
||
The `ROL` instruction (rotate right) pops 2 values from the stack, `arg1` and `arg2`, and pushes on the stack the second popped value `arg2` circular shifted to the right by the number of bits in the first popped value `arg1`. | ||
|
||
``` | ||
(arg1 shr arg2) or (arg1 shl (256 - arg2) | ||
``` | ||
|
||
Notes: | ||
- `arg2 ror arg1` is equivalent of `arg2 ror (arg1 mod 2^256)` | ||
|
||
The cost of the shift instructions is set at `verylow` tier (3 gas), while the rotations are 12 gas each. | ||
|
||
## Rationale | ||
|
||
Instruction operands were chosen to match the other logical and arithmetic instructions. | ||
|
||
## Backwards Compatibility | ||
|
||
The newly introduced instructions have no effect on bytecode created in the past. | ||
|
||
## Test Cases | ||
|
||
TBA | ||
|
||
## Implementation | ||
|
||
Client support: | ||
TBA | ||
|
||
Compiler support: | ||
- Solidity: https://github.com/ethereum/solidity/tree/asm-bitshift | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.