I think it would be neat if WebAssembly were embedded in other languages, like it is in JavaScript now. For example, suppose Python had a WebAssembly engine. I bet that could replace a lot of C extensions, and it would be as portable/universal as pure Python code, so no need for C compilers, OS-specific binary packages, etc.
While this would supplant "C for speed" libraries, it wouldn't supplant "C for OS access" libraries. At some point, system code needs to call the OS.
I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…
> There are only four types in wasm: int32, int64, float32, and float64.
You can't directly address and manipulate a single byte in WASM?
> WebAssembly isn't just a cross platform technology, it's also a way to target platforms that are currently walled gardens. Being able to run software on e.g., the iPad without paying Apple's 30% fee and being able to ship features / bug fixes without added delays is a big deal. Apple still control what API you can use in their mobile browser, and it's not like they are at the forefront when it comes to implementing…
Sure, that's certainly a factor. But there's a large class of applications that can get by with the API that is available. I'm not suggesting it's a way to build mobile applications without paying Apple. I'm suggesting it will be possible to deliver a product to (nearly) all platforms using 1) a single codebase and 2) bypassing walled gardens. Personally I won't build products for an App Store anymore. They're too re…
If you can assure the same security quality, then by all means.
While this would supplant "C for speed" libraries, it wouldn't supplant "C for OS access" libraries. At some point, system code needs to call the OS.
Not all OS were or are written in C.
Sure, replace "C" with whatever OS language is appropriate. The situation is still the same: wasm doesn't talk directly to the host interfaces, regardless of it being low-level. You'd still need another FFI layer somewhere to talk to those.
I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…
> There are only four types in wasm: int32, int64, float32, and float64. You can't directly address and manipulate a single byte in WASM?
You can address bytes (using instructions like i32.load8_u), but doing arithmetic with them can be awkward.
This is technically web, but not in the way you might think. We (Cloudflare) are working on providing WASM support in our Workers [1] product that lets you run code in our 155 data centers around the world. WASM is great because we can run it in V8 isolates which are much lighter weight than containers or full VMs. [1] https://cloudflareworkers.com
What are the security implications here? i.e. the Chrome team, post-Spectre, are assuming that any value in a process' memory is readable by any code executing within that process.
V8's developer guide[1] recommends running un-trusted code in separate processes. So each worker job would need to fork.
One thing I am concerned about is startup performance. On my (slow) Chromebook, some of my multi-megabyte WASM files take 10 seconds to compile. Seems we need either faster CPU cores, faster code generation, or some kind of staged JIT compile -- though I guess the latter could be accomplished today with sufficiently clever tooling.
Chrome Canary contains Liftoff, which is about 8x faster on my machine for initial compilation of wasm. I'm assuming it'll be in Chrome 69.
Indeed. X64 and ia32 support vor Liftoff will be in 69.
I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory. For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer…
> For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer to its start address? Or an int64 pointer? Maybe you encode it as two int64s? Once you've made a choice, good luck calling functions generated by a compiler that made a different one! Sounds like every architecture ever? There’s an architecture specification and then there…
LLVM IR is interesting in that it's the opposite: it supports from i1 to i(2^23-1)
If you have to compile a high level language L to wasm you could follow many paths, for example L to C, C to wasm, or L to Lisp, Lisp to wasm. I should suggest to create a graph in which vertices are languages and edges are labeled with the efficiency of translation. This way one could use graph theory to select the best path. This is only the ground idea. At a second step one could study what features of languages are main ingredients of that efficiency and design a middleware high level language M for the translation to wasm: L -> M -> wasm. Or weight the translation using a vector of features (concurrency, speed, bugs reports, etc) and select the path that gives the best result.
L -> M1 -> M2 -> ... wasm,where Mi are selected by the specific features used for a concrete program in L.
All computations of efficiency should discount or take into account the use of specific libraries. For instance, numpy with python makes the speed difference between c and python smaller.
I would like WebAssembly runtimes for embedded devices, both Linux and bare-metal for microcontrollers.
The WS program would be called with current inputs (as data), and produce a datastructure describing output to set.
This logic can then easily and safely be tested before deploy and updated over the air.