Conversation
|
Could you squash it into one patch to make it easier to view. |
|
@JSStats, the github diff view already squashes it, doesn't it? |
|
@rossberg-chromium Yes, thanks. Can checkout the 'decode' branch too. |
| expr e; op 0x03; list expr es1; | ||
| if es2 <> [] then op 0x04; list expr es2; op 0x17 | ||
| | Select (e1, e2, e3) -> expr e1; expr e2; expr e3; op 0x05 | ||
| | Br (x, eo) -> opt expr eo; op 0x06; arity1 eo; var x |
There was a problem hiding this comment.
The expression is not optional in the binary encoding, one expression is expected which may be a nop. The arity is a constant 1 and not necessary but include as a concession.
There was a problem hiding this comment.
See WebAssembly/design#595, which this already implements.
ml-proto/host/encode.ml
Outdated
|
|
||
| (* End section *) | ||
| let end_section () = | ||
| section "end" ignore () true |
There was a problem hiding this comment.
Currently there is no end section in BinaryEncoding.md. If we want an explicit terminator, perhaps instead we can propose a section_count : varuint32 that goes right after the version u32; but a dummy section seems like an abuse of what a section is.
There was a problem hiding this comment.
Ah right, forgot to remove that. Done.
|
I haven't read it all line-by-line, but fwiw, I think it's fine to merge this now and iterate towards precisely matching BinaryEncoding.md at either 0xb or 0xc. It's nice to have an alternate implementation that first builds the AST and only afterwards performs type validation. Ultimately, we'll shake out the discrepancies when we have ml-proto encode .wasms that SM/V8 consume and vice versa with sexpr-wasm-proto. |
|
Okay, thanks. I'm taking that as an LGTM and go merge it. |
2 participants
Add working (post-order) encoder & decoder. Supersedes PR #261.
Extends the test runner with encoding & decoding of all test files via a wast->wasm transcoding and loading the resulting modules. Works for all current tests.
There are still a number of smaller TODOs left, but I think it makes more sense to address them in follow-ups. Other follow-up work: wasm->wast reverse transcoding, more aggressive tests and testing capabilities.
We'll probably also need to revise the use of different integer types throughout the spec, which is not always consistent with what the binary format supports.