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

Add constant offsets to spec #89

Merged
merged 3 commits into from
Oct 15, 2015
Merged

Add constant offsets to spec #89

merged 3 commits into from
Oct 15, 2015

Conversation

lukewagner
Copy link
Member

This PR adds the immediate offset described in AstSemantics.md#addressing. I'd rather not block on the broader question of opcode naming in design/#374, so this PR just does what seems like the obvious extension to the current scheme of putting load/store immediates in the opcode name (prefixed with + for the offset).

@kg
Copy link
Contributor

kg commented Sep 30, 2015

Not okay with this. The parsing rules and opcode names are already too complicated; this is worse and in a non-general way. I'll move over to 374 for discussion, I guess.

| Load of memop * expr (* read memory address
| Store of memop * expr * expr (* write memory address
| LoadExtend of extendop * expr (* read memory address with sign- or zero-extension
| StoreTrunc of truncop * expr * expr (* write memory address with truncation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and elsewhere in this patch, the design repo calls this "wrap" instead of "trunc", for consistency with the conversion opcodes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, filed #91 to address.

@lukewagner
Copy link
Member Author

@kg The point is that the naming can, has been, and will continue to evolve separately from semantics and so there's no reason to derail with name bikeshedding. However, if we can reach a quick consensus in design/#374 then I'm happy to update this PR. I really don't care that much naming at this point.

@lukewagner
Copy link
Member Author

(Getting back to this now; will update with new patch to implement new immediate syntax.)

@lukewagner lukewagner reopened this Oct 14, 2015
@lukewagner
Copy link
Member Author

Ok, updated and ready for review.

@@ -79,9 +80,13 @@ let grow mem n =
Array1.blit (Array1.sub !mem 0 host_old_size) (Array1.sub after 0 host_old_size);
mem := after

let rec loadn mem n a =
let effective_address a o =
if (Int64.sub Int64.max_int a) < o then raise Bounds;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is doing a signed comparison. The design text describes the effective address as an unsigned computation, so it seems like this should be checking for unsigned overflow instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!

@sunfishcode
Copy link
Member

lgtm, with one comment above.

@rossberg
Copy link
Member

lgtm

lukewagner added a commit that referenced this pull request Oct 15, 2015
@lukewagner lukewagner merged commit eccab2a into master Oct 15, 2015
@lukewagner lukewagner deleted the add-load-offset branch October 15, 2015 15:08
alexcrichton pushed a commit to alexcrichton/spec that referenced this pull request Nov 18, 2019
* Add integer widen/narrow conversions
* Fix names, add explanation on signed/unsigned narrowing
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>
dhil pushed a commit to dhil/webassembly-spec that referenced this pull request Mar 2, 2023
This adds overview on traps not being caught by the `catch` instruction
and its relationship with the JS API.
Closes WebAssembly#1 and closes WebAssembly#89.
dhil pushed a commit to dhil/webassembly-spec that referenced this pull request Mar 2, 2023
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.

4 participants