| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
This change incorporates [simd-everywhere](https://github.com/simd-everywhere/simde) into the wasm2c output, which maps wasm SIMD C intrinsics to any supported target architecture.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes wasm2c serialize each function type, rather than registering
function types at module-initialization time. The serialized function
type is the SHA-256 of the mangled param and result types (with a space
between params and results).
At runtime in call_indirect, a known (immediate) function type is
compared against the function type stored in a funcref structure. For
call_indirects to functions local to the module, or for any
call_indirect when the toolchain merges string constants across
compilation units (generally, GCC and clang), this can be done by
comparing the pointers to each function type. Otherwise, the actual
32-byte values are compared.
The function type IDs can be looked up at runtime with
`Z_[modname]_get_func_type`, which matches the API from
`wasm_rt_register_func_type`. A new `callback` example demos this.
wasm2c does the SHA-256 either by linking against libcrypto or, if not
available or if requested via `cmake -DUSE_INTERNAL_SHA256=ON`, by using
a vendored (header-only) PicoSHA2. There is no runtime dependency on
SHA-256 in the wasm2c runtime or generated modules.
This eliminates the last of the per-module state, so this commit also removes
the [modname]_init_module() function and the s_module_initialized bool.
|
| |
|
|
| |
uvwasi was transferred into the Node.js GitHub org.
This commit updates the project's source repo.
|
| |
|
|
|
|
|
|
|
|
| |
This is proof of concept that only implements the `proc_exit` and
`fd_write` APIs.
Extending this to the full WASI API will to follow assuming this
approach seems reasonable.
Fixes #1409
|
| |
|
|
| |
All tests except `threads` pass.
|
| |
|
|
| |
It was an interesting experiment, but it is not maintained or tested.
|
| |
|
|
|
| |
It's not really the appropriate place to handle it. Now that we have
wasm-wast and wasm-interp, we can at least verify that the tools are
internally consistent.
|
| |
|
|
|
| |
This makes it easier to build for users who don't run
`git submodule update --init`.
|
| |
|
|
| |
These will be useful for testing the binary reader.
|
| | |
|
| |
|
|
| |
It's pretty clunky though
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Also added script to build d8 from source
|
