41–50 of 71 posts
Earlier quoted context omitted.
Follow-up question, why can't LLVM -> Web Assembly solve the problem?
x86 elf -> wasm could solve this problem.
Earlier quoted context omitted.
Follow-up question, why can't LLVM -> Web Assembly solve the problem?
The regular Go compiler doesn't use LLVM. It is derived from Plan9 compiler toolchain. There has been work on a LLVM Go compiler. There is also Gccgo, Go frontend for GCC, that could use GCC WebAssembly backend.
Earlier quoted context omitted.
In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.
It's also worth mentioning WASM has no GC today.
On languages where the algorithm is an implementation detail, one can make use of reference counting with a cycle collector, which are just a few hundred lines.
Implementing one is pretty simple, making it perform well is another matter.
This is huge. Looking forward to see what sort of front-end toolkits will pop up for this new platform (Go for the client-side web).
https://github.com/gopherjs/gopherjs
...and already has a reasonable js interop story, whereas my understanding is that calling the dom api from wasm is not the simplest thing.
Earlier quoted context omitted.
In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.
It's also worth mentioning WASM has no GC today.
Afaik in theory stack machines are simpler to implement, but slower than register machines. In practise, the JVM is still pretty quick. Why was WASM designed as a stack machine?
Or in other words, the “stack machine” is basically just a compact encoding of an AST.
(Note that the native “stack” is an entirely separate thing which does exist at runtime.)
[1] Actually, there can be multiple possible instructions from, e.g., inside the ‘if’ and ‘else’ sides of a prior if-block (which can push values that stay on the stack after the end of the block). But since both sides have to push the same number of values, this is still tractable; it turns into a phi node in SSA representation.
Earlier quoted context omitted.
WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).
but i'm asking what are some webasm languages/backends/use cases that aren't a JS interpreter?
One could use WASM for reconfigurable on-edge computing, all the way down to microcontrollers.
Earlier quoted context omitted.
> WASM has fairly strict stack/frame rules/types, so arbitrary gotos wouldn't work. kinda funny because golang follows the same idea.
So I am curious how the presence of them in WASM would help
Afaik in theory stack machines are simpler to implement, but slower than register machines. In practise, the JVM is still pretty quick. Why was WASM designed as a stack machine?
What you’re saying applies to interpreters, which execute the program opcode by opcode, and (in the case of stack machines) keep an actual stack at runtime. WebAssembly was designed to be the input for (at least mildly) optimizing JIT compilers. Since the stack is required to be at a fixed depth at each instruction, when the compiler reads the instruction, it can map each of the inputs it pops to a single earlier ins…