Adds two new Tier 3 targets - `aarch64v8r-unknown-none{,-softfloat}`
## New Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`
This PR adds two new Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test `aarch64-unknown-none` to a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
## Tier 3 Policy Notes
To cover off the Tier 3 requirements:
> A tier 3 target must have a designated developer or developers
Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.
> Targets must use naming consistent with any existing targets
We prefix this target with `aarch64` because it generates A64 machine code (like `arm*` generates A32 and `thumb*` generates T32). In an ideal world I'd get to rename the existing target `aarch64v8a-unknown-none` but that's basically impossible at this point. You can assume `v6` for any `arm*` target where unspecified, and you can assume `v8a` for any `aarch64*` target where not specified.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
It works just like the existing AArch64 bare-metal target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate.
It's a bare-metal target, offering libcore and liballoc.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Done
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
It's AArch64 and so works with LLVM.
db654cb421