This EIP introduces new EVM opcodes that allow loading a single byte from memory or calldata in a single operation, reducing gas cost and bytecode size compared to existing patterns based on MLOAD (0x51) or CALLDATALOAD (0x35) followed by bit shifting.
Currently, the only way to read a single byte from calldata or memory is to use CALLDATALOAD or MLOAD and then shift the loaded 32-byte word.
For example, reading the byte at offset x from calldata requires:
This pattern increases runtime gas cost and adds three extra bytes to the deployed bytecode for each single-byte access. Contracts that frequently parse byte-oriented calldata or instruction streams incur unnecessary overhead. This EIP proposes two new opcodes that allow loading a single byte directly in one operation.
offsetvalueReads one byte from memory at position offset and pushes it onto the stack as a 32-byte word, with the byte placed in the least significant position.
Memory expansion occurs prior to the load, after which the loaded byte is read.
If the accessed byte lies beyond the previously allocated memory, the returned value is 0 due to zero-initialization.
Memory expansion rules apply in the same way as for MSTORE8 (extending memory to at least offset + 1 bytes).
offsetvalueReads one byte from calldata at position offset and pushes it onto the stack as a 32-byte word, with the byte placed in the least significant position.
If offset is greater than or equal to CALLDATASIZE (0x36), the returned value is 0.
MLOAD8 additionally incurs memory expansion cost as defined by existing memory access rules.
The base gas cost matches MLOAD, MSTORE8, and CALLDATALOAD, ensuring consistency with existing EVM pricing.Execution results in an exceptional halt if:
In both cases, execution halts and the current call frame is reverted, consistent with existing EVM behavior.
MLOAD8 serves as a natural counterpart to MSTORE8 (0x53): one stores exactly one byte from the stack to memory, while the other loads exactly one byte from memory to the stack. This symmetry improves conceptual clarity and developer ergonomics.
Instruction-based architectures that interpret calldata as a sequence of byte-level commands benefit from reduced gas usage and smaller bytecode size when parsing instruction streams. A common pattern for reading a single byte from calldata today consists of the following instruction sequence:
CALLDATALOAD (3 gas)PUSH1 (3 gas)SHR (3 gas)This results in a total cost of 9 gas per byte read, excluding additional stack manipulation overhead, and increases deployed bytecode size due to the extra instructions.
Replacing this sequence with a single CALLDATALOAD8 instruction priced at 3 gas saves 6 gas per byte read and reduces deployed bytecode size by approximately 3 bytes per occurrence. These savings compound in contracts that repeatedly parse byte-oriented calldata or instruction streams.
While the final opcode values are subject to allocation during review, this proposal suggests placing MLOAD8 and CALLDATALOAD8 in the 0x4X opcode range. The 0x5X range, which primarily contains stack, memory, storage, and control flow operations, is largely exhausted.
Tentative values of 0x4e for MLOAD8 and 0x4f for CALLDATALOAD8 are suggested to group these instructions near existing data access operations while minimizing the risk of opcode collisions. These assignments are intended to facilitate early client prototyping and collision checking and may be adjusted during the standardization process.
This EIP introduces new opcodes and does not modify the semantics of existing instructions. No backwards compatibility issues are introduced beyond those inherent to any opcode-adding hard fork.
Assume:
calldata = 0x0123456789abcdefmemory = 0xfedcba9876543210| Bytecode | Description | Result |
|---|---|---|
5f <CALLDATALOAD8> | PUSH0; CALLDATALOAD8 | pushes 0x01 |
6002 <MLOAD8> | PUSH1 0x02; MLOAD8 | pushes 0xba |
<CALLDATALOAD8> | missing stack operand | exceptional halt |
<MLOAD8> | missing stack operand | exceptional halt |
No new security considerations are introduced beyond those already known for memory and calldata access.
Copyright and related rights waived via CC0.