Although Rust has support for MIPS, it’s currently limited to 32-bit and the o32 ABI, while the more recent MIPS processors are almost entirely 64-bit-capable, and people actually using them are more likely to choose a more performant ABI such as n32. For example, the Chinese homegrown Loongson series of processors support a superset of MIPS64 since Loongson 2, and it would be really nice to leverage the chip’s full potential.
I’m owner of a Loongson 2F netbook and a Loongson 1C development board, and would like to push forward MIPS support in Rust. But I’d first see if anyone else is also interested and perhaps get some advice on the general approach, as overall there seems to be insufficient foundation for elegant ABI support. x32 on AMD64 is missing for example, and the preparatory work really should be done.
I've added support for a few new targets to rustc and also done some of the required work to get new binary releases of std for those targets so I can mentor the implementation work.
We should have an RFC on how to support ABI variations of an existing target. The most straightforward way seems to just add new targets for them e.g. x86_64-unknown-linux-gnux32, mips-unknown-linux-gnun32 (?), etc. We already do something like that for arm: arm-unknown-linux-gnueabi (soft ABI) vs arm-unknown-linux-gnueabihf (hard ABI). The RFC should discuss how to handle conditional compilation for those targets, and/or if it's needed at all.
But, I think we can start adding support for mips64-unknown-linux-gnu right away if we first pick which calling convention ABI it should use: n32, n64 or o32. I don't which one is the most commonly used.
P.S. Adding a target to rustc is blocked on LLVM supporting that target/ABI/calling-convention. Releasing std binaries for a target is blocked on getting a C cross toolchain that can cross compile jemalloc, libbacktrace, etc for that target.