Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i128 as value type #29

Open
1 task done
oovm opened this issue Dec 27, 2024 · 1 comment
Open
1 task done

i128 as value type #29

oovm opened this issue Dec 27, 2024 · 1 comment

Comments

@oovm
Copy link

oovm commented Dec 27, 2024

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.

@alexcrichton
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants