Learning Assembly

In some specific cases, assembly, and its full control over memory, is the most efficient way to optimize a snippet of code.

Practice using inline assembly in your Solidity smart contracts to further optimize them, to an extent vanilla Solidity does not offer!

Assembly Optimization

Equipped with the knowledge of Solidity's storage model, we can now execute some gas optimization tricks. Explore how the reordering of state variables and the use of memory caching can save some functions a considerable amount of gas.

Storage Efficiency

The Solidity compiler packs state variables in a contract's storage space in a prudent manner. Walk through how the different types of variables are interpreted and kept in storage.

Storage Layout

Although found in niche use cases, the ability to discern a delegate call from an ordinary external call could be useful. Figure out how this can be done with some simple engineering.

Delegate Call Detection

To newer developers, the use of call() and delegatecall() can be intimidating. Especially since it seems more verbose or dangerous. However, these low-level calls are crucial to many use-cases. In this quest, learn the EVM Application Binary Interface (ABI) and how to safely use these calls.

Low-Level Calls

The third of the Five Pillars is The Scribe. Not only is his memory perfect, but he also seeks to perfectly record everything he sees, hears, and learns. He doesn’t make mistakes in his work, and to pass his trial, you must show him that you do not either. One slip up, and you may not survive the night…

Inline assembly allows the fine-grained manipulation of EVM's unconventional memory model. In this quest, learn about the EVM memory model and how to exercise control over it.

The Scribe is the master of memory. To conquer his trial, we first need a good understanding of EVM memory.

In compiled languages such as C or C++ there is only memory which is virtually divided into the stack and the heap. Both starts at opposite ends of the memory space and gradually grow on demand:

small_assembly_10.webp

thumbnail_assembly_10.webp

It is mostly used to store dynamically sized variables or variables that want to live beyond the function's scope.

The EVM also has a stack and heap, but implemented in a different manner.

large_assembly_11.webp

medium_assembly_11.webp

small_assembly_11.webp

thumbnail_assembly_11.webp

In the EVM, the stack is virtually separated from memory into its own allocated space. Since the memory only contains the heap, "heap" is renamed to "memory". This is observable in the <a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/ethereum/go-ethereum/blob/master/core/vm/interpreter.go#L41">go-ethereum implementation</a> of the EVM:

The "heap" (aka memory) in Solidity is a simplified model where there is no notion of blocks, just some allocated memory space followed by some free memory space.

Every <code class="richtext rt-inlinecode">memory</code> variable in Solidity is a pointer that refers to data living in EVM memory.

Solidity inteprets EVM memory as multiple separated regions:

medium_assembly_09.webp

small_assembly_09.webp

thumbnail_assembly_09.webp

This space is reserved for special use, and will not hold memory variables.

Memory allocated to store local variables. Memory here is never deallocated throughout the transaction duration.

lightBulb

Unused Memory, free to be allocated to store new local variables.

When programming in pure Solidity, the resultant bytecode will always respect Solidity's memory model. This means that:

However, with inline assembly, we can use memory unconventionally (e.g. use scratch space for other purposes, deallocate memory, etc.). This allows gas optimization.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part1.md#example"></a>Example

large_assembly_13.webp

medium_assembly_13.webp

small_assembly_13.webp

thumbnail_assembly_13.webp

As we can see, this somewhat mirrors the stack-heap model conventional machines employ.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part1.md#your-task"></a>Your Task

Read the description above and understand memory in Solidity.

What is memory?

Cryptomantic spells have minds of their own. They remember and forget; just like living beings.

We will learn to use and interact with the free memory pointer using inline assembly. To recap, the pointer is located at memory address <code class="richtext rt-inlinecode">0x40</code>.

The <code class="richtext rt-inlinecode">FreeMemoryPointer</code> contract wishes to implement the following functions.

Allocating memory in Solidity is straightforward, just increment the free memory pointer by the amount of bytes you want to allocate.

This is virtually labelling some of free memory as used.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part2.md#freeing-memory"></a>Freeing memory

Since contract execution is relatively short-lived, freeing memory is deliberately not supported in Solidity.

However, mimicing the freeing functionality is still an interesting exercise. The idea is to decrement the memory pointer, thereby labelling the "deallocated" memory as free space again.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part2.md#your-task"></a>Your task

Implement the functions in <code class="richtext rt-inlinecode">FreeMemoryPointer.sol</code> </code>using only inline assembly.

Free memory pointer

To master cryptomancy, you will first have to harness your memory of your spells.

Here are the assembly opcodes we can use.

As described in Solidity's memory model, the free memory pointer is located at <code class="richtext rt-inlinecode">0x40</code> in the memory space. You can therefore get the free memory address with <code class="richtext rt-inlinecode">mload(0x40)</code>.

Reading the highest memory address accessed

The <code class="richtext rt-inlinecode">msize()</code> opcode achieves this.

The memory allocation scheme in Solidity is very simple. We simply need to increment the free memory pointer at <code class="richtext rt-inlinecode">0x40</code> to declare new memory as used.

Since we allocate memory by incrementing the free memory pointer, it makes sense that we can free memory by decrementing it.

It is important to know how local variables are represented in memory and stack.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part3.md#word-size-256-bits"></a>Word Size: 256-bits

From arithmetics to hashing, the EVM performs computations on 256-bit values. Hence, for computation efficiency, aside from the exception of <code class="richtext rt-inlinecode">string</code> and <code class="richtext rt-inlinecode">bytes</code>, there is no variable packing in memory nor stack.

This means that values like <code class="richtext rt-inlinecode">uint256</code>, <code class="richtext rt-inlinecode">uint128</code>, and <code class="richtext rt-inlinecode">bool</code> all take up the same amount of space in memory: 256 bits.

As we will see, even arrays take up 256 bits on the stack...

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part3.md#value-types-vs-reference-types"></a>Value types vs Reference types

You may have heard that <code class="richtext rt-inlinecode">int256</code> is a value type, while <code class="richtext rt-inlinecode">uint256[]</code>, <code class="richtext rt-inlinecode">string</code> or <code class="richtext rt-inlinecode">struct</code> are reference types. What do these mean?

In the context of local variables, value types are (usually) stored directly on the stack. Reference types are stored as pointers, pointing to an address in memory or storage holding the actual data.

Dynamically sized arrays, strings, and structs are all reference types.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part3.md#arrays-in-memory"></a>Arrays in memory

Arrays in memory start with their length (a 256-bit value), followed by their elements.

large_assembly_12 .webp

medium_assembly_12 .webp

small_assembly_12 .webp

thumbnail_assembly_12 .webp

Each element, regardless of their type, will take up 32 bytes each (i.e. 1 word long).

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part3.md#string-and-bytes-in-memory"></a>String and bytes in memory

<code class="richtext rt-inlinecode">string</code> and <code class="richtext rt-inlinecode">bytes</code> behave like arrays but are stored differently where each element only occupies 1 byte (instead of 32 bytes).

For instance, the string <code class="richtext rt-inlinecode">"hello world"</code> is stored in memory like so:

large_assembly_04.webp

medium_assembly_04.webp

small_assembly_04.webp

thumbnail_assembly_04.webp

The <code class="richtext rt-inlinecode">MemoryLayout</code> contract wishes to implement the following functions.

The functions should respect Solidity's memory model.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/memory-manipulation/description/part3.md#your-task"></a>Your task

Implement the functions in <code class="richtext rt-inlinecode">MemoryLayout.sol</code> using only inline assembly.

Memory layout

Each time you write out your spells, the Scribe snatches away the parchment and tosses it into the fire. He demands more detail. 

Let us first sketch the overall approach in pseudo-code:

A possible solution in inline assembly is as follows:

The Scribe’s last trial awaits you.

Dynamic arrays only exist in storage. They provide convenient functionality like <code class="richtext rt-inlinecode">push(x)</code> and <code class="richtext rt-inlinecode">pop()</code>. Sadly, there is no such equivalent in memory.

Fortunately, with everything we have learned so far, we are certainly capable of achieving this in assembly.

The <code class="richtext rt-inlinecode">DynamicArray</code> contract would like to implement the following functions:

All functions should also respect Solidity’s memory model:

Implement the functions in <code class="richtext rt-inlinecode">DynamicArray.sol</code> using only inline assembly.

Creating dynamic memory arrays

As you write the same spells over and over again, you realize you are seeing them differently, simply through the practice of pulling them from memory in different ways. 

After what feels like hours, the muscles in your hand feel about ready to cramp up. You’ve used up nearly all the parchment on the desk, and only a trickle of ink remains. Just when you feel you can’t write another word, the Scribe takes your final attempt and looks at it closely. 

Very nice. As fine a hand as I ever saw. You have a talent, Guardian. Please, keep the feather…

Three down, one more to go. Can you survive the assessment?

As the hood is removed from your eyes in the next room, you are met by the third of the Pillars, the Scribe.

The Scribe is a curious man. His robe is marked by ink stains, as are his fingers. He seems distracted, and his hand twitches as if he wants to be writing. A large desk against one wall is covered by parchments, both clean and used, and a fire burns in a hearth.

Come, Guardian. Closer to the heart where it is warm. You look like you know your way around a pen. Show me.

The Scribe carefully picks a feather from a collection at his belt and hands it to you. Then he guides you to the desk. It’s time to put your penmanship to the test.

In this quest, we have seen these memory-related opcodes:

Memory Manipulation

prelude