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

Cross-compiled C# wasm tests #35

Closed
wants to merge 5 commits into from
Closed

Cross-compiled C# wasm tests #35

wants to merge 5 commits into from

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
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