Native MC Float handling with armv6m

[shabaz123]

Hello,

I've been experimenting with the Native Machine Code feature of MicroPython, and the example files are super-useful.

I can build the natmod/features2 example fine targeted for x64 architecture. If I edit the Makefile and replace x64 with armv6m:
ARCH = armv6m

then, the natmod/features2 example does not build. I get this error:

CC prod.c
LINK build/main.o
LinkError: build/main.o: undefined symbol: __aeabi_fadd

This is an issue for me, because I have a bunch of code that looks very like the natmod/features2 example, i.e. lots of separate functions in a lot of files, and many of them do conversions between integer and float or double, and it will be almost impossible to rewrite the algorithms to eliminate such conversions.

Is there any tip to get around this issue?

Many thanks!

[dlech]

Does it help if you link the gcc library? (LIBS += -lgcc)

[shabaz123]

Hi @dlech

Unfortunately no, I still see the same error:

Location of top-level MicroPython directory

MPY_DIR = ../../micropython_link

# Name of module
MOD = features2

# Source files (.c or .py)
SRC = main.c prod.c test.py

# Architecture to build for (x86, x64, armv7m, xtensa, xtensawin)
ARCH = armv6m

LIBS += -lgcc

# Include to get the rules for compiling and linking the module
include $(MPY_DIR)/py/dynruntime.mk

Error:

include $(MPY_DIR)/py/dynruntime.mk
shabaz@u18-nuc:~/development/micropython/native_mc/features2$ make
LINK build/main.o
LinkError: build/main.o: undefined symbol: __aeabi_fadd
make: *** [../../micropython_link/py/dynruntime.mk:145: build/features2.native.mpy] Error 1

[jimmo]

I think it is possible to make this work but it is complicated. The simple explanation is that the target architecture (armv6m) doesn't have hardware floating point so the compiler is trying to use software floating point but isn't linking against the helpers.

The reason it works on x86 (and any arch with hardware floating point) is that the compiler just emits regular floating point instructions. You need to be careful to match single or double precision against whatever the firmware is using though (i.e. mp_float_t must be the same type, i.e. MICROPY_FLOAT_IMPL must be the same), and all your interfaces that exchange float values with the firmware must be via mp_float_t.

On architectures without hardware floating point, we usually enable software single-precision, however this doesn't work in dynamic modules because we have no way for the dynamic loader to link up the helper functions. So you'd need to statically link in all the software floating point support, which is wasteful because the firmware already has it.

On the rp2040 specifically the situation is more interesting -- there is no hardware floating support, however, the software floating point (single and double) are implemented in the mask rom. And this is convenient because they're at a known static location (i.e. they don't have to be resolved in the MicroPython firmware). So... in theory all you need to do is tell the compiler how to find them. FWIW the pico-sdk does this here: https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/pico_float

[shabaz123]

Hi @jimmo
Thank you for the detailed answer. I've checked the pico-sdk link, and you're right, it's not straightforward!
I'll have a think about how I'll proceed. I initially thought the Native MC method could have been suitable for the code, but perhaps I should re-think and implement it in a different manner, perhaps even a hybrid method (convert some of the code into Python, so that the Native MC parts of the code doesn't need to call those float functions), and then re-visit this when I have more time to examine it, because I would like to have the capability to have those float math features in the C code, since there can be legacy code that is just not easy to port to Python.
Thanks again!

[jimmo]

Maybe get it working as a regular C module (i.e. compiled into the firmware) and then explore dynamic modules later?

[mishal]

I'm having the same problem with my native module... @shabaz123 how did you solve this?

I've found something on the old forum (year 2021).... https://forums.raspberrypi.com/viewtopic.php?t=320367

[vshymanskyy]

One way to solve it is this PR: #15838