-
|
I just added to my project some code trying to use a function returning some floats (on atmega32u4), and I seem to be getting a linker error: Am I doing something wrong? Am I missing something? My project is generally at: https://github.com/akavel/chordite-rust; I'm trying to call Any ideas what I could try? |
Beta Was this translation helpful? Give feedback.
Answered by
Patryk27
Mar 16, 2025
Replies: 4 comments 10 replies
-
|
In meantime, I found the EDIT: Whoops, too happy too early: micromath seems waaaay too humongous for my case: trying to use it gave me some +80KB to hex file size - this doesn't seem sustainable... :( |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
You should really avoid using 32-bit floating point numbers on an 8-bit microcontroller. All the floating point maths needs to be implemented in software which leads to the expected bloat you noticed. In any case, paging @Patryk27 - do you know about the |
Beta Was this translation helpful? Give feedback.
-
|
On the top of my head I'm not sure what might be going on - I'll investigate it tomorrow/Saturday! |
Beta Was this translation helpful? Give feedback.
-
|
f32 operations (aka intrinsics) are provided by avr-gcc and so depending on your avr-gcc's version you might or might not have them on your machine (newer avr-gcc = better, in general). But going over rust-lang/compiler-builtins#711 I've realized that we should be actually able to pull those intrinsics from compiler-builtins, which is a Rust crate that implements those operations bypassing the need for avr-gcc to provide them - in particular, the function that you're missing is there: ... but over rust-lang/compiler-builtins#527 I've disabled those floating-point intrisics, since they seemed not to work - initially I assumed it was an ABI mismatch (as in rust-lang/compiler-builtins#462 (comment)), but since floating-point intrinsics don't require special ABI (as I've noticed just now), it must be actually a codegen bug. tl;dr floating-point operations should work (and shouldn't even be prohibitively heavy), but it's somewhat of a gray area at the moment - in particular, there's something wrong in the codegen, because if you do: #[inline(never)]
fn out() -> bool {
f32::from_bits(black_box(2143289344)).is_nan()
}
#[arduino_hal::entry]
fn main() -> ! {
let dp = arduino_hal::Peripherals::take().unwrap();
let pins = arduino_hal::pins!(dp);
let mut serial = arduino_hal::default_serial!(dp, pins, 57600);
ufmt::uwrite!(serial, "out={}\n", out());
loop {
//
}
}... then as-is (using avr-gcc's intrinsics) it will correctly print tl;dr tl;dr it should work, is broken, will report back when I have a solution 🙂 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hah, it might be an ABI mismatch, after all 😄 -- it seems that compiler-builtins assumes that some intrinsics, like this one, return i32: ... while in reality they should return |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Ok, got something tangible! rust-lang/compiler-builtins#791 If you want, @akavel, you can test it locally by adding |
Beta Was this translation helpful? Give feedback.
8 replies
-
|
Still no luck I'm afraid on my side 😅 I now realize I didn't link a specific commit, so to correct this, I just pushed a branch, already with an attempt at using the Mar 13 nightly: https://github.com/akavel/clawtype/commits/float-noskip-tests/ (repo was renamed in meantime) FWIW I'm now getting some rustc panicks :D the first message after the warnings looks to be of some possible relevancy, though it doesn't tell much in detail to me: (Note also that the actual build in the repo needs to be started in the Full dump: |
Beta Was this translation helpful? Give feedback.
-
|
Ok, now I see the mistake - with the newest compiler you don't need the target jsons anymore, instead of: [build]
target = "avr-specs/avr-atmega32u4.json"... you should have: [build]
target = "avr-none"
rustflags = ["-C", "target-cpu=atmega32u4"] |
Beta Was this translation helpful? Give feedback.
-
|
Hrmh. So, as to the compilation itself, indeed it seems to work now, at least in the release mode. Unfortunately for me, again the resulting build artifact seems to swell inordinately in bytes terms. Such that I can no longer flash it to my puny 32k teensy2 😔 Which also has me super confused, because why just adding some code for float mul+div+sqrt, which doesn't seem so crazy much, would suddenly add some 10kb of assembly?? What am I not seeing? 🤔 Finally, as to non-release build, I'm getting a missing symbol |
Beta Was this translation helpful? Give feedback.
-
|
10 kB sounds about right - floating-point operations are pretty heavy! Here's all the code you need to have in order to just add or divide two numbers:
Considering AVR has just 8-bit registers, the final code probably just does a lot of "temporarily copy stuff here", "temporarily copy stuff there", "save to stack", "load from stack" etc. |
Beta Was this translation helpful? Give feedback.
-
|
Ouch... then I probably need to think how to do what I need through some kind of trickery, approximations, and other cheating 🤔 Thanks for all the amazing support, anyway! |
Beta Was this translation helpful? Give feedback.
Answer selected by
akavel
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ok, got something tangible!
rust-lang/compiler-builtins#791
If you want, @akavel, you can test it locally by adding
compiler_builtins_ex = { package = "compiler_builtins", git = "https://github.com/Patryk27/compiler-builtins", branch = "avr-skip-no-more" }toCargo.tomlandextern crate compiler_builtins_ex;tomain.rs; having done so, floating-point operations should work.