Tinygo: Parallax Propeller 2 Support

[bradleypeabody]

I'm not sure of the effort required to tie everything together, but I wanted to see if there's any input on what it would take to get TinyGo working on Parallax Propeller 2.

It looks like some headway has been made on an LLVM backend for it here: https://github.com/ne75/p2llvm (e.g. this appears to be a bunch of backend stuff going into an LLVM fork https://github.com/ne75/llvm-project/commit/dbe9bd9db1a1ead88847418f501e3e35cb9a1fef )

The Prop 2 is still being finalized but eval boards are available, and the Prop 1 saw much success and my experiences with it have been really good (those DefCon badges are awesome ;). One of the interesting features is multiple cores, which are commonly used to implement software versions of things like PWM, I2C, UART, etc. (the "bit bang" approach)

I'm wondering what it would take to get from where https://github.com/ne75/llvm-project is at now to a basic working target for TinyGo? Probably the various software implementations I2C, SPI, PWM and UART could be ported over from the C implementations as a separate step to improve overall support.

[bradleypeabody]

/cc @ne75

[aykevl]

I'm wondering what it would take to get from where https://github.com/ne75/llvm-project is at now to a basic working target for TinyGo?

In short: upstreaming the backend to LLVM.

We've made an exception for the Xtensa architecture because the ESP chips are hugely popular (and because I personally like them), but it's a big pain especially with upgrades and there isn't even a guarantee that the Xtensa backend will remain supported because of this. I don't think it's worth the effort to support the Parallax Propeller officially in TinyGo because of this.

Maybe there are people in the Rust community that are excited about support for this architecture and can help get it supported officially in LLVM?

[ne75]

I intend to keep focusing on the backend to continue expanding the architecture capability and focus on clang for C/C++ support, but if folks want to try connecting other frontends on my fork, that would be super cool. I do my best to keep my fork up to date with the main LLVM repo so it shouldn't ever diverge too much.

[bradleypeabody]

@ne75 Would you be interesting in collaborating on putting together patch/patch-set from your branch and submitting it using the instructions at https://llvm.org/docs/Contributing.html#how-to-submit-a-patch ?

It's probably something that will need to be discussed with the LLVM maintainers on the mailing list - http://lists.llvm.org/mailman/listinfo/llvm-dev

I'm not an LLVM guru but I don't mind spending some time to help see if we can arrive a workflow that regularly flows these changes back into the main LLVM project - which is the main thing needed for Tinygo (and other frontends too) to integrate.

[ne75]

Yeah, I would be interested. I’ll take a look at that doc this week and start seeing what’s needed. Ironically, I also don’t know LLVM very well, I started learning the system a few months ago when I started my P2 effort. That being said, my main goal was to have a backend that can support many languages for the chip and make it easy for others to connect new languages, which is exactly what’s starting to happen. Exciting!

[bradleypeabody]

Great! I'll read up too and offer what assistance I can. If you want to send me something directly you can use brad at vugu dot org. I'm also on the Gophers Slack.

[aykevl]

It's always exciting to see new backend support in LLVM and especially in TinyGo (it's just a huge pain to work with LLVM forks). Just ask if you need help. I'm not too deep in LLVM backends but I have done some work on the AVR backend.

It's probably something that will need to be discussed with the LLVM maintainers on the mailing list - http://lists.llvm.org/mailman/listinfo/llvm-dev

Yes, definitely. As long as the documentation is public and there is available hardware, it shouldn't be a problem. The main requirement is that there is someone available who wants to maintain the backend and can step in when something breaks. The only possible issue I can think of is that it is relatively niche hardware.