Support for hardware divider and firmware float support about rp-hal HOT 4 CLOSED

I haven't looked at the soft-float library that is shipped with the C SDK, but I do not want to embed a C floating point library into our HAL. End-users can choose to do that if they like, but we are not going to impose that on everyone.

The floating point library is in ROM. The C SDK just has some assembly stubs to make use of it.

from rp-hal.

I'm not 100% sure, but I believe that this is an issue for https://compiler-rt.llvm.org/ and not this project.

from rp-hal.

I think supporting the hardware divider is a good goal that deserves a tracking issue.
I've created a tracking issue for that at #35 if you would like to implement this.

As far as the other questions / thoughts go, I have some opinions.

I haven't looked at the soft-float library that is shipped with the C SDK, but I do not want to embed a C floating point library into our HAL. End-users can choose to do that if they like, but we are not going to impose that on everyone.

As for the hardware divider: As a user, I would not expect our implementation to override operator div(/) and operator mod(%) for i32/u32 (it would need to be part of the core lib to do this)
Neither do I think it likely that it would be implemented as part of LLVM-RT or Rust core lib.
Both of these projects target standard CPU features; this is a separate hardware peripheral that's specific to one processor family, requires use of target specific spinlock peripherals for multi-processor safety, and could be placed at another memory address on another pi microcontroller, etc.

In a C/C++ embedded it's fairly common for the vendor to ship toolchain with a custom version of libc.
For Rust, people are used to calling cargo or rustup and not having to deal with the typical one-toolchain-per-product-family that often only gets a single release.
I don't think the benefit of ease-of-use of div/mod with operator / and operator % is worth this cost, especially when embedded users will likely have to deal with function-style variations on arithmetic anyway ( for checked_div, saturating_add, etc).

from rp-hal.

Closing this out as we now have basic support for the hardware divider

from rp-hal.