Alternative design for shift opcodes by lu-pinto · Pull Request #10216 · besu-eth/besu

lu-pinto · 2026-04-10T09:22:53Z

PR description

I was honestly not convinced with the current design of the opcodes on EVM V2 from #10154 so I did some experimentation and I would like to challenge the existing design.
I managed to achieve the same performance level while splitting up duties between the arithmetic/bitwise computations from the opcodes themselves. Opcodes should be the ones fetching/updating the stack, and not the code that does computations - this should be strictly decoupled from one another.

IMO code looks much cleaner and easier to read. It also benefits from code reuse with already existing arithmetics in UInt256. I will take a look at repurposing shl and shr for modulus arithmetics in another PR as well as I believe we might be able to reuse them.

Performance stats:

Test Case	Latency (ns) main@2d4f077c27	Latency (ns) @065670ffe3
SarV2_SHIFT_0	6.049	6.334
SarV2_NEGATIVE_SHIFT_1	8.681	8.83
SarV2_POSITIVE_SHIFT_1	7.969	8.312
SarV2_ALL_BITS_SHIFT_1	8.518	8.804
SarV2_NEGATIVE_SHIFT_128	6.796	7.223
SarV2_NEGATIVE_SHIFT_255	6.996	7.546
SarV2_POSITIVE_SHIFT_128	6.756	7.101
SarV2_POSITIVE_SHIFT_255	6.765	6.959
SarV2_OVERFLOW_SHIFT_256	6.848	7.222
SarV2_OVERFLOW_LARGE_SHIFT	6.954	7.356
SarV2_FULL_RANDOM	15.349	15.379
ShlV2_SHIFT_0	5.785	6.362
ShlV2_SHIFT_1	8.492	8.778
ShlV2_SHIFT_128	7.149	7.105
ShlV2_SHIFT_255	6.871	7.277
ShlV2_OVERFLOW_SHIFT_256	6.647	7.698
ShlV2_OVERFLOW_LARGE_SHIFT	6.832	7.798
ShlV2_FULL_RANDOM	11.927	8.183
ShrV2_SHIFT_0	5.817	6.357
ShrV2_SHIFT_1	7.742	8.233
ShrV2_SHIFT_128	6.833	6.975
ShrV2_SHIFT_255	6.824	7.061
ShrV2_OVERFLOW_SHIFT_256	6.642	7.69
ShrV2_OVERFLOW_LARGE_SHIFT	6.805	7.846
ShrV2_FULL_RANDOM	11.381	8.628

Issue(s)

#10131

Thanks for sending a pull request! Have you done the following?

Checked out our contribution guidelines?
Considered documentation and added the doc-change-required label to this PR if updates are required.
Considered the changelog and included an update if required.
For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

spotless: ./gradlew spotlessApply
unit tests: ./gradlew build
acceptance tests: ./gradlew acceptanceTest
integration tests: ./gradlew integrationTest
reference tests: ./gradlew ethereum:referenceTests:referenceTests
hive tests: Engine or other RPCs modified?

ahamlat · 2026-04-10T09:56:52Z

evm/src/main/java/org/hyperledger/besu/evm/v2/operation/SarOperationV2.java

+  public static OperationResult staticOperation(final MessageFrame frame) {
    if (!frame.stackHasItems(2)) return UNDERFLOW_RESPONSE;
-    frame.setTopV2(StackArithmetic.sar(stack, frame.stackTopV2()));
+    long[] _stack = frame.stackDataV2();


I would suggest to just use stack instead of _stack to be inline with the naming used in the project.

ahamlat · 2026-04-10T09:57:17Z

evm/src/main/java/org/hyperledger/besu/evm/v2/operation/ShlOperationV2.java

    if (!frame.stackHasItems(2)) return UNDERFLOW_RESPONSE;
-    frame.setTopV2(StackArithmetic.shl(stack, frame.stackTopV2()));
+    long[] _stack = frame.stackDataV2();


I would suggest to just use stack instead of _stack to be inline with the naming used in the project.

ahamlat · 2026-04-10T09:57:24Z

evm/src/main/java/org/hyperledger/besu/evm/v2/operation/ShrOperationV2.java

+  public static OperationResult staticOperation(final MessageFrame frame) {
    if (!frame.stackHasItems(2)) return UNDERFLOW_RESPONSE;
-    frame.setTopV2(StackArithmetic.shr(stack, frame.stackTopV2()));
+    long[] _stack = frame.stackDataV2();


I would suggest to just use stack instead of _stack to be inline with the naming used in the project.

Sure, it is a leftover from the previous method argument before I removed it

ahamlat · 2026-04-10T10:00:49Z

evm/src/main/java/org/hyperledger/besu/evm/UInt256.java

+        || shift.u2() != 0
+        || shift.u1() != 0
+        || Long.compareUnsigned(shift.u0(), 256) >= 0) {
+      bytesToShift = 256;


I guess this is bitsToShift ?

We use bitShift in private methods below

yes it is bits, well spotted

ahamlat · 2026-04-10T10:04:20Z

evm/src/main/java/org/hyperledger/besu/evm/UInt256.java

+        || shift.u2() != 0
+        || shift.u1() != 0
+        || Long.compareUnsigned(shift.u0(), 256) >= 0) {
+      bytesToShift = 256;


The same as above.

ahamlat · 2026-04-10T10:05:09Z

evm/src/main/java/org/hyperledger/besu/evm/UInt256.java

+    return new UInt256(w3, w2, w1, w0);
+  }
+
+  private static long shiftLeftWord(final long value, final long nextValue, final int bitShift) {


Add javadoc.

ahamlat · 2026-04-10T10:05:13Z

evm/src/main/java/org/hyperledger/besu/evm/UInt256.java

+    return (value << bitShift) | (nextValue >>> (64 - bitShift));
+  }
+
+  private static long shiftRightWord(final long value, final long prevValue, final int bitShift) {


Add javadoc.

ahamlat · 2026-04-10T10:11:00Z

evm/src/test/java/org/hyperledger/besu/evm/v2/operation/ShiftOperationsV2PropertyBasedTest.java

-    final long[] s = new long[8];
-    writeLimbs(s, 0, valueVal);
-    writeLimbs(s, 4, shiftVal);
+    final UInt256 result = executor.execute(valueVal, shiftVal);


👍 (this is a good argument that this design is better)

ahamlat

I like the proposed design, I find it better and the code much cleaner. There is a small performance regression, could you double check if it is real with multiple runs and investigate the origin.

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

lu-pinto · 2026-04-10T15:01:29Z

I like the proposed design, I find it better and the code much cleaner. There is a small performance regression, could you double check if it is real with multiple runs and investigate the origin.

Looked into it and optimised a little more - but I'm going to park it here. Worst cases (FULL_RANDOM) are much closer or have improved significantly. IMO these are prob the most realistic ones.
The other ones are very hard to get better numbers without impacting the worse case because I primarily optimized for it.

ahamlat · 2026-04-10T15:23:56Z

evm/src/test/java/org/hyperledger/besu/evm/v2/operation/SarOperationV2Test.java

        Arguments.of(
            "0x8000000000000000000000000000000000000000000000000000000000000000",
-            "0x100",
+            "0x0100",


Why do make this change and all the changes below on unit tests ?

Is it related not using anymore fromHexStringLenient ?

changed fromHexStringLenient to fromHexString in the test to make the hexadecimal exact without having to guess if there will be a zero or not prepended. Hard to know if you don't know what lenient does. Since we are providing the values hardcoded does it make sense to "disguise" them? For instance 0x0 is half a byte so it seems lenient would put a zero to complete the byte.
I can revert it if you feel strongly about it.

lu-pinto requested review from ahamlat and siladu and removed request for siladu April 10, 2026 09:23

lu-pinto force-pushed the shift-opcodes-alt-design branch from da22999 to 82337b0 Compare April 10, 2026 09:24

ahamlat reviewed Apr 10, 2026

View reviewed changes

lu-pinto added 6 commits April 10, 2026 14:21

Move SAR implementation to UInt256

65b3c23

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

Move SHL implementation to UInt256

5a8a8f5

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

Move SRL implementation to UInt256

833a2e7

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

spotless

2dfdae0

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

javadoc

5187470

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

eliminate wasteful branch

f4ed77d

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

lu-pinto force-pushed the shift-opcodes-alt-design branch from 82337b0 to f4ed77d Compare April 10, 2026 13:21

lu-pinto added 2 commits April 10, 2026 14:30

nit: var renaming

3fe50fa

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

add additional stack tests for shifts

065670f

Signed-off-by: Luis Pinto <luis.pinto@consensys.net>

ahamlat reviewed Apr 10, 2026

View reviewed changes

ahamlat approved these changes Apr 10, 2026

View reviewed changes

lu-pinto mentioned this pull request Apr 10, 2026

Add MULMOD to EVMv2 #10168

Open

Conversation

lu-pinto commented Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR description

Issue(s)

Thanks for sending a pull request! Have you done the following?

Locally, you can run these tests to catch failures early:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lu-pinto Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ahamlat left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lu-pinto commented Apr 10, 2026

Uh oh!

ahamlat Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

lu-pinto commented Apr 10, 2026 •

edited

Loading

lu-pinto Apr 10, 2026 •

edited

Loading

ahamlat left a comment •

edited

Loading

ahamlat Apr 10, 2026 •

edited

Loading