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
I understand the point of view, anyway i128 needs to be split into struct i128 {hi: i64, lo: i64}, there is no difference between the two in linear memory.
But what if we consider wasm-gc? At this time, struct i128 is a reference type, which means that use cases such as array of uuid require more fetch, which will be much slower.
So I think it makes sense to add i128 as a value type.
The text was updated successfully, but these errors were encountered:
Current compilers split i128 source-level types into two 64-bit pairs for wasm, and this could be done similarly for wasm gc I think? For example a GC struct could have two fields representing one logical field in a source language and arrays of i128 in the source language could be twice-as-long arrays of i64 in wasm. In that sense I think it comes down to the same argument of: it's probably overall best to force translation to wasm handle the split-i128-to-two-i64-values than to force all wasm runtimes to implement this.
I understand the point of view, anyway
i128
needs to be split intostruct i128 {hi: i64, lo: i64}
, there is no difference between the two in linear memory.But what if we consider wasm-gc? At this time,
struct i128
is a reference type, which means that use cases such as array of uuid require more fetch, which will be much slower.So I think it makes sense to add
i128
as a value type.The text was updated successfully, but these errors were encountered: