wasi 64 support by adding _wasm64 API sets

[trcrsired]

See:
WebAssembly/wasi-libc#444

I think the wasi API can have its _i64 version to implement ptr for 64 bit instead of making the API the same. This will make things much easier to support for VM that needs to run for both 32 and 64.

We do it transparently in the wasi-libc so vm does not need to change anything.

[sbc100]

Maybe _wasm64 would be more descriptive?

Also maybe the wasm64 should go be part of the common prefix rather than suffixed?

[yamt]

This will make things much easier to support for VM that needs to run for both 32 and 64.

can you give me an example where it's much easier?
i suppose the functions affected by wasm64 usually take i64 instead of i32 and thus have different function types already. it isn't obvious to me why using different names can help implementations.

[trcrsired]

This will make things much easier to support for VM that needs to run for both 32 and 64.

can you give me an example where it's much easier? i suppose the functions affected by wasm64 usually take i64 instead of i32 and thus have different function types already. it isn't obvious to me why using different names can help implementations.

I am currently assisting in the integration of a 64-bit API into an existing project VM named WAVM. This VM automatically generates function signatures based on their definitions. Previously, I had to handle interfacing with LLVM, which was cumbersome. However, by simply adding "_i64" postfix APIs, I no longer need to deal with that complexity.
https://github.com/trcrsired/WAVM/blob/c63f13d60ca33d6436360a223d6aefb0fdd02731/Lib/WASI/WASIFile.cpp#L238

Also, most of the entire tooling systems are built based on assuming address and size being i32. By adding new API names to 64 bit only would not break any existing tools but reusing them. (Well, you just add new APIs) It just makes it much easier to implement.

By the way, if you want to run wasm32 and wasm64 apps in a VM like this, new APIs could do them both easily.

Maybe _wasm64 would be more descriptive?

Also maybe the wasm64 should go be part of the common prefix rather than suffixed?

Maybe.

[trcrsired]

Changed to wasm64

trcrsired/wasi-libc@c889960

[yamt]

This will make things much easier to support for VM that needs to run for both 32 and 64.

can you give me an example where it's much easier? i suppose the functions affected by wasm64 usually take i64 instead of i32 and thus have different function types already. it isn't obvious to me why using different names can help implementations.

I am currently assisting in the integration of a 64-bit API into an existing project VM named WAVM. This VM automatically generates function signatures based on their definitions. Previously, I had to handle interfacing with LLVM, which was cumbersome. However, by simply adding "_i64" postfix APIs, I no longer need to deal with that complexity. https://github.com/trcrsired/WAVM/blob/c63f13d60ca33d6436360a223d6aefb0fdd02731/Lib/WASI/WASIFile.cpp#L238

generate signatures from which definitions?
can you explain a bit for those of us who is not familiar with wavm?
do you mean it has some troubles to handle two functions with the same name but with different signatures?

Also, most of the entire tooling systems are built based on assuming address and size being i32. By adding new API names to 64 bit only would not break any existing tools but reusing them. (Well, you just add new APIs) It just makes it much easier to implement.

well, this issue is about core wasm import names, right?

my question is, what's wrong with having the following two functions with the same name?

• 32-bit version of fd_write: (param i32 i32 i32 i32) (result i32)
• 64-bit version of fd_write: (param i32 i64 i32 i64) (result i32)

[trcrsired]

This will make things much easier to support for VM that needs to run for both 32 and 64.

can you give me an example where it's much easier? i suppose the functions affected by wasm64 usually take i64 instead of i32 and thus have different function types already. it isn't obvious to me why using different names can help implementations.

I am currently assisting in the integration of a 64-bit API into an existing project VM named WAVM. This VM automatically generates function signatures based on their definitions. Previously, I had to handle interfacing with LLVM, which was cumbersome. However, by simply adding "_i64" postfix APIs, I no longer need to deal with that complexity. https://github.com/trcrsired/WAVM/blob/c63f13d60ca33d6436360a223d6aefb0fdd02731/Lib/WASI/WASIFile.cpp#L238

generate signatures from which definitions? can you explain a bit for those of us who is not familiar with wavm? do you mean it has some troubles to handle two functions with the same name but with different signatures?

Also, most of the entire tooling systems are built based on assuming address and size being i32. By adding new API names to 64 bit only would not break any existing tools but reusing them. (Well, you just add new APIs) It just makes it much easier to implement.

well, this issue is about core wasm import names, right?

my question is, what's wrong with having the following two functions with the same name?

• 32-bit version of fd_write: (param i32 i32 i32 i32) (result i32)
• 64-bit version of fd_write: (param i32 i64 i32 i64) (result i32)

yeah. Two functions with the same name are much harder to implement than just duplicating APIs. For example, try to support 32 bit and 64 bit wasm at the same time is much harder to implement. Plus existing tools are all assume address are 32 bits, they all have to be fixed which is too much work. If we duplicate the APIs for 64 bit version, these tools will still work without changing, but by adding new APIs.

[yamt]

This will make things much easier to support for VM that needs to run for both 32 and 64.

can you give me an example where it's much easier? i suppose the functions affected by wasm64 usually take i64 instead of i32 and thus have different function types already. it isn't obvious to me why using different names can help implementations.

I am currently assisting in the integration of a 64-bit API into an existing project VM named WAVM. This VM automatically generates function signatures based on their definitions. Previously, I had to handle interfacing with LLVM, which was cumbersome. However, by simply adding "_i64" postfix APIs, I no longer need to deal with that complexity. https://github.com/trcrsired/WAVM/blob/c63f13d60ca33d6436360a223d6aefb0fdd02731/Lib/WASI/WASIFile.cpp#L238

generate signatures from which definitions? can you explain a bit for those of us who is not familiar with wavm? do you mean it has some troubles to handle two functions with the same name but with different signatures?

Also, most of the entire tooling systems are built based on assuming address and size being i32. By adding new API names to 64 bit only would not break any existing tools but reusing them. (Well, you just add new APIs) It just makes it much easier to implement.

well, this issue is about core wasm import names, right?
my question is, what's wrong with having the following two functions with the same name?

• 32-bit version of fd_write: (param i32 i32 i32 i32) (result i32)
• 64-bit version of fd_write: (param i32 i64 i32 i64) (result i32)

yeah. Two functions with the same name are much harder to implement than just duplicating APIs. For example, try to support 32 bit and 64 bit wasm at the same time is much harder to implement.

for some reasons specific to wavm, you mean?
it isn't difficult for runtimes i'm familiar with. (wamr, toywasm)

Plus existing tools are all assume address are 32 bits, they all have to be fixed which is too much work. If we duplicate the APIs for 64 bit version, these tools will still work without changing, but by adding new APIs.

what kind of tools are you talking about, for example?

[yamt]

also, i guess function name alone is not enough to introduce 64-bit variant of wasi.
eg. what should happen if the memory is 64 bit and you use 32-bit functions, or vice versa.
eg. do you introduce 64-bit variant only for functions which take pointers? or all functions? why?

[sbc100]

This seems like an issue that should be continued in the WASI repo. Closing this here since I don't think it relates to the core memory64 spec.