ESP32 Forum

Hello.

So... I'm playing with "RVfplib - Optimized RISC-V FP emulation for 32-bit processors" (SOURCE)

I have the above compiled as a loadable module, and integrated into ESP-IDF in my IDE of choice. Was fiddly, but with MinGW I got it built.

If I drop the resulting files from above into an ESP-IDF project, the project will then happily compile and I can *MANUALLY* call functions from said library without error... but it's still not working how I would expect.

I'm having two problems...

• RVfplib is not available in the compiler options "compiler float lib source" on the SDK config.
• Performance is not different from libc when I call manually.

I believe my problem really is only the first bullet point, and the other will sort itself once I solve the first. From the documentation about this configuration option, is appears like I should just be able to switch to RVfplib, but that isn't one of the options and there is no other instructions on how to do this other than change this setting. I repeat the information here for notoriety sake.

CONFIG_COMPILER_FLOAT_LIB_FROM

Compiler float lib source

Found in: Compiler options

In the soft-fp part of libgcc, riscv version is written in C, and handles all edge cases in IEEE754, which makes it larger and performance is slow.

RVfplib is an optimized RISC-V library for FP arithmetic on 32-bit integer processors, for single and double-precision FP. RVfplib is “fast”, but it has a few exceptions from IEEE 754 compliance.

Available options:

• libgcc (COMPILER_FLOAT_LIB_FROM_GCCLIB)
• librvfp (COMPILER_FLOAT_LIB_FROM_RVFPLIB)

That is literally all the information there is about this on the ESP-IDF side of things. So, how do I actually get this option to populate and work? I have the library compiled and I can call it.... what else?

Attached is a sample project folder, complete with working builds. I just took the import_prebuilt example project, added the fresh build of the library, then slapped together some crude logic to try and run each of the libs through their paces manually.

I think that lib was added to esp-idf fairly recently... What ESP-IDF version are you using? If it's new enough (when in doubt, use the master branch) you should simply be able to select it in Menuconfig without having to add the sources manually; it should come with ESP-IDF.

ESP_Sprite wrote: ↑

Sat Mar 11, 2023 7:59 am

I think that lib was added to esp-idf fairly recently... What ESP-IDF version are you using? If it's new enough (when in doubt, use the master branch) you should simply be able to select it in Menuconfig without having to add the sources manually; it should come with ESP-IDF.

I'm using "ESP-IDF v5.0-dirty" I've tried the bleeding edge versions, but I get too many errors and problems to use it, mostly related to OpenOCD. Maybe I'll take another crack at it later today.

Just an update.

In accordance with the official instructions for RVfplib, I have attempted to edit the linker commands to GCC such that the linker unlinks gcc's math lib and links in RVfplib.

According to those instructions you are expected to simply add -nolibc followed by -lrvfp command flags to gcc when invoked, which, as far as I can tell, is done in ESP-IDF by modifying the CMake build script. Based on that, adding the following to project>main>CMakeLists.txt is what I came up with. . .
... and although this integrates without error, unfortunately, this doesn't seem to have changed much else.

Can someone explain what I have done here, and how close or far I am with this method? I have to admit, I am somewhat ignorant to how CMake works. That fact that it doesn't throw any errors has me somewhat hopeful that I'm on to something.

Another update.

Finally got around to trying out the master branch as suggested. I checked the configuration options... RVfplib is still not there.
...
Thinking about it more critically, my end goal isn't just to get RVfplib working and call it a day, but, rather, to be able to make my own hand tuned assembler language libs and install them side by side with C/C++.

The point being, even if I were to get the SDK configuration combo box to populate as intended, that would only "give me a fish" so to speak. I'm far more interested in making independent assembler library's work in a more generic fashion. A "teach me to fish" sort of answer.

... and that is making me start to feel like maybe I'm asking the wrong question...

I think so, yes RVfplib is a bit special since it replaces the floating point library, but generally having assembly stuff isn't that different from C stuff: simply create a component, dump your .S files in there, and they'll get linked and compiled.

Also, I think I found why you couldn't find the lib. Seems since the C2, we add rvfplib to the ROM of the chips, and the menuconfig option simply enables using that. The C3 was built before that, so it doesn't have the option.

ESP_Sprite wrote: ↑

Tue Mar 14, 2023 12:39 am

I think so, yes RVfplib is a bit special since it replaces the floating point library, but generally having assembly stuff isn't that different from C stuff: simply create a component, dump your .S files in there, and they'll get linked and compiled.

Also, I think I found why you couldn't find the lib. Seems since the C2, we add rvfplib to the ROM of the chips, and the menuconfig option simply enables using that. The C3 was built before that, so it doesn't have the option.

>"RVfplib is a bit special since it replaces the floating point library"
Right. Exactly.... and this point is certainly causing me problems.

I *DID* understand this from the beginning, of course. That is why for my first attempt I was trying to invoke RVfplib functions manually, as I have shown in the example provided. I wanted to see if I could run *BOTH* versions side-by-side, get a feel for the speed difference, then use that to *LATER* figure out if the math transplant was working. So far I am seeing no speed difference, which to me says I'm not getting RVfplib to run at all.... which is slightly odd. That, or RVfplib is already working in my example... does appear to be quite fast TBQH.