Support for hardware divider and firmware float support

[DusterTheFirst]

Thinking about the benefits of switching to rust from c/c++ for the pico, a few basic things stand out as downsides to rust. The C/C++ SDK links the standard / and % operators to the onboard hardware divider. Im not 100% sure on the internals of the rust arm compiler and the HAL/PAC for the rp2040 but assumedly, unless manually implemented, the rust compiler will not be able to correctly use the hardware divider. This is most definitely the same with the firmware float implementations. Both of these additions would let rust programs be able to fully take over the full power of the rp2040 chip that currently is exclusive to the standard C/C++ SDK and Micropython implementation.

[leo60228]

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

[9names]

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).

[9names]

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

[leo60228]

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.