Preparing for integration into wabt

[binji]

See WebAssembly/wabt#1543.

There are still some missing features from wasp that we'll want before we can use it to fully replace the equivalent wabt functionality:

• binary to text conversion
• memory64 support
• missing linking section features
  • memory64 relocations
  • check for any other differences (linking section in wasp was implemented a year ago or so, make sure nothing else needs updating)
• generating names in text format
• folded text output
• documentation
  • top-level directory structure
  • document file headers
  • document all structs/classes

[dbezhetskov]

@tlively Hi Thomas, do you have any plans to use this library? I'm asking because want to continue this work but don't know if I should or not. Maybe google have some plans to use this or something like that. Thanks in advance

[tlively]

@dbezhetskov I still think it would be great to share a parser between WABT and Binaryen. wasp could be that parser, but we are not actively working on it and we don't have plans to. @sbc100, if @dbezhetskov continued working on this, would we still want to update WABT to use wasp as its parser?

[sbc100]

;TLDR: I'm not sure

Its not clear what the major wins would be, but I'm open to being convinced. Having just one parser would clearly be great, but have to split feature work in wabt between two different repos would also add some overhead. Its also not clear to me how much work it would be to integrate wasp into wabt and who would do that work? (and perhaps there are other things in do in wabt that would be more valuable to invest it).

[dbezhetskov]

Just curious:

there are other things in do in wabt that would be more valuable to invest it
What are they?

[sbc100]

Just curious:

there are other things in do in wabt that would be more valuable to invest it
What are they?

Nothing specific, just ongoing support (e.g. adding support for new proposals and changes to existing ones).

[dbezhetskov]

I've run current spec tests with wasp and I revealed that next tests has failed:

• elem.wast
• unreached-valid.wast

There are also a few failing tests for exception handling proposal, but in general wasp is looking very good and
I think we should merge wabt and wasp because:

1. wasp support more features, for example full support of typed function references.
2. wasp has capacity to extend with future proposal because of more robust code and more flexible wasm type representation
3. and wasp code is just less

and I am willing to go ahead and do it, does it sound ok to experiment, @tlively @aardappel @sbc100?

[aardappel]

@dbezhetskov it looks like we don't know yet where we want to go w.r.t. Wasp integration. You could experiment with it, though it might be better to wait a little if we want to be sure this is the right direction.