Imported Functions with a Void return type

[ebekker]

Are imported functions (FunctionImport) with a void return type supported by DNWASM?

I was trying to load a fairly simple wasm file that relied on function import, whose expected signature type matches (type $t1 (func (param i32))).

I provided my .NET-defined function using various forms but they all produced errors, her are a couple of the obvious ones:

My Func	Error
public static void foo(int c)	Parameter name: Return type System.Void is not compatible with WebAssembly.
public static int foo(int c)	Unhandled Exception: WebAssembly.CompilerException: env::putc_js did not match the required type signature.

[RyanLamansky]

I'll take a close look at this over the weekend. It's probably something simple I missed.

[RyanLamansky]

This should be fixed with 0.3.3-preview.

[ebekker]

Awesome, thanks for the quick turnaround!

[ebekker]

I've been playing around with a some simple example wasm files generated from WebAssembly Studio and running into some errors. I've been trying to dig into the actual stack trace and see if I can find something simple, but looks like it may be more involved than that.

I know that you're still working out implementation details, so perhaps it's just a piece that's not implemented yet, but do you want me to submit issues for what I'm running into?

[RyanLamansky]

You're welcome to write up a new issue for every different problem you encounter.

This project has struggled with a lack of low-complexity WASM files to test against. I'm happy you pointed out WebAssembly Studio, which I wasn't previously aware of. It seems like a great resource to resolve that limitation.

[ebekker]

Great! I I went ahead and documented the next issue I'm running into.

[ebekker]

@RyanLamansky, in addition to WASM Studio, if you're developing in VS Code, you may also find some of these other extensions useful for visualizing and manipulating generated WASM/WAT files during development and testing.

[RyanLamansky]

Thanks for the tip; I'm eager to see what you and others come up with around this library 🙂

[ebekker]

I was exploring this library because I had an idea for creating a "restricted execution" environment, hosted under .NET. The idea was to be able to run other people's code but constrain the operations that were allowed, for example, restrict spawning threads, restrict file I/O, limiting network I/O, etc.

By using WASM as a common runtime format, it would be possible for others to write their logic in whatever language they're comfortable with (C, C++, Rust, Go, C#, JS, etc.) as long as there is a compilation path to WASM, and then host it in this environment.

Some example where this could be used, would be an ETL service that allows custom processing of extracted records, custom logic for validation and execution for a form builder service, custom logic inside of a data store like RDBMS or NoSQL.

One of the challenges I found is the restriction to just basic numeric types (in current version of WASM, no fault of yours, of course) makes the burden of providing a base library very difficult.

[ebekker]

FYI, in case you didn't already see this, there's a mention of this project in this article.

[RyanLamansky]

Thanks for the article link, I wasn't aware of it!

I was thinking about your constrained execution goals and this is actually how WASM is designed. The limitation to basic numeric types is how CPUs natively work. You can compile very complex C++ applications with no change to WASM because the C++ compiler and libraries are designed to run directly on CPUs and are thus unaffected by this limitation. WASM's import/export features allow (with bridging effort, in some cases), indirect access to the full JavaScript API.

When the WASM team gets better/more efficient host integration support (GC and object transitions especially), I think it will open up a wide variety of new areas.

For my part, I really want to get 1.0 done, but need to find a free weekend to grind through these last tricky missing features.

[ebekker]

Apparently others are working on my very same idea, for example Cloudflare intends to support execution of other (non-JS) languages on their Workers (FaaS) platform with the use of WebAssembly.

So hopefully with lots of efforts working on these problems, both in the .NET ecosystem and in other areas, this area will get fleshed out and come together quickly and with great capability.

I wish I could spend a little bit more of my time in this area myself, but I feel like I'm already spread too thin. One approach that I had toyed with a little while ago was actually porting a WASM execution engine from another platform that was already further along (and had more resources devoted to it). For example, there is this WASM VM in Go called Life that is focused on performance and the code base seemed relatively small that I thought it would be reasonably possible.

The company behind it even has a similar intent in mind (to create a trusted container for executing 3rd-party code).