I agree that “stack too deep” can be solved without these opcodes! However, solc hasn’t been able to solve it yet, and we can’t wait forever. This error is not acceptable in what should by now be a mature tech stack, and with Solidity being the most popular language for the EVM, I don’t think it’s unreasonable for Ethereum to take this measure at the VM level.
I think the listed downsides are only minor issues or can be mitigated:
- Cache: This is a fair point that needs to be measured and reflected in the gas schedule. For example, if SWAPN/DUPN are likely to read from L2 cache instead of L1 cache, the cost might be 10x that of SWAP/DUP (which would be 10 gas if repriced according to EIP-7904).
- Decoding complexity: We’re talking about 25 lines of self-contained code consisting of simple arithmetic and conditionals. However, if this is deemed too complex, the EIP can very easily be switched to use push-postfix immediates, which require no decoding.
- Compilation to native: I think this requires a more careful statement and discussion. I’m personally not convinced that the addition of SWAPN/DUPN makes compilation any more difficult than it already is. If I understand correctly, the argument is that these opcodes can potentially increase the number of simultaneously live values, but IMO they don’t: if a sequence of instructions grows the stack to height N, we can assume there are N live values, whether they are accessed via SWAPN/DUPN or only accessed when they’re in the top 16 stack slots. A compiler has to figure out what to do with the other N-16 values, with or without SWAPN/DUPN. Most likely, they will be spilled to memory, and that’s where SWAPN/DUPN should read them from. This would also support a higher gas cost, but as far as I know compilation to native is not a consideration that goes into choosing the gas schedule.
- Opcode use: I believe there are currently 106 free opcodes, so definitely not a shortage. If this is a real concern, the same impact can be achieved by just including DUPN.
I’m supportive of changing the memory model. I agree that it’d be a good improvement with broader impact than this EIP. It wouldn’t be as immediate a fix for “stack too deep” as this EIP though.