Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

github.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#11

Post by aykevl »

kodablah wrote: post #9

Neat. 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. Spe…

Yeah the heavyweight standard library is a big problem. I'm trying to solve it (in part) with smart analysis that tries much harder to remove dead code and dead global data. Maybe even try to run some initializers at compile time so the result can be put in flash instead of RAM.

In my experience, it's not the unicode package that's big but the run-time typing information and the reflect package used by packages like fmt. The fmt package doesn't know what types it will need to accept so it literally supports everything (including unused types).

And as you mention WASM: I've been thinking about supporting that too, exactly because WASM and microcontrollers have some surprising similarities (small code size, fast startup, little OS-support).

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#12

Post by jsolson »

aykevl wrote: post #11
kodablah wrote: post #9

Neat. 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. Spe…

Yeah the heavyweight standard library is a big problem. I'm trying to solve it (in part) with smart analysis that tries much harder to remove dead code and dead global data. Maybe even try to run some initializers at compile time so the result can be put in flash instead of RAM. In my experience, it's not the unicode package that's big but the run-time typing information and the reflect package used by packages like…

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support.

This project seems more immediately useful :)

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#13

Post by kodablah »

jsolson wrote: post #12
aykevl wrote: post #11

Earlier quoted context omitted.

Yeah the heavyweight standard library is a big problem. I'm trying to solve it (in part) with smart analysis that tries much harder to remove dead code and dead global data. Maybe even try to run some initializers at compile time so the result can be put in flash instead of RAM. In my experience, it's not the unicode package that's big but the run-time typing information and the reflect package used by packages like…

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support. This project seems more immediately useful :)

Yeah, just wait until you see multiple megabytes of WASM instructions for tiny progs or the realize the team does not care about non-web targets. You're much better off leveraging Rust's WASM support for resource limited, non-web WASM targets.

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#14

Post by aykevl »

jsolson wrote: post #12
aykevl wrote: post #11

Earlier quoted context omitted.

Yeah the heavyweight standard library is a big problem. I'm trying to solve it (in part) with smart analysis that tries much harder to remove dead code and dead global data. Maybe even try to run some initializers at compile time so the result can be put in flash instead of RAM. In my experience, it's not the unicode package that's big but the run-time typing information and the reflect package used by packages like…

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support. This project seems more immediately useful :)

That's pretty cool!

If you want something now, I've also written and abandoned this: https://github.com/aykevl/tinygo-gccgo

It actually worked fairly well, but the code was way too bloated to be useful.

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#15

Post by jsolson »

kodablah wrote: post #13
jsolson wrote: post #12

Earlier quoted context omitted.

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support. This project seems more immediately useful :)

Yeah, just wait until you see multiple megabytes of WASM instructions for tiny progs or the realize the team does not care about non-web targets. You're much better off leveraging Rust's WASM support for resource limited, non-web WASM targets.

In my case I was less interested in the WASM part of it than I was in something targeting a "no OS" environment. That said, for my target (those little Pine64 RTL8710 Cortex M3 MCU) you're almost certainly right. On the other hand it's a hobby project, and I like writing Go while I find writing Rust to be a bit of a chore. Also, it's a hobby project, so distractions like re-targeting WASM to the ARMv7-M are half of the fun :)

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#16

Post by jsolson »

aykevl wrote: post #14
jsolson wrote: post #12

Earlier quoted context omitted.

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support. This project seems more immediately useful :)

That's pretty cool! If you want something now, I've also written and abandoned this: https://github.com/aykevl/tinygo-gccgo It actually worked fairly well, but the code was way too bloated to be useful.

Honestly for what I'm doing what you have here is a pretty reasonable start. I'm comfortable writing (and calling into) C where the Go bits aren't in place yet, and I'm a lot more familiar with LLVM's internals than with GCC's if I need to debug something. We'll see what I get up to after brunch.

One request: if you're open to PRs (I can't promise I'll send any, but I'm trying to get into a habit of contributing to OSS with my hobby hackery), can you add a LICENSE file (context: the OSS patching policy I'm bound by is very friendly for projects on Github under most licenses -- https://opensource.google.com/docs/patching/ -- it's more problematic when the license for the code is undefined)?

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#17

Post by aykevl »

jsolson wrote: post #16
aykevl wrote: post #14

Earlier quoted context omitted.

That's pretty cool! If you want something now, I've also written and abandoned this: https://github.com/aykevl/tinygo-gccgo It actually worked fairly well, but the code was way too bloated to be useful.

Honestly for what I'm doing what you have here is a pretty reasonable start. I'm comfortable writing (and calling into) C where the Go bits aren't in place yet, and I'm a lot more familiar with LLVM's internals than with GCC's if I need to debug something. We'll see what I get up to after brunch. One request: if you're open to PRs (I can't promise I'll send any, but I'm trying to get into a habit of contributing to O…

I'm certainly open to PRs :)

Good catch on the LICENSE file, I totally forgot about it. I've added it now.

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#18

Post by stmw »

SiVal wrote: post #4

Go 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.

I actually wouldn't expect Go to be considerably better in memory footprint (or other things) than "embedded" Java in embedded environments. Once you accept the idea of having GC, it puts some constraints on things. Of course, you can't compare "server java" with embedded java -- those are as different as TinyGo and "real" Go, if not more so...

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#19

Post by UncleEntity »

aykevl wrote: post #8
akavel wrote: post #7

Didn'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 th…

> We hope that the support built into the LLVM IR is sufficient to support a broad class of garbage collected languages including Scheme, ML, Java, C#, Perl, Python, Lua, Ruby, other scripting languages, and more.[0]

Maybe "and more" means there's hope for Go style garbage collection.

[0]https://llvm.org/docs/GarbageCollection.html

Re: Show HN: TinyGo – LLVM-based Go compiler for microcontrollers

#20

Post by lossolo »

stmw wrote: post #18
SiVal wrote: post #4

Go 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.

I actually wouldn't expect Go to be considerably better in memory footprint (or other things) than "embedded" Java in embedded environments. Once you accept the idea of having GC, it puts some constraints on things. Of course, you can't compare "server java" with embedded java -- those are as different as TinyGo and "real" Go, if not more so...

Normal Go is a lot more memory efficient than normal Java, it has value types and no VM/JIT overhead. In my own measurements it was up to 50x times more memory efficient.
Post reply on HN