Skip to content

Cross-compiled C# wasm tests#35

Closed
kg wants to merge 5 commits intoWebAssembly:masterfrom
kg:master
Closed

Cross-compiled C# wasm tests#35
kg wants to merge 5 commits intoWebAssembly:masterfrom
kg:master

Conversation

@kg
Copy link
Contributor

@kg kg commented Aug 29, 2015

This isn't necessarily something we want to merge yet, but I wanted to make a PR so people can look at it and we can start a discussion.

I did some work to cross-compile simple test cases from C# to wasm. I have some basic stuff working. CountUp passes; Fannkuch starts, runs, then fails (which is progress, since it was hanging before!)

See https://gist.github.com/kg/3f66f50e2428d9d47a41 for the source to Fannkuch and https://gist.github.com/kg/4cd6e23a73ac232dcca5 for the source to CountUp.

My goal here was to start translating more-realistic functions and workflows from a source language to wasm, instead of just hand-writing wasm tests. This will be helpful in the interim until LLVM's wasm backend is working, and we might still want to have another source language for tests just to make sure we aren't overly focused on LLVM.

It would be great to get help stepping through fannkuch to figure out why it's broken. The current state of the interpreter is basically impossible to debug - if it hangs, it just hangs, and -t doesn't seem to trace the actual instructions being executed. I may take a shot at adding more instrumentation to the interpreter once I can figure out the code.

Some related code quality/syntax questions came up while porting these tests, so I'll file issues about them separately.

@titzer
Copy link
Contributor

titzer commented Aug 29, 2015

I think this is valuable work and having multiple frontends generating wasm
tests is a good sanity check. Thanks for doing this and keep it coming.

Is Fannkuch long-running? If so, let's try to separate it from "unit" tests
that try to poke on individual opcodes, features, memory behavior, control
structures, etc.

On Sat, Aug 29, 2015 at 3:24 AM, Katelyn Gadd notifications@github.com
wrote:

This isn't necessarily something we want to merge yet, but I wanted to
make a PR so people can look at it and we can start a discussion.

I did some work to cross-compile simple test cases from C# to wasm. I have
some basic stuff working. CountUp passes; Fannkuch starts, runs, then fails
(which is progress, since it was hanging before!)

See https://gist.github.com/kg/3f66f50e2428d9d47a41 for the source to
Fannkuch and https://gist.github.com/kg/4cd6e23a73ac232dcca5 for the
source to CountUp.

My goal here was to start translating more-realistic functions and
workflows from a source language to wasm, instead of just hand-writing wasm
tests. This will be helpful in the interim until LLVM's wasm backend is
working, and we might still want to have another source language for tests
just to make sure we aren't overly focused on LLVM.

It would be great to get help stepping through fannkuch to figure out why
it's broken. The current state of the interpreter is basically impossible
to debug - if it hangs, it just hangs, and -t doesn't seem to trace the
actual instructions being executed. I may take a shot at adding more
instrumentation to the interpreter once I can figure out the code.

Some related code quality/syntax questions came up while porting these

tests, so I'll file issues about them separately.

You can view, comment on, or merge this pull request online at:

#35
Commit Summary

  • Add two tests compiled from C#

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#35.

@kg
Copy link
Contributor Author

kg commented Aug 29, 2015

Is Fannkuch long-running?

With n=7 the C# version takes about 1ms (including startup overhead) and n=8 takes about 5ms.

@kg
Copy link
Contributor Author

kg commented Aug 31, 2015

Added a working Sieve of Eratosthenes test (and implemented fp sqrt, since it needs it).

@kg kg closed this Sep 4, 2015
eqrion pushed a commit to eqrion/wasm-spec that referenced this pull request Jul 18, 2019
This commit fixes WebAssembly#34 by specifying that the flags field (which
indicates if a segment is passive) is a `varuint32` instead of a
`uint8`. It was discovered in WebAssembly#34 that the memory index located at that
position today is a `varuint32`, which can be validly encoded as `0x80
0x00` in addition to `0x00` (in addition to a number of other
encodings). This means that if the first field were repurposed as a
single byte of flags, it would break these existing modules that work
today.

It's not currently known how many modules in the wild actually take
advantage of such an encoding, but it's probably better to be safe than
sorry!

Closes WebAssembly#34
eqrion pushed a commit to eqrion/wasm-spec that referenced this pull request Sep 18, 2019
… op proposal (WebAssembly#35)

Adds table.size, table.grow, table.fill to overview, spec, interpreter, and tests, as decided at recent CG meeting. Also adds a few more tests for table.get and table.set.

Also, change interpreter's segment encoding to match bulk ops proposal, addressing WebAssembly#18. (Not updated in spec yet, since corresponding spec text is still missing from bulk ops proposal.)
ErikMcClure pushed a commit to innative-sdk/spec that referenced this pull request Jun 15, 2020
[spec] fix resulttype in soundness - admin-instr - label
rossberg pushed a commit that referenced this pull request Nov 6, 2024
Really we should be merging in all change from upstream but that is still in progress.

Fixes: #35
CharlieTap pushed a commit to CharlieTap/spec that referenced this pull request Sep 25, 2025
Mention Wasmi in the list of engines supporting the proposal
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.

2 participants