M3 and M4 haven't been supported yet because they weren't a priority (looks like they've been focusing on gaming support for the last year or so).

Alyssa said in her talk that they'll probably get it working in 6 months or so: https://www.youtube.com/watch?v=pDsksRBLXPk&t=2932s

I believe the video decoder (h264 etc) is actually separate from the GPU.

Right now we don't have any support for Android and iOS in particular, but we do support Linux/ARM (regular Linux). It's an interesting use case however.

> In my understanding it supports most of the TLS stack and many other standard libraries as well

We don't have a proper net package yet so usage on Android/iOS will be rather limited.

Supporting GC on WebAssembly has been a _major_ pain for TinyGo because WebAssembly doesn't allow access to the stack. It's really slow and I'm still not confident it's bug free. Having a GC integrated in WebAssembly itself should solve these issues.

Unfortunately, the current GC design for WebAssembly doesn't support interior pointers which is going to be difficult to work around (but I don't think it's impossible). Interior pointers are normally required in Go.

Not on the heap, but it can certainly have uninitialized variables on the stack. These cannot be created in normal Go code but the optimizer may decide to leave some values uninitialized when it determines that this is safe to do.

Oops, those docs need updating. The GC now works on all platforms (including RISC-V and WebAssembly!) except for AVR because the AVR backend is just too unreliable at the moment and you wouldn't want a GC in 2kB of memory anyway.

That's wonderful to hear, I just wish I had learned about it sooner. I kept looking back at TinyGo for WASM tasks, because it looked like the right combo of size footprint and runtime capabilities, then ultimately thinking "hmm but the GC issue."

I'll probably take a look later today!

GC works even in WASM? That's great! What size wasm targets does TinyGo generate compared to the regular Go compiler?

It produces much smaller binaries My blog post on it -> https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168

In the (reasonably simple) stuff we've been doing so far, TinyGo produced wasm files are 2-3% the size of mainline Go produced wasm files. eg:

https://justinclift.github.io/tinygo_canvas2/ (~19.5kB)

https://justinclift.github.io/tinygo-wasm-rotating-cube/ (WebGL, ~12kB)

That should be possible: there is also experimental AVR support. Experimental because the LLVM backend is unfortunately too buggy to be used in real programs (but is improving!).

The first step to make this happen, would be to add a PIC backend to LLVM.

Hehe, LLVM takes about an hour to compile on my laptop. The compiler itself is not tiny in any way. It really refers to the size of the binaries produced which is usually very small. For example, for WebAssembly, reductions to 3% of the original size are not uncommon.

3% seems common (in my testing), with 2% occasionally happening as well. ;)

The conservative mark-sweep implementation was the easiest to write: I don't think there is any real GC that is simpler. In the long term, the plan is to add other GCs that are precise and can be used in a real time context. However, note that such a conservative mark-sweep GC is good enough for many use cases already (look at MicroPython!) and that other GCs will likely cause additional RAM/flash bloat.

There are 3 LLVM-based Go compilers that I'm aware of: gollvm, llgo, and tinygo. Of those, only TinyGo reimplements the runtime that causes lots of (code size) overhead in the other compilers.

There is more to a toolchain than translating source code to machine code. I'm sure the others do that job just as well, but only TinyGo combines that with a reimplemented runtime that optimizes size over speed and allows it to be used directly on bare metal hardware: binaries of just a few kB are not uncommon.