You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: introduce special immutables address space (#2689)
This commit introduces a new address space for manipulating immutables.
It also modifies the existing "code" address space which resolves
pointers as starting from the start of the "data" section instead of the
start of the "text" section of the code (air quotes because these
sections are conceptual rather than part of an object format). Lastly it
slightly changes the semantics of the `lll` opcode (and for clarity,
renames it to `deploy`) in order to save a few instructions in the
constructor.
This is important for two reasons. One, other VMs like zksync model
immutables differently by mapping them onto storage. In order to capture
different handling of the address space (immutables -> storage in zksync
vs immutables -> runtime code in EVM), the new pseudo opcodes `iload`
and `istore` can be compiled differently depending on the backend. For
EVM, they compile to `mload` and `mstore` at magic locations calculated
at assembly time. Note that `iload` and `istore` are not valid outside
of constructor code (that is, code which does not have a child `deploy`
section), and assembly will panic if they are used in non-constructor
code.
The second reason has to do with runtime code layout. Currently, the IR
codegen has no idea what the codesize will be (as that can only be known
after assembly), so we have runtime logic to calculate offsets of data
that is stored in code (e.g. currently to get data at position `x` in
the runtime code, we need to issue pointer arithmetic `(add ~codelen x)`
to get the runtime location of the data). By introducing new pseudo
opcodes, we can resolve these locations at assembly time instead of at
runtime.
This commit also renames the "code" address space to "data", to make it
clearer that it is used to access the data section of the code. The
pseudo-opcode `codeload` has been renamed to `dload`. For the same
efficiency reason described above, `data` is considered to start at the
end of the runtime code, so `dload` usage is `dload x` instead of
`codeload (add ~codelen x)`.
To accomplish all this, a couple magic locations have been introduced
into the assembly: `_mem_deploy_start` and `_mem_deploy_end`. These are
resolved at assembly time to the end of the runtime code just prior to
deploy - immutables are stored starting from `_mem_deploy_end`. To
support the assembly-time calculation of these offsets, two magic
opcodes have been added to the assembly: `_DEPLOY_MEM_OFST_<N>` and
`_OFST`. `_DEPLOY_MEM_OFST_<N>` is used to pass information from the
memory allocator to the assembler (which is required to calculate the
location of where immutables will be stored in memory), and `_OFST` is
used to resolve offsets from `_sym_code_end` and `_mem_deploy_end` at
compile time.
0 commit comments