Add support for the reference types proposal #938
Conversation
|
One final thing I know of that would want to be sorted out before merging is the binary representation of the opcodes. Currently the reference types overview doesn't go into detail about the binary encodings and the table instructions specification doesn't currently mention I think it should be easy to sort this out here whichever way we want it to be, I just want to make sure that this isn't merged before that's settled! I also don't mind sending a PR to the reference-types proposal with an update of encodings too! |
|
Oh I should also mentioned that this goes ahead and uses the renamings proposed of |
|
Oh hm I'm also not entirely sure where travis is going awry with the asmjs build (I think?). Is there perhaps a file I need to regenerate somewhere as well? |
It's an unrelated error, I believe. I filed a bug here: #939 |
alexcrichton
force-pushed
the
reference-types
branch
2 times, most recently
from
10790fd
to
0c41e09
Compare
|
I think there are many open questions around encoding. I have filed a bug here: WebAssembly/reference-types#18 to get some eyes on this. Basically, the bulk memory ops will require work for multi-table support and we could usefully coordinate the encodings between the two proposals. I'll file a similar bug for bulk memory. |
alexcrichton
force-pushed
the
reference-types
branch
from
0c41e09
to
169cccb
Compare
alexcrichton
force-pushed
the
reference-types
branch
from
169cccb
to
32fdda2
Compare
alexcrichton
force-pushed
the
reference-types
branch
3 times, most recently
from
73552b3
to
27bf702
Compare
|
Ok I've rebased over the changes that have happened inbetween since this started, and I was curious if perhaps since the binary encoding is still in-the-air-but-implemented-in-a-few-places it might be good to get this in as a starting point and the binary format can be tweaked as the spec evolves? |
|
Yes, I think we probably should (same as with other in-progress proposals). See further discussion about the instruction encoding here: WebAssembly/reference-types#29 |
alexcrichton
force-pushed
the
reference-types
branch
2 times, most recently
from
ef1eacc
to
472ed8a
Compare
This commit adds support for the reference types proposal to wabt.
Namely it adds new opcodes like `table.{get,set,grow}` as well as adds a
new `anyref` type. These are plumbed throughout for various operations
in relatively simple fashions, no support was added for a subtyping
relationship between `anyref` and `anyfunc` just yet.
This also raises the restriction that multiple tables are disallowed,
allowing multiple tables to exist when `--enable-reference-types` is
passed.
alexcrichton
force-pushed
the
reference-types
branch
from
472ed8a
to
5f48a91
Compare
|
Ok thanks for the review! I think I've covered all those points and increased the test coverage some more as well (embarassing bugs!) I've also gone ahead and updated all the encodings to match the latest proposal in WebAssembly/reference-types#29 which looks to be the way forward |
Plumb support throughout for the `call_indirect` instruction (and `return_call_indirect`) to work with multi-table modules according to the reference types proposal.
This commit adds support for the reference types proposal to wabt.
Namely it adds new opcodes like
table.{get,set,grow}as well as adds anew
anyreftype. These are plumbed throughout for various operationsin relatively simple fashions, no support was added for a subtyping
relationship between
anyrefandanyfuncjust yet.This also raises the restriction that multiple tables are disallowed,
allowing multiple tables to exist when
--enable-reference-typesispassed.