30
30
31
31
## Common Target Details
32
32
33
- This documentation covers details that apply to a range of bare-metal target for
34
- 32-bit ARM CPUs. In addition, target specific details may be covered in their
35
- own document.
33
+ This documentation covers details that apply to a range of bare-metal targets
34
+ for 32-bit ARM CPUs. In addition, target specific details may be covered in
35
+ their own document.
36
36
37
37
If a target ends in ` eabi ` , that target uses the so-called * soft-float ABI* :
38
38
functions which take ` f32 ` or ` f64 ` as arguments will have those values packed
39
39
into integer registers. This means that an FPU is not required from an ABI
40
- perspective, but within a function FPU instructions may still be used if the
41
- code is compiled with a ` target-cpu ` or ` target-feature ` option that enables
42
- FPU support.
40
+ perspective, but within a function floating-point instructions may still be used
41
+ if the code is compiled with a ` target-cpu ` or ` target-feature ` option that
42
+ enables FPU support.
43
43
44
- If a target ends if ` eabihf ` , that target uses the so-called * hard-float ABI* :
44
+ If a target ends in ` eabihf ` , that target uses the so-called * hard-float ABI* :
45
45
functions which take ` f32 ` or ` f64 ` as arguments will have them passed via FPU
46
- registers. These targets therefore require the use of an FPU and will assume the
47
- minimum support FPU for that architecture is available. More advanced FPU
48
- instructions (e.g. ones that work on double-precision ` f64 ` values) may be
46
+ registers. These targets therefore require the availability of an FPU and will
47
+ assume some baseline level of floating-point support is available (which can
48
+ vary depending on the target). More advanced floating-point instructions may be
49
49
generated if the code is compiled with a ` target-cpu ` or ` target-feature ` option
50
- that enables such additional FPU support.
50
+ that enables such additional FPU support. For example, if a given hard-float
51
+ target has baseline * single-precision* (` f32 ` ) support in hardware, there may be
52
+ ` target-cpu ` or ` target-feature ` options that tell LLVM to assume your processor
53
+ in fact also has * double-precision* (` f64 ` ) support.
54
+
55
+ You may of course use the ` f32 ` and ` f64 ` types in your code, regardless of the
56
+ ABI being used, or the level of support your processor has for performing such
57
+ operations in hardware. Any floating-point operations that LLVM assumes your
58
+ processor cannot support will be lowered to library calls (like ` __aeabi_dadd ` )
59
+ which perform the floating-point operation in software using integer
60
+ instructions.
51
61
52
62
## Target CPU and Target Feature options
53
63
@@ -61,7 +71,7 @@ It is important to note that selecting a *target-cpu* will typically enable
61
71
* all* the optional features available from Arm on that model of CPU and your
62
72
particular implementation of that CPU may not have those features available. In
63
73
that case, you can use ` -C target-feature=-option ` to turn off the specific CPU
64
- features you do not have available, leaving you with the optimised instruction
74
+ features you do not have available, leaving you with the optimized instruction
65
75
scheduling and support for the features you do have. More details are available
66
76
in the detailed target-specific documentation.
67
77
@@ -76,13 +86,13 @@ uses (likely linker related ones):
76
86
``` toml
77
87
rustflags = [
78
88
# Usual Arm bare-metal linker setup
79
- " -C " , " link -arg=-Tlink.x" ,
80
- " -C " , " link -arg=--nmagic" ,
89
+ " -Clink -arg=-Tlink.x" ,
90
+ " -Clink -arg=--nmagic" ,
81
91
# tell Rust we have a Cortex-M55
82
- " -C " , " target -cpu=cortex-m55" ,
92
+ " -Ctarget -cpu=cortex-m55" ,
83
93
# tell Rust our Cortex-M55 doesn't have Floating-Point M-Profile Vector
84
94
# Extensions (but it does have everything else a Cortex-M55 could have).
85
- " -C " , " target -feature=-mve.fp"
95
+ " -Ctarget -feature=-mve.fp"
86
96
]
87
97
88
98
[build ]
@@ -157,10 +167,10 @@ Most of `core` should work as expected, with the following notes:
157
167
158
168
Rust programs are output as ELF files.
159
169
160
- [ atomic-load ] : https://doc.rust-lang.org/stable/std /sync/atomic/struct.AtomicU32.html#method.load
161
- [ atomic-store ] : https://doc.rust-lang.org/stable/std /sync/atomic/struct.AtomicU32.html#method.store
162
- [ fetch-add ] : https://doc.rust-lang.org/stable/std /sync/atomic/struct.AtomicU32.html#method.fetch_add
163
- [ compare-exchange ] : https://doc.rust-lang.org/stable/std /sync/atomic/struct.AtomicU32.html#method.compare_exchange
170
+ [ atomic-load ] : https://doc.rust-lang.org/stable/core /sync/atomic/struct.AtomicU32.html#method.load
171
+ [ atomic-store ] : https://doc.rust-lang.org/stable/core /sync/atomic/struct.AtomicU32.html#method.store
172
+ [ fetch-add ] : https://doc.rust-lang.org/stable/core /sync/atomic/struct.AtomicU32.html#method.fetch_add
173
+ [ compare-exchange ] : https://doc.rust-lang.org/stable/core /sync/atomic/struct.AtomicU32.html#method.compare_exchange
164
174
165
175
## Testing
166
176
0 commit comments