6080604052

    60 80                       =   PUSH1 0x80
    60 40                       =   PUSH1 0x40
    52                          =   MSTORE 

        // Define a function to allocate memory dynamically using `push`
        function allocateMemory(uint _size) public pure returns (bytes memory) {
            bytes memory dynamicData;
            assembly {
                // Allocate memory for dynamicData
                let freePtr := mload(0x40) // Load the free memory pointer
                mstore(0x40, add(freePtr, _size)) // Increase the free memory pointer
                
                // Allocate memory using `push`
                dynamicData := mload(0x40) // Load the new free memory pointer as the dynamicData
                mstore(0x40, add(dynamicData, _size)) // Move the free memory pointer ahead by _size
                
                // Update the new size in the allocated memory
                mstore(dynamicData, _size)
            }
            return dynamicData;
        }

    assembly {
        let ptr := mload(0x40) // Load the current free memory pointer
        
        mstore(ptr, 42) // Store the value 42 at the current memory pointer
        
        // Update the free memory pointer to allocate more space (if needed)
        mstore(0x40, add(ptr, 32))
    }

Here:
    - mload(0x40) retrieves the current free memory pointer, denoted by ptr.
    - mstore(ptr, 42) stores the value 42 at the location pointed to by ptr.
    - mstore(0x40, add(ptr, 32)) updates the free memory pointer (0x40) to allocate more space by moving it ahead by 32 bytes (as each slot in Ethereum memory is 32 bytes).

This sequence showcases the coordination between mload, mstore, and the adjustment of the free memory pointer. 
While push is not explicitly used here, it could be employed to increase the memory space (ptr) further if needed.

function getData() public pure returns (uint) {
    uint value = 42;
    return value;
}

Here is an example of returning the value 7:

PUSH1 0x07
PUSH1 0x50
MSTORE

PUSH1 0x20
PUSH1 0x50
RETURN
In the above example:

The MSTORE opcode takes two arguments: The memory location and the value to store.
The memory location we are using is 0x50. In practice, we’d want to choose a location that does not clash with other data in memory (note that in this rudimentary example, it doesn’t matter which value we pick, so we choose a unique one to make the code easier to read).
The value we are storing is 0x07. Note that MSTORE always writes 32 bytes of data.
The RETURN opcode takes two arguments: The memory location of the where the data-to-return resides, and the length of that data in bytes.
The memory location we are using (0x50) is the same location we wrote to using MSTORE.
The length is 32 bytes (0x20) to return the full data we wrote using MSTORE.
Once the RETURN opcodes executes, the EVM stops execution of the function call, passing the return data to the parent context. This parent context may be the end of the transaction, or another function call that used a CALL opcode.

    function manipulateData(uint[] memory dataArray) public pure returns (uint) {
        // Work with the dataArray over multiple opcodes
        uint sum = 0;
        for (uint i = 0; i < dataArray.length; i++) {
            sum += dataArray[i];
        }
        return sum;
    }


Sometimes there will be data that you need to keep track of and continuously update throughout the lifespan of your function call, but not something you need to persist across function calls. Memory is the perfect use for this.

Arguably, the most common example is Solidity’s “free memory pointer”. This value exists at memory location 0x40. Semantically, it represents “the next location in memory that hasn’t been used yet” (read more at 💠 How Solidity Manages Memory (coming soon)).

This is useful not just for Solidity, but also for any bytecode architecture that allocates memory on a dynamic basis. It allows you to always have a handle on where to put new data, without conflicting with or overriding existing data.

    function processLargeData() public pure returns (bytes memory) {
        // Generate a large data set
        bytes memory largeData = new bytes(1000);
        for (uint i = 0; i < largeData.length; i++) {
            largeData[i] = bytes1(uint8(i));
        }
    return largeData;
}

Stack items are always 32 bytes in length. Memory is not limited in this respect.

A common example is contract deployment. During the contract deployment process, your bytecode needs to return the final state of the new contract’s bytecode.

This means your deployment bytecode is returning runtime bytecode, as a value in memory. This runtime bytecode will surely be larger than 32 bytes – up to 24 kilobytes on Layer 1. This is much larger than what can fit onto the stack.