Spec syntax, text, binary, and execution for bulk array ops #387
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
document/core/exec/instructions.rst
Outdated
| .. math:: | ||
| ~\\[-1ex] | ||
| \begin{array}{l} | ||
| S; (\REFARRAYADDR~a)~(\I32.\CONST~d)~(\REFARRAYADDR~b)~(\I32.\CONST~s)~(\I32.\CONST~n)~(\ARRAYCOPY~x~y) |
There was a problem hiding this comment.
Nit: b is the metavariable for bytes, so it would be better to use a1, a2 here.
document/core/exec/instructions.rst
Outdated
| (\otherwise, \iff & F.\AMODULE.\MITYPES[x] = \TARRAY~\X{ft} \\ | ||
| \land & t = \unpacktype(\X{ft}) \\ | ||
| \land & b^\ast = S.\SDATAS[F.\AMODULE.\MIDATAS[y]].\DIDATA[s \slice |\X{ft}|] \\ | ||
| \land & \bytes_{\X{ft}}(i) = \unpackval_{\X{ft}}(b^\ast)) |
There was a problem hiding this comment.
Hm, something is wrong here, unpackval expects a value, not a byte sequence. Also, it expects an sx if ft is actually a packed type.
But I believe you can simply drop the unpackval, since we do not need any sign extension.
There was a problem hiding this comment.
The semantics involve (t.const i) and produce t by unpacking the field type ft. Is (ft.const i) well-defined if we skip unpacking and use the field type directly? My guess is no, in which case we need to keep the unpacking.
This usage of unpackval was copied from the semantics of array.new_data, so whatever fix we apply here, we should apply there as well.
There was a problem hiding this comment.
Ah, you're right, that's already messed up. See #391 for a fix. I think you can do the same here.
There was a problem hiding this comment.
This is now fixed. PTAL!
No description provided.