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

Merge sign-extension-ops proposal into spec #1144

Merged
merged 1 commit into from
Apr 9, 2020
Merged

Conversation

binji
Copy link
Member

@binji binji commented Mar 18, 2020

See the sign-extension-ops proposal here:

https://github.com/WebAssembly/sign-extension-ops

This PR is built on top of #1143 (merge nontrapping-float-to-int).

binji added a commit that referenced this pull request Mar 19, 2020
See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* #1143 (merge nontrapping-float-to-int)
* #1144 (merge sign-extension-ops)
@binji binji changed the base branch from master to merge-nontrapping-float-to-int-conversions March 20, 2020 19:17
@binji binji changed the base branch from merge-nontrapping-float-to-int-conversions to master April 9, 2020 17:59
See the sign-extension-ops proposal here:

https://github.com/WebAssembly/sign-extension-ops

This PR is built on top of #1143 (merge nontrapping-float-to-int).
@binji binji merged commit e308ca2 into master Apr 9, 2020
binji added a commit that referenced this pull request Apr 9, 2020
See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* #1143 (merge nontrapping-float-to-int)
* #1144 (merge sign-extension-ops)
binji added a commit that referenced this pull request Apr 9, 2020
See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* #1143 (merge nontrapping-float-to-int)
* #1144 (merge sign-extension-ops)
@binji binji deleted the merge-sign-extension-ops branch April 9, 2020 18:09
alexcrichton added a commit to alexcrichton/wabt that referenced this pull request May 5, 2020
This enables three proposals by default since they've been merged into
the upstream specification:

* `saturating-float-to-int` - WebAssembly/spec#1143
* `sign-extension` - WebAssembly/spec#1144
* `multi-value` - WebAssembly/spec#1145

Most of the fallout from this is in the test suite with lots of
`--enable` flags getting removed and some tests which now
unconditionally pass also getting removed. Two spec tests explicitly
pass `--disable` until the spec test submodule is updated.
binji pushed a commit to WebAssembly/wabt that referenced this pull request May 6, 2020
This enables three proposals by default since they've been merged into
the upstream specification:

* `saturating-float-to-int` - WebAssembly/spec#1143
* `sign-extension` - WebAssembly/spec#1144
* `multi-value` - WebAssembly/spec#1145

Most of the fallout from this is in the test suite with lots of
`--enable` flags getting removed and some tests which now
unconditionally pass also getting removed. Two spec tests explicitly
pass `--disable` until the spec test submodule is updated.
@ngzhian
Copy link
Member

ngzhian commented May 15, 2020

Looking at the bottom of the instructions https://webassembly.github.io/spec/core/binary/instructions.html?highlight=prefix#numeric-instructions
I see that these sign-extension-ops come after the saturating truncation ops. I think it reads more natural if sign-extension-ops came before saturating truncation ops, that makes the ordering of opcode looks nicer, since 0xBF (𝖿𝟨𝟦.𝗋𝖾𝗂𝗇𝗍𝖾𝗋𝗉𝗋𝖾𝗍_𝗂𝟨𝟦) flows into 0xC0 (𝗂𝟥𝟤.𝖾𝗑𝗍𝖾𝗇𝖽𝟪_𝗌). @binji wdyt?

@binji
Copy link
Member Author

binji commented May 16, 2020

@ngzhian agreed, would you mind opening a PR fixing this?

ngzhian added a commit to ngzhian/spec that referenced this pull request May 18, 2020
ngzhian added a commit that referenced this pull request May 18, 2020
rossberg added a commit that referenced this pull request Feb 11, 2021
* Upgrade to latest Sphinx release (2.4.4) (#1171)

Fixes #1157

* Support 4GB of memory both in initial and max.

* [interpreter] Strictify and specify .bin.wast format (#1173)

* Merge nontrapping-float-to-int proposal into spec (#1143)

See the non-trapping-float-to-int-conversions proposal here:

https://github.com/WebAssembly/nontrapping-float-to-int-conversions

* Merge sign-extension-ops proposal into spec (#1144)

See the sign-extension-ops proposal here:

https://github.com/WebAssembly/sign-extension-ops

This PR is built on top of #1143 (merge nontrapping-float-to-int).

* Merge multi-value proposal into spec (#1145)

See the multi-value proposal here:

https://github.com/WebAssembly/multi-value

This PR is built on top of the following PRs:

* #1143 (merge nontrapping-float-to-int)
* #1144 (merge sign-extension-ops)

* [interpreter] Remove junk in README

* [interpreter] Remove junk in README

* [spec] Fix grammar for fractions (#1178)

* [spec] Add missing i64.extend32_s syntax (#1179)

* [js-api][web-api] Fix some markup errors.

* Add a README to the proposals directory.

* Add more address overflow tests (#1188)

There are already tests for effective address overflow, but those have a
large value baked into the offset. These tests all use `1` as the
immediate offset, and use `-1` for the address on the stack, which may
be compiled differently.

* Add a test for non-treelike behavior of stack (#961)

We've recently found a bug in a WebAssembly library we've been working
with where we're mapping WebAssembly to a tree-like IR internally. The
way we parse into this representation, however, has a bug when the
function isn't itself tree-like but rather exibits properties that
exploit a stack machine. For example this isn't so straightforward to
represent in a tree-like fashion:

    (import "" "a" (func $foo))
    (import "" "b" (func $foo (result i32)))
    (func (result i32)
      call $b
      call $b
      call $a
      i32.xor)

The extra `call $a` in the middle is valid `WebAssembly` but needs
special treatment when converting to a more tree-like IR format. I
figured it'd be good to ensure there's a spec test covering this case as
we currently pass the suite of spec tests but still contain this bug!

* [js-api] Various editorial improvements.

* [js-api] Replace pseudo-ASCII characters by normal ones.

This also required disambiguating the references to "module", as there are now
two definitions by that name.

* [js-api] Improve prose in 'run a host function'.

* [js-api] Improve some of the multi-value prose.

* Synchronize js-api tests.

* Add script to synchronize js-api tests.

Co-authored-by: Ng Zhi An <ngzhian@gmail.com>
Co-authored-by: Alon Zakai <azakai@google.com>
Co-authored-by: Ben Smith <binji@chromium.org>
Co-authored-by: Ms2ger <Ms2ger@igalia.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
kateinoigakukun added a commit to kateinoigakukun/wasminspect that referenced this pull request Nov 3, 2021
@Ms2ger Ms2ger mentioned this pull request Nov 5, 2021
RyanGlScott added a commit to GaloisInc/crucible that referenced this pull request Mar 25, 2023
This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.
RyanGlScott added a commit to GaloisInc/crucible that referenced this pull request Mar 26, 2023
This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.
RyanGlScott added a commit to GaloisInc/crucible that referenced this pull request Mar 27, 2023
This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.
RyanGlScott added a commit to GaloisInc/crucible that referenced this pull request Mar 27, 2023
This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.
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

Successfully merging this pull request may close these issues.

3 participants