forked from DecentralizedClimateFoundation/DCIPs
37 lines
2.3 KiB
Markdown
37 lines
2.3 KiB
Markdown
---
|
|
eip: 4520
|
|
title: Mult-byte opcodes prefixed by EB and EC.
|
|
description: Reserve `0xEB` and `0xEC` for usage as extended opcode space.
|
|
author: Brayton Goodall (@Spore-Druid-Bray), Mihir Faujdar (@uink45)
|
|
discussions-to: https://ethereum-magicians.org/t/multi-byte-opcodes/7681
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2021-12-1
|
|
---
|
|
|
|
## Abstract
|
|
Reserve `0xEB` and `0xEC` for usage as extended opcode space.
|
|
|
|
## Motivation
|
|
It would be convenient to introduce new opcodes that are likely to be infrequently used, whilst also being able to have greater than 256 opcodes in total. As a single byte opcode is half the size of a double byte opcode, the greatest efficiency in code sizes will be one where frequently used opcodes are single bytes. Two prefix bytes are used to accommodate up to 510 double byte opcodes.
|
|
|
|
## Specification
|
|
For example, a new arithmetic opcode may be allocated to `0xEC 01`(`ADD`), and a novel opcode may be introduced at `0xEB F4`(`DELEGATECALL`).
|
|
|
|
Triple byte opcodes may be doubly-prefixed by `0xEB EB`, `0xEC EC`, `0xEB EC` and `0xEC EB`. It is possible to allocate experimental opcodes to this triple-byte space initially, and if they prove safe and useful, they could later be allocated a location in double-byte or single-byte space.
|
|
|
|
Only `0xEB EB`, `0xEC EC`, `0xEC EC`, and `0xEB EC` may be interpreted as further extensions of the opcode space. `0xEB` and `0xEC` do not themselves affect the stack or memory, however opcodes specified by further bytes may. If a multi-byte opcode is yet to be defined, it is to be treated as `INVALID` rather than as a `NOP`, as per usual for undefined opcodes.
|
|
|
|
## Rationale
|
|
It was considered that two prefix bytes rather than one would be adequate for reservation as extension addresses. Both `0xEB` and `0xEC` were chosen to be part of the E-series of opcodes. For example, the `0xEF` byte is reserved for contracts conforming to the Ethereum Object Format. By having unassigned opcodes for extending the opcode space, there will be a lower risk of breaking the functionalities of deployed contracts compared to choosing assigned opcodes.
|
|
|
|
## Backwards Compatibility
|
|
Previous usage of `0xEB` and `0xEC` may result in unexpected behaviour and broken code.
|
|
|
|
## Security Considerations
|
|
There are no known security considerations.
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|