Michael Bebenita

If you're coming from web dev, I would think of it as a "foreign function interface" from javascript. You're calling a function defined in some other language. Here's a function, in WAT format (Web Assembly Text), that returns the number 42:

(module
(func (result i32)
(i32.const 42)
)
(export "testfunction" (func 0))
)

Go to https://mbebenita.github.io/WasmExplorer/ and paste that in the middle box, then click assemble, then download, and you'll have a local file called "test.wasm".

Then, since you already do web dev, get that test.wasm file and a new page accessible from a local web server. The new page should have this in it:

<script>
// should log 42 to the console
WebAssembly.instantiateStreaming(fetch('https://path/to/test.wasm')).then(prog =>
{
console.log(prog.instance.exports.testfunction());
});
</script>

Everything else is facades, layers, and tools on top of that. But that should help clear up what's at the bottom from a web-dev/js perspective. And also what the "2 halves" are. One half being, in your case, that the Rust compiles down eventually to WASM that you host somewhere. The other half being that you need to be able to call into that generated code from your JS.

If you're distributing an executable (not a library), you can just AOT compile the generated wasm to machine code.

For example, the WasmExplorer already lets you compile C++ -> wasm -> x86 assembly: https://mbebenita.github.io/WasmExplorer/?state=%7B%22options%22%3A%7B%22showGutter%22%3Atrue%2C%22showConsole%22%3Atrue%2C%22showOptions%22%3Atrue%2C%22autoCompile%22%3Atrue%2C%22showLLVM%22%3Afalse%2C%22darkMode%22%3Atrue%2C%22fastMath%22%3Afalse%2C%22noInline%22%3Afalse%2C%22noRTTI%22%3Afalse%2C%22noExceptions%22%3Afalse%2C%22cleanWast%22%3Afalse%2C%22wasmBaseline%22%3Afalse%2C%22dialect%22%3A%22C%2B%2B11%22%2C%22optimizationLevel%22%3A%22s%22%7D%2C%22source%22%3A%22int%20testFunction(int*%20input%2C%20int%20length)%20%7B%5Cn%20%20int%20sum%20%3D%200%3B%5Cn%20%20for%20(int%20i%20%3D%200%3B%20i%20%3C%20length%3B%20%2B%2Bi)%20%7B%5Cn%20%20%20%20sum%20%2B%3D%20input%5Bi%5D%3B%5Cn%20%20%7D%5Cn%20%20return%20sum%3B%5Cn%7D%22%7D

From playing around with https://mbebenita.github.io/WasmExplorer/ : it seems like any function you ever take the address of gets stored in the table, and wasm just passes the index in that table around. And if you do things like cast an integer to a function pointer, you actually just cast it to an index in the table.

C is high-level enough that IIRC it doesn't guarantee that arbitrary addresses can successfully be used as function pointers; the only valid function pointers are results of addresses of functions, or (possibly) values that have been cast from and then to them. Which is enough for wasm.

Try compiling this (to wat, which is an S-expression format that otherwise resembles the assembly in this article): https://wasdk.github.io/WasmFiddle/?5zbjb

This is really cool! But the compression quality of MPEG1 is really nowhere close to h264.

If you're interested in this sorta thing, try taking a look at Broadway JS: https://github.com/mbebenita/Broadway

Here's a simple demo page they have setup: http://mbebenita.github.io/Broadway/foxDemo.html

Its entirely possible to use WebSockets to stream H264 to a browser and decode using broadway, and the performance is pretty good, even on mobile.

I wish you all the best with your ambitious project ^w^

You should seriously consider employing techniques such as LLJS[1] to avoid thrashing the GC.

At the very least use typed arrays à la glMatrix[2] rather than a Vector prototype.

Typed arrays have the added benefit of interoperability with WebGL and Canvas2D via Function::apply.

---

[1] http://mbebenita.github.io/LLJS

[2] http://glmatrix.net