Skip to content

Conversation

pjuftring
Copy link
Contributor

I tried to tidy up the "show module signatures" mode since it wasn't indented at all and was lacking information about the memory size and (probably more important) information about imported functions.
Since we seem to get support for the binary format in the near future, it seemed to me, that some little summarizing functionality could come in handy.

This is what its output looks like:

File: test/testfile1.wast

Module #0
  Memory:
    Initial: 1
    Maximum: 1
  Functions:
    "inc" : () -> ()
    "get" : () -> i32
    $2 : () -> () [ENTRY]

File: test/testfile2.wast

Module #1
  Functions:
    "print32" : i32 -> ()
    "print64" : i64 -> ()
  Imports:
    spectest
      print : i32 -> ()
      print : i64 -> ()
      print : (i32 f32) -> ()
      print : (i64 f64) -> ()

@pjuftring pjuftring changed the title Add a more pretty module-summary-mode Add a prettier module-summary-mode Mar 29, 2016
@sunfishcode sunfishcode modified the milestone: Meta Jul 8, 2016
@rossberg
Copy link
Member

I just realised that I never commented on this PR. Sorry about that! I think the functionality is subsumed by now, so I'm closing. Please feel free to reopen if you think there's something missing still.

@rossberg rossberg closed this Oct 25, 2016
ngzhian added a commit to ngzhian/spec that referenced this pull request Nov 4, 2021
Packed data is not defined anywhere. We can specify SIMD as a i128
(128-bit integer). Later when specifying the SIMD instructions, we can
use some "expansions" to expand i128 into the required lane shapes.

Also, use v128 instead of s128, v128 is already commonly used in many
places in this proposal, in the BinarySIMD.md, SIMD.md, and reference
interpreter.
rossberg pushed a commit that referenced this pull request Jul 23, 2024
As discussed in #202

The JS tag was added to the JS API spec in #301, but it is not observable. This change
exposes it on the WebAssembly namespace, allowing it to be imported into wasm modules.
This allows wasm modules to explicitly extract the thrown JS objects as externrefs from the
caught exrefs, and also to throw fresh exceptions with externref payloads that will propagate 
into JS and can be caught as bare JS objects not wrapped in a WebAssembly.Exception.

It also places the restriction that WebAssembly.Exception objects cannot be created with
the JS tag, because it would result in ambiguity or asymmetry when such objects unwind
from JS into wasm and back out.
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