Tengo este contrato inteligente simple
contract C {
uint256 a;
function C() {
a = 1;
}
}
correr
solc --bin --asm c1.sol
arroja:
======= 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
No puedo entender estos dos OPCODE
EMPUJE 0 a POP a = 1
Estoy tratando de reconstruir la pila:
¿Por qué necesito Instrucción en el punto 3 y 4? se ven inútiles
Tiene razón, no son útiles y son solo basura generada por el compilador.
La cantidad de basura depende de la versión del compilador. Estoy usando 0.4.19-develop.2017.11.6+commit.dc154b4e.Linux.g++
y produce una combinación push/pop sin sentido menos que en su ejemplo.
El optimizador Solidity es bastante bueno para limpiar estas cosas si te causan problemas. Puedes usar la --optimize
bandera para ver el efecto. Pero algunas personas prefieren no usar el optimizador ya que es un paso más en la cadena de herramientas, lo que significa otro paso en el que se pueden introducir errores.
Si está realmente preocupado por estas cosas (¡como yo!), puede consultar otros lenguajes de contratos inteligentes, como LLL , que produce un código de bytes EVM muy limpio, similar al código de ensamblaje en línea.