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.