You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For interop between WASM modules needs dedicated EcmaScript v128 data type in EcmaScript. Not Number or BigInt. There is probably needs sort of register reference, or exported 128-bit packed or bitfield value. I not means about SIMD in EcmaScript, but means about data type.
The text was updated successfully, but these errors were encountered:
Could you provide more detail on what interop issues would be solved by having only the v128 data type exposed to JS? The reason v128 types are available in Wasm, is that we expect computations on v128 values to also happen only in Wasm.
When needs transfer v128 SIMD value between wasm modules, they can't share memory between of them. I mean, when getting pointer value, doesn't means memory itself. So needs specific data-type for transfering SIMD value between modules.
Even if the modules do not share a memory, JS should be able to read the vector data out of one module's memory and write it to the other module's memory. Doing a memory copy like this should be more efficient in the common case than passing v128 values one at a time from one module, out to JS, and back into another module.
For interop between WASM modules needs dedicated EcmaScript v128 data type in EcmaScript. Not Number or BigInt. There is probably needs sort of register reference, or exported 128-bit packed or bitfield value. I not means about SIMD in EcmaScript, but means about data type.
The text was updated successfully, but these errors were encountered: