EIP-5000: MULDIV instruction

This is the discussion topic for

1 Like

This twitter thread has some interesting questions, mostly from @Recmo.

Some initial discussions we had when writing the EIP:

  1. Support both “checked” (abort on overflow) and “unchecked” (do not abort) case
  2. Whether to return multiple stack items or not
  3. Support accessing the hi bits (after division) or not

The current design wanted to avoid multiple opcodes and returning multiple stack items, hence we arrived at having the special case with z=0. However we cannot accommodate the case of getting the hi bits after division, only before.

If we do not have that special case, then we need multiple opcodes, and need to decide what happens in the z=0 case. Existing opcodes (such as DIV, ADDMOD, MULMOD, etc.) handle it specially by just returning zero. One would think however that division-by-zero should be an abort, and result in a revert.

2 Likes

Nice idea. Current implementation in smart contract is way to heavy: openzeppelin-contracts/Math.sol at c11acfd9d3b8713e196791690a7feded496ebd99 · OpenZeppelin/openzeppelin-contracts · GitHub

1 Like

Have you considered the carry flag? - see EIP 1051

In fact we did, the entire conversation started from there (see also EVM: overflow detection in arithmetic instructions · Issue #159 · ethereum/EIPs · GitHub from 2016). These are the notes before we settled on the current design:

Checked opcode #1:

  • Abort on overflow

Checked opcode #2:

  • Returns two values (overflow flag)

Checked opcode #3:

  • New opcode which sets overflow flag

(For the following we introduce a CLEAROF (clears the flag) and GETOF (puts the value of the flag on the stack) instruction.)

Overflow-check clear-per-instruction:

  • Perform the calculation
  • Overwrite overflow flag

Overflow-flag set-if-not-set:

  • Perform the calculation
  • Set overflow flag if it was zero prior the calculation

Overflow toggle:

  • Turn on overflow setting (two behaviours for opcodes like ADD)

I see. Honestly, I still do not understand the carry flag was not pursued further when simple carry checks of arithmetic operations would result in smaller bytecode (comparing to safe math and now solc outcomes).
But this is OT for this EIP.

Is this EIP being considered for the next hard fork (not shanghai)