21 ms·

This book focuses on the ARM Cortex-M archtectured microcontrollers.. Is there a comprehensive list which other microcontroller is supported by Rust? I really

This book focuses on the ARM Cortex-M archtectured microcontrollers.. Is there a comprehensive list which other microcontroller is supported by Rust? I really like the direction that Rust is heading in regards to embedded but I wish that when folks mentioned embedded, they should also indicate which microcontrollers are relevant. There are so many varieties around.

Ericson2314 8y ago
There's no point in having a list. Anything LLVM supports can work. The rest it just a surmountable library problem, but which libraries are good enough is a matter of some opinion.
- aey 8y ago
  Not quite. Not all ISAs are equivalent and not all llvm backends are equivalent. Rust depends on a few features that are typically not found in embedded systems, like multiple return registers. I wouldn’t even call ARM an embedded ISA anymore.
  - ajross 8y ago
    Uh... multiple registers dedicated to return values is a feature of an ABI, not an architecture. The hardware doesn't care what you put in those registers, obviously. Rust defines its own ABI for internally-generated code, it doesn't need to care. And in fact I'm not aware of any such systems. Existing 32+ bit embedded architectures like MIPS, RISC-V, Xtensa, and ARC all have robust instruction sets with large register files and a fully-defined SysV-style C ABI. No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them.
    - analognoise 8y ago
      Where is the SysV style C ABI defined if we wanted to go read more about it? Or, do you have a favorite reference for a work explaining it's design choices? I'm interested in soft processors on FPGAs and their tools, and that sounds like it might make for good reading.
      - thristian 8y ago
        Nobody actually uses System V anymore, but because it's the thing other Unixy systems are based on, people keep extending the SysV ABI standard to processors ridiculously more powerful than System V itself could ever hope to run on. As best I can make out, the only relevant portions of the original SysV ABI document are chapters 4 and 5, still available and maintained on the SCO website: http://www.sco.com/developers/gabi/ http://www.sco.com/developers/gabi/ There are also separate documents defining the details of the SysV ABI for each processor family. This StackOverflow answer links to some: https://stackoverflow.com/a/40348010 https://stackoverflow.com/a/40348010 ... and the OSDev Wiki links to many more: https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI
    - 0815test 8y ago
      > No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them. Part of the problem is that LLVM developers themselves are apparently unwilling to release support for architectures that they see as liable to go unmaintained and bitrot in the future, even if someone shows up and does the work. There is a notion of "experimental arch's" but it doesn't seem to be actively used, or to suffice in addressing the issue.
      - wyldfire 8y ago
        Backend support is pruned for architectures that go dark. But if you showed up with support for a new one I'd be really surprised if it weren't included. Experimental archs were just used recently for wasm and riscv to find maturity. Are you referring to a specific discussion on the llvm-dev list? Last one that had a discussion in this area that I recall was Nios2.
    - aey 8y ago
      100%! My fault for conflating ABI and ISA. The C ABI that is first supported by a new llvm backend typically doesn’t have those features implemented. Which makes porting a higher level language like rust non trivial.
- mhh__ 8y ago
  Compiler exists in theory != supported
  - Ericson2314 8y ago
    I'm sorry but that sounds like a distinction only to freeloaders. Know your dependencies, use something like Nix+Nixpkgs to put yourself in charge of the upgrade schedule, and there will be no nasty surprises.
nouveaux 8y ago
The last I checked, it is only ARM chips now because it's what LLVM supports.
steveklabnik 8y ago
https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html is mostly accurate.
- robocat 8y ago
  Wow: tier 1 contains no ARM or other CPU arch. Tier 1 is only 32bit i686 and 64bit x86_64. Tier 2 platforms can be thought of as “guaranteed to build”. Automated tests are not run so it’s not guaranteed to produce a working build.
  - dagmx 8y ago
    It's pretty par for the course to have tier 1 be the most common consumer systems since they're the ones with the most bang for buck, and easiest available CI infrastructure.
  - steveklabnik 8y ago
    We’ve been thinking about re-doing the tier system, as it misses some important points. For example, Firefox has ARM as a tier 1 platform, so if we find bugs, they tend to get fixed up pretty quick. We’re not sure the current way of defining stuff really maps to the reality.
  - wyldfire 8y ago
    This is AFAICT a rust developer consideration more than anything else? I think/hope that releases are gated by one or more tier 2's successful target tests?
  - rcxdude 8y ago
    AFAIK this is mostly waiting on someone to step up and provide the relevant CI infrastructure.
- hsivonen 8y ago
  Notably for the topic at hand, RISC-V target list is unmerged: https://github.com/rust-lang/rust-forge/pull/202/files https://github.com/rust-lang/rust-forge/pull/202/files (Also two other unmerged PRs to the list.)

Ericson2314 8y ago

There's no point in having a list. Anything LLVM supports can work. The rest it just a surmountable library problem, but which libraries are good enough is a matter of some opinion.

aey 8y ago
Not quite. Not all ISAs are equivalent and not all llvm backends are equivalent. Rust depends on a few features that are typically not found in embedded systems, like multiple return registers. I wouldn’t even call ARM an embedded ISA anymore.
- ajross 8y ago
  Uh... multiple registers dedicated to return values is a feature of an ABI, not an architecture. The hardware doesn't care what you put in those registers, obviously. Rust defines its own ABI for internally-generated code, it doesn't need to care. And in fact I'm not aware of any such systems. Existing 32+ bit embedded architectures like MIPS, RISC-V, Xtensa, and ARC all have robust instruction sets with large register files and a fully-defined SysV-style C ABI. No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them.
  - analognoise 8y ago
    Where is the SysV style C ABI defined if we wanted to go read more about it? Or, do you have a favorite reference for a work explaining it's design choices? I'm interested in soft processors on FPGAs and their tools, and that sounds like it might make for good reading.
    - thristian 8y ago
      Nobody actually uses System V anymore, but because it's the thing other Unixy systems are based on, people keep extending the SysV ABI standard to processors ridiculously more powerful than System V itself could ever hope to run on. As best I can make out, the only relevant portions of the original SysV ABI document are chapters 4 and 5, still available and maintained on the SCO website: http://www.sco.com/developers/gabi/ http://www.sco.com/developers/gabi/ There are also separate documents defining the details of the SysV ABI for each processor family. This StackOverflow answer links to some: https://stackoverflow.com/a/40348010 https://stackoverflow.com/a/40348010 ... and the OSDev Wiki links to many more: https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI
  - 0815test 8y ago
    > No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them. Part of the problem is that LLVM developers themselves are apparently unwilling to release support for architectures that they see as liable to go unmaintained and bitrot in the future, even if someone shows up and does the work. There is a notion of "experimental arch's" but it doesn't seem to be actively used, or to suffice in addressing the issue.
    - wyldfire 8y ago
      Backend support is pruned for architectures that go dark. But if you showed up with support for a new one I'd be really surprised if it weren't included. Experimental archs were just used recently for wasm and riscv to find maturity. Are you referring to a specific discussion on the llvm-dev list? Last one that had a discussion in this area that I recall was Nios2.
  - aey 8y ago
    100%! My fault for conflating ABI and ISA. The C ABI that is first supported by a new llvm backend typically doesn’t have those features implemented. Which makes porting a higher level language like rust non trivial.
mhh__ 8y ago
Compiler exists in theory != supported
- Ericson2314 8y ago
  I'm sorry but that sounds like a distinction only to freeloaders. Know your dependencies, use something like Nix+Nixpkgs to put yourself in charge of the upgrade schedule, and there will be no nasty surprises.

nouveaux 8y ago

The last I checked, it is only ARM chips now because it's what LLVM supports.

steveklabnik 8y ago

https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html is mostly accurate.

robocat 8y ago
Wow: tier 1 contains no ARM or other CPU arch. Tier 1 is only 32bit i686 and 64bit x86_64. Tier 2 platforms can be thought of as “guaranteed to build”. Automated tests are not run so it’s not guaranteed to produce a working build.
- dagmx 8y ago
  It's pretty par for the course to have tier 1 be the most common consumer systems since they're the ones with the most bang for buck, and easiest available CI infrastructure.
- steveklabnik 8y ago
  We’ve been thinking about re-doing the tier system, as it misses some important points. For example, Firefox has ARM as a tier 1 platform, so if we find bugs, they tend to get fixed up pretty quick. We’re not sure the current way of defining stuff really maps to the reality.
- wyldfire 8y ago
  This is AFAICT a rust developer consideration more than anything else? I think/hope that releases are gated by one or more tier 2's successful target tests?
- rcxdude 8y ago
  AFAIK this is mostly waiting on someone to step up and provide the relevant CI infrastructure.
hsivonen 8y ago
Notably for the topic at hand, RISC-V target list is unmerged: https://github.com/rust-lang/rust-forge/pull/202/files https://github.com/rust-lang/rust-forge/pull/202/files (Also two other unmerged PRs to the list.)