\n<\/p>\n
Over the past two weeks our primary focus has been getting all of the clients updated to PoC5 compatibility, and it definitely has been a long road. Among the changes to the VM include:<\/p>\n
The largest changes, however, have been to the architecture surrounding the protocol. On the GUI side, the C++ and Go clients are evolving rapidly, and we will see more updates from that side coming very shortly. If you have been following Ethereum closely, you have likely seen Denny\u2019s Lotto<\/a>, a full implementation of a lottery, plus GUI, written and executed inside the C++ client. From here on, the C++ client will shift toward being a more developer-oriented tool, whereas the Go client will start to focus on being a user-facing application (or rather, meta-application). On the compiler side, Serpent has undergone a number of substantial improvements.<\/p>\n First, the code. You can peek into the Serpent compiler under the hood and you will be able to see all of the functions<\/a>available, together with their precise translations into EVM code. For example, we have:<\/p>\n 72: \u00a0\u00a0\u00a0\u00a0[‘access’, 2, 1, This means that what access(x,y) is actually doing under the hood is it\u2019s recursively compiling whatever x and y actually are, and then loading the memory at index x + y * 32; hence, x is the pointer to the start of the array and y is the index. This code structure has been around since PoC4, but now I have upgraded the meta-language used to describe translations even further, so as to include even if, while and init\/code in this construction (before they were special cases); now, only set and seq remain as special cases, and if I wanted to I could even remove seq by reimplementing it as a rewrite rule<\/a>.<\/p>\n The largest changes so far have been for PoC5 compatibility. For example, if you run serpent compile_to_assembly ‘return(msg.data[0]*2)’, you will see:<\/p>\n [“
\n73: \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0[”, ”, 32, ‘MUL’, ‘ADD’, ‘MLOAD’]],<\/p>\n