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
Merged

Conversation

axic
Copy link
Member

@axic axic commented Feb 13, 2017

Introduce bitwise shifting.

(Replaces the old issue #145.)

@axic axic changed the title Draft for bitwise shifting opcodes Bitwise shifting instructions in EVM Feb 13, 2017
@axic axic force-pushed the bitwise-ops branch 2 times, most recently from 73cf336 to 4bab879 Compare February 13, 2017 16:22
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.

@Arachnid
Copy link
Contributor

Please renumber this as eip-215 and we will merge as a draft.

@axic
Copy link
Member Author

axic commented Apr 22, 2017

I think it should be 145 based on the original issue id.

EIPS/eip-145.md Outdated
```

Notes:
- `arg2` is interpreted as unsigned number.
Copy link
Member

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.

Copy link
Member

@chfast chfast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@Arachnid
Copy link
Contributor

Are you happy for me to merge this?

@axic
Copy link
Member Author

axic commented Apr 26, 2017

@Arachnid seems like we have to clarify one part of SAR today.

@chfast
Copy link
Member

chfast commented Apr 26, 2017

Can we define SAR Python-style like floor(arg1 / 2**arg2). Otherwise it will difficult to specify it using existing opcodes.

@axic
Copy link
Member Author

axic commented Jul 3, 2017

Otherwise it will difficult to specify it using existing opcodes.

I think it wasn't specified in existing opcodes,udiv is not present. Though I agree we should be more specific in defining them.

@axic
Copy link
Member Author

axic commented Jul 3, 2017

@chfast updated.

@Arachnid I think this should be ready now.

@gcolvin
Copy link
Contributor

gcolvin commented Jul 3, 2017

Looks good to me. Still wish we had rotate, but it can wait.

@holiman
Copy link
Contributor

holiman commented Jul 28, 2017

LGTM!

@gcolvin
Copy link
Contributor

gcolvin commented Jul 28, 2017

But where did the rotates go?

@axic
Copy link
Member Author

axic commented Jul 28, 2017

256-bit rotates are pretty much useless (at least today). Your SIMD proposal supports 32/64bit rotates, that is way more useful.

@gcolvin
Copy link
Contributor

gcolvin commented Jul 28, 2017

Still would like them just for operational completeness, but I get what you are saying.

@axic
Copy link
Member Author

axic commented Jul 31, 2017

@chfast added the comparison

@axic
Copy link
Member Author

axic commented Aug 4, 2017

@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 DIV/SDIV.

@chfast
Copy link
Member

chfast commented Aug 4, 2017

I would go for it. This would also remove SWAP1 from my snippets.

@gcolvin
Copy link
Contributor

gcolvin commented Aug 5, 2017

Yes, the operand order for DIV and SDIV are broken.

@chfast
Copy link
Member

chfast commented Aug 11, 2017

@axic As there are no more comments about this, can you revert the operand order?
I can also do this by creating a PR to this PR :D

@axic
Copy link
Member Author

axic commented Aug 11, 2017

@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.

@axic
Copy link
Member Author

axic commented Sep 22, 2017

@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
Copy link
Member

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 in arg1.

Copy link
Member Author

@axic axic Sep 22, 2017

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?

Copy link
Member

@chfast chfast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@axic
Copy link
Member Author

axic commented Sep 22, 2017

@Souptacular @Arachnid @gcolvin this should be ready to merge ✨

Copy link
Contributor

@gcolvin gcolvin left a 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.

@axic
Copy link
Member Author

axic commented Sep 22, 2017

@gcolvin it has to be someone with merging rights :)

@gcolvin gcolvin merged commit 35c7ade into ethereum:master Sep 22, 2017
@axic axic deleted the bitwise-ops branch September 22, 2017 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants