https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Now that WebAssembly is outside the browser, operating systems aren't as vital as before. Maybe it would be possible for lightweight OS's to oust the old order of bloatware.

The implications of this are huge. Imagine turning the browser inside out and having JavaScript running on top of WebAssembly instead of the other way around and browsers suddenly shrink to the size of IBrowse or even MultiView.

@Samurai_Crow

Sound like they are reinventing JavaVM. It won't be as fast as native programs.

One funny thing about this, if you compile a C programs into Web Assembly, its possible that POSIX implementation in WASI, might be better then native support in AmigaOS.



Anyway they sort expect the OS to have some kind of security, guess we need to make security layer between WASI and the OS

Last edited by NutsAboutAmiga on 27-Mar-2019 at 05:48 PM.
Last edited by NutsAboutAmiga on 27-Mar-2019 at 05:46 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

What do you mean by "native" code? WebAssembly is a thin layer on top of LLVM and Clang. If you mean Java, it's based on a JIT. WASI is AOT. That means WASI compiles to "native" binaries upon installation while Java tried to run the bytecode itself. In summary: just-in-time is just-too-late while ahead-of-time is just once compiled by the installer script.

@thread
My favorite application of this technology would be bridging the architectures of AROS with a thin cross compatibility layer.

@Samurai_Crow
amigaDE.... here wee go agen

@Samurai_Crow

I've followed this off and on, more off than on lately, so thanks for the link.

To be clear, you compile Rust, or say C/C++ source (via Emscripten), to Web Assembly (wasm in source form). Emscripten sits on LLVM, of course. Wasm is the resulting distributable's target format and it is like a cross-browser byte code. With WASI, the wasm bundles will no longer be limited to running hosted by a browser. Rather, in the suggested configuration, WASI provides the functionality you would expect from, say, the C runtime.

Last I had read, one Mozilla/Firefox optimization effort was focused on caching the wasm 'bundles' for (much) faster launching of network applications:

Caching compiled WebAssembly modules

Heh - the docs are outdated ... So again, WASI will provide the 'common' runtime functionality required by such compiled code, but outside the context of a web browser.

From the article, "For example, if Node’s native modules were written in WebAssembly, then users wouldn’t need to run node-gyp when they install apps with native modules, and developers wouldn’t need to configure and distribute dozens of binaries."

The compiled (to native) code will invoke 'system' calls via stubs of some form into WASI (I can't imagine the compiler will statically link much, if anything).

For the record, this isn't a magic bullet to give, say, non-posix OS's posix functionality, rather it abstracts the system calls for resolution by the platform's WASI runtime. So no, generally speaking it won't be as fast as native code, but it will be so close that, for most applications, the speed difference won't matter.

Happy to be corrected on any of the above points, if I've missed anything.

@Snorg

It occurred to me, for instance, a C runtime would itself be implemented/provided as a wasm module. Another example is QT compiled to wasm. Last time I looked, wasm calls to such 'libraries' were still a work-in-progress, but clearly much progress has been made.

To maintain modularity, such calls across module boundaries would need to be handled by WASI, generally by delegating to cached, pre-built wasm modules installed (or dynamically resolved, for that matter).

Perhaps someone has some links to clarify?

@Snorg

Thanks for your explanation!

@thread

Regarding use case of AROS, it has a POSIXC.library as a simple POSIX runtime for C already. Whether it's sufficient to run WASI remains to be seen.