Support more families of microcontrollers

[japaric]

The "Arduino" sub-ecosystem is probably the biggest as it contains several devices from different
architectures. Right now, Rust pretty much only supports, albeit not officially, microcontrollers
based on the ARM Cortex-M processor. This family is big but there are a lot of other widely used
architectures, to name a few:

• AVR
• PIC
• MSP430
• Xtensa (see ESP8266)

To ease adoption, eventually, most of these architectures should be officially supported by the
compiler. By "oficially", I mean that not only the Rust compiler should be able to generate programs
for the target but there should also be some minimal testing of the target in the rust-lang/rust
repo.

Here's the current state of Rust support for all the architectures listed above (as of 2016-09-28):

(Note that, because rustc is LLVM based, adding support for any of these architectures depends on
LLVM also supporting the architecture.)

• ARM Cortex-M. Fully supported but not built into rustc. Can be used as a "custom" target by
  creating a JSON file that describes (specifies) the target.
• AVR. The avr-llvm fork supports this architecture. This fork is in the process of being
  merged back into upstream LLVM.
• PIC. Some (all?) 32-bit PIC micros are based on the MIPS32 M4K architecture so it may be
  possible to leverage existing LLVM support for the MIPS architecture to create targets for these.
  I think LLVM doesn't support the architecture of 8-bit and 16-bit variants though.
• MSP430. There is a MSP430 backend in official LLVM. Success building a Rust program for MSP430
  was reported back in 2014 but I haven't seen anyone pushing for or requesting MSP430 support
  recently.
• Xtensa. No LLVM support AFAIK.

[alexchandel]

I've successfully compiled Rust programs to IR, then compiled that to MIPS32 assembly and assembled it with LLVM, and linked it with the PIC toolchain's linker (although I imagine LLD would do it too). I've done something similar with MSP430 too.

So it's possible, someone just has to create bare-bones target files for rustc for those architectures.

[thejpster]

How different were the LLVM versions in Rust and in the MIPS32 version you used to compile the IR? I recall AVR support for example was in one fork and Rust used a different fork, so someone had the fun job of trying to merge it all together.

[pftbest]

I don't get the message. MIPS32r2 is officially supported "Tier 2" target, of course it will work :)

[whitequark]

Xtensa. No LLVM support AFAIK.

The Espressif people are actively working on Xtensa support, from what I know.

[rafaeldelucena]

Any updates?

Why not write a frontend for GCC? Outdated but @redbrain already started at: https://github.com/redbrain/gccrs

[whitequark]

Honestly I can't imagine many Rust people putting up with the kind of code you have to write to get a GCC frontend... An Xtensa backend isn't that scary either, it's only a few months of work.

[rafaeldelucena]

Regardless of imagination, what the reason to not doing it?

The reason to do is enabling Rust on all available architectures which GCC is present (Taking advantage of all the expertise that exists, all the tests and validations that have been done in real world in real hardware, and not try to do something new and have to deal with this kinda stuff again).

To me is a big bonus, that may be worth it.

[philberty]

I reckon it would be worth the effort i want to restart the project some day. For me Rust is interesting because its native. I think GCC would handle rust very well. Alot of hidden great code in GCC.

[whitequark]

Regardless of imagination, what the reason to not doing it?

To rephrase my earlier comment: the reason is that now you have to work with gcc. If my choice would have been working on gcc or not writing a compiler, I would not have written a compiler. There is a reason no new language (that I'm aware of) uses gcc as its middle/backend. gcc often has many more architecture-specific microoptimizations than LLVM for more obscure architectures, but they are, aptly said, well hidden.

[rafaeldelucena]

There is a reason no new language (that I'm aware of) uses gcc as its middle/backend.

This is okay, mainly because new languages as a first step, they intend to initially run on more common architectures.

But when you want to have an infrastructure for embedded systems, I think you have to think about a greater plurality of vendors and chips, and at this point GCC is way ahead of LLVM.

[whitequark]

I think you have to think about a greater plurality of vendors and chips, and at this point GCC is way ahead of LLVM.

Or we could write more backends for LLVM, and benefit every LLVM-based language, of which there are far more. The argument goes both ways, and IME (I maintain an LLVM backend) this way is easier.

[rafaeldelucena]

IME (I maintain an LLVM backend) this way is easier.

As you mentioned, clearly this is the easiest way, since you are already an LLVM developer.

In my view, everything that involves hardware and the physical world takes a lot more time to validate and test, It's not just code. This time has already been spent by the GCC developers, their users (embedded software developers) and of course, the product consumers.

Or we could write more backends for LLVM, and benefit every LLVM-based language

One thing does not make the other unfeasible, which I questioned from the beginning was the reason for not wanting to do this.

Anyway thanks for your answers

[jamesmunns]

I believe that the topics of this issue are now covered by other efforts, such as issue #3 and #20. Marking this for a cleanup sweep. If we would like this to stay open, please provide an update to what this issue should be focused on.

[caemor]

@whitequark do you know of any news for an open source llvm backend for xtensa besides the paid one for cadence/tensilica customers?

[jamesmunns]

@caemor you might want to take a look at https://twitter.com/EspressifSystem/status/1095849676572520453.

Please feel free to open a new issue to discuss any specific topics.

[n8henrie]

@caemor you may have already seen https://github.com/espressif/llvm-xtensa but if not it looks promising.

[caemor]

yes already saw. it's looking good although it will still take some time until its integrated/merged into llvm