diff --git a/document/core/exec/modules.rst b/document/core/exec/modules.rst index a6ed62be79..eb2faa05f6 100644 --- a/document/core/exec/modules.rst +++ b/document/core/exec/modules.rst @@ -713,8 +713,8 @@ It is up to the :ref:`embedder ` to define how such conditions are rep &\wedge& \module.\MELEMS = \elem^n \\ &\wedge& \module.\MDATAS = \data^m \\ &\wedge& \module.\MSTART = \start^? \\ - &\wedge& (\expr_{\F{g}} = \global.GINIT)^\ast \\ - &\wedge& (\expr_{\F{e}}^\ast = \elem.EINIT)^n \\[1ex] + &\wedge& (\expr_{\F{g}} = \global.\GINIT)^\ast \\ + &\wedge& (\expr_{\F{e}}^\ast = \elem.\EINIT)^n \\[1ex] &\wedge& S', \moduleinst = \allocmodule(S, \module, \externval^k, \val^\ast, (\reff^\ast)^n) \\ &\wedge& F = \{ \AMODULE~\moduleinst, \ALOCALS~\epsilon \} \\[1ex] &\wedge& (S'; F; \expr_{\F{g}} \stepto^\ast S'; F; \val~\END)^\ast \\ @@ -733,15 +733,15 @@ where: \instr^\ast~(\I32.\CONST~0)~(\I32.\CONST~n)~(\TABLEINIT~i)~(\ELEMDROP~i) \\ \F{runelem}_i(\{\ETYPE~\X{et}, \EINIT~\reff^n, \EMODE~\EDECLARATIVE\}) \quad=\\ \qquad (\ELEMDROP~i) \\[1ex] - \F{rundata}_i(\{\DINIT~b^n, DMODE~\DPASSIVE\}) \quad=\quad \epsilon \\ - \F{rundata}_i(\{\DINIT~b^n, DMODE~\DACTIVE \{\DMEM~0, \DOFFSET~\instr^\ast~\END\}\}) \quad=\\ \qquad + \F{rundata}_i(\{\DINIT~b^n, \DMODE~\DPASSIVE\}) \quad=\quad \epsilon \\ + \F{rundata}_i(\{\DINIT~b^n, \DMODE~\DACTIVE \{\DMEM~0, \DOFFSET~\instr^\ast~\END\}\}) \quad=\\ \qquad \instr^\ast~(\I32.\CONST~0)~(\I32.\CONST~n)~(\MEMORYINIT~i)~(\DATADROP~i) \\ \end{array} .. note:: Module :ref:`allocation ` and the :ref:`evaluation ` of :ref:`global ` initializers and :ref:`element segments ` are mutually recursive because the global initialization :ref:`values ` :math:`\val^\ast` and element segment contents :math:`(\reff^\ast)^\ast` are passed to the module allocator while depending on the module instance :math:`\moduleinst` and store :math:`S'` returned by allocation. However, this recursion is just a specification device. - In practice, the initialization values can :ref:`be determined ` beforehand by staging module allocation such that first, the module's own :math:`function instances ` are pre-allocated in the store, then the initializer expressions are evaluated, then the rest of the module instance is allocated, and finally the new function instances' :math:`\AMODULE` fields are set to that module instance. + In practice, the initialization values can :ref:`be determined ` beforehand by staging module allocation such that first, the module's own :ref:`function instances ` are pre-allocated in the store, then the initializer expressions are evaluated, then the rest of the module instance is allocated, and finally the new function instances' :math:`\AMODULE` fields are set to that module instance. This is possible because :ref:`validation ` ensures that initialization expressions cannot actually call a function, only take their reference. All failure conditions are checked before any observable mutation of the store takes place.