Skip to content
This repository was archived by the owner on Nov 3, 2021. It is now read-only.

Advance bulk-memory-operations to phase 4 #132

Closed
eqrion opened this issue Nov 27, 2019 · 4 comments
Closed

Advance bulk-memory-operations to phase 4 #132

eqrion opened this issue Nov 27, 2019 · 4 comments

Comments

@eqrion
Copy link
Contributor

eqrion commented Nov 27, 2019

After the change and follow-ups for #124 it looks like all substantive issues with the design have been resolved. There are still some issues open regarding new instructions such as #13 and #121, however I think it would be prudent to leave those for another proposal if someone wishes to pursue them.

I'd like to propose then that we move this repo to phase 4.

Entry requirements:

  • Two or more Web VMs implement the feature.
    • Firefox
      • As of bug 1598149, we are passing the latest spec tests from this repo.
    • Chrome
      • I believe they are tracking this spec, but may still need to update for the latest bounds checking behavior.
    • Safari/Webkit?
  • At least one toolchain implements the feature.
    • LLVM (as of LLVM 9)
    • Wabt
  • The formalization and the reference interpreter are usually updated (though these two can be done as part of step 3 at the Working Group chair's discretion).
    • The interpreter is up to date for all changes/issues I know of.
  • Community Group has reached consensus in support of the feature.
    • I believe a poll would be required for this.
@gahaas
Copy link
Contributor

gahaas commented Nov 28, 2019

Chrome/V8 indeed still needs to implement the latest bounds checking behavior. We should be done soon.

@MaxGraey
Copy link

MaxGraey commented Nov 29, 2019

binaryen also support bulk memory operations. Should it update bounds check validation?

@rossberg
Copy link
Member

I think I filled in all the remaining gaps and tracked all the recent changes over the last few months -- at least as far as they were possible in isolation within this repo. Unfortunately, some pieces of spec (execution of table instructions, specifically) can only be completed properly in the presence of reference types. So I rebased that proposal repo on this one and filled in those parts over there.

Technically, I'm afraid this means that we will need to merge both proposals together, since their semantics is mutually dependent. (Alternatively, we could duplicate various pieces of the reftypes spec here, but attempts to go that way got messy quickly, and would create a merging nightmare later.)

@rossberg
Copy link
Member

rossberg commented Nov 3, 2020

This has been done a while ago.

@rossberg rossberg closed this as completed Nov 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants