|
|
Subscribe / Log in / New account

Portable low-level *compiled* code

Portable low-level *compiled* code

Posted Nov 15, 2019 12:55 UTC (Fri) by CChittleborough (subscriber, #60775)
In reply to: Use case? by yodermk
Parent article: Announcing the Bytecode Alliance

It is important to note that WebAssembly is a moving target. Right now, it is good for arithmetic (integer and floating-point). Work is already under way to properly support structures, references, arrays etc. Separately, the project is developing WASI, which plays similar role to libc in POSIX systems. WASI is intended for tight sandboxing, so it uses capabilities (drawing inspiration from CloudABI and Capsicum) rather than POSIX permissions.

So WASM will one day let you write code in C, C++, Rust etc against WASI and produce .wasm files that (1) can run in any contemporary browser, (2) have great security (enough that you can safely run untrusted .wasm modules) and (3) are relatively easy to translate into optimized machine code. Yes, it is a form of write-once-run-anywhere (‘compile-once-run-anywhere’?) like the JVM, only with less overhead and better performance.

The folks working on WebAssembly realized early on that it would also be very useful outside the browser. For example, once WASM runtimes are widely available, software can be published in compiled form as one set of .wasm files that can be run on most any computer. Smaller project teams such as indy game developers might find this really attractive.

to post comments

Portable low-level *compiled* code

Posted Nov 15, 2019 22:52 UTC (Fri) by atai (subscriber, #10977) [Link] (9 responses)

Here come projects to implement WebAssembly in hardware...

Portable low-level *compiled* code

Posted Nov 15, 2019 23:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Won't really happen. WebAssembly doesn't have goto statements, for example.

Portable low-level *compiled* code

Posted Nov 16, 2019 16:09 UTC (Sat) by eru (subscriber, #2753) [Link] (2 responses)

But C and C++ do have goto statements. How does an implementation targeting WebAssembly deal with those?

Portable low-level *compiled* code

Posted Nov 16, 2019 16:38 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

There is some discussion at https://medium.com/leaningtech/solving-the-structured-con... . It looks like the naive approach is that any arbitrary control flow graph (including uses of goto) can be translated into a giant looped switch statement, where each case is a basic block and you use a label variable to select which case to run next. That should work for any C code, but performance won't be great. Emscriptem's Relooper algorithm tries to recognise control flow patterns that can be represented more efficiently as regular loops etc, then falls back to the naive approach in more complex cases. The Stackifier algorithm does something cleverer, and there's probably room to invent even better algorithms.

Portable low-level *compiled* code

Posted Nov 16, 2019 18:40 UTC (Sat) by eru (subscriber, #2753) [Link]

Interesting, thanks!

Portable low-level *compiled* code

Posted Nov 18, 2019 15:16 UTC (Mon) by ballombe (subscriber, #9523) [Link] (3 responses)

Does it have break; and continue; ?

Portable low-level *compiled* code

Posted Nov 18, 2019 16:35 UTC (Mon) by excors (subscriber, #95769) [Link] (2 responses)

According to https://webassembly.github.io/spec/core/syntax/instructio... a program consists of well-nested block..end/loop..end/if..end instructions. The br instruction can refer to any block/loop/if that it's nested under; for block/if it behaves like C's break (jumping to the end of the block), for loop it behaves like C's continue (jumping back to the start). If you want to compile a C loop that contains both break and continue, I guess you'd need a "(block (loop (...)))" to allow br in both directions. It looks like switch statements get implemented as a nested stack of blocks (roughly one per case), and then a br_table instruction that dynamically chooses which level of block to break out of, so that it's still nesting-based control flow.

Portable low-level *compiled* code

Posted Nov 18, 2019 22:50 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

And yet arbitrary setjmp/longjmp work (yes I tested).

Portable low-level *compiled* code

Posted Nov 19, 2019 5:49 UTC (Tue) by eru (subscriber, #2753) [Link]

There does not appear to be any dedicated exception handling, so implementing that (or throw...catch) must be quite kludgy.

Portable low-level *compiled* code

Posted Nov 16, 2019 18:30 UTC (Sat) by thoughtpolice (subscriber, #87455) [Link]

WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing a register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' the table to work around. (Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that.)

But then you're just implementing a compiler. At that point, you might as well call a spade a spade, and just generate code for a target that actually can be implemented efficiently in hardware. Though WASM is small and has fully specified semantics, so you can potentially do that in a trusted codebase at a transparent level (firmware) that would make the distinction a little less important anyway. And if you make that transparent, you have a level of hardware independence where you can play with performance improvements you couldn't safely try in a more general purpose CPU. Long live AS/400, I suppose!


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds