profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/alexcrichton/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

alexcrichton/AudioStreamer 70

A streaming audio player class (AudioStreamer) for Mac OS X and iPhone.

alexcrichton/bzip2-rs 56

libbz2 (bzip2 compression) bindings for Rust

alexcrichton/bufstream 30

A buffered I/O stream for Rust

alexcrichton/ars 1

ar in Rust

alexcrichton/atty 1

are you or are you not a tty?

alexcrichton/binaryen 1

Compiler infrastructure and toolchain library for WebAssembly, in C++

alexcrichton/bzip2-ruby 1

Original libbz2 ruby C bindings from Guy Decoux, with some new love

alexcrichton/1password-teams-open-source 0

Get a free 1Password Teams membership for your open source project

push eventalexcrichton/witx-bindgen

Alex Crichton

commit sha 62d076b6252bf762342eee39a5e41a7f3935a165

rebuild

view details

push time in 12 hours

delete branch alexcrichton/witx-bindgen

delete branch : move-smw-tests

delete time in 13 hours

push eventbytecodealliance/witx-bindgen

Alex Crichton

commit sha ed3f003947aa3eb2357b8439c161342afd136a9e

Move spidermonkey tests to `tests/runtime/*` This commit moves the spidermonkey tests into the new unit-test-like directory of `tests/runtime`. This merges the import/export JS for now but they can be split in the future if necessary. The only host which supports these at this time is the Wasmtime host which uses a new helper to compile and link in `spidermonkey.wasm` as well.

view details

Alex Crichton

commit sha 7c6230f2b6a8f2f1f037b93486ede9937342cac1

Merge pull request #75 from alexcrichton/move-smw-tests Move spidermonkey tests to `tests/runtime/*`

view details

push time in 13 hours

PR merged bytecodealliance/witx-bindgen

Move spidermonkey tests to `tests/runtime/*`

This commit moves the spidermonkey tests into the new unit-test-like directory of tests/runtime. This merges the import/export JS for now but they can be split in the future if necessary. The only host which supports these at this time is the Wasmtime host which uses a new helper to compile and link in spidermonkey.wasm as well.

+495 -683

0 comment

27 changed files

alexcrichton

pr closed time in 13 hours

push eventalexcrichton/witx-bindgen

Alex Crichton

commit sha 87899ea26ea667d52556967c8d335f0a1d82633e

Install binaryen

view details

Alex Crichton

commit sha 0d3633c3c43c853f95cf3db71c84f59855dbfbd8

shasum

view details

push time in 13 hours

PR opened bytecodealliance/witx-bindgen

Move spidermonkey tests to `tests/runtime/*`

This commit moves the spidermonkey tests into the new unit-test-like directory of tests/runtime. This merges the import/export JS for now but they can be split in the future if necessary. The only host which supports these at this time is the Wasmtime host which uses a new helper to compile and link in spidermonkey.wasm as well.

+495 -683

0 comment

27 changed files

pr created time in 13 hours

create barnchalexcrichton/witx-bindgen

branch : move-smw-tests

created branch time in 13 hours

create barnchalexcrichton/witx-bindgen

branch : build-on-ci

created branch time in 14 hours

create barnchalexcrichton/witx-bindgen

branch : try-split

created branch time in 15 hours

issue closedbytecodealliance/witx-bindgen

Simplify bindings implementation

After taking a quick look on the project, I realized there was a bit of shared logic between the binding generators that could be simplified. Eg: https://github.com/bytecodealliance/witx-bindgen/blob/main/crates/gen-wasmtime/src/lib.rs / https://github.com/bytecodealliance/witx-bindgen/blob/main/crates/gen-wasmtime-py/src/lib.rs

As more bindings get implemented this might become more challenging to maintain. I was wondering if there can be an implementation based on the visitor pattern.

Visitor pattern

GraphQL designed a very simple pattern (visitor pattern) to walk through the AST in a simple an succinct way.
Some overview: https://www.graphql-code-generator.com/docs/custom-codegen/using-visitor Reference implementation in Python: https://github.com/graphql-python/graphql-core/blob/main/src/graphql/language/visitor.py

Example of schema printer based on the Visitor pattern: https://github.com/graphql-python/graphql-core/blob/main/src/graphql/utilities/print_schema.py

Candid's approach

Candid (Dfinity's version of Interface Types), also follows a similar pattern where it's bindings are simple and concise to define: https://github.com/dfinity/candid/blob/master/rust/candid/src/bindings/typescript.rs

I was wondering if it could make sense to refactor some of the codebase to allow easy maintainability of the generators while repeating as minimum as possible in the bindings generator code.

Thoughts?

closed time in 15 hours

syrusakbary

issue commentbytecodealliance/witx-bindgen

Simplify bindings implementation

I'm going to close this since I think it's in an ok state for now, but if specific issues arise in the future I think it'd be good to open targeted issues to track improvements.

syrusakbary

comment created time in 15 hours

issue closedbytecodealliance/witx-bindgen

avoid get_export every time when guest code call into host function.

Wasmer has a WasmerEnv design to lazy init ctx when initialize instance. Is it possible to add this feature?

This approach can avoid lookup realloc every time when guest code call into host function.

For example

      let func = get_func(&mut caller, "canonical_abi_realloc")?;
      let func_canonical_abi_realloc = func.typed::<(i32, i32, i32, i32), i32, _>(&caller)?;
      let memory = &get_memory(&mut caller, "memory")?;

could be

let lazy_ctx = get_lazy_ctx(caller)?; // get_func/get_memory only be called once when linking
let func_canonical_abi_realloc = lazy_ctx.func_canonical_abi_realloc;
let memory = lazy_ctx.memory;

closed time in 15 hours

hh9527

issue commentbytecodealliance/witx-bindgen

avoid get_export every time when guest code call into host function.

I'm going to close this for now since AFAIK we don't have a concrete reason to not do this, but if it's an issue please feel free to reopen or submit a new issue!

hh9527

comment created time in 15 hours

issue closedbytecodealliance/witx-bindgen

Resources-with-methods should be more idiomatic in each language

For example in Rust resources-with-methods should be modeled as actual methods on structs. Similar for JS.

closed time in 15 hours

alexcrichton

issue commentbytecodealliance/witx-bindgen

Resources-with-methods should be more idiomatic in each language

I think this is done now.

alexcrichton

comment created time in 15 hours

delete branch alexcrichton/witx-bindgen

delete branch : validate-with-test-helpers

delete time in 15 hours

push eventbytecodealliance/witx-bindgen

Alex Crichton

commit sha 58d5f4b3e7dd4e6014a4cd88223a3f105fa1cd07

Move spidermonkey-wasm tests to `test/codegen/*` for validation This makes it the same as other code generators.

view details

Alex Crichton

commit sha aa00fa06ec7c90073e098a9a652ea8daa51ab1dc

Merge pull request #74 from alexcrichton/validate-with-test-helpers Move spidermonkey-wasm tests to `test/codegen/*` for validation

view details

push time in 15 hours

PR merged bytecodealliance/witx-bindgen

Move spidermonkey-wasm tests to `test/codegen/*` for validation

This makes it the same as other code generators.

+79 -42

0 comment

10 changed files

alexcrichton

pr closed time in 15 hours

PR opened bytecodealliance/witx-bindgen

Move spidermonkey-wasm tests to `test/codegen/*` for validation

This makes it the same as other code generators.

+79 -42

0 comment

10 changed files

pr created time in 16 hours

create barnchalexcrichton/witx-bindgen

branch : validate-with-test-helpers

created branch time in 16 hours

delete branch alexcrichton/witx-bindgen

delete branch : split-tests

delete time in 16 hours

push eventbytecodealliance/witx-bindgen

Alex Crichton

commit sha a096d9d339c4f8854af9bebfb1c75e62cdc73300

Move codegen tests to a codegen dir Make room effectively for smaller runtime tests to exist in the future, and the `codegen` tests will exculsively be used for validating the generated bindings as opposed to implementing/using them.

view details

Alex Crichton

commit sha 2457fed7b61e68a343116977999c98927f1cab77

Start to reorganize tests This commit is the start of a refactoring which will move from each code generator having one monolithic test into many separate sub-tests. This should enable smaller and more focused tests which benefits bringing new bindings generators online (can get some tests working before others) and also allows writing tests for some generators but not others. The way that this is currently architected is that there's a new `tests/runtime/*` directory in which a test-per-directory lives. For each tests `tests/runtime/foo` there will be a few conventions: * `tests/runtime/foo/imports.witx` - these are what hosts must implement and what the wasm can import from the host. This file is required to exist. * `tests/runtime/foo/exports.witx` - this is what wasms must implement and what hosts can call. This file must exist. * `tests/runtime/foo/host.*` - these are separate host implementations to execute the wasm code. The extension of the file indicates which generator it's used for (e.g. right now `host.{ts,rs,py}` are supported). If `host.py` doesn't exist for the test `foo` then testing the Python code generator will skip the test `foo`. Otherwise it's expected to work. At least one `host.*` file is required to work, but there's no need to have a file-per-host. * `tests/runtime/foo/wasm.*` - these are separate guest compiled-to-wasm implementations. Currently only `wasm.{c,rs}` are supported, but the intent is to support `wasm.js` for #71 as well. Not all languages need to have an implementation here either, they'll be skipped if omitted. The general goal is that adding a test for some witx functionality should be "drop a few files in `tests/runtime/your_new_test` and you're good to go. Over time more generators can add more tests if it becomes necessary, and generator-specific tests can also be added to this directory such as the one test exercising JS instantiation added here too. Overall I think this turned out quite well. The biggest downside is that Rust-compiled-to-wasm needs to list explicitly each test that's being compiled to wasm, which is a bit of a bummer.

view details

Alex Crichton

commit sha 952d81f07b54dae94cf072c858fe1b5090112b4c

Create a `numbers` test for moving numbers around Starts the extraction process from the monolithic tests that already exist into smaller tests.

view details

Alex Crichton

commit sha fcc8eae4b5a6ba5032d89886fcd55baf4a302909

Split records into their own test

view details

Alex Crichton

commit sha 23f059179866b02e7cf3b6538c901a9a35019981

Extract out a variants test

view details

Alex Crichton

commit sha 61b20c5e3b0482fbb6c9c4edb9938d0553712658

Extract lists into a standalone test

view details

Alex Crichton

commit sha c4a8ca4ec9bd43d4e1ab4c2d14478bf942644dd5

Move handles to their own test

view details

Alex Crichton

commit sha 9d6c7dd8d14b5c33d1e5ceefec76802584d049ad

Split buffers into their own tests

view details

Alex Crichton

commit sha 7b81c8ccb14a5a1e4c5bf38907e2bc48180f948c

Move 'flavorful' tests to their own test

view details

Alex Crichton

commit sha ff74427fec0ab6d6c8a35bef96953e6ee4585898

Move invalid tests to their own tests

view details

Alex Crichton

commit sha a4830ebae496da90b19e878a58fdb8717b6c7731

Update testing README

view details

Alex Crichton

commit sha d5331adfbf80680ec60b84470854db4a5d1103ae

Fix racy tests

view details

Alex Crichton

commit sha af0bd86e6e0db782818127f602a30fae3c5094e4

Split mypy caches to fix racy tests

view details

Alex Crichton

commit sha 1754187450f302d23d9516422d7cbea3223c7357

Don't destroy mypy cache between runs Helps to speed up tests

view details

Alex Crichton

commit sha a44879fc36a82351a51df3abc33d7e5fb3a83c16

Try not passing any options to node wasi

view details

Alex Crichton

commit sha 90635a4cc8ea88e88e1ef3b5f10abfcf59ad2437

Ignore js tests on Windows

view details

Alex Crichton

commit sha 7fbf513812f47ddbddee3cd18292e4aa72a86cc6

Fixup merge conflicts

view details

Alex Crichton

commit sha 881659bf117907a77bc1554bfa18e1052a7aa10e

Merge pull request #72 from alexcrichton/split-tests Split out monolithic tests into individual tests

view details

push time in 16 hours

PR merged bytecodealliance/witx-bindgen

Split out monolithic tests into individual tests

This commit adds an internal framework for testing witx-bindgen execution of generated code in a way that I believe is much more scalabe and easier to work with than before. After this change test are dropped into tests/runtime/* and they don't have to be implemented for all the hosts and all the guests. Instead it's now possible to implement tests for just a few runtimes and it's automatically skipped for other runtimes. This opt-in behavior makes it much easier to do things like develop new features that only work in some generators or bring a new generator online that doesn't have to get the whole world working at once to get any tests passing.

There's a huge amount of movement here and a lot of commits, but I can give more information as necessary! The commit messages and tests/README.md should hopefully give some more detailed background as well.

+6319 -5569

1 comment

138 changed files

alexcrichton

pr closed time in 16 hours

delete branch alexcrichton/witx-bindgen

delete branch : fix-typo

delete time in 16 hours

push eventbytecodealliance/witx-bindgen

Alex Crichton

commit sha c63ad299cc681c1acb77b3b0b6069a1ceaf7012f

Fix typo in profile settings Use `opt-level` instead of `opt`

view details

Alex Crichton

commit sha 38baa7b6be90a4fe16de7db4af5c0b64f4abff1b

Merge pull request #73 from alexcrichton/fix-typo Fix typo in profile settings

view details

push time in 16 hours

PR merged bytecodealliance/witx-bindgen

Fix typo in profile settings

Use opt-level instead of opt

+1 -1

0 comment

1 changed file

alexcrichton

pr closed time in 16 hours

push eventalexcrichton/witx-bindgen

Nick Fitzgerald

commit sha 6499e6ccf3a256f69df34e4f2b92022612a764f9

Introduce a WITX bindings generator for JS via SpiderMonkey This `witx-bindgen` backend targets JS running on Wasm via the SpiderMonkey JS engine. Unlike other `witx-bindgen` backends, this one does not generate source code. Instead, it generates Wasm glue code directly. The goal is to avoid requiring that users have a working C++ toolchain that targets Wasm. Users just supply their JS file and the WITX interfaces to `witx-bindgen-spidermonkey`, and don't need any other tools. The output is a single Wasm file that imports and exports the functions defined in the given WITX files and additionally * embeds or imports (configurable) a `spidermonkey.wasm` instance, and * exports a `wizer.initialize` function that initializes SpiderMonkey and evaluates the top level of the JavaScript. As an API contract, the `wizer.initialize` function must be invoked before any other function. It must only be invoked once. The initialization function performs the following tasks: * Calls `spidermonkey.wasm`'s `_initialize` function, which runs C++ global contructors. * `malloc`s space in `spidermonkey.wasm`'s linear memory and copies the JavaScript source code from its linear memory into the malloc'd space. * Evaluates the JavaScript source, compiling it to bytecode and initializing globals and defining top-level functions in the process. By the time an imported WITX function is called, we have the following layers of code on the stack, listed from older to younger frames: * User JS code (inside `spidermonkey.wasm`'s internal JS stack) This is the user's JavaScript code that is running inside of `spidermonkey.wasm` and which wants to call an external, imported function that is described with WITX. * Import glue Wasm code (on the Wasm stack) This is a synthesized Wasm function that understands both the canonical ABI and the SpiderMonkey API. It translates outgoing arguments from SpiderMonkey values into the canonical ABI representation, calls the actual imported Wasm function, and then translates the incoming results from the canonical ABI representation into SpiderMonkey values. * Imported function (on the Wasm Stack) This is the actual Wasm function whose signature is described in WITX and uses the canonical ABI. By the time an exported JS function that implements a WITX signature is called, we have the following frames on the stack, listed form older to younger frames: * External caller (on the Wasm or native stack) This is whoever is calling our JS-implemented WITX export, using the canonical ABI. This might be another Wasm module or it might be some native code in the host. * Export glue Wasm code (on the Wasm stack) This is a synthesized function that understands both the canonical ABI and the SpiderMonkey API. It translates incoming arguments from the canonical ABI representation into SpiderMonkey values, calls the JS function that implements this export with those values, and then translates the function's outgoing results from SpiderMonkey values into the canonical ABI representation. * JavaScript function implementing the WITX signature (inside `spidermonkey.wasm`'s internal stack) This is the user-written JavaScript function that is being exported. It accepts and returns the JavaScript values that correspond to the interface types used in the WITX signature. Most `witx2::abi::Instruction`s have a corresponding "intrinsic" function that is exported from `spidermonkey.wasm`, e.g. there is `witx2::abi::Instruction::I32FromU32` and `spidermonkey.wasm` exports the `SMW_i32_from_u32` function. These intrinsics are used when emitting Wasm opcodes directly is too difficult. The intrinsics are defined in `spidermonkey-wasm/bindgen.cpp`. We keep track of whether operands are JS values or Wasm locals. `witx-bindgen-spidermonkey` currently supports the following types: * `u32` * string * list It is expected that the other scalar types will be relatively easy to add support for. They should look basically the same as `u32`. It is expected that implementing structs and variants will be more difficult than the other scalars, but no more difficult than implementing lists already was. Either way, this seemed like a good point to check in and share the progress I've made more widely.

view details

Nick Fitzgerald

commit sha eff19861026ce5bfd394c8c097a4ea3af71e8847

Remove unnecessary `fn main` in tests

view details

Nick Fitzgerald

commit sha 13f6bcf0a53c47e14ff151ee9fc89874e867428d

Fix minimum memory page size calculation

view details

Nick Fitzgerald

commit sha c710b73088f11215d2466604b3e56523a7c7c0e5

Move `*.wasm` ignore to top-level `.gitignore`

view details

Nick Fitzgerald

commit sha 28980adb6a3d901c8d955b4ab130755ddb452a7e

Move the `spidermonkey-wasm` directory into `crates/gen-spidermonkey`

view details

Nick Fitzgerald

commit sha 831bd7d759ce075db8f1084d9282905f0919132b

Add a `README.md` for the `spidermonkey-wasm` subdirectory

view details

Nick Fitzgerald

commit sha 8416eee047c9b1508992b6e1a5057e7aa5831e44

Export `SMW_malloc` so that we don't need to handle `nullptr` in Wasm

view details

Nick Fitzgerald

commit sha e15f23bbd969ef8c5a1aa1200971dbac96dc67d1

Factor out `MemArg` construction to a helper function

view details

Nick Fitzgerald

commit sha cdd0b73ba2e6c93e3dd015eff56d0feafe691cb2

Use a helper function to convert `WasmType` to `wasm_encoder::ValType`

view details

Nick Fitzgerald

commit sha d18acc5ae88301022da48adc1aa5b2d8dc5f4d65

Add a TODO for typed arrays and canonical list representation

view details

Nick Fitzgerald

commit sha 12a553405b0c52be2b5951eb03353bfc266c4f3a

Expand the `Generator` trait so it can abstract the SpiderMonkey backend This commit renames * `preprocess` to `preprocess_one`, * `generate` to `generate_one`, and * `finish` to `finish_one`. It also adds three new methods: * `preprocess_all`, * `generate_all`, and * `finish_all`. The `preprocess_all` method is called at the start of bindings generation, and gives the generator a chance to inspect all imported and exported interfaces at once. This is necessary for the SpiderMonkey backend so that it can assign function indices in the generated glue code Wasm module for each imported and exported function. The `finish_all` method is called after all imported and exported interfaces have been processed. It is an opportunity to generate a final file once the generator has processed everything. This is necessary because generating a single Wasm glue module for all imported and exported interfaces can't happen until after we've processed each interface. Finally, the `generate_all` method is essentially the main, top-level bindings generation driver. It takes all imported and exported interfaces, calls `preprocess_all` on them, and then loops over each interface, calling `generate_one` on each of them with the appropriate import/export direction. Finally, it calls `finish_all`.

view details

Nick Fitzgerald

commit sha 3d070e627bf89bf25feb88666efa071dc6a4869e

Support the SpiderMonkey backend in the main CLI And remove the SpiderMonkey-specific CLI from the project. This required tweaking the common CLI arguments. Now all generators can be given multiple import and export interfaces, at least at the CLI layer.

view details

Nick Fitzgerald

commit sha 79de4b57f2276314b6bea2b183e98ed43d8ad9b9

Always build `cranelift-codegen` with optimizations and without debug assertions This makes tests that need to compile `spidermonkey.wasm` run much faster.

view details

Alex Crichton

commit sha 9a3b2674a04176ddeea70970c2a5c6f68c8919ef

Merge pull request #71 from fitzgen/introduce-witx-bindgen-spidermonkey Introduce a WITX bindings generator for JS via SpiderMonkey

view details

Alex Crichton

commit sha a096d9d339c4f8854af9bebfb1c75e62cdc73300

Move codegen tests to a codegen dir Make room effectively for smaller runtime tests to exist in the future, and the `codegen` tests will exculsively be used for validating the generated bindings as opposed to implementing/using them.

view details

Alex Crichton

commit sha 2457fed7b61e68a343116977999c98927f1cab77

Start to reorganize tests This commit is the start of a refactoring which will move from each code generator having one monolithic test into many separate sub-tests. This should enable smaller and more focused tests which benefits bringing new bindings generators online (can get some tests working before others) and also allows writing tests for some generators but not others. The way that this is currently architected is that there's a new `tests/runtime/*` directory in which a test-per-directory lives. For each tests `tests/runtime/foo` there will be a few conventions: * `tests/runtime/foo/imports.witx` - these are what hosts must implement and what the wasm can import from the host. This file is required to exist. * `tests/runtime/foo/exports.witx` - this is what wasms must implement and what hosts can call. This file must exist. * `tests/runtime/foo/host.*` - these are separate host implementations to execute the wasm code. The extension of the file indicates which generator it's used for (e.g. right now `host.{ts,rs,py}` are supported). If `host.py` doesn't exist for the test `foo` then testing the Python code generator will skip the test `foo`. Otherwise it's expected to work. At least one `host.*` file is required to work, but there's no need to have a file-per-host. * `tests/runtime/foo/wasm.*` - these are separate guest compiled-to-wasm implementations. Currently only `wasm.{c,rs}` are supported, but the intent is to support `wasm.js` for #71 as well. Not all languages need to have an implementation here either, they'll be skipped if omitted. The general goal is that adding a test for some witx functionality should be "drop a few files in `tests/runtime/your_new_test` and you're good to go. Over time more generators can add more tests if it becomes necessary, and generator-specific tests can also be added to this directory such as the one test exercising JS instantiation added here too. Overall I think this turned out quite well. The biggest downside is that Rust-compiled-to-wasm needs to list explicitly each test that's being compiled to wasm, which is a bit of a bummer.

view details

Alex Crichton

commit sha 952d81f07b54dae94cf072c858fe1b5090112b4c

Create a `numbers` test for moving numbers around Starts the extraction process from the monolithic tests that already exist into smaller tests.

view details

Alex Crichton

commit sha fcc8eae4b5a6ba5032d89886fcd55baf4a302909

Split records into their own test

view details

Alex Crichton

commit sha 23f059179866b02e7cf3b6538c901a9a35019981

Extract out a variants test

view details

Alex Crichton

commit sha 61b20c5e3b0482fbb6c9c4edb9938d0553712658

Extract lists into a standalone test

view details

push time in 16 hours

PR opened bytecodealliance/witx-bindgen

Fix typo in profile settings

Use opt-level instead of opt

+1 -1

0 comment

1 changed file

pr created time in 16 hours

create barnchalexcrichton/witx-bindgen

branch : fix-typo

created branch time in 16 hours

push eventbytecodealliance/witx-bindgen

Nick Fitzgerald

commit sha 6499e6ccf3a256f69df34e4f2b92022612a764f9

Introduce a WITX bindings generator for JS via SpiderMonkey This `witx-bindgen` backend targets JS running on Wasm via the SpiderMonkey JS engine. Unlike other `witx-bindgen` backends, this one does not generate source code. Instead, it generates Wasm glue code directly. The goal is to avoid requiring that users have a working C++ toolchain that targets Wasm. Users just supply their JS file and the WITX interfaces to `witx-bindgen-spidermonkey`, and don't need any other tools. The output is a single Wasm file that imports and exports the functions defined in the given WITX files and additionally * embeds or imports (configurable) a `spidermonkey.wasm` instance, and * exports a `wizer.initialize` function that initializes SpiderMonkey and evaluates the top level of the JavaScript. As an API contract, the `wizer.initialize` function must be invoked before any other function. It must only be invoked once. The initialization function performs the following tasks: * Calls `spidermonkey.wasm`'s `_initialize` function, which runs C++ global contructors. * `malloc`s space in `spidermonkey.wasm`'s linear memory and copies the JavaScript source code from its linear memory into the malloc'd space. * Evaluates the JavaScript source, compiling it to bytecode and initializing globals and defining top-level functions in the process. By the time an imported WITX function is called, we have the following layers of code on the stack, listed from older to younger frames: * User JS code (inside `spidermonkey.wasm`'s internal JS stack) This is the user's JavaScript code that is running inside of `spidermonkey.wasm` and which wants to call an external, imported function that is described with WITX. * Import glue Wasm code (on the Wasm stack) This is a synthesized Wasm function that understands both the canonical ABI and the SpiderMonkey API. It translates outgoing arguments from SpiderMonkey values into the canonical ABI representation, calls the actual imported Wasm function, and then translates the incoming results from the canonical ABI representation into SpiderMonkey values. * Imported function (on the Wasm Stack) This is the actual Wasm function whose signature is described in WITX and uses the canonical ABI. By the time an exported JS function that implements a WITX signature is called, we have the following frames on the stack, listed form older to younger frames: * External caller (on the Wasm or native stack) This is whoever is calling our JS-implemented WITX export, using the canonical ABI. This might be another Wasm module or it might be some native code in the host. * Export glue Wasm code (on the Wasm stack) This is a synthesized function that understands both the canonical ABI and the SpiderMonkey API. It translates incoming arguments from the canonical ABI representation into SpiderMonkey values, calls the JS function that implements this export with those values, and then translates the function's outgoing results from SpiderMonkey values into the canonical ABI representation. * JavaScript function implementing the WITX signature (inside `spidermonkey.wasm`'s internal stack) This is the user-written JavaScript function that is being exported. It accepts and returns the JavaScript values that correspond to the interface types used in the WITX signature. Most `witx2::abi::Instruction`s have a corresponding "intrinsic" function that is exported from `spidermonkey.wasm`, e.g. there is `witx2::abi::Instruction::I32FromU32` and `spidermonkey.wasm` exports the `SMW_i32_from_u32` function. These intrinsics are used when emitting Wasm opcodes directly is too difficult. The intrinsics are defined in `spidermonkey-wasm/bindgen.cpp`. We keep track of whether operands are JS values or Wasm locals. `witx-bindgen-spidermonkey` currently supports the following types: * `u32` * string * list It is expected that the other scalar types will be relatively easy to add support for. They should look basically the same as `u32`. It is expected that implementing structs and variants will be more difficult than the other scalars, but no more difficult than implementing lists already was. Either way, this seemed like a good point to check in and share the progress I've made more widely.

view details

Nick Fitzgerald

commit sha eff19861026ce5bfd394c8c097a4ea3af71e8847

Remove unnecessary `fn main` in tests

view details

Nick Fitzgerald

commit sha 13f6bcf0a53c47e14ff151ee9fc89874e867428d

Fix minimum memory page size calculation

view details

Nick Fitzgerald

commit sha c710b73088f11215d2466604b3e56523a7c7c0e5

Move `*.wasm` ignore to top-level `.gitignore`

view details

Nick Fitzgerald

commit sha 28980adb6a3d901c8d955b4ab130755ddb452a7e

Move the `spidermonkey-wasm` directory into `crates/gen-spidermonkey`

view details

Nick Fitzgerald

commit sha 831bd7d759ce075db8f1084d9282905f0919132b

Add a `README.md` for the `spidermonkey-wasm` subdirectory

view details

Nick Fitzgerald

commit sha 8416eee047c9b1508992b6e1a5057e7aa5831e44

Export `SMW_malloc` so that we don't need to handle `nullptr` in Wasm

view details

Nick Fitzgerald

commit sha e15f23bbd969ef8c5a1aa1200971dbac96dc67d1

Factor out `MemArg` construction to a helper function

view details

Nick Fitzgerald

commit sha cdd0b73ba2e6c93e3dd015eff56d0feafe691cb2

Use a helper function to convert `WasmType` to `wasm_encoder::ValType`

view details

Nick Fitzgerald

commit sha d18acc5ae88301022da48adc1aa5b2d8dc5f4d65

Add a TODO for typed arrays and canonical list representation

view details

Nick Fitzgerald

commit sha 12a553405b0c52be2b5951eb03353bfc266c4f3a

Expand the `Generator` trait so it can abstract the SpiderMonkey backend This commit renames * `preprocess` to `preprocess_one`, * `generate` to `generate_one`, and * `finish` to `finish_one`. It also adds three new methods: * `preprocess_all`, * `generate_all`, and * `finish_all`. The `preprocess_all` method is called at the start of bindings generation, and gives the generator a chance to inspect all imported and exported interfaces at once. This is necessary for the SpiderMonkey backend so that it can assign function indices in the generated glue code Wasm module for each imported and exported function. The `finish_all` method is called after all imported and exported interfaces have been processed. It is an opportunity to generate a final file once the generator has processed everything. This is necessary because generating a single Wasm glue module for all imported and exported interfaces can't happen until after we've processed each interface. Finally, the `generate_all` method is essentially the main, top-level bindings generation driver. It takes all imported and exported interfaces, calls `preprocess_all` on them, and then loops over each interface, calling `generate_one` on each of them with the appropriate import/export direction. Finally, it calls `finish_all`.

view details

Nick Fitzgerald

commit sha 3d070e627bf89bf25feb88666efa071dc6a4869e

Support the SpiderMonkey backend in the main CLI And remove the SpiderMonkey-specific CLI from the project. This required tweaking the common CLI arguments. Now all generators can be given multiple import and export interfaces, at least at the CLI layer.

view details

Nick Fitzgerald

commit sha 79de4b57f2276314b6bea2b183e98ed43d8ad9b9

Always build `cranelift-codegen` with optimizations and without debug assertions This makes tests that need to compile `spidermonkey.wasm` run much faster.

view details

Alex Crichton

commit sha 9a3b2674a04176ddeea70970c2a5c6f68c8919ef

Merge pull request #71 from fitzgen/introduce-witx-bindgen-spidermonkey Introduce a WITX bindings generator for JS via SpiderMonkey

view details

push time in 16 hours