This is the discussion topic for

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

Some initial discussions we had when writing the EIP:

- Support both â€ścheckedâ€ť (abort on overflow) and â€śuncheckedâ€ť (do not abort) case
- Whether to return multiple stack items or not
- 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.

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

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)

see discussion wrt Pectra upgrade here: Pectra Network Upgrade Meta Thread - #66 by radek

Shouldnâ€™t the return values include both remainder and the quotient? This would be more useful than an overflow flag.

So 2 stack inputs, 2 stack outputs? Would that have any impact on required gas?

It shouldnâ€™t, since both are available at the end of the muldiv computation.