Pico float uint2float, int2float, etc. undefined when PICO_BOARD is set to "pico2" #2160

New issue

Closed

opened 2025-01-04 17:43:10 -06:00 by AESilky · 3 comments

AESilky commented

2025-01-04 17:43:10 -06:00

(Migrated from github.com)

I have cleared out the build directory and rebuilt numerous times with different combinations of the PICO_BOARD and pico_set_float_implementation and pico_set_double_implementation. When the PICO_BOARD is set to "pico" the functions are found and when set to "pico2" they are not found.

I switched a design from Pico to Pico2. I updated the SDK to SDK2 and changed the CMakeList.txt to specify "pico2" as the board. The float functions: uint2float, int2float, float2int now result in an undefined reference during the link when building. I have cleared out the build directory and rebuilt numerous times with different combinations of the PICO_BOARD and pico_set_float_implementation and pico_set_double_implementation. When the PICO_BOARD is set to "pico" the functions are found and when set to "pico2" they are not found.

kilograham commented

2025-01-06 17:12:05 -06:00

(Migrated from github.com)

Yes, we need to add the single precision variants on RP2350

I have spotted the following inconsistencies too while look at the code:

It also seems that the float_dcp is using the C-library __aeabi functions (see below) which is probably incorrect as they use VFP

     pico_wrap_function(${TARGET} __aeabi_i2f)
     pico_wrap_function(${TARGET} __aeabi_l2f)
     pico_wrap_function(${TARGET} __aeabi_ui2f)
     pico_wrap_function(${TARGET} __aeabi_ul2f)
     pico_wrap_function(${TARGET} __aeabi_f2iz)
     pico_wrap_function(${TARGET} __aeabi_f2lz)
     pico_wrap_function(${TARGET} __aeabi_f2uiz)
     pico_wrap_function(${TARGET} __aeabi_f2ulz)
     pico_wrap_function(${TARGET} __aeabi_f2d)

The float_conv_m33.S conversions expose some non round towards zero methods as _z which needs fixing (presumably unnoticed because of 1) - edit: actually these were unsigned ones where both behaviors are the same
Note that the single precision functions for the non float_dcp library can use the VCVT instructions or maybe we can do linker magic or #define to map them back to the __aeabi functions above. Note, I'm tempted not to use #define as they might be called from assembly + it is a bit weird if function impls appear/disappear between RP2040 and RP2350

Yes, we need to add the single precision variants on RP2350 I have spotted the following inconsistencies too while look at the code: 1. It also seems that the `float_dcp` is using the C-library `__aeabi` functions (see below) which is probably incorrect as they use VFP pico_wrap_function(${TARGET} __aeabi_i2f) pico_wrap_function(${TARGET} __aeabi_l2f) pico_wrap_function(${TARGET} __aeabi_ui2f) pico_wrap_function(${TARGET} __aeabi_ul2f) pico_wrap_function(${TARGET} __aeabi_f2iz) pico_wrap_function(${TARGET} __aeabi_f2lz) pico_wrap_function(${TARGET} __aeabi_f2uiz) pico_wrap_function(${TARGET} __aeabi_f2ulz) pico_wrap_function(${TARGET} __aeabi_f2d) 2. The `float_conv_m33.S` conversions expose some non round towards zero methods as `_z` which needs fixing (presumably unnoticed because of 1) - edit: actually these were unsigned ones where both behaviors are the same 3. Note that the single precision functions for the non `float_dcp` library can use the `VCVT` instructions or maybe we can do linker magic or `#define` to map them back to the `__aeabi` functions above. Note, I'm tempted not to use `#define` as they might be called from assembly + it is a bit weird if function impls appear/disappear between RP2040 and RP2350

Rows
Columns