Uh oh!
There was an error while loading. Please reload this page.
add Thumbs to the compiler - #36874
Conversation
rust-highfive
commented
Sep 30, 2016
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
alexcrichton
commented
Sep 30, 2016
👍 |
japaric
left a comment
There was a problem hiding this comment.
Oh, I meant to left this comment earlier but didn't realize I clicked the start review thing. 🤦
There was a problem hiding this comment.
@alexcrichton this fixes the problem I was seeing where setting max_atomic_width to 0 in the Target declaration was being converted into 32 due to the JSON roundtrip. I've also added a rmake test for this.
There was a problem hiding this comment.
Woah can't we use Option instead of magic 0 treatment or similar? Granted, I'm arriving late to this issue so apologies if that has already been ruled out for good reason.
There was a problem hiding this comment.
This was the simplest change necessary to make this work but using Option here sounds better; I'll give it a try.
bors
commented
Oct 1, 2016
☔ The latest upstream changes (presumably #36339) made this pull request unmergeable. Please resolve the merge conflicts. |
this commit adds 4 new target definitions to the compiler for easier cross compilation to ARM Cortex-M devices. - `thumbv6m-none-eabi` - For the Cortex-M0, Cortex-M0+ and Cortex-M1 - This architecture doesn't have hardware support (instructions) for atomics. Hence, the `Atomic*` structs are not available for this target. - `thumbv7m-none-eabi` - For the Cortex-M3 - `thumbv7em-none-eabi` - For the FPU-less variants of the Cortex-M4 and Cortex-M7 - On this target, all the floating point operations will be lowered software routines (intrinsics) - `thumbv7em-none-eabihf` - For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU. - On this target, all the floating point operations will be lowered to hardware instructions No binary releases of standard crates, like `core`, are planned for these targets because Cargo, in the future, will compile e.g. the `core` crate on the fly as part of the `cargo build` process. In the meantime, you'll have to compile the `core` crate yourself. [Xargo] is the easiest way to do that as in handles the compilation of `core` automatically and can be used just like Cargo: `xargo build --target thumbv6m-none-eabi` is all that's needed. [Xargo]: https://crates.io/crates/xargo
japaric
commented
Oct 2, 2016
| options: TargetOptions { | ||
| // vfp4 lowest common denominator between the Cortex-M4 (vfp4) and the Cortex-M7 (vfp5) | ||
| features: "+vfp4".to_string(), |
There was a problem hiding this comment.
I believe you also need +fp-only-sp
There was a problem hiding this comment.
Hmm, won't that preclude a user from enabling double precision hardware acceleration? Perhaps they'll have to pass -fp-only-sp apart from the other feature that enables DP FP ops. (I'm speculating; I haven't tried any of this)
There was a problem hiding this comment.
Yes -fp-only-sp would work to switch it back on. +d16 should probably be added here too.
alexcrichton
commented
Oct 3, 2016
@japaric could you also add some comments to each target file in line with the RFC itself? Basically just some basic rationale for the target name, what it's intended to be used for, etc. |
to better express the idea that omitting this field defaults this value to target_pointer_width
alexcrichton
commented
Oct 4, 2016
bors
commented
Oct 4, 2016
📌 Commit 6136069 has been approved by |
bors
commented
Oct 4, 2016
add Thumbs to the compiler this commit adds 4 new target definitions to the compiler for easier cross compilation to ARM Cortex-M devices. - `thumbv6m-none-eabi` - For the Cortex-M0, Cortex-M0+ and Cortex-M1 - This architecture doesn't have hardware support (instructions) for atomics. Hence, the `Atomic*` structs are not available for this target. - `thumbv7m-none-eabi` - For the Cortex-M3 - `thumbv7em-none-eabi` - For the FPU-less variants of the Cortex-M4 and Cortex-M7 - On this target, all the floating point operations will be lowered software routines (intrinsics) - `thumbv7em-none-eabihf` - For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU. - On this target, all the floating point operations will be lowered to hardware instructions No binary releases of standard crates, like `core`, are planned for these targets because Cargo, in the future, will compile e.g. the `core` crate on the fly as part of the `cargo build` process. In the meantime, you'll have to compile the `core` crate yourself. [Xargo] is the easiest way to do that as in handles the compilation of `core` automatically and can be used just like Cargo: `xargo build --target thumbv6m-none-eabi` is all that's needed. [Xargo]: https://crates.io/crates/xargo --- cc @brson@alexcrichton
this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.
thumbv6m-none-eabiatomics. Hence, the
Atomic*structs are not available for thistarget.
thumbv7m-none-eabithumbv7em-none-eabisoftware routines (intrinsics)
thumbv7em-none-eabihfto hardware instructions
No binary releases of standard crates, like
core, are planned forthese targets because Cargo, in the future, will compile e.g. the
corecrate on the fly as part of the
cargo buildprocess. In the meantime,you'll have to compile the
corecrate yourself. Xargo is the easiestway to do that as in handles the compilation of
coreautomatically andcan be used just like Cargo:
xargo build --target thumbv6m-none-eabiis all that's needed.
cc @brson@alexcrichton