EVM stack question

Question

I have this simple Smart Contract

contract C {
    uint256 a;

    function C() {
        a = 1;
    }
}

running

solc --bin --asm c1.sol

it throws out:

======= C =======
EVM assembly:
.code:
  PUSH 60       contract C {...
  PUSH 40       contract C {...
  MSTORE            contract C {...
tag2: 
  JUMPDEST      function C() {...
  PUSH 1        1
  PUSH 0        a
  PUSH 0        a
  POP           a = 1
  DUP2          a = 1
  SWAP1         a = 1
  SSTORE            a = 1
  POP           a = 1
tag3: 
  JUMPDEST      function C() {...
  PUSH #[$00000000…00000000]        contract C {...
  DUP1          contract C {...
  PUSH [$00000000…00000000]     contract C {...
  PUSH 0        contract C {...
  CODECOPY          contract C {...
  PUSH 0        contract C {...
  RETURN            contract C {...
.data:
  0: 
  .code:
    PUSH 60     contract C {...
    PUSH 40     contract C {...
    MSTORE          contract C {...
    PUSH [tag2]     contract C {...
    JUMP            contract C {...
  tag2: 
    JUMPDEST        contract C {...
    STOP            contract C {...
Binary: 
60606040525b60016000600050819055505b600a80601d6000396000f360606040526008565b00

I can't understand this two OPCODE

PUSH 0 a POP a = 1

I'm trying to reconstruct the stack:

1. PUSH 1 --> [1]
2. PUSH 0 --> [0,1]
3. PUSH 0 --> [0,0,1]
4. POP --> [0,1]
5. DUP2 --> [1,0,1]
6. SWAP1 --> [0,1,1]
7. SSTORE --> [1]
8. POP --> []

Why I need Instruction at point 3 and 4? They look unuseful

Answer 1

You are correct, they are not useful and are just junk generated by the compiler.

The amount of junk is compiler version dependent. I'm using 0.4.19-develop.2017.11.6+commit.dc154b4e.Linux.g++ and it produces one fewer pointless push/pop combination than in your example.

The Solidity optimiser is quite good at cleaning these things up if they trouble you. You can use the --optimize flag to see the effect. But some people prefer not to use the optimiser since it is another step in the toolchain, which means another step in which errors could be introduced.

If you are really troubled about this stuff (as I am!) you can check out other smart contract languages, such as LLL which produces very clean EVM bytecode - akin to inline assembly code.