Use of i64 in the syscall layer is problematic for JS embedders

[sbc100]

Even with BitInt in many engines, chrome at least still doesn't support the use of BitInt for i64 WebAssembly bindings.

I know WASI is forward looking so this was most likely a deliberate design choice, but I thought at least mention it here for the record and see what solutions others have come up with.

To fully implement the current unstable syscalls in a JS engine today it seems to me that one would need to create a shim WASM file that split all the i64 values into a pair of i32 and route the problematic syscalls through this layer to JS.

Has anyone else found any other way to do this?

[jedisct1]

Splitting i64 values into i32 pairs is what all JS applications calling Emscripten code do already, so doing the same when calling WASI functions is pretty natural.

And it will be difficult to change the WASI interface to avoid 64 bit values, if only to represent file offsets.

[devsnek]

v8 (chrome) has --experimental-wasm-bigint. I think it's reasonable to keep the i64 interfaces.

[xtuc]

--experimental-wasm-bigint is available only in 64-bit host in v8, 32-bit is kinda comming soon.

I would suggest doing both: exporting i64 and an i32/i32 equivalent. In the runtime you can call the i64 version and if it throws fallback to the lowered version.

This is reliable because the spec only throws on a call from JS.

[sbc100]

Splitting i64 values into i32 pairs is what all JS applications calling Emscripten code do already, so doing the same when calling WASI functions is pretty natural.

And it will be difficult to change the WASI interface to avoid 64 bit values, if only to represent file offsets.

The difference is that in emscripten all the i64 are removed from the imports and exports by binaryen, so the final wasm doesn't have any i64s at the boundary.

This means dealing with a WASI module is a lot harder than an emscripten one. With the WASI module there no way to satisfy the imports using JS functions.

[littledan]

This all sounds like a reason to prioritize implementation of the BigInt/i64 integration proposal, rather than going around the issue forever.

[xtuc]

Good point, I'm assuming that this is also blocking the WASI Nodejs PR (nodejs/node#27850).

[devsnek]

it's not blocking it from landing as it's all flagged experimental, but this would block it from being unflagged.

[sbc100]

Closing out since I don't think we want to fix this, but instead push for BigInt/i64 integration.

[xtuc]

32-bit support for BigInt/i64 integration has just landed in v8.