[enhancement] enable inlining script assembly

[A60AB5450353F40E]

will be useful for producing optimized libraries

or just to save bytes by forcing some checks or ops to be carried out in a particular manner

[rkalis]

I think this will be very useful long-term. But for now it is kind of hard to integrate in a type-safe way. So I don't think we'll be able to implement this in CashScript v1.0. But definitely something to consider for later.

[mr-zwets]

version v1.0 has been called off for the foreseeable future as we have focused on first having integrated debugging tooling before focusing on re-usable libraries.

Still it can be useful to already discuss what in-lining script might look like 👍

Here is how solidity does it, with full fledged in-lining of assembly
https://docs.soliditylang.org/en/latest/assembly.html

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

library GetCode {
 function at(address addr) public view returns (bytes memory code) {
 assembly {
 // retrieve the size of the code, this needs assembly
 let size := extcodesize(addr)
 // allocate output byte array - this could also be done without assembly
 // by using code = new bytes(size)
 code := mload(0x40)
 // new "memory end" including padding
 mstore(0x40, add(code, and(add(add(size, 0x20), 0x1f), not(0x1f))))
 // store length in memory
 mstore(code, size)
 // actually retrieve the code, this needs assembly
 extcodecopy(addr, add(code, 0x20), 0, size)
 }
 }
}

[mr-zwets]

After discussion with @kiok46 about the possibility of in-lining script assembly I want to add to this research thread

First, note that even though EVM is also stack based with opcodes, the assembly code you write in Solidity’s is actually a secondary language called 'Yul' which is higher level than evm script with opcodes directly (see the solidity docs for more info)

I don't think a syntax allowing for in-lining any raw script like this will ever be possible:

contract Test(int somenumber){
 function example(){
 assembly {
 op_1 op_add
 }
 }
}

The user can't even know where the targeted int somenumber is on the stack when trying to do the low-level manipulations.
Used stack items would have to be explicitly imported and the returned values of any low level operation would have to be explicitly defined

Instead of prematurely trying to create a secondary language inside CashScript, I think it would be better to focus on having better support for hand-optimized/hand-written contracts.

For example with issue #214 and #217

[rkalis]

If we wanted to support inline assembly, we'd probably want to have proper typechecking / other semantic analysis. E.g. that could look like this:

contract Test(int x) {
 function example() {
 int y = 10;

 assembly {
 y, x = SWAP(x, y) // this swaps the stack items, it works because the stack is ordered like the params in SWAP(...)
 VERIFY(y) // !! this will throw a compiler error, because y is not on the top of the stack
 VERIFY(x) // this will not throw a compiler error, because it knows x is on top of the stack
 VERIFY(ADD(y, x)) // this also works, because the stack order in ADD is correct, and after that the result is VERIFY'd
 // not sure if we actually want to support this kind of nested syntax though, perhaps it should be this:
 int z = ADD(y, x)
 int z2 = DUP(z)
 VERIFY(z2)
 }

 require(z2 == 12); // this is fine
 require(y == z); // Error: y and z both no longer exist on the stack
 }
}