Create aarch32-cpu and aarch32-rt crates.

[thejpster]

Replaces cortex-r-rt, cortex-a-rt and cortex-ar.

[thejpster]

This got big, and Armv5TE stuff is broken in weird ways, so I'm going to pull out parts of this as separate PRs.

Current list of weirdness:

• Somehow, _default_handler ends up missing, and linking an example without an #[irq] function fails - yet when I dissassemble libaarch32-rt.rlib I can see _default_handler right there. No idea what is doing on.
• Armv5TE and Armv4T targets emit calls to instrinsic functions for atomic load and store, even though they can do atomic load/store without intrinsics (they cannot do CAS, but that's OK because we're not doing CAS). This is especially odd as the target is very similar to thumbv6m-none-eabi, and that does not emit calls to intrinsics. I suspect I'll need to go through the LLVM source to work it out - unless Zulip can help.

[robamu]

Needs to be rebased. I can also perform some testing on the Zynq7000

[thejpster]

Phew, all tests pass on ARMv4T (PXA25) and ARMv5TE (ARM926) in QEMU.

[robamu]

What about the double precision context functions? (

cortex-ar/cortex-a-rt/src/lib.rs

Line 595 in b7d60b9

macro_rules! save_context {

)

[thejpster]

There are no EABIHF targets for Armv4T and Armv5TE so I didn’t check.

[robamu]

would it make sense to set this to v0.1.0? It is a merge of 2 run-time crates with a different name, so maybe a the crate with a new name starting at version v0.2.1 might be confusing? I tripped over this trying to include it with version v0.1.0 (former cortex-a-rt version)

[thejpster]

Good point

[robamu]

I tested some of the Zynq7000 examples, and they work without issues :)

Those did not include floating code I think. Might add that to test the double precision support.