16

When I compile a blank contract:

contract A {}

with

solc --optimize --optimize-runs 300000 --opcodes test.sol

I get:

PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0x6 DUP1 PUSH1 0x10 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN PUSH1 0x60 PUSH1 0x40 MSTORE STOP

What is it? As I understand this bytecode not the code of contract, but code which during execution generate contract. But I don't get, what is going on.

Probably

PUSH1 0x60 PUSH1 0x40 MSTORE

is a pattern to allocate 64 bytes(0x40) in memory. If yes, why we need manually allocate it?

There are a few lines in Yellow paper about separation 'code' and 'data'. I can see it, when run solc with --asm-json. But how this two parts actually interact?

I feel like I missed a very important paper or manual where everything is cleared. Where can I get it?

To summarize:

  1. What does bytecode of blank contract do? If it is possible, I need explanation for each opcode.
  2. How interact code and data sections of contract?
  3. Where I can find full info about how evm works?
  • 2
    Welcome to Ethereum Stack Exchange! The first question is brilliant. However, it is preferred if you can post separate questions instead of combining your questions into one. That way, it helps the people answering your question and also others hunting for at least one of your questions. Thanks! – Waqar Lim Apr 9 '16 at 19:48
7

The "data" section mentioned in the yellow paper is the part that follows the PUSH instruction, i.e. the yellow paper only talks about push data. What you see in the assembly output is a higher-level concept.

The (init code of the) blank contract copies the final contract code from code into memory and then returns that.

Both the final contract code and the init code start with storing the so-called "free memory pointer" at memory position 0x40. This pointer tells you where the next free chunk of memory can be allocated. In the case of this contract, this is totally unnecessary and will probably be optimized away by the next improvement phase of the optimizer.

10

A user on Reddit kindly posted an opcode-by-opcode analysis for you:

PUSH1 0x60 PUSH1 0x40 MSTORE

Store 0x60 at memory location 0x40. I think this is normally used for variable indexing if you have one. I've never got into the detail of this

PUSH1 0x6 DUP1

Push 2 values of 0x6 into the stack. One is to be used as a parameter to CODECOPY, the other is to be used as a parameter to RETURN. This is the size of your code's body. It consist of PUSH1 0x60 PUSH1 0x40 MSTORE (again variable indexing) STOP (self explanatory).

PUSH 0x10

This is a parameter of CODECOPY. It refers to the offset where the code that is to be copied into the memory. Basically the body of your code (the non-constructor part).

PUSH1 0x0

Parameter of CODECOPY. It refers to which memory offset the code to be copied into.

CODECOPY

Copy part of the code into memory. Based on the parameter we have given it asks to copy 6 bytes from 17th byte offset(if you count from 1) into memory location 0.

PUSH 0x0 RETURN

RETURN takes two parameters, the number of bytes to be returned and the offset in memory to be returned. Since we are creating contract this is the code that we intend to upload. So we have 6 bytes (from the DUP1 above), which is the size and 0 (memory offset into which we copied the code above).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.