Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
1–10 of 24 posts
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#2Nice project!
With enough love it might follow Oberon's footsteps.
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#3Next step is to directly generate IR with (link: https://github.com/llir/llvm) github.com/llir/llvm.
And then rewrite all of llvm in Go :)
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#4Go tends to be at least as fast as Java with a much smaller memory footprint. It ought to run well on any device that can run Java, which includes a lot of small devices.
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#5Go tends to be at least as fast as Java with a much smaller memory footprint. It ought to run well on any device that can run Java, which includes a lot of small devices.
If I remember right though, the smallest devices running Java (comparable to the AVR devices in specs) were mostly designed at the hardware level to run Java, so there were lots of considerations made that wont be true for an AVR microcontroller that has a first-class C toolchain.
Additionally, the Java Card specification was a pretty cut down version of Java that didn't have the same "Not _yet_ supported" feature list here.
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#6Next step is to directly generate IR with (link: https://github.com/llir/llvm ) github.com/llir/llvm. And then rewrite all of llvm in Go :)
go get llvm.org/llvm/bindings/go/llvm
I'm actually using it for some things
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#7Didn't find it in the readme: does anyone know what general "level" of microcontrollers are the project author(s) hoping to target? I suppose that because of the Go spec already, the minimum required architecture must be at least 32bit?
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#8Didn't find it in the readme: does anyone know what general "level" of microcontrollers are the project author(s) hoping to target? I suppose that because of the Go spec already, the minimum required architecture must be at least 32bit?
Hi, I'm the author of the compiler.
All backends supported by LLVM should be fairly easily supported by TinyGo. In fact, I've had the blinky example running on an Arduino a while back (8-bit, 2kB RAM, 32kB flash). There is nothing in the Go spec that requires a 32-bit system, just like there is nothing in the C standard that requires a 16-bit system (ints are at least 16 bits).
The biggest obstacle is not the fact that it is 8-bit, but the fact that it is a Harvard-style processor with a separate address space for code and data. I've added a section to the README to explain this. Also, garbage collection is going to be painful.
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#9Neat. I've always considered Go, with its (relatively) simple design and significant quantity of decent libraries to be very retargetable (I'm toying with targeting the JVM now).
I could see this as a little less likely though for limited resource use cases since much of the code is not written with that in mind. I'd be curious how the LLVM IR looks compiled to WASM compared to Go's built in (as of 1.11) support. Specifically the initialization of the unicode package with all its exposed structs and init struct creation has been a startup and binary size burden on any size-restricted context Go runs in. Causes lots of bloat on the WASM side.
I created an issue on some of the WASM bloat [0], but it's not really going to be addressed now.
Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers
#10Next step is to directly generate IR with (link: https://github.com/llir/llvm ) github.com/llir/llvm. And then rewrite all of llvm in Go :)
go get llvm.org/llvm/bindings/go/llvm I'm actually using it for some things
I'm using this exactly. It's not the nicest interface but it supports almost everything that LLVM does.
https://github.com/llir/llvm looks nice but I don't think you can interface with LLVM from there, which is needed if you want to do more advanced stuff.