This is a 3-part series that assumes you know Solidity and want to understand YUL. We will start from absolute basics and build up to writing real contracts.<\/p>\n
YUL is a low-level language that compiles to EVM bytecode. When you write Solidity, the compiler turns it into YUL, then into bytecode. Writing YUL directly gives you precise control over what the EVM executes.<\/p>\n
Code Repository<\/strong>: All code examples from this guide are available in the YUL Examples repository.<\/a> Each part has its own directory with working examples you can compile and\u00a0test.<\/p>\n YUL is a human-readable, low-level intermediate language that compiles to EVM bytecode. It is what Solidity compiles to before becoming the bytecode that runs on Ethereum.<\/p>\n Important distinction<\/strong>: YUL is not<\/em> raw EVM assembly. It is a structured intermediate representation (IR) that compiles to EVM opcodes. YUL provides higher-level constructs (functions, variables, control flow) that are then compiled down to the stack-based EVM\u00a0opcodes.<\/p>\n You can write YUL in two\u00a0ways:<\/p>\n Inline assembly<\/strong> inside Solidity contracts (using assembly { }\u00a0blocks)Standalone YUL files<\/strong> (.yul files that compile directly to bytecode)<\/p>\n This guide covers both approaches<\/strong>. We start with inline assembly to bridge from Solidity, then show standalone YUL contracts.<\/p>\n Before diving into syntax, understand these core principles:<\/p>\n Everything is a 256-bit word<\/strong>: All values are 32-byte words, no exceptionsAll operations are stack-based<\/strong>: Operations push and pop values from the\u00a0stackNothing is implicit<\/strong>: No ABI encoding\/decoding, no safety checks, no type\u00a0systemMemory and calldata must be managed manually<\/strong>: You decide where to read from and write\u00a0to<\/p>\n This mental model will help you understand why YUL code looks the way it\u00a0does.<\/p>\n YUL syntax is\u00a0minimal:<\/p>\n Comments<\/strong>: \/\/ Single-line or \/* Multi-line *\/Literals<\/strong>: Numbers as decimal (42) or hex\u00a0(0x2A)Blocks<\/strong>: Code in curly braces {\u00a0}Statements<\/strong>: Separated by newlines or semicolons<\/p>\n The EVM is a stack-based machine<\/strong>. All operations work with values on a stack. You push values, operate on them, and pop them off. The stack has a maximum depth of 1024\u00a0items.<\/p>\n 5 \/\/ Push 5 \u2192 stack: [5] Visualization:<\/strong><\/p>\n Initial: [] dup1, <\/strong>dup2,\u00a0… <\/strong>dup16<\/strong>: Duplicate value from\u00a0positionswap1, <\/strong>swap2,\u00a0… <\/strong>swap16<\/strong>: Swap top with value at\u00a0positionpop<\/strong>: Remove top\u00a0value<\/p>\n add \/\/ Addition Important<\/strong>: For sub, div, and mod, the operation is second_value op top_value.<\/p>\n Example:<\/strong><\/p>\n \/\/ Stack: [10, 3] eq \/\/ Equal (returns 1 if equal, 0 if not) and \/\/ Bitwise AND (commonly used as logical when values are 0 or 1; YUL does not have a boolean type) Bit shifting moves bits left or right in a\u00a0number:<\/p>\n shl(bits, value)<\/strong>: Shift left (multiply by\u00a02^bits)<\/p>\n Moves all bits to the left, fills right with\u00a0zerosshl(1, 5) = 5 << 1 = 10 (binary: 101 \u2192\u00a01010)<\/p>\n shr(bits, value)<\/strong>: Shift right (divide by\u00a02^bits)<\/p>\n Moves all bits to the right, fills left with\u00a0zerosshr(1, 10) = 10 >> 1 = 5 (binary: 1010 \u2192\u00a0101)<\/p>\n Why shifting\u00a0matters:<\/strong><\/p>\n Extract specific parts of a\u00a0valuePosition bits for packing\/unpackingRemove unwanted data from the left or\u00a0right<\/p>\n YUL has only one data type: 256-bit unsigned integers<\/strong> (u256). No strings, arrays, structs, or booleans. Use 0 for false, 1 for\u00a0true.<\/p>\n Inline assembly still uses the stack underneath. When you write add(a, b) in an assembly block, Solidity automatically places a and b on the stack, then add pops both values, adds them, and pushes the result. This is the same stack operations as the raw 5, 3, add\u00a0example.<\/p>\n The difference is syntax: inline assembly lets you use function-like syntax while the stack operations happen automatically. In standalone YUL, you are responsible for value lifetimes and ordering, even though YUL provides expression syntax (like add(x, y)) that abstracts individual dup and swap instructions.<\/p>\n The easiest way to start with YUL is using inline assembly<\/strong> inside Solidity contracts. This lets you write YUL code within familiar Solidity\u00a0syntax.<\/p>\n Let us start with a simple Solidity function and convert it to inline assembly:<\/p>\n Solidity version:<\/strong><\/p>\n function add(uint256 a, uint256 b) public pure returns (uint256) { Inline assembly\u00a0version:<\/strong><\/p>\n function add(uint256 a, uint256 b) public pure returns (uint256 result) { What changed:<\/strong><\/p>\n The assembly { } block contains YUL\u00a0codeadd(a, b) is the YUL addition operationresult\u00a0:= assigns the result to the return\u00a0variableSolidity still handles function parameters and return values automatically<\/p>\n Note<\/strong>: You can also define variables inside the assembly block using\u00a0let:<\/p>\n assembly { Why this is\u00a0useful:<\/strong><\/p>\n You can optimize specific functionsYou learn YUL graduallyYou keep Solidity\u2019s safety features (function selectors, ABI encoding)<\/p>\n Memory is a temporary byte array used to store intermediate values and return data. It is not persisted between\u00a0calls.<\/p>\n Memory is organized in 32-byte words<\/strong>. Address 0 = first 32 bytes, address 32 = next 32 bytes, and so\u00a0on.<\/p>\n mstore(position, value)<\/strong>: Stores a 256-bit value at a memory\u00a0position<\/p>\n mstore(0, 42) \/\/ Store 42 at position 0-31 mload(position)<\/strong>: Loads a 256-bit value from\u00a0memory<\/p>\n mstore(0, 42) Why we need\u00a0memory:<\/strong><\/p>\n To return values from functionsTo prepare data for function\u00a0callsTo work with temporary data<\/p>\n Important note for inline assembly in Solidity:<\/strong><\/p>\n For learning clarity, we use memory slot <\/strong>0 in examples.<\/strong> Production Solidity inline assembly should allocate memory using the free memory\u00a0pointer.<\/p>\n What is scratch\u00a0space?<\/strong><\/p>\n Solidity uses memory positions 0 to 0x3F (64 bytes) as “scratch space” for temporary operationsSolidity may overwrite data you store in these positions at any\u00a0timeUsing mstore(0,\u00a0…) in production code is unsafe because Solidity might overwrite it<\/p>\n What is the free memory\u00a0pointer?<\/strong><\/p>\n Solidity tracks where free memory starts at position\u00a00x40The value stored at 0x40 tells you the next available memory\u00a0addressThis is how Solidity knows where to safely allocate new\u00a0memory<\/p>\n How to use it in production:<\/strong><\/p>\n assembly { \/\/ Use this address for your data \/\/ Update the free memory pointer (move it forward by 32 bytes) For standalone YUL contracts, you have full control and can use any memory position.<\/p>\n Important<\/strong>: mstore and mload always operate on 32 bytes, regardless of the starting position.<\/p>\n If you use unaligned addresses (not multiples of 32), you can overwrite adjacent\u00a0data:<\/p>\n mstore(7, 42) \/\/ Writes 32 bytes starting at byte 7 \u2192 writes to bytes 7-38 Problems with unaligned writes:<\/strong><\/p>\n Overwrites adjacent data (writes span word boundaries)mload reads 32 bytes, so you might read overlapping dataUnpredictable results when reading\u00a0back<\/p>\n Best practice<\/strong>: Always use aligned addresses (0, 32, 64, 96,\u00a0\u2026) for mstore and mload. Use mstore8 if you need byte-level writes.<\/p>\n To return data from a function, you\u00a0must:<\/p>\n Store the data in\u00a0memoryUse return(offset, size) to return\u00a0it<\/p>\n return(offset, size)<\/strong>: Returns size bytes starting from memory position\u00a0offset<\/p>\n let result := 42 \u26a0\ufe0f Important for inline assembly<\/strong>: In inline assembly, return() immediately exits the entire Solidity function and returns raw bytes, bypassing Solidity’s normal return handling. Use it only when you intend to fully control the return\u00a0data.<\/p>\n Complete example:<\/strong><\/p>\n function getValue() public pure returns (uint256) { Calldata is the input data sent with a transaction. It contains the function selector (first 4 bytes) and function parameters (ABI-encoded).<\/p>\n For a function like transfer(address to, uint256\u00a0amount):<\/p>\n Bytes 0\u20133: Function\u00a0selectorBytes 4\u201335: to (address, padded to 32\u00a0bytes)Bytes 36\u201367: amount (uint256)<\/p>\n calldataload(position)<\/strong>: Loads 32 bytes from\u00a0calldata<\/p>\n let selector := calldataload(0) \/\/ Loads bytes 0-31<\/p>\n Important<\/strong>: Production YUL code should check calldatasize() before reading parameters to avoid out-of-bounds reads. The examples in this guide assume calldata is long enough for demonstration purposes.<\/p>\n Extracting the function selector:<\/strong><\/p>\n calldataload(0) loads 32 bytes, but the function selector is only the first 4 bytes. We need to extract just those 4\u00a0bytes.<\/p>\n The problem:<\/strong><\/p>\n Calldata: [selector (4 bytes)][padding (28\u00a0bytes)]calldataload(0) returns: [selector][padding] (all 32\u00a0bytes)We want: just the selector (4\u00a0bytes)<\/p>\n The solution: Shift right by 224\u00a0bits<\/strong><\/p>\n let selector := shr(224, calldataload(0)) \/\/ Shift right by 224 bits<\/p>\n Why 224\u00a0bits?<\/strong><\/p>\n 32 bytes = 256 bits\u00a0totalSelector = 4 bytes = 32\u00a0bitsPadding = 28 bytes = 224\u00a0bitsShift right by 224 bits moves the selector to the rightmost position and removes the\u00a0padding<\/p>\n Visual example:<\/strong><\/p>\n Before shift (32 bytes): The selector is now in the rightmost 4 bytes, with zeros on the\u00a0left.<\/p>\n Reading function parameters:<\/strong><\/p>\n \/\/ Read ‘to’ (skip 4 bytes for selector) Why mask addresses:<\/strong><\/p>\n Addresses are 20 bytes, but calldata pads them to 32\u00a0bytesThe leftmost 12 bytes are\u00a0zerosMasking keeps only the rightmost 20\u00a0bytes<\/p>\n How masking\u00a0works:<\/strong><\/p>\n The and operation performs bitwise AND: it keeps bits where both values are 1, and clears bits where either is\u00a00.<\/p>\n The mask 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF is 20 bytes of all 1s (rightmost 20 bytes). When you and a value with this\u00a0mask:<\/p>\n Leftmost 12 bytes: AND with 0 \u2192 becomes 0 (cleared)Rightmost 20 bytes: AND with 1 \u2192 stays the same\u00a0(kept)<\/p>\n Why masking is necessary:<\/strong><\/p>\n Masking is defensive programming: it ensures we only use the rightmost 20 bytes even if calldata is malformed or contains unexpected values.<\/p>\n In normal cases, addresses are already left-padded with\u00a0zeros:<\/p>\n Input: 0x0000000000000000000000001234567890123456789012345678901234567890 But what if calldata is malformed or a malicious caller passes non-zero values in the leftmost 12\u00a0bytes?<\/p>\n Malicious input: 0xFFFFFFFFFFFFFFFFFFFFFFFF1234567890123456789012345678901234567890 What could go wrong without\u00a0masking:<\/strong><\/p>\n If you use an unmasked address value directly, the garbage bytes\u00a0could:<\/p>\n Incorrect storage slot calculations<\/strong>: When computing keccak256(address, slot) for mappings, the garbage bytes change the hash, leading to wrong storage\u00a0slotsSecurity vulnerabilities<\/strong>: An attacker could manipulate storage by crafting addresses with specific leftmost\u00a0bytesBroken assumptions<\/strong>: Your code might assume addresses are 20 bytes, but unmasked values are 32 bytes with\u00a0garbageUnexpected behavior<\/strong>: Comparisons, equality checks, and other operations could fail or behave unexpectedly<\/p>\n \u26a0\ufe0f Always mask addresses from calldata.<\/strong><\/p>\n Note<\/strong>: This function is not meant to be realistic. It is a mechanical demonstration of concepts covered in Part\u00a01.<\/p>\n Here is a complete function demonstrating all concepts from Part\u00a01:<\/p>\n function processAddressAndAmount(address addr, uint256 amount) public pure returns (uint256) \/\/ 2. Read address from calldata (position 4, after selector) \/\/ 3. Mask address to ensure only 20 bytes (demonstrates defensive programming) \/\/ 4. Read uint256 from calldata (position 36, after selector + address) \/\/ 5. Store values in memory (demonstrates memory operations) \/\/ 6. Perform a calculation (e.g., add selector to amount for demonstration) \/\/ 7. Return the result Note:<\/strong> The function has parameters (`address addr, uint256 amount`) that Solidity would normally handle automatically. The parameters are intentionally unused in the function body. We read from calldata manually to demonstrate how calldata parsing works. In practice, you would use the parameters directly, but reading from calldata shows the low-level mechanics.<\/p>\n What happens step by\u00a0step:<\/strong><\/p>\n Function selector extraction<\/strong>: shr(224, calldataload(0)) extracts the 4-byte selector from\u00a0calldataAddress reading<\/strong>: calldataload(4) reads the address parameter (32\u00a0bytes)Address masking<\/strong>: and(…, mask) ensures only the rightmost 20 bytes are used, clearing any\u00a0garbageAmount reading<\/strong>: calldataload(36) reads the uint256 parameterMemory storage<\/strong>: mstore stores both values in memory for potential useCalculation<\/strong>: Performs an operation (in this example, adds selector to\u00a0amount)Return<\/strong>: Stores result in memory and returns\u00a0it<\/p>\n Standalone YUL files (.yul) compile directly to bytecode. They require more setup but give you full\u00a0control.<\/p>\n A standalone YUL contract has two\u00a0parts:<\/p>\n object “ContractName” { object “runtime” { What each part\u00a0does:<\/strong><\/p>\n code block<\/strong>: Runs during deployment. It copies the runtime code and returns it. This is what gets stored on-chain.runtime code block<\/strong>: The actual contract code that runs on every\u00a0call.<\/p>\n datacopy(dest, offset, size)<\/strong>: Copies data to\u00a0memory<\/p>\n dest: Memory position to copy\u00a0tooffset: Source data\u00a0offsetsize: Number of bytes to\u00a0copy<\/p>\n dataoffset(“name”)<\/strong>: Returns the offset of a named object’s\u00a0data<\/p>\n datasize(“name”)<\/strong>: Returns the size of a named object’s\u00a0data<\/p>\n Why this structure:<\/strong><\/p>\n The code block sets up the\u00a0contractThe runtime block contains the actual\u00a0logicThis separation is required for standalone YUL contracts<\/p>\n Important<\/strong>: This standalone contract does not implement ABI dispatch. Any calldata sent is interpreted as raw arguments (function selector + parameters). Any call to this contract, regardless of selector, will execute the same code.<\/strong> In a real contract, you would check the function selector and route to different handlers (we\u2019ll cover this in Part\u00a03).<\/p>\n Here is a complete standalone YUL contract demonstrating all Part 1 concepts:<\/p>\n object “ProcessAddress” { \/\/ 2. Return the runtime code (this is what gets stored on-chain) object “runtime” { \/\/ 1. Extract function selector (demonstrates bit shifting) \/\/ 2. Read address from calldata (position 4, after selector) \/\/ 3. Mask address to ensure only 20 bytes (demonstrates defensive programming) \/\/ 4. Read uint256 from calldata (position 36, after selector + address) \/\/ 5. Store values in memory (demonstrates memory operations) \/\/ 6. Perform a calculation (e.g., add selector to amount) \/\/ 7. Return the result What each part\u00a0does:<\/strong><\/p>\n Deployment (<\/strong>code\u00a0block):<\/strong><\/p>\n datacopy(0, dataoffset(“runtime”), datasize(“runtime”))<\/strong>:Copies the runtime code from the runtime object into memory at position\u00a00dataoffset(“runtime”) returns where the runtime object’s data starts in the contract\u00a0bytecodedatasize(“runtime”) returns the size of the runtime code in\u00a0bytes<\/p>\n 2. return(0, datasize(“runtime”))<\/strong>:<\/p>\n Returns the runtime code from\u00a0memoryThis returned code is what gets stored on-chain as the\u00a0contract<\/p>\n Runtime (<\/strong>runtime object’s <\/strong>code\u00a0block):<\/strong><\/p>\n Function selector extraction<\/strong>: Uses shr(224, calldataload(0)) to extract the 4-byte\u00a0selectorAddress reading and masking<\/strong>: Reads address from calldata and masks it to ensure only 20\u00a0bytesAmount reading<\/strong>: Reads uint256 from\u00a0calldataMemory operations<\/strong>: Stores values in memory using\u00a0mstoreCalculation<\/strong>: Performs an operation with the\u00a0valuesReturn<\/strong>: Returns the\u00a0result<\/p>\n Avoid these common pitfalls when learning\u00a0YUL:<\/p>\n 1. Forgetting to mask addresses<\/strong><\/p>\n Addresses from calldata are 32 bytes, but only 20 bytes are\u00a0validAlways mask: addr\u00a0:= and(addr, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)Unmasked addresses can corrupt storage slot calculations<\/p>\n 2. Using unaligned <\/strong>mstore addresses<\/strong><\/p>\n mstore always writes 32 bytes, regardless of starting\u00a0positionUse aligned addresses (0, 32, 64, 96,\u00a0\u2026) to avoid overlapping writesUse mstore8 for byte-level writes if\u00a0needed<\/p>\n 3. Assuming Solidity safety checks\u00a0exist<\/strong><\/p>\n YUL has no type system, no overflow protection, no bounds\u00a0checkingYou must validate all inputs\u00a0manuallyCheck calldatasize() before reading parameters<\/p>\n 4. Using <\/strong>return() in inline assembly without understanding<\/strong><\/p>\n return() in inline assembly bypasses Solidity’s return\u00a0handlingIt immediately exits the function with raw\u00a0bytesOnly use when you need full control over return\u00a0data<\/p>\n 5. Using memory slot <\/strong>0 in production Solidity\u00a0code<\/strong><\/p>\n Memory below 0x40 is scratch space and may be overwrittenAlways use the free memory pointer: mload(0x40)Examples in this guide use slot 0 for learning clarity\u00a0only<\/p>\n The stack underlies everything<\/strong>: All operations work with the\u00a0stackInline assembly bridges Solidity and YUL<\/strong>: Start here to learn graduallyMemory is for temporary data<\/strong>: Use it to store return\u00a0valuesCalldata contains function inputs<\/strong>: Read parameters manuallyReturn requires memory<\/strong>: Store data in memory, then return\u00a0itStandalone YUL needs structure<\/strong>: code block for deployment, runtime for\u00a0logic<\/p>\n In the next part, we will dive deep into storage<\/strong>, the persistent database where contract state lives. We\u2019ll see why incorrect storage access is far more dangerous than incorrect memory\u00a0usage.<\/p>\n Questions?<\/strong> Drop a comment below and I\u2019ll do my best to\u00a0help!<\/p>\n Want to stay updated?<\/strong> Follow to get notified when Part 2 is published.<\/p>\n YUL: Solidity\u2019s Low-Level Language (Without the Tears), Part 1: Stack, Memory, and Calldata<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" This is a 3-part series that assumes you know Solidity and want to understand YUL. We will start from absolute basics and build up to writing real contracts. YUL is a low-level language that compiles to EVM bytecode. When you write Solidity, the compiler turns it into YUL, then into bytecode. Writing YUL directly gives […]<\/p>\n","protected":false},"author":0,"featured_media":126070,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-126069","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/126069"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=126069"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/126069\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/126070"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=126069"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=126069"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=126069"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What YUL Is (Briefly)<\/h3>\n
How to Think in\u00a0YUL<\/h3>\n
Basic Syntax<\/h3>\n
The Stack: The Foundation<\/h3>\n
How the Stack\u00a0Works<\/h3>\n
3 \/\/ Push 3 \u2192 stack: [5, 3]
add \/\/ Pop 3 and 5, add them, push 8 \u2192 stack: [8]<\/p>\n
After 5: [5]
After 3: [5, 3]
After add: [8]<\/p>\nCommon Stack Operations<\/h3>\n
Arithmetic Operations<\/h3>\n
sub \/\/ Subtraction (second – top)
mul \/\/ Multiplication
div \/\/ Division (second \/ top)
mod \/\/ Modulo (second % top)<\/p>\n
sub \/\/ 10 – 3 = 7 (result: [7])
div \/\/ 10 \/ 3 = 3 (result: [3])
mod \/\/ 10 % 3 = 1 (result: [1])<\/p>\nComparison Operations<\/h3>\n
lt \/\/ Less than (second < top)
gt \/\/ Greater than (second > top)
iszero \/\/ Is zero (returns 1 if top is 0)<\/p>\nLogical Operations<\/h3>\n
or \/\/ Bitwise OR (commonly used as logical when values are 0 or 1; YUL does not have a boolean type)
xor \/\/ XOR
not \/\/ Bitwise NOT (flips all 256 bits)<\/p>\nBit Shift Operations<\/h3>\n
Data Types<\/h3>\n
From Stack Operations to Functions<\/h3>\n
Inline Assembly: Your Bridge from\u00a0Solidity<\/h3>\n
Your First Inline\u00a0Assembly<\/h3>\n
return a + b;
}<\/p>\n
assembly {
result := add(a, b)
}
}<\/p>\n
let sum := add(a, b) \/\/ Define variable inside assembly
\/\/ Use sum here
}<\/p>\nMemory: Where Return Values\u00a0Live<\/h3>\n
Memory Layout<\/h3>\n
Memory Operations<\/h3>\n
mstore(32, 100) \/\/ Store 100 at position 32-63<\/p>\n
let value := mload(0) \/\/ value is now 42<\/p>\n
\/\/ Get the current free memory pointer
let freeMemPtr := mload(0x40)<\/p>\n
mstore(freeMemPtr, yourData)<\/p>\n
mstore(0x40, add(freeMemPtr, 32))
}<\/p>\nMemory Alignment<\/h3>\n
mstore(18, 100) \/\/ Writes 32 bytes starting at byte 18 \u2192 writes to bytes 18-49
\/\/ These writes overlap! Bytes 18-38 are overwritten by both operations.<\/p>\nReturn Operations<\/h3>\n
mstore(0, result) \/\/ Store result in memory
return(0, 32) \/\/ Return 32 bytes from position 0<\/p>\n
assembly {
let value := 42
mstore(0, value)
return(0, 32) \/\/ Exits function immediately, returns raw bytes
}
}<\/p>\nCalldata: Reading Function\u00a0Inputs<\/h3>\n
Calldata Layout<\/h3>\n
Calldata Operations<\/h3>\n
[selector (4 bytes)][padding (28 bytes)]
0xa9059cbb00000000000000000000000000000000000000000000000000000000After shr(224, …):
[zeros][selector (4 bytes)]
0x00000000000000000000000000000000000000000000000000000000a9059cbb
^^^^^^^^
Just the selector<\/p>\n
let to := calldataload(4)
\/\/ Mask to get just the address (20 bytes)
to := and(to, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)\/\/ Read ‘amount’ (skip 4 + 32 = 36 bytes)
let amount := calldataload(36)<\/p>\n
^^^^^^^^^^^^^^^^^^^^^^^^ already zeros
kept ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<\/p>\n
^^^^^^^^^^^^^^^^^^^^^^^^^^ garbage (could cause issues)<\/p>\n
assembly {
\/\/ 1. Extract function selector (demonstrates bit shifting)
\/\/ calldataload(0) loads 32 bytes, but selector is only 4 bytes
\/\/ Shift right by 224 bits (28 bytes) to move selector to rightmost position
let selector := shr(224, calldataload(0))<\/p>\n
let addr := calldataload(4)<\/p>\n
\/\/ Addresses are 20 bytes, but calldata pads them to 32 bytes
\/\/ Masking clears any potential garbage in the leftmost 12 bytes
addr := and(addr, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)<\/p>\n
let amount := calldataload(36)<\/p>\n
mstore(0, addr) \/\/ Store address at position 0
mstore(32, amount) \/\/ Store amount at position 32<\/p>\n
\/\/ In a real contract, you’d do something meaningful with addr and amount
let result := add(selector, amount)<\/p>\n
mstore(0, result) \/\/ Store result at memory position 0
return(0, 32) \/\/ Return 32 bytes from memory position 0
}
}<\/p>\nStandalone YUL Contracts<\/h3>\n
Contract Structure<\/h3>\n
code {
\/\/ Deployment code – runs once when contract is created
datacopy(0, dataoffset(“runtime”), datasize(“runtime”))
return(0, datasize(“runtime”))
}<\/p>\n
code {
\/\/ Runtime code – this is the actual contract
\/\/ Your functions go here
}
}
}<\/p>\nDeployment Operations<\/h3>\n
Complete Standalone YUL\u00a0Example<\/h3>\n
code {
\/\/ Deployment code – runs once when contract is created
\/\/ 1. Copy runtime code to memory using datacopy
\/\/ – Destination: memory position 0
\/\/ – Source: dataoffset(“runtime”) – where the runtime object’s data starts
\/\/ – Size: datasize(“runtime”) – how many bytes the runtime code is
datacopy(0, dataoffset(“runtime”), datasize(“runtime”))<\/p>\n
\/\/ – Offset: 0 (where we copied the code in memory)
\/\/ – Size: datasize(“runtime”) (how many bytes to return)
return(0, datasize(“runtime”))
}<\/p>\n
code {
\/\/ Runtime code – this runs on every function call<\/p>\n
\/\/ calldataload(0) loads 32 bytes, but selector is only 4 bytes
\/\/ Shift right by 224 bits to move selector to rightmost position
let selector := shr(224, calldataload(0))<\/p>\n
let addr := calldataload(4)<\/p>\n
\/\/ Addresses are 20 bytes, but calldata pads them to 32 bytes
\/\/ Masking clears any potential garbage in the leftmost 12 bytes
addr := and(addr, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)<\/p>\n
let amount := calldataload(36)<\/p>\n
mstore(0, addr) \/\/ Store address at position 0
mstore(32, amount) \/\/ Store amount at position 32<\/p>\n
\/\/ In a real contract, you’d do something meaningful with addr and amount
let result := add(selector, amount)<\/p>\n
mstore(0, result) \/\/ Store result at memory position 0
return(0, 32) \/\/ Return 32 bytes from memory position 0
}
}
}<\/p>\nCommon Beginner\u00a0Mistakes<\/h3>\n
What We\u00a0Learned<\/h3>\n