Comments (9)
Yes, I think parsing the full wast scripting language including threads extensions should be in-scope for the new parser, since the end point for that project is to be able to run all the upstream spec tests. I've added that to the list of remaining issues here: WebAssembly/binaryen#6208.
from wabt.
Without addressing the rest of the questions here I would note the binaryen does have a new text parser that is nearing completion that will be able to be fully spec compliant. IIUC (@tlively will correct me) it should allow binaryen to then run the full spec tests in their upstream form.
from wabt.
[option 3] We deprecate most of the WABT tools except for wasm2c, which we'd port to run in binaryen. An upside is that binaryen attracts a lot of investment/velocity and seems to be Google's focus right now in terms of non-browser Wasm tools, and wasm2c would get to ride its coattails;
That is accurate I think. Binaryen is proving really useful as an optimizer for WasmGC content on multiple languages, with speedups and code size improvements that are pretty significant (e.g. 2x faster for Java). So I expect our investment there to continue.
Note that porting wasm2c to Binaryen could benefit from that optimizer as well, as wasm2js already does: wasm2js runs some specific optimization passes aimed to help JS execution speed (the IR is designed for that kind of thing, and maybe we'll find ideas for wasm2c).
For those reasons I think porting wasm2c to Binaryen can make sense. As a Binaryen developer I'd support that.
Regarding the downsides:
binaryen isn't really intended (as I understand it) as a spec-conforming implementation of a Wasm binary/text reader/writer + validator/interpreter, given its IR that is slightly different from Wasm. (And, smaller point, binaryen currently seems to be much slower than WABT at some operations like a wasm-merge.) So the community would lose that part of WABT's benefits.
Correct, Binaryen is an optimizer, not a general-purpose tool. It constructs a full IR for its input, in particular, which is why it can be slower compared to a tool that just scans the wasm in-place. And it doesn't round-trip wasm binaries perfectly.
Overall I'd say wasm2c could be ported to Binaryen, but the non-wasm2c tools could not. So one possible path to consider here could be (which combines two of your ideas @keithw):
- Port wasm2c to Binaryen.
- Rely on
wasm-tools
for wabt's other current tools, like text-to-binary, binary-to-text, objdump, etc., and contribute there.
I don't know enough about the status and momentum of those parts of wasm-tools
, but there does seem to be a lot of overlap between wabt and wasm-tools, so maybe there is an opportunity to collaborate more there.
from wabt.
Hey folks π I'm the author of a VideoGame engine and libraries using Kotlin and did some tools regarding wasm myself, and I'm interested in the evolution of wasm2c + GC. I'm specially interested into being able to generate C code calling native libraries like SDL/Opengl from Kotlin WASM.
Not sure if it makes sense in this context reading the situation of this, but willing to contribute and/or at least betatest if possible either if it is here or ported to Binaryen. (I already commented in the irc, but doesn't seems to be too much activity there so decided to join this conversation here too).
from wabt.
Hello - my understanding of this issue is it's not necessarily specific to GC but about features in any new Wasm proposal. If that understanding seems off let me know and I can file a different one.
From what I can tell, currently wast2json
does not support the threads spec tests
https://github.com/WebAssembly/threads/tree/upstream-rebuild/test/core/threads
wast2json
has been very important for wazero to be able to execute spec tests and I'm wondering if there is a reasonable path forward to be able to use it for threads, it looks like the updates to the parser could be very significant. @sbc100 is threads support also in scope for the binaryen parser?
from wabt.
@anuraaga The binaryen parser already supports the threads proposal (without that, it would not be able to optimize pthreads content in Emscripten, for example, so that was implemented quite some time ago already).
from wabt.
@kripken Ah sorry if it was confusing, I meant the thread invocation syntax in the linked test cases, not atomics (I wish the proposal was caller Webassembly atomics instead of threads...). I don't know if this is the correct place to look but I don't see any IR related to those thread commands, which would make sense since they don't translate to Wasm IIUC, only test harness commands
Would parsing those test-specific commands also be in scope?
from wabt.
π wanted to drop in as someone who works on wasm-tools and say that I'm happy to help out if that's the direction wabt maintainers/users feel is best.
From a maintenance perspective I can perhaps add some color on the wasm-tools side of things as well. The core libraries (Rust crates) like wasmparser
are likely to be well-maintained for quite some time as they're the foundation for Wasmtime and a number of other libraries which have variety of stakeholders. The CLI, however, is mostly maintained by me at this time and thus has a pretty small bus factor. While useful to many folks also working on Wasmtime and such I've found that the CLI and some of the surrounding commands/crates are only "secondarily useful" so they don't receive quite as much love as they could.
Not to say the BA or folks are disinterested in the CLI itself of course, mostly just instead saying that while core functionality will likely be well-looked-after some of the surrounding bits are likely ripe for more interest and/or help maintaining.
from wabt.
- We work on the current best-effort basis to update our exception-handling support and finish the implementation of function-references and gc (in the binary/text readers/writers, the interpreter, and wasm2c). I'm not sure who has a ton of spare cycles for this, but if there is continued interest in WABT, I and other contributors will probably eventually make it happen. Could take a long time though, and I'm a little nervous about losing community trust/interest if we allow WABT to fall behind the living spec for too long.
Personally, we would like to see this happen. wasm GC scares us, but other than that...
from wabt.
Related Issues (20)
- Error using wasm2wat on a wasm file generated by Moonbit: "unexpected type form (got -0x30)" HOT 1
- Out-of-Memory Program Abort in wabt::interp::Table::Grow() HOT 2
- Out-of-Memory Program Abort in BinaryReaderInterp::OnDataCount()
- Invalid Memory Read in FreeList<wabt::interp::Object*>::IsUsed()
- error initializing module: invalid import "a.a" HOT 1
- Error while running testsuite (simd_lane, simd_load) "loop not vectorized" HOT 3
- wasm2wat: support component wasm HOT 1
- Wrong type error when validating globals with gc proposal features
- wat2wasm: Assertion `!"ParseExpr should only be called when IsExpr() is true"' failed in wabt::WastParser::ParseExpr
- Wast2Json fails on the testsuite HOT 8
- Library not loaded: /usr/local/opt/openssl@3/lib/libcrypto.3.dylib HOT 8
- Missing Import when running global.wast HOT 1
- `wast2json` miscompiles "if.wast" from the specification tests HOT 4
- Build failed on Apple Silicon platform HOT 4
- [wasm2c] Strange issue with double parsing in msvc HOT 5
- wasm2c compiling minimal example issues HOT 1
- [wasm2c] catching traps without exception runtime
- βpicosha2.hβ: No such file or directory HOT 2
- Allocator is out of memory in wasm-interp HOT 3
- Invalid Read Memory in wabt::interp HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wabt.