Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial bulk array op implementations #363

Merged
merged 23 commits into from
May 16, 2023
Merged

initial bulk array op implementations #363

merged 23 commits into from
May 16, 2023

Conversation

conrad-watt
Copy link
Contributor

See #313, and more specifically this comment.

This patch only updates the interpreter, the overview is not updated.

Note - this patch currently using the following opcode encodings in the hope of provoking more permanent suggestions:

| ArrayCopy (x, y)     -> op 0xfb; op 0x18; var x; var y
| ArrayFill x          -> op 0xfb; op 0x0f; var x
| ArrayInitData (x, y) -> op 0xfb; op 0x52; var x; var y
| ArrayInitElem (x, y) -> op 0xfb; op 0x53; var x; var y

@conrad-watt conrad-watt mentioned this pull request Mar 27, 2023
@tlively
Copy link
Member

tlively commented Mar 27, 2023

The opcodes here seem fine to me. We can figure out permanent opcodes alongside everything else just before we go to phase 4.

@jakobkummerow
Copy link
Contributor

For the record, 0xfb52 and 0xfb53 are still used by the old ref.is_i31 and ref.is_data (which have already disappeared from this repository, but are still supported by the prototype implementations for incremental backwards compatibility, and we have received a specific request to continue supporting them for a little while longer).
So for implementing array.init_from_{data,elem}, we'll use a different binary encoding, e.g. 0xfb54 and 0xfb55 are free. As always, we'll keep https://bit.ly/3cWcm6Q updated. Feel free to switch the encoding that this PR uses, or feel free to keep what you have for now; it'll all get resolved in the big final reshuffling anyway.

@conrad-watt
Copy link
Contributor Author

I'm happy to switch this PR to match the reservations listed in that doc (IIUC, 0xfb54 and 0xfb55).

@tlively
Copy link
Member

tlively commented Apr 4, 2023

What needs to happen to get this landed? Do we need an update to MVP.md to accompany the work here, or can that come later?

@conrad-watt conrad-watt requested a review from rossberg May 2, 2023 16:06
@conrad-watt
Copy link
Contributor Author

@rossberg PTAL!

interpreter/valid/valid.ml Outdated Show resolved Hide resolved
test/core/gc/array_bulk.wast Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Show resolved Hide resolved
let seg = data c.frame.inst y in
let bs = Data.bytes seg in
let j = I32.to_int_u y_off in
(* TODO: unify with ArrayNewData *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you extend the Data module with a load_num function analogous to Memory.load_num and use that here and for ArrayNewData?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

opening Type/Value in Data seems to cause a build circularity. For now I'm factoring this out into a shared helper in eval.ml.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, that is very odd. What's the circularity? I cannot reproduce it on main.

interpreter/exec/eval.ml Outdated Show resolved Hide resolved
@jakobkummerow jakobkummerow mentioned this pull request May 9, 2023
@conrad-watt
Copy link
Contributor Author

@rossberg PTAL

interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/valid/valid.ml Outdated Show resolved Hide resolved
interpreter/exec/eval.ml Outdated Show resolved Hide resolved
match v with
| Num n -> Plain (Const (n @@ at))
| Vec v -> Plain (VecConst (v @@ at))
| Ref r -> Refer r

let value_of_data_ind (seg : Data.data) (st : storage_type) (j : int) at =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we somehow make this mirror the load_num/load_vec functions in Memory.ml?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you have in mind here. Now that I've at least pulled this out as an auxiliary definition, would you be willing to take on refactoring it as a small follow-up PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay.

let seg = data c.frame.inst y in
let bs = Data.bytes seg in
let j = I32.to_int_u y_off in
(* TODO: unify with ArrayNewData *)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, that is very odd. What's the circularity? I cannot reproduce it on main.

test/core/gc/array_bulk.wast Outdated Show resolved Hide resolved
@conrad-watt
Copy link
Contributor Author

@rossberg PTAL, everything should be resolved except the issue with value_of_data_ind (see comment).

interpreter/exec/eval.ml Outdated Show resolved Hide resolved
interpreter/valid/valid.ml Show resolved Hide resolved
match v with
| Num n -> Plain (Const (n @@ at))
| Vec v -> Plain (VecConst (v @@ at))
| Ref r -> Refer r

let value_of_data_ind (seg : Data.data) (st : storage_type) (j : int) at =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay.

@conrad-watt
Copy link
Contributor Author

merging now 🥳

@conrad-watt conrad-watt merged commit afa3e66 into main May 16, 2023
@conrad-watt conrad-watt deleted the array_bulk_1 branch May 16, 2023 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants