Skip to content

Commit

Permalink
compiler-internals: remove -wasm-abi=generic flag
Browse files Browse the repository at this point in the history
Also update the text a bit.
  • Loading branch information
aykevl authored and deadprogram committed Feb 12, 2023
1 parent 3a6cc24 commit a5a8173
Showing 1 changed file with 3 additions and 3 deletions.
Expand Up @@ -18,11 +18,11 @@ TinyGo, however, uses a register based calling convention. In fact it is somewha

Note that all native Go data types that are lowered to aggregate types in LLVM are expanded this way: `string`, slices, interfaces, and fat function pointers. This avoids some overhead in the C calling convention and makes the work of the LLVM optimizers easier.

* The WebAssembly target by default doesn't export or import `i64` (`int64`, `uint64`) parameters. Instead, it replaces them with `i64*`, allocating the value on the stack. In other words, imported functions are called with a 64-bit integer on the stack and exported functions must be called with a pointer to a 64-bit integer somewhere in linear memory.
* Some environments don't support `i64` parameters and return values (like old Node.js versions). Therefore, when targeting browsers, TinyGo will use a special ABI where these parameters and return values are returned with `i64`, allocating the value on the C stack. In other words, imported functions are called with a 64-bit integer on the stack and exported functions must be called with a pointer to a 64-bit integer somewhere in linear memory.

This is a workaround for a limitation in JavaScript, which only deals with doubles and can therefore only work with integers up to 32-bit in size (a 64-bit integer cannot be represented exactly in a double, a 32-bit integer can). It is expected that 64-bit integers will be [added in the near future] (https://github.com/WebAssembly/design/issues/1172) at which point this calling convention workaround may be removed. Also see [this wasm-bindgen issue](https://github.com/rustwasm/wasm-bindgen/issues/35).
WASI doesn't have this limitation so it will always use plain `i64` values.

Currently there are also non-browser WebAssembly execution environments that do not have this limitation. Use the -wasm-abi=generic flag to remove the behavior described above and enable emitting functions with i64 parameters directly.
We will eventually remove support for this workaround, as it is only really needed for very old Node.js versions.

* The WebAssembly target does not return variables directly that cannot be handled by JavaScript (see above about `i64`, also `struct`, `i64`, multiple return values, etc). Instead, they are stored into a pointer passed as the first parameter by the caller.

Expand Down

0 comments on commit a5a8173

Please sign in to comment.