11–20 of 71 posts
I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?
Follow-up question, why can't LLVM -> Web Assembly solve the problem?
I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?
As others have said, Web assembly is an architecture/target for C, C++, rust, etc. that you compile for, and it will be the same for go. The link does talk about GC support. It looks like wasm will have one, but go’s will most likely perform better since it is tailored to go. (edit for clarification) I assume a lot of the planning for this was in the GitHub and mailing list discussions dedicated to go’s wasm support.…
Earlier quoted context omitted.
As others have said, Web assembly is an architecture/target for C, C++, rust, etc. that you compile for, and it will be the same for go. The link does talk about GC support. It looks like wasm will have one, but go’s will most likely perform better since it is tailored to go. (edit for clarification) I assume a lot of the planning for this was in the GitHub and mailing list discussions dedicated to go’s wasm support.…
I was under the impression that WASM does not have one.
If you tried to look at the document and found that the entire internet has been screwing with the formatting, change "Suggesting" to "Viewing" in the top right. Seems like someone forgot to check permissions on the document.
Earlier quoted context omitted.
As others have said, Web assembly is an architecture/target for C, C++, rust, etc. that you compile for, and it will be the same for go. The link does talk about GC support. It looks like wasm will have one, but go’s will most likely perform better since it is tailored to go. (edit for clarification) I assume a lot of the planning for this was in the GitHub and mailing list discussions dedicated to go’s wasm support.…
I was under the impression that WASM does not have one.
You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size.
Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the former will land before the latter.
If you tried to look at the document and found that the entire internet has been screwing with the formatting, change "Suggesting" to "Viewing" in the top right. Seems like someone forgot to check permissions on the document.
Honestly, the defacement is at least as interesting as the original document.
If you tried to look at the document and found that the entire internet has been screwing with the formatting, change "Suggesting" to "Viewing" in the top right. Seems like someone forgot to check permissions on the document.
[1] https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0...
I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?
Say you have the code C=A+B in your program.
The generated assembly for a real machine looks something like this: (R* denote registers and A-C are memory addresses) load A->R1 load B->R2 add R1+R2->R3 store R3->C
WASM looks more like this: push A push B add pop C
This alone makes the approach to code generation and optimization quite different.
WASM does lack some features that you would find in real CPUs, most notably the ability for execution to jump to arbitrary memory locations. They had to work around this to maintain the behavior of goroutines. Functions also live in their own address spaces which necessitates a change to how the program counter works.
I don't think it's hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can't (yet) do.
> Most file system operations are mapped to Node.js’ “fs” module. In the browser, file system operations are currently not available.
Please please abstract this. As a maintainer of a non-JS WASM backend, I'd love to use Go too.
> Especially a “goto” operation in WebAssembly would be very helpful.
I didn't look into the Go use case enough, but curious how much better this would be than the current labeled block and labeled break approach in WASM. WASM has fairly strict stack/frame rules/types, so arbitrary gotos wouldn't work.