Skip to content
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
merged 12 commits into from
Sep 22, 2017
108 changes: 108 additions & 0 deletions EIPS/eip-draft_bitwise_shifts.md
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)
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

```

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/).