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

i64 to BigInt in JS #1172

Open
xtuc opened this issue Jan 15, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@xtuc
Copy link

commented Jan 15, 2018

Currently I64 can't pass the boundaries of WebAssembly, it will throw an exception from the Hostfunc. BigInt was already mentioned in some issues in the WebAssembly organization, but not exactly for what I mean here.

Today V8 announced the support for the BigInt proposal (still stage 3 at the moment), we can expect to see more and more adoption soon.

My idea is:

  • if the host support BigInt we can safely convert the i64 value into a BigInt value.
  • If not, it would throw.

This introduces an inconsistent behavior on some hosts, but avoiding that would lock down i64 in JS for a very long time.

What do you think?

@rossberg

This comment has been minimized.

Copy link
Member

commented Jan 15, 2018

It is the current plan of record to reflect i64 as BigInt once it is standard in JS. Are you suggesting to start doing so earlier? If so, what's benefit if it's not portable?

@xtuc

This comment has been minimized.

Copy link
Author

commented Jan 15, 2018

Are you suggesting to start doing so earlier?

Yes, that's my idea.

If so, what's benefit if it's not portable?

Since we don't have a wide adoption for BigInt anyway, the use case might be to restricted at the moment.

But to make it portable we would have a mechanism to allow the user to fallback to something else, otherwise he will probably implement his own mechanism. It will be then very difficult for WebAssembly to introduce a breaking change.

@littledan

This comment has been minimized.

Copy link

commented Jan 16, 2018

One possibility would be to prepare the WebAssembly/BigInt interaction so that it's possible for browsers to ship the WebAssembly BigInt integration at the same time as they ship BigInt itself. I could write a specification for this. I'm not sure if we should throw an exception or not for out-of-bounds BigInts; maybe we should be consistent with TypedArrays (which would not throw).

@xtuc

This comment has been minimized.

Copy link
Author

commented Jan 17, 2018

Thinking about this a bit more. Since you can share a chunk of memory between the module instance and JavaScript you could use it to grab the i64 value (and use BigInt).

That is more a workaround than a real solution.

littledan added a commit to littledan/spec that referenced this issue Feb 17, 2018

[spec] Normative: Add i64<->BigInt conversion in JS API
With this patch, BigInts have support for bidirectionally converting
to 64-bit integer WebAssembly values, which appears as
- Parameters and return values to exported WebAssembly functions
- Parameters and return values to host functions
- Imported and exported globals

BigInts can be read or written from WebAssembly memory using the
BigInt proposal's BigInt64Array or BigUint64Array; no additional
support is needed.

This patch includes basic conformance tests in jsapi.js, which tests
that the conversion is done properly in the six cases listed above.
I don't know of any Wasm implementation that attempts to implement
this specification, so I converted most of the test to be against
i32 and saw that converted version pass on V8 (this process helped
work out a few silly test bugs).

Closes WebAssembly/design#1172

xtuc added a commit to xtuc/JS-BigInt-integration that referenced this issue Oct 17, 2018

[spec] Normative: Add i64<->BigInt conversion in JS API
With this patch, BigInts have support for bidirectionally converting
to 64-bit integer WebAssembly values, which appears as
- Parameters and return values to exported WebAssembly functions
- Parameters and return values to host functions
- Imported and exported globals

BigInts can be read or written from WebAssembly memory using the
BigInt proposal's BigInt64Array or BigUint64Array; no additional
support is needed.

This patch includes basic conformance tests in jsapi.js, which tests
that the conversion is done properly in the six cases listed above.
I don't know of any Wasm implementation that attempts to implement
this specification, so I converted most of the test to be against
i32 and saw that converted version pass on V8 (this process helped
work out a few silly test bugs).

Closes WebAssembly/design#1172

xtuc added a commit to WebAssembly/JS-BigInt-integration that referenced this issue Oct 23, 2018

[spec] Normative: Add i64<->BigInt conversion in JS API
With this patch, BigInts have support for bidirectionally converting
to 64-bit integer WebAssembly values, which appears as
- Parameters and return values to exported WebAssembly functions
- Parameters and return values to host functions
- Imported and exported globals

BigInts can be read or written from WebAssembly memory using the
BigInt proposal's BigInt64Array or BigUint64Array; no additional
support is needed.

This patch includes basic conformance tests in jsapi.js, which tests
that the conversion is done properly in the six cases listed above.
I don't know of any Wasm implementation that attempts to implement
this specification, so I converted most of the test to be against
i32 and saw that converted version pass on V8 (this process helped
work out a few silly test bugs).

Closes WebAssembly/design#1172

Co-authored-by: Daniel Ehrenberg <littledan@chromium.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.