TinyGo: New Go Compiler Based on LLVM

&gt; Garbage collection is currently only supported on ARM microcontrollers (Cortex-M). For this platform, a simple conservative mark-sweep collector has been implemented. Other platforms will just allocate memory without ever freeing it.<p>Conservative garbage collection has serious problems on 32-bit. Stuck pointers happen quite often. The usual culprit is floats, which thankfully don&#x27;t usually appear in embedded code, but by no means is the problem limited to floats.

How is this different than gollvm? And how does it combat the problems from the Go FAQ:<p>&gt; At the beginning of the project we considered using LLVM for gc but decided it was too large and slow to meet our performance goals. More important in retrospect, starting with LLVM would have made it harder to introduce some of the ABI and related changes, such as stack management, that Go requires but not are not part of the standard C setup. A new LLVM implementation is starting to come together now, however.

Congratulations on this new project. It’s compelling, your website is informative and easy to read, and the mission statement is very clear. Plus, it just looks like a lot of fun. Well done!<p>In my opinion, this feels very much in the hallowed traditions of Tiny Basic and Tiny C, but with modern tool chains.

I would be interested to see some more complex examples for this than the ones provided[1], specifically around interrupts and DMA, both are somewhat &quot;concurrent&quot; resources that in C need to be managed manually, with careful use of the volatile keyword and similar.<p>For instance, UART transmit looks to be implemented using blocking IO[2]. I don&#x27;t know Go very well, but it would be interesting if this could be implemented as a buffered channel [3], which would provide a nice abstraction for the hardware FIFO buffer used by the UART, and allow the CPU to be doing other things. The same could also be used for the I2S support I think, which will often be used to send much more data (streaming audio) than the UART.<p>On closer inspection, looking at the issue tracker, it appears this is already in planning, which is great [4].<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;tree&#x2F;master&#x2F;src&#x2F;examples" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;tree&#x2F;master&#x2F;src&#x2F;example...</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;blob&#x2F;515daa7d3c9af18c78fd97d43cafda7e4dec6290&#x2F;src&#x2F;machine&#x2F;machine_stm32f103xx.go#L156-L163" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;blob&#x2F;515daa7d3c9af18c78...</a> [3] <a href="https:&#x2F;&#x2F;gobyexample.com&#x2F;channel-buffering" rel="nofollow">https:&#x2F;&#x2F;gobyexample.com&#x2F;channel-buffering</a> [4] <a href="https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;issues&#x2F;9#issuecomment-502468619" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tinygo-org&#x2F;tinygo&#x2F;issues&#x2F;9#issuecomment-5...</a>

LLVM has a lot of optimizations. Does anyone have information about performance of applications built by each complier? I’d especially be curious about apps well tuned to reduce usage on the naive GC that TinyGo uses.

I&#x27;d love to see this targeted towards PICs. Really I&#x27;d like to just see any modern language targeting low power microcontrollers allowing for optimization of code size or performance. 8-bit processors using a banked memory model are hard for languages with modern (flat) memory models to adapt to.

golang compiler on a raspberry pi 3 compiles applications really slowly, think minutes, but there&#x27;s a workaround which is to cross compile on x86, think seconds plus sftp transfer. i assume the primary use case is to speed up compilation and create smaller binary sizes? this could be helpful as binary sizes for golang compiled binaries are pretty large, my apps typically are around 2-20MB, but i understand they include all dependencies.

I wonder if this could be adapted to bootstrap the standard Go compiler on new architectures. Big if true.