Architecture support (tracking issue) #112
Description
Rust supported architectures: https://forge.rust-lang.org/platform-support.html For our purposes, we don't care much about Tier 1 vs. Tier 2, and even Tier 3 support is probably fine.
Another useful reference is Debian's arch status as of February 2018: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-February/001215.html (doesn't include all the arches the kernel supports)
| arch | description | LLVM status | Rust status |
|---|---|---|---|
| alpha | DEC Alpha | removed from LLVM in 2011 | |
| arc | Synopsys ARC | present | needs port |
| arm | ARM 32-bit | present | ARMv5 and up is Tier 2 |
| arm64 | ARM 64-bit aka AARCH64 | present | Tier 2 |
| c6x | TI C6000-series VLIW DSPs | no LLVM port | |
| csky | C-Sky | no LLVM port | |
| h8300 | Hitachi H8 | no LLVM port | |
| hexagon | Qualcomm Hexagon DSP, part of Snapdragon SoCs | present | added July 2019 |
| ia64 | Intel Itanium | removed from LLVM in 2009 | |
| m68k | Motorola 680x0 | port exists, proposed for merge | work in progress |
| microblaze | Xilinx MicroBlaze for FPGAs | removed from LLVM | |
| mips | MIPS (R3000 / MIPS I and up) | present for R4000 / MIPS II and up | Tier 2 |
| nds32 | Andes AndeStar 32-bit | proposed for merge in 2017 | needs port |
| nios2 | Altera Nios II for FPGAs | removed from LLVM in January 2019 | |
| openrisc | OpenRISC | out-of-tree backend | needs port |
| parisc | Hewlett-Packard PA-RISC aka hppa | no LLVM port | |
| powerpc | PowerPC / POWER 32-bit, 64-bit LE, 64-bit BE | all present | all Tier 2 |
| riscv | RISC-V | present | Tier 2 |
| s390 | z/Architecture 64-bit aka s390x | present | Tier 2 |
| sh | Hitachi SuperH / J2 | experimental out-of-tree backend | needs port |
| sparc | Sun SPARC 32- and 64-bit | present | Tier 2 for 64-bit (SPARC v9), needs 32-bit port |
| um | User-Mode Linux (on any userspace arch) | N/A | might just work? |
| x86 | Intel x86 aka i386 and x86-64 aka amd64 | present | Tier 1 |
| xtensa | Tensilica Xtensa, used on ESP microcontrollers | proposed for merge in March 2019 | work in progress |
Re ARMv4 - the linked issue implies ARMv4 is only a microcontroller for OS-less use, but arch/arm/mach-gemini/ looks like an actual Linux target for ARMv4. There are also a few ARMv4T boards (i.e., with Thumb support). It looks like LLVM wants to emit BLX instructions which switch to Thumb mode, so unclear if plain ARMv4 will work. (Though forcing it to emit non-Thumb code only doesn't sound like it should be too difficult....)
Re MIPS I - see simias/psx-sdk-rs#1. MIPS I has load delay slots, LLVM's codegen would need to be taught about it. https://github.com/impiaaa/llvm-project seems to have a patch.
Some possible approaches for merging into mainline and dealing with architectures with no LLVM support and no realistic plans (e.g., processors no longer manufactured):
- Convince Linux to drop them <_< >_>
- Only support certain architectures via Kconfig - it's probably okay to only support some modules on the major architectures
- Use mrustc to compile via C https://github.com/thepowersgang/mrustc
- Use the LLVM C backend to compile via C Investigate LLVM C backend #111
- Write a GCC frontend for Rust, see https://github.com/sapir/gcc-rust/tree/rust (which glues actual rustc into GCC) or https://github.com/redbrain/gccrs, both of which seem to be actively developed
- Something involving Cranelift, maybe? I don't have a good sense of what this would look like / whether it would work.