parseTools helpers like toIndexType and to64

[cwoffenden]

Helpers such as toIndexType aren't documented (in the code at least) so it's a bit of a guess from my part when adding wasm64 support for the preferred way of adding the required BigInt (and Number) wrappers.

I'll happily create docs, but what's the intention?

• toIndexType to denote an index into one of the heaps?
• to64 for the same but...?

And along the same lines, what's the preference for BigInt conversions? As late as possible at the point of calling native code? We end up doing this:

emscripten/src/audio_worklet.js

Line 122 in 5fe41a5

if (didProduceAudio = this.callback(numInputs, {{{ toIndexType('inputsPtr') }}}, numOutputs, {{{ toIndexType('outputsPtr') }}}, numParams, {{{ toIndexType('paramsPtr') }}}, this.userData)) {

Some pointers here are already BigInt but some aren't.

[sbc100]

In terms of pointers, the idea is that all pointers on the JS side are numbers. When pointers flow into JS there should always be bigint -> number conversion and then pointers flow out of JS there should be a number -> bigint conversion.

There are some places that we currently cannot do that and the user ends up being exposed to bigints when running on wasm64 (IIRC EM_JS is one example).

toIndexType is for interacting with the WebAssembly JS API, its will convert a value to bigint if that index type being uses is 64-bit (i.e. in wasm64 mode). Otherwise the index type is number and no conversion is done.

to64 is very similar, but there is a subtle difference: it will convert also when MEMORY64=2 (i.e. when we don't actually use 64-bit wasm memory, only the 64-bit ABI. In this mode pointers are 64-bit but the index type mentioned above is 32-bit (because the memory and table uses are 32-bit).

[cwoffenden]

Thanks, that explains what I was missing.